[U-Boot] understanding mkimage a bit more

[U-Boot] understanding mkimage a bit more

[Charles Krinke]

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 at hwa:~/svn/trunk/linux-2.6.35.12$
ckrinke at hwa:~/svn/trunk/linux-2.6.35.12$

-- 
Charles Krinke

[U-Boot] understanding mkimage a bit more

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Fri, 6 May 2011 09:24:27 -0700
> Von: Charles Krinke <charles.krinke@gmail.com>
> An: u-boot at 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 at hwa:~/svn/trunk/linux-2.6.35.12$
> ckrinke at 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

[U-Boot] understanding mkimage a bit more

[Charles Krinke]

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 at 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 at hwa:~/svn/trunk/linux-2.6.35.12$
> > ckrinke at 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

[U-Boot] understanding mkimage a bit more

[Eric Cooper]

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] understanding mkimage a bit more

[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 at 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?

-- 
Charles Krinke

[U-Boot] understanding mkimage a bit more

[Eric Cooper]

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] understanding mkimage a bit more

[Charles Krinke]

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 at 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?"

-- 
Charles Krinke

[U-Boot] understanding mkimage a bit more

[Wolfgang Denk]

Dear Charles Krinke,

In message <BANLkTinOx16=skDXuSgwK7sLF1uKY11Q3g@mail.gmail.com> you wrote:
>
> 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

Yes, it is.

> be the pitfalls?"

Misconfiguration of your board.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you use modules, you pay the price. Sane embedded solutions
running in "tight" environments don't use modules :-)
    -- Benjamin Herrenschmidt in <1258234866.2140.451.camel@pasglop>