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

Stefan Reinauer stepan at coresystems.de
Tue Aug 26 02:18:33 CEST 2008


Carl-Daniel Hailfinger wrote:
> 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.
>   

The above looks like it seriously miscompiles the serengeti case.
There's no way AMD ram init fits in 640 bytes, when qemu's nop is 376.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://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/20080826/5c3081aa/attachment.sig>


More information about the coreboot mailing list