If you like BoxMatrix then please contribute Supportdata, Supportdata2, Firmware and/or Hardware (get in touch).
My metamonk@yahoo.com is not reachable by me since years. Please use hippie2000@webnmail.de instead.



From BoxMatrix

BoxMatrix >> Lexicon >> FRITZ-Terms >> Multi-EVA @ BoxMatrix   -   IRC-Chat   -   Translate: de es fr it nl pl
News Selectors Models Accessories Components Environment Config Commands System Webif Software Develop Lexicon Community Project Media

Computer FRITZ I18N Telephony Smarthome Internet Protocols Multimedia Formats Hardware Software Research


Goto:   FRITZ!OS   -   mtd2size  -  ARM  -  SMW-Browser


A Multi-EVA is the symbolic term for multiple EVA Bootloader instances.
EVA is the AVM developed Bootloader which launches FRITZ!OS since more than a decade.

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.

With the increasing complexity of FRITZ!OS more space was required. AVM decided to use NAND-Flash.
The disadvantage of NAND-Flash is that it's aging way faster than NOR-Flash.

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:

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.

Hawkeye, Miami, Maple and Dakota will be explained here as generic ARM boot. BCM63 is likely special.

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.

The secure world runs the TrustZone OS, for monitoring and for providing security and crypto services to the normal world.
The normal world runs the application OS, here EVA booting FRITZ!OS.

Booting happpens in multiple stages. Raw principle:

  • PBL - Primary Bootloader - located on-chip (SecureCore) - loading:
    • SBL - Secondary Bootloader - located in flash - loading:

All these have a "chain of trust", checking the signature of the respective next stage before execution.
This chain includes EVA, which could not be modified without getting signed by AVM.

Multi-EVA boot on Qualcomm ARM: (Hawkeye, Alder, Miami, Dakota, Maple)


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.

Details about the 7520v1 bootloader partition could be found in the SBL article:


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.


Information is currently being retrieved from the backend.


Showing 1 related property.