[opensuse-arm] Images for Raspberry Pi
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? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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?
Same here. None of the available images work. The kernel seems to be a patched copy of some kernel devel project state. Any chance to rebase that on something current? Looks like the sources come from some git, but where? This is what's on the serial port: ---8<--- U-Boot 2016.01-rc1 (Dec 01 2015 - 17:28:22 +0000) DRAM: 880 MiB WARNING: Caches not enabled RPI 2 Model B MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr reading /boot.scr 113 bytes read in 26 ms (3.9 KiB/s) ## Executing script at 02000000 2861 bytes read in 74 ms (37.1 KiB/s) ## Executing script at 00000200 switch to partitions #0, OK mmc0 is current device 7317720 bytes read in 8278 ms (862.3 KiB/s) 53327828 bytes read in 71003 ms (733.4 KiB/s) 9312 bytes read in 143 ms (63.5 KiB/s) Kernel image @ 0x1000000 [ 0x000000 - 0x6fa8d8 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 53327764 Bytes = 50.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00000100 Booting using the fdt blob at 0x000100 Using Device Tree in place at 00000100, end 0000555f Starting kernel ... ---8<--- Also, it takes ages to even boot up to this point. Kernel/initrd too big? 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
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?
Same here. None of the available images work. The kernel seems to be a patched copy of some kernel devel project state. Any chance to rebase that on something current? Looks like the sources come from some git, but where?
The first thing you guys could do is provide some more substantial info of what you are actually testing. Build numbers are not really telling. On the Pi 1 the official openSUSE kernel-default 4.3.0 from Tumbleweed works just fine (not 4.4-rcX due to USB, as reported). I.e., you need to double-check which kernel package you have and which repository you are installing your kernel from if it looks like "a patched copy of some kernel devel project state" - it might be kernel-rpi from devel:ARM:Factory:Contrib:RaspberryPi or kernel-rpi2 from devel:ARM:Factory:Contrib:RaspberryPi2, which are not maintained by the kernel team. Ludwig's serial log is from the Pi 2. The Pi 2 is still not supported by the mainline Linux kernel and therefore not by the openSUSE kernel either. The kernel-rpi2 package is built from: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP... These Contrib packages have no magic cron jobs unlike the openSUSE kernels and thus need to be manually updated like any other package, via osc bco / sr, by whomever cares about them. I guess the kernel will be from somewhere at https://github.com/raspberrypi/linux/ - there's several branches including an rpi-4.4.y that you might want to try building and packaging. One of my Hackweek projects was to clean up Raspberry Pi images and move the Pi 1 closer to first-class Tumbleweed citizen. raspberrypi-firmware was accepted into Tumbleweed and JeOS-raspberrypi "moved" from devel:ARM:Factory:Contrib:RaspberryPi:upstream project to official openSUSE:Factory:ARM, i.e. the download locaction will change to: http://download.opensuse.org/ports/armv6hl/tumbleweed/images/ As mentioned multiple times already, armv6 image builds keep hanging. Any help debugging that is appreciated - it's been broken for weeks and months, so waiting and complaining is seriously not going to help! https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS-raspberryp... Depending on your host kernel, a local osc build on x86_64 may work. Also, you can always check the list archives - long before we got the now-broken JeOS image, I had posted a how-to for manually partitioning and bootstrapping an upstream-based rpi1 card based on the armv6 rootfs (which still seems building fine) that with some tweaks should still work. Only the lazy way of installing a new Raspberry Pi is broken. :) Just today my Hackweek submission of raspberrypi-firmware was accepted, adding a Config.txt template and moving the files from /boot to /boot/vc so that the FAT partition can be automatically updated by zypper in the future. https://build.opensuse.org/request/show/347964 The matching change to JeOS has just been submitted: https://build.opensuse.org/request/show/349929 The corresponding u-boot change I haven't accepted yet, to not interfere with Guillaume's -rc2 submission. https://build.opensuse.org/request/show/350127
Also, it takes ages to even boot up to this point. Kernel/initrd too big?
On first boot of Kiwi images, a huge initrd is loaded and it will resize partitions, which both can take some time. For ARMv6 we mainly enable the Raspberry Pi, for ARMv7 the number of SoCs and boards and thus of drivers is significantly higher. Regards, 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
Andreas Färber wrote:
Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
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?
Same here. None of the available images work. The kernel seems to be a patched copy of some kernel devel project state. Any chance to rebase that on something current? Looks like the sources come from some git, but where?
The first thing you guys could do is provide some more substantial info of what you are actually testing. Build numbers are not really telling.
The OP was referring to "Raspberry Pi 2B". That's what I tried. All three images (factory, devel, devel:staging) show the same behavior.
[...] Ludwig's serial log is from the Pi 2. The Pi 2 is still not supported by the mainline Linux kernel and therefore not by the openSUSE kernel either. The kernel-rpi2 package is built from:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP...
These Contrib packages have no magic cron jobs unlike the openSUSE kernels and thus need to be manually updated like any other package, via osc bco / sr, by whomever cares about them.
The kernel-source.changes looks like some script pulled patches from a git repo. Unfortunately the package gives no hint from which repo. It must be something based on the openSUSE kernel git repo I guess. So it's not as simple as branch and submit. If that was the case we'd see patch lines in the spec file.
I guess the kernel will be from somewhere at https://github.com/raspberrypi/linux/ - there's several branches including an rpi-4.4.y that you might want to try building and packaging.
Do we have some spec file template that shows how to build some "upstream" kernel in a way that is compatible with the official openSUSE kernel packaging? 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 21.12.15 10:45, Ludwig Nussel wrote:
Andreas Färber wrote:
Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
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?
Same here. None of the available images work. The kernel seems to be a patched copy of some kernel devel project state. Any chance to rebase that on something current? Looks like the sources come from some git, but where?
The first thing you guys could do is provide some more substantial info of what you are actually testing. Build numbers are not really telling.
The OP was referring to "Raspberry Pi 2B". That's what I tried. All three images (factory, devel, devel:staging) show the same behavior.
[...] Ludwig's serial log is from the Pi 2. The Pi 2 is still not supported by the mainline Linux kernel and therefore not by the openSUSE kernel either. The kernel-rpi2 package is built from:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryP...
These Contrib packages have no magic cron jobs unlike the openSUSE kernels and thus need to be manually updated like any other package, via osc bco / sr, by whomever cares about them.
The kernel-source.changes looks like some script pulled patches from a git repo. Unfortunately the package gives no hint from which repo. It must be something based on the openSUSE kernel git repo I guess. So it's not as simple as branch and submit. If that was the case we'd see patch lines in the spec file.
I guess the kernel will be from somewhere at https://github.com/raspberrypi/linux/ - there's several branches including an rpi-4.4.y that you might want to try building and packaging.
Do we have some spec file template that shows how to build some "upstream" kernel in a way that is compatible with the official openSUSE kernel packaging?
The easiest is to use my awesome "Contrib Kernel" script. Just point it at a downstream tarball plus .config and it creates all the kernel-source and kernel-foo packages in OBS for you: http://users.suse.com/~dmueller/contrib_kernel.sh Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Alex, Am 21.12.2015 um 11:18 schrieb Alexander Graf:
On 21.12.15 10:45, Ludwig Nussel wrote:
Do we have some spec file template that shows how to build some "upstream" kernel in a way that is compatible with the official openSUSE kernel packaging?
The easiest is to use my awesome "Contrib Kernel" script. Just point it at a downstream tarball plus .config and it creates all the kernel-source and kernel-foo packages in OBS for you:
During your absence someone had reported your awesome script were not working any more - have you tested or fixed it lately? 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
On 21.12.15 16:34, Andreas Färber wrote:
Alex,
Am 21.12.2015 um 11:18 schrieb Alexander Graf:
On 21.12.15 10:45, Ludwig Nussel wrote:
Do we have some spec file template that shows how to build some "upstream" kernel in a way that is compatible with the official openSUSE kernel packaging?
The easiest is to use my awesome "Contrib Kernel" script. Just point it at a downstream tarball plus .config and it creates all the kernel-source and kernel-foo packages in OBS for you:
During your absence someone had reported your awesome script were not working any more - have you tested or fixed it lately?
I've used it for the Tegra TX1 kernel and it worked for me: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Tegra/kern... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
I can tell you my biggest source of frustration is there is very
little if any correct information/documentation posted anywhere about
opensuse-arm on Raspberry Pi2. I have been trying to get myself more
oriented but I can barely even get the image to boot I have to use an
older version just to even get a log in prompt. If people are
frustrated this probably why, I have spent weeks trying to even get
basic functionality with little luck. I did just acquire a second pi2
for dev stuff but my time is very limited in terms of being able to
fix stuff, plus I am very new to Arm and Raspberry Pi2 I have a lot to
learn! Thanks everyone I know working on opensource volunteer efforts
can be thankless and sometimes frustrating work, I really do
appreciate the help I have received so far!
On Mon, Dec 21, 2015 at 10:43 AM, Alexander Graf
On 21.12.15 16:34, Andreas Färber wrote:
Alex,
Am 21.12.2015 um 11:18 schrieb Alexander Graf:
On 21.12.15 10:45, Ludwig Nussel wrote:
Do we have some spec file template that shows how to build some "upstream" kernel in a way that is compatible with the official openSUSE kernel packaging?
The easiest is to use my awesome "Contrib Kernel" script. Just point it at a downstream tarball plus .config and it creates all the kernel-source and kernel-foo packages in OBS for you:
During your absence someone had reported your awesome script were not working any more - have you tested or fixed it lately?
I've used it for the Tegra TX1 kernel and it worked for me:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Tegra/kern...
Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- Michael Emory Cerquoni -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 21.12.2015 um 10:45 schrieb Ludwig Nussel:
Andreas Färber wrote:
Am 20.12.2015 um 15:50 schrieb Ludwig Nussel:
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?
Same here. None of the available images work. The kernel seems to be a patched copy of some kernel devel project state. Any chance to rebase that on something current? Looks like the sources come from some git, but where?
The first thing you guys could do is provide some more substantial info of what you are actually testing. Build numbers are not really telling.
The OP was referring to "Raspberry Pi 2B". That's what I tried. All three images (factory, devel, devel:staging) show the same behavior.
Yes, but it was diluted by talking about "any of the Raspberry Pi systems" - Raspberry Pi and Raspberry Pi 2 are very different, not just ARMv6 vs. ARMv7 but also the kernel situation, as I outlined. I mainly meant, tell us the download location (project) where you got the image from. There's :upstream vs. :RaspberryPi1 vs. the new official one and :RaspberryPi2 vs. :Staging that I thought Dirk said was obsoleted... You'd be surprised that some people still complain about ancient images from Bernhard they saw in some old blog post that were never officially built in OBS by any of us! ;) 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
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
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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Alexander Graf wrote:
On 21.12.15 11:03, Ludwig Nussel wrote:
Andreas Färber wrote:
[...] => 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.
So x86_64 with emulation? Can you provide me with a qemu command line to boot an image?
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.
Aren't there some hardware tinkerers on your floor? :-) 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 21.12.15 11:45, Ludwig Nussel wrote:
Alexander Graf wrote:
On 21.12.15 11:03, Ludwig Nussel wrote:
Andreas Färber wrote:
[...] => 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.
So x86_64 with emulation? Can you provide me with a qemu command line to boot an image?
I haven't used the cubietruck on myself either yet :).
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.
Aren't there some hardware tinkerers on your floor? :-)
Yes, I guess I can ask them next year ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 21.12.2015 um 12:08 schrieb Alexander Graf:
On 21.12.15 11:45, Ludwig Nussel wrote:
Alexander Graf wrote:
On 21.12.15 11:03, Ludwig Nussel wrote:
Andreas Färber wrote:
[...] => Find ways to use openQA for more testing, e.g. serial only rather than graphical testing with QEMU machines such as cubieboard.
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.
So x86_64 with emulation? Can you provide me with a qemu command line to boot an image?
I haven't used the cubietruck on myself either yet :).
Note it's the A10 based Cubieboard (sun4i?); Cubietruck is A20 (sun7i). I'm guessing it would be 'qemu-system-arm -machine cubieboard -kernel ... -initrd ... -append "..." ...' (i.e., don't expect full U-Boot). Not sure what storage options are available for which of the lesser known emulations for accessing the rootfs. qemu-system-arm -M \? gives a list of available machine options - not all supported by openSUSE (ARM9 etc.) but highbank, midway, smdkc210, vexpress-a9, vexpress-a15, xilinx-zynq-a9 are some of the other possibly interesting emulations available on Leap. dracut -N might help create an ad-hoc initrd that works for all such boards without needing to build a full JeOS image for each. 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
Op maandag 21 december 2015 04:27:40 schreef Andreas Färber:
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!
Dear Andreas, Maybe I can find such a device, but I have no idea how to connect it to my system to get some characters on a screen. I restrict myself to getting all the images for the Raspberry Pi 1B and 2B from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/ Should I use another source for the images. After putting an image on the (micro-)SD card I test the image with a connected HDMI screen and an Ethernet cable, so I can watch how the system boots. When I report a black screen, this means I do not seen ANY information on the HDMI screen. It does not boot means I do not see the Ethernet connection coming up. Furthermore I can change files on the SD card in case this is relatively simple. Putting a new kernel on it is beyond my capabilities. I do realize I am part of the team, but I have limited capabilities. Reporting about what works and not is about all I can do. After that I hope I am quite willing to regularly follow a cookbook type of procedure and report about the results. I once did something quite simple in OBS. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Freek de Kruijf wrote:
Op maandag 21 december 2015 04:27:40 schreef Andreas Färber:
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! Dear Andreas,
Maybe I can find such a device, but I have no idea how to connect it to my system to get some characters on a screen. I am using the TTL - USB cable from Adafruit (https://www.adafruit.com/products/954) and they have a tutorial on how to use it (which helped me) here - https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-c....
I restrict myself to getting all the images for the Raspberry Pi 1B and 2B from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
Should I use another source for the images. This is a question I've had in the past too. The wiki for RPi 1 only
Basically, connect the the data lines (white and green on mine) to pins 14 (TX) & 15 (RX) respectively (For RPi 1), and plug into a free USB port. Then open a terminal and use the command 'screen /dev/ttyUSB0 115200' (your USB number might be different) to start monitoring. Finally, power up your Pi in the normal manner. You should see the boot process scroll across the terminal. lists repos for 13.1 & 13.2, nothing about latests builds. The RPi 2 wiki talks about Tumbleweed, but not the others. Andreas posted the link for Tumbleweed earlier, saying it was becoming a more first-class citizen. If someone points to the other definitive repos for the RPi, I'll update the wiki. Best, - A -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Alex Armstrong -
Alexander Graf -
Andreas Färber -
Freek de Kruijf -
Ludwig Nussel -
Michael Emory Cerquoni