[SeaBIOS] IDT issue

[Naresh G. Solanki]

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 18 Mar 2015 20:13, "Kevin O'Connor" <kevin at 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.
>
> -Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.seabios.org/pipermail/seabios/attachments/20150319/b6f8ff4a/attachment.html>