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
filename.
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.
Cheers,
James
Reply to: