Items requiring solving for Debian support #76
Comments
pbatard
changed the title
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. |
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.
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. |
|
does analog audio work? |
|
As of 5.10, the linux mcfg message has been reduced to pr_debug() which should make it less noticeable. |
|
Great. Thanks for looking after this! |
|
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. |
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 |
|
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. |
|
"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.
#64 should be able to move forward now. |
|
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) |
|
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. |
|
@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 |
|
If |
* Move them to the actual location where Debian 11 may locate them (though d-i won't detect them unless you re-plug the media) * Also 'add brcmfmac43455-sdio.Raspberry' which should really be named 'brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt' but d-i's firmware locator also chokes on spaces... This appears to be a copy of 'brcmfmac43455-sdio.txt' that d-i insists on finding.
|
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). |
It seems like that problem is something to do with the (default?) setting of ACPI found in 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 |
|
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 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 |
|
Thanks, @jlinton - I wasn't aware of the I've likely raised some unnecessary noise within Debian as a result, since I felt that the behaviour of the 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). |
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) |
|
See issue #247 . |
|
I think the Wi-Fi problem is solved. I've been able to use Wi-Fi as the main installation method on my latest install. |
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
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).mdio-bcm-unimac.koto 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.
/cdromrwwhen 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!!!brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txtbut truncates that tobrcmfmac43455-sdio.Raspberryinstead. Also, why the heck does Debian requestbrcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txtalongsidebrcmfmac43455-sdio.txt?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.
ACPI : Failed to parse MCFGerror that Linux users get, as it's throwing them off.The text was updated successfully, but these errors were encountered: