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