Re: File conflicts between alsa-firmware and kernel-firmware
On Tue, 3 Mar 2009 16:07:38 -0500 Jarod Wilson ja...@redhat.com wrote: - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? No clue... Would have to talk to some alsa folks. David Woodhouse is working on firmware packaging. He just did a new package: http://www.kernel.org/pub/linux/kernel/people/dwmw2/firmware/linux-firmware-20090319.tar.bz2 Tim, you might want to ask if he's going to put the ALSA firmware in there. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: File conflicts between alsa-firmware and kernel-firmware
On Saturday 28 February 2009 11:47:57 Tim Jackson wrote: I maintain alsa-firmware and the following bug regarding file conflicts between recent versions of kernel-firmware and alsa-firmware got raised today: https://bugzilla.redhat.com/show_bug.cgi?id=487873 I'm not really familiar with the kernel package maintenance, nor who/what governs what firmware goes into kernel-firmware (and indeed how that is related to the upstream kernel). I had a cursory look at the kernel spec in CVS but that didn't appear to have any relevant recent changes that were obvious. I did a diff between the firmware in alsa-firmware and in kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although there are some overlaps, much of the audio firmware in alsa-firmware isn't in kernel-firmware. The current conflicting files are: ess/* korg/* sb16/* yamaha/ds1_ctrl.fw yamaha/ds1_dsp.fw yamaha/ds1e_ctrl.fw Things that are in alsa-firmware but NOT in the above version of kernel-firmware are: asihpi/* digiface* 3g* ea/* emu/* mixart/* multiface* pcxhr/* vx/* yamaha/yss225_registers.bin [usx2y, which does something funky so it's not in /lib/firmware] Either way, it looks like we need to work together on this. - I'm happy to just drop the conflicting files from alsa-firmware - is that the right thing to do? I'd say yes. The versions shipped in the kernel are (supposed to be) known to work with the matching shipped kernel code. - Are the above audio firmware files in kernel-firmware there to stay? They're put into kernel-firmware as part of the kernel's firmware build process, so as long as they're part of the kernel, yeah, they'll be there. - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? No clue... Would have to talk to some alsa folks. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
File conflicts between alsa-firmware and kernel-firmware
I maintain alsa-firmware and the following bug regarding file conflicts between recent versions of kernel-firmware and alsa-firmware got raised today: https://bugzilla.redhat.com/show_bug.cgi?id=487873 I'm not really familiar with the kernel package maintenance, nor who/what governs what firmware goes into kernel-firmware (and indeed how that is related to the upstream kernel). I had a cursory look at the kernel spec in CVS but that didn't appear to have any relevant recent changes that were obvious. I did a diff between the firmware in alsa-firmware and in kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although there are some overlaps, much of the audio firmware in alsa-firmware isn't in kernel-firmware. The current conflicting files are: ess/* korg/* sb16/* yamaha/ds1_ctrl.fw yamaha/ds1_dsp.fw yamaha/ds1e_ctrl.fw Things that are in alsa-firmware but NOT in the above version of kernel-firmware are: asihpi/* digiface* 3g* ea/* emu/* mixart/* multiface* pcxhr/* vx/* yamaha/yss225_registers.bin [usx2y, which does something funky so it's not in /lib/firmware] Either way, it looks like we need to work together on this. - I'm happy to just drop the conflicting files from alsa-firmware - is that the right thing to do? - Are the above audio firmware files in kernel-firmware there to stay? - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? Thanks Tim ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? steved. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote: On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? You bring up a pretty good point here Jarod, what happens with firmware for arch-specific drivers? The Makefile rules will have to be written in such a way that it gets built into the package despite the CONFIG_* symbol being unset on the build arch. r, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Kyle McMartin wrote: On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote: On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? You bring up a pretty good point here Jarod, what happens with firmware for arch-specific drivers? The Makefile rules will have to be written in such a way that it gets built into the package despite the CONFIG_* symbol being unset on the build arch. That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote: That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. Does this cover the case of firmware declared in Makefiles in subdirs that are obj-$(CONFIG_i) += subdir/? If so, cool, but I can't be arsed to check. cheers, kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Kyle McMartin wrote: On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote: That's what it does. It includes all firmware, even for drivers that don't get built. Look in firmware/Makefile and you'll see it builds lists named fw-shipped-y, fw-shipped-m and fw-shipped- then just merges them to create fw-shipped-all which it uses to build/install the firmware. Does this cover the case of firmware declared in Makefiles in subdirs that are obj-$(CONFIG_i) += subdir/? If so, cool, but I can't be arsed to check. It only does its thing for stuff in firmware/ Every firmware file needs to be moved there; some are not and they don't get into the package. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? Applied. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Steve Dickson wrote:
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the
same time. So this patch adds the --with firmware build option
which will allow kernel-firmware rpms to built with kernel rpms.
This patch also adds the --without vdso_install build option
which stop the VDSO binaries from being installed. This cuts
down the overall build time especially when you build over NFS
like I do..
Signed-Off-By: Steve Dickson [EMAIL PROTECTED]
With one small change we can still support --without firmware. That way
the default behavior can be overridden in either case. See below...
diff -up SPECS/kernel.spec.orig SPECS/kernel.spec
--- SPECS/kernel.spec.orig 2008-07-29 09:07:48.0 -0400
+++ SPECS/kernel.spec 2008-07-29 11:44:39.0 -0400
@@ -75,11 +75,13 @@ Summary: The Linux kernel
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# kernel-firmware
-%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
+%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
%define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper:
1}
+# Want to build a the vsdo directories installed
+%define with_vdso_install %{?_without_vdso_install: 0}
%{?!_without_vdso_install: 1}
# don't build the kernel-doc package
%define with_doc 0
@@ -188,8 +190,10 @@ Summary: The Linux kernel
%define all_x86 i386 i586 i686
+%if %{with_vdso_install}
# These arches install vdso/ directories.
%define vdso_arches %{all_x86} x86_64 ppc ppc64
+%endif
# Overrides for generic default options
@@ -217,7 +221,6 @@ Summary: The Linux kernel
# only package docs noarch
%ifnarch noarch
%define with_doc 0
-%define with_firmware 0
%endif
# no need to build headers again for these arches,
@@ -231,6 +234,7 @@ Summary: The Linux kernel
%define with_up 0
%define with_headers 0
%define all_arch_configs kernel-%{version}-*.config
+%define with_firmware 1
+%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
%endif
# bootwrapper is only on ppc
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] kernel.spec: adding --with firmware --without vdso_install build options
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the
same time. So this patch adds the --with firmware build option
which will allow kernel-firmware rpms to built with kernel rpms.
This patch also adds the --without vdso_install build option
which stop the VDSO binaries from being installed. This cuts
down the overall build time especially when you build over NFS
like I do..
Signed-Off-By: Steve Dickson [EMAIL PROTECTED]
diff -up SPECS/kernel.spec.orig SPECS/kernel.spec
--- SPECS/kernel.spec.orig 2008-07-29 09:07:48.0 -0400
+++ SPECS/kernel.spec 2008-07-29 11:44:39.0 -0400
@@ -75,11 +75,13 @@ Summary: The Linux kernel
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# kernel-firmware
-%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
+%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
%define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper:
1}
+# Want to build a the vsdo directories installed
+%define with_vdso_install %{?_without_vdso_install: 0}
%{?!_without_vdso_install: 1}
# don't build the kernel-doc package
%define with_doc 0
@@ -188,8 +190,10 @@ Summary: The Linux kernel
%define all_x86 i386 i586 i686
+%if %{with_vdso_install}
# These arches install vdso/ directories.
%define vdso_arches %{all_x86} x86_64 ppc ppc64
+%endif
# Overrides for generic default options
@@ -217,7 +221,6 @@ Summary: The Linux kernel
# only package docs noarch
%ifnarch noarch
%define with_doc 0
-%define with_firmware 0
%endif
# no need to build headers again for these arches,
@@ -231,6 +234,7 @@ Summary: The Linux kernel
%define with_up 0
%define with_headers 0
%define all_arch_configs kernel-%{version}-*.config
+%define with_firmware 1
%endif
# bootwrapper is only on ppc
___
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 11:04 +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. The patches have now hit Linus' tree, so I've committed the specfile parts too. As soon as we update to 2.6.26-git1, we'll get a separate kernel-firmware package which is required by the main kernel binary package. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Done. There are some firmwares which are under GPL, so even the Free Software or nothing! folks can have _some_ form of kernel-firmware package. I don't think there's a problem with requiring it. I'll leave it to Alex to submit for review a kernel-firmware-libre package which Provides: kernel-firmware and which actually builds the various firmware files from source :) Should the package own the /lib/firmware/ directory? Not done. 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. Done. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
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
Do recent kernels allow firmware to load at initrd time?
https://bugzilla.redhat.com/show_bug.cgi?id=329511 and https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to address failure of the kernel to load firmware in the initrd phase of system booting. I can confirm that the second (aic94xx) bug, although it results in a failure during boot, if followed by rmmod aic94xx and then modprobe aic94xx results in firmware being properly loaded and the system able to make use of disks attached to the controller. I can also state that the nash find command locates the proper firmware file within the initrd file system even though the kernel fails to locate it. This takes place on a x86_64 system with both kernel-2.6.23.1-49.fc8 and kernel-2.6.23.8-63.fc8 and mkinitrd-6.0.19-4.fc8 (I modified mkinitrd to include the nash find command.) My question is: is firmware loading working for anyone with recent Fedora kernels or is there some sort of bug in the kernel firmware routines exercised only by an initrd file system? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Qlogic firmware isn't in the FC7 kernel
Apparently the qlogic drivers don't have any firmware included in FC7, so nobody can actually use a qlogic adapter. Should we be patching the kernel like in FC6 or do we need a separate package? Or maybe the firmware goes in the kernel package? Peter says the support for Anaconda / mkinitrd to load the firmware is already written, so we could do it either way. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
