build icon indicating copy to clipboard operation
build copied to clipboard

[Feature]: split armbian-firmware into smaller packages

Open leggewie opened this issue 5 months ago • 3 comments

What happened?

$ du -shx /lib/firmware/ ; du -shx /lib/firmware/qcom/
280M    /lib/firmware/
180M    /lib/firmware/qcom/

As you can see above, even the "minimal" armbian-firmware package is already close to a whopping 300 MB in installed size. More than two-thirds of that is from qcom firmware. It would be great to split the current package into armbian-firmware and armbian-firmware-qcom. Naming could be discussed.

Armbian as usual is cooking up its own magic when compiling its packages 👎

https://github.com/armbian/build/blob/main/lib/functions/artifacts/artifact-firmware.sh https://github.com/armbian/build/blob/main/lib/functions/compilation/packages/firmware-deb.sh

Maybe this would be a good time to do away with that and use straight debian tooling like dpkg-buildpackage and friends. But if not, simply splitting the big package into smaller ones would already be great.

How to reproduce?

$ du -shx /lib/firmware/ ; du -shx /lib/firmware/qcom/
280M    /lib/firmware/
180M    /lib/firmware/qcom/

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 24.04 Noble

Code of Conduct

  • [x] I agree to follow this project's Code of Conduct

leggewie avatar Aug 08 '25 05:08 leggewie

Jira ticket: AR-2727

github-actions[bot] avatar Aug 08 '25 05:08 github-actions[bot]

I will add here that I think a general discussion of what the goals/purpose of having armbian-firmware (and armbian-firmware-full).

From my perspective it has become a dumping ground for firmware. There is no record of why a particular firmware is installed in this package. I suspect there are a number of firmwares that are obsolete and no longer needed (ie. for boards that are no longer are supported), but how would anyone know?

I believe the purpose was to have a slimmed down firmware package (vs. the mainline firmware package) that supported the hardware found on boards we support. But with all the csc boards that may no longer make sense to include everything for every board we support or ever have supported.

Also there is a lot of confusion among users of Armbian around this topic too. So they go and purchase a USB wifi dongle that is supported by mainline linux and it doesn't work on Armbian because they on Armbian need to install armbian-firmware-full (which would have those other non-board specific firmwares). But how does a user know this?

Now we don't have to solve all of these issues, but if we are going to invest some effort in this area, at least some of the big picture items should be thought about (maybe there is some low hanging items that can easily be improved).

And it certainly seems the qcom stuff is an area for significant improvement.

SteeManMI avatar Aug 08 '25 14:08 SteeManMI

@SteeManMI good points

What are common usage scenarios where users might end up needing to install armbian-firmare-full (or upstream linux-firware)? You already mentioned USB WiFi dongles. Other scenarios? The tradeoffs we need to balance here are installed size vs. user convenience.

As such, I guess we need to go through the biggest directories and files and inspect "git log" to figure out why a file was added and possibly by who and when.

leggewie avatar Aug 10 '25 10:08 leggewie