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.
--
Loïc Minier
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
