Am Samstag, 24. Mai 2008 14:22:43 schrieb Carl-Daniel Hailfinger:
On 24.05.2008 13:00, Harald Gutmann wrote:
Am Freitag, 23. Mai 2008 20:23:11 schrieb Carl-Daniel Hailfinger:
Try this: Report actual and wanted LZMA decompression scratchpad size: Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
The patch worked, i had to set the decoder scratchpad size to 50335340, which seems quite much to me, but there was no more error on "Uncompressing to RAM".
The maximum scratchpad size right now is ~512k. Anything above that will corrupt memory.
That is a good reason why it doesn't work here.
Acked-by: Harald Gutmann harald.gutmann@gmx.net To add that also into the coreboot v2 reprository, and not just in v3.
But booting with LAB didn't work, the last lines which i get for now are: "rom_stream: 0xffc00000 - 0xfffe7fff Uncompressing to RAM 0x0100000"
Maybe, as i set the scratchpad size that high, it takes really long to decompress the image to the RAM. I waited about 2 minutes and nothing more happened, i think that should be enaugh time to decompress 4MB into the RAM.
Any idea what is wrong with my image, or what could be done to get debug informations?
The scratchpad has to fit in a special area below 1 MB. Considering various other constraints, the maximum size is probably around 512k. A bigger scratchpad will clobber interrupt vectors and wrap around to the top of the 4 GB address space. The decompressor will then write to the area occupied by ROM (writes discarded) and non-RAM areas (writes discarded). That's a bad thing.
If a compressed payload needs more than 512k scratchpad, the payload is most likely corrupt.
how can i check if the payload is corrupt or not? the uncompressed payload, the compressed one and an manually uncompressed ( lzma-utils from http://tukaani.org/lzma/) are included here: http://rapidshare.com/files/117291876/payloads.tar.bz2.html
Regards, Carl-Daniel
Regards, Harald