Hacker News Reader

Comment by delroth | Hacker News Reader

See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD - some of the USB-C ports respond to USB PD Vendor-Defined Messages to trigger a bunch of debug features, including rebooting the SoC or configuring one of the internal UARTs to output to two pins on the USB-C connector.

View on HN

Related to anyone seeing this:

https://support.apple.com/guide/apple-configurator-mac/reviv...

If an update goes really wrong (ie. battery died in middle of an update), the Mac may need to go into DFU mode and get a firmware write over USB.

I don't know if this is the actual format the firmware update uses, but the ports listed in the official documents match the "special" ports in the wiki there.

Honestly, with flash so cheap these days, why isn't the firmware structured as two "partitions", each with a timestamp and checksum, and a small stub that

  (1) is never overwritten
  (2) is capable of accepting firmware updates over serial connection / TFTP / etc.
  (3) checksums the newest firmware "partition" runs it if the checksum checks out
  (4) falls back to the older "partition" of firmware if the checksum indicates corruption and/or partial update

Having had to TFTP-update several (and in one case exacto-knife jump two pins on the flash) WRT-54G firmware updates before I learned that the WRT-54G firmware update had issues with FireFox's HTTP POST implementation, I really wish firmware updates were more robust. A firmware update also bricked an early FitBit of mine.

Oh wow. I forgot about those days. In some ways I miss the WRT54G days a lot.

The Nintendo Switch does A/B firmware updates. It has tremendous speed benefits.

macOS sort of achieves something similar with the new system volume architecture, but…not exactly.

A lot of devices are actually structured that way. Android has an A/B flash system that works kind of like that.

It really comes down to how much time and care the developers have in their implementation.

It's not a particularly unusual configuration, but A/B images are still not immune to update failures

If a sufficiently robust integrity check is used, then an update failure is just a no-op, not a bricked (or even reduced capability) device, no?

Now, pushing a bad firmware version is another story, and impossible to prevent unless the firmware updater contains some impossibly complex static analysis tools to formally verify some set of correctness properties of the incoming update.

This is far more sophisticated than the protocol I was working with, cool!

In my design I needed to do the a similar thing -- physically switch the USB2.0 lines between USB and raw serial. Using the pico for a USB serial gadget is smart. I used a USB/serial adapter for my project and it was a PITA.

Reply on news.ycombinator.com