Is this with or without /etc/udev/rules.d/05-serial.rules in place?
The rules are not required.
Edit: rpi3 might need enable_uart=1
@Darksky on a standard arm-testing install, I have the following cmdline:
cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@30 smsc95xx.macaddr=E4:5F:01:07:F7:79 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait modprobe.blacklist=v3d mitigations=off console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=1 snd-bcm2835.enable_compat_alsa=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 usbhid.mousepoll=8 audit=0 usb-storage.quirks=152d:1561:u
However, the /boot/cmdline.txt file only contains:
$ cat /boot/cmdline.txt
root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait modprobe.blacklist=v3d mitigations=off console=serial0,115200 console=tty1 selinux=0 plymouth.enable=1 snd-bcm2835.enable_compat_alsa=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 audit=0 usb-storage.quirks=152d:1561:u
As you can see, the 8250.nr_uarts=1 is added to the beginning. Where does the parameter come from? Is this created and added by the bootloader?
You are probably right. The bootloader in the past seems to check for certain things depending on what type of boot is going on like with uboot / cmdline.txt and configures the system for boot.
I looked at an earlier efi boot /proc/cmdline you had posted and I noticed first that 8250.nr_uarts=anything is not there and it has console=serial0,115200 &
kgdboc=serial0,115200 where your regular install above has console=ttyAMA0,115200 & kgdboc=ttyAMA0,115200.
I had done some testing yesterday on an stock image and removed any mention of console=serial0,115200 & kgdboc=serial0,115200 in /boot/cmdline.txt with and without /etc/udev/rules.d/05-serial.rules. The difference in /proc/cmdline is no mention of serial anything and setting 8250.nr_uarts=0 and /dev/serial1 was created with /etc/udev/rules.d/05-serial.rules in place and no /dev/serial1 created with no /etc/udev/rules.d/05-serial.rules.
Bluetooth works just fine on a default image with the removal of these in /boot/cmdline.txt and no /etc/udev/rules.d/05-serial.rules:
Removed console=serial0,115200 & kgdboc=serial0,115200
No mention of 8250.nr_uarts=anything.
Today I want to test this with your efi boot and see what it does. I am having to burn a new image so it will be a while.
Bluetooth Tests with and without udev rules on standard image
#Standard image install with /etc/udev/rules.d/05-serial.rules:
[ray@pi4 ~]$ ls -lah /dev/{serial1*,ttyAMA*}
lrwxrwxrwx 1 root root 7 Aug 31 08:11 /dev/serial1 → ttyAMA0
crw-rw---- 1 root uucp 204, 64 Sep 19 13:39 /dev/ttyAMA0
[ray@pi4 ~]$ ls -lah /etc/udev/rules.d/05-serial.rules
-rw-r–r-- 1 root root 1.1K Sep 19 09:31 /etc/udev/rules.d/05-serial.rules
[ray@pi4 ~]$ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1360x768M@60 smsc95xx.macaddr=DC:A6:32:AF:B8:7B vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 root=PARTUUID=b75fdbb1-02 rw rootwait console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=1 snd_bcm2835.enable_headphones=1 audit=0
#Standard image install with /etc/udev/rules.d/05-serial.rules:
[ray@pi4 ~]$ ls -lah /dev/{serial1*,ttyAMA*}
ls: cannot access ‘/dev/serial1*’: No such file or directory
crw-rw---- 1 root uucp 204, 64 Sep 20 09:51 /dev/ttyAMA0
[ray@pi4 ~]$ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1360x768M@60 smsc95xx.macaddr=DC:A6:32:AF:B8:7B vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 root=PARTUUID=b75fdbb1-02 rw rootwait console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=1 snd_bcm2835.enable_headphones=1 audit=0
Right or wrong, this is my understanding.
The serial console will either be attached to ttyS0 or ttyAMA0. Which is determined by, if dtoverlay=disable-bt is used or not. If bluetooth is used, it will be attached to ttyAMA0.
Since bluetooth is always attached to ttyAMA0, the serial console must move to the ttyS0 uart. If bluetooth is not used, the serial console will then be attached to ttyAMA0. Since this change is based on the contents of config.txt, there needs to be a way to reflect this in cmdline.txt.
So they invented the udev rules. With the rules, serial0 will always point to the UART the serial console is using:
With bluetooth, serial0 → ttyS0
Without bluetooth, serial0 → ttyAMA0
Edit 3: This allows the kernel arguments console=serial0,115200 and kdgboc=serial0,115200 to be used and always supply the correct UART for the serial console, to the kernel.
Edit: The use of miniuart-bt is supposed to switch the UARTs, placing bluetooth on ttyS0 and serial console on ttyAMA0. But since patchram.sh only connects to ttyAMA0, switching is not possible. (I think).
Edit 2: Modifying patchram.sh to attach to ttyS0 “works”, but the bluetooth device is not created, so then the bluetooth.service is skipped. (but then maybe I did not do this all correctly).
Edit 4: Without adding 8250.nr_uarts=1 to the kernel args, /dev/ttyS0 will not be created. So if bluetooth is used, no serial console will be available. So you must choose between serial or bluetooth. By adding it, both will be available.
@0n0w1c I tested today the latest linux-rpi4-mainline 5.14.4 with your grubefi-rpi4 and the kernel and your grubefi-rpi4 with it’s latest changes did well. No lock ups rebooting with bluetooth. My bluetooth headset also connected and did well.
It looks like you may now have everything working.
inxi summary with kernel 5.14.4 booted with uefi/grub
[ray@pi4 ~]$ inxi -Fxz
System:
Kernel: 5.14.4-1-MANJARO-ARM aarch64 bits: 64 compiler: N/A
Desktop: Xfce 4.16.0 Distro: Manjaro ARM base: Arch Linux
Machine:
Type: Embedded-pc System: Raspberry Pi Foundation
product: Raspberry Pi 4 Model B v: D03114 serial:
Mobo: Sony UK model: Raspberry Pi 4 Model B v: D03114 serial:
UEFI: GitHub - pftf/RPi4: Raspberry Pi 4 UEFI Firmware Images v: UEFI Firmware v1.31 date: 09/09/2021
CPU:
Info: Quad Core model: N/A variant: cortex-a72 bits: 64 type: MCP
arch: ARMv8 rev: 3
features: Use -f option to see features bogomips: 432
Speed: 600 MHz min/max: 600/2000 MHz Core speeds (MHz): 1: 600 2: 600
3: 600 4: 600
Graphics:
Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A
Device-2: bcm2711-hdmi0 driver: N/A bus-ID: N/A
Device-3: bcm2711-hdmi1 driver: N/A bus-ID: N/A
Display: x11 server: X.Org 1.20.13 driver: loaded: modesetting
s-res: 1920x1080
OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 21.2.1 direct render: Yes
Audio:
Device-1: bcm2835-audio driver: bcm2835_audio bus-ID: N/A
Device-2: bcm2711-hdmi0 driver: N/A bus-ID: N/A
Device-3: bcm2711-hdmi1 driver: N/A bus-ID: N/A
Sound Server-1: ALSA v: k5.14.4-1-MANJARO-ARM running: yes
Sound Server-2: JACK v: 1.9.19 running: no
Sound Server-3: PulseAudio v: 15.0 running: yes
Network:
Device-1: bcm2835-mmc driver: mmc_bcm2835 v: N/A port: N/A bus-ID: N/A
IF: wlan0 state: up mac:
Device-2: bcm2711-genet-v5 driver: bcmgenet v: N/A port: N/A bus-ID: N/A
IF: eth0 state: up speed: 100 Mbps duplex: full mac:
Bluetooth:
Device-1: pl011 driver: uart_pl011 bus-ID: N/A
Report: rfkill ID: hci0 rfk-id: 1 state: up address: see --recommends
Drives:
Local Storage: total: 29.81 GiB used: 5.79 GiB (19.4%)
ID-1: /dev/mmcblk0 vendor: Samsung model: EB1QT size: 29.81 GiB
Partition:
ID-1: / size: 29.06 GiB used: 5.77 GiB (19.9%) fs: ext4
dev: /dev/mmcblk0p2
ID-2: /boot/efi size: 213.4 MiB used: 21.6 MiB (10.1%) fs: vfat
dev: /dev/mmcblk0p1
Swap:
ID-1: swap-1 type: zram size: 11.44 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
System Temperatures: cpu: 50.6 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 168 Uptime: 13m Memory: 7.69 GiB used: 734.8 MiB (9.3%)
gpu: 64 MiB Init: systemd Compilers: gcc: 10.2.0 Packages: 670 Shell: Bash
v: 5.1.8 inxi: 3.3.06
[ray@pi4 ~]$
Good job!!
1 Like
Si, do you plan @Darksky to release a new kernel to the unstable repo though ?
I plan on releasing the latest linux-rpi4-mainline and linux-rpi4-rc soon. It has been 12 days without them upgrading our linux-rpi4 kernel.
Well, it seems there is the additional kernel arguments from the bootloader. I need to find more information and get them added.
Thank you for testing and the kind words.
Here is the latest linux-rpi4 kernel with some more patches added since the last one and the latest raspberrypi-bootloader packages. Their mostly some video improvements for v4l. I also pushed the latest kodi-rpi4 packages and I believe with this kernel/bootloader and the new kodi packges HEVC is smoother now.
Pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.63-2
linux-rpi4-headers 5.10.63-2
raspberrypi-bootloader 20210923-1
raspberrypi-bootloader-x 20210923-1
Pic is me testing the new kodi and above packages. You will not see the video as it is not playing in a DE. All that is visible is the window dressing. As you can see it is a pretty stout HEVC with hardware decoding and low cpu usage.
Surprisingly, it doesn’t offer me to upgrade to these versions even though my mirror has been updated.
It is linked to the linux-rpi4 kernel ? I’m using the linux-rpi4-mainline one.
Are you saying this version shows up in your unstable mirror after a -Syy and then a -Syu does not offer it for upgrade?
The packages are not tied to anything. The last version was 20210908-1.
Yes, that’s what I am saying. (I have checked again before answering)
FYI : mirror : Germany Server (manjaro.re) = https://manjaro.re/arm-unstable/
raspberrypi-bootloader-20210923-1-any.pkg.tar.zst 24-Sep-2021 02:56 8858163
raspberrypi-bootloader-20210923-1-any.pkg.tar.z…> 24-Sep-2021 02:56 310
raspberrypi-bootloader-x-20210923-1-any.pkg.tar…> 24-Sep-2021 02:56 4023127
raspberrypi-bootloader-x-20210923-1-any.pkg.tar…> 24-Sep-2021 02:56 310
Edit : correct mirror link and add listing on the selected mirror
Edit2 : it works with another mirror ! sorry for that.
manjaro.re mirror has issues. Please use another mirror.
2 Likes
I’ve changed to a UK mirror and it works now.
Will we see anymore 5.15 builds?
thanks
I am currently testing the 5.15 and 5.14 kernels. I have had it frozen in the repo because upstream had created issues for the RPi team and it is still a WIP for them. They have both kernels working pretty good but still have some things to do. I have posted here the latest kernels for people to test along with me.
So far I have found that kodi-rpi with these kernels will boot and work with fkms and plays h264 with HW decoding but trying to play h.265 with HW decoding will crash kodi while kodi-rpi using kms boots up to loading kodi.bin and the screen goes black and my monitor displays “No Input”. I seem to have some sound source issues I still want to investigate.
Any feed back with testing these kernels posted here would be appreciated. It appears that not many people test with the unstable or stable branches and I really do not want to push them to the repo and have them make it to the stable branch and give them a chance to blow up all of a sudden when everyone goes through an upgrade.
There may be a little trouble brewing, not exactly sure.
I updated to latest arm-testing with the 5.10.63-2 kernel. On reboot, I have to press [ctrl][alt] F(something) before the boot messages stop, or my screen stays black. If I switch around ttys while booting, it will complete the boot to a gui. Rolling back to 5.10.60-2 this issue no longer exists, so pretty sure it is kernel related.
What I am more concerned with is a change in behavior of the green light. With the 5.10.60-2 kernel, the green light comes on and mostly stays on. With 5.10.63-2 (and 5.15), the green light goes into a rhythmic pattern, like some process is “retrying” to access a file on disk. I am concerned this could add unwanted disk activity to SD/SSD that will wear them out.
Edit: It could be that the green light now displays a bit more information and this disk access has been ongoing, just has not been noticable with a solid green light.
cat /boot/config.txt
# See /boot/overlays/README for all available options
# kernel
initramfs initramfs-linux.img followkernel
kernel=kernel8.img
# cpu/gpu
arm_64bit=1
gpu_mem=64
# overclocking
over_voltage=6
arm_freq=2000
core_freq=700
hdmi_enable_4kp60=1
#gpu_freq=700
#v3d_freq=600
#isp_freq=700
#h264_freq=700
#core_freq_min=600
# gpio
#enable_uart=1
dtparam=i2c_arm=on
dtparam=i2c1=on
# sound
dtparam=audio=on
#hdmi_drive=2
# display
disable_overscan=1
#max_framebuffers=2
disable_splash=1
# 4K@30Hz
#hdmi_group=1
#hdmi_mode=95
# 4K@60Hz
hdmi_group=1
hdmi_mode=97
# vc4
#dtoverlay=vc4-fkms-v3d-pi4
dtoverlay=vc4-kms-v3d
# bluetooth
dtoverlay=disable-bt
# wifi
dtoverlay=disable-wifi
# argone one case
dtoverlay=argonone,hysteresis=5
dtparam=fantemp0=45,fanspeed0=33
dtparam=fantemp1=50,fanspeed1=66
dtparam=fantemp2=55,fanspeed2=100
cat cmdline.txt
root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait modprobe.blacklist=v3d elevator=none mitigations=off console=serial0,115200 console=tty1 selinux=0 plymouth.enable=1 snd-bcm2835.enable_compat_alsa=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 audit=0 usb-storage.quirks=152d:1561:u
cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@60 smsc95xx.macaddr=E4:5F:01:07:F7:79 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000
root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait modprobe.blacklist=v3d elevator=none mitigations=off console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=1 snd-bcm2835.enable_compat_alsa=0 smsc95xx.t
urbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 usbhid.mousepoll=8 audit=0 usb-storage.quirks=152d:1561:u
inxi -Fzx
System: Kernel: 5.10.60-2-MANJARO-ARM aarch64 bits: 64 compiler: gcc v: 10.2.0 Desktop: KDE Plasma 5.22.5
Distro: Manjaro ARM base: Arch Linux
Machine: Type: ARM Device System: Raspberry Pi 4 Model B Rev 1.4 details: BCM2835 rev: d03114 serial: <filter>
CPU: Info: Quad Core model: N/A variant: cortex-a72 bits: 64 type: MCP arch: ARMv8 rev: 3
features: Use -f option to see features bogomips: 432
Speed: 600 MHz min/max: 600/2000 MHz Core speeds (MHz): 1: 1400 2: 1400 3: 1400 4: 1400
Graphics: Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus-ID: N/A
Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus-ID: N/A
Device-3: bcm2711-vc5 driver: vc4_drm v: N/A bus-ID: N/A
Display: x11 server: X.Org 1.20.13 driver: loaded: modesetting unloaded: fbdev resolution: 3840x2160~60Hz
OpenGL: renderer: llvmpipe (LLVM 12.0.1 128 bits) v: 4.5 Mesa 21.2.2 direct render: Yes
Audio: Device-1: bcm2711-hdmi0 driver: vc4_hdmi bus-ID: N/A
Device-2: bcm2711-hdmi1 driver: vc4_hdmi bus-ID: N/A
Device-3: bcm2835-audio driver: bcm2835_audio bus-ID: N/A
Sound Server-1: ALSA v: k5.10.60-2-MANJARO-ARM running: yes
Sound Server-2: JACK v: 1.9.19 running: no
Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.37 running: yes
Network: Device-1: bcm2711-genet-v5 driver: bcmgenet v: N/A port: N/A bus-ID: N/A
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: bcm2835-sdhci driver: N/A port: N/A bus-ID: N/A
Drives: Local Storage: total: 111.79 GiB used: 30.07 GiB (26.9%)
ID-1: /dev/sda type: USB vendor: Kingston model: SA400M8120G size: 111.79 GiB
Partition: ID-1: / size: 55.38 GiB used: 30.02 GiB (54.2%) fs: btrfs dev: /dev/sda3
ID-2: /boot size: 246.1 MiB used: 53.6 MiB (21.8%) fs: vfat dev: /dev/sda1
ID-3: /home size: 1.79 TiB used: 1.21 TiB (67.8%) fs: nfs remote: homeb2.{filtered}.com:/home
ID-4: /var/log size: 55.38 GiB used: 30.02 GiB (54.2%) fs: btrfs dev: /dev/sda3
Swap: ID-1: swap-1 type: partition size: 4 GiB used: 0 KiB (0.0%) dev: /dev/sda2
Sensors: System Temperatures: cpu: 46.3 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 204 Uptime: 25m Memory: 7.64 GiB used: 2.17 GiB (28.5%) Init: systemd Compilers: gcc: 10.2.0
clang: 12.0.1 Packages: 994 Shell: Bash v: 5.1.8 inxi: 3.3.06
I did not notice this on a regular install here. May not have anything to do with it but how is it you have vc4-kms-v3d enabled and have llvmpipe for the renderer. Do you have fbturbo installed? If so you need to make a choice of vc4-kms-v3d or fbturbo.
Not fbturbo but rather fbdev. fbturbo’s framebuffer will only run at of depth 16 (with vc4), fbdev with run a depth of 32 which is required for Plasma. Yes, I run kms with v3d turned off and use llvmpipe. It has been working great, until now.
I will try removing kms and just run llvmpipe.