firmware loading interface

firmware loading interface

[Philip Downer]

Hi,

I'm working for a company which is manufacturing a new pci card. The
details are probably irrelevant at this stage, but for those who might
be concerned the driver will be covered by the GPL and submitted
upstream at or before the launch of the card.

Currently I'm investigating how to provide firmware upgrades for the
card, and I've been looking at the request_firmware api. All of the
documentation (and mails that I've read from lkml archives) suggest that
request_firmware is for use with devices without firmware stored in
flash or eeprom, and to load it in to memory at initialisation of the
device.

However our device will have flash to store the firmware in and, whilst
it looks as though it would be possible for us to use request_firmware
to provide occasional firmware upgrades from userspace, I can't find any
reference as to whether this is an accepted method for doing so. Could
someone please confirm for me whether or not it's a good idea to use
request_firmware for this, or perhaps point me at another standard
method for doing firmware updates from userspace?

Please note that I am not subscribed to this mailing list, so could
anyone responding please CC me in their response.

Philip Downer

Re: firmware loading interface

[Arnd Bergmann]

On Friday 13 November 2009, Philip Downer wrote:
> However our device will have flash to store the firmware in and, whilst
> it looks as though it would be possible for us to use request_firmware
> to provide occasional firmware upgrades from userspace, I can't find any
> reference as to whether this is an accepted method for doing so. Could
> someone please confirm for me whether or not it's a good idea to use
> request_firmware for this, or perhaps point me at another standard
> method for doing firmware updates from userspace?

The idea of request_firmware is that it helps you load the firmware
into the device at initialization time so you can use it directly,
without making the firmware blob a part of the kernel driver.

If I understand you correctly, you never need a firmware in user space
in order to use the device, but only for flashing a new version into
the nonvolatile memory.

The easiest way to do that would be an ioctl operation, if you are
implementing a character or block device interface anyway. Just load
the firmware into the RAM of a user application and call an ioctl
with the pointer to the firmware as an argument, but don't use
a data structure with a pointer in it, which would mess up 32 bit
compatibility operation.

If you don't implement a character or block device, the chances are
that you need something else besides an ioctl, depending on how
an application would communicate with your hardware.

	Arnd <><

Re: firmware loading interface

[Roland Dreier]

 > However our device will have flash to store the firmware in and, whilst
 > it looks as though it would be possible for us to use request_firmware
 > to provide occasional firmware upgrades from userspace, I can't find any
 > reference as to whether this is an accepted method for doing so. Could
 > someone please confirm for me whether or not it's a good idea to use
 > request_firmware for this, or perhaps point me at another standard
 > method for doing firmware updates from userspace?

I think request_firmware() is fine for this... you could have a look at
drivers/net/cxgb3 to see a device that writes new firmware to flash when
it detects a version mismatch between driver and device.

 - R.

Re: firmware loading interface

[Robert Hancock]

On 11/13/2009 06:35 PM, Roland Dreier wrote:
>
>   >  However our device will have flash to store the firmware in and, whilst
>   >  it looks as though it would be possible for us to use request_firmware
>   >  to provide occasional firmware upgrades from userspace, I can't find any
>   >  reference as to whether this is an accepted method for doing so. Could
>   >  someone please confirm for me whether or not it's a good idea to use
>   >  request_firmware for this, or perhaps point me at another standard
>   >  method for doing firmware updates from userspace?
>
> I think request_firmware() is fine for this... you could have a look at
> drivers/net/cxgb3 to see a device that writes new firmware to flash when
> it detects a version mismatch between driver and device.

It depends on the consequences of a failed flash due to losing power, 
crash, etc - if it has the potential to brick the device then I don't 
think that should happen without the user triggering it explicitly..

Re: firmware loading interface

[Arnd Bergmann]

On Saturday 14 November 2009, venu wrote:
> Hi Arnd,
> 
> When the driver calls the request_firmware during initialization where is
> the firmware stored. What mean to ask is where the path it picks th firmware
> from ?

See Documentation/firmware_class/README. The file name is hardcoded
in the device driver. The path is part of the hotplug implementation,
typicaly /lib/firmware.

	Arnd <><

Re: firmware loading interface

[Robert Hancock]

On Sat, Nov 14, 2009 at 10:55 AM, venu <vjosyula@gmail.com> wrote:
>  who triggers this upgrade from userspace ? I understand it is a naivee /
> beginers questions but i hope somebody explains me how ?

The request_firmware interface probably isn't suitable for that..
using an ioctl or read/write-based interface, possibly on a separate
device node, would likely be the way to go..

>
> On Sat, Nov 14, 2009 at 9:38 PM, Robert Hancoctk <hancockrwd@gmail.cr tom>
> wrote:
>>
>> On 11/13/2009 06:35 PM, Roland Dreier wrote:
>>>
>>>  >  However our device will have flash to store the firmware in and,
>>> whilst
>>>  >  it looks as though it would be possible for us to use
>>> request_firmware
>>>  >  to provide occasional firmware upgrades from userspace, I can't find
>>> any
>>>  >  reference as to whether this is an accepted method for doing so.
>>> Could
>>>  >  someone please confirm for me whether or not it's a good idea to use
>>>  >  request_firmware for this, or perhaps point me at another standard
>>>  >  method for doing firmware updates from userspace?
>>>
>>> I think request_firmware() is fine for this... you could have a look at
>>> drivers/net/cxgb3 to see a device that writes new firmware to flash when
>>> it detects a version mismatch between driver and device.
>>
>> It depends on the consequences of a failed flash due to losing power,
>> crash, etc - if it has the potential to brick the device then I don't think
>> that should happen without the user triggering it explicitly..

Re: firmware loading interface

[Arjan van de Ven]

On Sat, 14 Nov 2009 12:19:13 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:

> On Sat, Nov 14, 2009 at 10:55 AM, venu <vjosyula@gmail.com> wrote:
> >  who triggers this upgrade from userspace ? I understand it is a
> > naivee / beginers questions but i hope somebody explains me how ?
> 
> The request_firmware interface probably isn't suitable for that..
> using an ioctl or read/write-based interface, possibly on a separate
> device node, would likely be the way to go..
> 

it's not unusual to have a sysfs attribute that, when written to, will
just do a request_firmware().
It's not pretty, but it's cleaner than the alternatives....


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: firmware loading interface

[Philip Downer]

Arnd Bergmann wrote:
> On Friday 13 November 2009, Philip Downer wrote:
>   
>> However our device will have flash to store the firmware in and, whilst
>> it looks as though it would be possible for us to use request_firmware
>> to provide occasional firmware upgrades from userspace, I can't find any
>> reference as to whether this is an accepted method for doing so. Could
>> someone please confirm for me whether or not it's a good idea to use
>> request_firmware for this, or perhaps point me at another standard
>> method for doing firmware updates from userspace?
>>     
>
> The idea of request_firmware is that it helps you load the firmware
> into the device at initialization time so you can use it directly,
> without making the firmware blob a part of the kernel driver.
>
> If I understand you correctly, you never need a firmware in user space
> in order to use the device, but only for flashing a new version into
> the nonvolatile memory.
>   

Thats correct.

> The easiest way to do that would be an ioctl operation, if you are
> implementing a character or block device interface anyway. Just load
> the firmware into the RAM of a user application and call an ioctl
> with the pointer to the firmware as an argument, but don't use
> a data structure with a pointer in it, which would mess up 32 bit
> compatibility operation.

Thank you for this suggestion and for the warning about 32bit, we are in 
fact implementing a character device and could use this method.

Thanks,

Philip Downer

Re: firmware loading interface

[Philip Downer]

Arjan van de Ven wrote:
> it's not unusual to have a sysfs attribute that, when written to, will
> just do a request_firmware().
> It's not pretty, but it's cleaner than the alternatives....
>   

This was in fact what I was considering when making my initial post, but 
couldn't find any examples or drivers which do use sysfs and request 
firmware in this way and as you say, it's not pretty. However if it's 
considered to be cleaner by others (I certainly think it to be so) then 
I am inclined to use this method as opposed to the ioctl method 
suggested by Arnd earlier in the thread.

Arjan, could you possibly point me at any drivers which already work in 
this way?

Thanks,

Philip Downer

Re: firmware loading interface

[Dmitry Torokhov]

On Fri, Nov 13, 2009 at 04:35:01PM -0800, Roland Dreier wrote:
> 
>  > However our device will have flash to store the firmware in and, whilst
>  > it looks as though it would be possible for us to use request_firmware
>  > to provide occasional firmware upgrades from userspace, I can't find any
>  > reference as to whether this is an accepted method for doing so. Could
>  > someone please confirm for me whether or not it's a good idea to use
>  > request_firmware for this, or perhaps point me at another standard
>  > method for doing firmware updates from userspace?
> 
> I think request_firmware() is fine for this... you could have a look at
> drivers/net/cxgb3 to see a device that writes new firmware to flash when
> it detects a version mismatch between driver and device.
> 

Doesn't dell_rbu also uses request-firmware for flashing BIOS?

-- 
Dmitry