Skip to content

earlgrey: Support 88K ROM_EXT variant for transport firmware and expand test suites - #440

Open
anthonychen1251 wants to merge 3 commits into
OpenPRoT:earlgrey-hwefrom
anthonychen1251:support-88K-rom-ext-transport-fw
Open

earlgrey: Support 88K ROM_EXT variant for transport firmware and expand test suites#440
anthonychen1251 wants to merge 3 commits into
OpenPRoT:earlgrey-hwefrom
anthonychen1251:support-88K-rom-ext-transport-fw

Conversation

@anthonychen1251

Copy link
Copy Markdown

This PR adds support for building and testing an 88 KiB (0x16000) base address variant of the OpenTitan Earlgrey transport firmware alongside the standard 64 KiB variant, and integrates the 88 KiB variant into the DFU and Update Manager test suites.

Upstream OpenTitan ROM_EXT supports searching for owner software at multiple bank offsets (88 * 1024 and 64 * 1024). Building the transport firmware with an 88 KiB offset produces a manifest with manifest_base_addr = 0xA0016000, enabling ROM_EXT to locate and boot the image at the 88 KiB flash boundary.

Note: this depends on #439 Only review the last 2 commits.

Update the `opentitan_devbundle` dependency in `MODULE.bazel` to point to the
official upstream release `devbundle-2026-08-21-1` from GitHub.

Additionally, set `HOME=/tmp` in the `OtpImageAssemble` action in
`target/earlgrey/env/environments.bzl`. In hermetic Bazel sandbox environments
where `HOME` is unset, `opentitantool` falls back to glibc's `getpwuid_r()`,
which dynamically `dlopen()`s host NSS libraries and crashes (SIGSEGV) due to
a glibc ABI mismatch between the static binary and the host libc. Providing
`HOME` prevents the NSS lookup.

Signed-off-by: Anthony Chen <antchen@google.com>
Support an 88 KiB (0x16000) ROM_EXT / offset variant of the OpenTitan
Earlgrey transport firmware, allowing the firmware image's manifest base
address (`manifest_base_addr` in the manifest header) to evaluate to
`0xA0016000`.

1. target.ld.jinja: Parameterize ROM_EXT and FLASH memory region sizes
   dynamically from `kernel.flash_start_address` using named Jinja
   constants (`FLASH_REMAP_BASE = 0xA0000000`, `FLASH_SLOT_SIZE = 0x80000`)
   instead of hardcoding 64 KiB.
2. tooling/system_config: Add `system_config_variant` Starlark rule and
   `system_config_override.py` tool to derive system configuration variants
   from `system.json5` on-the-fly, keeping `system.json5` as the single
   source of truth for application and process topology.
3. transport/BUILD.bazel: Add `:transport_firmware_88k` and
   `:no_panics_88k` targets alongside default 64 KiB targets.

Signed-off-by: Anthony Chen <antchen@google.com>
…dfu tests

Introduce `:transport_firmware_signed_88k` signed targets and expand
the test matrices in `tests/updatemgr/BUILD.bazel` and `tests/dfu/BUILD.bazel`
to test both 64 KiB and 88 KiB transport firmware variants.

Signed-off-by: Anthony Chen <antchen@google.com>
@anthonychen1251

Copy link
Copy Markdown
Author

Here is a summary of the end-to-end (E2E) test suites for the current Transport Firmware:

1. USB DFU Suite (tests/dfu)

  • Owner Transfer Scenario (dfu_owner_transfer):
    Tests the device ownership transfer functionality via USB DFU. It validates that a host can stream a signed owner-transfer package to a device running Transport Firmware, causing the silicon to update its owner key.
  • Firmware Update Scenario (dfu_firmware_update):
    Tests the in-field firmware update functionality via USB DFU. It validates that a host can update the application image on a device running Transport Firmware without changing device ownership, verifying that the new firmware boots successfully

2. Update Manager EEPROM Suite (tests/updatemgr)

  • EEPROM Owner Transfer Scenario (updatemgr_eeprom_owner_transfer):
    Tests the asynchronous ownership transfer flow staged via external EEPROM. It validates that an owner-transfer package pre-staged into SPI EEPROM is detected and applied by Transport Firmware's Update Manager on boot, correctly performing the ownership handover (ownership_transfers: 1) across different flash slot configurations (slot_aa, slot_ab, slot_ba, slot_bb).

  • EEPROM Firmware Update Scenario (updatemgr_eeprom_firmware_update):
    Tests the asynchronous in-field firmware update flow staged via external EEPROM. It validates that an application update pre-staged into SPI EEPROM is detected and programmed into the target internal flash slot by the Update Manager, successfully executing the new application while maintaining existing ownership (ownership_transfers: 0).

Both test suites tested against 64 KiB (manifest_base_addr = 0xA0010000) and 88 KiB (manifest_base_addr = 0xA0016000) Transport Firmware offset variants with this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant