No display on FreeBSD 14.2 with SiFive Unmatched RISCV board and AMD HD6450 Card

Hello Everyone!

Did some lurking here as well as some other places before posting my question here because I am really stuck. I am hoping to get some help/advice on how to proceed on this problem. I'm posting because from everything I have been able to find, this board is as "plug and play" as it gets under FreeBSD so I was eager to give RISCV a try. Apologies if this should have gone in "other architectures" but since its not giving a display I thought it might be more relevant here.

My reference for doing this install was this site: https://wiki.freebsd.org/riscv/HiFiveUnmatched

I am using 14.2 RELEASE

Because my hard drive had been used in a previous (arm) FreeBSD install, this board tried to boot from it (edit- I didn't try to use the arm code. I wanted a fresh install via memstick) so I followed the "Manually Booting from FreeBSD" section. I get no display whatsoever from the board, however I am able to see things in the serial terminal and get BSD installed with no issues.

Looking at dmesg I see the following lines:
Code:
pci7: <PCI bus> on pcib7
vgapci0: <VGA-compatible display> at device 0.0 on pci7
pci7: <multimedia, HDA> at device 0.1 (no driver attached)
So from what I can gather it sees the card but obviously no driver. Following the handbook in section 5.3 table 1 and cross-checking the database I think I need the graphics/drm-kmod package and then use the radeonkms module adding a line in /etc/rc.conf. When trying to use pkg I get:
Code:
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]:
and when I choose Y it bombs out with the following message:
Code:
pkg: Error: Authentication error
A pre-built version of pkg could not be found for your system.
Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.
Ok fine, so trying make install from ports-mgmt/pkg bombed out after partially compiling, but restarting the make for whatever reason got farther than it ever did before and seemed to make, so I cant duplicate the error. However, it ended with this:
Code:
===>  Checking if pkg is already installed
===>   pkg-1.21.3 is already installed
      You may wish to ``make deinstall'' and install this port again
      by ``make reinstall'' to upgrade it properly.
      If you really wish to overwrite the old port of pkg
      without deleting it first, set the variable "FORCE_PKG_REGISTER"
      in your environment or the "make install" command line.
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make: stopped in /usr/ports/ports-mgmt/pkg

Ok whatever, so pkg works now, so let's hit a pkg install drm-kmod only to get:
Code:
Updating FreeBSD repository catalogue...
pkg: An error occured while fetching package
pkg: An error occured while fetching package
repository FreeBSD has no meta file, using default settings
pkg: An error occured while fetching package
pkg: An error occured while fetching package
pkg: An error occured while fetching package
pkg: An error occured while fetching package
Unable to update repository FreeBSD
Error updating repositories!

Okay, maybe try a make install from graphics/drm-kmod? Nope...
Code:
===>  drm-kmod-20220907_3 not supported for this configuration.
*** Error code 1
Stop.
make: stopped in /usr/ports/graphics/drm-kmod

Am I even barking up the right tree trying to get this installed when handbook section 5.3 really pertains to a GUI instead of command line?

I'm really stumped on this. One of the reasons I wanted to give this particular board a try was because it seemed that it was the most mature of the RISCV boards out there even though RISCV is Tier2. It seemed like it would be a fun way to get a BSD install going. I dont know what Im missing in the instructions to get display output. FWIW the SD card that comes with it does indeed boot to a graphics screen with xfce but its not FreeBSD which is what I would prefer since I've played with it on and off since 4.4 and I only briefly touched "the other operating system" in the mid 1990s.

Any thoughts/advice on this would be greatly appreciated. Hopefully its something like a low level driver that can be fixed by making a new uboot SD card or something and the reference wiki I used is (slightly) out of date on this. Should I try version 13.X since the youtube videos I've seen of this board running FreeBSD were on 13.X?

A huge thank you to everyone who read through this slog and is willing to lend a hand.
 
There is no package repository for RISC-V, so pre-built packages are not available.

The graphics/drm-kmod is, depending on the version, only for i386, amd64, arm64 or powerpc64. Besides that it's really only useful for X though, not for "console" video. And the driver is specifically for Intel or AMD graphics cards (or iGPU).

