Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Wed, 3 May 2023 at 16:49, Cyril Brulebois <kibi@debian.org> wrote:
> James Addison <jay@jp-hosting.net> (2023-05-03):
> > 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.
>
> Did those modifications stay in place once you switched to Device Tree
> in your bootloader configuration? Just wondering whether you tested two
> cumulative changes (DTS tweaks + switch from ACPI), or independent ones
> (DTS tweaks, then switch from ACPI but using pristine DTB files).
That was tested cumulatively, yep - applied the DTS tweaks, found no
change, and then updated the UEFI setting from ACPI to Devicetree,
resulting in the expected fw requests.
Since then I've reverted the DTS tweaks, and the correct behaviour continues.
After that I reverted the UEFI setting back to ACPI briefly. I forget
what I was checking, but the problem reappeared, and now I'm back to
the expected behaviour (no spaces in the fw filenames) with the
Devicetree setting.
> I don't have any Pi 400 and haven't been following what the stock
> configuration is (and sorry I didn't read the whole backstory)… if EDF2
> UEFI comes by default, or is recommended, or fixes/works around bugs,
> and in the end is expected to be relevant and widely used, and if ACPI
> is indeed some kind of default setup, it would be best if we were to
> support that.
I'd defer to people with more familiarity of the ecosystem on these
kind of questions, although am also keen to learn more.
Some thoughts:
* 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)
* Perhaps Devicetree is a better default in EDK2 for ARM systems?
(that wouldn't solve the root cause, though)
* 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.
If & when attempting this again - it could be a while, this took some
energy - then I would probably experiment with u-boot as a comparison.
> I suppose that would mean either having the relevant files/symlinks in
> the firmware package *and* d-i support for it (hw-detect limitations…);
> or have some on-the-fly conversion in the Linux module so that it ends
> up requesting files that are actually in the firmware package, and that
> d-i can work with, without requiring any changes?
At the moment, I think that fixing this in the brcmfmac driver would
resolve the problem in a bootloader-agnostic way, so that seems worth
exploring.
Symlinks seem like they'd be a reasonable short-term workaround in our
packaging - but likely maintainer discretion on that one, as usual (if
that were me, it would help to know that it would be a temporary
measure while other problems were being resolved).
(sorry for what I think may be an overly-large reply list here - I'd
prefer that than to have anyone miss some hopefully-relevant details)
Reply to: