Verify that ROM can boot a ROM_EXT with default infrastructure configurations.

• The valid ROM_EXT should be a test program that returns true, optimizing for speed.
• The test program should be launched via the OTTF.

Verify that ROM can boot a ROM_EXT with default OTP values (all zeroes).

• Create an OTP with all zeros except:
  • CREATOR_SW_CFG_ROM_EXEC_EN set to 0xffffffff (enabled)
  • LC_STATE in the TEST_UNLOCKED0 state
  • LIFE_CYCLE count value set to 1
• Ensure that the ROM can boot.

Verify that ROM can properly report errors over UART.

• Attempt to boot without a valid ROM_EXT.
• Verify that we can receive the 28 character long (BFV:xxxxxxxx\r\nLCV:xxxxxxxx\r\n) error output in all life cycle states where Ibex is enabled, i.e. TEST_UNLOCKED*, PROD, PROD_END, DEV, and RMA.
  • BFV should be 0142500d for all life cycle states.
  • See the table below for the expected LCV value.

Verify that ROM redacts errors properly.

• Attempt to boot without a valid ROM_EXT.
• Verify that there is no redaction in TEST_UNLOCKED* and RMA.
• For DEV, PROD, and PROD_END:
  • Verify that BFV value is redacted according to the ROM_ERROR_REPORTING OTP item.

Verify that ROM configures the watchdog properly.

• Attempt to boot with a valid ROM_EXT.
  • ROM_EXT needs to print something and busy loop (bounded) until watchdog resets the chip.
• Verify that the chip does not reset in TEST and RMA.
• For DEV, PROD, and PROD_END:
  • Verify that the chip resets when the WATCHDOG_BITE_THRESHOLD_CYCLES OTP item is 0x00061a80 (2 s).
  • Verify that watchdog is disabled when WATCHDOG_BITE_THRESHOLD_CYCLES is 0.

Verify that ROM asm exception handler resets the chip.

• Power on with the CREATOR_SW_CFG_ROM_EXEC_EN OTP item set to 0.
  • Execution should halt very early in _rom_start_boot.
• Connect the debugger and set a breakpoint at _asm_exception_handler.
  • Note: We need to use a debugger for this test since mtvec points to C handlers when rom_main() starts executing.
• Set pc to 0x10000000 (start of main SRAM) and execute one machine instruction, i.e. stepi.
• Verify that execution stops at _asm_exception_handler since code execution from SRAM is not enabled.
• Continue and verify that the asm exception handler resets the chip by confirming that execution halts at _rom_start_boot.

Verify that ROM C exception handler triggers shutdown.

• Boot a valid fake ROM_EXT that doesn't register any interrupt handlers.
• Trigger an exception in the second stage.
  • Set pc to 0x10000000 (start of main SRAM). This should trigger an exception since code execution from SRAM is not enabled.
• Verify that the chip resets with the correct BFV: 01495202, i.e. instruction access fault in the interrupt module.

Verify that alerts trigger a chip reset when enabled.

• For PROD, PROD_END, DEV, and RMA life cycle states
  • Use an OTP image with an alert enabled.
• Boot a ROM_EXT that triggers this alert by writing to a ALERT_TEST register.
• Verify that ROM_EXT boots and the chip resets after the write to the ALERT_TEST register.

Verify that ROM enters bootstrap when enabled in OTP and requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip reports bootstrap:1 over the UART.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.

Verify that ROM does not enter bootstrap when enabled in OTP but not requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Do not apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV.
• Verify that the chip does not respond to READ_SFDP (0x5a).

Verify that ROM does not enter bootstrap when disabled in OTP but requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolFalse (0x1d4).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_STATUS (0x05).
  • The data on the CIPO line must be 0xff.

Verify that ROM does not enter bootstrap when disabled in OTP and not requested.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolFalse (0x1d4).

• Do not apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_STATUS (0x05).
  • The data on the CIPO line must be 0xff.

Verify that bootstrap handles READ_STATUS correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.

See rom_e2e_bootstrap_enabled_requested.

Verify that watchdog is disabled upon entering bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739). OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES OTP item must be 0x30d40

• For TEST, DEV, PROD, PROD_END, and RMA life cycle states:
  • Apply bootstrap pin strapping.
  • Reset the chip.
  • Verify that the chip responds to READ_SFDP (0x5a) correctly.
  • Release bootstrap pin strapping and wait for 2 seconds.
    • Note: Watchdog is always disabled in TEST and RMA. In other states, the threshold is set to OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES.
  • Verify that the chip responds to READ_SFDP (0x5a) correctly.
  • Verify that there was no output from UART.

Verify the JEDEC ID used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_JEDEC_ID (0x9f) with
  • 12 repetitions of the continuation code 0x7f,
  • manufacturer ID 0xef,
  • device ID 0x08, and
  • density 0x14.

Verify the SFDP table used during bootstrap.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_SFDP (0x5a).
• Verify the SFDP header structure. See this document.
• Verify the JEDEC Basic Flash Parameter Table. See this spreadsheet.

Verify that bootstrap handles WRITE_ENABLE (0x06) and WRITE_DISABLE (0x04).

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.
• Send WRITE_ENABLE (0x06) and READ_STATUS (0x05).
• Verify that the chip responds with the WEL bit set, i.e. 0x02.
• Send WRITE_DISABLE (0x04) and READ_STATUS (0x05).
• Verify that the chip responds with 0x00.

Verify that bootstrap phase 1 ignores RESET (0x99).

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Send RESET (0x99).
• Verify that the chip does not output anything over UART for at least 1 s.

Verify that bootstrap phase 1 ignores PAGE_PROGRAM (0x02).

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping.
• Reset the chip.
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART (`kErrorBootPolicyBadIdentifier').
  • If the write succeeds, which shouldn't happen, ROM outputs 0242500d (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that bootstrap phase 1 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
  • Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
    • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
    • ROM will continously reset the chip and output the same BFV and LCV.
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0142500d over UART (kErrorBootPolicyBadIdentifier).
    • ROM will continously reset the chip and output the same BFV and LCV.

Verify that phase 1 of bootstrap ignores READ (0x03).

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Reset the chip.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.
• Apply bootstrap pin strapping and reset the chip.
• Verify that the chip responds to READ_STATUS (0x05) with 0x00.
• Send READ (0x03) followed by the 3-byte address 0x80330.
  • This is the start address of the write operation performed above.
• Verify that the data on the CIPO line does not match 0x4552544f_00000000.

Verify that bootstrap phase 2 handles RESET (0x99) correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase transition to phase 2.
• Release pins and send RESET (0x99).
• Verify that the chip outputs the expected BFV: 0142500d over UART (kErrorBootPolicyBadIdentifier).
  • ROM will continously reset the chip and output the same BFV and LCV.
• Verify that the chip does not respond to READ_SFDP (0x5a).

Verify that bootstrap phase 2 handles PAGE_PROGRAM (0x02) correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• Release pins and reset.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that bootstrap phase 2 handles erase commands correctly.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• For erase in {SECTOR_ERASE (0x20), CHIP_ERASE (0xc7)}:
  • Apply bootstrap pin strapping and reset the chip.
  • Send erase.
    • For SECTOR_ERASE (0x20) use the lowest page-aligned address, i.e. 0x80000.
  • Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
    • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
  • Send erase.
  • Release pins and reset.
  • Verify that the chip outputs the expected BFV: 0142500d over UART (rom_e2e_bootstrap_phase2_page_program).
    • ROM will continously reset the chip and output the same BFV and LCV.

Verify that phase 2 of bootstrap ignores READ (0x03).

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• Apply bootstrap pin strapping and reset the chip.
• Send CHIP_ERASE (0xc7).
• Write 0x4552544f_00000000 (ASCII "\0\0\0\0OTRE") at byte offset 0x80330.
  • Note: Writes must start at a flash-word-aligned address and we must write to the second slot since ROM returns the last error.
• READ (0x03) 8 bytes starting at 0x080330.
  • This is the address of the identifier that was written earlier.
• Verify that the response is not equal to 0x4552544f_00000000.
• Release pins and reset.
• Verify that the chip outputs the expected BFV: 0242500d over UART (kErrorBootPolicyBadLength).
  • ROM will continously reset the chip and output the same BFV and LCV.

Verify that invalid addresses trigger shutdown.

OWNER_SW_CFG_ROM_BOOTSTRAP_DIS OTP item must not be kHardenedBoolTrue (0x739).

• For command in {SECTOR_ERASE (0xc7) and PAGE_PROGRAM (0x02)}
  • Apply bootstrap pin strapping and reset the chip.
  • Send CHIP_ERASE command to transition to bootstrap phase 2.
  • Send command with an invalid 3-byte address, e.g. 0xffffff.
  • Verify that the chip outputs the expected BFV over UART.
    • For SECTOR_ERASE: BFV:01425303 (kErrorBootstrapEraseAddress) followed by BFV:0142500d (kErrorBootPolicyBadIdentifier)
    • For PAGE_PROGRAM: BFV:02425303 (kErrorBootstrapProgramAddress) followed by BFV:0142500d (kErrorBootPolicyBadIdentifier)

Verify that ROM triggers shutdown when there is no valid ROM_EXT.

• Reset the chip.
• Verify that the chip outputs the expected BFV: 0142500d over UART.
  • ROM will continously reset the chip and output the same BFV and LCV.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM chooses the slot with the greater security version.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip.
• Verify that ROM chooses the slot with the greater security version.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM performs some basic checks on manifest fields.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 1, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• For slot in {slot_a, slot_b}
  • Write the image to slot.
    • The other slot remains empty.
  • Verify that the chip outputs the expected BFV over UART.
  • Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM chooses the slot with the valid signature.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- same security_version.
• Verify that ROM chooses the slot with the valid signature, otherwise triggers a shutdown.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM rejects rollbacks.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 1, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- valid signatures.
• Verify that ROM chooses the slot with acceptable & newer seurity version, otherwise triggers a shutdown.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM can use the default boot data when configured to do so.

• Apply bootstrap pin strapping and reset the chip.
• Write the ROM_EXT images to the chip -- valid signature, security version = 2.
• Verify that ROM boots the slot when boot data is available.
• Repeat for all life cycle states: TEST, DEV, PROD, PROD_END, and RMA.

Verify that ROM performs signature verification in all life cycle states.

• Prepare a ROM_EXT image with a valid signature generated using an authorized key.
• Flip a bit/make all zeros/make all ones at random.
  • Log so that test can be reproduced.
• Apply bootstrap pin strapping and reset the chip.
• Load the image.
• Verify that boot fails with the expected BFV: kErrorSigverifyBadRsaSignature.
• Repeat the steps above for TEST, DEV, PROD, PROD_END, and RMA.

See rom_e2e_boot_policy_valid.

Verify that ROM only uses authorized keys for signature verification.

• Prepare a ROM_EXT image with a valid signature generated using an unauthorized key.
• Attempt to boot.
• Verify that boot fails with BFV:kErrorSigverifyBadKey.

Verify that ROM only uses authorized keys that are not invalidated.

• For each key entry in CREATOR_SW_CFG_SIGVERIFY_RSA_KEY_EN,
  • Invalidate the key by setting the entry to a value other than kHardenedBoolTrue.
  • Prepare a ROM_EXT image with a valid signature generated using the invalidated key.
  • Verify that boot fails with BFV:kErrorSigverifyBadKey

Verify that ROM only uses appropriate key types for each life cycle state.

• For each life cycle state and key type,
  • Prepare a ROM_EXT image with a valid signature generated using a key of that type.
  • Verify that boot fails with BFV:kErrorSigverifyBadKey or succeeds depending on the life cycle state and key type. See the table below.

Verify that ROM can verify signatures using both implementations of mod_exp.

Note: The chip can be in any life cycle state except TEST since we use the software implementation without reading from the OTP in TEST.

• Prepare a ROM_EXT image with a valid signature generated using an authorized key.
• Apply bootstrap pin strapping and reset the chip and load the image.
• Verify that boot succeeeds. Repeat with the following values:

Verify that ROM enforces usage constraints.

• Generate an otherwise valid ROM_EXT image for the following cases:
  • No constraints specified
  • Constrained to a specific device ID
    • Device ID matches
    • Device ID doesn't match
  • Constrained to a family of devices
    • Device ID matches
    • Device ID doesn't match
  • Constrained to TEST, DEV, PROD, PROD_END, RMA
    • Life cycle state matches
    • Life cycle state doesn't match
  • Constrained to a creator manufacturing state
    • CREATOR_SW_CFG_MANUF_STATE matches
    • CREATOR_SW_CFG_MANUF_STATE doesn't match
  • Constrained to an owner manufacturing state
    • OWNER_SW_CFG_MANUF_STATE matches
    • OWNER_SW_CFG_MANUF_STATE doesn't match
  • All constraints specified
  • Corrupt usage constraints data, e.g. wrong unselected word value.

Verify that all address translation configurations work.

• Bootstrap the chip with a valid second stage image. See the table below.
• Verify that the chip behaves as expected.

Verify that ROM can be debugged in appropriate life cycle states.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0.

• Verify that ROM cannot be debugged in PROD and PROD_END.

Verify that ROM_EXT can be upgraded.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 0, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Load a ROM_EXT image that will
  • print the current minimum required security version,
    • The initial value of the minimum required security version should be 0.
  • increment it to 1, and
  • reset the chip.
• Verify that the minium required security version is incremented using UART output.
• Load a ROM_EXT with securiy version = 0.
• Verify that ROM fails to boot with BFV:kErrorBootPolicyRollback.

Verify that an interrupted upgrade does not brick the chip.

CREATOR_SW_CFG_MIN_SEC_VER_ROM_EXT OTP item should be 0, and CREATOR_SW_CFG_DEFAULT_BOOT_DATA_IN_PROD should be kHardenedBoolTrue for PROD and PROD_END for the sake of simplicity.

• Load a ROM_EXT image that will
  • print the current minimum required security version,
    • The initial value of the minimum required security version should be 0.
  • increment the minimum required security version, and
  • reset the chip while flash is being accessed.
• Verify that the chip can boot after first attempt.
• Verify that ROM_EXT can detect the interruption and increment the minimum required security version.

Verify that asm interrupt handler resets the chip.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set a breakpoint on the asm handler.
• Trigger an exception, e.g. by setting PC to an address (end of ROM) that will trigger an instruction access fault.
• Verify that execution breaks at the asm handler.

Verify that watchdog is initialized in rom_start.S.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set breakpoints on right after watchdog is initialized in rom_start.S and the asm handler.
• Wait until execution breaks at the first breakpoint, wait ~1s before continuing.
• Verify that watchdog expires and execution breaks at the asm handler.

Verify that rom_start.S configures the ROM C interrupt handler and it triggers shutdown.

Using a ROM_EXT image (preferred)

See #14274.

Using a debugger

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0 and the chip should in a life cycle state where debugging is enabled, i.e. TEST, DEV, or RMA.

• Connect a debugger.
• Set a breakpoint on rom_main() and the ROM C handler rom_interrupt_handler().
• Continue until rom_main().
• Trigger an exception, e.g. by setting PC to an address (start of flash) that will trigger an instruction access fault.
• Verify that execution breaks at the C interrupt handler.
• Verify that chip resets with BFV:kErrorInterrupt.

Verify that ROM initializes peripherals properly.

Note: While the following can be checked at ROM_EXT stage, using a debugger in FPGA-based tests would avoid depending on rom.c. Doing so would give us more information and help us narrow down possible issues if we end up having a problem in ROM. For DV, we don't have to use the JTAG interface: we can wait until Ibex accesses rom_main() and backdoor check specific values.

This test should be run in all life cycle states where the processor is allowed to execute instructions (TEST_UNLOCKED*, DEV, PROD*, RMA).

Also, we may want to break this into multiple tests.

• Verify that the following peripherals are initialized properly:
  • AST
    • CREATOR_SW_CFG_AST_INIT_EN: kMultiBitBool4True enables, kMultiBitBool4False disables. Both configurations should be tested.
    • If CREATOR_SW_CFG_AST_INIT_EN is set to kMultiBitBool4True, check that the AST_INIT_DONE signal is correctly set to 1 in sensor_ctrl once the AST initialization is complete.
  • Clock jitter
    • CREATOR_SW_CFG_JITTER_EN: kMultiBitBool4False disables, all other values enables. CREATOR_SW_CFG_AST_INIT_EN must also be kMultiBitBool4True to enable.
  • Entropy complex
    • Entryop_src, csrng, and edn must be configured at boot mode.
  • ePMP
  • Interrupts should be disabled
    • Trigger a test interrupt and verify that nothing happens.
  • SRAM
    • Must be scrambled with a new key. Can test using register values and functionality.

Verify that ROM initializes the retention SRAM when needed.

CREATOR_SW_CFG_RET_RAM_RESET_MASK should be 1 << 2 so that ROM initializes the retention SRAM after a SW reset request.

• Verify that reset_reasons reports POR.
• Write a known pattern into all sections of retention SRAM.
• Request a SW reset.
• Verify that reset_reasons reports a SW request.
• Verify that all previously written sections are different.

Verify that the retention SRAM is preserved across resets.

• Verify that reset_reasons reports POR.
• Write a known pattern into all sections of retention SRAM.
• Perform a low power entry & exit.
• Verify that reset_reasons reports a low power exit.
• Verify that all previously written sections are intact.
• Request a SW reset.
• Verify that reset_reasons reports a SW request.
• Verify that all previously written sections are intact.

Verify that ROM initializes various peripherals properly.

• Pinmux: UART pins, SW straps if OWNER_SW_CFG_ROM_BOOTSTRAP_DIS != kHardenedBoolTrue
• UART
• Bits 0-5 of the cpuctrl CSR: CREATOR_SW_CFG_CPUCTRL

Verify that ROM correctly configures the ePMP region for debug ROM.

• ePMP Debug ROM region should be enabled in TEST, DEV, and RMA, anddisabled in PROD and PROD_END.

Verify that ROM reconfigures the watchdog timer correctly.

• Should be disabled in TEST and RMA.
• In DEV, PROD, and PROD_END, the threshold should be OWNER_SW_CFG_ROM_WATCHDOG_BITE_THRESHOLD_CYCLES if greater than or equal to kWatchdogMinThreshold, disabled otherwise.

Verify that ROM configures the alert handler correctly.

• Disabled in TEST.
• Read from OTP in DEV, PROD, PROD_END, and RMA. Checksum of config registers must match the OTP value.

Verify that ROM initializes the flash_ctrl correctly.

• Verify that
  • CREATOR_SW_CFG_FLASH_DATA_DEFAULT_CFG controls the default scrambling, ecc, and he settings for the data partitions.
  • CREATOR_SW_CFG_FLASH_INFO_BOOT_DATA_CFG controls the scrambling, ecc, and he settings for the boot partitions kFlashCtrlInfoPageBootData0 and kFlashCtrlInfoPageBootData1.
• Verify that flash_ctrl is initialized.

Verify that ROM initializes the keymgr correctly.

• Verify that keymgr is at the "reset" state.
• Verify that
  • attestation sw binding equals
    • the digest of the ROM_EXT if OWNER_SW_CFG_ROM_KEYMGR_ROM_EXT_MEAS_EN is kHardenedBoolTrue, and
    • the binding_value field of the manifest, otherwise,
  • sealing sw binding equals the binding_value field of the manifest, and
  • max creator key version equals the max_key_version field of the manifest,

Verify that ROM initializes the data structures in the .static_critical section properly.

• Verify that boot_measurements holds the digest of the next stage.
  • Don't specify any usage constraints to be able to compute the actual hash in the second stage.
• Verify that sec_mmio_ctx is valid using sec_mmio_check_values() and sec_mmio_check_counters().
• Verify that a failed sec_mmio check triggers an illegal instruction exception.

Determine which functests can be executed using ROM.

Functests test ROM components (e.g., drivers, libraries, etc.) work as intended on-chip. However, unlike when these components are embedded in the ROM, functests are linked with the OTTF, and run out of flash. Additionally, unlike the ROM E2E tests, functests are booted by the test ROM.

Determine which functests can be executed using ROM to understand which tests can be reused on the silicon.

Verify that ROM can be debugged in appropriate life cycle states.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0.

• Verify that ROM can be debugged in TEST, DEV, and RMA life cycle states.
  • Test debugging with commands to GDB connected via OpenOCD and JTAG (or the SystemVerilog based JTAG debugger model in case of DV simulations).
  • Read back GDB responses to check they match expected behaviour
  • Connect a debugger and verify that ROM halts very early in rom_start.S.
  • Trial the following activities within GDB, ensuring the correct behaviour is seen:
    • Halting execution and resetting
    • Setting, hitting and deleting breakpoints using all available hardware breakpoints
    • Single stepping
      • In particular single step over wfi
    • Reading and writing all registers
    • Reading all CSRs and writing some (write set TBD)
    • Reading and writing memory (both SRAM and device)
    • Setting the PC to jump to some location
    • Executing code from GDB (using the call command)
  • Verify that ROM fails to boot with BFV:0142500d.

Verify that a program can be injected into SRAM via JTAG and executed.

CREATOR_SW_CFG_ROM_EXEC_EN should be set to 0.

• For TEST, DEV, and RMA:
  • Connect a debugger.
  • Follow the steps here and execute //sw/device/examples/sram_program binary from SRAM.
  • Verify that chip sends the expected message over UART.

See this doc for detils.

End to end test to ensure RMA mode can be activated by halting ROM execution.

• This test must be run with the real ROM.
• Pre-load the device into PROD or PROD_END state.
• Backdoor load CREATOR_SW_CONFIG_RMA_SPIN_CYCLES and SPIN_EN.
• The value for CREATOR_SW_CONFIG_RMA_SPIN_CYCLES should be small, just enough for the DV agent to activate the life cycle JTAG interface.
• Drive software strap to the RMA bootstrap value.
• The test contains two iterations.
• In iteration 1, do not issue the life cycle rma command. ROM should timeout on spin cycles and automatically reset the device. Check to ensure device has reset via backdoor CSR.
• In iteration 2, issue the life cycle RMA command and ensure RMA transition can be successfully completed.

Verify that ROM can differentiate strong pull-ups/-downs from weak pull-ups/-downs.

• For strap in {all 64 strap values}
• Verify that ROM boots as usual unless strap == bootstrap or strap == rma_entry.

Each iteration should be pretty fast since the next stage is empty. If the above test takes a long time to run in DV, consider the following (or a subset of):

• For strap in {bootstrap, rma_entry}
• Apply all combinations of strap where pin values are the same but at least one pin uses weak pull-down.
• Verify that ROM boots as usual.