BB XM RevC, with 2.6.38 kernel. Did the following:
1. Kernel config:
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_SPIDEV=y
2. Modified board-omap3beagle.c:
static void __init omap3_beagle_config_mcspi4_mux(void)
{
omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_INPUT);
omap_mux_init_signal("mcbsp1_fsx.mcspi4_cs0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", OMAP_PIN_INPUT_PULLUP);
}
static struct spi_board_info beagle_mcspi_board_info[] = {
{
.modalias = "spidev",
.max_speed_hz = 48000000, //48 Mbps
.bus_num = 4,
.chip_select = 0,
.mode = SPI_MODE_1,
},
};
static void __init omap3_beagle_init(void)
{
....
omap_serial_init();
omap3_beagle_config_mcspi4_mux();
spi_register_board_info(beagle_mcspi_board_info,ARRAY_SIZE(beagle_mcspi_board_info));
...
}
3. Recompiled kernel and copied uImage to boot SD.
4. Boot and there are no spidev4.0 device files in /dev??? Am I
missing something simple here?? I don't see any error messages in the
kernel boot log. Why is there no SPIDEV file?? Thx!
Ok, tried this same code on a non-XM Rev C board and it worked fine!
Hmm...I know some of the pins are different on the XM, but the
omap_mux_init_signal() calls in my example code should still work ok,
shouldn't they?? The x-loader on the Rev C is older, but I"m using
the same u-boot (2011.09) on both boards. I did notice this on the
NON-xm board:
[ 0.450504] omap2_mcspi omap2_mcspi.1: registered master spi1
[ 0.451821] omap2_mcspi omap2_mcspi.2: registered master spi2
[ 0.452948] omap2_mcspi omap2_mcspi.3: registered master spi3
[ 0.457347] omap2_mcspi omap2_mcspi.4: registered master spi4
and on the XM board, it only shows the first two. I wonder why spi3/4
masters aren't registering on the XM??? Anyone have any ideas??
Ok, replaced the x-loader and now the kernel, xloader, uboot, and root
fs are all the same on both boards. The non-xm RevC works, the XM
does not (no spidev file, and the 3/4 masters not showing registered
in the boot log).
I'm at a standstill now.....any ideas? I see posts where folks have
gotten the XM to work with SPI...but the patch code they are using is
the same code I have?? I do have some XM patches applied to fix the
pinmuxing with the XM, but it seems to be correct and I2C works fine.
Don't know where to go from here.....
Well, well...another linux goose chase! Turns out all the above code
was correct! However, my particular configuration of:
- Beagleboard XM Rev C
- Linux kernel 2.6.38
- Xenomai 2.60
- BBXM RevC pinmux patches (fixes gpio issues and other things)
is apparently problematic. The file "/linux-omap/arch/arm/mach-omap2/
devices.c" contains code to initialize the 4 SPI buses, but MCSPI3 and
MCSPI4 are initialized conditionally as follows:
static void omap_init_mcspi(void)
{
if (cpu_is_omap44xx())
omap4_mcspi_fixup();
platform_device_register(&omap2_mcspi1);
platform_device_register(&omap2_mcspi2);
if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi3_init();
if (cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi4_init();
}
It seems the 343x macro fails (actually, they all fail!), so neither
3/4 SPI buses are initialized...and hence I have no SPIDEV devices!
The easy fix here is to change the "cpu_is_omap343x()" to
"cpu_is_omap34xx()", and the 3/4 buses will then init just fine!
Apparently the 343x macro does NOT work properly when detecting a
BBXMRevC board! I think it's checking the wrong bits as I recall??
NOTE: The "devices.c" file is filled with several tests using the
34xx macro, and the SPI section was the only one using 343x. This is
probably a bug, and the 34xx should be used for SPI also. I think
these all used to be 343x...but most of em got changed eventually so
the BBXM board devices would work properly. I'm not 100% sure how
these folks with XM board got their SPI 3/4 working without this
patch....perhaps the 343x macro only fails on RevC boards?? Or maybe
it's already been changed in downstream kernels? Who knows....at
least I know this patch will fix my SPI issues with 2.6.38 and
BBxMRevC!