Problem solved.
On 10.02.2008 15:22, Carl-Daniel Hailfinger wrote:
On 10.02.2008 14:27, Stefan Reinauer wrote:
- Stefan Reinauer stepan@coresystems.de [080210 14:15]:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080210 13:02]:
Use the existing init_archive function to find the LAR in memory. This fixes the case where the option table was not found depending on a few unrelated parameters.
The parameters are obviously very related. The functionality was just moved into the lar utility ;-)
LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfffc0000 len 0x3c000 <------BUG! LAR: Start 0xfff00000 len 0x100000 LAR: Start 0xfff00000 len 0x100000
Your init_archive function is pretty broken, so the above line with the "BUG" mentioned is the only one that is half ways correct.
No, it is the only line being wrong.
You mentioned this is a default build, made with:
defconfig build, not default build. I'd like to blame the people for the confusion.
- 256 KB (COREBOOT_ROMSIZE_KB_256) (NEW)
So what I don't understand is why only the BUG line really assumes a 256k ROM while all others assume a 1M ROM.
Ouch. arch/x86/stage1.c:init_archive() tries to read the data written by util/lar/bootblock.c:fixup_bootblock(). Let's find out where the garbage is introduced.
No garbage, the defconfig image is 1024k and init_archive() reads exactly that value from the ROM.
Regards, Carl-Daniel