openSUSE ARM December 2018

arm@lists.opensuse.org

8 participants
8 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

3 years, 1 month

[opensuse-arm] VPP

by Alexander Graf

Hi Guillaume, To your question on IRC: > [14:37:37] <guillaume_g> dirk: is there a mean to be scheduled only on one type of machine (e.g. TX1 or TX2) in OBS? Maybe there is a flag or something? > [14:40:41] <guillaume_g> it would be for next VPP version, which perform some runtime checks at configure and if scheduled on TX1 (and maybe HiSi) it would not run on other machines. And if it is build on TX2 (or others), it would not be efficient on TX1. That sounds like we'd (short term) need to patch the configure script to explicitly be tuned for a particular target platform. Then build the binary n times - one for each optimization target. The long term fix is to work with OSEC for example and make sure that this becomes a real runtime check via IFUNCs for example, nothing checked at compile time. The same binary ideally runs fast everywhere then. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 4 months

[opensuse-arm] hctosys does not wait for rtc0 and fails

by Guillaume GARDET

Hi, On my Chromebook ARM, hctosys does not wait that /dev/rtc0 appears and fails on rtc0 opening as it is not accessible at this point. See my dmesg: [ 7.026205] hctosys: unable to open rtc device (rtc0) [ 9.474121] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0 The RTC appears 2.5 sec after hctosys failed. This is because i2c module is needed and is loaded at this time. Any idea how to fix/workaround that? Thanks, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 4 months

[opensuse-arm] rock64 not booting

by Mark Petersen

I finally have had some time to try to get opensuse Tumbleweed to boot on my 2Gb rock64. The image I used was downloaded from: https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/ Rockchip/images/ After dd'ing the image to the emmc, I installed the Arch u-boot using this install guide: https://archlinuxarm.org/platforms/armv8/rockchip/rock64 Using these kernel arguments in grub2/grub.cfg . I'm able to see where the boot process stops: $linux ($root)//Image-4.19.5-1-default ${extra_cmdline} loglevel=7 earlycon=uart8250,mmio32,0xff130000 console=ttyS0,1500000n8 splash=silent plymouth.enable=0 root=UUID=d90c3637-cea7-412c-8aa7-e3a5a47dad39 rw So after unpacking the initramfs, it stops after saying it can't open the rtc. [ 29.068003] Freeing initrd memory: 30036K [ 29.071144] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available [ 29.072396] kvm [1]: 8-bit VMID [ 29.074816] kvm [1]: vgic interrupt IRQ1 [ 29.075557] kvm [1]: Hyp mode initialized successfully [ 29.081276] Initialise system trusted keyrings [ 29.082177] workingset: timestamp_bits=44 max_order=19 bucket_order=0 [ 29.083355] zbud: loaded [ 29.086027] pstore: using deflate compression [ 29.101879] Key type asymmetric registered [ 29.102309] Asymmetric key parser 'x509' registered [ 29.102901] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244) [ 29.103982] io scheduler noop registered [ 29.104388] io sched[ 29.104995] io scheduler cfq registered (default) [ 29.105[ 29.105954] io scheduler bfq registered [ 29.115404] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 29.136242] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 29.163163] Serial: AMBA driver [ 29.164563] msm_serial: driver initialized [ 29.167928] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 29.170729] libphy: Fixed MDIO Bus: probed [ 29.172295] mousedev: PS/2 mouse device common for all mice [ 29.181473] ledtrig-cpu: registered to indicate activity on CPUs [ 29.182859] EFI Variables Facility v0.08 2004-May-17 [ 29.183463] efivars: get_next_variable: status=8000000000000007 [ 29.184227] hidraw: raw HID events driver (C) Jiri Kosina [ 29.189808] NET: Registered protocol family 10 [ 29.227610] Segment Routing with IPv6 [ 29.230255] registered taskstats version 1 [ 29.230691] Loading compiled-in X.509 certificates [ 29.231347] zswap: loaded using pool lzo/zbud [ 29.261624] cryptd: max_cpu_qlen set to 1000 [ 29.290314] Key type big_key registered [ 29.318665] Key type encrypted registered [ 29.319101] AppArmor: AppArmor sha1 policy hashing enabled [ 29.319728] ima:p found, activating TPM-bypass! [ 29.320325] ima: Allocated h[ 29.320986] evm: Initialising EVM extended attributes: [ 229.321845] evm: security.apparmor [ 29.322192] evm: security.61] evm: HMAC attrs: 0x1 [ 29.370627] hctosys: unable to open rtc device (rtc0) checking for rtc in the device tree blob show no entry: fdtdump rk3328-rock64.dtb |grep rtc Checking the kernel config does show 2 entries: cat config-4.19.5-1-default |grep rtc CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC_DEVICE="rtc0" Where do I go from here? Thanks. Mark -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] Kernel debugging

