GPU firmware naming and problems with loading

[Niclas Zeising]

On 2020-04-21 11:09, Alexey Dokuchaev via freebsd-x11 wrote:
> 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? :-/

drm-legacy-kmod and drm-kmod uses the same firmware modules, loaded from 
the same place.  This already works.  drm-legacy-kmod was adapted to 
work with the firmware installed by gpu-firmware-kmod quite some time 
ago, it was one of the last things we did in order to have it replace 
the base kmods.

As you can see in the two prints, the "could not load firmware image", 
comes from ./sys/kern/subr_firmware.c in the base system.
The reason it appears twice, at least for drm-kmod, is that the code 
tries to load the firmware multiple times, guessing where it is.  It 
first tries radeon/TAHITI_pfp.bin twice, then replaces / and . with _ 
and tries again.

IIRC, this was done in order to handle differences between how Linux and 
FreeBSD, and AMD and Intel handles firmware and firmware names.

The relevant code can be seen in request_firmware() here: 
https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.11-fbsd11.2/linuxkpi/gplv2/src/linux_firmware.c

I applied a patch done to later drm-kms branches that make the firmware 
loading more verbose, it is attached.  Needs to be applied with -p1, 
easiest is probably to run make extract in graphics/drm-fbsd11.2-kmod, 
then cd into WRKSRC and apply it with `patch -p1 < /path/to/patch`
then go back to graphics/drm-fbsd11.2-kmod and run make install as normal.

Please test the patch and give the output, that way we should be able to 
see how far firmware loading goes.

Regards
-- 
Niclas Zeising
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verbose.diff
Type: text/x-patch
Size: 2890 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20200421/1984b73d/attachment.bin>