Trying to use uart0 aka ttyS0 for NMEA communication with a GPS module i discovered that it is possible to crash the kerenel using ttyS0…
setup: remove console=ttyS0,115200n8 from the kernel commandline and disable login on ttyS0 by ln -s /dev/null /etc/systemd/system/serial-getty@ttyS0.service
Now accessing the console with a different baudrate, eg screen /dev/ttyS0 9600 leads to:
It seems this is because riscv hvc sbi driver waits for sbi_console_putchar to return but it doesn’t. as hvc0 via sbi and the ttyS0 use the same underlying hardware I’d suspect this is because the uart was configured to a different baudrate.
possible solutions:
A fix on the sbi or kernel level would be appreciated. I’m not sure how the setup is done on sbi level, but returning an error if the console was reconfigured instead of just blocking forever would be an option according to the documentation.
workaround:
For now my workaround is to make sure hvc0 isn’t used by also disabling it with
i have not cause i’m not sure where and what to report.
on the sbi/u-boot level i’ve got no idea how this is set up… but i think it’s hardware specific
on the kernel level:
one might argue that the kernel driver should not just wait for the sbi funcition call to return forever but on the other hand that function call is specified to block until the console is ready or to return an error… so i’d assume its safe to wait for a return
all in all this seems pretty hardware specific because the uart is used by u-boot/sbi and linux (configured via starfives device tree)
but if you’ve got hints where & how to report the issue i’d be happy to do so
I understand is deprecated and shouldn’t be used in the first place.
Doesn’t the kernel hit the serial port directly? Maybe the problem is that the sbi-based console remains in use after the kernel has already taken over.
This should get some attention, as serial port being reliable is very important.
@SunWukong this is true, but I already have a spare Uputronics HAT and would love to get an NTP server using it up and running on the Visionfive 2. And I really don’t like the system monopolising UART0, anyhow.
I can understand that, I use two HATs from Uputronics myself.
mike@mpc4:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+rpi8.ln.berline 192.168.178.16 2 u 957 1024 377 0.521 +0.281 0.247
*rpi6.ln.berline .PPS. 1 u 617 1024 377 0.567 +0.068 0.129
+rpi2.ln.berline .GPS. 1 u 343 1024 377 0.353 +0.045 0.169
+rpi1.ln.berline 192.168.178.16 2 u 601 1024 377 0.527 +0.179 0.219
rpi1 is only a backup NTP without GPS and rpi8 is actually also a Statum-1 with PPS and uses a HAT from Uputronics like rpi6, but something is broken since the last apt upgrade. Only on rpi8 do I have an Ubuntu installed, the others all run Debian from Raspberry. On rpi2 I use an Adafruit Ultimate GPS.
I’m not sure, the document i linked is still a draft.
Yes, thats my understanding. I’m pretty sure the kernel doesn’t “know” that serial0 and the sbi-based console use the same underlying hardware.
And yes, instead of directly attaching the hat I can connect it via jumper cables. nevertheless the serial0 is configured for use with linux via the device tree so i’m trying to use it for my needs.
