Re: [RFC] mci: imx-esdhc-pbl: enable ADMA2 for i.MX8M BL33 loads

[Johannes Schneider <johannes.schneider@leica-geosystems.com>]

Hoi Sascha,

On Mon, Jun 22, 2026 at 09:11:30 +0200, Sascha Hauer wrote:
> > 
> > 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.

You're right, and my cover letter was wrong :-S
To be precise about who uses what:

  Linux sdhci-esdhc-imx : ADMA2 + HS400ES @ 200 MHz
  barebox-proper        : SDMA  (sdhci_transfer_data_dma(), SDHCI_USE_ADMA unset)
  barebox PBL           : PIO   (esdhc_use_pio_mode() is true in PBL)

I wrote that *barebox*-proper uses ADMA2 - that was the mistake; it is
*Linux* that does. barebox-proper uses SDMA, and nothing on i.MX uses
ADMA2.

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

No, nothing unpublished. The ADMA2 reference I was comparing against is
Linux's sdhci-esdhc-imx, not anything in barebox. Linux drives ADMA2 +
HS400ES at 200 MHz on the exact board this RFC targets (USDHC3 -> eMMC):

  # dmesg | grep mmc2
  mmc2: SDHCI controller on 30b60000.mmc using ADMA
  mmc2: new HS400 Enhanced strobe MMC card at address 0001
  mmcblk2: mmc2:0001 IM032G 9.70 GiB

  # cat /sys/kernel/debug/mmc2/ios
  clock:          200000000 Hz
  bus width:      3 (8 bits)
  timing spec:    10 (mmc HS400 enhanced strobe)
  signal voltage: 1 (1.80 V)

so it is a PBL bring-up gap, not a silicon limit.
On our i.MX8MM board, PBL load_bl33 takes ~640 ms in PIO - and this is
what i'm trying to lower ... somehow.

One step up would be SDMA, but that has the problem of the SDMA
boundary field colliding with the 13-bit BLKSIZE, so the boundary
cannot be raised far enough and the engine would end up restarting
every 4K (~340 stops for a 1.5 MB read, which makes SDMA ~= PIO ?).

Therefore i directly "aimed high" at ADMA2, to avoid round-trips and
load everthing in one go - but there it hangs in ST_TFR (RFC body)
-> what might i be missing or have overlooked?


Gruß,
Johannes