BOOT: Add "bootz" command to boot Linux zImage

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Tested on PXA270 based Voipac PXA270.

---
 common/Makefile    |    1 +
 common/cmd_bootz.c |  178 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_bootz.c

index 1b672ad..1ddf77a 100644
@@ -42,6 +42,7 @@ COBJS-y += xyzModem.o
 # core command
 COBJS-y += cmd_boot.o
 COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o
+COBJS-$(CONFIG_CMD_BOOTZ) += cmd_bootz.o
 COBJS-y += cmd_help.o
 COBJS-y += cmd_nvedit.o
 COBJS-y += cmd_version.o

1.7.7.1

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Tested on PXA270 based Voipac PXA270.

---
 common/Makefile    |    1 +
 common/cmd_bootz.c |  178 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_bootz.c

V2: Use CONFIG_BOOTZ_MAX_KERNEL_LMB_SIZE to reserve kernel LMB

index 1b672ad..1ddf77a 100644
@@ -42,6 +42,7 @@ COBJS-y += xyzModem.o
 # core command
 COBJS-y += cmd_boot.o
 COBJS-$(CONFIG_CMD_BOOTM) += cmd_bootm.o
+COBJS-$(CONFIG_CMD_BOOTZ) += cmd_bootz.o
 COBJS-y += cmd_help.o
 COBJS-y += cmd_nvedit.o
 COBJS-y += cmd_version.o

1.7.7.1

Marek Vasut wrote at Friday, November 11, 2011 7:51 PM:

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?

2) Should bootz_start() validate it was passed a valid zImage, by checking the magic value in the header?

3) boot_get_ramdisk() only accepts uImage (legacy or FIT). Can/should it be enhanced to accept raw ramdisk images?

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

I don't have any other specific comments on the code.

You may want to CC everyone else involved in the IH_TYPE_KERNEL_NOLOAD discussion - I imagine they'll all be interested in this too.

--
nvpublic

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.

Sounds good.

Certainly, that'd help. Are you willing to look into that?

Yes, this is valid point. We should be very careful about this. So suggestions how to handle this ?

Sure.

Marek Vasut wrote at Monday, November 14, 2011 12:42 PM:

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.

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.

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