On 21.12.15 11:03, Ludwig Nussel wrote: > Andreas Färber wrote: >> Am 17.12.2015 um 13:04 schrieb Freek de Kruijf: >>> I tested the latest released Tumbleweed image for the Raspberry Pi 2B, >>> Build354.2 which shows a black screen and does not boot at all, same >>> as the >>> latest one from Staging, which is from a few days back. >>> >>> Currently there are no working Tumbleweed images for any of the >>> Raspberry Pi >>> systems. Is there anything I can do, apart from testing the latest >>> images? >> >> Yes. >> >> "Black screen" and "does not boot" do not help getting it fixed. >> Buy yourself a cheap UART adapter (less than 4 EUR for 3.3 V!) and post >> concrete error output if something is not working. A good report is half >> the fix! >> >> Others have reported really trivial issues (like missing symlink/file) >> that either you yourself could fix on your SD card or that someone >> without access to that hardware can quickly fix in OBS if told what >> issue there is. >> >> There's some main sources of trouble: >> [...] > > Might be worth putting those hints in the wiki and linking it from every > HCL page. Esp the contrib ones. > >> 3) Lack of automated QA: We inherit not just kernel updates but all >> package updates, without having openQA based testing before publishing > > So the images should have Factory in their names rather than Tumbleweed.
It's a mixed bag :). I think there were reasons we had to rename to Tumbleweed - something with the publisher not working otherwise. Dirk might remember details here. > >> images. Factory submissions get build-tested only for x86 and ppc. >> Further, limited OBS build workers for ARM do not always allow for >> consistent rebuilds before publishing packages. >> >> Most breakages are hardware-specific though, in some u-boot-foo package >> or a specific kernel driver or depending on NEON availability that would >> not show in a generic KVM guest - and only very few of the boards have a >> matching QEMU emulation. Hardware-in-the-loop testing was an alternative >> idea. Several projects around openQA had been investigated but only few >> successfully completed. >> >> => Find ways to use openQA for more testing, e.g. serial only rather >> than graphical testing with QEMU machines such as cubieboard. Maybe > > IOW cubieboard can be emulated by qemu? Do you have a command line for > me? What host architecure is needed for that? Can the aarch64 worker we > have for openQA emulate that in reasonable speed? So far we haven't managed to make AArch64 KVM work with full AArch32 only VMs. Also keep in mind that with KVM host cpu == guest cpu, so you'd get a cubieboard with an A57 CPU - something nobody expects to see. > >> contribute to upstream efforts such as finally upstreaming Raspberry Pi >> or Beagleboard emulations, to broaden the base to test against. >> >> => Use Wifi-enabled SD cards, USB gadget devices, HDMI framegrabbers, >> JTAG adapters or other creative solutions to implement automated >> hardware testing, avoiding some of the QEMU/KVM shortcomings. > > That would be nice :-) The minimum requirement for openQA would be > control over the power switch and SD card and access to the serial port. > On the weekend I found this: > http://www.linuxinternals.org/blog/2014/06/04/a-microsd-card-remote-switcher/ > > Maybe that could be cheap solution to allow the openQA worker to get > the disk image on the target. Yup, Linaro also has built similar adapters for their QA initiative. Unfortunately my hardware skills aren't as great, so I doubt I could actually solder this thing together ;). If you can find a way to get us a dozen, we can start to make automated testing become reality. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
