This sbc is StarfiveVF2 1.3b. uname -a 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n280609-b0091036f724: Sat Sep 27 09:47:04 EEST 2025 /usr/obj/usr/src/riscv.riscv64/sys/GENERIC-NODEBUG riscv The uart used to work OK with FreeBSD 15-CURRENT july 2025. with FreeBSD 16, when the system shifts from u-boot to boot FreeBSD the uart starts to double characters, then finally jibberish (as if speed is wrong). ttyu0 used to work after boot. FreeBSD 16 does not work -- jibberish. dmesg appears normal: <root@riscv>:~# dmesg | grep uart GDB: debug ports: uart GDB: current port: uart uart0: <16550 or compatible> mem 0x10000000-0x1000ffff irq 28 on simplebus0 uart0: console (115200,n,8,1)
This is almost certainly a rclk being wrong bug. I need loader.conf and the FDT that's being used to boot, at the very least. I may need more info about the board Otherwise, this hardware is obscure and it's hard to chase down. If you could also bisect, that would be helpful. There's been a lot of loader changes / fixes. Given that I'm unlikely to be able to obtain this board, having more data is better than less.
I suspect it is this commit as it falls in the window and claims to support the UART on this SOC: commit 768ce2eba66c155a4358d5285008555872b4bb61 Author: Jashank Jeremy <jashank@rulingia.com.au> Date: Tue Aug 26 21:09:15 2025 +1000 puc: Add support for Systembase SB16C1054, SB16C1058. The Systembase SB16C1054 and SB16C1058 are PCI quad- and octal-UART complexes, based on multiple Systembase SB16C1050 cores, which appear to be compatible with the NS8250 family (except for the "enable interrupts" bit in the other BAR). The SB16C105x family are one of two families of PCIe UART complexes on cards by StarTech.com, such as the PEX4S1050 and PEX8S1050. (Other StarTech.com serial offerings use the ASIX AX99100 or ASIX MCS990x.) This is derived from the NetBSD driver. Reviewed by: imp Tested by: Jashank Jeremy <jashank@rulingia.com.au> Obtained from: Jashank Jeremy <jashank@rulingia.com.au> MFC after: 1 week Differential Revision: <https://reviews.freebsd.org/D52150
git revert 768ce2eba66c155a4358d5285008555872b4bb61 /usr/bin/time -h make -j4 buildkernel KERNCONF=GENERIC-NODEBUG /usr/bin/time -h make installkernel KERNCONF=GENERIC-NODEBUG uart problem still there cat /boot/loader.conf kern.geom.label.disk_ident.enable=0 zfs_load=YES vfs.zfs.arc_max="2G" boot_multicons="YES" comconsole_speed="115200" console="comconsole,video"
Created attachment 264281 [details] dtb file for vf2
Any chance you can bisect this?
I would need instructions.
Created attachment 264579 [details] workaround for DTB specifying baud rate but not clock frequency Which version of u-boot are you using? I cannot reproduce with v2025.04 from the u-boot-starfive-visionfive2 port. But with a more recent u-boot built manually I get a similar console issue. It seems they have dropped some essential field for detecting the rclk value. You can try the attached patch and see if it helps.
I am using u-boot from 24 sep 2025. I build manually. Will apply the patch.
That patch works. U-Boot SPL 2025.10-rc5 (Sep 24 2025 - 10:01:40 +0300) DDR version: dc2e84f0. Trying to boot from SPI OpenSBI v1.7 FreeBSD riscv.smallcatbrain.com 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n281161-ead721935251-dirty: Wed Oct 15 10:24:38 EEST 2025 root@sky22.smallcatbrain.com:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC-NODEBUG riscv Console working during boot and ttyu0 working after boot. Thank you!
It looks like this is going to be a problem with u-boot. It appears StarFive is not giving back to u-boot or opensbi. https://lists.denx.de/pipermail/u-boot/2025-October/601018.html https://lore.kernel.org/lkml/521e5549-de83-49a1-a0e5-e47a2cb275ef@freeshell.de/
(In reply to rdunkle from comment #10) Thanks for the heads up. It is very unclear to me the reason or legitimacy of this deprecation. I guess see how it plays out...
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6de1c50e78a826abc08660e4c3ac10f1ddba9ba2 commit 6de1c50e78a826abc08660e4c3ac10f1ddba9ba2 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2025-10-14 18:02:40 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2025-10-31 15:30:02 +0000 uart: provide and use default rclk for JH7110 UART A regression in the u-boot-provided JH7110 device tree leaves the uart incorrectly configured. The issue arises when a baud rate is specified ('current-speed' property), but the rclk value is not ('clock-frequency'). Previous releases, e.g. v2025.04, provided both. The alternative way to retrieve this value is to query the parent clock, but our clk framework is not available during early console probing and configuration. In this instance, we end up defaulting to DEFAULT_RCLK in ns8250_init(), which is the wrong value. The relevant uart class (uart_snps) should provide a default rclk in its definition, but it does not. Add a new variant class with the correct default rclk of 24000000. Finally, uart_cpu_fdt_probe() needs to be updated to actually query this default value when it does not find a 'clock-frequency' property. This was simply missing; the ACPI uart bus behaves identically, see uart_acpi_probe(). PR: 289978 Reported by: rdunkle@smallcatbrain.com MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53119 sys/dev/uart/uart_bus_fdt.c | 6 ++++++ sys/dev/uart/uart_dev_snps.c | 10 ++++++++++ 2 files changed, 16 insertions(+)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c03593716fb13a776778993a83d6385497b373e8 commit c03593716fb13a776778993a83d6385497b373e8 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2025-10-14 18:02:40 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2025-11-13 16:24:48 +0000 uart: provide and use default rclk for JH7110 UART A regression in the u-boot-provided JH7110 device tree leaves the uart incorrectly configured. The issue arises when a baud rate is specified ('current-speed' property), but the rclk value is not ('clock-frequency'). Previous releases, e.g. v2025.04, provided both. The alternative way to retrieve this value is to query the parent clock, but our clk framework is not available during early console probing and configuration. In this instance, we end up defaulting to DEFAULT_RCLK in ns8250_init(), which is the wrong value. The relevant uart class (uart_snps) should provide a default rclk in its definition, but it does not. Add a new variant class with the correct default rclk of 24000000. Finally, uart_cpu_fdt_probe() needs to be updated to actually query this default value when it does not find a 'clock-frequency' property. This was simply missing; the ACPI uart bus behaves identically, see uart_acpi_probe(). PR: 289978 Reported by: rdunkle@smallcatbrain.com MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53119 (cherry picked from commit 6de1c50e78a826abc08660e4c3ac10f1ddba9ba2) sys/dev/uart/uart_bus_fdt.c | 6 ++++++ sys/dev/uart/uart_dev_snps.c | 10 ++++++++++ 2 files changed, 16 insertions(+)