Hi Garrett, Thanks for the feedback. This is something I've thought about before. Particularly when I was dealing with the world of eeproms on devices like ixgbe and the like. I've also been trying to think through what firmware upgrade would look like in the world of i40e.
Unfortunately, over the years I lost notes on what that sketch looked like, but it had many things that weren't dissimilar to what you described below. In particular, the main focus of what I was doing was for permanent firmware upgrade as opposed to the device needing firmware at power on. I think the latter case has actually been discussed and solved in work that Hans did and is merely waiting for the consumer to be cleaned up and finished before both are integrated. One thing though is that interface is going to need to be pretty well thought out and we're going to need to make sure that a rather diverse set of consumers are considered here. So I'm going to make some notes about this in the rfd in the future work direction as at this time I'm not in a position where I'll be working on firmware upgrade for all kinds of different devices. It's my hope that as we continue to explore the questions of firmware upgrade and looking at it more seriously for other devices, we'll start to get a better idea of what this looks like and what makes sense. Thanks for taking a look and the feedback. Robert On 4/25/16 11:53 , Garrett D'Amore wrote: > The write up of the partial DMA is cogent and correct. > > However, I am of the opining that there is a unique opportunity here to > express something another way than via USCSI, which I happen to think is a > hideous way to deal with this. USCSI is a sort of catch all for “any > other SCSI command we don’t know how to handle”, and IMO we can do much > better here. I’d really like to avoid the mistake of continuing to abuse > USCSI this way. > > So what I’d actually like to see instead is a new firmware flash API > (ioctl-based) defined, ideally that a common framework could use, > essentially presenting firmware flashing as a first class operation. Then > the sd(7d) driver could internally use whatever mechanism(s) it finds are > best for supporting this. For example, I imagine that I’d implement this a > single transfer between user and kernel space, then use either multiple > mode 7 steps, or a single mode 5 step, depending on the device’s behavior . > User space application code (the fwflash utility) need not be bothered with > any of this. > > I believe some other open source operating systems have generalized > firmware loading interfaces. Part of figuring out a good interface here > is coming up with a solution to “permanent” firmware rewrite, vs. a device > that needs a firmware file to be loaded into device RAM during boot (see > linux’s request_firmware() interface for examples of this). > > If you look at fwflash, it has some pretty basic operations, so it should > be straight-forward to map these into an ioctl API, IMO. > > Actually, even better, one could imagine a central “fwflash” driver that > individual device nodes “register” a fwflash ops vector to, so that in the > future it would not be necessary to write new fwflash plugins for a driver, > but instead just supply an fwflash ops entry point and register it. The > fwflash module/API would express the flash operations via ioctl to fwflash. > > On Mon, Apr 25, 2016 at 10:21 AM, Robert Mustacchi <[email protected]> wrote: > >> Hi, >> >> This RFD focuses on changes to illumos to better enable firmware >> upgrade. It mostly focuses on extending some public and private >> interfaces for use with the fwflash(1M) command which can be used to >> flash disk drive firmware. >> >> https://github.com/joyent/rfd/tree/master/rfd/0031 >> >> Feedback is appreciated. >> >> Robert >> > > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
