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

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

[Erik van Konijnenburg]

On Wed, Feb 23, 2005 at 10:50:44AM -0800, Andrew Vasquez wrote:
> On Tue, 22 Feb 2005, Erik van Konijnenburg wrote:
> > On Tue, Feb 22, 2005 at 11:03:58PM +0300, Roman Kagan wrote:
> > > On Tue, Feb 22, 2005 at 11:26:09AM -0800, Patrick Mansfield wrote:
> > > > On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:
> > > > 
> > > > > BTW one more item to track the dependencies for (in case you don't have
> > > > > enough :) is the firmware files.
> > > > 
> > > > Maybe we need in module.h:
> > > > 
> > > > #define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> > > > 
> > > > And use it for any module that can generate a call to request_firmware().
> > > > (Too bad we can't hook right into request_firmware(), since some callers
> > > > pass variables as the name.)
> > > 
> > > That's the problem here as well: you'll have to manually keep
> > > MODULE_FIRMWARE in sync with what you actually pass to
> > > request_firmware().
> > 
> > I haven't really looked at firmware yet, so the following may be 
> > off the mark, but:
> > 
> > - one approach would be MODULE_FIRMWARE, perhaps in the form of an array,
> > where every firmware file that's potentially interesting to the module is
> > listed.  This way you can build the leanest initrd images possible;
> > it will also fail to make us wildy popular with out-of-tree driver authors.
> 
> Actually, this particular subject is quite important for myself and
> QLogic as the qla2xxx FC-SCSI driver currently ships with embedded
> firmware images (drivers/scsi/qla2xxx).  One of the changes that we'd
> like to investigate is to strip-out the firmware images and use the
> request_firmware() interface exclusively.
> 
> > - another approach is to let mkinitrd/yaird note a dependency on firmware
> > class, and if present put *all* of firmware on the image.  Yaird would need
> > to support wildcards for that (put a whole tree on the image, not individual
> > files), but that's needed anyway to allow experiments with hotplug on the
> > image.  If the firmware directory is small, this may be good enough.
> 
> Seems like a reasonable start.

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.

- 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.

- 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.

- 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.

- 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.)

- 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.

Comments and corrections welcome.

Regards,
Erik




-------------------------------------------------------
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

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

[Patrick Mansfield]

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

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

[Erik van Konijnenburg]

On Fri, Feb 25, 2005 at 03:29:11PM -0800, Patrick Mansfield wrote:
> 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.

Correct.  However, if one of the modules needed to boot depends on
firmware_class, it's *possible* that the firmware is necessary to
boot.  Thus, to play it safe, you'll want the firmware on the image.

> > - 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?

I meant the reverse: if FW_LOADER=y, it's possible that firmware will
be needed to boot, so the firmware should be on the image.

> 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).

Yep.  However, command line options for the generator are a pain
for the sysadm who has to manage a farm of heterogeneous hardware.
To be avoided if at all possible.

> ...
> > - 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.

You're right, module.firmwaremap is easy to generate.  What worries me
about it is a migration issue: how is the initrd generator to know
whether every module has all relevant MODULE_FIRMWARE statements
added?

Consider the case where module A and B both need firmware C.  A has
MODULE_FIRMWARE, B does not, and B is included on the image.  The
initrd generator finds no indication firmware C should be included:
a non-booting image results.

This migration problem disappears when you add an annotation to the
firmware that indicates what devices it's needed for (Note the use of
devices rather than modules).

It also allows the initrd generator to be a bit more precise;
consider for instance Andrews proposed qla2xxx driver.  This would
load q12100_fw.bin .. q12322_fs.bin, depending on the hardware model.
With MODULE_FIRMWARE, all firmware files would be referenced by the
module, all firmware would need to go on the image.  With firmware
annotated with device type, only the the firmware that matches the
actual device would need to go on the image.

[ Note to self: annotating the firmware does not have to be done with
a wrapper around the firmware file.  It's much easier to have the
annotation for /lib/firmware/q12100_fw.bin in a separate file, eg
/lib/firmware_info/q12100_fw.bin.  This way firmware.agent does not
have to be modified.  The important thing is that the annotation is
related to the firmware, not to every module that may use it. ]

Anyway, in today's image generators, firmware is not supported at all.
Let's get back to these space optimisations after we've fixed that.

Regards,
Erik




-------------------------------------------------------
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

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

[Roman Kagan]

On Fri, Feb 25, 2005 at 04:18:21PM -0800, Andrew Vasquez wrote:
> Actually, the qla2[123]00.ko, qla2322.ko and qla6312.ko files only
> existed as 'firmware-loader' modules.  The core driver routines went
> into qla2xxx.ko.  My hope is that once the driver transitions to the
> request_firmware() interface, the firmware-loader modules get dropped
> and the we're left with a single qla2xxx.ko module which will
> request_firmware() the proper image type based on device-id:

This brings up another question: if the only difference between the
devices is the firmware image they need, and otherwise the driver can be
made generic (dunno if this is the case for qla2xxx, but I've seen a few
drivers like this), should the driver request_firmware() by
device-specific names, or should it rather request a generic name, and
the hotplug firmware agent would have to provide the correct image based
on device IDs available via sysfs or environment?

In other words, where should the knowledge about the matching between
the device IDs and the required firmware go into: the driver or the
firmware agent?

Roman.


-------------------------------------------------------
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

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

[Erik van Konijnenburg]

On Fri, Mar 04, 2005 at 02:16:47PM +0300, Roman Kagan wrote:
> On Fri, Feb 25, 2005 at 04:18:21PM -0800, Andrew Vasquez wrote:
> > Actually, the qla2[123]00.ko, qla2322.ko and qla6312.ko files only
> > existed as 'firmware-loader' modules.  The core driver routines went
> > into qla2xxx.ko.  My hope is that once the driver transitions to the
> > request_firmware() interface, the firmware-loader modules get dropped
> > and the we're left with a single qla2xxx.ko module which will
> > request_firmware() the proper image type based on device-id:
> 
> This brings up another question: if the only difference between the
> devices is the firmware image they need, and otherwise the driver can be
> made generic (dunno if this is the case for qla2xxx, but I've seen a few
> drivers like this), should the driver request_firmware() by
> device-specific names, or should it rather request a generic name, and
> the hotplug firmware agent would have to provide the correct image based
> on device IDs available via sysfs or environment?
> 
> In other words, where should the knowledge about the matching between
> the device IDs and the required firmware go into: the driver or the
> firmware agent?

For the initrd generator, it's more convenient to have the matching done
by the firmware agent.  It also seems elegant to select firmware using the
same kind of matching that we now do in modules.aliases.  Reasoning as follows:

"It's not the module that needs the firmware, but the device.  Annotate
the firmware with the devices it supports, and it becomes easy to
determine which firmware needs to go on the initrd image.  It also makes
for easier upgrades: when qla9999 starts shipping, just distribute the
firmware without need for a kernel upgrade."

Unfortunately there's a counter argument: the firmware also can expose
a kind of API to the driver module.   The current device matching
algorithms (fnmatch against modules.alias) do not make it possible
to express that the qla2xxx module needs version 3.04 or later of the
firmware.  Perhaps the request_firmware call should specify a device
id plus an API version?

Note that I'm writing from a limited perspective: just initrd.  Lets
see what the people who actually work with firmware think.

Regards,
Erik




-------------------------------------------------------
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