On your custom board based on i.mx253 running a stock 188.8.131.52 kernel, i've noticed a strange behavior when DMA is enabled.
For some reason the booting stalls for ~60s, and resumes without any error and/or warnings.
From what i could find out, the DMA in mx25 is the same as in mx35. I'm using a firmware originally designed for mx35 with the 184.108.40.206 kernel, "stock defaults" with the 3.x.x kernels.
I've tried different kernels; 3.0.8, 3.1.2, 3.2.0 all behaving the same way...
Is this a normal behavior? Am i doing something wrong, am i missing something?
Is there a way to improve the speed?
[ 3.386247] mousedev: PS/2 mouse device common for all mice
[ 3.390370] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 3.397442] input: TSC2007 Touchscreen as /devices/virtual/input/input1
[ 3.404424] rtc-ds1307 0-0068: SET TIME!
[ 3.409180] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
[ 3.413267] i2c /dev entries driver
[ 64.181134] imx-sdma imx-sdma: initialized
[ 64.184593] sdhci: Secure Digital Host Controller Interface driver
[ 64.188044] sdhci: Copyright(c) Pierre Ossman
[ 64.190758] _regulator_get: sdhci-esdhc-imx.1 supply vmmc not found, using dummy regulator
[ 64.196746] mmc0: SDHCI controller on platform [sdhci-esdhc-imx.1] using DMA
Thanx for your help in advance.
It seem to be only DMA related. If i disable DMA (kernel config=>Device Drivers=>DMA engine support), then the kernel starts within ~5s...
It could be that the firmware is "not the right fit" (even thou it should be compatible). Is there a tool for generating the FW?
Yes, there is a tool for generating the the sdma firmware that the mainline kernel requires at:
If you provide the firmware generated by this tool, you will not experience the long wait timeout.
if it happens with 3.2.0 as well, I'd say it is a bug and should be reported on the ARM Linux Kernel mailinglist, with Cc: to firstname.lastname@example.org. I don't remember having seen anything like this on the mainline before. You could try to disable some of the drivers "around" the breakage (which is i2c and imx-sdma) and check if it is really the sdma driver.