The problem I have is that sPI signals don't seem to get on the i/o connector pins dedicated to McSPI bus #1. After investigating the problem, I found which Linux kernel source file was doing BGA ball assignment and mux'ing. The file in question is mux34xx.c . [ref.1]
Since the kernel was built for the AM3517 EVM board with the CONFIG_OMAP_PACKAGE_CBB=y build option, the following ball assignments were used with their respective McSPI signals, as defined by the ~/arch/arm/mach-omap2mux34xx.c kernel source file:
static struct omap_ball __initdata omap3_cbb_ball[] = {
_OMAP3_BALLENTRY(MCSPI1_CLK, "ab3", NULL),
_OMAP3_BALLENTRY(MCSPI1_CS0, "ac2", NULL),
_OMAP3_BALLENTRY(MCSPI1_CS1, "ac3", NULL),
_OMAP3_BALLENTRY(MCSPI1_CS2, "ab1", NULL),
_OMAP3_BALLENTRY(MCSPI1_CS3, "ab2", NULL),
_OMAP3_BALLENTRY(MCSPI1_SIMO, "ab4", NULL),
_OMAP3_BALLENTRY(MCSPI1_SOMI, "aa4", NULL),
};
It should be noted that the source file does not define 'ZCN' ball assignments.
It seems to me that the second parameter indicates a grid location. However, locations for McSPI bus #1 location do not match TI's documented location. I used package type 'ZCN' from the chip itself. As documented, assignments for McSPI bus #1 is as follows: [ref.2]
MCSPI1_SOMI: AC15
MCSPI1_CLK : AC14
MCSPI1_SIMO: AD15
MCSPI1_CS0 : AB15
Clearly, that does not match with Linux kernel i/o mapping. Interestingly, Linux is functional, except for SPI support.
So, either there is something I missed when I built the kernel or either I'm using the wrong kernel 'mux' source file. I would have expected a mux35xx.c file somewhere in the kernel source tree, but the latter does not seem to exist.
That would explain why SPI transmissions don't work. Any pointers/logical explanations about this?
Help!
Yves McDonald
References:
1- SOURCE: ARM35x-OMAP35x-LINUX-PSP-04.02.00.07
2- SOURCE: AM3517/05 Sitara ARM Microprocessor (Rev. C) (PDF 2053 KB) 29 Mar 2011 (http://www.ti.com/litv/pdf/sprs550c)
