3 ms·

See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD - some of the USB-C ports respond to USB PD Vendor-D

See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD 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.

mmastrac 3y ago
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.
ROFISH 3y ago
Related to anyone seeing this: https://support.apple.com/guide/apple-configurator-mac/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac 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.
- KMag 3y ago
  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.
  - mmastrac 3y ago
    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.
  - rcxdude 3y ago
    It's not a particularly unusual configuration, but A/B images are still not immune to update failures
    - KMag 3y ago
      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.
  - TheNewsIsHere 3y ago
    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.

mmastrac 3y ago

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.

ROFISH 3y ago

Related to anyone seeing this: https://support.apple.com/guide/apple-configurator-mac/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac 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.

KMag 3y ago
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.
- mmastrac 3y ago
  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.
- rcxdude 3y ago
  It's not a particularly unusual configuration, but A/B images are still not immune to update failures
  - KMag 3y ago
    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.
- TheNewsIsHere 3y ago
  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.