Skip to content

Commit aed73d0

Browse files
committed
chore: document reorder-apps
Signed-off-by: Walid Aliwi <walid.aliwi@stud.fils.upb.ro>
1 parent 65e43ff commit aed73d0

1 file changed

Lines changed: 98 additions & 0 deletions

File tree

docs/src/commands/install.md

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
# Install
2+
3+
## _reshuffle_apps(apps, preserve_order=False)
4+
5+
This internal helper function determines the **exact physical arrangement of applications in flash memory** before installing them on a Tock board.
6+
It enforces constraints from **TBF headers**, **board-specific flash/RAM layout rules**, and **MPU alignment requirements** so that the kernel can correctly discover and run applications.
7+
8+
---
9+
10+
### Purpose
11+
12+
Tock applications are stored in flash in **TBF (Tock Binary Format)** containers.
13+
Each TBF header specifies:
14+
- Whether the app is **fixed-address** (must be loaded at a specific flash/RAM address) or **position-independent** (can be loaded anywhere).
15+
- The app’s **flash size** and **RAM usage**.
16+
- MPU alignment requirements.
17+
18+
> **Note on fixed addresses and sizes:**
19+
> A fixed flash address refers to where the **TBF header itself** (and thus the whole app) must be placed in flash.
20+
> The size used for layout calculations **includes** the TBF header plus the app’s binary contents.
21+
> There is no footer — the kernel uses the total size from the header to locate the next app.
22+
23+
The kernel discovers apps by scanning flash **sequentially** from the **start-of-apps** address.
24+
Because of this, the **order and alignment** of apps in flash is critical.
25+
_reshuffle_apps() ensures:
26+
- Correct **sorting** of apps.
27+
- Proper **MPU-compliant alignment**.
28+
- Insertion of **padding** when needed.
29+
- Prevention of **flash and RAM overlaps**.
30+
31+
---
32+
33+
### Determining the Correct Order
34+
35+
The function first determines which type of applications it is dealing with.
36+
37+
#### **1. Fixed-address apps**
38+
- Compiled for **specific flash (and sometimes RAM) addresses**.
39+
- The addresses are encoded in the TBF header and cannot be changed without recompilation.
40+
- _reshuffle_apps() will:
41+
1. Sort them in **increasing flash address order**.
42+
2. Verify **no overlapping flash ranges**.
43+
3. If RAM addresses are fixed, verify **no overlapping RAM ranges**.
44+
4. Discard any app starting **before the start-of-apps address** or outside flash limits.
45+
5. Insert **padding apps** into gaps so that kernel scanning continues correctly.
46+
47+
**Why sorting by address is mandatory**
48+
The kernel loads apps like this:
49+
address = start_of_apps
50+
while valid_TBF_header_at(address):
51+
load_app()
52+
address += app_size
53+
54+
#### 2. Position-independent apps
55+
56+
- Can be placed **anywhere** in flash because they use relative addressing.
57+
- _reshuffle_apps() decides order based on:
58+
- **preserve_order=True** → Keep apps exactly in the order they are given.
59+
- **preserve_order=False**:
60+
- "size_descending" → Sort largest to smallest to reduce fragmentation.
61+
- None → Any order is acceptable.
62+
- After ordering, applies alignment rules and inserts padding when needed.
63+
64+
---
65+
66+
#### 3. Mixed fixed and position-independent
67+
68+
- **Not supported**.
69+
Mixing fixed and movable apps is complex and currently unimplemented.
70+
- If both types are detected, _reshuffle_apps() raises a TockLoaderException.
71+
72+
---
73+
74+
### Alignment and Padding
75+
76+
In this context, **alignment** means placing each app in flash at a starting address that matches certain hardware rules.
77+
These rules come from the MPU (Memory Protection Unit) or the flash controller, and they define which addresses are considered valid starting points for an app.
78+
79+
For example:
80+
- Some boards require apps to start at a multiple of their own size.
81+
- Others require starting addresses to be aligned to a power-of-two boundary (e.g., 4 KB).
82+
- Some flash chips can only write or erase in page-sized chunks.
83+
84+
If an app would start at an address that doesn’t meet these rules, `_reshuffle_apps()` inserts a **padding app** — an empty region filled with `0xFF`.
85+
This moves the start of the next real app forward until it’s at a valid aligned address.
86+
87+
Padding apps have no executable code. They simply reserve space so that:
88+
- The kernel can correctly find the next app when scanning flash.
89+
- Hardware alignment requirements are satisfied.
90+
91+
92+
### Cleaning Up Flash
93+
94+
After writing, _reshuffle_apps():
95+
96+
- Erases flash immediately after the last installed app.
97+
- Ensures the kernel detects the correct **end-of-applications**.
98+
- Prevents stray flash data from being mistaken for a valid app.

0 commit comments

Comments
 (0)