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.
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:
thanks,
Graeme
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
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
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
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