Property:Multi-EVA

---

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

Research

---

Term

Term:	Multi-EVA	Wiki	Freetz	IPPF	whmf	AVM	Web
Short for:	Multi-Instance EVA Bootloader
Location:	Lexicon >> FRITZ-Terms
Weblinks:
Description:	Multi-Instance EVA Bootloader

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

Details

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.

FRITZ!OS

mtd2size

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, fsgw - 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:

ARM

This is research in progress and may be partially or completely wrong.

Hawkeye, 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:
    • TrustZone - located in flash
    • EVA - located in flash - loading:
      • FRITZ!OS - located in flash

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, Dakota, Maple)

• Lexicon: PBL, SBL, TrustZone, EVA
• Procfs: sbl_version, sbl_reboot, struct_version
• 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
• Kconfig: CONFIG_AVM_FASTIRQ, CONFIG_AVM_TZ_EXTENSIONS, CONFIG_QSEECOM
• Kernel: avm_sbl.ko, avm_tz.ko, qseecom.ko, ipq40xx_qseecom.ko

Dakota

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

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.

SMW-Browser

Property:Multi-EVA

Information is currently being retrieved from the backend.