The memory reservation block lists regions of physical memory that the operating system must not use for ordinary
allocation: the Specification names tables for an IOMMU and the code of runtime firmware. It sits where the
header’s off_mem_rsvmap says. The rules are from the
Devicetree Specification, section 5.3.
Format
| Offset | Size | Field | What it holds |
|---|---|---|---|
| 0 | 8 | address | The physical address of the region, a 64-bit big-endian number. |
| 8 | 8 | size | Its size in bytes, also 64 bits. |
That pair repeats. The list ends with a pair in which both the address and the size are zero, and that terminator is part of the block. The whole block starts on an 8-byte boundary, and so does each pair. On a 32-bit processor the upper 32 bits of each number are ignored.
- The regions must not overlap.
- The blob itself may, but need not, be in a reserved region; the operating system must still not overwrite it before it has read it.
- Any memory the boot program touches after it has handed over control should be reserved.
In devicetree source a region is written /memreserve/ 0x1000 0x2000; before the root node. Many modern trees
describe reserved memory with a /reserved-memory node instead, which is part of the structure block and not of
this list.
Example
The Raspberry Pi Zero 2 W blob reserves the first 4 KiB of memory (what the file does not say is why):
00000028: 0000 0000 0000 0000 0000 0000 0000 1000 address 0, size 0x1000
00000038: 0000 0000 0000 0000 0000 0000 0000 0000 the terminating pairThe blob’s own header gives the block’s offset as 0x28, directly after the header, and the structure block
starts at 0x48, after the 32 bytes of the two pairs.
What the viewer checks
It lists the pairs (address, size and the end address), warns when the list has no terminator before the end of the blob, when the block is not 8-byte aligned, and when two regions overlap.