Firmware
Been playing with how I'd make the kernel package deal with the new
'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get
that until we start to build it from a separate srpm.
Other comments?
(the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git)
Index: config-generic
===
RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v
retrieving revision 1.109
diff -u -p -r1.109 config-generic
--- config-generic 4 Jun 2008 00:22:50 - 1.109
+++ config-generic 9 Jun 2008 09:59:12 -
@@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
-CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MAESTRO3=m
-CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MIRO=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
@@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
-CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set
#
# ALSA USB devices
@@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9V022=m
# MT9V022_PCA9536_SWITCH is not set
+CONFIG_BUILTIN_FIRMWARE=
+# CONFIG_USB_KAWETH_FIRMWARE is not set
+# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set
+# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set
+# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set
+# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set
+# CONFIG_USB_EMI62_FIRMWARE is not set
+# CONFIG_USB_EMI26_FIRMWARE is not set
+
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.679
diff -u -p -r1.679 kernel.spec
--- kernel.spec 7 Jun 2008 01:48:53 - 1.679
+++ kernel.spec 9 Jun 2008 09:59:13 -
@@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
+# kernel-firmware
+%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
@@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch
#Patch08: linux-2.6-compile-fix-gcc-43.patch
%if !%{nopatches}
+Patch5: linux-2.6-firmware.patch
Patch10: linux-2.6-hotfixes.patch
@@ -693,6 +696,14 @@ header files define structures and const
building most standard programs and are also needed for rebuilding the
glibc package.
+%package firmware
+Summary: Firmware files used by the Linux kernel
+Group: Development/System
+License: Redistributable
+%description firmware
+Kernel-firmware includes firmware files required for some devices to
+operate.
+
%package bootwrapper
Summary: Boot wrapper files for generating combined kernel + initrd images
Group: Development/System
@@ -992,6 +1003,7 @@ fi
%if !%{nopatches}
+ApplyPatch linux-2.6-firmware.patch
ApplyPatch linux-2.6-hotfixes.patch
# Roland's utrace ptrace replacement.
@@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i
rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h
%endif
+%if %{with_firmware}
+make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install
+%endif
+
%if %{with_bootwrapper}
make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install
WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper
WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts
%endif
@@ -1690,6 +1706,12 @@ fi
/usr/include/*
%endif
+%if %{with_firmware}
+%files firmware
+%defattr(-,root,root)
+/lib/firmware/*
+%endif
+
%if %{with_bootwrapper}
%files bootwrapper
%defattr(-,root,root)
--
dwmw2
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. Other comments? We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Yeah, seems the sanest thing to do at least initially, so people don't suddenly wind up with non-functional devices. Should the package own the /lib/firmware/ directory? Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of this could be done sans-udev in some particular case. Just requiring udev does sound like the way to go then. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jarod Wilson ([EMAIL PROTECTED]) said: Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. Well, it means you may end up including various firmwares on architectures where they're irrelevant. But as long as you're willing to take the installed space hit, it's not a huge deal. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote: Another issue that we never really solved was that we really need to have one firmware package per firmware (group) so that others can possibly override their firmware without replacing the entire kernel-firmware package and affecting everyone. Opinion? Later. We can't do it now, and it's not a loss. What we're doing makes it _easier_ to do that later, if we want to. But I don't want to try it now. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :) Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote: On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote: K. I guess I'm just raising it so we're aware of it. It's not exactly a loss, but my fear is that once we make it possible for someone else to replace all the kernel firmware just to update their buggy one, then they'll rush out and do this as soon as possible :) Better option might be another directory which appears first on udev's (and mkinitrd's) search patch. That way you can override firmware without having to split the package. And that of course is a nicer fix, yeah, then people can have their own per-device firmware package if they choose to do so. Coolness. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, Jun 09, 2008 at 03:15:05PM +0100, David Woodhouse wrote: On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote: On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. Is that something new upstream? It would be great to separate the firmware from the kernel builds. http://lwn.net/Articles/284104/ http://lwn.net/Articles/284932/ git.infradead.org/users/dwmw2/firmware-2.6.git Thanks for the links. The discussion was helpful. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Cheers, Don ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jarod Wilson wrote: We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. But of course, you've still got a system that at least boots, and can back-rev the firmware if needed, so not a big issue vs. boot-path-dependent firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? A stub kernel? Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk? We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that. Cheers, Don ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? Not sure. What happens in such cases today? Have to install a new kernel or kmod? A stub kernel? Ew. Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk? Could get messy, littering /boot with old initrds that aren't cleaned up, and your bootloader with extra entries you may never use -- what would trigger their removal and when? I just assume leave out the auto-rebuilding of the initrd though. I think if you know you need/want new firmware for a device, you should be able to figure out how to create a new initrd with it (and save the old initrd as a fallback). I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that. Yeah, I sent a follow-up email saying the same, didn't take that into account until after hitting send, and my unsend button never seems to work... :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
