Hi folks.
On your custom board based on i.mx253 running a stock 2.6.39.4 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 2.6.39.4 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?
<snip>
[ 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
</snip>
Thanx for your help in advance.
Cheers, Kardy
Hi Robert,
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?
-Kardy
Yes, there is a tool for generating the the sdma firmware that the mainline kernel requires at:
http://git.pengutronix.de/?p=imx/sdma-firmware.git;a=summary
If you provide the firmware generated by this tool, you will not experience the long wait timeout.
Regards,
Fabio Estevam
Dear Kardy,
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 kernel@pengutronix.de. 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.
rsc