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.


N Solanki

On 18 Mar 2015 20:13, "Kevin O'Connor" <kevin@koconnor.net> wrote:
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.