Cortex-m App Flashing: Ordering and Padding Improvements

[tyler-potyondy]

Overview

This PR updates the logic when inspecting the tab of cortex-m apps to use mpu subregions for apps larger than 64kB. This helps prevent wasted space vs rounding to the nearest power of two. Additionally, this introduces a change to default to flashing applications in ascending order (there are tradeoffs to this vs descending discussed below).

Flashing Application Before Changes

Attempting to install ~85kB lorawan application results in Tockloader only being able to flash one application.

 0x8016800┬──────────────────────────────────────────────────┐
          │Padding                                           
          │  Length: 38912 (0x9800)                          
 0x8020000┼──────────────────────────────────────────────────┤
          │App: lorawan                          [Installed]
          │  Length: 131072 (0x20000)                        
 0x8040000┴──────────────────────────────────────────────────┘

Flashing Application After Changes

Able to flash many applications with lorawan application.

 0x8018000┬──────────────────────────────────────────────────┐
          │App: c_hello                           [Installed]
          │  Length: 4096 (0x1000)                       
 0x8019000┼──────────────────────────────────────────────────┤
          │Padding                                           
          │  Length: 12288 (0x3000)                          
 0x801c000┼──────────────────────────────────────────────────┤
          │App: blink                             [Installed]
          │  Length: 16384 (0x4000)                          
 0x8020000┼──────────────────────────────────────────────────┤
          │Padding                                           
          │  Length: 32768 (0x8000)                          
 0x8028000┼──────────────────────────────────────────────────┤
          │App: lorawan                           [Installed]
          │  Length: 98304 (0x18000)                         
 0x8040000┴──────────────────────────────────────────────────┘

Ascending vs Descending Ordering

When flashing applications in descending order, we minimize fragmentation with smaller applications. For instance, flashing in the order: c_hello and then blink in descending order would not result in fragmentation. This is true so long as we follow a strict power of two rounding.

With the introduction of using subregions in this PR, apps larger than 64kB are no longer powers of two (resulting in larger padding before applications).

There does not seem to be a one size fits all solution for ascending vs descending (as there are cases where each might be better). I lean towards the ascending order as fragmentation with larger apps requiring padding often is much larger than the fragmentation arising from padding smaller applications. In my opinion it seems we should prioritize many small fragmentation (ascending order) so long as this is smaller than the fragmentation arising from descending order (open to counter examples where this may not be true).