On Mon, Mar 30, 2020 at 05:49:20PM -0400, Joshua Kinard wrote: > For some time now, I've been trying to maintain a patch that kludges the > external firmware loader and specific firmware blobs back into the kernel > for sys-kernel/mips-sources. This works fine up until 5.6, which seems to > have further changed the way that firmware is loaded that breaks my existing > patch in a not-so-obvious way. I am not terribly inclined to keep debugging > this, so I think it's time to throw in the towel and use external firmware > loading. > > This brings up the issue that frankly, sys-kernel/linux-firmware is overkill > for currently-supported MIPS targets. Speaking for just the SGI systems, > MIPS literally needs only 4 firmware blobs (1 is critical, 1 optional, the > other two are for the future): > - acenic/tg2.bin: optional for ACENIC/Tigon II PCI cards > - qlogic/1040.bin: required for QLA1040 on SGI IP27, IP30 > - qlogic/1280.bin: future use (maybe on SGI IP35?) > - qlogic/12160.bin: future use (maybe on SGI IP35?) The 1280 was crucial for SGI Visual Workstation 320, and also worked as an option on IP32's PCI64 slots (I used it on my O2 R12k).
Q1) What distfile would it use? If it's going to be just the same upstream giant 200+ MiB linux-firmware distfile, then you still have to get that copied in for the builds, and when you pin it, you're going to keep it on all Gentoo mirrors. If you're going to produce a stripped down distfile, how is that going to interact when you might need a firmware that isn't in the stripped down package (see further about conflicts). I have used other NICs in my MIPS gear when I still used it (which I admit was more than a decade ago now). > I wanted to see if there would be any problem with creating a > sys-kernel/mips-firmware package to contain, at least initially, these four > firmware files from the linux-firmware repo, and install them to either > /lib/firmware-mips or /usr/share/mips-firmware (thinking more the latter to > avoid polluting /lib any further). Q2) Do you intend to patch the kernel drivers/base/firmware_loader for these new paths, or what other way would you pass them? The firmware_class.path modparam takes only ONE path. If you don't patch it to add more paths, then I worry that you can't use the new paths you propose, and you have to have a blocker against sys-kernel/linux-firmware. > These four blobs have not seen updates in years, so I anticipate there being > only a single ebuild for sys-kernel/mips-firmware. It'll be versioned like > the virtual packages (mips-firmware-1, -2, -3, etc), rather than by > datestamp, as the only times a version bump happens is if the firmware blobs > ever change or we add/remove a blob. > > Thoughts/feedback? Can you clarify relative goals in this effort? - Avoid packaging effort? - Save root FS disk space (a limited resource on many MIPS systems) - Avoid having to build the very large sys-kernel/linux-firmware (even with savedconfig the download/build takes lots of space, starting with the 200+ MiB distfile). I think you SHOULD keep the datestamp method, and have the PV explicitly match the upstream linux tarballs. I'm not sure about if it should have it's own smaller distfile or not. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
