Musca-B1

Enablement

LAVA by default is configured to work with this DUT + LAA setup. If you opt for a different setup you’ll have to change your DUT + LAA device configuration on LAVA.

The Arm Musca-B1 test chip board is automated for Trusted Firmware-M (TF-M) testing. It is a Cortex-M33 board with an on-board DAPLink; power, flashing (over USB mass storage) and the serial console all run over the single DAPLink USB connection, so no board modification is required.

This document applies to the following boards:

  • Musca-B1: musca-b

Components

The following components are required to automate the board:

  • One USB cable from an LAA USB port to the board’s on-board DAPLink connector. This single link carries power, mass-storage flashing and the UART console.

Board modifications

None. The board is flashed by copying the image onto the DAPLink USB mass storage, so there is no boot-mode switch to change and no flying leads to solder.

Connections

Connect the board’s DAPLink USB connector to USB port 3 on the LAA (laacli usb 3). That port powers the board and exposes both the DAPLink mass-storage flash interface and the DAPLink Virtual COM Port (the DUT console).

The console enumerates on the LAA as /dev/ttyACM0 at 115200 8N1 and is served over telnet on port 2020.

Software

Flashing is done by musca-flash-fw, shipped in the LAA overlay (appliance/firmwares/musca-b). baklaweb provisions the overlay into /usr/local/ on the dispatcher, and the device dictionary’s flasher_deploy_commands calls the wrapper directly: the dispatcher is already privileged and has USB access. The wrapper (adapted from LAVA’s to: musca deploy):

  • copies the TF-M image onto the DAPLink USB mass storage, retrying if the DAPLink rejects the program, and lets the DAPLink “Auto Reset” run it.

The device dictionary’s hard_reset_command is a no-op (true): the board is reset in-band by the DAPLink’s own “Auto Reset” after each flash, so no separate reset step is needed.

No USB power-cycle

The board is powered on once (laacli usb 3 on) and never power-cycled; power_off is a no-op. The DAPLink “Auto Reset” after each flash resets the Musca chip but not the DAPLink, so the console stays attached across the reset and the boot is captured from the first byte, which the USB-power-cycle musca boot method loses. (The Musca DAPLink also used to wedge on a VBUS-only power-cycle by back-powering through the data lines; the LAA now cuts the data lines too, so that is no longer a concern.)

Health check

The health check flashes a TF-M image and waits for Non-Secure system starting... on the console.