Skip to content

8. Differences

Jump to bottom
Austin Shirley edited this page Oct 16, 2026 · 3 revisions

Goals

This page records where this repository diverges from the vendor and available community configurations. Two core goals drive the differences behind dbl-buildroot:

  • Every firmware component from its upstream release; no ST or MYIR forks, no out-of-tree patches. Security fixes and version bumps follow upstream directly.
  • Target the MyIR MYD-YF135 specifically, not an ST evaluation board. Device tree and storage configuration match the hardware on this SOM.

The projects below were valuable starting points. In most cases the differences arise because those projects made reasonable choices for a different context, a vendor fork or a different board, whereas this repository follows the upstream code paths that those choices bypass.

Reference projects

  • bootlin/buildroot-external-st: the ST-maintained BR2 external tree. It targets ST evaluation boards and uses the ST kernel and OP-TEE forks.
  • BasicCode/STM32MP135_Dev_Board_Buildroot: community BR2 configuration for a similar MP135 board. Useful starting point. Relies on ST OP-TEE fork DTS constructs that do not build against upstream OP-TEE.
  • MYiR-Dev/myir-st-linux: MYIR's kernel fork, which is v6.6 plus approximately 40 commits. It is used as a pinctrl and DTS reference only.
  • MYIR BSP: the vendor BSP, for which registration is required. It is used to confirm the NAND chip identity and the pin wiring.

NAND chip identity

The published references disagree on the flash part. The MYIR kernel device tree (myb-stm32mp135x-256m.dts on develop-yf13x-L6.6.78) names the flash node MX35LF2G24AD@0 (Macronix), while the MYIR TF-A device tree, the MYIR hardware datasheets, and the U-Boot probe output (MT29F2G01AB) all identify a Micron MT29F2G01ABAGDWB. The Micron part is correct, verified on several SOMs.

The node name has no effect on Linux, which identifies the chip by its ID. Upstream TF-A, however, takes the geometry from the OTP fuse and never checks it against the chip. A fuse value worked out from the wrong part gets the plane count wrong, which corrupts BL2 reads (see NAND parameters and OTP). The device tree uses compatible = "spi-nand" with spi-max-frequency = <100000000> (100 MHz).

NAND geometry: OTP fuse instead of a hardcoded table

The vendor TF-A fork (develop-yf13x-v2.10) sets NAND parameters at the top of get_data_from_otp() and returns before reading the OTP, so it always uses fixed geometry (page_size=2048, block_size=128KB, nb_planes=2, size=256MB).

Upstream TF-A reads the geometry from the OTP fuse, and this repository follows that path with the bootloader unpatched. The word is burned once during provisioning, as described in NAND parameters and OTP.

OP-TEE device tree: rebuilt on the upstream reference

The ST OP-TEE fork carries STM32MP1-specific device tree infrastructure that is not present in upstream OP-TEE 4.3.0. Configurations built on that fork inherit those nodes. Because this project targets upstream OP-TEE, where the same configuration is implemented in C rather than driven from the device tree, the secure device tree was rebuilt on the upstream stm32mp135f-dk.dts from OP-TEE OS 4.3.0 and the fork-only nodes were dropped.

Node What it does in the fork Upstream equivalent
&etzpc with st,decprot Peripheral security access control Hardcoded in core/drivers/stm32_etzpc.c
&tzc400 TZC400 memory firewall Hardcoded in platform C code
&scmi_regu with VOLTD_SCMI_* SCMI voltage domain mapping Static defaults in the SCMI server
&pwr_regulators suspend modes system_suspend_supported_soc_modes Upstream takes only vdd-supply and vdd_3v3_usbfs-supply

The resulting file is stm32mp135d-myd-yf135-optee.dts.

Kernel configuration: multi_v7_defconfig base

Neither ST nor upstream ships an stm32mp135_defconfig. This repository uses multi_v7_defconfig as the base, which matches ST's own approach, then enables the board-relevant options through make linux-menuconfig and saves the result to board/myd-yf135/linux.config.

Flash layout: spi-nand0 rather than nand0

On STM32MP15x boards, nand0 is the IP name for raw FMC-attached NAND. Configurations derived from those boards use nand0 accordingly. On this board the NAND is attached over QSPI and enumerates as spi-nand0 in U-Boot, so flashlayout.tsv and the device tree partitions use spi-nand0.

Firmware update: BL2 walk instead of PSA FWU

This repository uses a BL2 fallback walk to the factory FIP plus a U-Boot version stamp. The upstream FWU path does not yet meet the no-patches goal on NAND; upstream FWU is supported mainly on EFI bootloaders backed by SD/MMC.

  • TF-A NAND FIP-B offset is hardcoded; A/B layout here would require an upstream change.
  • U-Boot fwu command is read-only. Write-side library functions exist but are reachable only through the EFI capsule path, not from an environment script; accepting or switching a slot requires authoring a new subcommand.
  • First boot against blank FWU metadata panics TF-A; metadata must be pre-staged with mkfwumdata during the build.

The mechanism is described in Firmware update and fallback.

Clone this wiki locally