openSUSE ARM November 2018

arm@lists.opensuse.org

7 participants
5 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] 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

2 years, 4 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

2 years, 4 months

[opensuse-arm] ARMv8 CRC and Crypto on openSUSE Leap 42.1

by Jeffrey Walton

Hi Everyone, I'm working on the GCC Compile Farm. I'm on machine gcc118.fsffrance.org, which is an ARMv8.a machine. The cpu offers CRC and Crypto. The machine runs openSUSE Leap 42.1. When I attempt to engage the CRC and Crypto extensions the program fails to compile. CRC is shown below, but AES and SHA result in similar failures. The unusual thing is, there is no <arm_acle.h> header. Missing <arm_acle.h> is common for Android and Apple, but Linux usually supplies it. Does anyone know how to enable the CRC and Crypto extensions on openSUSE? Thanks in advance. ======== ======== ======== ======== ======== ======== == CPU info == > cat /proc/cpuinfo processor : 0 [nid: 0] Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 2 ... == Linux == > lsb_release -a LSB Version: n/a Distributor ID: SUSE LINUX Description: openSUSE Leap 42.1 (aarch64) Release: 42.1 Codename: n/a == GCC == > gcc --version gcc (SUSE Linux) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == No ACLE == > cat TestPrograms/test_acle.cxx #include <arm_acle.h> int main(int argc, char* argv[]) { return 0; } > g++ -march=armv8-a -O0 TestPrograms/test_acle.cxx TestPrograms/test_acle.cxx:1:22: fatal error: arm_acle.h: No such file or directory #include <arm_acle.h> ^ compilation terminated. == No CRC == > cat TestPrograms/test_crc.cxx #include <arm_neon.h> #include <stdint.h> #if (CRYPTOPP_ARM_ACLE_AVAILABLE) # include <arm_acle.h> #endif int main(int argc, char* argv[]) { uint32_t w=0xffffffff; w = __crc32w(w,w); w = __crc32h(w,w); w = __crc32b(w,w); return 0; } > g++ -march=armv8-a -DCRYPTOPP_ARM_ACLE_AVAILABLE=0 -O0 TestPrograms/test_crc.cxx TestPrograms/test_crc.cxx: In function ‘int main(int, char**)’: TestPrograms/test_crc.cxx:15:18: error: ‘__crc32w’ was not declared in this scope w = __crc32w(w,w); ^ TestPrograms/test_crc.cxx:16:18: error: ‘__crc32h’ was not declared in this scope w = __crc32h(w,w); ^ ... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 years, 5 months

[opensuse-arm] No ssh access to openSUSE Tumbleweed on Raspberrry Pi 1B

by Freek de Kruijf

Recently I upgraded Tumbleweed on my Raspberry Pi 1B to the latest version. After that I am unable to access that system using ssh. I found that the problem is caused by upgrading openssh to version 7.8p1. The problem is solved in 7.9p1, which for other systems is available in OBS. However I could not find that version for armv6hl. Any information on that? -- 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, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

openSUSE ARM November 2018