[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.