Forum Post: RE: Linux support for AM3874/DM8148 in Arago linux-omap3

Hi Pavel,

Thanks for the quick response -- I'll diff my kernel snapshot with the PSP version to determine what's different, and go from there.

Treating the SPI issue specifically, however, I see that the driver (omap2_mcspi.c) in linux-2.6.37-psp04.04.00.01 is identical to the linux-omap3 version I'm using. Both have incorrect bit defines for the AM387x/DM814x:

#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE BIT(4)
#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP BIT(2)
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET BIT(1)

...and both versions use these bit definitions to initiate a soft-reset:

static int __init omap2_mcspi_reset(struct omap2_mcspi *mcspi)
{
 struct spi_master *master = mcspi->master;
 u32 tmp;

if (omap2_mcspi_enable_clocks(mcspi))
 return -1;

mcspi_write_reg(master, OMAP2_MCSPI_SYSCONFIG,
 OMAP2_MCSPI_SYSCONFIG_SOFTRESET);
 do {
 tmp = mcspi_read_reg(master, OMAP2_MCSPI_SYSSTATUS);
 } while (!(tmp & OMAP2_MCSPI_SYSSTATUS_RESETDONE));

[...]

Now, I'm using a JTAG debugger on-and-off, and the bit that's incorrectly being twiddled (FREEEMU) does have an impact on debug logic. So, perhaps not using a debugger avoids the crash path. It's also possible that other differences between kernel versions or u-boot initialization prevent this code from crashing in the PSP version.

I'm going to put this aside for now, since I can get past it by changing the soft-reset procedure. I may return to it later if there's a reason. Let me know if you'd like me to repeat the experiment with a stock PSP kernel.

best,

Graeme