[coreboot] r820 - in coreboot-v3: mainboard/amd/serengeti southbridge/amd/amd8111
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.
>> 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
- normal/initram/segment0 (24060 bytes)
+ normal/initram/segment0 (640 bytes)
- normal/initram/segment0 (6436 bytes)
+ normal/initram/segment0 (5364 bytes)
- 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.
More information about the coreboot