Using tools/mkimage
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
Quoted 1 line · In message <[email protected]> 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
Quoted 2 lines
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.
Quoted 4 lines
decompression, to
0xc00c8000. Normally, compressed kernel images are loaded at0xc0008000.
tools/mkimage-A arm -C none -a0xc0008000-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
Quoted 2 lines
The trouble is that it starts executing at
0xc0008000which is the image header.
Why is there trouble? It is OK.
Quoted 5 lines
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\
Quoted 2 lines
-e
0x0C008000-n 'ARM Linux-2.4.18' \
-darch/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
Signature · 4 lines
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)
Quoted 5 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> 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?
Quoted 6 lines
Quoted 2 lines
It was my intention to use the zImage file already compressed with a loader. RAM starts at
0xc0000000, the kernel wants to load, afterIt 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.
Quoted 5 lines
Quoted 4 lines
decompression, to
0xc00c8000. Normally, compressed kernel images are loaded at0xc0008000.
tools/mkimage-A arm -C none -a0xc0008000-d zImage image
Quoted 7 lines
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.
Quoted 2 lines · In message <[email protected]> you wrote:
Nice to see some organized documentation. I'm not finding mkimage in
Yes :-) Sorry for antedating the official announcement. Detlev?
Quoted 1 line
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 :-)
Quoted 5 lines
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 9 lines
Quoted 7 lines
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 uImageI'm not sure what you mean. Setting -a sets -e automatically.
Maybe. But load address and entry point address are not necessarily the same.
Quoted 1 line
Where do you get a uImage file?
As file "uImage" - the last argument in above call.
Quoted 2 lines
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).
Quoted 3 lines
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
Signature · 3 lines
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
Quoted 5 lines · Wolfgang Denk
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
Where do you get a uImage file?
As file "uImage" - the last argument in above call.
Right. The output. Duh.
Quoted 8 lines
Quoted 2 lines
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'?
Quoted 7 lines
Quoted 3 lines
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.
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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.
Quoted 9 lines
Quoted 5 lines
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?
Quoted 3 lines
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
Signature · 4 lines
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
Quoted 1 line · Wolfgang Denk
Which actual board are we talking about?
The Sharp KEV7A400. The CPU uses the ARM920T core.
Quoted 1 line
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.