BeagleBoard SPI woes

GoogleGroups
1

I am just starting out with the BeagleBoard rev C4 for my robotics
project. I am trying to get SPI, UART2, and a small selection of GPIO
pins going.

What I'm running:
OS: Ubuntu Maverick
Kernel: linux-source-2.6.35

My problem?
I don't see SPI3 or UART2 in the /dev directory after remaking the
uImage and loading it up.
I added the following to the initdata section:
  OMAP3_MUX(SDMMC2_CLK, OMAP_MUX_MODE1 | OMAP_PIN_INPUT), //clock for
SPI3
  OMAP3_MUX(SDMMC2_CMD, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT), //SIMO for
SPI3
  OMAP3_MUX(SDMMC2_DAT0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT), //SOMI for
SPI3
  OMAP3_MUX(SDMMC2_DAT1, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT), //CS '2'
for SPI3
  OMAP3_MUX(SDMMC2_DAT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT), //CS1 for
SPI3
  OMAP3_MUX(SDMMC2_DAT3, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT), //CS0 for
SPI3
  OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT), //
GPT9_PWMEVT
  OMAP3_MUX(UART2_RTS, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT), //GPIO
Output for LCD
  OMAP3_MUX(UART2_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), //UART2_TX
  OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT), //UART2_RX

I also added to omap3_beagle_init:
        /* Initialize all signals and gpio pin stuff*/
        omap_mux_init_signal("sdmmc2_clk.mcspi3_clk",
OMAP_PIN_OUTPUT);
  omap_mux_init_signal("sdmmc2_cmd.mcspi3_simo", OMAP_PIN_OUTPUT);
        omap_mux_init_signal("sdmmc2_dat0.mcspi_somi",
OMAP_PIN_INPUT_PULLUP);
  omap_mux_init_gpio(145, OMAP_PIN_OUTPUT); //ab25
  omap_mux_init_gpio(135, OMAP_PIN_OUTPUT); //af4
        omap_mux_init_gpio(134, OMAP_PIN_OUTPUT); //ag4
        omap_mux_init_gpio(133, OMAP_PIN_OUTPUT); //ah4
  omap_mux_init_signal("uart2_cts.gpt9_pwmevt", OMAP_PIN_OUTPUT);
  omap_mux_init_signal("uart2_tx.uart2_tx", OMAP_PIN_OUTPUT);
  omap_mux_init_signal("mcbsp3_fsx.uart2_rx", OMAP_PIN_INPUT);
  spi_register_board_info(beagle_mcspi_board_info,
        ARRAY_SIZE(beagle_mcspi_board_info));

I then compiled:
make distclean
make ARCH=arm omap3_beagle_defconfig
make ARCH=arm uImage

I loaded that up and booted and saw nothing in /dev for my SPI.
I have put in alot of hours and have no idea what I am missing.

2

You have looked here[1]? Make sure your .config includes SPI,
SPI_OMAP24XX, and SPI_DEV. How are you building your kernel?

Cheers,

- Ben

[1] http://elinux.org/BeagleBoard/SPI#Patches

3

Last year I had a student team do a robot project with the Beagle.
They used i2c, but maybe you can learn something from the project
page: [1].

--Mark

[1] http://elinux.org/ECE597_Project_Sumo_Robot

4

So I thought that the three steps below were used to remake the
kernel:
make distclean
make ARCH=arm omap3_beagle_defconfig
make ARCH=arm uImage

...is that wrong? I saw it rebuild board_omap3beagle.o which I thought
was the important part.
I do everything listed in the patch. I am booting up my Beagle to
triple check the config file stuff.

Do the chip select lines have to be selected as such? I currently am
setting them as GPIO.

5

I like the idea of using I2C, but my team and I just assumed from the
get-go that the SPI stuff would be easy to figure out. We already
designed and ordered our own custom breakout board.

6

So I thought that the three steps below were used to remake the
kernel:
make distclean
make ARCH=arm omap3_beagle_defconfig
make ARCH=arm uImage

Looks good.

I do everything listed in the patch. I am booting up my Beagle to
triple check the config file stuff.

I'll be waiting.

Do the chip select lines have to be selected as such? I currently am
setting them as GPIO.

The spidev layer doesn't care. You should see the device either way,

