Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems

[Cyril Brulebois]

Hi,

I added a note[1] on the rpi4-uefi.dev GitHub repository, and from
one of your fellow contributors' responses, it seems that in fact
the filename-with-spaces format _is_ referenced from
linux-firmware.git, in a 'WHENCE' file that is used to create
symlinks (I hadn't been aware of that previously).

And that makes it a firmware-brcm80211 issue and now it all does make
sense as it now all does tie together :-)

Great, that's what it looked like to me but I was afraid I could have
misunderstood the situation and I didn't want to digress in a wrong
direction


So while upstream does define the link from what I earlier called
'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian
firmware-brcm80211 package does not define that link and is therefor
missing.

Adding the links will at least make those paths shows up in the
Contents-firmware indices generated by debian-cd. Those contain 3
“columns”: path, package, component (the current format string is
"%-55s %s %s\n").

Even if hw-detect didn't misbehave because of spaces in filenames (i.e.
the way the list of missing files is constructed, which I've been
assuming is one of the main issue here, but I didn't dive into it
because that's not getting rewritten for Bookworm anyway)
 it wouldn't
be able to perform the required lookup, given how it extracts those
“columns” from those indices.

(Looking at regular Contents file again, I see there's nothing done
specifically — like some kind of escaping — for paths like
“/etc/testssl/DST Root CA X3.txt” in the testssl.sh package; so I guess
it wouldn't be crazy to just change nothing in debian-cd, and have
hw-detect deal with spotting package and component at the end of the
line, reading the whole beginning as a path; of course, if someone goes
as far as including spaces at the end of some firmware filename, we'll
have to just change the format
 Cc-ing debian-cd@ for information.)

Anyway, you know how stupidly pragmatic I can be


For Bookworm, given we expect the firmware package to be adjusted to
include those symlinks, what if hw-detect had some little cheatsheet,
turning the space-powered filenames into their normal counterparts right
off the bat (while going through the dmesg lines), so that hw-detect
would:
- not split those into smaller parts, therefore building a list of
paths correctly;
- additionally succeed in performing the firmware file to firmware
package (and component) lookup;
- deploy the relevant firmware package;


 while the linux kernel would ultimately request the space-powered
filenames again, this time finding the symlinks that the updated package
would ship, being happy, no longer complaining, and hw-detect would give
a green light and carry on.

Embedding a little symlinks → files mapping for one single package,
that's really not expected to change too much this close to the release

looks like (1) a very ugly kludge, granted; but also (2) a very small
price to pay to get immediate support for that particular way of booting
Pi devices, without waiting on any major, post-release rewrite.


If that looks fine to you, feel free to clone this against hw-detect
with the symlinks → files mapping. Cc-ing debian-boot@ for information
as well.


Cheers,

[Diederik de Haas]

Control: block -1 1035505

Post by Cyril Brulebois

And that makes it a firmware-brcm80211 issue and now it all does make
sense as it now all does tie together :-)

Great, that's what it looked like to me but I was afraid I could have
misunderstood the situation and I didn't want to digress in a wrong
direction


So while upstream does define the link from what I earlier called
'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian
firmware-brcm80211 package does not define that link and is therefor
missing.

Adding the links will at least make those paths shows up in the
Contents-firmware indices generated by debian-cd. Those contain 3
“columns”: path, package, component (the current format string is
"%-55s %s %s\n").

Assuming the '55' stands for max 55 chars, that could be an issue?

Post by Cyril Brulebois
Even if hw-detect didn't misbehave because of spaces in filenames (i.e.

It turns out that spaces (and or backslashes to escape them) seems to be an
issue for the Debian scripts used to make the Debian firmware-nonfree packages
too. See https://bugs.debian.org/1035505 for details.
Once that is fixed, I can submit my MR to add those missing symlinks.

Post by Cyril Brulebois
For Bookworm, given we expect the firmware package to be adjusted to
include those symlinks, what if hw-detect had some little cheatsheet,

Seems doable. I'm not going to spend time trying to make that though.
I know virtually nothing about d-i/hw-detect internals, so it seems very
unwise for me to even try it.
Given the (specific) subject at hand, you won't be surprised that there's also
a motivational issue ;-)

Cheers,
Diederik

[Cyril Brulebois]

Hi,

Post by Diederik de Haas
Assuming the '55' stands for max 55 chars, that could be an issue?

That's not how format strings work. :)

That happily overflows:

$ printf "%-10s and the rest of the line\n" kibi
kibi and the rest of the line

$ printf "%-10s and the rest of the line\n" "Diederik de Haas"
Diederik de Haas and the rest of the line

Post by Diederik de Haas
It turns out that spaces (and or backslashes to escape them) seems to
be an issue for the Debian scripts used to make the Debian
firmware-nonfree packages too. See https://bugs.debian.org/1035505 for
details. Once that is fixed, I can submit my MR to add those missing
symlinks.

Oh, d-i isn't the only one expecting non-crazy paths! :)

Post by Diederik de Haas
Seems doable. I'm not going to spend time trying to make that though.
I know virtually nothing about d-i/hw-detect internals, so it seems
very unwise for me to even try it.
Given the (specific) subject at hand, you won't be surprised that
there's also a motivational issue ;-)

I was merely writing it out so that it could be sanity-checked, I wasn't
suggesting you would be the one to implement that. (Instead, I was
implicitly volunteering myself
)


Cheers,