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
install-time.
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.
Regards,
/Pete
[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
