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