size status information
Eric W. Biederman
ebiederman at lnxi.com
Fri Oct 29 17:23:01 CEST 2004
"Ronald G. Minnich" <rminnich at lanl.gov> writes:
> On Fri, 29 Oct 2004, YhLu wrote:
>
> > If the ROMCC can handle function not as inline. You may don't need to
> > enlarge the 64K limit.
> > Current Auto.c compiled is some big. Esp the print_debug causes the problem
>
> yes.
>
> The long term solution is to have all vendors set up working cache-as-ram,
> short term is harder and involves romcc. It would be good if more people
> could learn romcc innards and help with this difficult problem.
At the moment I would be happy for some bug reports. That included
a small code sample the reduced problems. Not that I have heard
of many bugs.
First remember that by turning the down the level of debugging size
can almost always be decreased in LinuxBIOS to a size we can test things
with.
So the things we can to do to keep size down.
1) Use gcc-3.4 instead of gcc-3.3
From my experience the Opteron platform has the largest and
most complex code before memory initialization. So using
the arima hdama dual opteron board is a reasonable gauge on how
large we are. Building with gcc-3.4 and looking at current cvs
the status is:
$ ls -l linuxbios_payload.nrv2b
rw-r--r-- 1 eric eric 28930 Oct 29 16:30 linuxbios_payload.nrv2b
$ size crt0.o
text data bss dec hex filename
36121 0 0 36121 8d19 crt0.o
36121 + 28930 = 65051
65536 - 65051 = 485
$ ls -l linuxbios_payload.nrv2b
-rw-r--r-- 1 eric eric 28393 Oct 29 16:28 linuxbios_payload.nrv2b
$ size crt0.o
text data bss dec hex filename
37033 0 0 37033 90a9 crt0.o
37033 + 28393 = 65426
65536 - 65426 = 110
So even with gcc-3.4 I am running quite tight but it does still build.
It is interesting that it takes nearly 1KiB for fallback.c
2) Kill unused strings.
3) Expand the space available for linuxbios_c.gz
4) Better tune the current 64bit support for size. I think the size
increase of the last few days has something to do with gcc's poor
handling of 64bit integers. Perhaps linuxbios_c needs to go native
64bit on x86-64 capable machines.
5) Get non-inlining working usefully with romcc.
6) cache-as-ram support (long term).
Eric
More information about the coreboot
mailing list