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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
