Process loading: applications' FLASH order must be the same as RAM order; otherwise loading fails for some

[wprzytula]

I have 2 apps:
console: flash=0x00012000-0x00014000 ram=0x20003000-0x20003CFB
blink: flash=0x00010000-0x00012000 ram=0x20004000-0x20004EFB
(as you can see, console is earlier in RAM but later in FLASH than blink)

When I disable blink by tockloader, console loads fine:

Loading processes from flash=0x00010000-0x0001FFA7 into sram=0x20002664-0x20004FFF
Loading process binary from flash=0x00010000-0x0001FFA7
Process not enabled flash=0x00010000-0x00011FFF process="blink"
Loading process binary from flash=0x00012000-0x0001FFA7
Loading: process flash=0x00012000-0x00013FFF ram=0x20002664-0x20004FFF
Loading: console [0] flash=0x00012000-0x00014000 ram=0x20003000-0x20003CFB
Loaded process console
Loading process binary from flash=0x00014000-0x0001FFA7
No more processes to load: Could not find TBF header.
Hello world!

However, having both apps enabled yields:

Loading processes from flash=0x00010000-0x0001FFA7 into sram=0x20002664-0x20004FFF
Loading process binary from flash=0x00010000-0x0001FFA7
Loading: process flash=0x00010000-0x00011FFF ram=0x20002664-0x20004FFF
Loading: blink [0] flash=0x00010000-0x00012000 ram=0x20004000-0x20004EFB
Loaded process blink
Loading process binary from flash=0x00012000-0x0001FFA7
Loading: process flash=0x00012000-0x00013FFF ram=0x20004EFC-0x20004FFF
Processes load error: App memory does not match requested address Actual:0x20004efc, Expected:0x20003000.
Loading process binary from flash=0x00014000-0x0001FFA7
No more processes to load: Could not find TBF header.

It's clear that Tock forgets that there is a hole in RAM between SAPPS and blink that is perfect for console's requirements.

Is it thus necessary for the apps to have RAM order consistent with FLASH order?
Should it be so?

[wprzytula]

@alevy

[bradjc]

Having the RAM order match the flash order is not required for correct operation. It is required for the current implementation of the kernel and how processes are loaded.

This becomes a tradeoff with kernel complexity/size and ergonomics for fixed-address apps. Because Tock works best with PIC apps, we do support fixed address apps, but not extensively, and instead push some of the burden onto the host/app loading side.