Hi Liran,
I have thought a while about your problem but no obvious solution appeared.
On 04.09.2007 17:50, liran tal wrote:
I have done some more investigating on this issue but no luck (yet). It made some sense to me as well that the problem might be with the use of 7ZIP-specific compression/decompression but I'm not sure of that anymore. I have attempted to use the LZMA SDK library to compress the image using that instead of the 7z application (p7zip) but actually the booloader/kernel denied me from that image, possibly because it was written specifically to 7z so I am sure that encoding the image must be done using 7z. That's about how to encode the image.
OK, so the format seems to be OK.
Regarding the decompression which happens in the kernel/bootloader stage - well the print out is:
Launching kernel decompressor. Starting LZMA Uncompression Algorithm. Compressed file is LZMA format. Kernel decompressor was successful ... launching kernel.So I am relying on the fact that it decompressed fine and that there is no bug in the decompression code
At least no obvious bug.
(I've been provided with an SDK so this is not some home-brew code that might contain more errors than usual).
My experience is that SDKs may contain really hard-to-find errors because sometimes the code is tested, but not reviewed.
So going over the code more thouroughly - the part that handles the decompression calls the kernel_entry function which in turn calls the start_kernel and that to _text (if I remember the ordering right) and I am assuming that the problem is there somewhere.
A possible problem is overlap between the compressed and decompressed kernel, another possibility is decompression to the wrong address.
Can you try to get both decompression routines to print out where exactly the decompressed code is located? If possible, printing the end addr of the decompressed data will be interesting as well.
A good thing to remember is that the only difference from this problem to a working kernel image is the CONFIG_KERNEL_COMPRESS_7ZIP option which I use. If I use the default GZIP compression then the kernel image loads just fine.
You could try with early serial support to get at least some logs, but I doubt you'd get that far.
I guess this could also be some sort of alignment problems, but memory alignments specific to the 7z compression is somewhat doubtful, isn't it?
Many patches for embedded systems not merged in mainline Linux have had their share of problems in the past because the review is less thorough (if any). It has been quite a lot of time since I last looked at the in-kernel LZMA decompression code and I'm not quite sure how it works anymore. Hm... another option is a compiler/linker bug.
The decompression scratch pad memory is sometimes quite big and depends on lots of factors, one of them being dictionary size. Try using the default values for everything when compressing. That might help as well.
Regards, Carl-Daniel