@SanderV the confusion came from a difference between the registers used by the iMX host controller driver, and the registers as documented in the SD host controller spec! The iMX driver corrects how these registers are reported to the SD Host Controller stack
0x07eb0000 indicates that ADMA1 is not used, but ADMA2 is used. This is manually manipulated in the iMX ESDHC driver.
if (val & SDHCI_CAN_DO_ADMA1) {
val &= ~SDHCI_CAN_DO_ADMA1;
val |= SDHCI_CAN_DO_ADMA2;
}
I have been able to disable ADMA2 by forcing this bit off to try fall back to SDMA. This still resulted in some timeouts at the time.
However! After inspecting more carefully I have noticed that the register dump on this imx6 board had changed when these timeouts occured. For some time now, I had been investigating a register dump with the following argument value, a CMD53 read of the MM chip ID.
Argument: 0x149a4004
This argument occurs earlier in the Morse Micro init sequence, and on closer inspection with the logic analyzer - this was identified as an unstable voltage supply to the Morse Micro hat.
Note in the above image, the instability in the clock, and the spurious transitions in the data lines.
Opting to connect the USB-C of the Morse Micro hat to the iMX6 baseboard for power, I was able to get back to the original error with argument
Argument: 0xac00001b
I realise this argument differs to yours slightly, but I expect this to be failing in a similar spot to yours - as this argument is a CMD53 write and should align with writing the firmware binary to the chip.
Reattempting the ADMA disabling, by forcing the value in esdhc_readl_le where SDHCI_CAPABILITIES is read.
val &= ~SDHCI_CAN_DO_ADMA1;
val &= ~SDHCI_CAN_DO_ADMA2;
I have managed to bring up the Morse Micro chip and have it register on the iMX6 as a netdev!
root@imx6ul-var-dart:~# ifconfig wlan0
wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 0c:bf:74:00:02:9c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The ADMA change is necessary at this stage. The length mismatch error you are seeing (ADMA Err: 0x00000007) lines up with the SD Host Controller Spec, section 1.13.1.3 which states.
If total length of a descriptor were not multiple of block size, ADMA2 transfer might not be terminated. In this case, data timeout would occur and the transfer would be stopped by abort command. Therefore, total length should be multiple of block size.
The mmc request operations in the sdhci driver used by the iMX doesn’t split the data length into two parts of block multiples and one part for byte transfer, so the simplest thing to do is disable ADMA. The driver should still fall back to SDMA based transfers.
On our side, we still have some intermittent EILSEQ (-84) errors preventing us from bringing up a reliable interface, which we are still looking into. I suspect these are further signal integrity related issues or other forms of data corruption on the bus. Will be interested if you see the same thing.