openSUSE ARM August 2016

arm@lists.opensuse.org

9 participants
7 discussions

[opensuse-arm] Attempt to run KIWI on unsupported architecture 'armv8l'
by Dirk Müller 12 Apr '17

12 Apr '17

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

3 3

[opensuse-arm] Turris Omnia (prototype) enablement report
by Andreas Färber 06 Nov '16

06 Nov '16

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

2 2

[opensuse-arm] ffmpeg build errors
by Oscar C 29 Aug '16

29 Aug '16

Hi, I see that ffmpeg is failing for all arm versions (although for different reasons): arm6 and arm7: [ 6141s] libavcodec/libavcodec.so: undefined reference to `ff_avg_vc1_chroma_mc4_neon' [ 6141s] libavcodec/libavcodec.so: undefined reference to `ff_avg_vc1_chroma_mc8_neon' [ 6141s] libavcodec/libavcodec.so: undefined reference to `ff_put_vc1_chroma_mc8_neon' [ 6141s] libavcodec/libavcodec.so: undefined reference to `ff_put_vc1_chroma_mc4_neon' arm64: [ 875s] libavcodec/libavcodec.so: undefined reference to `ff_vc1dsp_init_aarch64' I tried to build it locally on my arm7 board but I got the same errors. Does anyone know how to fix that errors? Thanks! -- Cheers -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 4

[opensuse-arm] Panda
by Andreas Schwab 10 Aug '16

10 Aug '16

I tried the latest panda image (openSUSE-Tumbleweed-ARM-JeOS-panda.armv7l-2016.07.22-Build1.9.raw.xz), but all I get is this: Loading linux.vmx... Loading initrd.vmx... data abort pc : [<bdeba824>] lr : [<bdebd010>] reloc pc : [<7e751824>] lr : [<7e754010>] sp : bef47f50 ip : 00000074 fp : 0000000a r10: bdeed6b4 r9 : 0000011d r8 : 0000011d r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : bdebbe30 r3 : 00000000 r2 : 00000000 r1 : 00005440 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

[opensuse-arm] hanging armv7l builds?
by Michael Ströder 09 Aug '16

09 Aug '16

HI! armv7l builds on OBS seem to be scheduled but never get executed. During the last days OBS was quite busy but currently the number of active build workers is below 200. For example: https://build.opensuse.org/package/show/devel:languages:python/python-ldap Ciao, Michael.

6 14

[opensuse-arm] Request For Comment: new GRUB_DEVICETREE_FILE option for grub2
by LOIC DEVULDER 08 Aug '16

08 Aug '16

Hello all! I'm testing openSUSE (and SLES) on ARM64 servers and I ran into an issue with the default DT integrated into the UEFI of my server (this problem is investigated by Matthias Brugger). To workaround my problem, I had to load a custom DT using the 'devicetree' option of grub2. But the main problem is that I didn't find a way to add it properly in the grub.cfg file without hacking the file (which is very bad)! So, I've made a small patch to add a new option called GRUB_DEVICETREE_FILE in /etc/default/grub file. I also compiled a new grub2 version with this patch and tested it successfully on my servers (https://build.opensuse.org/package/show/home:ldevulde:branches:Base:System/…). I opened a bug/fate on the official grub bugtracker (https://savannah.gnu.org/bugs/?48358) but it seems to have low activity... I plan to submit my change to the official openSUSE grub2 version but it could interesting to have some feedback before :-) PS: I know that a 'dtb' option exists in the kernel for loading a custom DT from efi but I wasn't able to make it work. And I think it's easier and more cleaner to use the grub2 option. Regards, Loic

2 3

[opensuse-arm] 4.7-rc6 status
by Andreas Färber 01 Aug '16

01 Aug '16

Hello, With help from Matwey we finally have armv7hl kernels in Kernel:HEAD again. Here are some mixed test results of 4.7.0-rc6-4.g3146576: Jetson TK1: * lpae works but only with Tumbleweed kernel-firmware, oops otherwise * 4.6.2-1-lpae boots okay with dtb-tegra124 4.7.rc6 Cubietruck: * lpae broken, no output * 4.6.2-1-lpae boots with dtb-sun7i 4.7.rc6 * Only boot.scr works, no output with GRUB (u-boot-cubietruck 2016.05) Raspberry Pi 2: * default and lpae broken, no output * 4.6.2-1-default boots with dtb-bcm2836 4.7.rc6 (-lpae known broken) Raspberry Pi: * default boots fine, except for some deadbeef vc4 error * 4.6.2-1-default boots with dtb-bcm2835 4.7.rc6 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(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 8

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM August 2016