On 20 September 2012 04:17, Dave Pigott <[email protected]> wrote: > I've registered a BP in advance of any agreement: > > https://blueprints.launchpad.net/lava-lab/+spec/hack-box-hardware-ticketing-system
Adding Amit as well. Some requirements from my side, 1. TC2 is remotely resetable. 2. TC2 can be completely reflashed remotely (may need SD-Mux) 3. Can connect to the serial port remotely Basically all the things that: http://www.synaccess-net.com/remote-power.php/2/37 thing allows you to do. > > 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 > > > -- 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
