[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

Hello all and sorry for pinging in late into this conversation.

First of all, as someone who noticed the original issue but never got around to properly report or investigate it, a big thanks go to the people here who have been devoting time and effort trying to get to the bottom of it, and offering good clues as to what's causing the issue.

On 2023.05.03 17:29, James Addison wrote:
   * Maybe there's a bug to report in the upstream Linux brcmfmac
driver here; are there better alternatives than DMI that it could use
to determine fallback filenames?  (again, I'm not sure, but can follow
up on that)

Note that, in case you think there may be something that we can improve in the SMBIOS data reported by the UEFI firmware (which is currently generated from the source code at [1], with the full output from a Raspberry Pi 4, from UEFI Shell's smbiosview command at [2]) we can look into updating the UEFI firmware to alter the data we output.

   * Perhaps Devicetree is a better default in EDK2 for ARM systems?
(that wouldn't solve the root cause, though)

Please note that the reason why the Raspberry Pi UEFI firmware defaults to ACPI is so that this ARM device follows the relatively new ARM SBBR standard [3], which we (hopefully) expect more and more ARM64 based device to follow.

Obviously, with the idea of not having ARM based device that are constrained to a single OS (be it Windows, Linux, BSD or something else), and considering that Windows and Device Tree don't work together, you want to go with a mode of operation that isn't Linux specific, which, even if ACPI has its drawbacks, pretty much forces the use of ACPI over Device Tree. Else, you have Linux going into the exact Microsoft strong-arm tactics that it should strive to avoid...

   * Alternatively, if EDK2/RPI4-UEFI became Debian-packaged (excluding
the brcm firmware, because that's already in raspi-firmware), _and_
could be installed on the ESP partition by d-i (it's beyond my
experience to say whether that's a good idea...), then perhaps it
could be preconfigured (or d-i could request) Devicetree at

Well, if you package the UEFI firmware with Debian, I guess you can do whatever you want. You may however run into (a very limited number of) folks who might try to dual boot between Debian and Windows on Pi, just like you run into folks who may want to dual boot between Debian and Windows on x86 based PC... though I have to concede that, considering that, with Windows on Pi becoming a headache ever since Microsoft made Windows 11 22H2 incompatible with the ARM revision used in the Pi 4, and most of the dual boot crowd expected to be using separate devices, each with their own UEFI firmware (since the UEFI firmware is not actually written into SPI but resides on a removable device), it's probably something that's unlikely to be a big deal.

So I guess I can only mention my *preference* of having Debian striving to fix the issue with ACPI, rather than work around it by switching to Device Tree, knowing, once again, that if it boils down to something that we can alter in the SMBIOS data (and that passes the SMBIOS compliance tests, which are themselves part of SBBR compliance), we should be able to work out something in the UEFI firmware if needed.



[1] https://github.com/tianocore/edk2-platforms/blob/20e07099d8f11889d101dd710ca85001be20e179/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
[2] https://pastebin.com/3vLr1ZVJ
[3] https://community.arm.com/arm-community-blogs/b/internet-of-things-blog/posts/arm-server-standards-part-2-sbbr-specification-released

Reply to: