I'm not sure what I can add to this discussion but I wanted to mention a couple of things I noticed in the discussion:

1) l-m-c / a-l-m-c will need modifying if you want to create an image for a7/a15 models.
Currently, the media create scripts have a hard coded list of boards they support, you have to modify the script if you want to add a new board.  This isn't hard, but it isn't a single line change either.  The tools people need to be in the loop to do this as they'd have to either make the changes or at the very least approve and integrate them.
Of course, with the new hwpack format that we agreed last week, this will be easier, but that won't be available for many weeks yet.

2) Creating a "proper" hwpack isn't as trivial a task as it might seem.  And maintaining our current hwpacks properly takes Tixy several days for every release.

3) Android doesn't use hwpacks, it builds its own kernel.  So that's actually easier, but I wanted to mention it as it didn't seem clear in the mails before this.

On 13 February 2012 23:05, Peter Maydell <peter.maydell@linaro.org> wrote:
On 13 February 2012 22:43, Paul Larson <paul.larson@linaro.org> wrote:
> I think you misunderstood what I'm getting at.  What I'm suggesting is that
> there should just be a proper hwpack for vexpress-a7/15+fastmodel.  This
> wouldn't have to be supported forever, just until we have real hardware that
> can be used.

A hwpack supporting the fast model would be good, but my understanding
of the workflow to use it would be:
 (1) use l-m-c to turn hwpack+rootfs into sd card image
 (2) unpack kernel and initrd from sd card image
 (3) boot on model using split kernel+initrd and the sd card image
 rootfs

> My understanding from the discussion before is that this would
> be possible, but might require some modifications to the bootloader.

I'm not sure what bootloader you're talking about here. When booting
a kernel on fast models there is no boot loader involved (this is why
we have the boot-wrapper code).

> If ARM can fix the 2GB limit, then what that means is *if* we someday need
> to test using a larger image, we can. But for now, it doesn't seem to be
> critical.  I did mention this to Roger at the connect, but I'll also pursue
> this further with ARM just in case.

The reason to file feature requests formally is that the fast models
are produced by a completely different part of ARM from that which
Roger is in charge of. Obviously he can raise things internally if
necessary [and it is worth keeping him in the loop] but mostly you're
just adding a longer and lossier channel for the information :-)

-- PMM