Re: [RFC] mci: imx-esdhc-pbl: enable ADMA2 for i.MX8M BL33 loads
Johannes Schneider <[email protected]> Tue, 23 Jun 2026 13:01:53 +0000
| Newsgroups | org.infradead.lists.barebox |
|---|---|
| Message-ID | <[email protected]> |
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