Eric W. Biederman ebiederman at
Sun Mar 28 17:34:01 CEST 2004

ron minnich <rminnich at> writes:

> On 24 Mar 2004, Eric W. Biederman wrote:
> > That is a major challenge.  I have a back burner project to make romcc
> > not inline all function calls.  But until I do that I don't know of a
> > good way to reduce the code size.
> actually there is an easy way I tested way back that worked out ok. 
> You put the linuxbios_c payload BEFORE the auto.c-generated code. That
> really opens up the space. Requires some .lds hacking. I forget why I
> never committed it -- might have been an issue with mapping the ROM space. 
> It may have been because we did not have the new config tool and it was 
> too much work.

There is an issue with mapping ROM space, which means at least the code
to open that up needs to be within 64K or so.

Beyond that there is the piece that with if LinuxBIOS gets to big we can't
stuff a kernel in there.  And until we have exhausted all of our options
to shrink it we should not give LinuxBIOS too much license to grow.

Size will always be an important consideration for LinuxBIOS.

Currently code generated by romcc is a factor of 3 larger than hand
generated assembly.  If can get a correct implementation that does
not inline everything we should see a significant reduction in code

I have incorrect implementations that show a lot of promise.  Hopefully
I can find the time to build a correct version.

My rough numbers suggest that if we can keep LinuxBIOS to 64KB.  We can
squeeze a kernel in there with a 512KByte flash chip.  If we can't using
a kernel is pushed out farther in time.


More information about the coreboot mailing list