Re: firmware and initrd [was Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts]

[Patrick Mansfield <patmans@us.ibm.com>]

On Thu, Feb 24, 2005 at 10:43:43PM +0100, Erik van Konijnenburg wrote:

> Some thoughts on how this should work.
> 
> - The easy case is where everything is modular.  If there's a dependency
>   on firmware_class, bingo, we need firmware support.

But not necessarily in the initrd.

> - This does not cover the case where firmware_class or caller is
>   compiled into the kernel.  Note that if a caller is compiled in,
>   firmware_class must also be compiled in.  We track kernel defines;
>   bingo if CONFIG_FW_LOADER=y.

Do you mean if CONFIG_FW_LOADER=y, we don't support firmware loading in
initrd? Why not? Is driver init happening before initrd is ready?

There could be an option to the initrd generator to add firmware files, or
to behave as if driver X were built as a module (depending on if or how you
figure out firmware to driver mappings).

> - Firmware loading works as follows: the device driver invokes
>   request_firmware, which creates a new class in sysfs.  request_firmware
>   then calls hotplug with FIRMWARE set to the desired file, and waits
>   for hotplug to return.  Hotplug cats the requested firmware file to a
>   'data' file in /sysfs/class/firmware/...  and uses a 'loading' file
>   next to it to indicate when it's done.  Back in the kernel, the 'data'
>   and 'loading' files have callbacks that let the device driver upload
>   the firmware to the device.

Yes.

> 
> - Thus, any boot image that requires firmware also requires hotplug.
>   At the moment, Debian mkinitrd has no hotplug, and Fedora FC3 mkinitrd
>   has a limited version, which does udev but no hotplug.agent.
> 
> - Interpreting the modules to determine which particular firmware
>   file is needed (MODULE_FIRMWARE) is error prone: there are too many
>   opportunities for the driver author to come up with creative ways to
>   break the interpretation.

The driver writers/maintainers already have to specify the name of the
firmware file somewhere in the driver, it is not much more work to add a
matching MODULE_FIRMWARE. We can also have multiple MODULE_FIRMWARE lines
in one module.

> - On the other hand, it would be reliable and fairly simple to put a
>   wrapper around the firmware file and annotate it with the devices it
>   supports.  (For example, put it in mime/multi-part format with base64
>   encoding for the payload, plus some patterns in the header modeled
>   on modules.alias.  Or wrap it in XML and claim SOAP conformance.)

Or just add to some sort of modules.firmwaremap file? Then no wrappers
around the firmware files are needed, but the rpm or installer pieces need
changes. I still like a MODULE_FIRMWARE so such a file can be
auto-generated (or just dump modinfo output in the ya/mkinitrd).

Maybe under /lib/firmware (I don't know if that is appropriate). It would
only be used by the initrd generator.

For qlogic, we would have some lines like:

	qla2100.ko	ql2100_fw.bin	
	qla2200.ko	ql2100_fw.bin	
	qla2300.ko	ql2300_fw.bin	
	qla2300.ko	ql2322_fw.bin	

> - On the third hand, if a hardware vendor went to the trouble of
>   supporting such annotations, what he would achieve is a smaller boot
>   image for everybody *except* the people who actually bought his device.
>   I can't imagine it will be easy to find budget for such an exercise.

For qlogic, they have multiple devices, so it would help them out.

Andrew V: BTW, what are the sizes of qlogic firmware files?

-- Patrick Mansfield


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel