[PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware

[Dan Williams]

On Tue, 2008-06-03 at 11:26 -0400, Dan Williams wrote:
> On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote:
> > libertas-dev-bounces at lists.infradead.org wrote on 06/03/2008 10:12:31 AM:
> > 
> > > On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
> > > > To update boot2, copy the boot2 and firmware images to /lib/firmware 
> > and:
> > > > 
> > > > echo <boot2_image_name> > /sys/class/net/eth2/lbs_boot2
> > > > echo <firmware_image_name> > /sys/class/net/eth2/lbs_fw
> > > 
> > > So why are we doing this with the driver, and not the userspace update
> > > tool?  Marvell keeps wanting to do firmware update in the driver, and we
> > > (David and I at least) keep saying no.  If there are issues that prevent
> > > the userspace firmware update tool from working, then we need to fix
> > > those issues.  Firmware updates from the driver were a disaster the
> > > first time around, and I don't quite see how that may have changed this
> > > time?
> > > 
> > > If you really want, the userspace tool can be rewritten in C.
> > > 
> > It is not a matter of Python vs C.
> > The userspace tool is extremely awkward to use (since it requires the 
> > driver modules to be unloaded which in turn makes the identification of 
> 
> How does it make the ID more difficult?  What do we need besides the
> bcdDevice ID that tells us what boot2 version the device has?  Is there
> something more needed to find out if the device has larger EEPROM for
> active antenna support perhaps?
> 
> > devices on the XO even more difficult) and it bricks wireless modules 
> > while the driver method doesn't. So the statement that "firmware updates 
> > from the driver were a disaster" is simply not true.
> 
> It bricks the modules because the only people with the access to the
> docs and firmware (Marvell) didn't try to debug the issue, or correct
> the tool.  There's only so much _I_ can do without access to the
> firmware source itself if other people who have the info aren't really
> jumping on these problems, when I don't have the info.
> 
> > This is low level hardware functionality that needs to be implemented in a 
> > fail-safe manner. Out testing has showed that the driver/firmware method 
> > (the driver just controls the memory updating code on the firmware) is 
> > more robust than the userspace tool.
> 
> The original issue was that the driver needed to be told how to flash
> using module parameters, which is just a non-starter.  A dynamic,
> sysfs-based interface is quite a lot better; I'm willing to keep
> discussing that solution.  But some questions:
> 
> 1) is the interface extendable to flashing firmware on CF & SDIO 8385
> and SD 8686 too?

So this point is moot because the patch is only applicable to USB right
now, and we don't have any USB devices other than 8388.

The question below still stands though...

Dan

> 2) does the patch handle resets and everything correctly, ie can I flash
> the firmware and then immediately start using the device?  Can I also
> stop using the device and flash the firmware on-demand without unloading
> the driver?
> 
> Dan
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev