On Wed, Sep 5, 2012 at 4:22 PM, Scott Bambrough scott.bambrough@linaro.org wrote:

On Wed 05 Sep 2012 10:01:00 AM EDT, Dave Pigott wrote:

...

On 17 Jul 2012, at 21:15, Ryan Harkin wrote:

...

Hi Dave,

5. A5 and board naming.

I was talking to Scott about all this earlier today. He is keen that we get this TC2 board up and running, but he's also keen that we replace one of the A9 core tiles with the A5 tile - now that the A9 has stabilised. This is a commitment we made to ARM a long time ago and I've been putting it off while we had 1 x A9 playing up on us.

Scott and I discussed naming conventions and we were thinking that the numbering would be best on a per board type rather than overall vexpresses. Eg, we would have 3 boards:

vexpress-a501 vexpress-a901 vexpress-tc201

Hi Ryan,

Now that I am close to having the A5 booting in the lab, we need to discuss this issue, as we did with the panda. Basically, with the panda, Scott and I originally settled on them having a common device type, with a device_tag of either 4430 or 4460, and then naming the device instances as pandaXX and panda-esXX.

However, this was later changed so that we have two distinct devices, panda and panda-es, since people will want to test on a specific platform, and know that they are, rather than the situation as it would have been, in that if you didn't specify a device tag, the job would run on any panda - 4430 or 4460. It was felt that this was less than desirable.

So what I'm suggesting is, that we create three device types, viz:

vexpress-a5 vexpress-a9 vexpress-tc2

And then it's clear when you submit a job it's clear which device type you will run on, rather than, as in the panda case above, submitting to vexpress and not knowing which type is being targeted.

N.B. I am aware of the need/desire to be able to submit one job to lava and then have it run across all device variants, but that is orthogonal to this argument since, if we do implement such a feature, a device set would probably be defined, i.e. rather than saying "one each of vexpress variants" you would specify "vexpress-a5, vexpress-a9, vexpress-tc2", or indeed "panda, panda-es".

Just to be clear, is that what you were suggesting as well?

Brickbats and suggestions?

Thanks

Dave

Yes, we want three different device types. I don't want one situation with the Panda, and a different one with Versatile Express. That would just give me a headache trying to remember how to address a particular board.

Yeah. I think I agree with this.

we also talked about this for fastmodels and said tentatively that we would use different device types names for each (e.g. a9, big.LITTLE, AARCH64 ... while the 1x1 and 4x4 might or might not be seaparate device names or just tags).

On an entirely different subject, I'm thinking tags may be useful for optional HW modules. The new Origens have daughter cards for some functionality, and we could use tags to distinguish between boards with different daughtercards and boards with no daughtercards. What do you think?

right. as dave said, we have a tagging feature that will be used to route test jobs with specific requirements to boards that have "tagged" instrumentation and module variants.

On 12-09-06 04:51 AM, Dave Pigott wrote:

On 5 Sep 2012, at 15:22, Scott Bambrough wrote:

...

On Wed 05 Sep 2012 10:01:00 AM EDT, Dave Pigott wrote:

...

On 17 Jul 2012, at 21:15, Ryan Harkin wrote:

...

Hi Dave,

5. A5 and board naming.

I was talking to Scott about all this earlier today. He is keen that we get this TC2 board up and running, but he's also keen that we replace one of the A9 core tiles with the A5 tile

• now that the A9 has stabilised. This is a commitment we made

to ARM a long time ago and I've been putting it off while we had 1 x A9 playing up on us.

Scott and I discussed naming conventions and we were thinking that the numbering would be best on a per board type rather than overall vexpresses. Eg, we would have 3 boards:

vexpress-a501 vexpress-a901 vexpress-tc201

Hi Ryan,

Now that I am close to having the A5 booting in the lab, we need to discuss this issue, as we did with the panda. Basically, with the panda, Scott and I originally settled on them having a common device type, with a device_tag of either 4430 or 4460, and then naming the device instances as pandaXX and panda-esXX.

However, this was later changed so that we have two distinct devices, panda and panda-es, since people will want to test on a specific platform, and know that they are, rather than the situation as it would have been, in that if you didn't specify a device tag, the job would run on any panda - 4430 or 4460. It was felt that this was less than desirable.

So what I'm suggesting is, that we create three device types, viz:

vexpress-a5 vexpress-a9 vexpress-tc2

And then it's clear when you submit a job it's clear which device type you will run on, rather than, as in the panda case above, submitting to vexpress and not knowing which type is being targeted.

N.B. I am aware of the need/desire to be able to submit one job to lava and then have it run across all device variants, but that is orthogonal to this argument since, if we do implement such a feature, a device set would probably be defined, i.e. rather than saying "one each of vexpress variants" you would specify "vexpress-a5, vexpress-a9, vexpress-tc2", or indeed "panda, panda-es".

Just to be clear, is that what you were suggesting as well?

Brickbats and suggestions?

Thanks

Dave

Yes, we want three different device types. I don't want one situation with the Panda, and a different one with Versatile Express. That would just give me a headache trying to remember how to address a particular board.

On an entirely different subject, I'm thinking tags may be useful for optional HW modules. The new Origens have daughter cards for some functionality, and we could use tags to distinguish between boards with different daughtercards and boards with no daughtercards. What do you think?

Scott

OK. I realised a couple of problems as I started doing this.

1. When we transition, all vexpress jobs will start failing because

the vexpress device type will no longer exist. All affected parties will have to change their submission scripts to cope with this, so we need to set a deadline for the switchover and inform all affected parties.

2. If I delete the old device instances (vexpress-a901, vexpress-a902

and vexpress-tc2 we lose all the history of jobs run, or so it seems to me.

My proposed solution is as follows:

1. Create the new device types (which I've already done) 2) Name the

instances slightly differently to the old ones, viz vexpress-a5-XX, vexpress-a9-XX, vexpress-tc2-XX 3) Set a date for switching the old devices off and the new ones on and inform all concerned parties

I'll hold off doing anything until tomorrow when (hopefully) some consensus will have been arrived at

Thoughts?

I don't have any current jobs, or history worth keeping so in effect I'll be starting from scratch with the new device names. I'll go along with this plan, and I can accommodate whatever works for other folks.

Cheers,

Scott