On 03/07/2015 01:43 AM, Ken Moffat wrote: > Now that we have some time before the next release, I would like to > question whether our treatment of firmware is adequate. > > In the old days, (most) firmware was in the kernel - and then the > licence police took exception to that (and some 'libre' > distributions deliberately omit it). Now, most firmware is in > linux-firmware, or its upstreams such as Dave Airlie's > freedesktop.org page. AFAICS, there are three main users of > external firmware: > > 1. radeon graphics cards, R300 through to Sea Islands [ and probably > the newer high-end stuff, amdkfd I think it is called in the kernel > - but for the moment that is barely in the kernel and has no Xorg > driver ]. The firmware for R200 and earlier is still in the kernel. > > For these, we cover it in the Xorg ATI video driver (with a link to > Dave Airlie's freedesktop page) under 'Kernel configuration for > additional firmware'. Please note that nowadays, the kernel default > for radeon DRM is with KMS (Kernel ModeSetting) enabled, and for > that the firmware is required when the text console tries to move to > a framebuffer. Either build it in (slightly quicker if there is a > lot of firmware, e.g. my Kaveri uses 9 blobs - building it in means I > can see the penguins just before they scroll out, but making it a > module and letting it load from /lib/firmware means I never get to > see them, and probably miss some of the message. > > 2. some wired network adaptors, particularly those using the R8169 > driver - these are different, the kernel complains if the desired > firmware is not found, but they appear to work. Oddly, if I build > the driver in, but point to /lib/firmware in the kernel's .config, > and put the required item there, it seems to find the firmware (i.e. > no message in dmesg). > > 3. wifi drivers. My netbook uses the brcm/bcm43xx*.fw files. > Without these, the wifi cannot be brought up [ that is definitely a > BLFS issue, arguably the other two could be seen as part of LFS ]. > > For all of these, the key thing is to point the kernel's > CONFIG_FIRMWARE_DIR to /lib/firmware instead of "firmware" > > At the moment, we only mention firmware under the Xorg ATI driver. > I would like to see it moved to a more general place, perhaps at the > end of chapter 3. If we had a firmware page there, it could also > cover CPU microcode - if anybody wants to cover that (last time I > looked, the latest intel and AMD microcode updates did not apply to > my CPUs). > > But maybe you are all using things which do not need extra firmware > :) > > ĸen >
Hi Ken, Thanks for bringing this up. I brought it up a long time ago too, and I wanted to write an initial instructions that could be included in LFS or BLFS but I forgot about it. Now that you've brought it up, I may be able to help. You mentioned 4 cases of where firmware may be needed and I happen to be the one who uses all the drivers you mentioned. I have hybrid graphics laptop with an Intel and Radeon GPU, which is branded as CAICOS (HD 6470M) and I need about 6 blobs for it. My network adapter is Realtek 8169 and it asks for a firmware file, but I didn't try removing it. I also have a Broadcom wireless, lspci identifies it as BCM4313 802.11bgn but it's actually a BCM4727 model. I used to use the brcmsmac driver, but switched to the proprietary driver due to power management and other issues with the in kernel one. Recently, I bought an USB dongle due to issues with proprietary driver and kernel 3.18 and later (which was fixed), but I'm happy with it. It's an Atheros AR9271 802.11n model and it too needs firmware. I build all of the mentioned drivers as modules so they can pick up the files from /lib/firmware. I used to build them all into kernel, but somewhere around kernel 3.15 radeon driver gave me issues when both intel and radeon drivers were built into kernel and radeon gets loaded first at boot. So, this is what my /lib/firmware looks like: # r8169 /lib/firmware/rtl_nic/rtl8105e-1.fw # atk9k_htc /lib/firmware/htc_9271.fw # brcmsmac /lib/firmware/brcm/bcm43xx_hdr-0.fw /lib/firmware/brcm/bcm43xx-0.fw # radeon /lib/firmware/radeon/BTC_rlc.bin /lib/firmware/radeon/CAICOS_me.bin /lib/firmware/radeon/SUMO_uvd.bin /lib/firmware/radeon/CAICOS_smc.bin /lib/firmware/radeon/CAICOS_pfp.bin /lib/firmware/radeon/CAICOS_mc.bin I have also included the AMDKFD driver in my 3.19 kernel, but I didn't notice it asking for any additional firmware. What I did notice is that my OpenCL setup broke and mpv using ffmpeg built with OpenCL support would hang trying to open the radeon device (but that's offtopic here, it might as well be related to Mesa itself). As for the microcode firmware, I too am an user of that. However, I used Archlinux instructions for that and they recently switched to "Early Microcode Loading", which means building the firmware as an initramfs and loading it before the kernel starts (on the first CPU only) due to issues on Haswell hardware. Mine is SandyBridge and it receives and update and turns pebs on as a direct result of that. It's worth noting that "Early Microcode Loading" requires the microcode module to be built in, while the classic one requires it to be built as module. This is what I see in my kernel: [ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.19.0-krejzi ([email protected]) (gcc version 4.9.2 (Krejzi 4.9.2) ) #1 SMP PREEMPT Tue Feb 24 05:26:52 CET 2015 and further down: [ 0.094496] CPU2 microcode updated early to revision 0x29, date = 2013-06-12 I am not sure how this would be handled in LFS. If I can help you with something, just let me know. I too would like a page in either LFS or BLFS about the firmware. -- Note: My last name is not Krejzi.
signature.asc
Description: OpenPGP digital signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
