status information

Ronald G. Minnich rminnich at lanl.gov
Fri Oct 29 14:00:00 CEST 2004


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



More information about the coreboot mailing list