[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 02:32:32 CEST 2008


On 26.08.2008 02:18, Stefan Reinauer wrote:
> 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.
>   

I looked at the code and there's no miscompilation. Current v3 serengeti
initram looks like this:
int main(void)
{
        printk(BIOS_DEBUG, "Hi there from stage1\n");
        post_code(POST_START_OF_MAIN);

        printk(BIOS_DEBUG, "stage1 returns\n");
        return 0;
}

So the code is a NOP and gcc figured it out. Perfect.

Regards,
Carl-Daniel

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





More information about the coreboot mailing list