AMD GPU FreeBSD 14-Release

M

mkooner

Hello,

I am trying to get my AMD 6900XT working with FreeBSD, I have seen other articles on the forum and followed instructions. I have install drm-515-kmod and gpu-firmware-amd-kmod and still having an issue loading the driver.
When I boot into the system it results in a blackscreen, and when I check the /var/log/messages output, it seems to load all the sienna_cichlid firmwares.
But it gives me the error PSP runtime database does not exist and firmware failed to load, I am not sure how to fix this issue, have anyone else encountered this?
 
Adding copy of /var/log/messages:
Code: 
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: VRAM: 16368M 0x0000008000000000 - 0x00000083FEFFFFFF (16368M used)
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: AGP: 267894784M 0x0000008400000000 - 0x0000FFFFFFFFFFFF
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] Detected VRAM RAM=16368M, BAR=16384M
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] RAM width 256bits GDDR6
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] amdgpu: 16368M of VRAM memory ready
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] amdgpu: 16368M of GTT memory ready.
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
Mar  4 06:27:42 Mehrab-FreeBSD kernel: [drm] PCIE GART of 512M enabled (table at 0x0000008001FA4000).
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_sos.bin'
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_ta.bin'
Mar  4 06:27:42 Mehrab-FreeBSD kernel: drmn0: PSP runtime database doesn't exist
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_smc.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: lkpi_iic0: <LinuxKPI I2C> on drmn0
Mar  4 06:27:44 Mehrab-FreeBSD kernel: iicbus0: <Philips I2C bus> on lkpi_iic0
Mar  4 06:27:44 Mehrab-FreeBSD kernel: iic0: <I2C generic I/O> on iicbus0
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_dmcub.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm] Loading DMUB firmware via PSP: version=0x0202001E
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_pfp.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_me.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_ce.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_rlc.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_mec.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_mec2.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_sdma.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm] use_doorbell being set to: [true]
Mar  4 06:27:44 Mehrab-FreeBSD syslogd: last message repeated 3 times
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: successfully loaded firmware image 'amdgpu/sienna_cichlid_vcn.bin'
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm] Found VCN firmware Version ENC: 1.27 DEC: 2 VEP: 0 Revision: 0
Mar  4 06:27:44 Mehrab-FreeBSD kernel: drmn0: Will use PSP to load VCN firmware
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm ERROR :psp_hw_start] PSP load sos failed!
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm ERROR :psp_hw_init] PSP firmware loading failed
Mar  4 06:27:44 Mehrab-FreeBSD kernel: [drm ERROR :amdgpu_device_fw_loading] hw_init of IP block <psp> failed -22
 
Small question - did you use any self-build parts here, like self compiled kernel, self-compiled package...?
 
This is my first time using FreeBSD just followed directions on the forum and documentation. Tried installing the packages using PKG install and compiled using ports collection. Get the same error each time, also tried multiple versions of FreeBSD and same error.
I am not familiar with the system enough to compile the kernel or would know what to look for to fix.
 
mkooner said:
I have install drm-515-kmod and gpu-firmware-amd-kmod
Click to expand...
Try installing meta port graphics/gpu-firmware-kmod

From github.com/freebsd/drm-kmod issue drm-515-kmod: Loss of display signal with RX 6800 XT #244
evadot commented Mar 25, 2023 on Mar 25, 2023

Looks like you might need more firmwares.
Some AMD GPU needs firmware from other generation (usually for video decoding etc ...), can you test installing the meta package gpu-firmware-kmod (which will install all the firmwares) and try again ?
If that works please paste again dmesg as it will contain the name of the firmware loaded, I'm working on a script that will automatically install firmware packages based on the PCI id of the video card so I will need to patch it.
Click to expand...
 
I have an update on this, I can get the AMD GPU driver to load but it loads in a very hacky way and I am not sure why.
The only way it works is if I boot into Xorg/SDDM/KDE first with the SCFB driver loaded, must run a video in my case through YouTube website and then I run kldload amdgpu and restart SDDM/Xorg/KDE. And only if I do things in that order does the GPU load properly.

I wrote a script to automate this and do all that for me, but does anyone know why this is happening and an easier/permanent way to fix it?
 
Without your current edition of a script, try:

sysrc -f /etc/rc.conf kld_list+=drm && sysrc -f /etc/rc.conf sddm_enable=YES

– (that is, specifically, drm without amdgpu) then:
  1. restart the system
  2. sign in to Plasma
  3. as root, kldload amdgpu
At <https://github.com/freebsd/drm-kmod/issues/> and in Bugzilla, there are order-/timing-related issues. If yours is another case, let's refine it.
 
mkooner said:
… When I boot into the system it results in a blackscreen, …
Click to expand...

Later:

mkooner said:
…/…/KDE …
Click to expand...

Was the blackness before installing SDDM and KDE, or after?

If the blackness is after log in to Plasma (X11) (as the option is presented in SDDM) – a commonplace symptom – then we may be over-thinking, a simple workaround may apply.

After log in:
  1. key Alt-F2, to present KRunner
  2. plasmashell --replace

mkooner said:
… directions on the forum and documentation …
Click to expand...

Please, can you recall which directions? Some topics in The FreeBSD Forums are terribly outdated, and will remain so (the possibility of complaints, removals, and punishment if updates are added).

Similarly, which documentation?

Did it include the quick start (four steps) for KDE?
 
grahamperrin said:
Without your current edition of a script, try:

sysrc -f /etc/rc.conf kld_list+=drm && sysrc -f /etc/rc.conf sddm_enable=YES

– (that is, specifically, drm without amdgpu) then:
  1. restart the system
  2. sign in to Plasma
  3. as root, kldload amdgpu
At <https://github.com/freebsd/drm-kmod/issues/> and in Bugzilla, there are order-/timing-related issues. If yours is another case, let's refine it.
Click to expand...
The results are the same as I have now, need to run a video first before kldload amdgpu works otherwise I get the same original error.
 
mkooner said:
… need to run a video first before kldload amdgpu works otherwise I get the same original error.
Click to expand...

So, after drm loads and whilst Plasma (X11) runs with SCFB, kldload amdgpu (without previously viewing a video) results in a blackout of the type described in the opening post.
 
Did OP try the tip in post #10 in my thread? Specifically, from the screenshot about EFI framebuffer:
Code: 
hw.syscons.disable=1
(See the rest of the screenshot for more info on how to make that sysctl setting stick).

I think that setting should help with loading the amdgpu.ko and the sienna_cichlid driver...

That tidbit disappeared from the FreeBSD graphics wiki since I made that thread... 😩
 
astyle said:
Did OP try the tip in post #10 in my thread? Specifically, from the screenshot about EFI framebuffer:
Code: 
hw.syscons.disable=1
(See the rest of the screenshot for more info on how to make that sysctl setting stick).

I think that setting should help with loading the amdgpu.ko and the sienna_cichlid driver...

That tidbit disappeared from the FreeBSD graphics wiki since I made that thread... 😩
Click to expand...
I've use the EFI framebuffer flag before but it, then the system just freezes at the bootloader and can't get past that.

Also, on a side note, I couldn't figure out how to get into single user mode to make change the loader.conf after since it froze at the bootloader, so I needed to do a reinstall. Is there a better way repair that file if something goes wrong?
 
Yeah, this looks interesting... I just checked on my 13.2-RELEASE laptop - hw.syscons.disable is not a variable that sysctl knows about in this case... 😲 But there's quite a few hw.amdgpu.nnn, surprisingly. If someone finds good documentation on THAT, I think that would be a good contribution to this thread... 😅
 
For UEFI boots, loader tunable kern.vty cannot be sc. Only vt is supported.

Possibly some CSM implementations of some UEFI firmware support real text modes that legacy BIOS had, but maybe wouldn't always supported by even CSM.

And neither boot1.efi nor loader.efi used for UEFI boot doesn't support/initializes real text mode (text modes on them are emulated using graphical efifb framebuffer).

And more, memory region which loader.efi allocates to load kernel and modules specified in /boot/loader.conf[.local] is not so large, because (if I understand correctly the UEFI spec) there's no way to free the region afterwards (means, kept until next reboot even if too much a mess). So modules loaded in /boot/loader.conf[.local] should be limited to anything fundamental for base system to start. Everything else should be loaded via kld_list variable in /etc/rc.conf[.local].

If any modules explicitly described as dependency (in modules themselves) are not yet loaded, they are automatically loaded.

Note that if there are implicit dependencies, possibly (actually) required modules are not automatically loaded. In such a case, order of modules in kld_list variable could be mutually fundamental (implicit dependencies should be appear earlier than their implicit consumers).
 
You must log in or register to reply here.
Back
Top