On Wed, Jan 19, 2011, James Westby wrote:
Would in general be nice to deal with other image types like Android and ChromeOS and avoid .debs unless targetting Ubuntu images.
I think this is the wrong aim to be putting in the document. I think that the aim should be to be able to produce hardware packs that can be shared between Ubuntu, Android and ChromeOS images, and leave the implementation of that as a separate question.
Hmm maybe the wording was poor, but it's definitely the intent that the hwpacks be kept as portable across image types as possible.
cmdline
Is this going to be a static string, or will it need to substitute variables in to it as it is used?
Good idea; I don't know; maybe we want linaro-image-tools to substitute rootfs partition number or so.
omap_mlo
I think it's generally better to not put strings like "omap" in the name, and rather have a list of files that will have the same treatment (in this case copy to the boot disk)
I think it can be either way; I don't care too strongly. We could say "extra_boot_files", but then we might not know it's a x-loader anymore. Imagine that we'd use the hwpack as a source to boot a board over a serial line, we might have to send the MLO first, and then u-boot. If we move to extra_boot_files we can't do that anymore. It's a judgment call really.
(I prefixed the name with omap_ as to not clutter the namespace with OMAP specific settings)
igep_uboot_ini
Similar for this (list of files to create)
I don't like the name of that field, but it's basically a flag whether or not we need a boot.ini; I actually think we could do without this entirely ("do we need this" reminder I had put for myself there). This is basically a requirement as long as we miss a x-loader. Once we have one, we don't care about the default bootloader configuration in flash which requires a boot.ini (IIRC).
fdt
What would we do with this if we found it in a hwpack?
I don't know; I need more handson experience with DT to tell. It might be that we don't need this this cycle because the DT will be embedded in the zImage. Otherwise, we'd have to mkimage it along uImage and uInitrd, probably in a uFdt or something like that, and then change the boot script to pass it to the kernel.
linux_image
I don't think there's any point in ignoring this now, and then doing something with it later. It should have a hwpack format bump so that users can be told that they need a newer l-m-c, otherwise when we first release Android hwpacks people will generate unbootable images.
So "old" l-i-t will bail out against new hwpacks again? If we could allow them to continue working, that would be nicer IMO
We should only aim for forward compatibility where we know what we will do with the option when it exists. I have no problem not using all options, but unless we know what to do with an option we should not put it in the format, as we will need a format bump when we do know what to do with it anyway.
Granted we don't have a full plan for Cros and Android, but I was hoping we could have a tentative one including this linux_image field. In the worst case, we indeed move to an incompatible hwpack format. But if it's good enough, it means natty's l-i-t will be able to use natty+1 hwpacks.