Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: >> I always thought that when decompressing a uImage, that the entry point was >> stored in the header, (at the beginning of the file) and was read after the >> decompression took place - is that wrong? > > I'm not sure what all the different architectures do, but at least > for PowerPC, ARM and MIPS I know that one of the very first things we > do in the bootm code is to create a local copy of the image header.
The image header copy is created but its not always properly used, do_bootm_netbsd() and do_bootm_linux() for AVR32 and I386 are the examples where we access image location directly instead of the header copy. This might be fixed, but other, serious problem is concerning MULTI images, where we need to access second or third component. If the original image gets overwritten with the uncompressed kernel u-boot will not be able read len_ptr[] table and access components. New uImage format is even more demanding. As there is no such thing as image header (data is spread across the new uImage blob as a various properties) we are unable to create a header copy, thus we may not accept image overwrites. I have already posted a patch that adds overwrite checks, see: http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-testing.git;a=commit;h=7582438c285bf0cef82909d0f232de64ec567a8a Overwrite checking is done in bootm code as we may be using gunzip, bunzip or no compression and need to handle all the cases. Cheers, m. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users