Hey Carl,<br><br>Sorry about the late reply, I've been on and off during flights out of the country and<br>haven't got around to check this issue.<br><br>I have done some more investigating on this issue but no luck (yet).
<br>It made some sense to me as well that the problem might be with the use of 7ZIP-specific<br>compression/decompression but I'm not sure of that anymore.<br>I have attempted to use the LZMA SDK library to compress the image using that instead of
<br>the 7z application (p7zip) but actually the booloader/kernel denied me from that image, possibly<br>because it was written specifically to 7z so I am sure that encoding the image must be done<br>using 7z. That's about how to encode the image.
<br><br>Regarding the decompression which happens in the kernel/bootloader stage - well the print out is:<br><br> Launching kernel decompressor.<br> Starting LZMA Uncompression Algorithm.<br> Compressed file is LZMA format.
<br> Kernel decompressor was successful ... launching kernel.<br><br>So I am relying on the fact that it decompressed fine and that there is no bug in the decompression code<br>(I've been provided with an SDK so this is not some home-brew code that might contain more errors than usual).
<br><br>So going over the code more thouroughly - the part that handles the decompression calls<br>the kernel_entry function which in turn calls the start_kernel and that to _text (if I remember the ordering<br>right) and I am assuming that the problem is there somewhere.
<br><br>A good thing to remember is that the only difference from this problem to a working kernel image<br>is the CONFIG_KERNEL_COMPRESS_7ZIP option which I use.<br>If I use the default GZIP compression then the kernel image loads just fine.
<br><br>I guess this could also be some sort of alignment problems, but memory alignments specific<br>to the 7z compression is somewhat doubtful, isn't it?<br><br><br>Any insight is welcome,<br><br>Regards,<br>Liran.<br>
<div><span class="gmail_quote">On 8/31/07, <b class="gmail_sendername">Carl-Daniel Hailfinger</b> <<a href="mailto:firstname.lastname@example.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Liran,<br><br>On 30.08.2007 17:06, liran tal wrote:<br>> I have stumbled upon posts by Carl-Daniel and Stefan while trying to get<br>> some information why when I compile a kernel image with 7zip (LZMA)<br>> the kernel image doesn't load up.
<br>> [...]<br>> I have been given an SDK based on Linux 2.6.10 for an embedded mips 4Kec (TI<br>> Avalanche series) cpu to build an image from. When I build the image<br>> using GZIP (standard) the kernel boots fine but when I
<br>> choose 7ZIP support for better compression, the 'make ram_zimage' procedure<br>> is working successfully<br>> but when the image attempts to run off the device (via nfs) it writes:<br>><br>> Launching kernel decompressor.
<br>> Starting LZMA Uncompression Algorithm.<br>> Compressed file is LZMA format.<br>> Kernel decompressor was successful ... launching kernel.<br>><br>> and nothing happens after that.
<br><br>Ah, the classic "no logs available" problem because the kernel hangs<br>during early boot. Since it works with gzip I have to assume there is a<br>bug either in the decompression routine or some #define has not been
<br>adjusted to the architecture. Less likely, but still possible would be<br>that the decompression routine is touching memory which is special on<br>your machine.<br><br>> I've been attempting to figure out what is causing the kernel not to load
<br>> and after reading the post by Carl-Daniel and Stefan about 7zip<br>> using different headers than "normal" LZMA sdk<br>> I thought that this could be the problem.<br><br>Possible, but rather unlikely. What do the docs for the lzma kernel
<br>patch say? Is it supposed to be used with p7zip or the original SDK?<br><br>Carl-Daniel<br><br></blockquote></div><br>