[U-Boot-Users] Using tools/mkimage
elf at buici.com
Tue Aug 5 18:37:32 CEST 2003
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
> > 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.
More information about the U-Boot