[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035392: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

Mystery may be (partially) solved.  Responses inline below.

On Wed, 3 May 2023 at 15:17, Diederik de Haas <didi.debian@cknow.org> wrote:
> On Wednesday, 3 May 2023 03:41:05 CEST James Addison wrote:
> > I think that the vendor name is coming from a DMI fallback:
> > ...
> > https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7
> AFAIK the most important thing is the "compatible" string.
> Next to "DMI" there was also mention of "OF", which stand for Open Firmware
> which is (essentially?) the same as Device Tree
> ...
> I'd double check whether you actually see that line in your own dmesg output,
> before spending time to find some logic in that name.

Agreed.  The 'compatible' string is what seems intended for inclusion
into the fw filename request - by the driver authors,
linux-firmware.git, ourselves, and the RPi operating system.

After editing and rebuilding the Device Tree (DTS) files, and
deploying those changes to the system, I can confirm that adjusting
the 'model' field value in there has no effect on the requested fw

The system's dmesg includes this line:

  DMI: Raspberry Pi Foundation Raspberry Pi 400/Raspberry Pi 400, BIOS
UEFI Firmware v1.34 1 2/16/2022

As Cyril said though.. this can't (shouldn't) be genuine DMI.  So
what's going on?

It seems that the cause may be this:

The default settings within the EDK2 UEFI, under "Device Manager" ->
"Raspberry Pi Configuration" -> "Advanced Configuration" contained a
key labeled "System Table Selection" that was set to "ACPI".  Changing
that value to "Devicetree" and then booting caused the correct,
expected fw filename to be requested:

  firmware: failed to load brcm/brcmfmac43456-sdio.raspberrypi,400.bin (-2)

> Probably my fault, but I don't think it's relevant "what we agree to".
> We need to use what the kernel uses of which I suspect there's a (strong)
> correlation with what's used in the linux-firmware upstream repo.

Agreed here too - we can (and should) only make adjustments that are
acceptable and compatible for adjacent components.  I think we're
aligned with upstream here, it's simply that some other component --
and at the moment, that appears to me to be the EDK2 UEFI -- is
producing an unusual effect.


Reply to: