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