Items requiring solving for Debian support

[pbatard]

Just going to create an issue to gather all the items that require solving before we can propose Debian installation as a viable option:

Major showstoppers

• Linux kernel Genet ACPI bindings → Added to kernel 5.x and backported to the current Debian 11.0 kernel.
• SoC boot with base files (config.txt, start.elf, RPI_EFI.fd, etc.) residing in an ESP → Solved in Recognize efi partition (0xef) as a valid boot raspberrypi/rpi-eeprom#126 (may requires an EEPROM update for older models).
• UEFI boot should not freeze when no SD card is present → Needed since, with the latest EEPROM, the Pi 4 can boot directly to a GPT/ESP on a USB drive, which would allow copying the Debian 11 netinst ISO to an ESP on the target installation drive, along with the firmware files, and get through the whole installation process using one drive only. Tracked in Improve Arasan driver to fail gracefully when no card is present #37.
• Newer kernels need mdio-bcm-unimac.ko to connect to the network, but current Debian 11 netinst ISOs do not include it (Debian bug #985956)

Partial showstoppers

These can be worked around, but asking users to do so is less than ideal, as it will greatly degrade their experience during installation. Therefore classified as showstoppers.

• Console should properly default to graphical → Tracked in Debian installer uses serial console by default #64 and now in EDK2 bug 2831 → OH, FOR CRYING OUT LOUD!!! <sigh>
• Debian needs to remount /cdrom rw when it maps to an ESP. → Needed for the same reason as the above, as this is another hurdle for easy install through a single USB. Patch submitted as a Debian bug 967918. → FINALLY!!!
• Debian installer can't locate WiFi firmware blobs unless the USB is replugged. And it seems to choke on spaces, i.e. should request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt but truncates that to brcmfmac43455-sdio.Raspberry instead. Also, why the heck does Debian request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt alongside brcmfmac43455-sdio.txt?
• Even with the binary blobs and a (working?) kernel driver, WiFi doesn't seem to be able to connect to AP.

Would be nice to have

These are not considered showstoppers as, once a user manages to complete a Debian netinst installation, they will get kernel updates and therefore will naturally see these fixes integrated once they have been upstreamed and backported.

• Have the kernel support RAM above 3 GB → Tracked in Upstream Linux patch for _DMA constraints, to support booting with 4GB RAM #20
• Have the kernel support the SD controller → Tracked in Upstream Linux ACPI enablement for Arasan SDHCI #26
• Since we have started applying patches that EDK2 don't want, we might as well take care of the ACPI : Failed to parse MCFG error that Linux users get, as it's throwing them off.
• Have the kernel support vc4/5 modesetting and accelerated graphics

[ehem]

Added to kernel 5.x and backported to the current Debian 11.0 kernel.

Possible to get more specificity here? I suspect you're referring to Debian's linux-source-5.5 package (and presumably later versions)? Perhaps linux-source-5.6 (and later)?

I would place memory above 3GB as rather more than merely "nice to have". On a 4GB RP4, losing 25% of memory is a big hit, on a 8GB RP4 you're losing more than half of system memory. That is darn near a major show-stopper.

[pbatard]

Possible to get more specificity here?

The Genet driver (or more exactly the ACPI binding patches for Genet), which is included in recent 5.x mainline kernels was backported into the semi-custom 5.y kernel that Debian 11 uses. If you pick the latest Debian 11 pre-release ISO, you will find that it has Genet support.

I would place memory above 3GB as rather more than merely "nice to have".

Sorry but this is not a show stopper.

It does not prevent you from running or installing Linux, and, if you have Debian installed with networking, you will get this fixed automatically through system update. Therefore, not an actually problematic item.

[dony71]

does analog audio work?
i have add dtparam=audio=on in config.txt

[jlinton]

As of 5.10, the linux mcfg message has been reduced to pr_debug() which should make it less noticeable.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.10-rc4&id=d24e124577cdb47824c6665af16250807c2daa89

[pbatard]

Great. Thanks for looking after this!

[jlinton]

The edk2+linux-firmware pieces have landed, and the the ACPI enablement patch for linux is in -next. I would expect that will merge to mainline RSN, so it should now be a debian issue until 4.12 is picked up by debian.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/mmc/host/sdhci-iproc.c?h=next-20210222&id=4f9833d3ec8da34861cd0680b00c73e653877eb9

[meskilla]

does analog audio work?
i have add dtparam=audio=on in config.txt

snd-bcm2835 does not add the alsa compat sink necessary to use the headphone jack. This problem goes away with newer 4.elf & 4.dat broadcom blobs or with a newer bcm2711-rpi-4-b.dtb than what is at the moment supplied by the rpi4-uefi firmware. So the only way to have sound is get rid of the nice grub enviroment after installation and use the blobs directly :-( . Would be nice to see a fix of this issue: allow people to replace bcm2711-rpi-4-b.dtb and add start4x.dat/start4x.elf in order to enable vc4-fkms-v3d.dtbo

[Wyzard256]

I think the item for the SD controller can be marked as done here: #26 is closed, and I was able to successfully install and boot Debian 11 on an SD card using firmware 1.29.

[paulwratt]

"Console should properly default to graphical" has been resolved according to the EDK2 bug 2831 conclusion, and the resulting spec update that provides new variables.

This means we can now update the TianoCore EDK2 / EDK2-Platforms code to signal EFI_EVENT_GROUP_READY_TO_BOOT (and EFI_EVENT_GROUP_AFTER_READY_TO_BOOT when it gets implemented) on platform recovery path, similar to what is done on normal boot path.

#64 should be able to move forward now.

[paulwratt]

It appears the only items left of this "Debian FIXME" list are the WiFi Blob issues, and the "Nice to have" vc4/5 option.

Is it possible that the WiFi blob need DeviceTree to function?

Cant that filename convention (breaking on spaces) be verified on the Debian side? (what is used on the RPi3 version?)

Is vc4/5 a practical reality any time soon? (I doubt that, but I have also not researched it either)

[sharpenedblade]

Doesnt just need device tree, and there is a setting to enable devicetree. After that shouldnt it be just passing the .dtb file to the kernel.

[jlinton]

@hellosway The device tree support for the RPi4 wasn't the main focus area for this project. The idea was to create a single UEFI+ACPI firmware image that can boot a wide range of OSs rather than having ACPI for some of them and DT for others. Mostly because DT is not standard, and its not even well specified as the linux devs are constantly tweaking it, which is why there are a few dozen differing DT's for the base bcm2711 SoC floating around, with varying levels of support depending on the rpi foundations kernel, mainline, etc.

[sharpenedblade]

@hellosway The device tree support for the RPi4 wasn't the main focus area for this project. The idea was to create a single UEFI+ACPI firmware image that can boot a wide range of OSs rather than having ACPI for some of them and DT for others. Mostly because DT is not standard, and its not even well specified as the linux devs are constantly tweaking it, which is why there are a few dozen differing DT's for the base bcm2711 SoC floating around, with varying levels of support depending on the rpi foundations kernel, mainline, etc.

I understand that, but adding a dtoverlay to config.txt with vc4 doesnt pass it to linux when using this firmware. When using uboot, the devicetree is passed to the kernel properly

[sharpenedblade]

If devicetree or ACPI+devicetree is enabled for system table selection vc4 is working.

[jlinton]

I have a fix for the DT PCIe issue, which shows up on the more recent SoC revisions as well. (basically updating more of the DT with the programming edk2 is doing, rather than expecting it to be able to reset the bridge windows).

[jayaddison]

Debian installer can't locate WiFi firmware blobs unless the USB is replugged. And it seems to choke on spaces, i.e. should request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt but truncates that to brcmfmac43455-sdio.Raspberry instead. Also, why the heck does Debian request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt alongside brcmfmac43455-sdio.txt?

It seems like that problem is something to do with the (default?) setting of ACPI found in Device Manager : Raspberry Pi Configuration : Advanced Configuration : System Table Selection. When I change that to Devicetree, the correct firmware filenames are requested by the kernel module.

Some notes from investigating that on the Debian bugtracker:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035392#25

(another, possibly slightly inaccurate, way I'd attempt to describe this: the brcmfmac driver attempts to match a devicetree entry for detected hardware, and has a fallback that uses DMI. As an ARM-based system, the RPi doesn't really have DMI, so my best guess is that the ACPI interface provided by EDK2 provides enough for Linux to read from as a fallback.. but not an ideal fallback, in this case)

[jlinton]

Well, I don't know what happens WRT DT in that particular case, but this has been a debian specific issue AFAIK because its not symlinking/providing the firmware. AKA the wifi has been working for a couple years with fedora and ACPI (and DT too, although I rarely test it).

And yes this platform provides DMI, you can verify it with dmidecode or 'lscpu` or various other utilities.

Also note: the linux-firmware links the DMI string for the wifi firmware on this platform.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE#n2708

[jayaddison]

Thanks, @jlinton - I wasn't aware of the WHENCE file and the copy-firmware.sh scripting to create symlinks from it (I had been considering linux-firmware.git as basically version control over a set of static files, although now I understand that there are buildsystem components, such as the Makefile).

I've likely raised some unnecessary noise within Debian as a result, since I felt that the behaviour of the brcmfmac driver (to probe for filenames containing spaces) was odd and out-of-sync with linux-firmware.git (apparently not, though). I'll follow-up there with some explanatory notes and a reference to this discussion.

That said: while I understand that ACPI and Devicetree each have their own heritage, it seems like it could be simpler for most people involved if the requested firmware filename for each device could be the same regardless of the deviceinfo context (apologies: this isn't my area of expertise, quite obviously, so my terminology may be quite inaccurate).

[jayaddison]

Thanks, @jlinton - I wasn't aware of the WHENCE file and the copy-firmware.sh scripting to create symlinks from it (I had been considering linux-firmware.git as basically version control over a set of static files, although now I understand that there are buildsystem components, such as the Makefile).

I've opened a potential fix to handle the spaces-in-filenames problem for the RPi firmware files at: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65 (tracked against Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029843)

[jayaddison]

• Debian installer can't locate WiFi firmware blobs unless the USB is replugged. And it seems to choke on spaces, i.e. should request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt but truncates that to brcmfmac43455-sdio.Raspberry instead. Also, why the heck does Debian request brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt alongside brcmfmac43455-sdio.txt?

There's been some progress here - thanks to Salsa merge request firmware-non-free#94, filenames with spaces are included in the Debian firmware-brcm80211 package in trixie:

$ apt-file list firmware-brcm80211 | grep -i raspberry.*4
firmware-brcm80211: /usr/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt
firmware-brcm80211: /usr/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi Compute Module 4.txt
firmware-brcm80211: /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-compute-module.txt
firmware-brcm80211: /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt

As a recap: filenames-with-spaces are requested when the system is configured to use ACPI, and filenames-without-spaces imply that the system is using DeviceTree.

However, there is at least one remaining problem: I doubt that the Debian installer (specifically, the hw-detect component) detects this firmware as required during the install process.

I think the fix may be as simple as an edit to a regex in check-missing-firmware.sh -- the firmware: failed to load ([^ ]+) part in particular won't match filenames with spaces. But the format of that log message is well-defined in Debian (it originates from a line in Debian's linux package patch firmware_loader-log-direct-loading-failures-as-info-for-d-i.path). That would require testing, though.

[jayaddison]

I think the fix may be as simple as an edit to a regex in check-missing-firmware.sh -- the firmware: failed to load ([^ ]+) part in particular won't match filenames with spaces. But the format of that log message is well-defined in Debian (it originates from a line in Debian's linux package patch firmware_loader-log-direct-loading-failures-as-info-for-d-i.path). That would require testing, though.

FWIW: it turns out that a fix would not be as simple as that; in particular, spaces are relied upon as delimiter/separator characters elsewhere in the same script, so the addition of filenames containing spaces would cause problems.

Edit: remove unintentionally included context.