Normalize the Makefiles and do almost all logic in the Makefile.inc

[bzfbd]

Normalize the Makefiles and do almost all logic in the Makefile.inc for each driver firmware directory. While this does not change the kernel module file name, it will change the "imagename" of the firmware(9) enbedded in the KMOD. The current DRM linuxkpi will load them with the mapped name and the upcoming in-kernel linuxkpi firmware implementation will also match these names. This will allow for forward compatibility and also remove the slightly odd "imagename" with a "/" included.

Some comments got cleaned up initially copied from iwn(4). And the CLEANFILES lines got harmonised.

Sponsored by: The FreeBSD Foundation

[zeising]

Have you double checked that they actually load and work? I think that the imagename is used by the drm drivers to actually use the firmware. There is a lot of trickery involved with this, and the / in the imagename is intentional.

[zeising]

You also need to be aware that this is used on all versions of FreeBSD, not just current.

What linuxkpi firmware work is going on?

[bzfbd]

Have you double checked that they actually load and work? I think that the imagename is used by the drm drivers to actually use the firmware. There is a lot of trickery involved with this, and the / in the imagename is intentional.

I tried with one Intel card; I have no radeon and no amdgpu.

[bzfbd]

You also need to be aware that this is used on all versions of FreeBSD, not just current.

And I assume from what I saw (though I have not enough insight into all the copies of the various DRM code used) the linuxkpi linux_firmware.c shipped along is the same.

What linuxkpi firmware work is going on?

WiFi and it's supposed to go into HEAD but cannot until I sorted out all DRM breakage.

[zeising]

Have you double checked that they actually load and work? I think that the imagename is used by the drm drivers to actually use the firmware. There is a lot of trickery involved with this, and the / in the imagename is intentional.

I tried with one Intel card; I have no radeon and no amdgpu.

That is not enough. It needs to be tested on radeon and amdgpu as well.

You also need to be aware that this is used on all versions of FreeBSD, not just current.

And I assume from what I saw (though I have not enough insight into all the copies of the various DRM code used) the linuxkpi linux_firmware.c shipped along is the same.

The code for loading firmware might be different depending on which version of FreeBSD is used. There are different branches in kms-drm, one per FreeBSD version, and I don't know if they differ (I haven't looked). They all use the same firmware package though. This firmware package is also used for drm-legacy, although that is being phased out.

[zeising]

It works on FreeBSD current from today, with drm-devel-kmod. However, there are some errors that indicates that it fails (it fails to load the firmware with the original name, and then tries again and gets it right). It might be worth getting rid of those error messages eventually.

amdgpu/raven_asd.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_asd.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_asd_bin
amdgpu/raven_pfp.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_pfp.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_pfp_bin
amdgpu/raven_me.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_me.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_me_bin
amdgpu/raven_ce.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_ce.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_ce_bin
amdgpu/raven_rlc.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_rlc.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_rlc_bin
amdgpu/raven_mec.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_mec.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_mec_bin
amdgpu/raven_mec2.bin: could not load firmware image, error 2
drmn0: fail (0) to get firmware image with name: amdgpu/raven_mec2.bin
drmn0: successfully loaded firmware image with mapped name: amdgpu_raven_mec2_bin

[zeising]

I'm going to see if I can get drm-v4.16 going as well, which could give some indication about FreeBSD 12. Unfortunately it won't load for me when running on actual FreeBSD 12.1.

[zeising]

I'm going to see if I can get drm-v4.16 going as well, which could give some indication about FreeBSD 12. Unfortunately it won't load for me when running on actual FreeBSD 12.1.

Well, that didn't work. It gives compile errors when building the driver.

[bzfbd]

I'm going to see if I can get drm-v4.16 going as well, which could give some indication about FreeBSD 12. Unfortunately it won't load for me when running on actual FreeBSD 12.1.

What doesn't load? The drm-v4.16 or firmware? The 12.x branch had exactly he same linux_firmware logic as the drm-kmod. It's only 11 which is different.

Well, that didn't work. It gives compile errors when building the driver.

"it"? drm-v4.16?

[bzfbd]

It works on FreeBSD current from today, with drm-devel-kmod. However, there are some errors that indicates that it fails (it fails to load the firmware with the original name, and then tries again and gets it right). It might be worth getting rid of those error messages eventually.

Yes, but that's a matter of the firmware (image) name and which logic the linuxkpi version tries with firmware(9). The one from D26598 might even throw another additional one. I'll go and see that we'll get rid of them once the changes are in the tree; don't want to mangle multiple things into one issue.

[valpackett]

amdgpu (Vega) on head, without the linuxkpi changes — firmware with this patch loads fine, with a bit more spam.

before:

[13] drmn0: successfully loaded firmware image with name: amdgpu/vega10_gpu_info.bin
…

after:

[12] amdgpu/vega10_gpu_info.bin: could not load firmware image, error 2
[12] drmn0: fail (0) to get firmware image with name: amdgpu/vega10_gpu_info.bin
[12] drmn0: successfully loaded firmware image with mapped name: amdgpu_vega10_gpu_info_bin
…

[valpackett]

compile errors when building the driver

Yeah, 5.x required many base linuxkpi changes that are not backwards compatible, so you can't build 4.x on head

[zeising]

I'm going to see if I can get drm-v4.16 going as well, which could give some indication about FreeBSD 12. Unfortunately it won't load for me when running on actual FreeBSD 12.1.

What doesn't load? The drm-v4.16 or firmware? The 12.x branch had exactly he same linux_firmware logic as the drm-kmod. It's only 11 which is different.

When I try to load amdgpu.ko on 12.1, the comuter freezes, probably because my GPU isn't properly supported in 4.16, or because of a bug.

Well, that didn't work. It gives compile errors when building the driver.

"it"? drm-v4.16?

Yes. When trying to build 4.16 on CURRENT, the build fails.

[zeising]

It works on FreeBSD current from today, with drm-devel-kmod. However, there are some errors that indicates that it fails (it fails to load the firmware with the original name, and then tries again and gets it right). It might be worth getting rid of those error messages eventually.

Yes, but that's a matter of the firmware (image) name and which logic the linuxkpi version tries with firmware(9). The one from D26598 might even throw another additional one. I'll go and see that we'll get rid of them once the changes are in the tree; don't want to mangle multiple things into one issue.

I'd like to get rid of the extra messages before hand, since it will confuse people, and lead to extra support issues.

[zeising]

amdgpu (Vega) on head, without the linuxkpi changes — firmware with this patch loads fine, with a bit more spam.

before:

[13] drmn0: successfully loaded firmware image with name: amdgpu/vega10_gpu_info.bin
…

after:

[12] amdgpu/vega10_gpu_info.bin: could not load firmware image, error 2
[12] drmn0: fail (0) to get firmware image with name: amdgpu/vega10_gpu_info.bin
[12] drmn0: successfully loaded firmware image with mapped name: amdgpu_vega10_gpu_info_bin
…

Is your GPU working on 12.1? If so, can you test with this patch there?

[valpackett]

probably because my GPU isn't properly supported in 4.16

Yep, raven only started really working in 4.19

it will confuse people

Well, we did have the fail messages for ages, I don't even remember when and how they disappeared.. but +1 in general.

Is your GPU working on 12.1? If so, can you test with this patch there?

It should work. I'll try installing 12.1 on a spare disk..

[zeising]

probably because my GPU isn't properly supported in 4.16

Yep, raven only started really working in 4.19

I have to go dig in an e-waste somewhere then. ;)

it will confuse people

Well, we did have the fail messages for ages, I don't even remember when and how they disappeared.. but +1 in general.

Is your GPU working on 12.1? If so, can you test with this patch there?

It should work. I'll try installing 12.1 on a spare disk..

Thank you! If you are using ZFS, you can try to create a FreeBSD 12.1 boot env otherwise, although it might not work if you've done zpool upgrade.

[valpackett]

Booted 12.1 memstick with drm-v5.0-fbsd12.1 and this firmware, both clean-built while releng/12.1 was checked out in /usr/src, and installed by make install DESTDIR=/mnt, works fine

[zeising]

@myfreeweb Can you check 4.16 as well?

[bzfbd]

I'll update this #13 if #14 passes into the tree; makes things a lot easier to modified and validate as #14 can be validated by 2 builds and diff that nothing changes.

[bzfbd]

Close in favour of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251415 now.