On Fri, 14 Dec 2001, David Brownell wrote: > > > > manage dynamic loading of different overlaid firmware > > > > images at runtime > > > > > > Are there devices that really do that ? > > > > Yep. Right here in front of me ;-) > > But are there are _products_ that do this and don't bother to
In fact we _are_ talking about a real product - well, admittedly a future one which is not targeted to high-volume low-price consumer market. So I don't claim this counts very much here. > implement it as regular bank switching hardware? Last time > I looked, only one of the Linux drivers that needs firmware > even needed a second stage loader (to write off-chip memory). > None even wanted to change firmware during operations. Right for all devices supported by Linux kernel drivers, AFAICS. Probably same for drivers based on usbdevfs. But I don't know for the devices which are currently unsupported under Linux. > It's my understanding that while folk can do things like that with > 8051-based chips like EZ-USB FX/FX2, they usually do it with > bank switching. So that if the firmware isn't in ROM, they'd > need a boot loader that knows how to populate each of the > various banks of memory. Bank switching is only possible if you have an external ram with banks to be switched - but why adding the ram if all you need is another 2kB to support a different device configuration? Just make the config-specific part of the firmware to overlay each other in the onchip memory of the microcontroller and let the driver manage overlay loading whenever it issues set_config requests - just to give an example. > Seems to me that anything outside of a simple load-at-init > model, for a flat address space in the device, is a special > case already. So IMHO the current list of special cases (either not simple load-at-init or due to resume/VM issues) is already at least: - usb/storage (swapping to usb-disk) - usb/serial, if boot loader required - all usb-ethernet bridges (swapping over NFS) The point is, what does a special case mean - the driver just needs to get and download one or more pieces of firmware by calling an in-kernel firmware managing entity or the driver needs to duplicate all the firmware handling procedures from userland. I personally have no problem at all, when saying everything but simple load-at-init, without additional loader or resume/VM issues, ... is a special case. I just don't see any win when moving the loading into userspace - but I do suspect we will see more and more devices which require special cases. Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
