On Wed, 22 Oct 2014 20:32:53 -0700 Vagrant Cascadian <vagrant@debian.org> wrote: > On 2014-10-19, Paul Wise wrote: > > On Mon, Oct 20, 2014 at 1:09 AM, Steve McIntyre wrote: > >> On Sun, Oct 19, 2014 at 10:27:30AM -0400, Martin Michlmayr wrote: > >>>* Paul Wise <pabs@debian.org> [2014-10-18 15:58]: > >>>> Debian's "hardware wanted" web page says that the ARM porters > >>>> (Riku Voipio and Martin Michlmayr are named in comments) are > >>>> looking for donations of ARM NAS systems. Is this hardware > >>>> request still wanted? > >>>> > >>>> https://www.debian.org/misc/hardware_wanted > ... > > That said, we should probably move the page to the wiki so that a > > larger group of people can update it. I wanted to ask about ARM > > hardware before doing that though. > > What I would find really useful is to have some sort of remote access > to various boards that are supported by the u-boot packages in Debian > (which are almost all ARM based), without having to host them all > myself. As far as testing the kernel is concerned, this is planned - using LAVA allied to Jenkins to do the builds - and initial test support is already available. (It just needs someone to provide the build files and some scripts which are to be run after booting those files.) I've not had a lot of success preseeding DI to a fully automated run on ARM, if someone has a working preseed config which can be passed on the kernel command line and which presents no prompts of any kind, I can implement that on a variety of ARM boards using LAVA. (The limitation being that the bootloader commands would be entered by LAVA using the existing bootloader, not one in the image - so bootloader interactive commands rather than installation.) > Essentially, someting like a porter box, LAVA can provide fully automated tests as well as hacking sessions (which provide a similar access to a dchroot on a porter box but with the additional support of specifying the kernel to use in the hacking session). > but with access to be able to > install the bootloader... ... which is the hard bit. To reinstall the bootloader in any kind of automated system requires an automated way to fallback to a working bootloader when the test bootloader fails. LAVA has tried several approaches over time, there is inevitably some kind of specialised hardware required to automate that process. Software can only go so far and bootloader failure will need manual intervention to replace the media - not practical for any automated system providing access to the hardware. So far, LAVA has had two services for this - a simplistic SDMux which was not sufficiently stable and a more complex LMP SDMux using a CortexA0 which did work but has since become unmaintained (not due to a lack of interest, due to a lack of someone to do the hardware design and firmware updates). Maybe UEFI can provide a means for this but then we're likely to need to test UEFI changes too ... > Not sure how that would work exactly, as it typically requires > flashing the device and/or installing to a raw SD card or some such, > but maybe a hosted LAVA environment *might* be an option for this > sort of test... It is part of the plan. Right now, I can run specified tests on behalf of others using a variety of ARM hardware (v7 and v8) available via staging.validation.linaro.org or validation.linaro.org but my main effort is refactoring LAVA to make it easier to run tests on developer systems but collate the results to a single frontend. That is intended to allow DDs to host ARM devices at home and make those devices available to a LAVA instance run by Debian which makes those boards available to submissions by other DDs. I'm aiming for that in Stretch. LAVA in Jessie isn't able to handle NAT, so requires a static IP at each end. Longer term, the work going on for OpenTAC (http://linux.codehelp.co.uk/?p=171) could also lead to a supportable SDMux implementation via http://www.vero-apparatus.com/ but that is quite a long way away.... -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgphSFS_vuRFb.pgp
Description: OpenPGP digital signature