3 ms·

Yes - hardware should be designed to always provide a way to recover from any failure mode that can result from software that's running on that hardware. Even

by xmodem 14y ago

Yes - hardware should be designed to always provide a way to recover from any failure mode that can result from software that's running on that hardware. Even bad firmware updates should be recoverable - what happens if you lose power mid-update?

cdawzrd 14y ago
Bad firmware updates are (almost always) recoverable, just not always (easily) by the end user. What happens when you lose power is that you need to use the hardware-level debugging/testing functionality of whatever programmable device is in question--JTAG, for example--to load a running firmware image and then reprogram the half-programmed flash storage.
Someone 14y ago
I expect that you also would like "hardware should be designed to always provide a way to update all of its software" to be true. I don't think you can expect both to be true nowadays. For example, chances are that your battery charging 'hardware' runs some software. That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) This applies elsewhere, too. Historically, we had the 'killer poke' (http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html; variants at http://en.wikipedia.org/wiki/Killer_poke http://en.wikipedia.org/wiki/Killer_poke). Nowadays, it is rumored that buggy baseband firmware for mobile phones can fry the hardware. I do not think it is feasible to prevent all of these in hardware. Because of that, you must accept "if you can update all software through software, you can brick your device through software". So, to get to "provide a way to recover from any failure mode that can result from software", you will need to have some unmodifiable software on the device. You also will need that software to allow updating of some firmware and to be free of bugs. I think that is possible, but not economically feasible. Why would anyone spend even a week on bug-checking that earliest running code on a device that will be sold for only six months? That would be giving up the bestselling 4% of the sales cycle.
- xmodem 14y ago
  > That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) I'd put that in the same category as writing robot arm control software that throws the arm off the table, for instance.

by xmodem 14y ago

cdawzrd 14y ago

Bad firmware updates are (almost always) recoverable, just not always (easily) by the end user. What happens when you lose power is that you need to use the hardware-level debugging/testing functionality of whatever programmable device is in question--JTAG, for example--to load a running firmware image and then reprogram the half-programmed flash storage.

Someone 14y ago

I expect that you also would like "hardware should be designed to always provide a way to update all of its software" to be true. I don't think you can expect both to be true nowadays. For example, chances are that your battery charging 'hardware' runs some software. That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) This applies elsewhere, too. Historically, we had the 'killer poke' (http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html; variants at http://en.wikipedia.org/wiki/Killer_poke http://en.wikipedia.org/wiki/Killer_poke). Nowadays, it is rumored that buggy baseband firmware for mobile phones can fry the hardware. I do not think it is feasible to prevent all of these in hardware. Because of that, you must accept "if you can update all software through software, you can brick your device through software". So, to get to "provide a way to recover from any failure mode that can result from software", you will need to have some unmodifiable software on the device. You also will need that software to allow updating of some firmware and to be free of bugs. I think that is possible, but not economically feasible. Why would anyone spend even a week on bug-checking that earliest running code on a device that will be sold for only six months? That would be giving up the bestselling 4% of the sales cycle.

xmodem 14y ago
> That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) I'd put that in the same category as writing robot arm control software that throws the arm off the table, for instance.