I've registered a BP in advance of any agreement: https://blueprints.launchpad.net/lava-lab/+spec/hack-box-hardware-ticketing-system
Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog On 20 Sep 2012, at 08:39, Dave Pigott wrote: > On 19 Sep 2012, at 21:04, Zach Pfeffer wrote: > >> On 19 September 2012 07:11, Loïc Minier <[email protected]> wrote: >>> On Wed, Sep 19, 2012, Dave Pigott wrote: >>>> Device Type Instances >>>> vexpress-a5 vexpress-a5-01 >>>> vexpress-a9 vexpress-a9-01 >>>> vexpress-tc2 vexpress-tc2-01 >>>> vexpress-tc2-02 >>>> vexpress-tc2-03 >>>> vexpress-tc2-04 >>>> >>>> Notes: >>>> * vexpress-tc2-01 will remain offline for external user testing. I'm >>>> thinking that perhaps we should switch this around and make that tc2-04 >>>> and then remove it from the list to make it tidier >>> >>> Yes; note that one of the TC2 was actually meant to be reserved to TCWG, >>> with remote access, but we currently have nobody to set it up as they >>> desire (custom kernel with PM features turned off). If the TCWG frees >>> resources to pick this up, they'll grab one of these TC2 boards. >> >> Sorry to vector off a bit, but we could probably get it set up for >> them. We'd also like a TC2 box we could run code on. > > We have a total of four at the moment. The idea was that there was one spare > for remote access, but what I'm hearing now is that the way the TCWG want it > set up is different from the way that, say, the Android team would want it > set up. This means two sidelined TC2s, with two for LAVA. My concern is when > another group or two wants remote access. > > Let's try to think of a way of handling this properly. Let's gather the > requirements and see if there is some sensible "ticketing" type system, with > some auto-configuration, that would make sense. In terms of re-flashing a > board, this would be easy to provide access to, by connecting the board to a > USB port on the gateway server. It always mounts with a known volume name > (which is configurable, of course), so there's no issue of having to udev it > like we do the snowballs. > > In a nutshell: I think we need to raise a BP for this work. Does everyone > agree, or am I tilting at windmills? > > Thanks > > Dave > >> >>>> * I have one spare a9 tile and a mother board. Does anyone want me to put >>>> this in a new motherboard and bring a second a9 online? >>> >>> Makes sense; apparently the new motherboard are slightly different, is >>> it easy to tell them apart? We should make sure that people working on >>> advanced tiles (e.g. TC2 or later) get the very latest baseboard to >>> avoid any incompatibilities. IIUC all baseboards and daughterboards are >>> compatible, but best to avoid that risk. >>> >>> -- >>> Loïc Minier >> >> >> >> -- >> Zach Pfeffer >> Android Platform Team Lead, Linaro Platform Teams >> Linaro.org | Open source software for ARM SoCs >> Follow Linaro: http://www.facebook.com/pages/Linaro >> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog >
_______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
