From owner-freebsd-x11@freebsd.org Tue Apr 21 11:26:31 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FD312C8F95 for ; Tue, 21 Apr 2020 11:26:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4961VH3r1hz48qN for ; Tue, 21 Apr 2020 11:26:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 839AD2C8F94; Tue, 21 Apr 2020 11:26:31 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8358F2C8F93 for ; Tue, 21 Apr 2020 11:26:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4961VH1Q8Lz48qM for ; Tue, 21 Apr 2020 11:26:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4961VC508Kz3mCk; Tue, 21 Apr 2020 11:26:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id ssez34wW48vs; Tue, 21 Apr 2020 11:24:07 +0000 (UTC) Received: from garnet.daemonic.se (host-95-192-232-195.mobileonline.telia.com [95.192.232.195]) by mail.daemonic.se (Postfix) with ESMTPSA id 4961RV3jc1z3lbm; Tue, 21 Apr 2020 11:24:06 +0000 (UTC) Subject: Re: GPU firmware naming and problems with loading To: Alexey Dokuchaev , x11@freebsd.org References: <20200421090909.GB13384@regency.nsu.ru> From: Niclas Zeising Message-ID: <8990dbd6-65b7-81f4-e0c5-4541e34afee2@freebsd.org> Date: Tue, 21 Apr 2020 13:24:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200421090909.GB13384@regency.nsu.ru> Content-Type: multipart/mixed; boundary="------------55C6910B5155581F623CCC4E" Content-Language: en-US X-Rspamd-Queue-Id: 4961VH1Q8Lz48qM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; NEURAL_HAM_LONG(-0.99)[-0.987,0]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:26:31 -0000 This is a multi-part message in MIME format. --------------55C6910B5155581F623CCC4E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------55C6910B5155581F623CCC4E Content-Type: text/x-patch; charset=UTF-8; name="verbose.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="verbose.diff" commit 91721a9d1071f394da064936209ccc43311ab494 Author: Johannes Lundberg Date: Tue Mar 20 11:10:10 2018 +0000 lkpi: improve firmware load messages (cherry picked from commit d5e840a1679d975e3762658980a286ae9e05d550) diff --git a/linuxkpi/gplv2/src/linux_firmware.c b/linuxkpi/gplv2/src/linux_firmware.c index 68a4196df..e982886bf 100644 --- a/linuxkpi/gplv2/src/linux_firmware.c +++ b/linuxkpi/gplv2/src/linux_firmware.c @@ -27,12 +27,17 @@ request_firmware(const struct linux_firmware **lkfwp, const char *name, lkfw = malloc(sizeof(*lkfw), M_LKPI_FW, M_WAITOK); retries = 0; + device_printf(device->bsddev, "try to load firmware with " + "name: %s\n", name); fw = firmware_get(name); if (fw == NULL) { pause("fwwait", hz/2); + device_printf(device->bsddev, "retry to load firmware " + "with name: %s\n", name); fw = firmware_get(name); } - if (fw == NULL && ((index(name, '/') != NULL) || (index(name, '.') != NULL))) { + if (fw == NULL && + ((index(name, '/') != NULL) || (index(name, '.') != NULL))) { mapped_name = strdup(name, M_LKPI_FW); if (mapped_name == NULL) { rc = -ENOMEM; @@ -43,14 +48,22 @@ request_firmware(const struct linux_firmware **lkfwp, const char *name, while ((pindex = index(mapped_name, '.')) != NULL) *pindex = '_'; if (linker_reference_module(mapped_name, NULL, &result)) { - device_printf(device->bsddev, "failed to load firmware image %s\n", mapped_name); + device_printf(device->bsddev, "failed to link firmware " + "module with mapped name: %s\n", mapped_name); rc = -ENOENT; goto fail; } + device_printf(device->bsddev, "successfully linked firmware " + "module with mapped name: %s\n", mapped_name); retry: pause("fwwait", hz/4); + device_printf(device->bsddev, "try (%d) to load firmware " + "image with name: %s\n", retries, name); fw = firmware_get(name); if (fw == NULL) { + device_printf(device->bsddev, "try (%d) to load " + "firmware image with mapped name: %s\n", + retries, name); fw = firmware_get(mapped_name); if (fw == NULL) { if (retries++ < 10) @@ -64,13 +77,17 @@ request_firmware(const struct linux_firmware **lkfwp, const char *name, #endif } if (fw == NULL) { - device_printf(device->bsddev, "failed to load firmware image %s\n", name); + device_printf(device->bsddev, "failed to load firmware " + "image with name: %s\n", name); if (mapped_name) - device_printf(device->bsddev, "failed to load firmware image %s\n", mapped_name); + device_printf(device->bsddev, "failed to load firmware " + "image with mapped name: %s\n", mapped_name); rc = -ENOENT; goto fail; } + device_printf(device->bsddev, "successfully loaded firmware " + "image with name: %s\n", name); free(mapped_name, M_LKPI_FW); lkfw->priv = __DECONST(void *, fw); --------------55C6910B5155581F623CCC4E--