[U-Boot-Users] Using tools/mkimage

[U-Boot-Users] Using tools/mkimage

[Marc Singer]

I'm having trouble understanding how an image should be created.  

It was my intention to use the zImage file already compressed with a
loader.  RAM starts at 0xc0000000, the kernel wants to load, after
decompression, to 0xc00c8000.  Normally, compressed kernel images are
loaded at 0xc0008000.

  tools/mkimage -A arm -C none -a 0xc0008000 -d zImage image

[U-Boot-Users] Using tools/mkimage

[Wolfgang Denk]

In message <20030805020001.GA15284@buici.com> you wrote:
> I'm having trouble understanding how an image should be created.  

See the README. See the U-Boot and Linux Guide
at http://www.denx.de/twiki/bin/view/DULG/WebHome

> It was my intention to use the zImage file already compressed with a
> loader.  RAM starts at 0xc0000000, the kernel wants to load, after

It makes no sense to use a zImage file. It was one of the  intentions
of  U-Bot  (well,  it  was PPCBoot then) to get rid of this bootstrap
loader.

> decompression, to 0xc00c8000.  Normally, compressed kernel images are
> loaded at 0xc0008000.
> 
>   tools/mkimage -A arm -C none -a 0xc0008000 -d zImage image

I don't see any use of the "-e" option in this command. And zImage is
not what you want. If you want to use an  uncompressed  kernel  image
this should be something like

	mkimage -A arm -O linux -T kernel -C none -a 0x0C008000 \
	-e 0x0C008000 -n 'ARM Linux' \
	-d arch/arm/boot/compressed/piggy uImage


> The trouble is that it starts executing at 0xc0008000 which is the
> image header.

Why is there trouble? It is OK.

> Based on reading the README, I'm suspicious that I've misconstrued the
> load addresses and that the loader doesn't support uncompressed
> images.
> 
> Any tips?

It works fine for me like this:

-> mkimage -A arm -O linux -T kernel -C none -a 0x0C008000\
>  -e 0x0C008000 -n 'ARM Linux-2.4.18' \
> -d arch/arm/boot/compressed/piggy  /tftpboot/TRAB/uImage-uncompressed
Image Name:   ARM Linux-2.4.18
Created:      Tue Aug  5 09:04:27 2003
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1930071 Bytes = 1884.83 kB = 1.84 MB
Load Address: 0x0c008000
Entry Point:  0x0c008000


And on the target:

TRAB # tftp c400000 /tftpboot/TRAB/uImage-uncompressed
TRAB # run nfs_args add_net add_misc;bootm
## Booting image at 0c400000 ...
   Image Name:   ARM Linux-2.4.18
   Created:      2003-08-05   7:04:27 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1930071 Bytes =  1.8 MB
   Load Address: 0c008000
   Entry Point:  0c008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Linux version 2.4.18-rmk7 (wd at atlas.denx.de) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #2 Tue Aug 5 09:00:03 MEST 2003
CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0
Machine: S3C2400
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=192.168.3.1:/opt/eldk/arm_920TDI ethaddr=00:D0:93:00:88:FB ip=192.168.3.68:192.168.3.1::255.255.0.0:trab::off console=ttyS0 panic=1
...



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I can't say I've ever been lost, but I was bewildered once for  three
days.                                     - Daniel Boone (Attributed)

[U-Boot-Users] Using tools/mkimage

[Marc Singer]

On Tue, Aug 05, 2003 at 09:08:22AM +0200, Wolfgang Denk wrote:
> In message <20030805020001.GA15284@buici.com> you wrote:
> > I'm having trouble understanding how an image should be created.  
> 
> See the README. See the U-Boot and Linux Guide
> at http://www.denx.de/twiki/bin/view/DULG/WebHome

Nice to see some organized documentation.  I'm not finding mkimage in
the table of contents.  Where is it described?

> > It was my intention to use the zImage file already compressed with a
> > loader.  RAM starts at 0xc0000000, the kernel wants to load, after
> 
> It makes no sense to use a zImage file. It was one of the  intentions
> of  U-Bot  (well,  it  was PPCBoot then) to get rid of this bootstrap
> loader.

Perhaps it is strong to say "no sense".  In fact, there is a good
reason to use zImage when u-boot is one of several methods of booting
a kernel.  It helps us to know that the same exact code is running in
every situation.

> > decompression, to 0xc00c8000.  Normally, compressed kernel images are
> > loaded at 0xc0008000.
> > 
> >   tools/mkimage -A arm -C none -a 0xc0008000 -d zImage image
> 
> I don't see any use of the "-e" option in this command. And zImage is
> not what you want. If you want to use an  uncompressed  kernel  image
> this should be something like
> 
> 	mkimage -A arm -O linux -T kernel -C none -a 0x0C008000 \
> 	-e 0x0C008000 -n 'ARM Linux' \
> 	-d arch/arm/boot/compressed/piggy uImage

I'm not sure what you mean.  Setting -a sets -e automatically.

Where do you get a uImage file?

I'm not sure why, but it appears to be working now.  It is probable
that one of the components was out-of-sync.

I'm on to a new problem.  For some reason, a kernel booted from blob
returns a bogo-mips value of 79 while the same kernel booted from
u-boot returns a bogo-mips value of 39.  It's an intriguing mystery.

Cheers.

[U-Boot-Users] Using tools/mkimage

[Wolfgang Denk]

In message <20030805073513.GA32163@buici.com> you wrote:
>
> Nice to see some organized documentation.  I'm not finding mkimage in

Yes :-) Sorry for antedating the official announcement. Detlev?

> the table of contents.  Where is it described?

Sorry,  it  ain't  (yet).  It's  implicitely  hitten  in  the  kernel
Makefiles. But you made your point, now I know what to add next :-)


> > It makes no sense to use a zImage file. It was one of the  intentions
> > of  U-Bot  (well,  it  was PPCBoot then) to get rid of this bootstrap
> > loader.
> 
> Perhaps it is strong to say "no sense".  In fact, there is a good

It makes no sense. U-Boot provides an interface  which  (1)  includes
all of the functionality of the bottstrap loader [plus much more] and
(2) which assumes the kernel call interface, which is not used by the
bootstrap loader.

> reason to use zImage when u-boot is one of several methods of booting
> a kernel.  It helps us to know that the same exact code is running in
> every situation.

I think it is the kernel you  care  about  right?  So  run  the  same
kernel,  once  by  wrapping  it with a bootstrap loader into a zImage
file, and once by wrapping it with mkimape into an uImage file.

> > I don't see any use of the "-e" option in this command. And zImage is
> > not what you want. If you want to use an  uncompressed  kernel  image
> > this should be something like
> > 
> > 	mkimage -A arm -O linux -T kernel -C none -a 0x0C008000 \
> > 	-e 0x0C008000 -n 'ARM Linux' \
> > 	-d arch/arm/boot/compressed/piggy uImage
> 
> I'm not sure what you mean.  Setting -a sets -e automatically.

Maybe. But load address and entry point address are  not  necessarily
the same.

> Where do you get a uImage file?

As file "uImage" - the last argument in above call.

> I'm not sure why, but it appears to be working now.  It is probable
> that one of the components was out-of-sync.

What you are doing is bogus. "bootm" is meant to start  images  which
have  the expected kernel interface. If you load a zImage file (let's
ignore for a moment that this makes no sense :-) you should  use  the
"go"  command  toi  start  it  as this provides the interfqce for the
zImage bootstrap loader (i. e. none).

> I'm on to a new problem.  For some reason, a kernel booted from blob
> returns a bogo-mips value of 79 while the same kernel booted from
> u-boot returns a bogo-mips value of 39.  It's an intriguing mystery.

Different  initialization  of  the  hardware?  Different  passing  of
parameters?  When  booting a image with a non-matching call interface
many things can go wrong.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"The whole world is about three drinks behind."     - Humphrey Bogart

[U-Boot-Users] Using tools/mkimage

[Marc Singer]

On Tue, Aug 05, 2003 at 09:47:30AM +0200, Wolfgang Denk wrote:
> It makes no sense. U-Boot provides an interface  which  (1)  includes
> all of the functionality of the bottstrap loader [plus much more] and
> (2) which assumes the kernel call interface, which is not used by the
> bootstrap loader.
>
> > reason to use zImage when u-boot is one of several methods of booting
> > a kernel.  It helps us to know that the same exact code is running in
> > every situation.
> 
> I think it is the kernel you  care  about  right?  So  run  the  same
> kernel,  once  by  wrapping  it with a bootstrap loader into a zImage
> file, and once by wrapping it with mkimape into an uImage file.

Thought that is so, the value of using the same exact file in all
instances superceedes technical superiority.  Should this change for
us, I'm certain that we'll embrace the u-boot way.

> Maybe. But load address and entry point address are  not  necessarily
> the same.

On ARM, both the kernel and the zImage bootstrap enter at the first
loaded address.

> 
> > Where do you get a uImage file?
> 
> As file "uImage" - the last argument in above call.

Right.  The output.  Duh.


> > I'm not sure why, but it appears to be working now.  It is probable
> > that one of the components was out-of-sync.
> 
> What you are doing is bogus. "bootm" is meant to start  images  which
> have  the expected kernel interface. If you load a zImage file (let's
> ignore for a moment that this makes no sense :-) you should  use  the
> "go"  command  toi  start  it  as this provides the interfqce for the
> zImage bootstrap loader (i. e. none).

Hmm.  I'm not sure what you mean by 'the expected kernel interface'.
According to the ARM source, the zImage bootstrap expects the same
thing that the kernel expects r1 to contain an architecture ID and
that the kernel parameters are stored in a predefined memory location.
This is what the code in lib_arm/armlinux.c does when it handles bootm.

Can you amplify what you mean about 'expected kernel interface'?


> > I'm on to a new problem.  For some reason, a kernel booted from blob
> > returns a bogo-mips value of 79 while the same kernel booted from
> > u-boot returns a bogo-mips value of 39.  It's an intriguing mystery.
> 
> Different  initialization  of  the  hardware?  Different  passing  of
> parameters?  When  booting a image with a non-matching call interface
> many things can go wrong.

Yes.  Of course.  As I've stated above, the call interface appears to
be OK.  The parameters block differs only in that u-boot passes an
initrd tag that is newer than the kernel understands.  I have no
initrd, so at present I don't care.  I've been looking into the
hardware part but haven't yet found any place where they differ.
Believe me, this is $1000 question in the "Mysterious Code" category.

Cheers.

[U-Boot-Users] Using tools/mkimage

[Wolfgang Denk]

In message <20030805163732.GA7011@buici.com> you wrote:
>
> > I think it is the kernel you  care  about  right?  So  run  the  same
> > kernel,  once  by  wrapping  it with a bootstrap loader into a zImage
> > file, and once by wrapping it with mkimape into an uImage file.
> 
> Thought that is so, the value of using the same exact file in all
> instances superceedes technical superiority.  Should this change for
> us, I'm certain that we'll embrace the u-boot way.

You _are_ using the same file, just wrapped differently.

> > What you are doing is bogus. "bootm" is meant to start  images  which
> > have  the expected kernel interface. If you load a zImage file (let's
> > ignore for a moment that this makes no sense :-) you should  use  the
> > "go"  command  toi  start  it  as this provides the interfqce for the
> > zImage bootstrap loader (i. e. none).
> 
> Hmm.  I'm not sure what you mean by 'the expected kernel interface'.
> According to the ARM source, the zImage bootstrap expects the same
> thing that the kernel expects r1 to contain an architecture ID and

Which actual board are we talking about?

> Yes.  Of course.  As I've stated above, the call interface appears to
> be OK.  The parameters block differs only in that u-boot passes an
> initrd tag that is newer than the kernel understands.  I have no

Which kernel version are you using?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There are some things worth dying for.
	-- Kirk, "Errand of Mercy", stardate 3201.7

[U-Boot-Users] Using tools/mkimage

[Marc Singer]

On Tue, Aug 05, 2003 at 07:37:42PM +0200, Wolfgang Denk wrote:
> Which actual board are we talking about?

The Sharp KEV7A400.  The CPU uses the ARM920T core.

> Which kernel version are you using?

Linux cerise 2.4.17-rmk2-lineo5 #8 Mon Aug 4 20:09:02 PDT 2003 armv4l unknown

It is a kernel patched by Lineo.