|BoxMatrix >> Lexicon >> FRITZ-Terms >> Multi-EVA||@|
|Short for:||Multi-Instance EVA Bootloader|
|Location:||Lexicon >> FRITZ-Terms|
|Description:||Multi-Instance EVA Bootloader|
Initially all models used NOR-Flash, with limited size and a single EVA (formerly ADAM2) at the beginning of it.
The CPU directly starts the bootloader after powerup and it's the first intelligent thing which happens.
To keep the reliability of their brand (5 years warranty on routers) they decided to store multuple instances of FRITZ!OS.
Dual-Boot was introduced, storing 2 Filesystem and 2 Kernel instances, and a hybrid TFFS design with S-Flash.
If a partition breaks due to aging or loss of power during an update there is still a second working instance as fallback.
But this did not work for the bootloader with early SoCs, which requires a hardware dependend fixed start address at powerup.
With later SoCs it was possible (or necessary) to run portions of code and store its config before the Bootloader is executed.
This was the birth of a Multi-EVA solution, finally providing a safe way to update the bootloader.
How this is designed is platform and architecture dependend and will be researched and explained here separately.
Multi-EVA models can be detected by the mtd2size. Single-EVA models use 64 KB - 256 KB for the bootloader partition mtd2.
For models with multiple EVA instances mtd2 is always at least 1 MB, up to currently 32 MB. Current mtd2size ranking:
32,768 KB- 4060, 5590, 6000 - Hawkeye - ARM - FIT-Image
5,376 KB- 7510, 1200ax, 3000ax - Maple - ARM - FIT-Image
2,816 KB- 6850lte, 68505g, 7520, 7520v2, 7530ac, 1200, 3000, 1260 - Dakota - ARM
2,048 KB- 6591, 6660, 6690 - Puma7 - ATOM + ARM
2,048 KB- 7530ax, 7581, 7583 - BCM63 - ARM - 7530ax is FIT-Image
1,536 KB- 5530 - Falcon - MIPS - FIT-Image
1,152 KB- 4040, 1260e - Dakota - ARM
1,024 KB- 6890v1, 6890v2, 7590, 7560, 7580, 7583gfast, 7583vdsl, 7590ac, 7590ax, 7590axv2 - Seale - MIPS
As you see there are at least 3 architectures to explain. Let's start with generic ARM:
This is research in progress and may be partially or completely wrong.
These ARM SoCs all support SecureBoot, with hardware-enforced isolation of trusted and untrusted execution environments.
This is implemented by the ability to split each core into a virtual core for the secure world and the normal world each.
Booting happpens in multiple stages. Raw principle:
- PBL - Primary Bootloader - located on-chip (SecureCore) - loading:
- Lexicon: PBL, SBL, TrustZone, EVA
- Procfs: sbl_version, sbl_reboot
- Procfs: sbl_fault_register, sbl_reset_debug, sbl_wdog_status, sbl_wonce
- Procfs: tz0_verified, tz0_version, tz1_verified, tz1_version
- Procfs: tz_boot_ack, tz_boot_index, tz_version
- Procfs: eva0_verified, eva0_version, eva1_verified, eva1_version
- Procfs: eva_boot_ack, eva_boot_index
- Firmware: sblupdate, tzupdate, urladerupdate
- Commands: tz_update
- Startup: E02-tz_update, cortexa9, cortexa9.service
- Partitions: GPT, alignto512, SBL1, MIBIB, BOOTCONFIG, BOOTCONFIG1
- Partitions: QSEE, QSEE_1, DEVCFG, DEVCFG_1, RPM, RPM_1, CDT, CDT_1
- Partitions: APPSBL, APPSBL_1, CONFIG, CONFIG_1
- Kernel: qseecom.ko
Dakota models store 1 instance of the SBL, 2 instances of the TrustZone and 2 instances of EVA in the mtd2 partition.
The SBL loads the device-tree (located where?) and initializes the hardware, before signature checking and executing EVA.
Hawkeye models also store 1 instance of the SBL, 2 instances of the TrustZone and 2 instances of EVA but in eMMC partitions.
The SBL loads the device-tree from the FIT-Image and initializes the hardware, before signature checking and executing EVA.
Showing 1 related property.