[coreboot] Got a problem, which may fix the other problem :-)

[Carl-Daniel Hailfinger]

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           0x0000c0 0x00100000 0x00100000 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             PROGBITS        00100080 000140 00e667 00 WAX  0   0 16
>   [ 3] .rodata           PROGBITS        0010e6e8 00e7a8 002b73 00   A  0   0  4
>   [ 4] .eh_frame         PROGBITS        0011125c 01131c 000070 00   A  0   0  4
>   [ 5] .data             PROGBITS        001112e0 0113a0 000150 00  WA  0   0 32
>   [ 6] .bss              NOBITS          00111440 0114f0 025450 00  WA  0   0 32
>   [ 7] .initctx          PROGBITS        001368a0 011500 000048 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
1        19
256      20
65536    90
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