4 ms·

Pretty cool. Made me wonder if it would make sense on these SoC targets to dynamically load a program from external storage and write into internal flash for e

by unwind 8y ago

Pretty cool. Made me wonder if it would make sense on these SoC targets to dynamically load a program from external storage and write into internal flash for execution, then start running it without a reboot. Since such flashes are typically only erasable in pretty big blocks ("sectors") it would require some interesting design choices, but it should be doable. :)

berti 8y ago
You could exec from SRAM if you have enough to spare (larger Cortex M4/M7 uCs have 256k+, RetroBSD claims to only need 128k of that).
- unwind 8y ago
  Yes, of course, I've done that. It was the idea of treating on-board flash as a load-target for temporary programs that felt fun.
  - dbuder 8y ago
    I would do it on an external NOR chip, to which the usual response is, at that point, just get a proper microprocessor.
monocasa 8y ago
I'd be hesitant, as those flash banks aren't rated for more than 1000 or so writes over their lifetime. I've killed the internal flash in a few Arduinos and STM32s just from development/testing.
- exikyut 8y ago
  Hm. Makes me think how many (few) bytes you could fit a "if a specific interrupt is received then copy bytes from wire to RAM and run that instead" preamble into the bootloader. Presuming "killed" means "won't accept new updates but will read" (?), you could then continue to use the chip.
derefr 8y ago
This is, essentially, what the older generation of “flash carts” for game consoles do. Each new loaded game ROM gives you a progress bar as the cart performs an erase/program cycle to its flash. (The newer generation just copies the ROM to memory.)
okl 8y ago
There are several runtimes for microcontrollers that feature an elf/hex loader for static binaries, or a bootloader that retrieves a program and executes it in RAM. Sometimes you can re-enter the bootloader from your application software. On some embedded systems (satellite OBSW comes to mind) you can actually hot-patch the code function-by-function while running. You compile/link the software with some extra space before and after your functions for future modifications. Then when you patch, you have to make sure that the modified code is locked out and that the variables used by the functions being patched are in an acceptable state as well as the cache. Whether all of that extra effort makes sense? - it depends. But in most embedded projects you can just flash a new firmware and avoid the overhead of executing from RAM. (Depending on your target, flash might have a separate memory bus and could be one or two clock cycles faster.) Edit: Hot-patching in flash is totally possible as well.
- ramzyo 8y ago
  Sounds interesting - any runtimes in particular you could point out? Interested to read more about them.
LeifCarrotson 8y ago
I built such a system for a PIC32 in a previous job. When it was online, we'd connect to it over Ethernet and send it firmware updates that it would burn to an external SPI flash chip (we used it for testing communications protocols with a wide variety of products, and it needed frequent firmware updates). If one of these updates had a bug and bricked the controller, it was a hassle (not to mention downtime!) to remove it from the machines on the production floor and bring it back to engineering to plug in the dedicated programming device. So we set up the SPI flash to store two copies of the firmware. If it went down, you could reset it while holding down a "restore last-known-good firmware" button, and the boot routine would reflash the on-board flash memory with the previous copy of the firmware from the SPI flash. I wouldn't do this every time you needed to power cycle it - but on a per-revision level it was very useful!
alxlaz 8y ago
> Made me wonder if it would make sense on these SoC targets to dynamically load a program from external storage and write into internal flash for execution, then start running it without a reboot. There is less reason for this today because high-capacity, high write-count storage is cheap. But I have seen it done, e.g. in order to retrofit redundant firmware update schemes on devices that do not originally support it. A long time ago I looked into something like this for one of the devices I was working on at the time (the firmware was stored in the internal flash of the MCU, but was steadily growing, and we'd eventually run out of space to hold two copies; however, we also had a larger, cheaper, slower external flash that we could use). The write cycles cap of flash devices can make it a bad idea under some scenarios, but that's a decision you make on a case-by-case basis. ZOMG THIS IS FLASH DO NOT REWRITE IT is not exactly a clever design solution.
- kevin_thibedeau 8y ago
  Integrated NOR flash still commonly tops out at 100K erases. Not something you'd want to be doing as an integral part of an OS execution model.
ChuckMcM 8y ago
Some of these SoC targets (like the STM32F4x9 series) have SDRAM controllers so you can put 4 - 16MB of RAM on them.

by unwind 8y ago

berti 8y ago

You could exec from SRAM if you have enough to spare (larger Cortex M4/M7 uCs have 256k+, RetroBSD claims to only need 128k of that).

unwind 8y ago
Yes, of course, I've done that. It was the idea of treating on-board flash as a load-target for temporary programs that felt fun.
- dbuder 8y ago
  I would do it on an external NOR chip, to which the usual response is, at that point, just get a proper microprocessor.

monocasa 8y ago

I'd be hesitant, as those flash banks aren't rated for more than 1000 or so writes over their lifetime. I've killed the internal flash in a few Arduinos and STM32s just from development/testing.

exikyut 8y ago
Hm. Makes me think how many (few) bytes you could fit a "if a specific interrupt is received then copy bytes from wire to RAM and run that instead" preamble into the bootloader. Presuming "killed" means "won't accept new updates but will read" (?), you could then continue to use the chip.

derefr 8y ago

This is, essentially, what the older generation of “flash carts” for game consoles do. Each new loaded game ROM gives you a progress bar as the cart performs an erase/program cycle to its flash. (The newer generation just copies the ROM to memory.)

okl 8y ago

There are several runtimes for microcontrollers that feature an elf/hex loader for static binaries, or a bootloader that retrieves a program and executes it in RAM. Sometimes you can re-enter the bootloader from your application software. On some embedded systems (satellite OBSW comes to mind) you can actually hot-patch the code function-by-function while running. You compile/link the software with some extra space before and after your functions for future modifications. Then when you patch, you have to make sure that the modified code is locked out and that the variables used by the functions being patched are in an acceptable state as well as the cache. Whether all of that extra effort makes sense? - it depends. But in most embedded projects you can just flash a new firmware and avoid the overhead of executing from RAM. (Depending on your target, flash might have a separate memory bus and could be one or two clock cycles faster.) Edit: Hot-patching in flash is totally possible as well.

ramzyo 8y ago
Sounds interesting - any runtimes in particular you could point out? Interested to read more about them.

LeifCarrotson 8y ago

I built such a system for a PIC32 in a previous job. When it was online, we'd connect to it over Ethernet and send it firmware updates that it would burn to an external SPI flash chip (we used it for testing communications protocols with a wide variety of products, and it needed frequent firmware updates). If one of these updates had a bug and bricked the controller, it was a hassle (not to mention downtime!) to remove it from the machines on the production floor and bring it back to engineering to plug in the dedicated programming device. So we set up the SPI flash to store two copies of the firmware. If it went down, you could reset it while holding down a "restore last-known-good firmware" button, and the boot routine would reflash the on-board flash memory with the previous copy of the firmware from the SPI flash. I wouldn't do this every time you needed to power cycle it - but on a per-revision level it was very useful!

alxlaz 8y ago

> Made me wonder if it would make sense on these SoC targets to dynamically load a program from external storage and write into internal flash for execution, then start running it without a reboot. There is less reason for this today because high-capacity, high write-count storage is cheap. But I have seen it done, e.g. in order to retrofit redundant firmware update schemes on devices that do not originally support it. A long time ago I looked into something like this for one of the devices I was working on at the time (the firmware was stored in the internal flash of the MCU, but was steadily growing, and we'd eventually run out of space to hold two copies; however, we also had a larger, cheaper, slower external flash that we could use). The write cycles cap of flash devices can make it a bad idea under some scenarios, but that's a decision you make on a case-by-case basis. ZOMG THIS IS FLASH DO NOT REWRITE IT is not exactly a clever design solution.

kevin_thibedeau 8y ago
Integrated NOR flash still commonly tops out at 100K erases. Not something you'd want to be doing as an integral part of an OS execution model.

ChuckMcM 8y ago

Some of these SoC targets (like the STM32F4x9 series) have SDRAM controllers so you can put 4 - 16MB of RAM on them.