GPU firmware naming and problems with loading
Alexey Dokuchaev
danfe at nsu.ru
Tue Apr 21 09:09:05 UTC 2020
Hi there,
While trying to understand why anything other than `graphics/drm-legacy-kmod'
port locks my laptop hard on "kldload radeonkms", I've noticed the different
output during loading of the firmware:
With graphics/drm-legacy-kmod:
info: [drm] Loading ARUBA Microcode
2x radeon/ARUBA_pfp.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name):
radeon/ARUBA_pfp.bin (radeon_ARUBA_pfp_bin)
2x radeon/ARUBA_me.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name):
radeon/ARUBA_me.bin (radeon_ARUBA_me_bin)
2x radeon/ARUBA_rlc.bin: could not load firmware image, error 2
drmn0: Successfully loaded firmware image with name (mapped name):
radeon/ARUBA_rlc.bin (radeon_ARUBA_rlc_bin)
While graphics/drm-fbsd11.2-kmod:
info: [drm] Loading ARUBA Microcode
2x radeon/ARUBA_pfp.bin: could not load firmware image, error 2
2x radeon/ARUBA_me.bin: could not load firmware image, error 2
2x radeon/ARUBA_rlc.bin: could not load firmware image, error 2
info: [drm] Internal thermal controller without fan control
info: [drm] radeon: dpm initialized
2x radeon/TAHITI_uvd.bin: could not load firmware image, error 2
2x radeon/TAHITI_vce.bin: could not load firmware image, error 2
Looks as new DRM code tries to load `/boot/modules/radeon/ARUBA_pfp.bin.ko'
et al., does not find them, and locks up the system, while the legacy code
would try to replace the slash with underscore to generate "mapped name",
which works (since /boot/modules/radeon_ARUBA_pfp_bin.ko does exist).
Can we please decide on the firmware layout, fix this naming/search bug
and make it universal across all DRM ports, at the very least? How does
this even works for other people? :-/
./danfe
More information about the freebsd-x11
mailing list