[BPI-R2] Login console lost with Linux Kernel 6.6

Hi all,

First of all, I would like to thank and glorify frank-w did a great work with his repos related to Linux Kernel and u-boot.

I currently have the BPI-R2 up and running with kernel 5.15 (GitHub - frank-w/BPI-Router-Linux: Linux kernel 4.14+ for BPI-R2, 5.4+ for R64, 6.1+ for R2Pro and R3; updated to latest 5.15 long-term release) with debian bookworm on rootfs. Everything is working without any problem related to login console via serial line.

I am facing issues with 6.6 kernel (build from the same repo; branch 6.6-main) where the kernel is logging to serial line, systemd gets starting but the console is lost after some time and there is no login console being shown. It seems like it incorrectly initialize the ttyS console.

I am using same bootargs for both kernels:

board=bpi-r2 earlyprintk console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4 rootwait vmalloc=496M debug=7 initcall_debug=0 video=1920x1080 console=tty1 fbcon=map:0 drm.debug=0x7

Any guess from where to start? I plan to investigate the problem via ssh because the network seem to be running but I am wondering of some of you was already facing the problem like this :slight_smile:.


6.6-main contains the swap mmc+uart patch but i have not tried latest versions on r2 (due to work on newer boards).

Maybe something else is missing/wrong…can you connect over ethernet? If yes you can look in dmesg if there is something strange

Remember: the internal wifi/bluetooth is no more supported in 6.x kernels

unavailability of wifi/bluettoth is not a problem and I am aware of that :).

I am also appending the log, basically stuff I am not seeing from the serial line is this:

[   20.958975] mediatek-disp-ovl 14007000.ovl: deferred probe timeout, ignoring dependency
[   20.959687] mediatek-disp-rdma 14008000.rdma: deferred probe timeout, ignoring dependency
[   20.960357] mediatek-disp-rdma 14012000.rdma: deferred probe timeout, ignoring dependency
[   20.960639] mediatek-disp-rdma 14012000.rdma: Failed to add component: -517
[   20.961683] platform 14012000.rdma: deferred probe pending
[   20.961710] platform 10205000.mmsys_iommu: deferred probe pending
[   34.398035] vusb: disabling
[   34.398115] vmc: disabling
[   34.398171] vmch: disabling
[   34.398226] vgp1: disabling
[   34.398386] vcamaf: disabling

The only suspicious thing here seems to be not initialized display subsystem and ovl timeout.

dmesg.log (32.4 KB)

Looks good so far…disp lines are for drm (hdmi out). TtyS0 is recognized and i guess it is a problem with systemd. Maybe the service file for the ttyS0 is wrong,but wonder why this is kernel depended

11004000.serial: ttyS0 at MMIO 0x11004000 (irq = 204, base_baud = 1625000) is a ST16650V2

Maybe something like here: No login promt for serial console - Raspberry Pi Forums

Our suspicious seems to be correct - the serial-getty service is not running. Let me dig into this more. Echo of something to /dev/ttyS0 is working.

Kernel 6.6:

           │ └─1 /sbin/init earlyprintk
             │ └─277 /usr/sbin/cron -f
             │ └─278 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             │ ├─281 /bin/sh -e /etc/rc.local start
             │ ├─283 /bin/bash /usr/sbin/wifi.sh
             │ └─289 /usr/bin/wmt_loader
             │ └─282 /usr/sbin/smartd -n
             │ ├─296 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
             │ ├─300 "sshd: root@pts/0"
             │ ├─311 -bash
             │ ├─317 systemctl status
             │ └─318 less
             │ └─129 /lib/systemd/systemd-journald
             │ └─285 /lib/systemd/systemd-logind
             │ └─156 /lib/systemd/systemd-networkd
             │ └─269 /lib/systemd/systemd-resolved
             │ └─270 /lib/systemd/systemd-timesyncd
                 └─147 /lib/systemd/systemd-udevd

Kernel 5.15:

CGroup: /
           │ └─1 /sbin/init
             │ └─316 /usr/sbin/cron -f
             │ └─317 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             │ ├─340 /usr/bin/stp_uart_launcher -p /etc/firmware
             │ └─383 hostapd -d /etc/hostapd/hostapd_ap0.conf
             │ └─322 /usr/sbin/smartd -n
             │ ├─338 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
             │ ├─403 "sshd: root@pts/0"
             │ ├─414 -bash
             │ ├─419 systemctl status
             │ └─420 less
             │ └─[email protected]
             │   └─384 /sbin/agetty -o "-p -- \\u" --noclear - linux
             │ └─[email protected]
             │   ├─385 /bin/login -p --
             │   └─397 -bash
             │ └─158 /lib/systemd/systemd-journald
             │ └─324 /lib/systemd/systemd-logind
             │ └─187 /lib/systemd/systemd-networkd
             │ └─359 /lib/systemd/systemd-resolved
             │ └─309 /lib/systemd/systemd-timesyncd
                 └─176 /lib/systemd/systemd-udevd

Yes it looks like the getty service is not started,but why depend on kernel? Any info in syslog?

Maybe try

systemctl status serial-getty

If you do not use hdmi out you can drop the console settings for it from cmdline

Maybe removing all baudrates except 115200 from the execline

Maybe you should disable the wifi.sh in /etc/rc.local…it is possible it blocks further bootup

Sorry, it get me some time until I get back to this. I have seen some queued jobs with systemctl list-jobs like graphical.target etc. So I have enabled just systemctl set-default multi-user.target because the default one was graphical target. Commenting out the wifi.sh solved the issue because the rc-local service was running but it was’t ending.

systemctl list-jobs --after

JOB UNIT                                                              TYPE  STATE  
1   multi-user.target                                                 start waiting
└─      waiting for job 114 (systemd-update-utmp-runlevel.service/start) -     -      
114 systemd-update-utmp-runlevel.service                              start waiting
104 getty.target                                                      start waiting
└─      waiting for job 1 (multi-user.target/start)                      -     -      
105 [email protected]                                                start waiting
└─      waiting for job 104 (getty.target/start)                         -     -      
113 rc-local.service                                                  start running
└─      waiting for job 1 (multi-user.target/start)                      -     -      
└─      waiting for job 105 ([email protected]/start)                   -     -      
└─      waiting for job 110 ([email protected]/start)           -     -      
110 [email protected]                                        start waiting
└─      waiting for job 104 (getty.target/start)                         -     -      

6 jobs listed.

I am not sure if it was my fault during the kernel compilation but systemd was complaining about missing autofs4 module and I have find out that the autofs support wasn’t enabled in my kernel compilation. So recompiling with this option also made systemd happy about this.

Thank you for your patience, I wasn’t aware that there is wifi being enabled in /etc/rc.local file :). I have created a sytemd service with timeout so when the WIFI is not available than it doesn’t stuck in the rc-local.service. I am starting with this but it might require some tuning and it might be good to split the device init and add the dependency on the wifi init service.

# /etc/systemd/system/wifi.service
Description="Start WIFI on BPI device"
After=network.target remote-fs.target