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
Regards
YH
-----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 29, 2004 12:22 PM To: Richard Smith Cc: ollie@lanl.gov; Eric W. Biederman; Stefan Reinauer; LinuxBIOS Subject: Re: status information
On Fri, 29 Oct 2004, Richard Smith wrote:
Ronald G. Minnich wrote:
The issue is this: right now, linubios compressed payload AND romcc
object
fit in the top 64k. There is no need to do this. They're not fitting
anyway
at this point. romcc object startup can turn on full flash access, so
the
linuxbios compressed payload can be placed, not in the top 64k, but in the
next-to-top
64k. The linuxbios image will then have 128k available to it, not just
64k.
Then we can put all the debug prints we want into romcc code, which
would be
nice.
old-fashioned linuxbios
----------- (e.g.) 0xfff80000 | payload | | | | | ----------- 0xffff0000 | linux | | bios | ----------|
V2:
--------------0xfff80000 | smith | | payload | --------------0xffff0000 | c_payload | | uncompress | | to ram | | ---- | | auto.C | | compiled | | code | --------------
So there are really two "payloads"
There is startup code -- now compiled by romcc -- that turns on ram and uncompresses the c_payload to ram. The RAM code then does final setup and uncompresses the "smith payload" or whatever (Etherboot, filo, linux, ADLO) to ram.
So I'm just saying do this.
--------------0xfff80000 | smith | | payload | --------------0xfffe0000 | c_payload | | uncompress | | to ram | |------------|0xffff0000 | auto.C | | compiled | | code | --------------
That's all you have to do to fix the issues with romcc getting too big.
ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios