7 ms·
the thing I keep failing to understand is: why do these devices need to block while updating? Can't they just use two (small) memory-banks and download the imag
by edejong 10y ago
the thing I keep failing to understand is: why do these devices need to block while updating? Can't they just use two (small) memory-banks and download the image to bank 2 while working from the first one and do one quick switcheroo in a couple of milliseconds?
(edit: question marks should mark the end of sentences which are questions)
- Bartweiss 10y agoFrom the security we've seen in these devices, I'm assuming that would be both a financial and technical no-go. The standard practice appears to be buying a minimum-cost board and loading it up with some stolen open-source software - sensible hot-swapping would be far too demanding for that. (But yes, that really should be the case. It could also support elegant failures back to the previous firmware version.)
- dom0 10y agoIoT devices seem to be the result of putting web people in charge of embedded development. Not to defend emb. devs... some truly horrendous stuff out there as well.
- krallja 10y agoI think it's the opposite; they put the embedded developers, who (rightly) have no sense of the insane challenge of doing security, in charge of talking to the Web.
- vonmoltke 10y agoI disagree with that characterization. Engineers working on connected devices, Web or not, should be cognizant of security issues. That many aren't I see as a problem. For that matter, I don't think most web developers have a proper sense of security challenges, either.
- dTal 10y agoDoes it have to be either/or? You need both types of developers, and they have to talk to each other, and you have finite hiring resources. These are very different cultures, and the failure mode is either broken system software, which will get noticed and fixed, or broken security, which likely won't.
- witty_username 10y agoYou don't need that. Linux does that without using two separate memory banks. (You only need to reboot for kernel updates, and that can be reduced with kexec) Your idea is pretty similar to having a hypervisor running two VMs and switching from one to the another. There's no need to have two separate memory banks.
- edejong 10y agoWith an IC, it makes sense to work from two different RAM ICs. I'm not an electronics engineer, however.
- RealityVoid 10y agoProgram flash is usually ROM and that is where you are executing the SW. You mostly keep variables in RAM, although you can do a couple of neat tricks with copying and fiddling with code in RAM. Even more, while you usually can self-program the ROM memory, you can only erase it in blocks that are pretty big relative to the whole memory of the device. If you have a simple system that runs in a flat address space with no MPU and virtual memory, it gets pretty complicated for a running update. Of course, that's from my experience with microcontrollers. SOrry if I went off-topic, but I just thought the discussion interesting. Embedded Linux computers I bet are more complex than that and probably execute code in RAM. These babies are connected to the internet so they probably have a far beefier SOC running Linux not some lightweight RTOS. It is a kettle, you need a lot of juice for that baby!