On Tuesday 03 November 2009 06:54, Sebastian Haas wrote: > Wolfgang Grandegger schrieb: > > Sebastian Haas wrote: > >> Regarding firmware update. As this process is always pretty manufacturer > >> specific, I don't see any need to build a general interface for it. Each > >> device may have it's own solution. > > > > IIRC, there is a generic interface for firmware downloads, which sjould > > be used. I think the softing driver uses it. > The Softing board needs a firmware to be uploaded to actually run. The > CPC-USB for example doesn't need an extra firmware to be loaded but > instead you can upgrade/flash the internal firmware if you need. > > I don't know the generic interface for firmware downloads, but I don't > want to upgrade the firmware automatically if I connect a devices. AFAIK > the firmware download mechanism starts automatically. > > Sebastian
You are both right. When a device needs a firmware download to actually run, the kernel's firmware mechanism should be used. Other devices have some firmware in thier flash. You don't want to update these devices automatically. So a special device specific implemenation is needed. For USB devices I could think of libusb for such operations. This brings the advantage, that a driver could even refuse to load until a specific firmware is flashed through libusb. But this does not answer the question for PCI devices. This requires some driver support. I could think of the kernel's firmware mechanism for this, but with a manual trigger. This trigger fits into the same sheme as the "enable 5V on pin1" task mentioned elsewhere in this thread. So when we find a way for the "enable 5V on pin1" issue, firmware updating is somehow solved from point of view. Matthias _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
