For RISC-V (and other hypothetical architectures) which do not support the FDPIC relocations we need for arbitrary app placement, we need some other mechanism for enabling multiple applications on a board. One potential approach is to compile an application once, and then link it for some number of different flash and memory positions on the board, and then at deploy time choose a suitable matching location and linked binary.

Steps to implement this:

• Choose an "N", the number of flash locations, and a "K", the number of RAM locations. Then also choose what those addresses should be.
• Add support in the make infrastructure to do the linking to different locations.
• Update crt0.c to not do relocation setup for non PIC apps.
• Update the TBF header to denote apps with fixed locations.
  • Probably will need to know the memory address to use.
• Extend the TAB format to support multiple copies of a binary for the same architecture.
• Update tockloader
  • Add support for TABs with multi-linked binaries.
  • Choose the correct multi-linked binary
  • Add support for creating padding apps which may be necessary.
• Update the kernel to know that it has to put certain application RAM in certain locations.

Downsides I see so far

• Installing new apps may not work as well as before. Tockloader right now will happily just move an application to fit a new application, and this will obviously not work with "NxK" apps. We will have to handle this somehow.