On 03/07/2015 02:56 AM, Ken Moffat wrote: > On Sat, Mar 07, 2015 at 02:18:36AM +0100, Armin K. wrote: >> >> 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). > > I think AMDKFD is for something new - I *assume* that there are > high-end cards already available (I think wikipedia knew the name > when I was looking at it a few days ago), but I saw a report > somewhere that it is different from radeon, so Sea Islands will be > the last generation of radeon GPUs.
amdkfd is a kernel part for their HSA architecture. http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/ The new GPU driver will be called amdgpu and will support newer generations of AMD GPU's and will be used by both catalyst and oss radeonsi drivers. Not really the last generation of radeon gpu's, but last generation of gpu's supported by Linux "radeon" driver. >> >> 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 >> > > That is interesting for two reasons - my only intel (at the moment) > is a low-end SandyBridge and when I last looked (probably a long > while ago) nothing got loaded. Maybe I was doing it wrongly. The > other reason it is interesting is that one of the kernel devs was > suggesting this week that early microcode loading was what ought to > be done in future (I don't have a link, and there have probably been > 2000+ posts on lkml this week). > >> 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. >> > > Yes, I suppose that CPU microcode fits better with LFS - and > eventually, LFS users might be dragged kicking and screaming into > using initramfs. But I think BLFS already covers the creation of an > initramfs, so let's keep it here for the moment. Without the > microcode, the machine will still boot, but it might do the wrong > things in some circumstances. Well, actually the firmware image is an initramfs on its own. If you need an actual initramfs for, as an example, lvm or mdadm, then you'll need to load two of them - the firmware image and an actual initramfs (yes, grub supports it). See how it's created: https://github.com/elkrejzi/system-management/blob/master/buildscripts/buildintel-ucode#L174 To build an initramfs that contains the ucode firmware, you need cpio (or bsdcpio) in LFS, and I don't think we want to do that given that microcode isn't something that's strictly required. >> 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. >> > > Let's start by waiting to see what people think. Everybody hates > being pulled into things, and we have a while before our next > release. If nobody comes out strongly against this, I'll raise a > ticket and we can discuss what will be best. And if they do, it > will have to start as a hint iff I lose the flamewar. > > For the radeon firmware (your follow-up post), I got mine from > people.freedesktop.org, at a page called airlied (I went via gentoo, > to check which blobs), and I thought I checked that the book pointed > there - but yes, Alex is the guy who works at ATI/AMD. > > ĸen > -- 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
