Add vexpress_a9 platform to linaro-android-media-create

[Tixy (Jon Medhurst)]

The ARM Landing Team is bringing up Android on the Versatile Express platform and linaro-android-media-create needs extending to add support for this. The attached patch does this.

[Dave Martin (dave-martin-arm)]

> Add vexpress_a9 platform to linaro-android-media-create

Should the name "vexpress" be used instead, for consistency with
linaro-media-create? Or does l-a-m-c use an independent set of board
names?

Other platforms based on vexpress would need to be more fully qualified
in any case.

Cheers
---Dave

[Tixy (Jon Medhurst) (tixy)]

On Fri, 2011-11-11 at 17:09 +0000, Dave Martin wrote:
> > Add vexpress_a9 platform to linaro-android-media-create
>
> Should the name "vexpress" be used instead, for consistency with
> linaro-media-create? Or does l-a-m-c use an independent set of board
> names?
>
> Other platforms based on vexpress would need to be more fully qualified
> in any case.

For linaro-media-create we can specify all of the required board
parameters in the hardware pack so the tool doesn't need a command-line
board parameter to distinguish between vexpress flavours.

linaro-android-media-create however needs everything hardcoded into the
tools, so we need to distinguish between vexpress core-tiles to pass the
correct memory addresses to U-Boot.

--
Tixy

[Mattias Backman (mabac)]

On Mon, Nov 14, 2011 at 8:27 AM, Tixy (Jon Medhurst)
<email address hidden> wrote:
> On Fri, 2011-11-11 at 17:09 +0000, Dave Martin wrote:
>> >   Add vexpress_a9 platform to linaro-android-media-create
>>
>> Should the name "vexpress" be used instead, for consistency with
>> linaro-media-create?  Or does l-a-m-c use an independent set of board
>> names?
>>
>> Other platforms based on vexpress would need to be more fully qualified
>> in any case.
>
> For linaro-media-create we can specify all of the required board
> parameters in the hardware pack so the tool doesn't need a command-line
> board parameter to distinguish between vexpress flavours.
>
> linaro-android-media-create however needs everything hardcoded into the
> tools, so we need to distinguish between vexpress core-tiles to pass the
> correct memory addresses to U-Boot.

Still, I agree that we should keep the naming consistent with the
names in l-m-c for code maintenance reasons and for not confusing the
end user with different names for the same board. If it's important to
change the name of the BoardConfig and --dev option we should also
make the same change in l-m-c. The --dev option is left in l-m-c since
it will be needed when there is support for multiple boards in one
hwpack.

> - boot_script = None
> + boot_script = 'boot.scr'

This change should go in the AndroidVexpressConfig so it does not
break support for existing Vexpress hwpacks. That line is still in
boards.py only to maintain support for old hwpacks. and will not take
effect for new hwpacks anyway.

Would you push your branch to launchpad and create a merge proposal so
we can keep track of this change?

Thanks,

Mattias

[Tixy (Jon Medhurst) (tixy)]

On Mon, 2011-11-14 at 15:41 +0000, Mattias Backman wrote:
> On Mon, Nov 14, 2011 at 8:27 AM, Tixy (Jon Medhurst)
> <email address hidden> wrote:
> > On Fri, 2011-11-11 at 17:09 +0000, Dave Martin wrote:
> >> > Add vexpress_a9 platform to linaro-android-media-create
> >>
> >> Should the name "vexpress" be used instead, for consistency with
> >> linaro-media-create? Or does l-a-m-c use an independent set of board
> >> names?
> >>
> >> Other platforms based on vexpress would need to be more fully qualified
> >> in any case.
> >
> > For linaro-media-create we can specify all of the required board
> > parameters in the hardware pack so the tool doesn't need a command-line
> > board parameter to distinguish between vexpress flavours.
> >
> > linaro-android-media-create however needs everything hardcoded into the
> > tools, so we need to distinguish between vexpress core-tiles to pass the
> > correct memory addresses to U-Boot.
>
> Still, I agree that we should keep the naming consistent with the
> names in l-m-c for code maintenance reasons and for not confusing the
> end user with different names for the same board. If it's important to
> change the name of the BoardConfig and --dev option we should also
> make the same change in l-m-c. The --dev option is left in l-m-c since
> it will be needed when there is support for multiple boards in one
> hwpack.

OK, how about if create a sub-class of VexpressConfig in l-m-c called
VexpressA9Config and add a 'vexpress-a9' entry for it in board_configs.
My AndroidVexpressA9Config class for l-a-m-c could then derive from
this?

> > - boot_script = None
> > + boot_script = 'boot.scr'
>
> This change should go in the AndroidVexpressConfig so it does not
> break support for existing Vexpress hwpacks. That line is still in
> boards.py only to maintain support for old hwpacks. and will not take
> effect for new hwpacks anyway.
>

It shouldn't break anything by adding this as the VExpress U-Boot
currently doesn't read boot.scr - so the file will just get ignored.

I was adding this because I plan on fixing U-Boot very soon so it does
read boot.scr, and when I do, both Android and V1 hardware packs will
need to create this. I can add this as a separate patch in a week or so.

> Would you push your branch to launchpad and create a merge proposal so
> we can keep track of this change?

So I should create a Bazaar branch with my changes in then? Will this
need to be on Launchpad, e.g. under https://code.launchpad.net/~tixy?
How do I create a 'merge proposal'? (As you may have gathered, I've
never done this sort of thing before ;-)

--
Tixy

[Mattias Backman (mabac)]

On Tue, Nov 15, 2011 at 8:50 AM, Tixy (Jon Medhurst)
<email address hidden> wrote:
> On Mon, 2011-11-14 at 15:41 +0000, Mattias Backman wrote:
>> On Mon, Nov 14, 2011 at 8:27 AM, Tixy (Jon Medhurst)
>> <email address hidden> wrote:
>> > On Fri, 2011-11-11 at 17:09 +0000, Dave Martin wrote:
>> >> >   Add vexpress_a9 platform to linaro-android-media-create
>> >>
>> >> Should the name "vexpress" be used instead, for consistency with
>> >> linaro-media-create?  Or does l-a-m-c use an independent set of board
>> >> names?
>> >>
>> >> Other platforms based on vexpress would need to be more fully qualified
>> >> in any case.
>> >
>> > For linaro-media-create we can specify all of the required board
>> > parameters in the hardware pack so the tool doesn't need a command-line
>> > board parameter to distinguish between vexpress flavours.
>> >
>> > linaro-android-media-create however needs everything hardcoded into the
>> > tools, so we need to distinguish between vexpress core-tiles to pass the
>> > correct memory addresses to U-Boot.
>>
>> Still, I agree that we should keep the naming consistent with the
>> names in l-m-c for code maintenance reasons and for not confusing the
>> end user with different names for the same board. If it's important to
>> change the name of the BoardConfig and --dev option we should also
>> make the same change in l-m-c. The --dev option is left in l-m-c since
>> it will be needed when there is support for multiple boards in one
>> hwpack.
>
> OK, how about if create a sub-class of VexpressConfig in l-m-c called
> VexpressA9Config and add a 'vexpress-a9' entry for it in board_configs.
> My AndroidVexpressA9Config class for l-a-m-c  could then derive from
> this?

That sounds good. Having a Vexpress superclass will be good since I
gather from the earlier comments that there may be other incarnations
of the Vexpress. So please go ahead with that change.

>
>> > -    boot_script = None
>> > +    boot_script = 'boot.scr'
>>
>> This change should go in the AndroidVexpressConfig so it does not
>> break support for existing Vexpress hwpacks. That line is still in
>> boards.py only to maintain support for old hwpacks. and will not take
>> effect for new hwpacks anyway.
>>
>
> It shouldn't break anything by adding this as the VExpress U-Boot
> currently doesn't read boot.scr - so the file will just get ignored.

Good, the I won't worry about that.

>
> I was adding this because I plan on fixing U-Boot very soon so it does
> read boot.scr, and when I do, both Android and V1 hardware packs will
> need to create this. I can add this as a separate patch in a week or so.

If we need it, we might as well change it now. I was hoping that we
wouldn't create any more hwpacks using the V1 hwpack format though. If
we use the V2 hwpack format, l-m-c has no need to know about boot
script paths etc.

>
>> Would you push your branch to launchpad and create a merge proposal so
>> we can keep track of this change?
>
> So I should create a Bazaar branch with my changes in then? Will this
> need to be on Launchpad, e.g. under https://code.launchpad.net/~tixy?

Yes please, then we get the complete change history and can comment
away while ...

[Tixy (Jon Medhurst) (tixy)]

On Tue, 2011-11-15 at 09:01 +0000, Mattias Backman wrote:
> On Tue, Nov 15, 2011 at 8:50 AM, Tixy (Jon Medhurst)
> >
> > I was adding this because I plan on fixing U-Boot very soon so it does
> > read boot.scr, and when I do, both Android and V1 hardware packs will
> > need to create this. I can add this as a separate patch in a week or so.
>
> If we need it, we might as well change it now. I was hoping that we
> wouldn't create any more hwpacks using the V1 hwpack format though. If
> we use the V2 hwpack format, l-m-c has no need to know about boot
> script paths etc.

The ARM landing team uses V2 hardware packs but I believe the vexpress
hwpack produced from jcrigby's tree uses V1, I didn't want to break
that.

--
Tixy