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
Reply to: