CMA on raspberry pi 4
by Thomas H.P. Andersen
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.d...>),
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
3 years, 4 months
Workstation on Pinebook Pro
by Ben Cotton
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
3 years, 4 months
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
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...
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
3 years, 6 months
fedora 32 systemd-udevd segv
by John Gwynne
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
3 years, 6 months
Re: Fedora CoreOS on multi-arch
by Jakub Cajka
----- 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-buildexten... 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
3 years, 6 months
State of RocPro64 support?
by Marcin Juszkiewicz
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.
3 years, 6 months
