Live data from Hacker News

Serial adapter/reboot controller for Apple M1/M2

tindie.com

41–42 of 42 posts

Re: Serial adapter/reboot controller for Apple M1/M2

#41
post #38
post #16

Earlier quoted context omitted.

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…

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.

Re: Serial adapter/reboot controller for Apple M1/M2

#42
post #40
post #38

Earlier quoted context omitted.

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…

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.

Post reply on HN