Arm-dev October 2016

arm-dev@lists.centos.org

17 participants
15 discussions

Gigabyte MP30-AR0
by Gordan Bobic 12 Nov '19

12 Nov '19

Hi, I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions? Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM? Thanks. Gordan

10 197

Request for a new package: raspberrypi-vc
by Jordi Sanfeliu 13 Sep '17

13 Sep '17

Hello, Following the Fabian Arrotin recommendation, I open here the request to include the 'raspberrypi-vc' package into the CentOS 7 EPEL repository, or in the main tree. This package includes a command called 'vcgencmd' which offers a set of interesting values of the Raspberry Pi board; e.g. its temperature. Check here <http://www.elinux.org/RPI_vcgencmd_usage> for more information. I've downloaded the SRPM package from here <http://www.squeezecommunity.org/repo/fedora/24/pi/SRPMS/raspberrypi-vc-2016…>, and I realized that it was pretty easy to build on a full-updated CentOS 7 (kernel 4.4.14-v7). The following are the small modifications I made on the .spec file to accomplish it: --- raspberrypi-vc.spec 2016-07-05 23:23:13.000000000 +0200 +++ raspberrypi-vc.spec.ok 2016-07-13 12:14:39.494059817 +0200 @@ -21,12 +21,12 @@ Patch1: raspberrypi-vc-EGL-dep.patch # dtoverlay -BuildRequires: libfdt-devel >= 1.4.1-501.gitbeef80b%{?dist} +##BuildRequires: libfdt-devel >= 1.4.1-501.gitbeef80b%{?dist} Requires: libfdt >= 1.4.1-501.gitbeef80b%{?dist} BuildRequires: cmake, gcc-c++ -ExclusiveArch: armv6hl armv7hnl +ExclusiveArch: armv7hl %description Libraries, utilities and demos for the Raspberry Pi BCM2835/6 SOC GPU @@ -34,7 +34,7 @@ %package libs Summary: Libraries for accessing the Raspberry Pi GPU -Requires: %{name}-firmware >= 20150212git47bd0f0-501 +##Requires: %{name}-firmware >= 20150212git47bd0f0-501 #Provides: libEGL.so #Provides: libGLESv1_CM.so The build generated successfully the following packages: [root@rpi3 rpmbuild]# l -R RPMS/ RPMS/: total 8 drwxr-xr-x 2 root root 4096 Jul 26 15:59 armv7hl drwxr-xr-x 2 root root 4096 Jul 13 12:23 noarch RPMS/armv7hl: total 1352 -rw-r--r-- 1 root root 552156 Jul 13 12:22 raspberrypi-vc-libs-20160705-501.git0b8c195.el7.centos.armv7hl.rpm -rw-r--r-- 1 root root 340184 Jul 13 12:22 raspberrypi-vc-libs-devel-20160705-501.git0b8c195.el7.centos.armv7hl.rpm -rw-r--r-- 1 root root 244960 Jul 13 12:23 raspberrypi-vc-static-20160705-501.git0b8c195.el7.centos.armv7hl.rpm -rw-r--r-- 1 root root 241332 Jul 13 12:23 raspberrypi-vc-utils-20160705-501.git0b8c195.el7.centos.armv7hl.rpm RPMS/noarch: total 30688 -rw-r--r-- 1 root root 31420584 Jul 13 12:23 raspberrypi-vc-demo-source-20160705-501.git0b8c195.el7.centos.noarch.rpm The installation worked finely: # [root@rpi3 armv7hl]# rpm -ivh raspberrypi-vc-utils-20160705-501.git0b8c195.el7.centos.armv7hl.rpm raspberrypi-vc-libs-20160705-501.git0b8c195.el7.centos.armv7hl.rpm Preparing... ################################# [100%] Updating / installing... 1:raspberrypi-vc-libs-20160705-501.################################# [ 50%] 2:raspberrypi-vc-utils-20160705-501################################# [100%] Then a simple command to get the temperature: [root@rpi3 ~]# vcgencmd measure_temp temp=47.2'C Thanks. -- Jordi Sanfeliu FIBRANET Network Services Provider http://www.fibranet.cat

4 5

Kernel for BananaPi R1 (Lamobo R1)
by mo.ucina 12 May '17

12 May '17

Hello Guys, I have been compiling the Fedora 4.4.2-300 kernel for Centos , using the new Centos image for the Banana-pi . I have used the Fedora src rpm and then added the patch for the switch drivers specific for R1 (Lamobo R1) , then compiled it within the Centos dev arm environment I have . I ran into a couple of things : one cosmetic , the other one not so . Firstly the cosmetic one is that my packages came out looking like this : -rw-rw-r-- 1 user user 49332 Feb 26 07:27 kernel-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 87721969 Feb 26 07:27 kernel-4.4.2-300.LR1.el7.centos.src.rpm -rw-rw-r-- 1 user user 18785384 Feb 26 07:29 kernel-core-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 10452672 Feb 26 07:30 kernel-devel-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 1012496 Feb 26 07:27 kernel-headers-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 11844188 Feb 26 07:31 kernel-modules-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 925980 Feb 26 07:31 kernel-modules-extra-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 105452 Feb 26 07:27 kernel-tools-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 65356 Feb 26 07:27 kernel-tools-libs-4.4.2-300.LR1.el7.centos.armv7hl.rpm -rw-rw-r-- 1 user user 52160 Feb 26 07:27 kernel-tools-libs-devel-4.4.2-300.LR1.el7.centos.armv7hl.rpm They all have "centos" as part of the name , which I did not expect . I did not get that when compiling in Fedora. How do you remove that ? Second observation , a one that is a bit of a concern is that , after installing the new kernel I am missing bits : user@bananapi /boot $ ls -l total 43611 drwxr-xr-x. 5 root root 1024 Feb 25 22:21 38f5ec9e217b471e8adee477d933f640 -rw-r--r--. 1 root root 171924 Nov 26 00:43 config-4.2.3-200.el7.armv7hl drwxr-xr-x. 2 root root 15360 Dec 3 14:37 dtb-4.2.3-200.el7.armv7hl drwxr-xr-x. 2 root root 1024 Dec 3 14:47 extlinux drwxr-xr-x. 2 root root 1024 Jan 1 1970 grub -rw-r--r--. 1 root root 34922581 Dec 3 14:46 initramfs-4.2.3-200.el7.armv7hl.img -rw-r--r--. 1 root root 592347 Dec 3 14:37 initrd-plymouth.img drwxr-xr-x. 3 root root 1024 Dec 3 14:44 loader drwx------. 2 root root 12288 Dec 3 14:31 lost+found -rw-------. 1 root root 2879429 Nov 26 00:43 System.map-4.2.3-200.el7.armv7hl -rwxr-xr-x. 1 root root 5866104 Nov 26 00:43 vmlinuz-4.2.3-200.el7.armv7hl I expected that I would be missing 'initramfs' as the install prog is still work-in-progress. And I was prepared to create it with dracut . However I did not expect not to be missing all the other bits such as : config , dtb, system.map, vmlinuz . I did find my new kernel it was in that dir with a hex name : user@bananapi /boot $ ls -l 38f5ec9e217b471e8adee477d933f640/* 38f5ec9e217b471e8adee477d933f640/0-rescue: total 40652 -rw-r--r--. 1 root root 35427302 Dec 3 14:43 initrd -rwxr-xr-x. 1 root root 6033128 Feb 25 22:26 linux 38f5ec9e217b471e8adee477d933f640/4.2.3-200.el7.armv7hl: total 39995 -rw-r--r--. 1 root root 34923169 Dec 3 14:40 initrd -rw-r--r--. 1 root root 5866104 Dec 3 14:44 linux 38f5ec9e217b471e8adee477d933f640/4.4.2-300.LR1.el7.centos.armv7hl: total 41061 -rw-r--r--. 1 root root 35844934 Feb 25 22:24 initrd -rw-r--r--. 1 root root 6033128 Feb 25 22:36 linux So my question is how do I go from these 2 files above , to the situation where I can boot into the new kernel 4.4.2-300.LR1.el7.centos.armv7hl . Best Regards Milorad PS Once I have verified that the switch driver works , I will post it here .

5 13

I2C in Centos 7
by cjvijf＠gmail.com 29 Jan '17

29 Jan '17

Hello, I am running Centos on a raspberry pi 2b. (I downloaded the image from: http://people.centos.org/hughesjr/armv7hl/rpi2/images/ rpi2-centos-image.img.xz ) and installed the i2c libraries and modules for i2c. [root@rpi2-2 ~]# lsmod | grep i2c i2c_bcm2708 5006 0 i2c_dev 6027 0 From what I read that should be correct device file is there too: crw------- 1 root root 89, 1 Dec 31 1969 i2c-1 kernel: Linux rpi2-2 3.18.14-v7+ #794 SMP PREEMPT Sun Jun 7 12:50:51 BST 2015 armv7l armv7l armv7l GNU/Linux However, when I scan the i2c bus with 'i2cdetect -y 1' I don't see any devices (and I tried 2 that I know work). is the I2C stuff in this kernel working? (or is there a newer kernel version?) thanks, Ron P.S. I know this is an arm-dev list, but figured the I2C topic would fit better here than in a general Centos list

2 1

supported 64bit hardware
by Nick Hardiman 15 Dec '16

15 Dec '16

Which 64 bit consumer-size board is the easiest to work with now? I want to buy a few small ARMv8 boards to run CentOS on. Seems like a reasonable idea to offload simple services onto simple boards. Is this page still accurate? https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 I don’t really know why 64 bits gets all the attention at this small scale, but that does seem to be where people are headed. I’ve tried a few 32 bit boards, and it is fiddly work. I end up spending more time on the bootloader and kernel compilation and less time at the application level. AFAICT, progress is being made getting Odroid C2 support into the kernel. Not so sure about Hikey and RPi3. Looks like Redhat is working with Applied Micro X-gene - I guess that's for the data center market. Any suggestions? Many thanks, Nick

12 37

armv7hl kernel update for Dirty COW
by Ian Pilcher 31 Oct '16

31 Oct '16

Can we expect an armv7hl kernel update to address CVE-2016-5195? -- ======================================================================== Ian Pilcher arequipeno(a)gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ========================================================================

4 10

kernel armhfp 4.4.26 - feedback wanted !
by Fabian Arrotin 24 Oct '16

24 Oct '16

Hi, With the recent CVE-2016-5195 (aka "Dirty Cow"), we bumped the armhfp kernels to the following version : 4.4.26 (both for "generic" and rpi2/rpi3) Before releasing those to mirror.centos.org (and also sign those) we'd like some people to test the updated/unsigned kernels (feedback wanted !) - create the /etc/yum.repos.d/ .repo file pointing to corresponding repo, depending on your board : - http://dev.centos.org/centos/7/kernel/armhfp/kernel-generic/ - http://dev.centos.org/centos/7/kernel/armhfp/kernel-rpi2/ as an example, here is how it would look like : [kernel-generic] name=armhfp kernel generic baseurl=http://dev.centos.org/centos/7/kernel/armhfp/kernel-generic/ gpgcheck=0 enabled=1 or [kernel-rpi2] name=armhfp rpi2 kernel baseurl=http://dev.centos.org/centos/7/kernel/armhfp/kernel-rpi2/ gpgcheck=0 enabled=1 - now "yum clean all ; yum update" PS : for rpi2/3, the system will automatically use the updated kernel on next reboot PS2 : for "generic" (so cubietruck, etc) you still need to : - modify /boot/extlinux/extlinux.conf to reflect new kernel PS3 : depending on the image you're using for cubietruck/bananapi, the /boot space is probably just too small, so dracuty will complain about not able to probably build the -rescue- initramfs (which isn't needed) : just be sure that kernel and initramfs were built before rebooting, and you can also remove the undeeded files in /boot : rm uIm* uInit* Cheers, -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

2 2

USB on PI3
by Björn Dieding 18 Oct '16

18 Oct '16

Hello, I am tying the raspberry image on a pi3. Somehow I am not sure, if USB is properly working. The WIKI pages says it does (https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32/RaspberryPi3). Does someone get the same result or what message do you get? [root@support ~]# export LIBUSB_DEBUG=9 [root@support ~]# lsusb -v libusbx: debug [libusb_init] created default context libusbx: debug [libusb_init] libusbx v1.0.15.10646 libusbx: error [op_init] could not find usbfs unable to initialize libusb: -99 On my regular centos servers I get a proper result. Best regards, Björn Dieding

1 0

[RFC] Bootstrapping a new arch
by Haïkel 17 Oct '16

17 Oct '16

Hi, There was various discussions about enabling aarch64 architecture for Cloud SIG OpenStack repositories. And likely others are coming, so I'd like to confirm with a wider audience about the proper course of action. So we can document it and share that experience with other SIGs. Arrfab suggested the following: * scratch builds with archoverride of existing arch-dependent builds * ask CBS admin to merge the task with existing builds using mergeScratch. I find this process simple and efficient, but I'm worried about how it scales. In my case, I have about 250 binary packages (including the Erlang stack etc.) with many interdependencies, so it can rapidly get bothersome for CBS admins. If we can find a way to automate the mergeScratch operations or temporarily grant that permission to SIGs during bootstrapping phase, I have pretty much no objections for that course. --- As for daily operations, if you can't block on alternate arch build failures, I was recommended to just use %excludearch and move forward. Which gives us the flexibility to move forward and give more time to fix things at our pace. So what do you think? Any other suggestions? Regards, H.

2 1

python34 for aarch64
by Gordan Bobic 13 Oct '16

13 Oct '16

Are there python34 packages for aarch64 already built somewhere? I need them for acd_cli, but they don't seem to be in any of the available repositories I could find. TIA. Gordan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev October 2016