Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Apr 2020 20:09:55 +0700
From:      Alexey Dokuchaev <danfe@nsu.ru>
To:        Niclas Zeising <zeising@freebsd.org>
Cc:        x11@freebsd.org
Subject:   Re: GPU firmware naming and problems with loading
Message-ID:  <20200421130955.GA8165@regency.nsu.ru>
In-Reply-To: <8990dbd6-65b7-81f4-e0c5-4541e34afee2@freebsd.org>
References:  <20200421090909.GB13384@regency.nsu.ru> <8990dbd6-65b7-81f4-e0c5-4541e34afee2@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <drmn> 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.

./danfe



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200421130955.GA8165>