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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Aug 26 01:24:36 CEST 2008


On 25.08.2008 19:57, Stefan Reinauer wrote:
> 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.
>   

Absolutely agreed.

>> 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 just enabled it for initram in my testing because the initram
makerules only needed to add -fwhole-program. My earlier patches which
switched to source-based rules do make conversion to -fwhole-program
rather easy as well.

Results with gcc 4.2.1, real size in the LAR:
- is current state
+ is with -fwhole-program

amd_serengeti
-  normal/initram/segment0 (24060 bytes)
+  normal/initram/segment0 (640 bytes)

artecgroup_dbe62
-  normal/initram/segment0 (6436 bytes)
+  normal/initram/segment0 (5364 bytes)

emulation_qemu-x86
-  normal/initram/segment0 (420 bytes)
+  normal/initram/segment0 (376 bytes)

The savings vary between substantial and almost improbable. I do suspect
something fishy in the serengeti target, but we'd need to test in Simnow.

> I agree if there are 20% in for just enabling a compiler option, we
> should definitely use it.

Yes. I'll post patches in short order.

> But using compiler revision dependent trickery
> and hacks to be able to go bloat elsewhere is not the right approach.
>   

Fully agreed. We need to keep the bloat down. Once that is done, we can
apply optimizations on top.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list