Hi @ajudge, just wanted to give you an update on our attempts to turn off the ADMA.
At first we implemented the patch exactly as you described. However, that resulted in errors communicating with the eMMC memory during boot. The boot sequence could not complete.
Then we decided to change the patch slightly, where, if I understand correctly, we only turn off ADMA for the mmc1 interface to which the halow module is connected. Is this understanding correct?
We were able to boot up the device without errors on the mmc2 interface, but the timeout error on mmc1 persisted.
Next we have tried to setup the sdhci.debug_quirks=0x40 in U-boot. Depending on how we do that it was either unable to boot up, or the error remained unresolved.
I will try to see if there are other ways of implementing the quirks this week.
@SanderV ah, I was using NAND on board instead of eMMC (which was having issues), unfortunately the simple solution I’ve provided is going to apply globally. Applying the sdhci.debug_quirks is also going to apply globally.
Digging through the 5.15 kernel source I have, there is actually a device-tree property which might be suitable!
If my understanding of the linux sdhci driver is correct, this should be where the iMX esdhc_readl_le is called from. This means that you should be able to set the sdhci-caps-mask property in the mmc1 devicetree node such that it disables SDHCI_CAN_DO_ADMA2. I wish I had found this earlier!
I have been playing around with the property after removing the patch, but so far not the results we are looking for. The system is persistent in using ADMA.
root@ucm-imx8m-mini:~# dmesg | grep ADMA
[ 1.597838] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA
[ 2.305003] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[ 2.376908] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using ADMA
I have added your suggestion to the device tree as shown below
It appears as though something might be overriding the device tree settings regarding ADMA. I did check in /proc/device-tree to ensure that the new property shows up and it does.
Hm, that’s very frustrating and it definitely looks like it’s still forcefully enabling ADMA.
Can you modify __sdhci_read_caps in sdhci.c and add a debug print to the following code block (and verify the code block is actually there), just to verify the host->caps are being applied?
if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
return;
if (caps) {
host->caps = *caps;
} else {
host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
host->caps &= ~lower_32_bits(dt_caps_mask);
host->caps |= lower_32_bits(dt_caps);
// add a debug print here - printk("using caps 0x%x\n", host->caps);
}
That’s very likely possible. Naively I would expect you could simply compare host->ioaddr against the base address of the mmc host controller you care about. In this case, it looks like mmc1 is an alias for usdhc2 so check host->ioaddr == 0x30b50000. Obviously not ideal as it is a hardcoded solution, but definitely good to check.
I happened upon this thread as I am also running into ADMA failures with an mm6018 module but in my case its on an IMX8MP SoC.
I don’t see any broken-adma or no-adma property in the kernel so that seems invalid.
As far as your sdhci-caps-mask this is a 64bit value so to disable ADMA2 you would need to give it two 32bit values otherwise your trying to set the upper 64bits which is not what you want:
sdhci-caps-mask = <0x0 0x00080000>; /* disable ADMA2 */
Due to ‘ADMA Err: 0x00000007’ in your case here being an ADMA length mismatch try setting MORSE_SDIO_RW_ADDR_BOUNDARY_MASK to 0xffff0004 instead of the default 0xffff0000 which will reduce the ADMA length to 65532 instead of 65536. For me this resolved the ‘ADMA Err: 0x00000007’ on the IMX8MP but I still am having ADMA transfer errors.
In my case I’m disabling ADMA yet still getting ‘Timeout waiting for hardware Interrupt’ on some modules on my board:
[ 0.980955] mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
[ 1.025937] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using DMA
[ 1.053192] mmc0: new high speed SDIO card at address 0001
cat /sys/kernel/debug/mmc0/ios
clock: 50000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don’t care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
Thanks for the correction on the sdhci-caps-mask property @tharvey.
In my case I’m disabling ADMA yet still getting ‘Timeout waiting for hardware Interrupt’ on some modules on my board
Just to clarify, does this mean you have other modules/boards which are working with the iMX8?
I ask because, as in post #18, I saw failures on the first CMD53 read in the init sequence (Argument: 0x149a4004, same as yours) which was caused by a poor supply of power to the module carrier board I was using (one of our own RPi hats). From memory, this is the first part of the init sequence where the data lines are driven by the MM6108.
If you have access to a logic analyzer, capturing a trace and finding the CMD53 read with argument 0x149a4004 might help give some hints as to what is going on.
@SanderV this is typically seen when the version of the firmware or BCF binary does not match the version of the driver. Please make sure the sources are all from the same software release version.
If they are from the same version, can you share the sha256 hash of the firmware and bcf binary you are using on your device?
Or better still, attach the binaries here for inspection.
The next step would be to bring up an interface and connect it to an AP. How do you suggest we do that? Or perhaps you can point me to a resource on how to do that?
We’re currently in the process of migrating our documentation to something more accessible. But if you have access to the Morse Micro support portal I recommend reading the Linux porting guide - available here: https://www.morsemicro.com/download/mm-appnote-24-linux-porting-guide/
This has information for running hostapd_s1g and wpa_supplicant_s1g. The opensource repository containing source for both applications can be found at GitHub - MorseMicro/hostap
So I have cross-compiled the binaries according to the porting guide and transferred them to the iMX8. Everything seems to have gone okay, but I am not yet able to connect to the AP.
root@ucm-imx8m-mini:~# wpa_supplicant_s1g -t -D nl80211 -s -i wlan0 -c /etc/wpa_supplicant_s1g/wpa_supplicant-wlan0.conf -B
Long Sleep Mode: disabled
root@ucm-imx8m-mini:~# [ 220.512518] wlan0: authenticate with 00:0a:52:0a:db:5f
[ 220.804716] wlan0: send auth to 00:0a:52:0a:db:5f (try 1/3)
[ 222.845622] wlan0: send auth to 00:0a:52:0a:db:5f (try 2/3)
[ 224.861618] wlan0: send auth to 00:0a:52:0a:db:5f (try 3/3)
[ 225.813588] wlan0: aborting authentication with 00:0a:52:0a:db:5f by local choice (Reason: 3=DEAUTH_LEAVING)
[ 248.721804] wlan0: authenticate with 00:0a:52:0a:db:5f
[ 249.024303] wlan0: send auth to 00:0a:52:0a:db:5f (try 1/3)
[ 251.037623] wlan0: send auth to 00:0a:52:0a:db:5f (try 2/3)
[ 253.053619] wlan0: send auth to 00:0a:52:0a:db:5f (try 3/3)
[ 254.031018] wlan0: aborting authentication with 00:0a:52:0a:db:5f by local choice (Reason: 3=DEAUTH_LEAVING)
For hostapd I do get an error, because our Yocto build does not contain a certain library. I only intend to use this device as a client so that is not a problem for now
root@ucm-imx8m-mini:/etc/wpa_supplicant_s1g# hostapd_s1g -t -B -s hostapd.conf
hostapd_s1g: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory
Usually you will see this sequence of supplicant logs when your device has failed to authenticate with the AP.
[ 220.804716] wlan0: send auth to 00:0a:52:0a:db:5f (try 1/3)
[ 222.845622] wlan0: send auth to 00:0a:52:0a:db:5f (try 2/3)
[ 224.861618] wlan0: send auth to 00:0a:52:0a:db:5f (try 3/3)
[ 225.813588] wlan0: aborting authentication with 00:0a:52:0a:db:5f by local choice (Reason: 3=DEAUTH_LEAVING)
This could be caused by a mismatch in configuration between the AP and station (I often forget the sae_pwe setting, which you do have).
I would have expected wpa_supplicant to not start, but without a libcrypto on the device, wpa_supplicant won’t be able to complete authentication. If possible, try to build openssl for your target and install it onto the device. This site has some helpful information for that. Adjust your architecture and toolchain as required: https://wiki.beyondlogic.org/index.php?title=Cross_Compiling_iw_wpa_supplicant_hostapd_rfkill_for_ARM#OpenSSL
It might be helpful to run wpa_supplicant with a higher output verbosity. Can you add -d or -dd to the command line?
Alright I have been able to cross-compile the required files and added them to my device. However, hostapd now throws the error below. I understand it is not recommended to cross-compile GLIBC, so I have asked a developer to help me upgrade it in our Yocto build.
root@ucm-imx8m-mini:/opt/sdk# hostapd_s1g -t -B -s hostapd.conf
hostapd_s1g: /lib/libc.so.6: version `GLIBC_2.34' not found (required by hostapd_s1g)
The -d or -dd tags do not give any additional information
It might take a few days for the new Yocto build to be ready. The current build runs GLIBC_2.33.
Is this behaviour that you expect from wpa_supplicant? Any other suggestions for me to try?
You should be able to “cross compile” hostap by creating a metalayer in Yocto which would link it to the correct glibc, and use the porting guide for instructions on how to run wpa_supplicant only. One of our community members did this previously for the Raspberry Pi 4, and I leveraged that work to build a Yocto layer for wpa_supplicant and hostap for the iMX6 target I was using for the rest of this thread.
And here’s the bitbake files I was using for the Variscite iMX6 board, based on those above. If I find the time I’ll clean up the metalayer I was using and host it somewhere appropriate.
This has the added benefit that it should resolve dependencies rather trivially if you build the whole image.
