Hardware Bootloaders, why DFU? - Page 1
Forum section: electronics / general

author: Propaganda
author_rank: Newbie
timestamp: April 12, 2021, 06:16:49 pm
content: Many devices which have USB device peripherals contain hardware bootloaders utilizing DFU. I see one example, NXP, emulating a mass storage device; this is interesting but also has some quirks from my research. The issue from my research is interfacing with DFU bootloaders requires playing around with Zadig and drivers so isn't really a solution for end customers. Sure you can make a software bootloader do anything but what happens when that has a bug, difficult and dangerous to have a self updating bootloader. It seems like making USB CDC hardware bootloaders would be a no brainer, but I can't see anyone doing this. Maybe Microsoft should just fix the DFU driver mess...

author: ataradov
author_rank: Super Contributor
timestamp: April 12, 2021, 06:41:56 pm
content: You still need drivers for CDC. Even if it is just an INF file pointing to usbser.sys.It is really on Microsoft to make bare devices available to the applications without any drivers. I think there is some hacky way of doing this, but I have not tried it myself. You can return some GUID as a string descriptor 99 or something like this, which would tell Windows to just install WinUSB driver for the device, making it accessible to applications right away. I don't know if this actually works in practice.MSD is somewhat universal solution, although pretty crappy one too.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 12, 2021, 06:49:07 pm
content: DFU is a dedicated USB class made for exactly this: firmware upgrade. It definitely makes a lot of sense to use it, as it's standard and has been reasonably thought-out, instead of fiddling with messy solutions using more general USB classes.The driver issue is an issue only for those that don't want to invest sufficient resources. For a company, it's pretty easy to package a driver ready to install for the end user. The only "problem" is that - at least for recent Windows versions - it requires driver signing, which has a cost. But any company - unless it's an ultra small one - which is serious about supporting firmware upgrade through USB should provide easy to install drivers. This is not rocket science.Whether MCU vendors should themselves provide such easy to install drivers is a good, but problematic question. MCU vendors do not provide end products. The companies designing and selling end products should IMO do this extra step. They may want to use their own USB vendor ID, provide their own installers, and so on. As you noticed, as most make you use "Zadig" for driver installation, this is definitely just a matter of installation. The drivers already exist, and that would be the hard part to code and validate.Now whether Windows should support DFU without requiring any specific installation - like with HID devices - that would probably be a good idea. Windows has been known to have HUGE lag regarding the USB standard. Just consider how long it took them to natively support USB Audio 2.0. This is one area where Linux, for instance, has a clear lead. Weirdly enough.

author: Bassman59
author_rank: Super Contributor
timestamp: April 12, 2021, 07:39:47 pm
content: Quote from: Propaganda on April 12, 2021, 06:16:49 pmDFU would be a no-brainer if the three major operating systems offered built-in Device Class drivers.A bunch of years ago I did a USB audio device and the client asked about DFU. I said it needs a driver. The response? "Is there another way to implement firmware update?" So I cooked up a method by which a specialist HID Report was used to upload the new binary image. Crude, but effective.

author: ataradov
author_rank: Super Contributor
timestamp: April 12, 2021, 08:00:45 pm
content: Yes, I personally use HID as well. It is the best option for a generic data transfer protocol that is supported without drivers everywhere. Even from the web browser directly now.Arguably the first thing USB people should have done is define a generic data transfer class. And then go define other classes. But USB is a disorganized mess, so that's not going to happen.

author: Bassman59
author_rank: Super Contributor
timestamp: April 12, 2021, 09:28:03 pm
content: Quote from: ataradov on April 12, 2021, 08:00:45 pmI agree that USB is a mess. But I wonder if, way back when the spec was first written, the USB-IF people assumed that most class drivers would be supplied by the operating system. That is a reasonable assumption, I think, especially considering that there are not that many classes!But we know how that went, and I'll use the same example as SiliconWizard -- USB Audio Class 2.0 on Windows. That shit tookforeverfor no reason that makes any sense.

