5 ms·

Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom

Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it writes the result on its partition and then looks at the other partition. If the other partition did not succeed the test, it reports the fact back to HQ and overwrites it with the current system. The upgrade procedure is extremely simple -- the current system writes to the other partition, then restarts. If the upgrade is interrupted at any point in time, the other system will know it was interrupted and will just restart immediately. In any case, after two restarts we are back to the system that initiated the upgrade and if it checks the other system did not start and self-tested successfully, it can redo the upgrade as many time as we want and you still have a working system. Could it be done better? Probably it could. It took me one day to think up and implement. I would think Ford could do it better (Edited: yes, not a Tesla)

jnwatson 3y ago
That is very much standard.
- matt-attack 3y ago
  Yep TiVos did something similar
- onetimeuse92304 3y ago
  I wouldn't know what the standard is. This seems like something my kid could figure out. It is a shame that multi-billion dollar company that makes consumer products costing hundreds of thousands of dollars can't.
  - deleted 3y ago
    [deleted]
Kirby64 3y ago
This is a Ford Mach-E, not a Tesla.
deleted 3y ago
[deleted]
znpy 3y ago
My router does that. It’s the wrt3200 and has two partitions and if it fails at booting three times in a row it will boot the old partition. I know because i have bricked and unbricked it this morning whole updating openwrt ^_^”
rollcat 3y ago
A/B boot is old, good, and proven, but what do you do when you have dozens of separate microcontrollers, each governing a semi-independent subsystem, all running their own software that needs its own updates? It would make sense from safety/reliability PoV when a crash/bug in a slightly less critical system (like adjusting mirrors) does not affect a slightly more critical system (like indicators). What do you do when updating only one of the components fails? Do you rollback everything? Do you continue with the rest? Just to be clear, I'm firmly in the "less smart = more reliable" camp, but even a SoC resembles a distributed system nowadays, and this architecture has its merits. The GPU on my M1 Mac crashed, rebooted itself, and all I saw was 1-2s of glitched graphics - no application noticed. Of course ideally GPUs wouldn't crash, but the same could be said of cars.
- onetimeuse92304 3y ago
  I don't think "more smart = less reliable" is inevitable. The goal should be designing it in a way that failure of the more smart features does not spill to critical functionality. Or that you can use it in a degraded state sort of like fly by wire planes do. I have no car design experience, but here is my 5-minute idea: For starters, you build a basic car. It drives, it has basic indicators, it has ABS, etc. It has some APIs that can be connected to but there is limited ability to break the basic car through those APIs. Then you build your smart car around it by adding to the basic car. You add on more computers, electronics, etc. But any time you rip off the smart car functionality, you still have the basic car working. If there is a need to update software, this should really only be needed for the smart car part. But even if it fails completely, the basic car underneath should be functional and you should be able to use the car albeit without infotainment and navigation and other "stuff". You should be able to do whatever you need to do, call your mechanic and limp there to get them to sort the problem out for you.
  - AlotOfReading 3y ago
    That's not how vehicles are designed for many reasons. For one, there's no option where critical components aren't designed with updateability in mind. It's simply a fact of life that code has bugs, and the only way to fix those bugs is updates. It's valid to feel that that those updates should applied at a dealership where the system can be tested afterwards, but that has a lot of implications of its own.
geor9e 3y ago
You speak as though this is an ancient hack, but this is exactly how it still works in a lot of modern devices. https://source.android.com/docs/core/ota/ab/ab_implement https://source.android.com/docs/core/ota/ab/ab_implement

jnwatson 3y ago

That is very much standard.

matt-attack 3y ago
Yep TiVos did something similar
onetimeuse92304 3y ago
I wouldn't know what the standard is. This seems like something my kid could figure out. It is a shame that multi-billion dollar company that makes consumer products costing hundreds of thousands of dollars can't.
- deleted 3y ago
  [deleted]

Kirby64 3y ago

This is a Ford Mach-E, not a Tesla.

deleted 3y ago

[deleted]

znpy 3y ago

My router does that. It’s the wrt3200 and has two partitions and if it fails at booting three times in a row it will boot the old partition. I know because i have bricked and unbricked it this morning whole updating openwrt ^_^”

rollcat 3y ago

A/B boot is old, good, and proven, but what do you do when you have dozens of separate microcontrollers, each governing a semi-independent subsystem, all running their own software that needs its own updates? It would make sense from safety/reliability PoV when a crash/bug in a slightly less critical system (like adjusting mirrors) does not affect a slightly more critical system (like indicators). What do you do when updating only one of the components fails? Do you rollback everything? Do you continue with the rest? Just to be clear, I'm firmly in the "less smart = more reliable" camp, but even a SoC resembles a distributed system nowadays, and this architecture has its merits. The GPU on my M1 Mac crashed, rebooted itself, and all I saw was 1-2s of glitched graphics - no application noticed. Of course ideally GPUs wouldn't crash, but the same could be said of cars.

onetimeuse92304 3y ago
I don't think "more smart = less reliable" is inevitable. The goal should be designing it in a way that failure of the more smart features does not spill to critical functionality. Or that you can use it in a degraded state sort of like fly by wire planes do. I have no car design experience, but here is my 5-minute idea: For starters, you build a basic car. It drives, it has basic indicators, it has ABS, etc. It has some APIs that can be connected to but there is limited ability to break the basic car through those APIs. Then you build your smart car around it by adding to the basic car. You add on more computers, electronics, etc. But any time you rip off the smart car functionality, you still have the basic car working. If there is a need to update software, this should really only be needed for the smart car part. But even if it fails completely, the basic car underneath should be functional and you should be able to use the car albeit without infotainment and navigation and other "stuff". You should be able to do whatever you need to do, call your mechanic and limp there to get them to sort the problem out for you.
- AlotOfReading 3y ago
  That's not how vehicles are designed for many reasons. For one, there's no option where critical components aren't designed with updateability in mind. It's simply a fact of life that code has bugs, and the only way to fix those bugs is updates. It's valid to feel that that those updates should applied at a dealership where the system can be tested afterwards, but that has a lot of implications of its own.

geor9e 3y ago

You speak as though this is an ancient hack, but this is exactly how it still works in a lot of modern devices. https://source.android.com/docs/core/ota/ab/ab_implement https://source.android.com/docs/core/ota/ab/ab_implement