On Wed July 2 2008 19:59:11 Stephen Wille Padnos wrote:
> Sebastian Kuzminsky wrote:
> >The hostmot2 drivers already use the PCI hotplug system. The entire
> >kernel device model is transitioning to that. For firmware loading in
> >particular, it's literally just request_firmware().
>
> As far as I can tell, all that does is get the firmware file into a
> kernel buffer. It does not appear to program the image into the device
> (how could it?). I think bitfiles need a little massaging to be
> programmed into the FPGA (you have to extract various sections and send
> those, but not the headers, etc.). The actual device programming code
> would need to be in the kernel, and it would need to have a bitfile
> parser in it.
Indeed, how could it? Programming firmware into a device is totally
device-dependent, and the responsibility of the device driver.
As you say, all the kernel firmare framework does is let the driver
request a firmware file from userspace by name, and have that firmware
delivered to the driver. It's a very focused "open/read/close" in the
kernel, backed by userspace via the standard uevent/udev infrastructure.
It's widely used and it seems to be here to stay.
> How would you propose to load different (or the same) firmware into
> several cards? Would you rewrite the driver so that it can be loaded
> more than once, and send separate bitfiles to different cards? (this
> would likely require some HAL/RTAPI work as well, since you can't have
> more than one copy of each named module loaded at once) Is it possible
> to have an array of char pointers to point at multiple firmware images?
The driver would be loaded once, and the firmware for each board would
be chosen at that time.
Currently, the hostmot2 driver system has a per-board modparam string
called "config"; each low-level driver has an array of them and
assigns one to each board it finds. Thus the config string for each
board is provided by the module loader (loadrt). The config string
consists of space-separated config tokens such as "num_encoders=3" or
"num_stepgens=1".
The request_firmware()/udev solution would add another config token to
the current config string, something like "firmware=foo.bit".
The driver would prepend "hostmot2/<BoardType>/" to the firmware name
string, and request something like "hostmot2/5i20/foo.bit" from udev.
udev would send it /lib/firmware/hostmot2/5i20/foo.bit, and the driver
would program the board with that.
Thus the user gets to choose which firmware gets sent to which board.
The same firmware can be sent to multiple boards, or they can get
different firmwares. User's choice, no problem.
If the "firmware=" config token is omitted, the driver would request
firmware based on the board identifier: order of detection, or pci
slot address, or epp io address, or something unambiguous like that.
It'd request something like "hostmot2/7i43/board0" from udev, which
would be a user-managed symlink to the user's chosen "default" firmware
for that board.
This *would* work really well and be really clean, except it interacts
poorly with RIP. (And I fully recognize the value of RIP.)
udev has a fixed set of directories that it searches for
the requested firmware; on Ubuntu 8.04 it's /lib/firmware
and /lib/firmware/$(uname -r). It does not search in
/home/seb/emc2/src/hal/drivers/mesa-hostmot2/firmware...
It could be taught to, but we'd have to apply a minor hack to udev.
If the driver could request absolute paths, instead of relative to
/lib/firmware, we'd be set. I wrote this up and offered the patch
to the udev folks on the linux-hotplug list, and it was rejected.
"Just use symlinks like everyone else", they said.
So the RIP setup would include pointing a symlink at your sandbox
like this:
ln -s $HOME/emc2/src/hal/drivers/mesa-hostmot2/firmware /lib/firmware/hostmot2
If you want to have multiple RIPs *with different firmware*, you'd have
to remember to switch the symlink.
This is pretty grotty. But maybe it's less grotty than forking
libpciaccess.
I appreciate all y'all's input, and the civil, focused discussion.
When the rubber meets the road (or the code meets the users), theoretical
cleanliness and practical usability are sometimes at odds. Thanks for
helping me find the right way.
--
Sebastian Kuzminsky
you are the only light there is for yourself my friend
-- Gogol Bordello
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