author: devan
author_rank: Contributor
timestamp: April 13, 2021, 02:39:13 am
content: Quote from: ataradov on April 12, 2021, 06:41:56 pmIn Windows 10, it will actually automatically do the binding for usbser.sys based on the class descriptors, no need for the device manufacturer / end-user to manually provide the .INF file any more:https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-compatible-ids#windows10The GUID method (Microsoft OS Descriptors 2.0) works if the device manufacturer takes care to set it up from the beginning, but because it caches the uses-MS-OS-descriptors status the first time any device of a given VID/PID pair is inserted on a particular machine, it won't always work if the manufacturer tries to add the descriptors later in a silicon revision / firmware update.The modern successor to the various attempts at MSC bootloaders is theUF2, which should be pretty much bulletproof.The Raspberry Pi Pico is the first instance that I know of where someone has actually put it into the bootrom.

author: gmb42
author_rank: Frequent Contributor
timestamp: April 13, 2021, 10:34:02 am
content: Quote from: devan on April 13, 2021, 02:39:13 am+1 for this info, yet more proof that like it or not, Windows < 10 must die.MS are providing another push, from 1st July 2021 they will no longer cross-sign drivers for down-level OS < 10. For PnP drivers the only acceptable method to get a signature will be to pass the appropriate WHQL tests, which is anything but trivial, or even possible for some drivers. SeethisOSR article for more info.

author: westfw
author_rank: Super Contributor
timestamp: April 14, 2021, 04:55:49 am
content: QuoteAnd quite large (~8k for a CM0) :-(

author: josip
author_rank: Regular Contributor
timestamp: April 14, 2021, 07:04:33 am
content: Quote from: ataradov on April 12, 2021, 06:41:56 pmLast time when I checked (on not updated/latest OS versions), CDC device was enumerated automatically without asking any drivers/files from OS side, on Win 10, Linux and OSX.Quote from: ataradov on April 12, 2021, 08:00:45 pmI don't see any problems for CDC, today, and like to have 1 MByte/s transfer, so it is my first choice for everything (including bootloader).

author: dgtl
author_rank: Regular Contributor
timestamp: April 15, 2021, 06:36:24 pm
content: On the MCU side, the DFU almost the simplest thing to implement (as simple as usb gets), just control transfers and that's it. So it's a good choice for built-in roms, failsafe recovery (debricking) interfaces etc, I've used it a lot for those; for those use cases, the multi-platform compatibility and driver signing is not an issue anymore. Also having a standard dfu-util helps, I don't need write yet another tool.For customer-used update, the device should implement something device-specific usually anyway inside the normal communication flow the device uses - typically the fw update shall be buffered into local storage and uses encrypted images etc. Once the device has received the update, it will boot into bootloader and then do the update locally.Sadly, the non-class driver USB in Windows is hard; there is no good generic and simple libusb-like functionality. It is possible to use Microsoft os descriptors and WinUSB, but that is almost as bad as rolling out real driver. You can't just enumerate using vid/pid without having a driver installed - the winusb insists on providing a GUID (ie using the descriptor) for the application to find the device... There's even a in-browser webusb for web-based usb device control apps, but that's no good until Windows doesn't support simple direct access.At least, they provided serial port class driver in win10, so no more usbser.sys inf files... That works actually quite well, better than in some older windows version.

author: voltsandjolts
author_rank: Unknown
timestamp: January 09, 2022, 02:55:32 pm
content: Apologies for waking a sleeping beauty...Quote from: dgtl on April 15, 2021, 06:36:24 pmErm, yes you can.From Win8 upwards I believe, you can use Win OS Descriptors to automatically have WinUSB.sys/.dll assigned to your device.No user interaction, no driver install, plug and play.You can then access your device by vid/pid, guid is not enforced, in libusb at least.See thisexamplefor PIC32MM.So much better than searching through COM ports to find your device.