Skip to content

Add support for Microchip EV23X71A (Laguna) - #1596

Merged
mattiaswal merged 4 commits into
mainfrom
laguna
Aug 26, 2026
Merged

Add support for Microchip EV23X71A (Laguna)#1596
mattiaswal merged 4 commits into
mainfrom
laguna

Conversation

@troglobit

Copy link
Copy Markdown
Contributor

Description

  • Initial board support, including bootloader, for Microchip EV23X71A (Laguna)
  • statd: refactor temp sensors, consolidate SoC sensor handling
  • doc/: update netboot.md, how to flash a remote device

Checklist

Tick relevant boxes, this PR is-a or has-a:

  • Bugfix
    • Regression tests
    • ChangeLog updates (for next release)
  • Feature
    • YANG model change => revision updated?
    • Regression tests added?
    • ChangeLog updates (for next release)
    • Documentation added?
  • Test changes
    • Checked in changed Readme.adoc (make test-spec)
    • Added new test to group Readme.adoc and yaml file
  • Code style update (formatting, renaming)
  • Refactoring (please detail in commit messages)
  • Build related changes
  • Documentation content changes
    • ChangeLog updated (for major changes)
  • Other (please describe):

@mattiaswal

Copy link
Copy Markdown
Contributor

USB test fails, please investigate. I suspect your commit about statd

Comment thread package/mbedtls-atf/mbedtls-atf.mk
@troglobit

Copy link
Copy Markdown
Contributor Author

USB test fails, please investigate. I suspect your commit about statd

Yup, name clash with the cpu VPD component, fixing by prefixing all VPD's with vpd-.

Platforms with Trusted Board Boot authenticate every image in the FIP
against a chain of X.509 certificates.  Arm Trusted Firmware parses
those with mbed TLS, which it compiles into BL1 and BL2 from the sources
MBEDTLS_DIR points at, so ATF for Microchip LAN969x (Laguna) does not
build without them.

The mbedtls package cannot serve this purpose: it tracks the 3.x series
for use as a library, while ATF 2.8 builds only against the 2.28 LTS
series, and expects sources, e.g. library/rsa_internal.c, that 3.x no
longer has.

Nothing is built or installed here, the package only provides the
sources and points ATF at them.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Add board support for the Microchip EV23X71A evaluation board, based on
the LAN969x (Laguna) family: a Cortex-A53 with a TSN capable switch core,
24 GbE copper ports over QSGMII, four 10G SFP+ cages, and an RGMII
management port.  The sample here reports part 0x969b, a LAN9696RED,
one of the variants for which the driver offers PTP and PSFP.

Ports are renamed from the device tree path each netdev carries, e1
through e28 for the front ports and e29 for management.  The switch
driver leaves naming to the kernel, and there is no port@28, so the
kernel names end up one off from Microchip's numbering.  Attaching 29
PHYs also takes far longer than the ten seconds hw-wait allows, so that
timeout is now read from /etc/default/hw-wait.

Infix builds its own boot chain rather than using the one the board
ships with: Microchip's Trusted Firmware for BL2 and BL31, and their
U-Boot for BL33, which carries the LAN969x support but leaves out
blkmap, SquashFS, and sysboot.  It keeps no environment in flash, so a
writable environment cannot be used to bypass secure boot.  That needs
the ENV_IS_NOWHERE patch, since the board only ever asks for the
location matching the medium it booted from.

Trusted Board Boot pulls in the mbedtls-atf package.  Two ATF build
variables are not obvious: KEY_ALG=ecdsa, since the LAN969x crypto
driver is built around the Silex ECDSA engine, and GENERATE_COT=1,
without which the FIP carries no certificates for the ROM to check.
Trusted Firmware is pinned to a commit rather than a tag because no tag
carries the fix for ERR-LAN969X-001, where the boot ROM's ECDSA verifier
mishandles P-256 values with a leading zero byte.

The eMMC layout keeps the fip and fip.bak partition names, which is how
BL1 finds the firmware and its fallback, followed by the usual Infix
partitions.  See the board README for the strapping table, the rescue
paths, and how to install and update.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The CPU temperature was missing from show system on LAN969x and SparX-5.
The kernel names the hwmon device s5_temp, which the sensor name
normalizer reduced to "temp", taking s5_ for a vendor prefix, and
nothing downstream recognized that as a die temperature.

Each consumer carried its own list of names, and they disagreed: the CLI
matched cpu, soc, core, ap- and cp<N>-, the dashboard cpu, soc and core
plus radio, phy and sfp prefixes.  A new SoC meant patching every one.

Give the SoC a component of its own, class iana-hardware:cpu, with the
die sensors as its children.  Consumers then ask for a celsius sensor
whose parent is a CPU, the same question over NETCONF, RESTCONF, the
WebUI, and the CLI, and hwmon and thermal zone names are recognized in
a single place.

Keep the kernel's names as they are.  Collapsing them lost what the
sensor belonged to, and stripping the -thermal suffix off one spelling
of a name but not the other hid the fact that, with THERMAL_HWMON, the
kernel mirrors every thermal zone as an hwmon device: the same sensor
was discovered twice, under two names.  Skip the mirror.

VPD components move out of the way as well.  Their names come from
infix,board in the device tree, where board authors pick short words for
the board an EEPROM sits on, and Alder calls one of them "cpu".  Name
them vpd-<board>.  Nothing references them from configuration, unlike
WiFi radios and GPS receivers, whose names are leafref targets and have
to stay as they are.

Duplicate names are not cosmetic, they fail every client parsing the
tree, so assembling the components now renames any duplicate that is
left and logs it.

This also brings in x86, where coretemp and k10temp never matched, and
show hardware groups sensors under any component that has them, not
just modules.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A device with empty storage has no slot to boot, so it falls back to
DHCP on its own.  Pointing the boot file at a rootfs.itb is therefore
enough to bring a factory fresh board all the way up to a running
system, with no console interaction and no netboot.scr, since the
ixprepdhcp handler downloads and validates the image itself.

From there the system can install itself: build the image, give the
netbooted system an address, and stream it onto the eMMC.  Document
that, including the partition table warning that follows, which the
first boot resolves when it grows the last partition.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
@mattiaswal
mattiaswal merged commit d1cb279 into main Aug 26, 2026
11 checks passed
@mattiaswal
mattiaswal deleted the laguna branch August 26, 2026 06:31
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.

2 participants