No kernel bootlog on serial port.

[RockBian]

Today I upgraded my Helios64, and after reboot it didn't come back. (Waited for 5 minutes or so)  After connecting a serial cable (via the USB-C connector), and rebooting, I saw a normal bootloader log (as far as I can see), but no kernel log, just a repeated 'ERROR:   rockchip_plat_sip_handler: unhandled SMC (0x82000003)'. 

I rebooted again, to create a bootlog file, and I saw the same. Then suddenly, after a minute or so, I saw network activity, and my Helios64 was back.

 

Now I have 3 questions. 

1) Why didn't it boot twice, and then succeeded?

2) Why is there no kernel bootlog?

3) What is an unhandled SMC?

 

The log ended with 

ERROR:   rockchip_plat_sip_handler: unhandled SMC (0x82000003)
ERROR:   rockchip_plat_sip_handler: unhandled SMC (0x82000003)
p104^Gp104^G
Armbian 26.5.1 trixie ttyS2 

helios64 login: 

So apparently the serial port is ttyS2.

dmesg gave me this info:

sudo dmesg | grep tty
[    0.000000] Kernel command line: root=UUID=d03fc106-73e9-4465-89a6-b23dbd26eddd rootwait rootfstype=btrfs splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory
[    0.001587] printk: legacy console [tty1] enabled
[    1.986600] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 31, base_baud = 1500000) is a 16550A
[    1.988766] ff1a0000.serial: ttyS2 at MMIO 0xff1a0000 (irq = 32, base_baud = 1500000) is a 16550A
[    1.988911] printk: legacy console [ttyS2] enabled
[    7.930510] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[    7.934926] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[    7.938724] systemd[1]: Expecting device dev-ttyS2.device - /dev/ttyS2...
[    8.771412] systemd[1]: Found device dev-ttyS2.device - /dev/ttyS2.

 

Is it normal that there are 2 legacy consoles enabled?

 

minicom.cap

[Werner]

I don't have this device so I can only give generic advice. 

Set verbosity to 7 in /boot/armbianEnv.txt to get more details besides this unhandled SMC message.

 

From what I've read over the years is that this device seems quite fragile and has lots of quirks in to get it halfway decently running. It would be not uncommon that (on first glance unrelated) upstream changes break something.