Re: [RFC] mci: imx-esdhc-pbl: enable ADMA2 for i.MX8M BL33 loads -- help needed: ADMA stalls in ST_TFR despite every visible register matching the Linux runtime driver

["Sascha Hauer" <s.hauer@pengutronix.de>]

Hi Johannes,

On 2026-06-19 16:09, Johannes Schneider wrote:
> Add a generic sdhci_enable_adma() helper that lets drivers provide their own
> descriptor table (so PBL builds can use a static buffer without dma_alloc),
> gate the SDMA boundary-restart loop in sdhci_transfer_data_dma() behind
> !SDHCI_USE_ADMA, and switch the i.MX8M PBL BL33 load path to call into the
> new helper. On a working i.MX8MM board this should cut load_bl33 from
> ~645 ms (SDMA polled, restart-per-DMA-boundary) to ~140 ms (single ADMA2
> descriptor, one interrupt at completion).
> 
> The patch builds and applies cleanly on barebox/next. On our test
> hardware (custom i.MX8MM board, USDHC3 -> eMMC) the ADMA engine fetches
> the descriptor, programs the data path, then stalls in ST_TFR
> (ADMA_ERR=0x3) with no progress. Looking for input from anyone who has
> either (a) shipped ADMA2 in i.MX PBL successfully, or (b) can point at
> what infrastructure the full runtime driver does on probe that PBL would
> need to replicate.
> 
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
> ---
> RFC writeup
> ===========
> 
> Motivation
> ----------
> Current PBL i.MX8M BL33 load is SDMA-based with the SDHCI boundary-restart
> loop in sdhci_transfer_data_dma(). For a 32 KiB BL33 transfer at the default
> 4 KiB SDMA boundary that's eight kicks-and-restarts. Measured on a custom
> i.MX8MM board:
> 
>  Boot timeline (from power-on):
> 	 BootROM:          1 ms
> 	 PBL-init:         3 ms
> 	 DDR-training:   262 ms
> 	 PBL-load:       819 ms
> 		 PBL-pre-load:    168 ms
> 		 load_bl33:       645 ms   <--  (SDMA, ~5 MiB/s effective)
> 		 PBL-post-load:     5 ms
> 		 BL31-early:      114 ms
> 		 BL31-platform:    15 ms
> 		 BL31-runtime:     98 ms
> 			 thru-OPTEE:       98 ms
> 			 post-OPTEE:        0 ms
> 	 barebox:       5654 ms
> 	 kernel-init:    111 ms
> 
> barebox's own runtime imx-esdhc.c driver uses ADMA2 for the same controller
> and gets the FIT image off the same eMMC at expected speed. ADMA2 in PBL
> should match.

You lost me here. ADMA(2) usage is gated behind the SDHCI_USE_ADMA which
is set in sdhci_setup_adma(). Only the Rockchip driver calls this
currently, so imx-esdhc should use SDMA also in barebox proper.

So you have patches in your tree I haven't seen yet?

Sascha

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |