arm May 2020

arm@lists.fedoraproject.org

12 participants
15 discussions

The server images are not working with Fedora 31
by Peter Hjalmarsson 04 Aug '20

04 Aug '20

Hi, Just wanted to point out that due to U-Boot not supporting XFS, and Fedora Server has moved to a XFS /boot, the current images as https://dl.fedoraproject.org/pub/fedora/linux/releases/31/Server/aarch64/im… does not boot on any system using U-Boot, like for example the raspberry pi. Best Regards, Peter Hjalmarsson

3 5

CMA on raspberry pi 4
by Thomas H.P. Andersen 04 Aug '20

04 Aug '20

Hi, I have looked into the CMA setting issue a bit. This is what I have found so far. The rpi4 needs CMA to be in ZONE_DMA (lower 1GB of memory) as this is the only area that the peripherals on the rpi4 can address. The DT sets the allowed range to allocate the CMA from ( arch/arm/boot/dts/bcm2711.dtsi#L869 <https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2711.dts…>), but it seems to not work here. What does work is instead to set the offset manually. I replaced "cma=256MB" with "cma=256M@704M" and then it boots. Note that it has to be 256M instead of 256MB. Removing the cma option on the command line was known as a workaround. Without that we would fall back to the build config of 64MB cma which was located at offset 0x38000000. This left 64MB at the end of ZONE_DMA, and I chose offset 704M so that those 64MB would still be free. Not sure if that is needed or not. The crashkernel needs to be in ZONE_DMA as well but it seems to be set to 0 size. I have tested on 5.7 rc2 from rawhide. This probably belongs in a bug report. What would be the correct place to file that? From what I can tell upstream has been tested with cma settings without problems (as long as the requested CMA size can fit in ZONE_DMA). From that it seems like fedora-specific issue. Not sure though. Cheers, Thomas

4 17

Workstation on Pinebook Pro
by Ben Cotton 09 Jul '20

09 Jul '20

Hi ARM friends, I've been trying without success to get the F32 Workstation RC1.6 (tomorrow's release) installed on my Pinebook Pro. If anyone here has done it, do you have instructions written up somewhere? One layer of trouble I've had is that the image apparently doesn't have the uboot files. The arm-image-installer script looks for them, AFAICT, in the image, so I called the installer with the PREFIX set to '', which was enough to get the install script to work, but the PBP doesn't boot from the SD card. I also used the 'rock64' target, which seems like it should be the right answer and not 'pinebook' (since the Pinebook uses a different board from the Pinebook Pro). But maybe that's part of my problem, too? -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

5 9

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 31 May '20

31 May '20

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2020-06-02 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

Getting U-Boot after uart is enabled and trying to connect pollution sensors to my RPI 3 B+ running Fedora IoT 32 (latest update)
by Andrea Battaglia 25 May '20

25 May '20

