[coreboot] r820 - in coreboot-v3: mainboard/amd/serengeti southbridge/amd/amd8111

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 25.08.2008 17:10, ron minnich wrote:
>   
>> On Mon, Aug 25, 2008 at 8:00 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
>>   
>>     
>>> Is the superio init code getting too complex? Or the "enable all flash"
>>> code? Or CAR init? Did I miss something
>>>       
>> I don't think you missed anything. At the moment, I would bet that I
>> have put un-needed stuff in stage 0. That is why I said "may" :-)
>>   
>>     
>
> There's also some stuff which can be either in initram or the bootblock.
>   
If something can be put in initram (or in another stage like initram),
it should not live in the boot block.

The bootblock is the bare minimum of functions needed to get things up
(ie for loading the other stages/modules), plus very few functions like
printk that are used in all module stages.

If anything suddenly starts bloating the bootblock, there is most likely
a conceptional bug in that code.

> We also may decide to switch to gcc -combine -fwhole-program for the
> bootblock. That would probably reduce bootblock size by 20%.
>   
I heard you say that before. Is it as simple as enabling those switches
in the makefiles? Or will it require further action?

I agree if there are 20% in for just enabling a compiler option, we
should definitely use it. But using compiler revision dependent trickery
and hacks to be able to go bloat elsewhere is not the right approach.


-- 
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080825/164dcc72/attachment.sig>