From owner-freebsd-x11@freebsd.org Thu Apr 23 20:44:49 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 078612C2DAB for ; Thu, 23 Apr 2020 20:44:49 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 497TnX64mXz4JxS for ; Thu, 23 Apr 2020 20:44:48 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CEB782C2DA9; Thu, 23 Apr 2020 20:44:48 +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 CE7642C2DA8 for ; Thu, 23 Apr 2020 20:44:48 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (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 497TnX2FpDz4JxR for ; Thu, 23 Apr 2020 20:44:48 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 497TnT5C5Nz3lbm; Thu, 23 Apr 2020 20:44:45 +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 Etz0c-Zfx0lv; Thu, 23 Apr 2020 20:42:23 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:e04e:ddd4:a034:2f8a]) by mail.daemonic.se (Postfix) with ESMTPSA id 497Tkl3gKpz3mDk; Thu, 23 Apr 2020 20:42:23 +0000 (UTC) Subject: Re: GPU firmware naming and problems with loading To: Alexey Dokuchaev Cc: x11@freebsd.org References: <20200421090909.GB13384@regency.nsu.ru> <8990dbd6-65b7-81f4-e0c5-4541e34afee2@freebsd.org> <20200421130955.GA8165@regency.nsu.ru> From: Niclas Zeising Message-ID: <749e8db2-8dd8-3ad8-dbee-332bb2a7742b@freebsd.org> Date: Thu, 23 Apr 2020 22:42:22 +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: <20200421130955.GA8165@regency.nsu.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 497TnX2FpDz4JxR 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.985,0]; NEURAL_HAM_LONG(-0.99)[-0.989,0]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, 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: Thu, 23 Apr 2020 20:44:49 -0000 On 2020-04-21 15:09, Alexey Dokuchaev wrote: > On Tue, Apr 21, 2020 at 01:24:05PM +0200, Niclas Zeising wrote: >> On 2020-04-21 11:09, Alexey Dokuchaev via freebsd-x11 wrote: >>> ... >>> 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? :-/ >> >> 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. > > *sigh* Classic example of Linux' development methodologies. Instead > of fixing the mess, they're trying to heuristically embrace it. :-) > >> Please test the patch and give the output, that way we should be able to >> see how far firmware loading goes. > > Thanks, I've applied and rebuilt. I've also applied EDID patch from > PR 245730 just in case. Here's more complete log, including what was > printed before "Loading ARUBA Microcode". Should I worry about those > lines marked with *'s? > > [drm] radeon kernel modesetting enabled. > drmn0: on vgapci0 > vgapci0: child drmn0 requested pci_enable_io > last message repeated 1 times > [drm] initializing kernel modesetting (ARUBA 0x1002:0x990D 0x103C:0x1992 0x00). > [drm] register mmio base: 0xD6000000 > [drm] register mmio size: 262144 > * [drm:radeon_device_init] Unable to find PCI I/O BAR > * [drm:radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO > ATOM BIOS: HP > drmn0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used) > drmn0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF > [drm] Detected VRAM RAM=768M, BAR=256M > [drm] RAM width 64bits DDR > [TTM] Zone kernel: Available graphics memory: 7958688 kiB > [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [TTM] Initializing pool allocator > [drm] radeon: 768M of VRAM memory ready > [drm] radeon: 1024M of GTT memory ready. > [drm] Loading ARUBA Microcode > drmn0: try to load firmware with name: radeon/ARUBA_pfp.bin > radeon/ARUBA_pfp.bin: could not load firmware image, error 2 > drmn0: retry to load firmware with name: radeon/ARUBA_pfp.bin > radeon/ARUBA_pfp.bin: could not load firmware image, error 2 > drmn0: successfully linked firmware module with mapped name: radeon_ARUBA_pfp_bin > drmn0: try (0) to load firmware image with name: radeon/ARUBA_pfp.bin > drmn0: successfully loaded firmware image with name: radeon/ARUBA_pfp.bin > drmn0: try to load firmware with name: radeon/ARUBA_me.bin > radeon/ARUBA_me.bin: could not load firmware image, error 2 > drmn0: retry to load firmware with name: radeon/ARUBA_me.bin > radeon/ARUBA_me.bin: could not load firmware image, error 2 > drmn0: successfully linked firmware module with mapped name: radeon_ARUBA_me_bin > drmn0: try (0) to load firmware image with name: radeon/ARUBA_me.bin > drmn0: successfully loaded firmware image with name: radeon/ARUBA_me.bin > drmn0: try to load firmware with name: radeon/ARUBA_rlc.bin > radeon/ARUBA_rlc.bin: could not load firmware image, error 2 > drmn0: retry to load firmware with name: radeon/ARUBA_rlc.bin > radeon/ARUBA_rlc.bin: could not load firmware image, error 2 > drmn0: successfully linked firmware module with mapped name: radeon_ARUBA_rlc_bin > drmn0: try (0) to load firmware image with name: radeon/ARUBA_rlc.bin > drmn0: successfully loaded firmware image with name: radeon/ARUBA_rlc.bin > [drm] Internal thermal controller without fan control > [drm] radeon: dpm initialized > drmn0: try to load firmware with name: radeon/TAHITI_uvd.bin > radeon/TAHITI_uvd.bin: could not load firmware image, error 2 > drmn0: retry to load firmware with name: radeon/TAHITI_uvd.bin > radeon/TAHITI_uvd.bin: could not load firmware image, error 2 > drmn0: successfully linked firmware module with mapped name: radeon_TAHITI_uvd_bin > drmn0: try (0) to load firmware image with name: radeon/TAHITI_uvd.bin > drmn0: successfully loaded firmware image with name: radeon/TAHITI_uvd.bin > drmn0: try to load firmware with name: radeon/TAHITI_vce.bin > radeon/TAHITI_vce.bin: could not load firmware image, error 2 > drmn0: retry to load firmware with name: radeon/TAHITI_vce.bin > radeon/TAHITI_vce.bin: could not load firmware image, error 2 > drmn0: successfully linked firmware module with mapped name: radeon_TAHITI_vce_bin > > Why is it trying to load TAHITI modules is another question. It was > always just three ARUBA modules AFAIR, all the way back to ca. 2017 > when X11 was fully working on this laptop. Just want you to know I haven't forgotten about this, just not had time to dig that much deeper. I don't know why it tries to load TAHITI, I'll try to figure more out, but in general, the firmware selection code is from the original source, so it should be the same elsewhere. Does TAHITI load with drm-legacy-kmod (the base version uses other firmwares, so you can't check with that one). If you have the opportunity, can you check which firmwares are loaded on a Linux system with the same hardware? Which firmware is loaded with drm-current-kmod (or drm-fbsd12.0-kmod) and drm-devel-kmod? Does it work if you remove the TAHITI modules before loading the graphics ko? Looks like it loads TAHITI ok though. Apologies for all the questions and none of the answers. Regards -- Niclas Zeising