search

pftf / RPi4

Raspberry Pi 4 UEFI Firmware Images
https://rpi4-uefi.dev
Other
1.21k stars 143 forks source link

Items requiring solving for Debian support #76

Open pbatard opened 4 years ago

pbatard commented 4 years ago

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

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.

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.

ehem commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

jlinton commented 4 years ago

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 commented 4 years ago

Great. Thanks for looking after this!

jlinton commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

"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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

jlinton commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 3 months ago
  • [ ] 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 commented 2 months ago

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.