May 2016 - openSUSE ARM - openSUSE Mailing Lists

[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] Tumbleweed Raspberry Pi2 i2c-tools not work
by Денислав Радославов 17 Jun '16

17 Jun '16

After two months (first report for this bug -forum and mailing list), bcm2835 modules working fine, but i2c-tools again not working. Missing packages python-smbus is big problem. Have ready packages, Is it so hard to be ported to Tumbleweed arm? After command sudo i2cdetect -y 1 , result is - Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory . -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

[opensuse-arm] kdump on arm
by Matwey V. Kornilov 13 Jun '16

13 Jun '16

Hello, Is kdump supposed to work on armv7l? Which kernel should I use as kdump kernel? kdumptool doesn't like -default for me: # kdumptool find_kernel Kernel '/boot/vmlinux-4.6.0-1.gd9e67cc-default' is not suitable for kdump. Please change KDUMP_KERNELVER in /etc/sysconfig/kdump. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] Unknown symbols using kernel 4.6
by Oscar C 12 Jun '16

12 Jun '16

Hi, I'm trying to boot a udoo quad board (imx6, similar to cubox-i). It boots and I can login but one of the usb ports work. Looking at the dmesg output I see that there are unknown symbol errors when the usb modules are being loaded: [ 12.905677] libphy: fec_enet_mii_bus: probed [ 12.910917] fec 2188000.ethernet eth0: registered PHC device 0 [ 12.979507] usbcore: registered new interface driver usbfs [ 12.985146] usbcore: registered new interface driver hub [ 12.990659] usbcore: registered new device driver usb [ 13.175153] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 13.407405] usb_otg_fsm: module license 'unspecified' taints kernel. [ 13.413995] Disabling lock debugging due to kernel taint [ 13.420407] usb_otg_fsm: Unknown symbol usb_bus_start_enum (err 0) [ 13.426990] usb_otg_fsm: Unknown symbol usb_control_msg (err 0) [ 13.433189] usb_otg_fsm: Unknown symbol usb_hub_find_child (err 0) [ 13.463782] usb_otg_fsm: Unknown symbol usb_bus_start_enum (err 0) [ 13.471592] usb_otg_fsm: Unknown symbol usb_control_msg (err 0) [ 13.478116] usb_otg_fsm: Unknown symbol usb_hub_find_child (err 0) [ 13.531556] fsl-asrc 2034000.asrc: driver registered [ 13.544423] fsl-asoc-card sound: ASoC: CPU DAI (null) not registered [ 13.544764] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW [ 13.558141] fsl-asoc-card sound: snd_soc_register_card failed (-517) [ 13.566862] fsl-asoc-card sound: ASoC: CODEC DAI ac97-hifi not registered [ 13.568653] Adding 505292k swap on /dev/mmcblk0p3. Priority:-1 extents:1 across:505292k SSFS Since the 4.6 kernel is not yet on factory (when will it land?), I'm using the version from the kernel:stable repo. What can I do to fix it? Thanks! -- Cheers -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 4

[opensuse-arm] Leap 42.2 ARM: Ring 0 status
by Matwey V. Kornilov 06 Jun '16

06 Jun '16

Hello, Leap 42.2 Ring0 rebuilt for ARM is here: https://build.opensuse.org/project/monitor/home:matwey:experimental:Leap:42… The following changes have to be introduced: build: 1) apply https://github.com/openSUSE/obs-build/commit/2caf24a52292b0e23725d1821d48c4… to fix build on armv7 (this is common issue also for Factory) gcc5: 1) drop _constraints, they are never satisfied at armv7 libunwind: 1) apply c90a2e02b3c1b03362a549a05261a4d0513d6026 from upstream 2) apply 0bed10aa217157b287e036fba1e48ad2c6a3356e from upstream (fixed package is probably already in SLE queue) post-build-checks: 1) apply https://github.com/openSUSE/post-build-checks/commit/c6e35c3b68457630fa7379… What should I do with this changes? Should I submit them directly to Leap:42.2? Leap 42.2 Ring1 is being built here: https://build.opensuse.org/project/monitor/home:matwey:experimental:Leap:42… You are welcome to reuse my work or participate into fixing `failed' packages in Ring1. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 13

[opensuse-arm] Raspberry pi 3 non-free firmware
by Bo Simonsen 03 Jun '16

03 Jun '16

Hi! I just got a raspberry pi 3 and got Tumbleweed running, runs very good, and very easy to install (after I found the right image). However there were no wifi, I had to manually pick it from here: https://github.com/RPi-Distro/firmware-nonfree/ The files: brcmfmac43430-sdio.txt and brcmfmac43430-sdio.bin My question is, is there any RPM source where these drivers are available? Bo -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 6

[opensuse-arm] Trying to use GPIO using /sys/class/gpio/
by Freek de Kruijf 27 May '16

27 May '16

I tried to use "echo '23' > /sys/class/gpio/export" as root on a Raspberry Pi 1B, but I get an error message. Tried other values as 23 also, but I continue to get the error message. Any hints? -- 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

2 4

[opensuse-arm] cubox-i tumbleweed image broken
by Thomas Bechtold 15 May '16

15 May '16

Hi, I tried again the Cubox-i Tumbleweed image (openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2016.05.05-Build1.4.raw.xz ) but it's broken again. This time, I get: => run bootcmd switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2750 bytes read in 34 ms (78.1 KiB/s) ## Executing script at 12000000 switch to partitions #0, OK mmc0 is current device 7420680 bytes read in 519 ms (13.6 MiB/s) 79608549 bytes read in 4776 ms (15.9 MiB/s) 38156 bytes read in 306 ms (121.1 KiB/s) Kernel image @ 0x10800100 [ 0x000000 - 0x713b08 ] ## Loading init Ramdisk from Legacy Image at 14800100 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 79608485 Bytes = 75.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 14700100 Booting using the fdt blob at 0x14700100 Using Device Tree in place at 14700100, end 1470c60b Starting kernel ... [ 0.225135] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 6.376159] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 [ 6.383309] sr_init: platform driver register failed for SR [ 6.403448] Unable to find PPMU node setterm: cannot (un)set powersave mode: Inappropriate ioctl for device [ 11.269077] systemd-udevd[247]: could not dup netlink fd: File exists [ 11.275601] systemd-udevd[247]: could not listen on fds: File exists [ 169.866174] reboot: Restarting system Any hints how to fix it? Best, Tom -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 5

[opensuse-arm] Raspberry Pi 1
by Duncan Mac-Vicar P. 12 May '16

12 May '16

After my Rpi3 booted I moved on to the Rpi1 This is my boot log: https://gist.github.com/dmacvicar/de59bc59af24c027ba03f623cdccf4ef It looks like boot.scr is not passing init= correctly to the kernel. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1