Dear Maintainer,

I'm still unable to use a Debian kernel for my Rasebrry Pi 4 as this package
doesn't have support for Pi4 :

Setting up raspi-firmware (1.20190925-1) ...
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package raspi-firmware (--configure):
 installed raspi-firmware package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 raspi-firmware
E: Sub-process /usr/bin/dpkg returned an error code (1)

Also note that Pi4 is able to boot from an ext4 partition and don't need /boo/firmware.

(Bug report done from an Intel machine)

Christian

Hello,

As far as I understand, the CPU in the RPi4 is a *completely*
different beast from the ones in the rest of the family. It seems it
will not require a binary firmware loader anymore!

Right now, it is not *yet* bootable using the stock Linux kernel, but
there are people working on its support. I have asked them to update
this bug when our kernel can boot on RPi4.

Hi,

raspi-firmware now supports RPI4. (I could not find the exact version
where this was fixed, but at least it's fixed in the version above)

- Lucas

I'm not talking about files itself but how firmware are installed under
Debian.

With a rpi4 we don't need a /boot/firmware partition in vfat format as
rpi4 are able to boot from ext4.

Here is the original bug report :

,----
| >> Setting up raspi-firmware (1.20190925-1) ...
| >> Error: missing /boot/firmware, did you forget to mount it?
| >> dpkg: error processing package raspi-firmware (--configure):
| >>  installed raspi-firmware package post-installation script subprocess returned error exit status 1
| >> Errors were encountered while processing:
| >>  raspi-firmware
| >> E: Sub-process /usr/bin/dpkg returned an error code (1)
| >>
| >> Also note that Pi4 is able to boot from an ext4 partition and don't need /boo/firmware.
`----

Christian

retitle 948712 raspi-firmware: no need for /boot/firmware in vfat with RPI4 (ext4 is supported)
thanks

Hi Christian,

OK, I'm retitling the bug to clarify that it's not about RPI4 support
per se, but rather not using /boot/firmware, since the RPI4 can boot
from ext4.

Lucas

On 30 juil. 2020 12:36, Lucas Nussbaum <lucas@debian.org> wrote:


[...]

Thanks.

Christian

Hi,

As Lucas mentioned, this bug addresses two separate bits: Being able
to boot on RPi4 systems, and needing a separate FAT partition.

As to the first part, it's done (I'm tagging this using a RPi4), and
I'm specifying the first version we had that was able to boot in RPi4.

As to the second part, this package is meant to work on all RPi
models. We _could_, yes, bend around to stop requiring a
/boot/firmware/ FAT partition, but I don't see it as much of a problem
point, and don't plan on introducing changes that would make it more
painful to work on earlier models.

If there's a specific use case for which you need *not* to have a FAT
/boot/firmware partition, please reopen the bug!

reopen 948712
quit

There should be a rather obvious use case where absent /boot/firmware is
quite appropriate.  For someone needing a copy of the firmware, but using
other tools to build the boot area.

Notably one might use raspi-firmware to retrieve start*.elf/fixup*.dat.
Then add u-boot-rpi for second stage bootloader.  Next grub-efi-arm* for
third stage.  Lastly flash-kernel to glue all the pieces together.

Not one of these requires the existance of /boot/firmware.  In fact, not
one of these needs the installation of dosfstools.

Perhaps the raspi-firmware package should be split into pieces so as to
allow merely installing the actually required portions?

(raspi-firmware-bin which depends upon: raspi1-firmware-bin,
raspi2-firmware-bin, raspi3-firmware-bin, and raspi4-firmware-bin?)

Pinebook Pro also wants this firmware, and it's definitely not a raspi,
and it doesn't have /boot/firmware either.


Meow!

Is this about the /lib/firmware/brcm/brcmfmac434* files?

IMO, that group of files shouldn't be part of this package, but be moved to
another firmware package, perhaps firmware-brcm80211?

Yeah, that.

The idea of moving these files to another package seems good; steev proposed
firmware-linux, firmware-brcm80211 would be a more specific fit.
Both packages are maintained by debian-kernel@l.d.o, could you folks
comment please?


Meow!

Hi,

In the FWIW catagory, I'm following this thread beacuse
installed Debian (11) on an RPI4B using the Debian installer.
Following the instructions:

https://wiki.debian.org/RaspberryPi4?action=show&redirect=InstallingDebianOn%2FRaspberryPi%2FRaspberry+Pi+4#Using_EFI_Firmware_and_the_regular_Debian_Installer

and following the link to:

https://forums.raspberrypi.com/viewtopic.php?t=282839


What I found, I think, was that /boot/firmware does not then exist on
the resulting system.  I _believe_ I solved the issue by creating a
symlink.  (Maybe to /boot/UEFI/firmware/ ??)

All this was some time ago and I will have to (eventually)
go back and look at my notes and report back.  (I'd put off
reporting anything until I'd figured out something that worked.
By then I'd forgotten about this thread and was just reminded
by the recent emails.)

I'm not even 100% certain that the rpi firmware package
is relevant.  But I think so, to get wireless working.

Here's hoping that this is useful feedback and not noise.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

So long as those files are in linux-firmware.git, it should be fine to
ship them in firmware-brcm80211.  If they aren't, they should be added
there first.

Ben.

https://github.com/raspberrypi/linux/issues/4723 seems relevant.
I didn't dive into it too much, but AFAICT you need to convince the RPi folks
to upstream those files.
Good luck with that!

Dear maintainer,

using a simple modification of two postinst scripts, it it easily possible to avoid unnecessary grief for users of the Pinebook Pro and possibly other PINE64 devices.

The proposed modification consists of an additional check to verify if the platfom actually is an RPI before raising an error condition just because /boot/firmware is not a mount point.

On Pinebook Pro and some other PINE64 devices, /boot/firmware is usually just a subdirectory and there is no need to complicate things by insisting it to be a mount point.

See attached diffs for how this was resolved for our own use.

Best regards,
Paul Seelig

Paul Seelig <wmlive@users.sf.net> (2025-12-12):

We support much more than just the Pi 4 family. You seem to have
borrowed from a function that matches the Pi 4 family specifically
because of cma-related requirements (having it or not having it on the
kernel cmdline).

Why are you deploying *raspi*-firmware on PINE devices in the first
place?


Cheers,

Paul Seelig <pseelig@rumbero.org> (2025-12-13):

Yes, I understood what was meant (reusing something), but that I'm
saying that particular function is not appropriate for the purpose
you're aiming for. (Spotting Pi family 4 versus detection a Pi,
respectively.)

Yes, having someone who steps us and tackles the split of those files
from the current raspi-firmware package (regardless of the destination
package) is the proper way to address the issue.

My mind is not made up regarding whether the mountpoint thing is
something that should remain (whether it's restricted to Pi or not), but
changing this only hides the actual problem longer, and that makes the
whole situation even worse in my book.

Again, the submitted patch does not actually do that.


Cheers,

Thanks for your feedback, Cyril!
Just reusing the very same function that was already defined by the
package maintainer in debian/kernel/postinst.d/z50-raspi-firmware and
trying to avoid that pointless (for a PINE64 device) error condition.
A cursory read of the full thread
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948712 should easily
make this clearer.

The very same issue applies for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064072, where a
Pine64 RockPro64 is affected. A closely related bug was filed via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999485 for the
firmware-brcm80211 package.

The raspi-firmware package contains the /lib/firmware/brcm/brcmfmac434*
blobs that are required to use the Wifi capabilities of some PINE64
devices, including the Pinebook Pro. These files would probably be
better positioned as part of the firmware-brcm80211 or other firmware
package, but there appear to be some reasons that impedes this so far.

Those using a Pinebook Pro are basically "condemned" to use the
raspi-firmware package for this blob component if we won't proper
network connectivity in Debian. And since the raspi-fimrware package is
designed with mostly RPI's in mind, these unfortunate postinst error
conditions arise if used outside of the intended scope.

Discerning RPI's in the postinst scripts from other ARM devices that use
the included firmware in different ways would very much help its wider
user base.

Thanks!
Paul