openSUSE ARM September 2018

arm@lists.opensuse.org

10 participants
6 discussions

[opensuse-arm] cubox-i / leap 42.3: problems with automatic module loading after upgrade

by Miklos Vajna

Hi, Just asking if this is only me or it's a wider problem: I recently updated my cubox-i with zypper, pulling in kernel-default-4.4.114, and after reboot the box boots, but several drivers are missing, so there is no wired ethernet, no mmcblk, etc. After booting and waiting for a while, dmesg starts to complain about driver detection did not finish in time (sadly I don't have the backtrace at hand, it already went out of the buffer of the serial console). For now I worked around the problem this way: - download the repo-oss (ie. non-update) kernel-default-4.4.76 rpm on an other machine, copied it to an usb stick - install the old kernel-default from the usb stick - copy the /boot from the root fs to the usb stick - use the other machine to update the /boot on the mmcblk device where u-boot reads it So is this only me or do other cubox-i users see the same? Thanks, Miklos

2 years

[opensuse-arm] How to debug Grub config

by Matwey V. Kornilov

Hello, I am (stilL) trying to boot openSUSE on Rock64. I use JeOS image from Contrib:Rockchip and manually built bootloader (with 0001-XXX-openSUSE-XXX-Prepend-partition-.patch). And currently I see the following new issue: mmc1 is current device Scanning mmc 1:2... 52462 bytes read in 43 ms (1.2 MiB/s) Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Scanning mmc 1:1... Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 1247744 bytes read in 58 ms (20.5 MiB/s) ## Starting EFI application at 02000000 ... Card did not respond to voltage select! mmc_init: -95, time 10 Scanning disk rksdmmc(a)ff520000.blk... Scanning disk rksdmmc(a)ff500000.blk... Found 2 disks Welcome to GRUB! ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@ff540000 GNU GRUB version 2.02 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub> I see that both dtb file and EFI GRUB executable are loaded. But instead of GRUB menu I see GRUB command line. I suppose it means that grub failed to fetch GRUB configuration. How could I debug further what is wrong? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 years, 6 months

[opensuse-arm] Support for Banana Pi M64

by Freek de Kruijf

I experienced problems with the 1GB memory of the Raspberry Pi 3, so I went to a Banana Pi M64, which has almost the same specifications as the RPi3, except it has 2 GB memory, and it uses a slightly different CPU. I even found an image to run openSUSE Tumbleweed on it from a year ago. The image used the same repository as the repository for the RPi3 (aarch64). However upgrading to a newer version of Tumbleweed failed. As far as I could see the only issue is a slightly different kernel and boot system. Currently I am trying to implement my services on it using Debian Stretch. I would very much like to use openSUSE on it, because I am more familiar with it. Debian is quite different, both in managing packages as in configuration of the services. If I can be of assistance in implementing openSUSE on a Banana Pi M64 I am quite willing to do that. Don't know if I have the necessary knowledge. -- 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 years, 7 months

[opensuse-arm] Cubox-i Tumbleweed JeOS images broken

by Josua Mayer

Hi everybody, I just tried the two available JeOS images for cubox-i: openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2018.08.13-Snapshot20180905.raw.xz openSUSE-Tumbleweed-ARM-JeOS-cuboxi.armv7l-2018.08.13-Snapshot20180822.raw.xz Both fail at booth with Loading kernel... Loading initrd... [ 0.303128] Initramfs unpacking failed: junk in compressed archive [ 1.653868] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) So something seems wrong with that initrd. The microsd is not at fault: - tried 2 cards - tried leap 15.0 image on one of the cards: works br Josua Mayer Appendix: the kernel part of the log - skipped u-boot Loading kernel... Loading initrd... [ 0.303128] Initramfs unpacking failed: junk in compressed archive [ 1.653868] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 1.662151] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.13-1-default #1 openSUSE Tumbleweed (unreleased) [ 1.671896] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 1.678469] [<c0321000>] (unwind_backtrace) from [<c0319640>] (show_stack+0x20/0x28) [ 1.686231] [<c0319640>] (show_stack) from [<c0de3998>] (dump_stack+0xb8/0xe4) [ 1.693470] [<c0de3998>] (dump_stack) from [<c036c1a0>] (panic+0xf0/0x28c) [ 1.700366] [<c036c1a0>] (panic) from [<c15018ec>] (mount_block_root+0x26c/0x31c) [ 1.707862] [<c15018ec>] (mount_block_root) from [<c1501a30>] (mount_root+0x94/0x98) [ 1.715619] [<c1501a30>] (mount_root) from [<c1501b94>] (prepare_namespace+0x160/0x1a8) [ 1.723635] [<c1501b94>] (prepare_namespace) from [<c1501420>] (kernel_init_freeable+0x42c/0x440) [ 1.732523] [<c1501420>] (kernel_init_freeable) from [<c0df8a44>] (kernel_init+0x18/0x128) [ 1.740801] [<c0df8a44>] (kernel_init) from [<c03010ac>] (ret_from_fork+0x14/0x28) [ 1.748376] Exception stack(0xee947fb0 to 0xee947ff8) [ 1.753435] 7fa0: 00000000 00000000 00000000 00000000 [ 1.761619] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.769801] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 1.776435] CPU1: stopping [ 1.779157] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.17.13-1-default #1 openSUSE Tumbleweed (unreleased) [ 1.788902] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 1.795453] [<c0321000>] (unwind_backtrace) from [<c0319640>] (show_stack+0x20/0x28) [ 1.803211] [<c0319640>] (show_stack) from [<c0de3998>] (dump_stack+0xb8/0xe4) [ 1.810445] [<c0de3998>] (dump_stack) from [<c031d5ac>] (handle_IPI+0x338/0x360) [ 1.817856] [<c031d5ac>] (handle_IPI) from [<c0302c40>] (gic_handle_irq+0x98/0x9c) [ 1.825438] [<c0302c40>] (gic_handle_irq) from [<c030203c>] (__irq_svc+0x5c/0x94) [ 1.832925] Exception stack(0xee987eb8 to 0xee987f00) [ 1.837982] 7ea0: 00000000 00000000 [ 1.846168] 7ec0: 2e066000 20000093 00000000 00000001 c170df98 c170dfe8 00000001 ef6cec00 [ 1.854354] 7ee0: 69e21c10 ee987f54 ee987f08 ee987f08 c0c2af94 c0c2af98 20000013 ffffffff [ 1.862548] [<c030203c>] (__irq_svc) from [<c0c2af98>] (cpuidle_enter_state+0x428/0x480) [ 1.870651] [<c0c2af98>] (cpuidle_enter_state) from [<c0c2b060>] (cpuidle_enter+0x40/0x54) [ 1.878929] [<c0c2b060>] (cpuidle_enter) from [<c03a0740>] (call_cpuidle+0x30/0x50) [ 1.886598] [<c03a0740>] (call_cpuidle) from [<c03a0be4>] (do_idle+0x234/0x290) [ 1.893919] [<c03a0be4>] (do_idle) from [<c03a0f1c>] (cpu_startup_entry+0x28/0x2c) [ 1.901502] [<c03a0f1c>] (cpu_startup_entry) from [<c031cfc4>] (secondary_start_kernel+0x17c/0x1a8) [ 1.910562] [<c031cfc4>] (secondary_start_kernel) from [<103034ac>] (0x103034ac) [ 1.917979] Rebooting in 90 seconds.. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 years, 7 months

[opensuse-arm] Updates for Leap 15.0 on aarch64?

by Olav Reinert

Hi all, I'm running Leap 15.0 on my Raspberry Pi 3, the aarch64 port. It all works great, but I've noticed that the system doesn't receive any updates. Zypper only has one repository registered, which is the main download repo (see below). That's perfect for installing new packages, but it doesn't receive any updates (as expected). For example, the kernel hasn't changed since Leap 15 was released. Is there an update repository for Leap 15 on aarch64? Thanks, Olav pi3:~ # zypper lr -u Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh | URI --+-----------------------------------+------------------------------ -----+---------+-----------+---------+--------------------------------- ------------------------------------------- 1 | openSUSE-Ports-Leap-15.0-repo-oss | openSUSE-Ports-Leap-15.0-repo- oss | Yes | (r ) Yes | Yes | http://download.opensuse.org/port s/aarch64/distribution/leap/15.0/repo/oss/ pi3:~ # rpm -qi kernel-default Name : kernel-default Version : 4.12.14 Release : lp150.11.3 Architecture: aarch64 Install Date: Sun Jun 10 20:19:13 2018 Group : System/Kernel Size : 263289216 License : GPL-2.0 Signature : RSA/SHA256, Wed May 16 22:37:53 2018, Key ID b88b2fd43dbdc284 Source RPM : kernel-default-4.12.14-lp150.11.3.nosrc.rpm Build Date : Wed May 16 22:22:37 2018 Build Host : obs-arm-2 Relocations : (not relocatable) Packager : https://bugs.opensuse.org Vendor : openSUSE URL : http://www.kernel.org/ Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems. Source Timestamp: 2018-05-11 10:28:30 +0200 GIT Revision: a9fee0989a17203b0fa48196e464a738f1222412 GIT Branch: openSUSE-15.0 Distribution: openSUSE Leap 15.0 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 years, 7 months

[opensuse-arm] Control output pin on RPi

by Volker Kuhlmann

Has anyone ever managed to control an output pin on a raspberry pi 3 B+? Don't laugh! Using python gpiozero [2] a few days ago produced crash output indicating 4 different ways of accessing IO pins were tried and all failed. [1] (Running as root worked no better.) Now the same thing dies with Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/gpiozero/pins/pi.py", line 71, in pin pin = self.pins[n] KeyError: 4 During handling of the above exception, another exception occurred: ... File "/usr/lib/python3.6/site-packages/gpiozero/pins/local.py", line 67, in _get_revision raise PinUnknownPi('unable to locate Pi revision in /proc/cpuinfo') gpiozero.exc.PinUnknownPi: unable to locate Pi revision in /proc/cpuinfo indicating someone's relying on what looks like proprietory kernel extensions. Trying wiringpi means installing the whole gcc lafaffel, on a minimal system. Is there a something like a 3-liner cli program that can flick an output pin on request and JUST WORKS(TM) on openSUSE? (leap 15) Thanks, Volker [1] /usr/lib/python3.6/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpigpio: module 'RPi.GPIO' has no attribute 'IN' 'Falling back from %s: %s' % (name, str(e)))) /usr/lib/python3.6/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpio: No module named 'RPIO' 'Falling back from %s: %s' % (name, str(e)))) /usr/lib/python3.6/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from pigpio: failed to connect to localhost:8888 'Falling back from %s: %s' % (name, str(e)))) /usr/lib/python3.6/site-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root 'Falling back from %s: %s' % (name, str(e)))) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Can't connect to pigpio at localhost(8888) Did you start the pigpio daemon? E.g. sudo pigpiod Did you specify the correct Pi host/port in the environment variables PIGPIO_ADDR/PIGPIO_PORT? E.g. export PIGPIO_ADDR=soft, export PIGPIO_PORT=8888 Did you specify the correct Pi host/port in the pigpio.pi() function? E.g. pigpio.pi('soft', 8888) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Traceback (most recent call last): File "./pi-out-set", line 7, in <module> from gpiozero import LED File "/usr/lib/python3.6/site-packages/gpiozero/__init__.py", line 22, in <module> from .devices import ( File "/usr/lib/python3.6/site-packages/gpiozero/devices.py", line 486, in <module> Device.pin_factory = _default_pin_factory() File "/usr/lib/python3.6/site-packages/gpiozero/devices.py", line 453, in _default_pin_factory raise BadPinFactory('Unable to load any default pin factory!') gpiozero.exc.BadPinFactory: Unable to load any default pin factory! [2] from gpiozero import LED import sys out = LED(4) state = sys.argv[1] if state == "on" or state == "1": out.on() else: out.off() -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM September 2018