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
