Author Topic: Hardware Bootloaders, why DFU?  (Read 696 times)

0 Members and 1 Guest are viewing this topic.

Offline Propaganda

  • Contributor
  • Posts: 6
  • Country: us
Hardware Bootloaders, why DFU?
« on: April 12, 2021, 06:16:49 pm »
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...
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7522
  • Country: us
    • Personal site
Re: Hardware Bootloaders, why DFU?
« Reply #1 on: April 12, 2021, 06:41:56 pm »
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.
Alex
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6314
  • Country: fr
Re: Hardware Bootloaders, why DFU?
« Reply #2 on: April 12, 2021, 06:49:07 pm »
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.

 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1759
  • Country: us
  • Yes, I do this for a living
Re: Hardware Bootloaders, why DFU?
« Reply #3 on: April 12, 2021, 07:39:47 pm »
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...

DFU 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.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7522
  • Country: us
    • Personal site
Re: Hardware Bootloaders, why DFU?
« Reply #4 on: April 12, 2021, 08:00:45 pm »
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.
Alex
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1759
  • Country: us
  • Yes, I do this for a living
Re: Hardware Bootloaders, why DFU?
« Reply #5 on: April 12, 2021, 09:28:03 pm »
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.

I 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 took forever for no reason that makes any sense.
 

Offline devan

  • Contributor
  • Posts: 11
  • Country: us
Re: Hardware Bootloaders, why DFU?
« Reply #6 on: April 13, 2021, 02:39:13 am »
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.

In 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#windows10

The 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 the UF2, 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.
 

Online gmb42

  • Regular Contributor
  • *
  • Posts: 218
  • Country: gb
Re: Hardware Bootloaders, why DFU?
« Reply #7 on: April 13, 2021, 10:34:02 am »
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.

+1 for this info, like it or not Windows < 10 must die.

MS are providing anothr push, from 1st July 2021 they will no longer cross-sign attestat

In 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#windows10

The 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 the UF2, 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.

+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. See this OSR article for more info.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3416
  • Country: us
Re: Hardware Bootloaders, why DFU?
« Reply #8 on: April 14, 2021, 04:55:49 am »
Quote
The modern successor to the various attempts at MSC bootloaders is the UF2, which should be pretty much bulletproof.
And quite large (~8k for a CM0) :-(
 

Online josip

  • Regular Contributor
  • *
  • Posts: 81
  • Country: hr
Re: Hardware Bootloaders, why DFU?
« Reply #9 on: April 14, 2021, 07:04:33 am »
You still need drivers for CDC. Even if it is just an INF file pointing to usbser.sys.

Last 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.

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.

I 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).
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 172
  • Country: ee
Re: Hardware Bootloaders, why DFU?
« Reply #10 on: April 15, 2021, 06:36:24 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf