[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