Mystery may be (partially) solved. Responses inline below. On Wed, 3 May 2023 at 15:17, Diederik de Haas <didi.deb...@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