Hi all, I'm investigating and trying to make this work for a week now. I wouldn't bother if I wasn't sure that digging deeper into this issue would take much more time than I have available at the moment. So this is the scenario: Hardware: - Platform: RPi 3 B+ - Sensor (on the board): Pimoroni Enviro+ - Particulate Matter Sensor (connected to Enviro+): PMS5003 - SD Card: Sandisk 64Gb Software: Fedora IoT 32 (just updated to the latest) State of art: I've successfully enabled and tested I2C and SPI. Drivers for the Enviro+ board run like a charm on a container manager by Podman. The particulate Matter Sensor needs urat to be enabled, so I've made the fedora arm installer tool to enable uart for me. Below the command issued to setup the SD card: sudo fedora-arm-image-installer -y --image=/home/abattagl/Downloads/OS/Fedora-IoT-32-20200429.0.aarch64.raw.xz --target=rpi3 --media=/dev/sde --resizefs --addkey=/home/abattagl/.ssh/id_rsa.pub --norootpass --addconsole I started testing uart from a fresh install and "rpm-ostree update" to avoid previous changes to the system affect the proper fuctioning of the serial port. After the first boot of Fedora IoT and the system update I've shout id down and connected the Enviro+ sensors board. The system booted properly after and I could see that both /dev/ttyS1 and /dev/ttyAMA0 are working at a boud rate of 9600: [root@localhost ~]# stat /dev/ttyAMA0 File: /dev/ttyAMA0 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 178 Links: 1 Device type: cc,40 Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout) Context: system_u:object_r:tty_device_t:s0 Access: 2020-04-01 17:24:15.499999987 +0000 Modify: 2020-04-01 17:24:15.499999987 +0000 Change: 2020-04-01 17:24:15.499999987 +0000 Birth: - [root@localhost ~]# stat /dev/ttyS0 File: /dev/ttyS0 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 1113 Links: 1 Device type: 4,40 Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout) Context: system_u:object_r:tty_device_t:s0 Access: 2020-04-01 17:24:15.249999987 +0000 Modify: 2020-04-01 17:24:15.249999987 +0000 Change: 2020-04-01 17:24:15.249999987 +0000 Birth: - [root@localhost ~]# stat /dev/ttyS1 File: /dev/ttyS1 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 1145 Links: 1 Device type: 4,41 Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout) Context: system_u:object_r:tty_device_t:s0 Access: 2020-04-01 17:24:15.599999987 +0000 Modify: 2020-04-01 17:24:15.599999987 +0000 Change: 2020-04-01 17:24:15.599999987 +0000 Birth: - The big issues happens when I connect the particulate matter sensor to the sensors board. The RPi startup phase stops showing the U-Boot command prompt. and, of course, I haven't got the skills to debug/investigate that. I can just guess I'm missing something. A side note: using raspbian and the Pimoroni installation script, which, in turn, uses raspi-config to set up the system as the sensor expect, everything works fine and I'm able to query the particulate matter sensor using the python drivers. I've tried to read the bash code of the raspi-config tool, but I'm not capable to understand ad deeply as I would. The official documentation for the sensors says (quote): "Note that if you're using this sensor with Raspberry Pi, then you'll need to make a couple of changes to its configuration. Type sudo raspi-config in the terminal and then under "Interfacing options" and "Serial" disable the login shell and enable the serial port hardware. Edit your /boot/config.txt file and add the lines enable_uart=1 and dtoverlay=pi3-miniuart-bt to the bottom of the file." https://shop.pimoroni.com/products/pms5003-particulate-matter-sensor-with-c… here is my config.txt file: [root@localhost ~]# cat /boot/efi/config.txt [pi3] kernel=rpi3-u-boot.bin [pi4] kernel=rpi4-u-boot.bin [all] arm_64bit=1 dtparam=i2c_arm=on dtparam=spi=on bootcode_delay=1 gpu_mem=32 start_x=1 upstream_kernel=1 dtoverlay=upstream dtoverlay=pi3-miniuart-bt dtoverlay=adau7002-simple mask_gpu_interrupt1=0x100 audio_pwm_mode=0 enable_uart=1 And the kernel args: [root@localhost ~]# rpm-ostree kargs net.ifnames=0 modprobe.blacklist=vc4 root=UUID=3111a58e-40ce-4a5d-9314-90d7993c97f9 ostree=/ostree/boot.1/fedora-iot/82e3a6b60b9e57a232d7bcc53ea00d8f7ec28eacc454f0391f8e5c29d671d2ed/0 Could you please provide support on this topic? It's a very interesting and technical detail to me and it's a compulsory step for a meaningful, big project I'm currently running for my company. Many thanks in advance, Andrea

2 1

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 24 May '20

24 May '20

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2020-05-26 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 17 May '20

17 May '20

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2020-05-19 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

fedora 32 systemd-udevd segv
by John Gwynne 15 May '20

15 May '20

Fresh install of Fedora 32 on a Xilinux Zynq (Trenz Electronics TE0726-03M zynqberry). systemd 245.4-1 has a segmentation fault on boot. Downgrading to 243.8-1 from fedora 31 works as expected. The relevant syslog error follows: systemd-udevd[1312]: Using default interface naming scheme 'v245'. systemd-udevd[1312]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. systemd-udevd[1304]: eth0: Worker [1312] processing SEQNUM=968 is taking a long time systemd-udevd[1304]: Worker [1312] terminated by signal 11 (SEGV) systemd-udevd[1304]: eth0: Worker [1312] failed systemd-coredump[1348]: Process 1312 (systemd-udevd) of user 0 dumped core. Stack trace of thread 1312: #0 0x00000000004ace70 builtin_net_setup_link.lto_priv.0 (systemd-udevd + 0x29e70) Before pursuing this as a possible bug, I would like to ask if anyone recognizes this error or knows of possible causes. Thanks in advance, jsg

