Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 1387 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux support for AM3874/DM8148 in Arago linux-omap3

Graeme Smecher
Intellectual 415 points
Other Parts Discussed in Thread: AM3874, SYSCONFIG, LINUXEZSDK-SITARA, CDCE62005

I'm trying to get Linux working on an AM3874 board. I've started with the linux-omap3 tree from arago-project.org:

git://arago-project.org/git/projects/linux-omap3.git

Now, I've almost got the kernel booting. However, the McSPI driver in this kernel tree appears to be incompatible with this chip's drivers, even when using ti8148_evm_defconfig. The MCSPI peripheral gets confused during omap2_mcspi_probe() and crashes the processor.

I've traced the problem to the soft-reset bit in the MCSPI_HL_SYSCONFIG register. For the am3874, this register is defined on Page 2585 of sprug7c:

http://www.ti.com/lit/ug/sprugz7c/sprugz7c.pdf#page=2584

The register is identical on the DM8148. However, the register layout in drivers/spi/omap2_mcspi.c is incompatible: the soft reset bit is defined as bit 1, when it should be bit 0 for this device:

#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET BIT(1)

I can correct this particular problem by fixing the bit definitions. However, I have a few higher-level questions:

  • Is there a better kernel snapshot to use for the am3874 so I can avoid problems like this in the future?
  • Are there other known "gotchas" w.r.t. driver support from TI's kernel sources?

thanks,

Graeme

  • 0
    TI__Guru**** 170625 points

    Hi Graeme,

    The AM3874 device is validated with EZSDK 5.04.00.11 and PSP04.04.00.01, see below:

    http://www.ti.com/tool/linuxezsdk-sitara -> http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/5_04_00_11/index_FDS.html -> ezsdk_dm814x-evm_5_04_00_11_setuplinux

    We are no longer validating our AM38xx devices on new EZSDKs/PSPs, the last one was 5.04.

    BR
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 415 points

    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

  • 0 in reply to Graeme Smecher
    TI__Guru**** 170625 points

    Graeme,

    Regarding the SPI issue, I suspect you are looking at the wrong register. We have two variants of the McSPI SYSCONFIG register:

    1. MCSPI_HL_SYSCONFIG at offset 0x10. For McSPI0, the full address is 0x48030010 (see AM387x datasheet)

    2. MCSPI_SYSCONFIG at offset 0x110. For McSPI0, the full address is 0x48030110 (see AM387x datasheet)

    And the McSPI driver (linux-2.6.37-psp04.04.00.01/drivers/spi/omap2_mcspi.c) is using the MCSPI_SYSCONFIG variant, where the SOFTRESET bit is at [1] position, which match the definition #define OMAP2_MCSPI_SYSCONFIG_SOFTRESET    BIT(1)

    The base address is defined in linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/devices.c

    #define TI81XX_MCSPI1_BASE        0x48030100
    #define TI814X_MCSPI2_BASE        0x481A0100
    #define TI814X_MCSPI3_BASE        0x481A2100
    #define TI814X_MCSPI4_BASE        0x481A4100

    And the offset is defined in linux-2.6.37-psp04.04.00.01/drivers/spi/omap2_mcspi.c

    #define OMAP2_MCSPI_SYSCONFIG        0x10

    Thus for McSPI0 we have full address of 0x48030110, which correspond to the MCSPI_SYSCONFIG register (not to MCSPI_HL_SYSCONFIG).

    Graeme Smecher said:
    Let me know if you'd like me to repeat the experiment with a stock PSP kernel.

    Yes, try with a stock PSP kernel, from the EZSDK 5.04.

    Are you using AM387x EVM or AM387x based custom board? In case of custom board, you should also follow the below wiki:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_McSPI_Driver_Guide

    BR
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 415 points

    Hi Pavel,

    Thanks for the attention -- this is the hint I needed. I was confusing the two register definitions. My "fix" was side-stepping the issue by avoiding McSPI soft-reset.

    This is a board-specific quirk: my SPI1 bus is connected to the PLL (TI's CDCE62005) that generates the 20 MHz ARM clock. When the McSPI is soft-reset, there's a downward glitch on the CS line that confuses the PLL. This cuts off the ARM's clock, and it's no surprise that I can't proceed.

    I am able to work around the issue in a number of ways, but the simplest is to mux the CS0 to a GPIO bit, rather than the McSPI, when the kernel boots. After boot-up, if necessary, the signal can be re-routed to CS0 without any problems.

    Thanks again for your time!

    cheers,

    Graeme