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

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.

Today I updated the kernel, and so had to reboot. I first changed verbosity, and rebooted. The box didn't come back. So I hooked up the serial cable, and power cycled it. No serial output, and no boot. I power cycled again, still no output, but it did boot. Weird.

 

Is there a drawback to leave it running with verbosity on 7? And if there isn't, why isn't that the default?

18 hours ago, RockBian said:

Is there a drawback to leave it running with verbosity on 7? And if there isn't, why isn't that the default?

No drawback. Boot might be slightly slower since the kernel has to shove all its output over serial, no matter if it is actually read or not.