Code:
.  if ${OSVERSION} >= 1302000 && ${OSVERSION} < 1400097
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-510-kmod
_DRM_ARCHS=	aarch64 amd64 i386 powerpc64 powerpc64le
.  elif ${OSVERSION} >= 1400097 && (${ARCH} == i386 || ${ARCH} == aarch64)
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-510-kmod
_DRM_ARCHS=	aarch64 i386
.  elif ${OSVERSION} >= 1400508
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-61-kmod
_DRM_ARCHS=	amd64 powerpc64 powerpc64le
.  else
_DRM_ARCHS=
.  endif

You might be able to get X working with the scfb(4) or vesa(4) X drivers.
 
Thank you for the reply, SirDice

Getting X working while nice, is far less "important" than getting the display to work at all (everything I did was through serial terminal). I have zero display output, CLI or otherwise. That being said, if I have to do it the way the SD card does it for linux (display doesn't work until you're in X), then I don't mind that. I'll give those drivers a go and see what I can come up with. I'm glad that I can at least get it working even if it is only through serial terminal for now. I'm going to keep playing with it and see what else I can learn while I get some old X86 hardware back up on FreeBSD.

Again, I really appreciate you taking time to reply.
 
I seriously doubt there are PCIe bus drivers for this board.

Without PCIe bus you will have no video card.

You can check pciconf -lv to see i you have any PCIe devices showing up.
 
Thanks for the info. I'll check that command Phishfry and see what I get.

I apologize for some confusion... this was a hard drive I had formatted and used on an arm install, but I am not using the arm image or anything from it. The documentation I have says that if you had a previously formatted drive (which it was) its going to try and boot off of that (which it did and not surprisingly crapped out) and you have to do a manual boot by escaping the uboot and typing a few commands.

I had no problem reformatting the drive and installing the riscv image and verifying the install (via serial) but I could not get the graphics card to work.

EDIT:
Here is what I get when I execute pciconf -lv
Code:
pcib1@pci0:0:0:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0xf15e device=0x0000 subvendor=0x0000 subdevice=0x0000
    vendor     = 'SiFive, Inc.'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:1:0:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:2:0:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib4@pci0:2:2:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib5@pci0:2:3:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib6@pci0:2:4:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:2:8:0:       class=0x060400 rev=0x01 hdr=0x01 vendor=0x1b21 device=0x2824 subvendor=0x0000 subdevice=0x0000
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM2824 PCIe Gen3 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
xhci0@pci0:4:0:0:       class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1b21 device=0x1142 subvendor=0x1b21 subdevice=0x1142
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1042A USB 3.0 Host Controller'
    class      = serial bus
    subclass   = USB
nvme0@pci0:6:0:0:       class=0x010802 rev=0x01 hdr=0x00 vendor=0x1dbe device=0x5216 subvendor=0x1dbe subdevice=0x5216
    vendor     = 'INNOGRIT Corporation'
    device     = 'NVMe SSD Controller IG5216 (DRAM-less)'
    class      = mass storage
    subclass   = NVM
vgapci0@pci0:7:0:0:     class=0x030000 rev=0x00 hdr=0x00 vendor=0x1002 device=0x6779 subvendor=0x1028 subdevice=0x2120
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]'
    class      = display
    subclass   = VGA
none0@pci0:7:0:1:       class=0x040300 rev=0x00 hdr=0x00 vendor=0x1002 device=0xaa98 subvendor=0x1028 subdevice=0xaa98
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235X OEM]'
    class      = multimedia
    subclass   = HDA

So it does find it on vgapci0.

The instructions say I can use the SD card that came with the board to get booted, but I wonder if I should make a new uboot SD card using the uboot repository i found
 
I seriously doubt there are PCIe bus drivers for this board.
According to the May 2024 FreeBSD Developer Summit where they were discussing RISCV, Mitchell Horne gave a talk and discussed this board. He said that FreeBSD support status was "complete" in that NVMe, PCIe, clk/reset, and USB all work. He even called the board "not interesting" because it "just works". That was my motivation for giving it a try.

I might try and make a separate uboot SD card myself and see if that change fixes anything versus using the one that came with the board per the instructions I followed (link in original post).
 
He said that FreeBSD support status was "complete" in that NVMe, PCIe, clk/reset, and USB all work.
PCIe slot probably works with network or storage cards, graphics cards are a bit of a different animal.

That said, I suspect the DRM drivers have only been tested on the architectures set in the port. You could just remove that restriction and give it a shot. Heck it might even build and work.
 
Since the card shows up to the system you should probably focus on how to bring up VGA manually.
vt_vga seems to be the driver that needs to come up. Plug and Play does not exist so you may need to load something.

When a KMS driver is not available, vt_vga remains active.

 
This part of vt(4) manual is relevent:
hw.vga.acpi_ignore_no_vga
Set to 1 to force the usage of the VGA driver regardless of
whether ACPI IAPC_BOOT_ARCH signals no VGA support. Can be
used to workaround firmware bugs in the ACPI tables. Note no
VGA support is only acknowledged when running virtualized.
There is too many broken firmware that wrongly reports no VGA
support on physical hardware.
So I think we can assume ACPI is part of how video card interacts with modern OS for basic video.
I looked at acpi_video and it is not relevent here.
When I was messing with SleepWalker 's EDK2 UEFI BIOS for RK356x that used ACPI with FDT providing some flexibility.
But I looked at SiFive Unleashed and I see no EDK2 builds by anybody. Its all u-boot.

I see this RevB is an ITX class board with good IO options. x8 lanes for the slot.

I tested some lightweight x1 slot and x8 slot NVidia boards on RockPro64 with failure.
One of my first thoughts was power requirments of Video card. I used x8 GT710/720/730 and GT210 x1 card and NVS290 x1.
These were the lowest power cards I had. All failed. I did not try hard.

This is typical of the x8 cards I tested with.
 
PCIe slot probably works with network or storage cards, graphics cards are a bit of a different animal.

That said, I suspect the DRM drivers have only been tested on the architectures set in the port. You could just remove that restriction and give it a shot. Heck it might even build and work.

I might give that a try but I'm not sure. I ran into what might be a show stopper that I'll explain below...

Since the card shows up to the system you should probably focus on how to bring up VGA manually.
vt_vga seems to be the driver that needs to come up. Plug and Play does not exist so you may need to load something.




Well I tried to get the vesa driver installed a couple of times. First time I left the board to compile overnight as its a little pokey and woke up to an error about the disk being full and a panic and a restart. I had zero coffee and so I never thought to copy the error for future checking before verifying disk space (not even remotely close to full on my 256MB drive) so the error message was lost.

The second time I tried to restart it and it bombed on a kernel panic, probably because of settings I messed up in the install (I was multitasking and hit commands in the build window when I thought I was another window). After trying to fix a fix a fix I said "bugger it" and blew everything off and started with a fresh install so I could more carefully trace what I was doing. Also, since the handbook says to install x11/Xorg before the driver, I decided to follow that path. For additional sanity and organization, I used freshports to install the dependencies one by one starting with graphics/mesa-dri. During the build things were going smoothly last night into this morning one of its dependencies, lang/rust gave me what I think might be a showstopping error:
Code:
=> Sanity check failed: kernel is missing COMPAT_FREEBSD11
=> Aborting build
Here is the context of the error:
Code:
/usr/local/lib/libcurl.a(libcurl_la-tftp.o)

      If there are vulnerabilities in these programs there may be a security
      risk to the system. FreeBSD makes no guarantee about the security of
      ports included in the Ports Collection. Please type 'make deinstall'
      to deinstall the port if this is a concern.

      For more information, and contact details about the security
      status of this software, see the following webpage:
https://curl.se/
===>   rust-1.81.0 depends on shared library: libcurl.so - found (/usr/local/lib/libcurl.so)
===>   Returning to build of rust-1.81.0
===>  Configuring for rust-1.81.0
===>   FreeBSD 10 autotools fix applied to /usr/ports/lang/rust/work/rustc-1.81.0-src/vendor/libssh2-sys-0.3.0/libssh2/config.rpath
===>   FreeBSD 10 autotools fix applied to /usr/ports/lang/rust/work/rustc-1.81.0-src/vendor/libssh2-sys-0.2.23/libssh2/config.rpath
Bad system call
=> Sanity check failed: kernel is missing COMPAT_FREEBSD11
=> Aborting build
*** Error code 1

Stop.
make[17]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[16]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[15]: stopped in /usr/ports/devel/py-setuptools-rust
*** Error code 1

Stop.
make[14]: stopped in /usr/ports/security/py-cryptography
*** Error code 1

Stop.
make[13]: stopped in /usr/ports/security/py-cryptography
*** Error code 1

Stop.
make[12]: stopped in /usr/ports/security/py-openssl
*** Error code 1

Stop.
make[11]: stopped in /usr/ports/net/py-urllib3
*** Error code 1

Stop.
make[10]: stopped in /usr/ports/net/py-urllib3
*** Error code 1

Stop.
make[9]: stopped in /usr/ports/www/py-requests
*** Error code 1

Stop.
make[8]: stopped in /usr/ports/www/py-requests
*** Error code 1

Stop.
make[7]: stopped in /usr/ports/textproc/py-sphinx
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/textproc/py-recommonmark
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/devel/llvm15
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/devel/llvm15
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/graphics/mesa-libs
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/graphics/mesa-libs
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/graphics/mesa-dri
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/mesa-dri

x11-drivers/xf86-video-vesa also relies on lang/rust but graphics/drm-kmod does not based on running make all-depends-list | grep rust , so I'm going to have to some more digging to the path of least resistance to get a graphics driver in place. If I try to override the platforms and try to get graphics/drm-kmod to work, I might get a CLI but I wont have x11. On the other hand, getting freebsd11 compatability in the kernel gives x11 support and by extension a vesa driver. I need to try a kernel rebuild and take it from there. I'll keep you posted.

Not giving up by a longshot, but wanted to give all of you an update since you were kind enough to take time to give me suggestions.

Regards,
 
Are you sure you want VESA video driver in this case?
VESA only runs under the old sc(4) system console.
SC only runs on Legacy BIOS machines.

You are going to want scfb for an EFI machine that uses vt(4).

This board boots via EFI method correct?

I think working on a X11 driver when you have no console video is a faulty concept.

 
Are you sure you want VESA video driver in this case?
VESA only runs under the old sc(4) system console.
SC only runs on Legacy BIOS machines.

You are going to want scfb for an EFI machine that uses vt(4).

This board boots via EFI method correct?

I think working on a X11 driver when you have no console video is a faulty concept.


I reviewed the documentation and I think I got it backwards when to use vesa vs scfb.

My rationale for trying to get this installed came from doing an install a few days ago on my x86 box. after graphics/drm-kmod was installed, my resolution suddenly changed during the boot not just in X, so my thought process was if the driver listed under configuring X would affect the boot (and hece the CLI) on the x86 this might get display to work on the RISCV.

However, now that ive re-read what you sent and the vga man, im going to double check the kernel and, if necessary, rebuild it.


Regards,
 
Kernel didn't have device vga in it, so I added it along with the hint the appropriate hint file (which didn't exist so it was freshly created). The make buildkernel failed right out of the gate...

Code:
make[1]: "/usr/src/Makefile.inc1" line 337: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 342: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.

--------------------------------------------------------------
>>> Kernel build for VGAKERNEL started 
--------------------------------------------------------------
===> VGAKERNEL
mkdir -p /usr/obj/usr/src/riscv.riscv64/sys

--------------------------------------------------------------
>>> stage 1: configuring the kernel
--------------------------------------------------------------
cd /usr/src/sys/riscv/conf;  PATH=/usr/obj/usr/src/riscv.riscv64/tmp/bin:/usr/obj/usr/src/riscv.riscv64/tmp/usr/sbin:/usr/obj/usr/src/riscv.riscv64/tmp/usr/bin:/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin:/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/bin:/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin:/usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  config  -d /usr/obj/usr/src/riscv.riscv64/sys/VGAKERNEL  -I '/usr/src/sys/riscv/conf' -I '/usr/src/sys/riscv/conf'  '/usr/src/sys/riscv/conf/VGAKERNEL'
config: Error: device "vga" is unknown
config: 1 errors
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Still researching and looking to see what I can find.

Regards,
 
I am pretty sure there is something on traditional BIOS called INT10h hooks.
This fires up video bios.

So maybe you need to add something to u-boot. (Does this board uses U-Boot??)

I saw this section in .config for another board in u-boot and thought of this thread:
# Graphics support
#
# CONFIG_VIDEO is not set
# CONFIG_SPL_VIDEO is not set
 
Good looking out, Phishfry I'll take a look at that. This board does use u-boot. In fact I found a specific uboot for this board that I will take a look at (I think I found it in ports I have to go through my 5 billion tabs) once things settle down in a few days.
 
Back
Top