Problem solved. On 10.02.2008 15:22, Carl-Daniel Hailfinger wrote: > On 10.02.2008 14:27, Stefan Reinauer wrote: > >> * Stefan Reinauer <[EMAIL PROTECTED]> [080210 14:15]: >> >> >>> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [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. >>> 2. 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 -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
