openSUSE ARM March 2016

arm@lists.opensuse.org

26 participants
33 discussions

[opensuse-arm] Attempt to run KIWI on unsupported architecture 'armv8l'

by Dirk Müller

Hi, this is a known OBS bug, asked the admins to deploy a fix shortly. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 years, 3 months

[opensuse-arm] Turris Omnia (prototype) enablement report

by Andreas Färber

Hello, This weekend I've had the opportunity to test openSUSE on a prototype of CZ.NIC's Indiegogo-funded Turris Omnia router [1]. In a FOSDEM 2016 talk a prototype had already been shown to the public, whereas this was the first time we could peek at the current software environment of a running prototype ourselves and provide some early third-party distro feedback to its creators. Known for being overly critical and aiming at perfect solutions, let me say in advance that the Armada 385 mainline kernel support looks quite good already, needing only the Turris Omnia Device Tree [2] apparently. Turris Omnia's U-Boot [3] is quite usable but will need a little more love before we can benefit from new features such as UEFI boot support (both upstream where it's not yet using the distro defaults [4] and downstream for deriving a clean new turris_omnia_defconfig). I'm confident that most of the functional limitations I observed can be fixed until the final board version ships to backers. That said, here's a quick how-to I would've added to the Wiki [1] if it let me... == Manual installation == As of 2016-03-18, the prototype's U-Boot does not yet support XHCI, so that the two USB ports cannot be used for booting. That leaves eMMC and mSATA as local boot options. === Building an upstream kernel === Use mvebu_v7_defconfig and enable CONFIG_BTRFS_FS. === Installation to USB === As of 2016-03-18, the prototype's U-Boot does not yet support XHCI and therefore does not recognize any USB devices on either of the two USB ports. Still you can place your rootfs onto USB. As of 2016-03-18, the prototype's kernel has USB drivers built as modules and no initrd, so you cannot directly boot a USB rootfs with it. An easy solution is to build an upstream kernel yourself with those drivers built-in and to copy it to the eMMC's /boot directory (e.g., zImage-next). Note: In linux-next.git next-20160318 kernel only USB 3.0 devices work. Partition your USB disk with GPT or MBR. Create a partition for the rootfs and extract an [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-Current.tbz] tarball. Then boot similar to this (derived from bootargs and mmcboot variables): setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext4 rootwait rw' btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 Note: As always, "/dev/sda1" is unsafe as it may become, e.g., /dev/sdb1 when an mSATA SSD or a second USB storage device is connected. You could save those commands in a U-Boot environment variable, otherwise you will need to re-type them on each boot. === Installation to mSATA === Unless you have another device with mSATA port, you may find it difficult to set up the SSD. As of 2016-03-18, the prototype's OpenWrt kernel did not recognize a Samsung SSD 850 EVO 120 GB mSATA card (while U-Boot's scsi scan does). As workaround you can compile an upstream kernel (cf. [[#Building_an_upstrea_kernel|above]]), copy it under a new name to /boot on the eMMC (e.g., zImage-next) and boot OpenWrt with this new kernel (derived from mmcboot variable): btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 Now that you have a /dev/sda device for the mSATA SSD, you may find that OpenWrt does not come with parted, fdisk or gdisk tools for partitioning this device. One solution is to boot into openSUSE Tumbleweed, where you can easily install those tools, from USB (cf. [[#Installation_to_USB|above]]): setenv bootargs 'console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext4 rootwait rw' btrload mmc 0 0x01000000 boot/zImage-next @ btrload mmc 0 0x02000000 boot/dtb @ bootz 0x01000000 - 0x02000000 >From inside openSUSE verify that /dev/sda is your mSATA card and partition it using gdisk (zypper in gptfdisk). Format your new partition and extract a JeOS rootfs tarball. For now just copy zImage-next and dtb over. mount /dev/sda1 /mnt tar xvjf [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt cp /boot/zImage-next /mnt/boot/zImage-next cp /boot/dtb /mnt/boot/armada-385-turris-omnia.dtb ln -sf zImage-next /mnt/boot/zImage ln -sf armada-385-turris-omnia.dtb /mnt/boot/dtb Boot similar to this: setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw' setenv fdtfile armada-385-turris-omnia.dtb scsi scan btrload scsi 0:1 0x01000000 boot/zImage-next btrload scsi 0:1 0x02000000 boot/dtb/$fdtfile bootz 0x01000000 - 0x02000000 It's beginning to look much more like openSUSE, just lacking an openSUSE kernel still. === Installation to eMMC === In theory you can also replace OpenWrt with openSUSE, optionally backing it up as btrfs snapshot. To do so you'll need to boot from some other root device such as USB or mSATA. mount /dev/mmcblk0p1 /mnt btrfs subvolume snapshot /mnt/@ /mnt/root-pre-opensuse rm -rf /mnt/@/* tar xvjf [http://download.opensuse.org/ports/armv7hl/tumbleweed/images/openSUSE-Tumbl… openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz] -C /mnt/@ cp /boot/zImage-next /mnt/@/boot/zImage-next cp /boot/dtb /mnt/(a)/boot/armada-385-turris-omnia.dtb ln -sf zImage-next /mnt/@/boot/zImage ln -sf armada-385-turris-omnia.dtb /mnt/@/boot/dtb Then on next boot you should boot into openSUSE automatically. === openSUSE kernel === Unlike mvebu_v7_defconfig, the openSUSE kernels build drivers as modules whenever possible. To boot you will need additional driver modules in a ramdisk. There's two easy ways to create such an initrd file. Either use Kiwi (as done for our JeOS SD card images) or boot into the system once without modules and have the initrd be created by dracut. If you zypper up or zypper dup the system for the first time, chances are a new kernel-default package gets installed and generates an initrd; you can force this the easy way by reinstalling the package (zypper in -f kernel-default) or figure out the lengthy dracut command line. Try to boot it like this: setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw' scsi scan btrload scsi 0:1 0x01000000 boot/zImage btrload scsi 0:1 0x02000000 boot/dtb/armada-385-turris-omnia.dtb btrload scsi 0:1 0x03000000 boot/initrd bootz 0x01000000 0x03000000:$filesize 0x02000000 This resulted in: Kernel image @ 0x1000000 [ 0x000000 - 0x6f2d78 ] Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid ''To be investigated - U-Boot lacking CONFIG_SUPPORT_RAW_INITRD?'' This is blocking creation of a JeOS disk image. Cheers, Andreas [1] https://en.opensuse.org/HCL:Turris_Omnia [2] https://gitlab.labs.nic.cz/turris/openwrt/tree/test/target/linux/mvebu/file… [3] https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/commits/omnia [4] http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/db-88f6820-gp.h;h… -- 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(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 years, 8 months

[opensuse-arm] raspberrypi image 2016.03.24-Build2.1 almost working

by Herbert Graeber

Hi! I have tried the latest Raspberyy pi image and found out it does not run on second boot (again). The image is: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2016.03.24-Build2.1.raw.xz On second boot on serial console the following message is shown: [ 9.176607] EXT4-fs (mmcblk0p3): Unrecognized mount option "size=100%" or missing value This leads to the following solution: - After first boot, "cd /boot" and edit the file "boot.script". - There remove the entry "rootflags=size=100%" - Then run "mkimage -A arm -O linux -T script -C none -a 0 -e 0 -d boot.script boot.scr" I have done a "dracut -H -f", too but I think that's not necessary. Herbert

5 years, 3 months

[opensuse-arm] A couple of u-boot links

by Bill Merriam

I recently ran across an explanation, which I think is now somewhat dated, on how booting works on Raspberry Pi. I thought others might find it interesting. http://dius.com.au/2015/08/19/raspberry-pi-uboot/ I think there are efforts underway to get opensuse running on the new pine64 boards. I found the source for their u-boot. We will certainly need that. https://github.com/longsleep/u-boot-pine64 Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

[opensuse-arm] failing openQA for aarch64

by Dirk Müller

Hi, https://openqa.opensuse.org/group_overview/3 in case anyone has time to look into it. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

[opensuse-arm] Is there any good way to specify frame buffer size options to Raspi2 kernel?

by Fuminobu TAKEYAMA

Hi, Is there any good way to specify framebuffer options to Raspberry Pi 2 kernel? To set the size of frame buffer, we need to specify the size options by kernel cmdline. (Otherwise the resolution of framebuffer will be 800x480) - bcm2708_fb.fbwidth - bcm2708_fb.fbheight - bcm2708_fb.fbdepth - bcm2708_fb.fbswap I now specify those options by modifying boot.script. It seems that on Rasbian, u-boot passes the size options to kernel according to "display_mode". However, on openSUSE, it does not. Is it possible passing those options in the same way as Rasbian? Or any better way to add some options to kernel cmdline? Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

[opensuse-arm] RPi2, Tumbleweed and "official" 7" RPi touchscreen

by Robert Kaiser

Hi, I've had one RPi2 running headless with Tumbleweed for quite some time now, and it does fine, so thanks everyone for making that work! That said, I now have acquired the "official" RPi 7" touchscreen to use with a second RPi2, and it actually displays the text console nicely on first boot of the Build 385 JeOS image, but on second boot it stays completely black (not even the backlight is on). In addition, the network interface also does not come up (same as on first boot), so the build gets completely unusable for me. I tried the old build 307 that I had used initially to get the other RPi2 up months ago, and the screen is completely black with that, but the network is fine and I could update it to a current Tumbleweed, which it still boots fine and is accessible from the network. That said, the screen stays dark on this as well. Given that the first boot with build 385 works and AFAIK uses the same kernel and probably bootloader, and the difference is there right from booting the system, it feels like it can't be that hard to get it working in the end. That said, the difference has to be in some parameters or things available during boot. I attached two dmesg outputs, one ("noscreen") from the updated-to-current system that can be accessed remotely, one ("screenworking") from a build 385 first boot. One difference that strikes me there is that the non-working version says (omitting times): simple-framebuffer 3db79000.framebuffer: framebuffer at 0x3db79000, 0x81800 bytes, mapped to 0xb7d00000 simple-framebuffer 3db79000.framebuffer: format=r5g6b5, mode=592x448x16, linelength=1184 simple-framebuffer 3db79000.framebuffer: fb1: simplefb registered! The working version has the following instead: simple-framebuffer fdb3f000.framebuffer: framebuffer at 0xfdb3f000, 0xbb800 bytes, mapped to 0xb7d00000 simple-framebuffer fdb3f000.framebuffer: format=r5g6b5, mode=800x480x16, linelength=1600 simple-framebuffer fdb3f000.framebuffer: fb1: simplefb registered! The "mode=800x480x16" actually fits this screen correctly. Any idea what I can try to get it working? I have found out enough to play with kernel command line parameters by editing boot.script and regenerating boot.scr from it, but I got stuck there as removing this from the commandline didn't help and I'm not sure what else I can do there that may help. That said, once the display actually shows stuff, the second question will be the touch input - if the rpi-ft5406 driver available in the kernel right now? I saw there are sources for it in https://github.com/raspberrypi/linux/blob/rpi-4.5.y/drivers/input/touchscre… at least for 4.5, not sure for how far back they exist/work. Thanks, KaiRo

5 years, 4 months

[opensuse-arm] Support for Wi-Fi and bluetooth on Raspberry Pi 3

by Freek de Kruijf

After installation of the openSUSE Tumbleweed image for the Raspberry Pi 3 I do not see the Wi-Fi and the Bluetooth devices with the command lsusb. I found the firmware needs to be updated. Is anybody working on that? I am also trying to find out what psi-update is doing, but mentioned was it is for kernel 5.0. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

[opensuse-arm] New RPI2 image

by Michael Emory Cerquoni

I just tested the openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2.armv7l-2016.03.24-Build3.1.raw image and it seems to work so far, booted up and survives a reboot without any hacky fixes, good stuff! Also not sure if you all saw this but looks cool > https://www.suse.com/company/press/2016/64-bit-arm-gets-a-boost-on-opensuse… I look forward to perhaps a faster development path in the future! -- Michael Emory Cerquoni -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

Re: [opensuse-arm] Leap 42.2 plans?

by Michal Hrusecky

Ludwig Nussel - 14:16 9.03.16 wrote: > Hi, > > Are there any plans to build the next Leap (42.2) also on ARM > architectures? It would be nice to try this time to get even armv7 version as most of the boards out there are armv7. I'm willing to dedicate it some time, but it would be definitely for ports. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM March 2016