Bug#494308: e100 firmware testing
On Thu, Oct 23, 2008 at 12:47:09AM +0100, Ben Hutchings wrote: On Wed, 2008-10-22 at 17:05 -0600, dann frazier wrote: hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. My changes to e100 in linux-2.6 are actually divided across 3 files under debian/patches, following what has been done for several other instances of sourceless firmware: 1. debian/dfsg/e100-disable.patch inserts #ifdef REMOVE_DFSG...#endif around the microcode and marks the driver as BROKEN in Kconfig. 2. debian/dfsg/files-1 uses unifdef to remove the microcode. 3. features/all/e100-request_firmware.patch removes the BROKEN mark and adds firmware loading using request_firmware. Each of the 11 other drivers is dealt with similarly, except that for most of them we can use rm instead of unifdef. The orig tarball has steps 1 and 2 already applied and step 3 is part of the normal build process. Ah - I somehow missed the step3 patch. Also, it turns out my controller (8086:1229) isn't one of the devices that gets fw loaded. The driver still works fine though, fwiw. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Right, I hadn't got that far yet. Ben. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494308: e100 firmware testing
hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Thanks! [1] http://people.debian.org/~benh/firmware-removal/ -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494308: e100 firmware testing
On Wed, 2008-10-22 at 17:05 -0600, dann frazier wrote: hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. My changes to e100 in linux-2.6 are actually divided across 3 files under debian/patches, following what has been done for several other instances of sourceless firmware: 1. debian/dfsg/e100-disable.patch inserts #ifdef REMOVE_DFSG...#endif around the microcode and marks the driver as BROKEN in Kconfig. 2. debian/dfsg/files-1 uses unifdef to remove the microcode. 3. features/all/e100-request_firmware.patch removes the BROKEN mark and adds firmware loading using request_firmware. Each of the 11 other drivers is dealt with similarly, except that for most of them we can use rm instead of unifdef. The orig tarball has steps 1 and 2 already applied and step 3 is part of the normal build process. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Right, I hadn't got that far yet. Ben. signature.asc Description: This is a digitally signed message part
