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.