[Linaro-validation] a7/a15 kernels for fast models in lava
ryan.harkin at linaro.org
Tue Feb 14 12:18:16 UTC 2012
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
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
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 at linaro.org> wrote:
> On 13 February 2012 22:43, Paul Larson <paul.larson at linaro.org> wrote:
> > I think you misunderstood what I'm getting at. What I'm suggesting is
> > 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
> > 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
> > 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-validation