[coreboot] [PATCH] v3: fix bug in ad-hoc archive finding code in mc146818rtc.c
Stefan Reinauer
stepan at coresystems.de
Sun Feb 10 14:27:51 CET 2008
* Stefan Reinauer <stepan at coresystems.de> [080210 14:15]:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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.
You mentioned this is a default build, made with:
> 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.
Maybe this introduced all the access speed problems we were seeing
lately? Scanning 4x the needed area is pretty overkill.
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
More information about the coreboot
mailing list