October 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] ARM auto tests
by Guillaume Gardet 21 Nov '16

21 Nov '16

Hi ARM guys! I think current openQA AArch64 tests are done using qemu (at least virtualization). But, how far is ARM tests on real hardware? It seems os-autoinst support real hardware and I remember that some people worked on it during hackweeks. I would like to collect all information in order to maybe work on it a bit. For example, which devices do you use to power on/off boards. Did you use os-autoinst or some other tests tools? Guillaume -- 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] 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] openSUSE Leap 42.2 on BeagleBone Black
by Matwey V. Kornilov 04 Nov '16

04 Nov '16

Hello, I've just booted Leap 42.2 on BBB: http://download.opensuse.org/repositories/home:/matwey:/experimental:/Leap:… Join the party! -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 8

[opensuse-arm] ANN: Raspberry Pi 2 Tumbleweed image
by Andreas Färber 31 Oct '16

31 Oct '16

Hello, Last weekend already the 4.8 kernel landed in Factory. Since then we have a usable JeOS-raspberrypi2 image in openSUSE:Factory:ARM. https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS-raspberry… These images have not been published yet, so you will need to download them from OBS (build.opensuse.org) rather than download.opensuse.org. For that reason the Wiki couldn't be updated with new instructions yet. https://en.opensuse.org/HCL:Raspberry_Pi2 Known issues: * The GRUB menu is only shown on HDMI, not on serial. Workaround: Attach a monitor for the first boot, then edit /etc/default/grub replacing GRUB_TERMINAL="gfxterm" with GRUB_TERMINAL="console" and run `update-bootloader` (or `grub2-mkconfig -o /boot/grub2/grub.cfg`). * Downstream kernels booted through GRUB might get a random MAC address. Workaround: edit GRUB menu entry or create a boot.scr script. The old images in devel:ARM:Factory:Contrib:RaspberryPi2 and :Staging will stay around for now, but you are encouraged to use the official image for new installations and, if needed, install only kernel-rpi2 and dtb-bcm2709 packages from the Contrib projects. Therefore please report success or problems with the new raspberrypi2 image. Thanks. Have a lot of fun, Andreas P.S. The 4.8 arm64 kernel has been tested to work on the Raspberry Pi 3 but U-Boot is looking for the .dtb file in the wrong place, breaking automatic boot. Therefore no official image yet. Workaround: symlink or `load mmc 0:2 $fdt_addr_r boot/dtb/broadcom/$fdtfile; boot` -- 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] Raspberry Pi JeOS cleanups
by Andreas Färber 26 Oct '16

26 Oct '16

Hello, Here's a quick heads-up about some cleanups I've been doing for our Kiwi images. The relationships of the images have been slightly tweaked and there are two new experimental images. Rough overview over the new _link relations (E20, LXQT, XFCE left out): openSUSE:Factory:ARM/JeOS |`- openSUSE:Factory:ARM/JeOS-raspberrypi |`- home:a_faerber:branches:openSUSE:Factory:ARM/JeOS-raspberrypi2 (NEW) | (=> to be created in openSUSE:Factory:ARM - still without USB) |`- devel:ARM:Factory:Contrib:HEAD/JeOS (new) | |`- devel:ARM:Factory:Contrib:HEAD/JeOS-efi.aarch64 | | (previously a direct _link to openSUSE:Factory:ARM) | `- devel:ARM:Factory:Contrib:HEAD/JeOS-raspberrypi3 (NEW) |`- devel:ARM:Factory:Contrib:RaspberryPi/JeOS-raspberrypi |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi2 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi2 | (previously a direct _link to openSUSE:Factory:ARM, broken) |`- devel:ARM:Factory:Contrib:RaspberryPi2/JeOS-raspberrypi3 | `- devel:ARM:Factory:Contrib:RaspberryPi2:Staging/JeOS-raspberrypi3 | (previously a direct _link to openSUSE:Factory:ARM) `- devel:ARM:Factory:Contrib:RaspberryPi3/JeOS-raspberrypi3_aarch64 Main motivation was to facilitate testing of openSUSE kernel based Raspberry Pi 2 and 3 images (help needed with debugging: why no USB?!) and to simplify maintenance of derived Contrib images. While most of the .kiwi[.in] changes merge just fine, any .tgz updates require manual conflict resolution - the above scheme should require less such merges. Note: These changes are independent of the ext4 fixes on the U-Boot level that Stefan has been working on - no functional changes yet. 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

3 7

[opensuse-arm] bcm43xx-firmware not symlinked in RPi3 32 bits
by Guillaume Gardet 26 Oct '16

26 Oct '16

Hi, WiFi does not work out of the box on JeOS-raspberrypi3 armv7l image (downstream 32 bits) because: cat /sys/firmware/devicetree/base/compatible returns: brcm,bcm2710brcm,bcm2709 and not: *raspberrypi,3-model-b* But: cat /sys/firmware/devicetree/base/model returns: Raspberry Pi 3 Model B Could we add this case in bcm43xx-firmware script? Note that JeOS raspberry pi 3 (AArch64 contrib) has no WiFi, probably because of the following error: brcmfmac_sdio: probe of mmc1:0001:1 failed with error -110 brcmfmac_sdio: probe of mmc1:0001:2 failed with error -110 whereas mmc1 seems to be ok: [ 3.109301] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 3.111430] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.113282] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.120140] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 3.339697] random: nonblocking pool is initialized [ 3.357090] mmc1: new SDIO card at address 0001 Any idea why it happens? Guillaume -- 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] Factory:ARM dtb rebuild
by Guillaume Gardet 25 Oct '16

25 Oct '16

Hi, Could you trigger a rebuild of DTB packages in Factory:ARM, because dtb are still in 4.7.5 whereas kernel is at 4.8.*. Guillaume -- 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] BananaPi - usb out of function
by Stefan Mack 24 Oct '16

24 Oct '16

Hello all, usb is out of function on my bananapi with Tmbleweed. After boot up the USB power seems to be turned off. I found two links: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/395 232.html https://patchwork.kernel.org/patch/7927841/ "With a new kernel, the kernel will turn off the USB power supply during boot by default if the driver isn't present." Can anybody help me with the patch? Which file I have to patch? After this I have to compile the kernel? Am I the only one with Banana and Opensuse? Thanks a lot Stefan Sorry for my bad English, I'm still learning... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 8

[opensuse-arm] Raspberry Pi 3 AArch64 DTB
by Guillaume Gardet 18 Oct '16

18 Oct '16

Hi, On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently 2 DTB packages: * dtb-aarch64 : compiled broadcom DTBs from sources and output a bcm2837-rpi-3-b.dtb file too. * dtb-rpi3-aarch64 : pre-compiled bcm2837-rpi-3-b.dtb (from where?) Current JeOS uses the pre-compiled DT. WiFi is not working on AArch64 version, and I am wondering if it could be caused by the DTB used. Alex, Andreas, any idea? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

5 34

[opensuse-arm] All Raspberry Pi images EFI-enabled - call for testing
by Andreas Färber 18 Oct '16

18 Oct '16

Hi, Both the Tumbleweed raspberrypi image and the Contrib raspberrypi, raspberrypi2 and raspberrypi3 images now boot from U-Boot into GRUB. This feature was already enabled for the raspberrypi3_aarch64 image and until recently had been impacted by the ext4 64bit feature breakage. Now that we have a workaround and are preparing to enable raspberrypi2 in Tumbleweed, it was time to clean this up. I had already been successfully running manually GRUB2-converted installations for many weeks. Now Tumbleweed based raspberrypi and raspberrypi2 images were tested; for the Contrib projects I have faked the filenames U-Boot expects, based on upstream vs. downstream .dtb filenames and testing of rpi-2-b as well as $fdtfilename in u-boot-rpi332b v2016.09.01. As a side effect, the faked .dtb filenames also fix the model B+, which was using the model B's .dtb so far. Known issues: * Overwriting an SD card that had the old partitioning scheme with separate /boot partition leads to a GRUB rescue shell, i.e. unbootable system. Workaround: Either zero out the old GPT or the full SD card (took ~45 min for 32 GB...) before dd'ing the image. https://lists.opensuse.org/opensuse-arm/2016-10/msg00082.html Please report if any other boot issues remain with the updated images. Outlook: * With my bcm28*.dtb symlinks in place for the Contribs, we can drop the hardcoded $fdtfile bcm27*.dtb values in uboot-image-setup.in now (b-plus vs. b TODO comment). * We could also drop some non-$is_efi paths in uboot-image-install.in once we're confident we don't need to switch back in any branch. * Once Factory gets the 4.8 kernel (sr#435703), we can build official Tumbleweed images for Raspberry Pi 2 and 3. Have a lot of fun, 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

1 0

[opensuse-arm] RPi image - Need info how it's supposed to work
by Tony Su 17 Oct '16

17 Oct '16

Right now, When I insert the RPi 1 image into my RPi Zero, it just sits there... nothing happening. I'd ordinarily expect the LED light to be blinking furiously as the system boots up, so it's likely the image just isn't bootable. Have written the image 2 ways... Following the instructions as described on the following link using xzcat to decompress the JEOS .xz file, which is then piped to dd, writing to the sdcard. https://en.opensuse.org/HCL:Raspberry_Pi I also extracted the file, then used Win32DiskImager to write results to the sdcard blindly which still wouldn't work... When both failed, I took a look at what the uncompressed result was, and I see not a raw file system but executable binary files and the main image in ELF format. Is the flow for how these files are supposed to execute documented somewhere? Or, is the source for all this publicly visible(I've looked around, can't find in OBS, Studio, GitHub)? It's kind of hard to see where the problem might be when the code is in binary format... Thx, Tony . -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 10

[opensuse-arm] RPi zero unable to boot images
by Tony Su 17 Oct '16

17 Oct '16

Decided to take another look at trying to boot TW RPi 1 images on a RPi zero, hooked up to a monitor to see stdout. Have tried the following TW LXQT and JeOS images, the LXQT is the latest build and the JeOS is one release older. openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2016.09.27-Build1.8.raw.xz openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2016.06.12-Build2.10.raw.xz Both have same results. The boot process proceeds until unable to find a "config.txt" file. Knowing the file should actually have a capital "C" I renamed the file to "Config.txt" But with no different result. The following is a link to a photo image of stdout when boot stops, is the same for both images https://goo.gl/photos/uV2FyFdwv2SkQToT8 >From that boot prompt, I can type "help" but if there is a command that might continue while also referencing or injecting the Config.txt file, I don't know what that might be. I've waited over an hour each time in case the boot might just have taken longer than expected, but there's no difference. The display is the same (as the photo). Each time, when the boot has failed, I've inserted the card back in a big machine, and I can see that the boot process has at least created 3 partitions, EFI, boot and root. I didn't try to mount the card or partitions to inspect the contents of the partitions. Anything else to try? TIA, Tony -- 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] U-Boot v2016.11-rc1 in Staging
by Andreas Färber 16 Oct '16

16 Oct '16

Hello, With v2016.09.01 in Base:System and on its way to Factory, I have updated Base:System:Staging to v2016.11-rc1: https://build.opensuse.org/project/show/Base:System:Staging All patches rebased cleanly. All builds are green. rpi2 and rpi3 tested. It's still early in the release cycle, so I imagine any EFI/ext4/... bug fixes should still go to tumbleweed-2016.09 branch and Base:System. But anyone facing problems with v2016.09.01 can now easily test whether v2016.11-rc1 works any better. Have a lot of fun, 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

1 0

[opensuse-arm] JeOS-raspberrypi3_aarch64 fail to boot
by Matwey V. Kornilov 15 Oct '16

15 Oct '16

Hello, I am trying to boot from openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3_aarch64.aarch64-2016.10.15-Build1.1.raw from openSUSE:Factory:ARM I see the following: U-Boot 2016.07 (Sep 28 2016 - 15:18:17 +0000) DRAM: 880 MiB RPI 3 Model B (0xa22082) 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. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 729088 bytes read in 83 ms (8.4 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 0x01000000 ... WARNING: Invalid device tree, expect boot to fail Scanning disks on usb... Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 5 disks Welcome to GRUB! error: terminal `gfxterm' isn't found. EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: ERROR: could not determine UEFI Secure Boot status. EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... EFI stub: ERROR: Failed to update FDT and exit boot services and nothing else happens. -- 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] openSUSE on Nexbox z68 (GeekBox like TV box)
by LOIC DEVULDER 13 Oct '16

13 Oct '16

Hello all! I have a Nexbox z68 android TV box with a RK3368 processor that I want to play with. This box is like the GeekBox but cheaper (I bought mine for 30€). And, of course, also with less connectors, but it’s really cheap for a 2GB RAM / 16GB eMMC box. The hardware of the two box are pretty close, I’ve been able to boot the Ubuntu GeekBox version without any problem. One of missing function is the serial console by default (like a lot of TV box) but I’ve been able to use it with some minor work. If you want to try, give a look at my post on FreakTab (I tried to add the link but it seems that it's not allowed by the forum rules, my message was denied). Now, I want to try openSUSE on it. I saw that Andreas has a WIP on GeekBox (https://en.opensuse.org/HCL:GeekBox) and, as I understand, it’s possible to boot openSUSE with both the vendor U-Boot or the mainline U-Boot. For the moment, I want to stay with the vendor version because at this time I don’t known how to enter MaskRom mode (there is two test points near the eMMC chip, I just need to test it). Here my question (finally!): what openSUSE image do I use? And where to find the initrd? I found a kernel in the generic JeOS image but no initrd... Regards, Loic N��r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.�櫛�0��Ǩ�

3 8

[opensuse-arm] JeOS structure and _links
by Fabian Vogt 10 Oct '16

10 Oct '16

Hi, I'm currently working on getting the Pine64 upstream image updated to latest sources (firmware, u-boot, kernel and dtb) and the SRs are ready. However, due to the current structure of _links in the ARM projects on OBS merging will probably break some if not most of those, as told by afaerber. I propose generating the uboot-*.tgz files with the C preprocessor as well, just like Images.kiwi.in, so that changes in the uboot-image-install.in or uboot-image-setup.in files only affects the .tgzs for the relevant boards. That way changes in the parent JeOS package can be merged easily, even automatically in most cases. It would also result in more readable scripts (IMO) as the relationship between board and installation procedure is more obvious, compared to guessing which file relates to which boards. Suggestions, opinions? Cheers, Fabian -- 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 11

[opensuse-arm] No wlan on raspberry pi 3
by Jogchum Reitsma 08 Oct '16

08 Oct '16

I installed openSUSE-Tumbleweed-ARM-XFCE-raspberrypi3_aarch64.aarch64-2016.09.27-Build8.4.raw.xz in my PI 3, but got no wlan. Yast shows only eth0, as does 'ip a'. Having read the thread started by Freek de Kruijff on Mar 26 this year on this list, I found the files brcmfmac43430-sdio.bin and brcmfmac43430-sdio.txt where missing indeed in /lib/firmware/brcm/ So I downloaded them from https://github.com/RPi-Distro/firmware-nonfree/raw/master/brcm80211/brcm/ to /lib/firmware/brcm/ and rebooted, but still no wlan. What can I do to get wlan working? Jogchum Reitsma -- 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] pine64 tumbleweed image
by Paul Gonin 04 Oct '16

04 Oct '16

Hi ! I gave a try today to the pine64 non-upstream openSUSE Tumbleweed image [1] Writing the image to sdcard went fine and I was able to boot. I did not get to a prompt though. It stopped at Loading linux.vmx... Loading initrd.vmx... EFI stub: Booting Linux Kernel... EFI stub: UEFI Secure Boot is enabled. EFI stub: Generating empty DTB EFI stub: Exiting boot services and installing virtual address map... U-Boot EFI: Relocation at 00000000bffacff0 is out of range (1fffc1d0) U-Boot EFI: Relocation at 00000000bffad000 is out of range (1fffc1e8) U-Boot EFI: Relocation at 00000000bffad010 is out of range (1fffc1e8) U-Boot EFI: Relocation at 00000000bffad020 is out of range (1fffc058) Any advice what I can try next ? Anything I can do to help ? Thanks Paul [1] http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Pin… -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 7

[opensuse-arm] openSUSE Leap 42.2: RPI3 aarch64
by Matwey V. Kornilov 02 Oct '16

02 Oct '16

Hello, There is aarch64 port for Leap 42.2. But I can not find images for RPi3. It would be great to test. -- 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] Image for RPi3, using architecture aarch64 works
by Freek de Kruijf 02 Oct '16

02 Oct '16

Just tried the image for the Raspberry Pi 3 openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3_aarch64.aarch64-2016.09.27- Build6.1.raw.xz and I have a working system. The only problem I had was, when I had a USB storage device connected, the system did not continue in the boot process, or I was too inpatient. I disconnected that device and started the boot process again and now I have a working system. -- 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