2 3

Re: Fedora CoreOS on multi-arch
by Jakub Cajka 15 May '20

15 May '20

----- Original Message ----- > From: "Alex Perez" <aperez(a)alexperez.com> > To: coreos(a)lists.fedoraproject.org > Sent: Saturday, May 9, 2020 2:49:17 AM > Subject: Re: Fedora CoreOS on multi-arch > > Jakub, > > How difficult would it be to add armhfp to the CoreOS builds? If you're > interested in the use case, it's for the third and fourth generation > OLPC laptops, the XO-1.75 and XO-4, both of which are based on Marvell > MMP, and are 32-bit, with ~1GB RAM. As of Fedora 32, stock Fedora armhfp > kernels boot and userland runs, unmodified, on the XO-1.75. > > Regards, > Alex Perez > > I think that it is kind of technically possible, but not that simple. IMHO possibly harder, at least from my perspective, than ppc64le, aarch64 and s390x together. To elaborate even aarch64 will work currently only on UEFI(qemu somewhat tested only). I'm not really sure if there is even some that generic way to do it for armhfp(VMs or boards). My current understanding is that even for aarch64 there will be need to alter the produced "bare-metal" images for the target "non standard" HW/board. Something similar to the arm-image-installer(hopefully just patch for it). For starting to enable the FCOS you will have to look in the coreos-assembler(https://github.com/coreos/coreos-assembler). Either fully build it on armhfp(IMO easier), although I believe we aren't building Fedora base container image for it or cross build from(aarch64,hard or other system via full emulation hardest). You should be able just start by following the README(IMO it is extremely easy to build Fedore CoreOS locally, on x86_64) and see what will break. One thing is sure that the armhfp will need patches for https://github.com/coreos/coreos-assembler/blob/master/src/cmd-buildextend-… and few other place at minimum. Actually one blocking point might be that you need nested virt working due to the way how the assembler works currently. So not really that easy and I have definitively forgotten some other possible pain points. For me, from arm side, I hope that I will be able to have time to look in to running FCOS on baremetal aarch64 RPI4(VM runs on rawhide Fedora fine for me ;) ) and RockPro64. JC

2 1

State of RocPro64 support?
by Marcin Juszkiewicz 13 May '20

13 May '20

Some time ago I bought Rockpro64 board from Pine64. To check how EBBR works, how PCIe works on SBCs, Mali Panfrost driver etc. Board arrived yesterday. I connected serial cable (CB2102 dongles suxx, FT2232HL works fine at 1.5Mbps serial), Ethernet, HDMI and booted. Boot fails each time at same place (whole boot log attached): [ 29.043106] panfrost ff9a0000.gpu: clock rate = 500000000 [ 29.053073] rockchip-vop ff8f0000.vop: Adding to iommu group 1 [ 29.058099] panfrost ff9a0000.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 status 0x0 [ 29.058948] panfrost ff9a0000.gpu: features: 00000000,100e77bf, issues: 00000000,24040400 [ 29.059820] panfrost ff9a0000.gpu: Features: L2:0x07120206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7 [ 29.061053] panfrost ff9a0000.gpu: shader_present=0xf l2_present=0x1 [ 29.063559] rockchip-vop ff900000.vop: Adding to iommu group 2 [ 29.147966] panfrost ff9a0000.gpu: devfreq_add_device: Unable to find governor for the device [ 29.151244] panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq [ 29.173499] panfrost ff9a0000.gpu: Fatal error during devfreq init Same effect with F32 and it's 5.6.6 kernel and with rawhide and 5.7-rc4 one. Board boots to login when I blacklist "panfrost" driver with "rd.driver.blacklist=panfrost" kernel argument. Any suggestions what to look at? It's been a while since I did kernel debugging.

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm May 2020