[U-Boot] [PATCH V2] BOOT: Add "bootz" command to boot Linux zImage

[Stephen Warren]

Marek Vasut wrote at Monday, November 14, 2011 12:42 PM:
> > Marek Vasut wrote at Friday, November 11, 2011 7:51 PM:
> > > This command boots Linux zImage from where the zImage is loaded to.
> > > Passing initrd and fdt is supported.
> >
> > Marek, this looks pretty neat. A few general questions though:
> >
> > 1) I believe the zImage format is ARCH-specific. I'm not sure that on
> > non-ARM ARCHs, you just start executing at the start of the zImage. Should
> > this function be somehow disabled on non-ARM until something explicit is
> > done about that?
> 
> Well zImage contains the decompressor which handles the proper placement of the
> kernel. Therefore there is only the catch the user must not be an idiot and must
> load the kernel at the correct address himself.

My point is that since the zImage format is ARCH-specific, is it always
true that to boot a zImage, you always jump directly to offset 0 of that
image, or are there other cases to consider?

In particular, looking at arch/x86/boot/header.S, which is what I believe
is at the start of an x86 (b)zImage, if you jump to offset zero, you'll
end up seeing a message stating that booting from floppy isn't support.
Instead, I /think/ you need to jump to offset 512. Similarly, it looks
like the magic number for an x86 (b)zImage is at a different offset within
the image, and has a different value.

Now, all of that can be catered for pretty easily by bootz with just a few
ifdefs in the future, but given the existing implementation possibly only
works for ARM, it seems sensible to prevent usage on non-ARM for now.

> > 3) boot_get_ramdisk() only accepts uImage (legacy or FIT). Can/should it
> > be enhanced to accept raw ramdisk images?
> 
> Certainly, that'd help. Are you willing to look into that?

I would prefer not to commit to this; I'm pretty swamped. Unfortunately,
bootm (plus IH_TYPE_KERNEL_NOLOAD) works fine for me, so I'm not terribly
motivated here.

> > 4) Is it safe to assume that do_bootm_linux() only cares about images->ep
> > and nothing else for the kernel? I know it's coded that way right now,
> > but I wonder if someone might refactor bootm and forget about bootz and
> > change this assumption. I guess this is OK though...
> 
> Yes, this is valid point. We should be very careful about this. So suggestions
> how to handle this ?

Well, just keeping an eye out for any bootm-related changes would be
simplest.

One way to enforce this might be to change each ARCH's implementation of
do_bootm_linux() to accept the specific values it needs right now. This 
would document exactly what information was required. You'd also need a
shim function to convert from prototype boot_os_fn (see common/cmd_bootm.c's
boot_os[] array) to this new prototype. Have cmd_bootz() call the specific
function directly instead of the shim (so passing explicit data instead of
the images array). With that in place, any change to do_bootm_linux() would
fail to compile unless cmd_bootz() was adjusted appropriately.

-- 
nvpublic