Arm-dev September 2017

arm-dev@lists.centos.org

19 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

Centos support for Marvell Armada 7k/8k
by Marcin Wojtas 05 Oct '17

05 Oct '17

Hi, As for the news, unmodified CentOS-7-aarch64 downloaded from http://mirror.centos.org/altarch/7/isos/aarch64/ works great on Marvell Armada 8040 MacchiatoBin (http://macchiatobin.net/). You can see vmlinuz-4.11.0-22.el7a.aarch64 bootlog here: https://pastebin.com/kuDQRzDV All interfaces that are supported in the mainline linux kernel (with ACPI) work fine with Centos image as well. However as there's an effort to add ACPI support to remaining interfaces (e.g. network or sd/mmc controllers), we would like backport upstream patches to your tree. Hence I have a couple of questions in addition to what can be found in https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64/Contributions: 1. Are the Centos kernel sources accessible in some kind of public repository? 2. When sending patches to arm-dev, do you require original commit log and URL to adequate patch in the kernel.org? 3. Is patch existence in linux-next sufficient for you to accept it? 4. I imagine proceeding in two steps - align drivers between v4.11 and mainline first and later add (still being developed) ACPI support patches once they are ready and merged upstream. Would it be ok for you? 5. Do you have some kind of merge windows/release cycles to follow, when upstreaming patches? Given current quality of Centos support for new family of ARM64 SoCs, how about mentioning Armada 7k/8k family in 'Supported Hardware' section on https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 ? Best regards, Marcin

2 4

Kernel bump to 4.11 for aarch64
by Jim Perrin 25 Sep '17

25 Sep '17

I've just pushed the 4.11 kernel rebase into git ( https://git.centos.org/summary/?r=sig-altarch/kernel ) The previous patches included in the 4.5 kernel have been dropped as the majority either are now included or no longer apply cleanly. Please take a look at configs listed and submit patches for things you'd like to see enabled. This 4.11 base will be coming out shortly as part of the 7.4.1708 build. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

5 9

Kernel problems on APM X-Gene
by Jeremiah Rothschild 22 Sep '17

22 Sep '17

Hey everyone! I cannot get any kernel past 4.5.0-23.el7.aarch64 to work on APM X-Gene hardware. This includes the new (CentOS 7.4) 4.11.0-22 kernel. The last thing ever displayed during boot is this: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... L3c Cache: 8MB which is usual. However, nothing is logged to /var/log/messages (presumably it isn't making it far enough in the boot process) and I'm not sure how to further troubleshoot the issue. Has anyone else been successful? Are there new patches I am unaware of? Can someone please help me debug deeper? Thanks in advance! j

5 17

Fwd: Kernel problems on APM X-Gene
by Gordan Bobic 22 Sep '17

22 Sep '17

This sounds familiar. ISTR messages like this when I tried to use any PCIe cards in my machine, and the machine would typically lock up as soon as the driver for the PCIe card was loaded. I eventually gave up on running with any PCIe cards. What was interesting that the CentOS kernel package would run fine, but as soon as I rebuilt a mainline kernel with the same config and 4KB memory pages, the machine would become allergic to any PCIe card I put in it (tried several AMD and Nvidia GPUs and several SATA controllers). Do you have any PCIe cards in yours? On 22 Sep 2017 01:35, "Jeremiah Rothschild" <jeremiah(a)franz.com> wrote: On Thu, Sep 21, 2017 at 03:14:41AM -0700, Jeremiah Rothschild wrote: > Hmm, interesting. Perhaps if I can figure out how to get the kernel booting > to actually display via video (or IPMI) then it would reveal an error > message. It has never shown output after GRUB but I imagine there's a way to > route it. I was able to get output by adding this to my kernel parameters: console=ttyS0,115200 earlycon=uart8250,mmio32,0x1c020000 >From there, booting into 4.11, it hung here: [ 4.168868] acpi ACPI0007:07: CPPC data invalid or not present [ 4.175198] GHES: HEST is not enabled! [ 4.179167] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address. [ 4.187021] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >From there, I added 'acpi=off' to the kernel parameters. Now I can successfully boot the 4.11 kernel. However, the console is flooded with messages like this: [ 42.982471] pcieport 0002:00:00.0: TLP Header: 60001004 000000ff 00000090 30032000 [ 42.990201] pcieport 0002:00:00.0: AER: Device recovery failed [ 43.156938] pcieport 0002:00:00.0: AER: Multiple Uncorrected (Non-Fatal) error received: id=0000 [ 43.165695] pcieport 0002:00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=0000(Requester ID) [ 43.177385] pcieport 0002:00:00.0: device [10e8:e004] error status/mask=00100000/00000000 [ 43.185695] pcieport 0002:00:00.0: [20] Unsupported Request (First) I'm happy I can boot now. If I can also stop the errors, that'd be great. _______________________________________________ Arm-dev mailing list Arm-dev(a)centos.org https://lists.centos.org/mailman/listinfo/arm-dev

1 0

Official docker containers are now available for AArch64/ARM64
by Jim Perrin 15 Sep '17

15 Sep '17

As of the release of 7.4.1708, the official centos docker containers are now available via multiarch support from the docker hub. For those of you who have been using the centos/aarch64 namespaced base container, you can now use 'FROM centos' as the proper method. I'll keep the centos/aarch64 container around for a little while longer to give people time to migrate. TL;DR: 'docker pull centos' now does the right thing, and provides the image appropriate for your architecture. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

3 3

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

CentOS 7.4.1708 rebuild status
by Fabian Arrotin 08 Sep '17

08 Sep '17

Hi guys, You're probably aware that upstream RHEL 7.4 was released last week, so the x86_64 rebuild started in the following days (https://seven.centos.org/2017/08/centos-linux-7-1708-based-on-rhel-7-4-sour…) On the armv7hl/armhfp side I started (as usual) to rebuild gcc, wait (long time), then glibc. Those rebuilds finished on saturday morning, so since that day, the armhfp builders have been busy rebuilding the 700+ SRPMs. At this stage, more than 530 pkgs were already rebuilt (https://armv7.dev.centos.org/built.html), and some are excluded as not covered for armhfp, which is always expected But this time, we have packages that have failures where they were able to build fine, or other new issues. Example of package failing now to build is mariadb : it builds, but it fails at the tests stage in mariadb itself, so we'll probably need to verify what/why/how Other new "interesting" issue is that some pkg are now relying on external BuildRequires, like devtools-6 package set. As Johnny explained it in his blog post for x86_64, it was built for x86_64, so there is no issue at all. But on the armhfp side, it wasn't, and worse, it will not work : https://armv7.dev.centos.org/rpmbuild/c71708-pass-1/19769-devtoolset-6-gcc-… => "*** Configuration armv7hl-redhat-linux-gnu7E not supported" Any help on trying to solve those issues is welcome PS : myself being busy on my SysAdmin job, so not having a lot of time to spend on armhfp, and also diving into "Summer Holidays without internet connectivity" mode soon ... -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

5 12

Re: [Arm-dev] Lies! Doesn't work on Raspberry Pi 3
by Binary Buddha 08 Sep '17

08 Sep '17

ifconfig -a I get the normal expected output for eth0 and lo "UP,BROADCAST,RUNNING,MULTICAST”. But, I never receive a DHCP address. No packet info because it’s not connecting. As mentioned before, not even the lights on the ethernet port blink. I’m on the RPi 3 Model B V1.2. Is the version the same? Any chance you clean install with the same version of Centos that’s posted to see if it still works for you? Binary Buddha the.binary.buddha(a)gmail.com thebinarybuddha.com PGP/GPG Public Key: https://sks-keyservers.net/pks/lookup?op=get&search=0x8D59CF094187D78D

3 2

Re: [Arm-dev] ?==?utf-8?q? ?==?utf-8?q? java-1.8.0 not building on armv5
by Jacco Ligthart 07 Sep '17

07 Sep '17

On Saturday, 02 September, 2017 10:20 CEST, Jacco Ligthart <jacco(a)redsleeve.org> wrote: > > > On 09/02/2017 09:14 AM, Fabian Arrotin wrote: > > On 31/08/17 00:11, Jacco Ligthart wrote: > >>>> I also checked the other log > >>>> (https://armv7.dev.centos.org/rpmbuild/c71708-pass-1/19329-java-1.8.0-openjd…) > >>>> about resources.jar file missing, when it finds 1.7 and I exploded the > >>>> rpm through rpm2cpio to verify the content and yes, there is a > >>>> permission issue in the -headless package : > >>>> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.141-2.6.10.5.el7.arm/jre/lib/resources.jar > >>>> is 600 so probably not readable by mock itself (argh) > >>>> > >>>> Have now to investigate if the perm issue is due to that package build, > >>>> or if the .spec needs some changes to force better permissions. > >>>> > >>> So the issue with resources.jar is coming from an interim build that I'm > >>> missing, so have to rebuild it first (from the .spec) > >>> - Reset permissions of resources.jar to avoid it only being readable by > >>> root (PR1437). > >>> - Resolves: rhbz#1350042 (but that one is private so can't see what was > >>> changed) > >>> > >>> Seem linked to https://bugzilla.redhat.com/show_bug.cgi?id=1207129 though > >>> > >>> So I tried to rebuild older 1.7 pkg but it fails with "duplicate case > >>> value" . I then found this bug report, and Jacco is included in that bug > >>> report, the IT world is small after all :-) : > >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2942 > >>> > >>> I tried fixing 1.7 openjdk with the > >>> + ARM32JIT="false" \ > >>> patch for the make to ensure that it doesn't build arm32 JIT, but for > >>> strange reason it still tries to build it and fails again ... some other > >>> investigations required to rebuild older 1.7 from pre-7.4, then the one > >>> from 7.4 (with the resources.jar permission issue gone) and then 1.8 > >>> (hopefully) .. of course it happens on java, and on armhp, where each > >>> build needs *several* hours .... > >> I think the issue around ARM32JIT never got fixed, but by now ARM32JIT > >> is disabled by default. There should be no need to disable by hand. > >> > >> Jacco > > Hi Jacco, > > > > Now that I my java-1.7 issues are solved, I confirm that for 7.4.1708 I > > have exactly the same issue as you wrt GDB ( full log at > > http://armv7.dev.centos.org/rpmbuild/c71708-pass-1/19329-java-1.8.0-openjdk…) > > > > (gdb) (gdb) Breakpoint 1 (javaCalls.cpp:1) pending. > > (gdb) >>>(gdb) Starting program: > > /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.131-11.b12.el7.arm/openjdk/build/jdk8.build/images/j2sdk-image/bin/java > > -version > > No source file named javaCalls.cpp. > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/libthread_db.so.1". > > Missing separate debuginfos, use: debuginfo-install > > glibc-2.17-196.el7.armv7hl libgcc-4.8.5-16.el7.armv7hl > > zlib-1.2.7-17.el7.armv7hl > > (gdb) quit > > A debugging session is active. > > Inferior 1 [process 19549] will be killed. > > Quit anyway? (y or n) [answered Y; input not from terminal] > > warning: Probes-based dynamic linker interface failed. > > Reverting to original interface. > > Cannot access memory at address 0xc2400000 > > + grep JavaCallWrapper::JavaCallWrapper gdb.out > > RPM build errors: > > > > Wondering what can be done to fix this > > I don't know gdb enough to understand what it is they are doing here. Is > this a test? (we could just try and skip this) or does this change the > binaries in a meaningful way? > OK I had another look at this. I don't think the gdb section in the SPEC file adds anything to the package, it is just a test. I build java-1.8.0 without this section and it finishes normal. My gut feeling is that the java-1.8.0 binaries are OK, but that we found an error in gdb somehow. Not sure how to test/debug. Jacco

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev September 2017