[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