Le mar. 26 mai 2020 à 16:38, Grant Likely grant.likely@arm.com a écrit :
On 26/05/2020 15:30, François Ozog wrote:
On Mon, 25 May 2020 at 21:55, Grant Likely <grant.likely@arm.com mailto:grant.likely@arm.com> wrote:
[...]
MBR partitioning ^^^^^^^^^^^^^^^^ -Protective partitions should have a partition type of 0xF8 unless
some
+If firmware is at a fixed location entirely within the first 1MiB of +storage (<= LBA2047) then no protective partitions are required. +If firmware resides in a fixed location outside the first 1MiB, +then a protective partition must be used to cover the firmware LBAs. +Protective partitions should have a partition type of 0xF8 unless an immutable feature of the platform makes this impossible. +OS partitioning tools must not create partitions in the first 1MiB +of the storage device, and must not remove protective partitions.
For the boards I work on, fixed locations FIP with (TFA+DDR+SCP+U-Boot) are 1.5MB. Adding OP-TEE and StandaloneMM to get UEFI SecureBoot we are getting close to 4MB. If we add firmwareTPM and measuredBoot, I assume we will reach 4MB. So I wonder if the right value shouldn't be 32MiB (rationale is 4MB/Page rounding; future growth to 8MB; A/B versions:16MB; 2x margin: 32MiB).
The thinking here is that existing partitioning tools already avoid the first 1MiB of storage by default, so there isn't a massive impact to get distro tooling changed. If a larger limit was chosen then we've got a lot of tooling that needs to be changed, assuming we can get the maintainers of those tools to agree to avoid a larger number of LBAs at the base of storage.
However, in the case that you're describing it is probably possible to switch to GPT partitioning because the firmware image is at a fixed location (unless the fixed firmware begins at LBA1) and the loaded firmware image can be taught to understand GPT.
ROM That I deal with have this tendency to be stubborn and start loading at LBA1 ;-) so no GPT. Isn’t there a good opportunity to say “recommend” instead of must/shall. Otherwise tool projects can’t get their cues from reliable sources.
g.
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog