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.
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?
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.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
