2414142_en-US

Yes

i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards

Summary

On a custom System Manager configuration for i.MX95, booting the A55 logical machine (LM1) hangs inside the shared driver function SRC_MixSoftPowerUp() (devices/MIMX9/drivers/fsl_src.c) for srcMixIdx = PWR_MIX_SLICE_IDX_A55P (index 11). SRC_MixPowerUpCompleted() never returns true, FUNC_STAT freezes in a mixed/inconsistent state, and SM's own WDOG2 eventually fires an FCCU reset.

Critically, when the sequence is forced to do a full power-down-then-up cycle, the power-down request never completes either — the hardware does not respond to software power control for this mix in either direction.

The same firmware stalls identically on two physically different boards (FRDM-IMX95 15x15/LPDDR4x and FRDM-IMX95-PRO 19x19/LPDDR5), while both boards' factory-shipped eMMC images boot to a full Linux userspace, so the silicon and boards themselves are demonstrably capable.

I have been able to rule out a large number of candidate causes with concrete evidence (listed below) and would appreciate guidance on what remains.

Environment

Item Value

SoC	i.MX95 (B0)
Boards	FRDM-IMX95 (15x15, LPDDR4x) and FRDM-IMX95-PRO (19x19, LPDDR5)
System Manager	nxp-imx/imx-sm at lf-6.18.20-2.0.0-5-g3198944
SM config	Custom (SMCT/.mex-generated), not mx95evk
M33/SM status	Fully working
M7 status	Fully working — SCMI, TRDC partitioning, STOP/SUSPEND/deep-idle, I2C, Ethernet MDIO all functional
A55 (LM1)	Fails as described
Boot media tested	SD and eMMC (identical results)

Symptom

A55 is booted on demand from M7 via SCMI_LmmBoot() (also reproducible manually with lm LM1 boot from the SM debug monitor).

The SCMI call itself succeeds: status = 0
LM1 then reports SCMI_LMM_STATE_SUSPEND (state = 2)
Execution stalls in SRC_MixSoftPowerUp() waiting on SRC_MixPowerUpCompleted(PWR_MIX_SLICE_IDX_A55P)
FUNC_STAT remains frozen for 4,000,000+ poll iterations
Left unbounded, SM's WDOG2 supervisory watchdog fires an FCCU reset (errId = 18), taking down the whole system including M7

Register evidence

SRC_XSPR_CORTEXMIX_PLATFORM (mix index 11) FUNC_STAT freezes at 0x00001010 or 0x00001011 depending on entry state.

Decoding the seven status fields in PWR_MIX_FUNC_STAT_PUP/PDN:

Field Observed state

PSW_STAT	"up" pattern
SSAR_STAT	"up" pattern
A55_HDSK_STAT	"up" pattern
SYSMAN_STAT	"up" pattern
RST_STAT	"powered-down" pattern
ISO_STAT	"powered-down" pattern
MEM_STAT	"powered-down" pattern

This is an inconsistent state that matches neither a fully-powered-up nor a fully-powered-down condition, and it does not advance.

Hardware measurement

A scope was placed on VDD_ARM (output caps C211–C215, after inductor L7, downstream of the discrete PPF5301 DCDC — this board has a genuine dedicated ARM rail). During an lm LM1 boot attempt:

The rail is already live at ~0.92 V before the attempt
It visibly drops during the attempt

So this is a real, physically observable incomplete power transition, not purely a permissions/timing/software artifact.

Most informative single data point

Forcing the entire power-down-then-up cycle unconditionally for the A55P mix (bypassing the MEM_STAT == 0 gate — i.e. SLICE_SW_CTRL |= PDN_SOFT, wait PowerDownCompleted, SLICE_SW_CTRL &= ~PDN_SOFT, wait PowerUpCompleted) shows that even the explicit power-down request never completes. FUNC_STAT is unchanged for the entire wait.

This suggests the problem sits below the SRC register interface — e.g. a GPC handshake precondition, a missing clock to the SRC block itself, or a board/PMIC response issue — rather than anything correctable in SRC_MixSoftPowerUp()'s own sequencing logic.

Already investigated and ruled out (with evidence)

PERF_A55 argument (3 → 0, ODV → PRK voltage level) — byte-identical failure at either value. Rules out a DVS/voltage-level mismatch.
config_bctrl.h (SM_BCTRL_A_CONFIG / SM_BCTRL_W_CONFIG) — was empty in my config; populating it with mx95evk's values changed nothing. I then read the live registers on the working factory system via the SM monitor (BLK_CTRL_NS_AONMIX 0x44210008–0x44210024, BLK_CTRL_WAKEUPMIX 0x42420030–0x42420064) — every word matched the mx95evk reference exactly.
SM_A55P_CONFIG, config_user.h, TRDC SRC/GPC/ANATOP grants, WDOG2 timeout — all confirmed identical to mx95evk, or confirmed not to be the blocker. (SM's own DOM2 TRDC access to these registers demonstrably works — I can read and write changing register values.) Note SM_A55P_CONFIG and SM_DDR_CONFIG are empty in mx95evk's own config too.
SRC_MixIsPwrReady() guard — correct logic, but it legitimately returns false here (mixed bit state), so it never changes behaviour.
Unconditional SRC_MixSetA55HdskMode(..., ACK_WAIT) — zero effect; A55_HDSK_STAT was already in the correct "up" pattern throughout.
Newer SM firmware — diffed the pinned SRCREVs across the walnascar → whinlatter span: zero changes to devices/MIMX9/ (including fsl_src.c, dev_sm_cpu.c, dev_sm_power.c).
uboot-imx differences — real differences exist across releases, but none touch PD_A55P/SRC_XSPR/A55 power-up. This is also true by construction: U-Boot SPL runs on A55, i.e. only after this power-up has already succeeded.
ERR053228 analog (MTR_ACK_CTRL) — i.MX95 has a per-mix MTR_ACK_CTRL/MTR_ACK_STAT handshake (offset 0x90/0x94) whose reset default (CNT_MODE = 0) waits indefinitely for a hardware MTR ack, which looked like a plausible match for the stuck MEM_STAT. I wrote CNT_MODE = 3 (timeout mode) with max MTR_CNT_CFG before the power-up transition and confirmed via readback that the write takes effect (no LOCK_CFG interference). No change.
Real factory AP binaries — extracted bl31.bin / tee.bin / u-boot* from this board's own known-good factory eMMC image and built them into my flash.bin. No change (expected, since the stall precedes U-Boot's first instruction).
Fuses/OTP — ruled out: fuses are burned once per die, and the factory image and my image run on the same physical board.
Boot medium — SD and eMMC both tested, identical.
Factory SM binary provenance — this one I want to highlight, because it closes off "maybe NXP ships a different SM build". I extracted the factory eMMC's own M33 image (ROM container 3, image 3, CORE_CM33, container-relative offset 0x79000, size 0x2C800) using mkimage_imx8 -soc IMX9 -parse, and verified the extraction by exact SHA384 match against the container's own recorded hash. Its build banner reads:

Hello from SM (Build 819, Commit c450f539, Mar 09 2026 03:24:50)

c450f539 is confirmed (git merge-base --is-ancestor) to be a direct ancestor of my own build, and the only intervening commit touching fsl_src.c/dev_sm_cpu.c/dev_sm_power.c is pure test-scaffolding cleanup with no functional change.
So the factory image that successfully boots A55 is running functionally the same SM source that fails for me.

Questions

Given that the factory image boots A55 with functionally identical SM source, what differs outside imx-sm source and the BCTRL register configuration that could gate A55P mix power-up? Specifically, is there AHAB/ELE container signing or provisioning metadata that affects whether the A55 platform mix can be powered up?
Is the observed FUNC_STAT pattern (PSW/SSAR/A55_HDSK/SYSMAN up, RST/ISO/MEM down, not advancing) a known signature? What is the expected next transition from that state, and what drives it?
Why would the explicit power-down request also never complete? That seems the strongest clue — what preconditions must hold for SRC_XSPR to respond to SLICE_SW_CTRL.PDN_SOFT at all for this mix?
Is there a known i.MX95 B0 erratum affecting A55P mix power sequencing beyond ERR053228?
Is there any required initialisation for the A55 platform mix that is present in the reference mx95evk flow but not expressed in the generated config_*.h files — i.e. something a custom SMCT-based config would silently omit?

Notes

JTAG is not available on the PRO board (no header), and I have chosen not to use the fragile 0.5 mm test pads on the 15x15 board.
All diagnosis above was done via SM's own debug monitor (lm info, err, btime, md), direct register reads, and scope measurement.
I have a containment fix in place (bounded waits replacing the original unbounded while (!SRC_MixPowerUpCompleted()) {;} loops) so that the failure now degrades gracefully to LM1 = suspended instead of watchdog-resetting the entire system. Happy to share that separately if useful.

Re: i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards

Please disregard the post above and close the ticket... I just did a fresh build with wrynose and it works! My previous builds were with whinlatter (selected because that's what the FRDM-IMX95 shipped with), but that didn't work.