On Fri, May 6, 2011 at 10:33 AM, Gerhard Pircher gerhard_pircher@gmx.net wrote:
-------- Original-Nachricht --------
Datum: Fri, 6 May 2011 09:24:27 -0700 Von: Charles Krinke charles.krinke@gmail.com An: u-boot@lists.denx.de Betreff: [U-Boot] understanding mkimage a bit more
I can create a uImage with mkimage with "-C gzip" and it boots fine. If I use "-C none", it hangs on boot with bootm in u-boot. The arguments below come directly from the linux-2.6.35.12 kernel which creates uImage from vmlinux.bin.gz (which is already compressed, I know, but that is a different issue).
In trying to work through how mkimage, uboot, objdump and objcopy interact, my The question becomes "Why does a uImage created with -C gzip boot with bootm and a uImage created with -C none hang?"
In both $ scripts/mkuboot.sh -A ppc -O linux -T kernel -C gzip -a 0x00000000 -e 0x00000000 -n Linux-2.6.35.12-svn438 -d ./vmlinux.bin.gz /tftpboot/uImage Image Name: Linux-2.6.35.12-svn438 Created: Fri May 6 09:05:42 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1714808 Bytes = 1674.62 kB = 1.64 MB Load Address: 0x00000000 Entry Point: 0x00000000
$ scripts/mkuboot.sh -A ppc -O linux -T kernel -C none -a 0x00000000 -e 0x00000000 -n Linux-2.6.35.12-svn438 -d ./vmlinux.bin.gz /tftpboot/uImage Image Name: Linux-2.6.35.12-svn438 Created: Fri May 6 09:10:31 2011 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size: 1714808 Bytes = 1674.62 kB = 1.64 MB Load Address: 0x00000000 Entry Point: 0x00000000 ckrinke@hwa:~/svn/trunk/linux-2.6.35.12$ ckrinke@hwa:~/svn/trunk/linux-2.6.35.12$
You wrap a compressed kernel image in an uImage that is marked as 'uncompressed'. Thus U-Boot doesn't decompress the uImage and tries to directly execute the gzipped data. Decompress vmlinux.bin.gz with "gzip -d" before converting it with mkuboot.sh and it should work.
regards, Gerhard -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Dear Gerhard:
I appreciate your clue. That was the needed piece of information to bootm an uncompressed kernel.
What I am working on is speeding up the boot process of an MPC8323 design and this helps a bit.
The next issue is the flash file system. Normally, I like to use JFFS2 for reliability as embedded devices frequently have their power switch turned off at any time. I do understand that UBIFS is getting more prevalent lately and I wonder if you or anyone else has a comment on the suitability of UBIFS in an environment where the power will be turned off and on exexpectdly and frequently.
In googling UBIFS problems, I do see posts across the internet of UBIFS devices that will not boot after power is turned off and on. My experience with JFFS2 is that it has always recovered during boot with all the designs I have participated in over the last several years. Admiteddly, the act of doing something like "scandisk" on boot slows the boot down, but does seem to add reliability.
-- Charles Krinke