firmware loading
Sam Leffler
sam at errno.com
Wed Dec 21 09:19:51 PST 2005
Scott Long wrote:
> Poul-Henning Kamp wrote:
>
>> In message <43A8EE23.3010202 at errno.com>, Sam Leffler writes:
>>
>>> Florent Thoumie and I have been working on some generic support for
>>> loading firmware using kld's. You can find a proof of concept at:
>>>
>>> http://www.freebsd.org/~sam/firmware.tgz
>>>
>>> It has code to manage firmware images and load them on demand by
>>> requesting a kld through standard facilities.
>>
>>
>>
>> Is the firmware kld unloaded again when no longer in use, or does it
>> stay in KVM once as long as the driver is active ?
>>
>
> Right now it stays resident. My understanding is that the wireless
> cards that this was designed for need to reload their firmware after
> resume. We don't have any hooks to tell drivers when the filesystem
> is ready, so the only non-hackish solution right now is to just keep
> it resident. I agree that this isn't ideal, and I would think that it
> would be pretty trivial to add an event handler hook to solve this.
> The other thing that I'm not sure about is whether this being a module
> dependency will prevent it from being unloaded. I'm not sure how
> ispfw.ko handles this.
Actually, it is unloaded on last reference. This is controlled by the
caller (there's a flag to firmware_put that says it's ok to unload).
Unloading on last ref is the most tricky part of the code as I wanted to
handle multiple firmware images packaged in a single kld and that
requires some care to be robust. For now consumers need to be somewhat
aware of how multi-image kld's are packaged; they must order their
get+put calls to put last on the "master image" in a kld.
Using kld's to do this adds a level of indirection (over just reading
directly from files) but also has lots of advantages. You can trivially
link stuff statically into the kernel. You can pre-load stuff from the
loader. You can print copyright notices to the console on load. You
can also do things like compress the firmware in the kld. The big win
is having a common api that hides the implementation details. In this
regard the code needs some cleanup so consumers don't have to include
linker.h to get the definition of linker_file_t and so they don't know
about implementation details.
Sam
More information about the freebsd-arch
mailing list