by Frank Kunz

Hello, I want to debug a kernel problem on a armv7 board. For that I want to temporary enable the CONFIG_PROVE_LOCKING config. My idea was to branch the used kernel (lpae) build in obs, add the config to the cloned kernel, and install then the build result on my board. I tried to modify the config.tar.bz2 as well as adding the CONFIG_PROVE_LOCKING=y to the config.addon.tar.bz2. in both cases the build fails with the same error: https://build.opensuse.org/package/live_build_log/home:frank_kunz:branches:… Where do I need to put the configuration change in to get a debug build? Or is there an other method to prepare that? Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] pine64-image not booting on Pinebook 1080p

by Freigeist

Hello all, I own an 11.6" Pinebook 1080p for a few weeks now and have some problems getting opensuse running on it. Maybe someone can help me figuring out what is going wrong. I do not have a serial cable. I am using the latest pine64 image from http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Pin… and write it to a 32GB sdcard using the openSUSE image writer. As I could see, these images now contain a sun50i-a64-pinebook.dtb so I am assuming that they should/could boot on a pinebook. These are my problems: 1. Whenever I look at an sdcard with a freshly written image using gparted, gdisk or any other disk utility it says: "The backup GPT table is not at the end of the disk, as it should be. Fix, by moving the backup to the end (and removing the old backup)?" "Yes" or "Ignore" When I answer "Yes", the card is not recognized afterwards during boot by the pinebook anymore and the pinebook boots Arch Linux from the installed emmc. When I answer "Ignore" the card is recognized during boot by the pinebook but the screen stays black and no matter how long I wait, the pinebook does not boot of it. My questions are, is there something wrong with the image and should I fix it as above or leave it alone and just use it as it is when the image writer has finished its job? 2. I am pretty sure that the pinebook can boot from the above mentioned images because it already did but only _one_ single time and, after that one time boot event, it never did that again. I saw openSUSE's grub coming up and the last message I could see was "Loading initial ramdisk". After that the screen went black and never came back to life again. After this single succesful boot I found the root partition enlarged and a swap partition being added to the sdcard when I looked at it with gparted afterwards. I do not recall anymore if I "fixed" the GPT on the card as above under 1. before inserting it into the pinebook or if I left it unchanged but I am pretty sure that the uboot coming up and starting openSUSE's grub was the Arch Linux one from the emmc. However, I was not able to reproduce this behaviour. What am I doing wrong? 3. After that I tried to start openSUSE's grub with the Arch Linux uboot on the emmc. I was able to list the content of the esp on the sdcard from within Arch Linux's uboot and find the/EFI/BOOT/bootaa64.efi but unable to start it. Is that possible anyway and how would I do that? Thanks guys -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] Notice for Tumbleweed users - root access from ssh is disabled by default

by Guillaume GARDET

Hi, In Tumbleweed, latest openSSH update disables root login by default. So, if you have only 'root' user on your headless system, please run the following command on your system, before running a 'zypper dup': echo -e "\n# Allow root login on ssh\nPermitRootLogin yes" >> /etc/ssh/sshd_config Otherwise, you will not be able to login to your system anymore. If it is too late, please use a local connection (serial or keyboard/screen, if not headless), or edit the /etc/ssh/sshd_config file on your SD card from another computer. Cheers, Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 years, 5 months

[opensuse-arm] Question about support for Banana Pi (M64)

by Freek de Kruijf

I noticed a number of images/support for Banana Pi systems having an armv7 type processor architecture. Also using names with sinovoipbpi in the name of the image. This name is also present in information about the Banana Pi M64 of which the processor architecture is aarch64. There is even an openSUSE Tumbleweed image, dating a year back, which runs on this system. Will there be support for the Banana Pi M64 with a more recent image? It does seem very complicated to have such an image available in the ports repository for aarch64. -- 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

3 years, 5 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM December 2018