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

On Fri, May 6, 2011 at 11:33 AM, Eric Cooper ecc@cmu.edu wrote:

On Fri, May 06, 2011 at 11:13:39AM -0700, Charles Krinke wrote:

...

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.

It has been very resilient to power failures in my experience -- the Linux ubifs code has always managed to recover, and very quickly.

The main pitfall is that U-Boot's support for ubifs is only the read-only subset of Linux's.  That means it can read from a consistent ubifs partition, but not from one that needs repair (because that requires writing).  So you can't rely on booting your Linux kernel *from a ubifs partition*.  But if you have your kernel in a separate, read-only uImage partition you should be fine (it's just more annoying to update kernels).

-- Eric Cooper             e c c @ c m u . e d u _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Dear Eric:

I appreciate your kind reply. I wonder if you (or someone else) might consider doing me another favor.

I understand a bit about setting up JFFS2 and have used drivers/mtd/maps for this purpose. I also understand that in setting up UBIFS, I will enable UBIFS in the linux kernel.

But, on the flash, I am a little perplexed as I have not done this before.

Can someone give me a few hints and clues about setting up the flash in the manner Eric describes, please?

On Fri, May 6, 2011 at 1:30 PM, Eric Cooper ecc@cmu.edu wrote:

On Fri, May 06, 2011 at 11:45:08AM -0700, Charles Krinke wrote:

...

I understand a bit about setting up JFFS2 and have used drivers/mtd/maps for this purpose. I also understand that in setting up UBIFS, I will enable UBIFS in the linux kernel.

But, on the flash, I am a little perplexed as I have not done this before.

Can someone give me a few hints and clues about setting up the flash in the manner Eric describes, please?

This page may help:    https://wiki.xkyle.com/Install_Debian_Lenny_on_a_Seagate_Dockstar

It has a description of how to set up a ubifs image (under "Generate UBIFS IMage") and how to write a kernel and ubifs image to NAND flash (in step 5 of "Get the DockStar Going").

This all presumes that you have a partitioning scheme set up on your flash.  If you're starting from scratch or completely overwriting someone else's firmware, you can set up whatever you want (you'll want to learn about the mtdparts kernel boot parameter).  Otherwise, you can use the existing system to find out what it is (try "cat /proc/mtd" if it's running an embedded Linux).

-- Eric Cooper             e c c @ c m u . e d u _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Oops. Maybe I need to back up a tiny bit here.

I have a NOR flash, not a NAND flash.

I have been trying to compile UBIFS into u-boot for the last little while and keep stumbling over NAND unresolveds at link time. So, I have to ask the question: "Is it reasonable to expect UBIFS to work in NOR flash on a MPC8323ERDB with u-boot-2011.03 and if so, what might be the pitfalls?"