paul_c sent me this feedback off-list. Forwarded for your consideration.
--
Sebastian Kuzminsky
my brothers are protons / my sisters are neurons
I stir it twice, it's instant family! -- Gogol Bordello
--- Begin Message ---
Tried sending to the list, but it bounces... Can't be a&%$ to fix it.
On Tuesday 01 July 2008, Sebastian Kuzminsky wrote:
> 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.
module_param(firmware, charp, 0444);
request_firmware(&fw, firmware, dev);
> 2. Users who install .debs must have a convenient way to choose
> which firmware gets sent to each board.
See 1.
> 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.
See 1.
> 4. It would be nice if the solution was applicable to all firmwares
> of AnyIO-dom, not just HostMot2.
See 1.
> There are basically two ways to do it:
There is only one correct way of doing it.
> 1. Load the firmware from the kernel driver, using request_firmware()
> and udev [0, 1]
Correct. Use the kernel provided services along with the hotplug
support.
> Firmwares must be installed (or symlinked) into the udev firmware
> search path, usually /lib/firmware.
Generally, yes - However, relative paths could be passed to the module
parameter.
> 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.
Uggg. Messy.
> 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.
Um, yes, about the parport subsystem.
> 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").
Not at all surprised - If *you* really want absolute paths, write a
new firmware.assistant and modify the udev rule that gets triggered
by a firmware_request() event.
> 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...
R-I-P is a hangover from the NIST days and contributes much to
many of the poor decisions inflicted on the user.
> 2. Load firmware from userspace, using bfload
As I understand it, your primary interest in bfload is to fix a problem
that a minority of users may experience due to a BIOS deficit. In
essence,
a corruption of one of the PCI config registers - A simple solution
would be
to add a few lines to the module_init function to test/correct the
register.
bfload & Co = 1500 or so lines of code - Including your own fork of
libpciaccess would add bucket loads more. Using the kernel provided
routines
requires less than 100 lines (including any bit-flipping).
> 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.
If bfload is the "solution", what was the problem that can't be solved
at module load time ?
> 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.
The kernel provided firmware solution does exactly what it says
on the box with the additional benefits of being widely tested and
supported.
> To make bfload work, it would need to be augmented to have the
> PCI access needed, but this is a small matter of hacking.
What was bfload for again ?
> 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.
Modify the udev rule, pass relative paths, and dump R-I-P.
> 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 suspect you already know bfload is not an answer...
>
> 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.
Just wait for 2.6.26 and GCC-4.4.... 1350 compile time errors/warnings
and
counting..
> 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].
Using the correct kernel services, you don't need to mess with, or
support any dead end "utilities".
Dump the cruft and move on.
---
Paul.
--- End Message ---
-------------------------------------------------------------------------
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