Cheers,

- Ben

7

Hello all,

I spent a lot of time(~1 month) getting SPI to work. I used Code Sourcery G++ Lite 2009q1-203, it the free/lite version.

#1. Compiling the kernel. I tried a few distributions of the kernel with the spi patch and found that this one worked. Here's the url for the git repository for the kernel.

url = git://gitorious.org/beagleboard-validation/linux.git

Long story short, the beagleboard validation image works with this patch http://elinux.org/BeagleBoard/SPI/Patch-2.6.32

#2. You'll also have to compile a patched version of uboot. This is how. The file is uboot/u-boot-main/board/ti/beagle/beagle.h
Look a the changes.

url = git://git.denx.de/u-boot.git
[branch "omap3"]
     remote = origin
     merge = refs/heads/master

/*Wireless LAN */\
     /*MUX_VAL(CP(MMC2_CLK), (IEN | PTU | EN | M4)) GPIO_130*/\
     /*MUX_VAL(CP(MMC2_CMD), (IEN | PTU | EN | M4)) GPIO_131*/\
     /*MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M4)) GPIO_132*/\
     MUX_VAL(CP(MMC2_CLK), (IEN | PTU | DIS | M1)) /*MCSPI3_CLK*/\
     MUX_VAL(CP(MMC2_CMD), (IEN | PTU | DIS | M1)) /*MCSPI3_SIMO*/\
     MUX_VAL(CP(MMC2_DAT0), (IEN | PTU | EN | M1)) /*MCSPI3_SOMI*/\
     MUX_VAL(CP(MMC2_DAT1), (IEN | PTU | EN | M4)) /*GPIO_133*/\
     /*MUX_VAL(CP(MMC2_DAT2), (IEN | PTU | EN | M4)) GPIO_134*/\
     /*MUX_VAL(CP(MMC2_DAT3), (IEN | PTU | EN | M4)) GPIO_135*/\
     MUX_VAL(CP(MMC2_DAT2), (IDIS | PTU | DIS | M1)) /*GPIO_134*/\
     MUX_VAL(CP(MMC2_DAT3), (IDIS | PTU | DIS | M1)) /*GPIO_135*/\
     MUX_VAL(CP(MMC2_DAT4), (IEN | PTU | EN | M4)) /*GPIO_136*/\
     MUX_VAL(CP(MMC2_DAT5), (IEN | PTU | EN | M4)) /*GPIO_137*/\
     MUX_VAL(CP(MMC2_DAT6), (IEN | PTU | EN | M4)) /*GPIO_138*/\
     MUX_VAL(CP(MMC2_DAT7), (IEN | PTU | EN | M4)) /*GPIO_139*/\

3. I didn't remember having to modify anything for MLO. The only problem I had was getting the final result. This involved building something called ift. It signs xloader and produces the final product, MLO(if I remember correctly)

url = git://gitorious.org/x-load-omap3/mainline.git
remote = origin
merge = refs/heads/master

I hope this helps. Like I said, I tried for at least one month(no exaggeration) to get SPI working. It does work! I use the same uImage, u-boot.bin and MLO files with a basic rootfs on my BBXM and BBC4 and both work flawlessly.

There is a lot of information out there on how to accomplish what I have described above. The learning curve was/is steep but worth the effort. I still have much to learn.

8

Thank’s a lot!!!..

Question: How do you apply the patch? and where?.

I’m triying to get SPI work on expansion (about a month too!) but I’m lost.

9

Alright. After a long weekend, I am trying to move the kernel to 2.6.37 as the 2.6.35 hasn’t successfully built. I tried using the build_kernel.sh and load_uImage.sh scripts since I have been cross-compiling for the BeagleBoard, as well as compiling the kernel source on the Beagleboard itself. I can’t get the new uImage to boot. I make it the normal way, but when I view the startup over a serial connection it gets past the u-boot commands and then hangs. No output ever shows up. I can copy the original uImage and u-boot.bin over and it’s ok.

I got my u-boot-omap as David explained and tried patching it. I then use the resulting mkimage for making my new uImage.

I copy the u-boot.bin over first and then copy the new uImage in. It then hangs as I explained.

I’m running out of time, and my team is starting to think that using a software method for GPIO is a more realistic expectation than getting the kernel to play nice. Any help would be appreciated.

10

Alright. After a long weekend, I am trying to move the kernel to 2.6.37 as
the 2.6.35 hasn't successfully built. I tried using the build_kernel.sh and
load_uImage.sh scripts since I have been cross-compiling for the
BeagleBoard, as well as compiling the kernel source on the Beagleboard
itself. I can't get the new uImage to boot. I make it the normal way, but
when I view the startup over a serial connection it gets past the u-boot
commands and then hangs. No output ever shows up. I can copy the original
uImage and u-boot.bin over and it's ok.

and did you change console=ttyS2 to ttyO2 ?

11

Alright. After a long weekend, I am trying to move the kernel to 2.6.37 as
the 2.6.35 hasn't successfully built. I tried using the build_kernel.sh and
load_uImage.sh scripts since I have been cross-compiling for the
BeagleBoard, as well as compiling the kernel source on the Beagleboard
itself. I can't get the new uImage to boot. I make it the normal way, but
when I view the startup over a serial connection it gets past the u-boot
commands and then hangs. No output ever shows up. I can copy the original
uImage and u-boot.bin over and it's ok.

Sounds like you forgot to change the console parameter to ttyO2 (OMAP
serial controllers are now named ttyO*, from ttyS* prior to 2.6.37).

I'm running out of time, and my team is starting to think that using a
software method for GPIO is a more realistic expectation than getting the
kernel to play nice. Any help would be appreciated.

It shouldn't be too tough. Just stick with it. I'll be at the keyboard
all day today, so don't hesitate to email the list with questions.

Cheers,

- Ben

12

Alright. Sounds like a plan. I will do that as well. in your experience, does the order in which you copy over the MLO, u-boot.bin, and uImage matter?

Also, I made a new uInitrd, and I am unsure of whether or not I need it.

13

At one time it did.. Just to be safe, put them on the sd card in that order..

uInitrd's are not that essential, it just helps fix some time related
issues on boot with ubuntu..

Regards,

14

Alright. Sounds like a plan. I will do that as well. in your experience,
does the order in which you copy over the MLO, u-boot.bin, and uImage
matter?

Absolutely. MLO must be first. I'm honestly not certain whether
u-boot.bin must be second, but it's not a bad practice. uImage I place
last.

Also, I made a new uInitrd, and I am unsure of whether or not I need it.

Depends upon your kernel configuration. I generally compile a monolithic
kernel so there is no need for an initrd.

- Ben

15

I think MLO still needs to be first. I don't believe the boot firmware
understands FAT.

- Ben

16

“Depends upon your kernel configuration. I generally compile a monolithic
kernel so there is no need for an initrd.”

When you say that, is there a change to the build steps on the eLinux page (i.e. some thing added to the make steps)?
I like the idea of using a truly monolithic kernel, and I am just trying to grasp how to do so. From what I’ve read, the make modules steps that I’ve been doing:
make modules
depmod -a
update-initramfs -c -k 2.6.37 -t

make the kernel something outside the realm of monolithic but not quite microkernel.

-Neil

17

When you say that, is there a change to the build steps on the eLinux page
(i.e. some thing added to the make steps)?

Simply configure the kernel not to build any modules (i.e. with
menuconfig).

I like the idea of using a truly monolithic kernel, and I am just trying to
grasp how to do so. From what I've read, the make modules steps that I've
been doing:

By monolithic I simply mean not using modules; all of the functionality
needed to bring the board up is compiled into the kernel.

- Ben

18

It seems like a good idea, but that’ll be for the longterm when I get back to my personal robot and not my senior project.

I was wondering what u-boot people who are seeing spi use. I used the git that was /beagleboard-validation/u-boot.git.

I am just trying to evaluate all of the choices that have been made with hopes of finding the problem. Also, I will be able to get some idea as to how the actual boot sequence is going tomorrow when I have my USB to Serial cable. Until then, there is only introspection.

19

So…
We kinda ran out of time to work on this BeagleBoard insanity. We, uh, decided on using my robotics board. Thought I’d tell the internet what we’re using now:
Roboard RB-110

It’s robotics specific, so it’ll be faster for our needs. The response time for my BeagleBoard questions was great.

Thanks,
Neil