I've been talking to people and thinking about firmware loading for the
hostmot2 subsystem. This email presents the results of this inquiry
and my plan for the future. The short version is i'll be sticking with
bfload, and using libraries other than upci to supply the missing PCI
access methods. Read below for all the details.
I intend to start coding later this week, so please send any comments,
questions, or criticism to the emc-developers list for public discussion
before then.
Here's some things we want from the firmware loading solution:
1. Developers and users who compile from source and Run-In-Place
must have a convenient way to choose which firmware gets sent to
each board.
2. Users who install .debs must have a convenient way to choose
which firmware gets sent to each board.
3. It would be nice if users couldn't accidentally re-program their
FPGAs in mid-run, ie if firmware loading happened at the sole
discretion of the driver rather than having multiple pieces of
code twiddling the boards.
4. It would be nice if the solution was applicable to all firmwares
of AnyIO-dom, not just HostMot2.
There are basically two ways to do it:
1. Load the firmware from the kernel driver, using request_firmware()
and udev [0, 1]
Features: -1, +2, +3, -4
Firmwares must be installed (or symlinked) into the udev firmware
search path, usually /lib/firmware.
User may specify firmware name by modparams, or the driver
defaults to "<BoardID>". Driver prepends "hostmot2/<BoardType>/"
to all firmware names before requesting. User can also symlink
"hostmot2/<BoardType>/<BoardID>" to the bitfile they want.
Feature 4 could be added. The abstraction layer between the
hostmot2 low-level drivers and the hostmot2 firmware driver could
be strengthened so that the low-level drivers are not expecting to
talk specifically to the hostmot2 firmware driver, but instead
can speak to any of several higher-level firmware drivers.
Something like the parport driver layer in Linux.
Feature 1 could be added if the udev firmware helper accepted
absolute paths. The folks on the linux-hotplug list shot this
idea down in flames ("just use symlinks like everyone else").
The lack of feature 1 (RIP) really kills this idea. We'd have to
have people symlink parts of their sandboxes into /lib/firmware,
and that's probably too gross. This problem is an indication
that the hostmot2 subsystem is straining the emc2 RIP model,
but I realize that model is not about to change any time soon...
2. Load firmware from userspace, using bfload
Features: +1, +2, -3, +4
I think we all understand this solution. It has all the features
we want, except it has the "someone can reprogram the FPGA while
the driver is using it" problem.
It was re-evaluated because the current upci library lacks some
pci access methods that I need, and because the (fairly recent)
firmware loading support in the kernel is tantalizingly close to
what we need, and superior in some ways.
To make bfload work, it would need to be augmented to have the
PCI access needed, but this is a small matter of hacking.
The way forward:
It's sadly awkward to do in-kernel firmware loading from user's home
directories (or any non-standard firmware directory), as needed by our
RIP use case. Thus we cannot use udev, and we're stuck with bfload.
bfload needs to be extended to have better PCI access (access
to both PCI Config space and PCI device BARs). upci currently
supports BAR access only. libpci supports Config space access only.
libpciaccess supports both [2].
I plan to support TRUNK by moving bfload from upci to libpciaccess.
I wont mess with upci, pci_read, or pci_write in TRUNK. libpciaccess
is packaged for Ubuntu starting with Gutsy, but it's not available
for Dapper [3]. This means TRUNK wont work on Dapper unless the
developer installs libpciaccess by hand. Hardy is here and it's
time to move on.
I plan to support the 2.2 branch by using both upci and libpci
in bfload. I wont mess with upci, pci_read, or pci_write in 2.2.
libpci is available for Ubuntu releases back to Dapper [4].
That's the plan. Object now or forever hold your peace.
0:
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/firmware_class/README;h=c3480aa66ba8048bf46483544ed6fb3ebb7151eb;hb=e1441b9a41c33aa9236008a7cfe49a8e723fb397>
1: <http://lwn.net/Articles/242046/>
2:
<http://people.freedesktop.org/~anholt/doxygen/xorg/lib/libpciaccess/pciaccess_8h.html>
3:
<http://packages.ubuntu.com/search?suite=default§ion=all&arch=any&searchon=names&keywords=libpciaccess>
4:
<http://packages.ubuntu.com/search?suite=default§ion=all&arch=any&searchon=names&keywords=pciutils-dev>
--
Sebastian Kuzminsky
"The brain is [a machine]. The fact that it's made out of meat is a
red herring." -- David Adler <http://www.spectrum.ieee.org/print/6268>
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
