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