On 07.02.2008 17:55, ron minnich wrote:
Lar does not currently process bss quite right.
I kind of blame ELF, but see what you think.
Here is filo. These are program headers used in Execution (the 'E' in ELF):
LOAD 0xc0 0x0010 0x0010 0x11430 0x36890 RWE 0x20
LOAD 0x011500 0x001368a0 0x001368a0 0x00048 0x00048 RW 0x20
Note the LOAD sections. Here is more of FILO. These are section
headers used in Linking (the 'L' in ELF')
[ 2] .text PROGBITS00100080 000140 00e667 00 WAX 0 0
16
[ 3] .rodata PROGBITS0010e6e8 00e7a8 002b73 00 A 0 0
4
[ 4] .eh_frame PROGBITS0011125c 01131c 70 00 A 0 0
4
[ 5] .data PROGBITS001112e0 0113a0 000150 00 WA 0 0
32
[ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0
32
[ 7] .initctx PROGBITS001368a0 011500 48 00 WA 0 0
32
OK, where did the LOAD sections come from? The first is a combination
of .text, .rodata, .eh_frame, and .data.
.initctx is the second one.
What's the FILO problem? Well:
ide_probe: ide_probe drive #0
ide_probe: ctrl 1188128 base f9e8
base f9e8 is the IO base for the controller. f9eh? WHAT IS THAT? Well,
it is a chunk of memory that is *supposed* to be zero!
it's garbage. it's in the .bss area and lar does not initialize it or
anything. Why? Well:
[ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0
32
Note that there is NO program header (LOAD above) for this area of memory!
There is only this program header!
So the elf processor in LAR (which I grabbed from v2) is not
processing that section. I don't think it should have to: it's a
section header, not a program header, but this is an esoteric
argument.
So I need to modify LAR to create another payload segment for .bss,
which is just a zero-filled thing.
Nice analysis.
I will just look for a section header named .bss and use that. Now,
this will be a zero-filled LAR entry but once compressed it will be
nothing -- zero's compress nicely. But should we have a LAR type BSS
for this type of usage? I am wondering. The BSS type would have a base
address and size, and would be taken to mean Zero this piece of ram.
I'd go with your suggestion to use a compressed zero-filled LAR entry
compressed with LZMA. It may not be perfectly efficient, but it is
surely good enough when the alternative is additional LAR complexity in
the ROM.
LZMA compressed size table for zeros:
size compressed
119
256 20
6553690
1048576 231
We successfully sidestepped the special LAR member for fillup, why not
do the same with BSS?
The fact that we can sidestep all those issues without changing the LAR
header nor the LAR parser in ROM is a testimony to the thoughtful design
that went into LAR.
Semi-OT: The LZMA utility we use will create zero length archives if it
gets zero length input. That may be fatal if we ever add zero length
LZMA comprssed files to the LAR. Maybe adding that case to a test suite
will ensure the code never explodes.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
