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: 1) Kernel instability: ARM kernels are often less stable than on x86 - mainline kernel.org kernels frequently break on some board while adding cool new features for another one. Our use of modules is less tested than built-in drivers used by the defconfigs. => Compare Kernel:stable when there's a problem in openSUSE:Factory:ARM. => Test Kernel:HEAD kernels before they hit Tumbleweed and report such issues on opensuse-kernel list. Chances are, problems need to be reported to the respective upstream kernel maintainers. => Kernel:linux-next has been in preparation for testing maintainers' queues even earlier, in particular for enablement of new boards. => On most boards that run kernel-lpae you can compare kernel-default, and for kernel-default you can compare kernel-vanilla to rule out any SUSE patches. => perl-Bootloader and U-Boot enhancements for grub2 are two projects to help dealing with multiple possibly broken kernels. 2) qemu-linux-user: For ARMv6, updated packages may fail to work under QEMU emulation when new syscalls or ioctls got introduced, leading to failing or hanging builds. => Help find a small test case narrowing down what the issue is. => Packages' testsuites can get disabled or ignored for QEMU builds. 3) Lack of automated QA: We inherit not just kernel updates but all package updates, without having openQA based testing before publishing 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 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. 4) Work in progress: Whenever we touch things to make them better, something may break. The same may happen if we don't update something. => Report regressions early. Check if there was a recent submission that looks suspicious. Be prepared to submit small fixes yourself to speed things up. Usual suspects are: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS https://build.opensuse.org/package/show/openSUSE:Factory:ARM/dtb-source https://build.opensuse.org/package/show/openSUSE:Factory:ARM/u-boot Also, since our armv7l build power is insufficient, keeping your eyes open whether, e.g., x86 users are wastefully branching kernel packages and forgetting to turn off armv7l builds can help to get our fixes to you more quickly. f.ex.: https://build.opensuse.org/request/show/245580 Lastly, while you're waiting for other Raspberry Pi fixes, you could help clean up any "trivial" packages in the Contrib projects that you use (e.g., raspberrypi-userland, pihwm) and find them a new devel project (e.g., hardware), so that they can get submitted to Tumbleweed properly. That won't help your boot problems but it will take some time (weeks?) to go through reviews, so looking into it early will save you time later. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org