Hi,
With respect to the auto reset issue,
I did detailed memory test on my board and found the following
0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF region is not writable and every byte reads as 0xFF.
Coreboot loads Seabios in the address range 0xA0000 to 0x10_0000.
When I tried to read the memory range through XDP after coreboot decompressed the seabios payload,
it appeared to be fine.
When Seabios was executing , it was resetting at or around malloc init.
Later I introduced WBINVD instruction just before jump to payload,
XDP which was displaying program code started reading 0xFF.
This indicates that the payload loading was happening in cache memory of CPU & executing
from it.
Here I conclude that the memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF is not usable in my board
& is the cause of seabios failure.
I tested the same region by booting with bios provided with board & found that the memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF is not usable.
Can anyone suggest me how to go about this issue. My intention is to boot Win7 successfully.
Regards,
N Solanki
On Tue, Mar 17, 2015 at 06:42:06PM +0530, Naresh G. Solanki wrote:
> Dear All,
>
> I'm trying to port coreboot with seabios payload on Intel Atom E6xx based
> board,
>
> The problem I'm facing is during malloc init, the board reboot & keeps on
> rebooting after displaying malloc init debug message.
>
> I tried to track it & found that it might probably be due to dummy IDT
> loaded @seabios entry point (entry_elf)
>
> Once it reboot I'm finding that breakpoints set are not working.
> Breakpoints are set through JTAG-XDP.
>
> Can anyone give an idea to how to go about this issue.
SeaBIOS loads a dummy IDT when in 32bit mode, because the code is
never supposed to raise an interrupt (interrupts and NMIs are always
disabled when in 32bit mode). So, if you're seeing a fault with the
IDT, it likely indicates something is causing a software fault.
If a fault is ocurring in malloc_init(), then I'd check that the
memory between 0xc0000-0x100000 is fully read/writable. You could
also try disabling CONFIG_MALLOC_UPPERMEMORY to see if that changes
behavior. malloc_init() is also called right after self-relocation,
so check that the memory map that coreboot provides is accurate. You
could also try disabling CONFIG_RELOCATE_INIT to see if that changes
the fault.
-Kevin