[U-Boot-Users] 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
From the boot loader,
rarp 0xc0008000 bootm
The trouble is that it starts executing at 0xc0008000 which is the image header.
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?
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@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
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.
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
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.
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
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.
participants (2)
-
Marc Singer -
Wolfgang Denk