MCSPI3 working, both ways

1,439 views
Skip to first unread message

Philip Balister

unread,
Feb 18, 2009, 3:43:11 PM2/18/09
to beagl...@googlegroups.com
I have spidev_test reading data sent from the port now. Steve sent me
a patch for u-boot to set up the pinmux in u-boot. I removed the
pinmux code from Linux and I could read data from the SPI port:

http://www.flickr.com/photos/32615155@N00/3291304854/

I'm attaching the patch against OE. The u-boot patch is from Steve.

I compile spidev_test.c with this command:

/home/balister/oe/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc
-o spidev_test spidev_test.c

Adjust for the path to your cross compiler. I am using the one built by OE.

Philip

0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-expa.patch

Yuchih

unread,
Feb 23, 2009, 1:52:36 AM2/23/09
to Beagle Board
Hello,
It is so good to see someone succeed in receiving data!!
Could we have Steve's u-boot patch to try?

thanks,
Yuchih
> 0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-expa.patch
> 19KViewDownload

Philip Balister

unread,
Feb 23, 2009, 7:03:14 PM2/23/09
to beagl...@googlegroups.com
On Mon, Feb 23, 2009 at 1:52 AM, Yuchih <liuy...@gmail.com> wrote:
>
> Hello,
> It is so good to see someone succeed in receiving data!!
> Could we have Steve's u-boot patch to try?

It is the the patch against the OE mete-data :)

I've attached is separately.

Philip
crofton.patch

Yuchih

unread,
Feb 24, 2009, 1:39:20 AM2/24/09
to Beagle Board
Ha, i didn't see the u-boot patch is already in the first patch.
Philip, so only u-boot pinmux setup instead of the one in kernel makes
the RX read available?

I have patched u-boot, but still got Rx all zeros.
My u-boot source is from http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
Kernel source is from linux omap git server.
Maybe i have to try the OE, does anyone also succeed?

yuchih


On Feb 24, 8:03 am, Philip Balister <philip.balis...@gmail.com> wrote:
> crofton.patch
> 1KViewDownload

Philip Balister

unread,
Feb 24, 2009, 10:04:56 AM2/24/09
to beagl...@googlegroups.com
On Tue, Feb 24, 2009 at 1:39 AM, Yuchih <liuy...@gmail.com> wrote:
>
> Ha, i didn't see the u-boot patch is already in the first patch.
> Philip, so only u-boot pinmux setup instead of the one in kernel makes
> the RX read available?

I won't say that, it would be worth trying to setup only the pins that
are setup in the u-boot patch, in the kernel.

> I have patched u-boot, but still got Rx all zeros.
> My u-boot source is from http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
> Kernel source is from linux omap git server.
> Maybe i have to try the OE, does anyone also succeed?

OE does make life easier, once you get the hang of it :)

Philip

Leon Woestenberg

unread,
Feb 27, 2009, 9:59:12 AM2/27/09
to beagl...@googlegroups.com
Hello Philip,

On Wed, Feb 18, 2009 at 9:43 PM, Philip Balister
<philip....@gmail.com> wrote:
> I have spidev_test reading data sent from the port now. Steve sent me
> a patch for u-boot to set up the pinmux in u-boot. I removed the
> pinmux code from Linux and I could read data from the SPI port:
>

Congrats.

> http://www.flickr.com/photos/32615155@N00/3291304854/
>
Nice setup.

Maybe I should exchange one cat for a scope.

It helps debugging in a better way.

Regards,
--
Leon

hemanth_...@yahoo.com

unread,
Mar 2, 2009, 3:38:26 AM3/2/09
to Beagle Board
Hi Philip,

Could you briefly explain your setup and Mux settings below, are these
for the slave mode.

++ 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*/\

I am trying to test data transfers using SPI2 on two OMAP3430SDP
boards. One SPI2 is configured as master and the other as slave. I am
also seeing similar problem where Slave writes but the master is
unable to read proper data. I am trying to figure out if your settings
will help.

Thanks
Hemanth
>  0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-expa.patch
> 19KViewDownload

Philip Balister

unread,
Mar 2, 2009, 8:08:11 AM3/2/09
to beagl...@googlegroups.com
On Mon, Mar 2, 2009 at 3:38 AM, <hemanth_...@yahoo.com> wrote:
>
> Hi Philip,
>
> Could you briefly explain your setup and Mux settings below, are these
> for the slave mode.
>
> ++ 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*/\
>
> I am trying to test data transfers using SPI2 on two OMAP3430SDP
> boards. One SPI2 is configured as master and the other as slave. I am
> also seeing similar problem where Slave writes but the master is
> unable to read proper data. I am trying to figure out if your settings
> will help.

This code sets up the pinmux in u-boot. I'm not sure where the docs
are for this. Hopefully, someone who knows how to set up the pinmux in
u-boot will speak up.

Philip

John (USP)

unread,
Mar 2, 2009, 12:11:41 PM3/2/09
to beagl...@googlegroups.com

> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of
> hemanth_...@yahoo.com
> Sent: Monday, March 02, 2009 12:38 AM
> To: Beagle Board
> Subject: [beagleboard] Re: MCSPI3 working, both ways
>
>
> Hi Philip,
>
> Could you briefly explain your setup and Mux settings below, are these
> for the slave mode.
>
> ++ 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*/\
>
> I am trying to test data transfers using SPI2 on two OMAP3430SDP
> boards. One SPI2 is configured as master and the other as slave. I am
> also seeing similar problem where Slave writes but the master is
> unable to read proper data. I am trying to figure out if your settings
> will help.
I don't believe the Linux SPI driver supports slave mode.

hemanth_...@yahoo.com

unread,
Mar 3, 2009, 1:46:45 AM3/3/09
to Beagle Board
On Mar 2, 10:11 pm, "John \(USP\)" <jsyne...@us-power.com> wrote:
> > -----Original Message-----
> > From: beagl...@googlegroups.com
> > [mailto:beagl...@googlegroups.com] On Behalf Of
> > hemanth_venkat...@yahoo.com
> > Sent: Monday, March 02, 2009 12:38 AM
> > To: Beagle Board
> > Subject: [beagleboard] Re: MCSPI3 working, both ways
>
> > Hi Philip,
>
> > Could you briefly explain your setup and Mux settings below, are these
> > for the slave mode.
>
> > ++ 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*/\
>
> > I am trying to test data transfers using SPI2 on two OMAP3430SDP
> > boards. One SPI2 is configured as master and the other as slave. I am
> > also seeing similar problem where Slave writes but the master is
> > unable to read proper data. I am trying to figure out if your settings
> > will help.
>
> I don't believe the Linux SPI driver supports slave mode.
>

Yes currently it doesnot. I am trying to add slave support but am
facing the above problem. I am able to get Master write/Slave read
working though.

tigmoid

unread,
Mar 11, 2009, 11:04:25 AM3/11/09
to Beagle Board
There is a function in <u-boot>/board/omap3/beagle/beagle.c called
set_muxconf_regs(). It "calls" what really is a define that is set up
in <u-boot>/include/asm-arm/arch-omap3/mux.h, called MUX_DEFAULT_ES2
().

If you want you can change the define for MUX_DEFAULT_ES2 or copy it,
rename it and then "call" your new define from set_muxconf_regs().

The muxing define itself is easy enough to figure out from the
comments right above...


tim

On Mar 2, 9:08 am, Philip Balister <philip.balis...@gmail.com> wrote:
> On Mon, Mar 2, 2009 at 3:38 AM,  <hemanth_venkat...@yahoo.com> wrote:
>
> > Hi Philip,
>
> > Could you briefly explain your setup and Mux settings below, are these
> > for the slave mode.
>
> > ++ 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*/\
>
> > I am trying to test data transfers using SPI2 on two OMAP3430SDP
> > boards. One SPI2 is configured as master and the other as slave. I am
> > also seeing similar problem where Slave writes but the master is
> > unable to read proper data. I am trying to figure out if your settings
> > will help.
>
> This code sets up the pinmux in u-boot. I'm not sure where the docs
> are for this. Hopefully, someone who knows how to set up the pinmux in
> u-boot will speak up.
>
> Philip
>
>
>
> > Thanks
> > Hemanth
>

tigmoid

unread,
Apr 2, 2009, 9:04:47 AM4/2/09
to Beagle Board
The u-boot pin muxing to get spidev working is:

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*/\




naviga...@gmail.com

unread,
Apr 9, 2009, 2:20:16 PM4/9/09
to Beagle Board
I'm running out of options to try on this. So far I've:

Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
expa.patch) patched against openembedded (modified patch directories
to /recipes/ instead of /packages/)

Linux
cleaned bitbake -c clean -b /openembedded/recipes/linux/linux-
omap_2.6.28.bb
rebuilt bitbake -b linux-omap_2.6.28.bb
verified that a message appeared during build "Applying patch 'spi-
test.patch'"

U-Boot
cleaned bitbake -c clean -b /openembedded/recipes/u-boot/u-
boot_git.bb
rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
verified that a message appeared during build "Applying patch
'crofton.patch'"

transferred over the newly built u-boot.bin and uImage to my SD card
from /tmp/deploy/glibc/images/beagleboard.

When the system boots up I can see two registered spi devices under /
dev

spidev3.0
spidev4.0

spidev_test
Cross compiled on development machine and transferred to /home/root on
the beagle. I've been running spidev_test like this:

spidev_test -D /dev/spidev3.0 -s 20000

this produces no errors just something like:

root@beagleboard:~# spidev_test /dev/spidev3.0 -s 2000000 -H -O -b
16
spi mode:
3
bits per word:
16
max speed: 2000000 Hz (2000
KHz)

00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00 00 00 00
00
00 00

Nothing changes on pins 19 (SIMO) or 21 (CLK) when I hook up my scope
and run spidev_test on /dev/spidev3.0, the lines remain pulled high.

Is there a step in here I'm missing? Am I running spidev_test
correctly?

Thanks,

Andrew

Philip Balister

unread,
Apr 10, 2009, 8:46:41 AM4/10/09
to beagl...@googlegroups.com
Have you connected the data in to data out pins so you can loop back
test the driver?

Philip

aLamkin

unread,
Apr 10, 2009, 1:13:33 PM4/10/09
to Beagle Board
Hi Philip thanks for your reply. I have not connected the SIMO line
back onto SOMI on the expansion header, I'll give that a shot today
and see if I can read any data coming out. What really worries me is
that I cannot see any change on the SIMO line on the scope so I have a
sneaking suspicion that nothing is getting out to the pin.

Andrew

On Apr 10, 6:46 am, Philip Balister <philip.balis...@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 2:20 PM,  <navigatio...@gmail.com> wrote:
>
> > I'm running out of options to try on this. So far I've:
>
> > Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
> > expa.patch) patched against openembedded (modified patch directories
> > to /recipes/ instead of /packages/)
>
> > Linux
> > cleaned  bitbake -c clean -b /openembedded/recipes/linux/linux-
> > omap_2.6.28.bb
> > rebuilt  bitbake -b linux-omap_2.6.28.bb
> > verified that a message appeared during build "Applying patch 'spi-
> > test.patch'"
>
> > U-Boot
> > cleaned  bitbake -c clean -b /openembedded/recipes/u-boot/u-
> > boot_git.bb
> > rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
> > verified that a message appeared during build "Applying patch
> > 'crofton.patch'"
>
> > transferred over the newly built u-boot.bin and uImage to my SD card
> > from /tmp/deploy/glibc/images/beagleboard.
>
> > When the system boots up I can see two registeredspidevices under /

Philip Balister

unread,
Apr 10, 2009, 1:20:40 PM4/10/09
to beagl...@googlegroups.com
On Fri, Apr 10, 2009 at 1:13 PM, aLamkin <naviga...@gmail.com> wrote:
>
> Hi Philip thanks for your reply. I have not connected the SIMO line
> back onto SOMI on the expansion header, I'll give that a shot today
> and see if I can read any data coming out. What really worries me is
> that I cannot see any change on the SIMO line on the scope so I have a
> sneaking suspicion that nothing is getting out to the pin.


Yeah, that bother me also. Go over the mux stuff really carefully.
Here is a photo of it working for me:

http://www.flickr.com/photos/32615155@N00/3291304854/

I have a rev A board, not sure if that makes any difference.

Philip

Søren Steen CHristensen

unread,
Apr 10, 2009, 2:33:28 PM4/10/09
to beagl...@googlegroups.com
>On Fri, Apr 10, 2009 at 1:13 PM, aLamkin <naviga...@gmail.com> wrote:
>>
>> Hi Philip thanks for your reply. I have not connected the SIMO line
>> back onto SOMI on the expansion header, I'll give that a shot today
>> and see if I can read any data coming out. What really worries me is
>> that I cannot see any change on the SIMO line on the scope so I have a
>> sneaking suspicion that nothing is getting out to the pin.
>
>
>Yeah, that bother me also. Go over the mux stuff really carefully.
>Here is a photo of it working for me:
>
>http://www.flickr.com/photos/32615155@N00/3291304854/
>
>I have a rev A board, not sure if that makes any difference.
>
> Philip


Hi Andrew,

I can't remember if you previously wrote which board type you have (B or C)?

In case of Rev C take care - The McBSP3 pins (RX, TX and CLK) were changed
compared to Rev B.
This in order to allow access to the PWM signals on the expansion connector
as well..

Instead of muxing the balls AF6, AE6 and AF5 you therefore need to mux the
balls AB26, AB25 and AA25...

With this addition/change to Philips original patch (to u-boot AFAIR?) I
guess it will work for you...

Best regards - Good luck
Søren


Søren Steen CHristensen

unread,
Apr 10, 2009, 2:40:01 PM4/10/09
to beagl...@googlegroups.com
Hmm - Apparently I'm a bit too much into Easter-vacation-mode :-)

Sorry for mixing McBSP3 with McSPI3...

AFAIK there are no changes to the McSPI3 connections...

Best regards and Sorry again
Søren

aLamkin

unread,
Apr 10, 2009, 3:28:22 PM4/10/09
to Beagle Board
I have access to three boards, two rev B6's and one rev C2. The two
I've been testing with are the B6's. I'm running a few tests right
now, hopefully I'll have some results to post soon. Thanks!

On Apr 10, 12:40 pm, Søren Steen CHristensen

Hunyue Yau

unread,
Apr 10, 2009, 11:55:23 PM4/10/09
to beagl...@googlegroups.com
I recently went through the exercise of getting the McSPI4 and McSPI3 to work
and I found a few odd things that might be useful.

The McSPI's seem to have an odd quirk in that it requires the input driver to
be enabled for the clock line. I came to this conclusion after checking the
pin mux and using the sys test features of the McSPI to verify the signals
were indeed being routed to the McSPI block.

Running the test program and with a scope, I was able to verify McSPI
clock out and MOSI. Using the sys test features (see TRM), I was able to
read the state of the MISO line after tying it high or low through a resistor
to either 18V or ground. My understanding of the sys test functionality is
that the read back of the lines is totally independent from the GPIO input
stuff.

What made the loop back work for me was enabling the input receivers
on the McSPI clock line. It is behaving as if the input shift register for the
McSPI is gettng its clock from outside of the block (but still inside the
chip). Prehaps this was a designed in feature to allow a seperate input clock
that got removed at the last minute on the OMAP? Just a guess as I was
not able to find an errata or note about this requirement. The McSPI is
definitely more complex then the original SPI stuff where MISO and MOSI are
ends of the same shift register so there is only one clock.

Hope this is somewhat helpful as I do not use OE.
--
Hunyue Yau
http://www.hy-research.com/

aLamkin

unread,
Apr 11, 2009, 4:34:00 PM4/11/09
to Beagle Board
Thanks for all the replies,

I wired up SIMO(19) to SOMI(17) on my last build, ran spidev_test
again but still nothing coming in or going out on the scope.

Tried Drastic measures - wiped out my entire openembedded install,
reinstalled, got a fresh copy of the meta-data.
ran the original patch again (changing /packages to /recipes again in
the patch file) from my OE/openembedded directory.

Verified that the changes to /recipes/linux/linux-omap-2.6.28/
beagleboard/defconfig were made.

Verified that crofton.patch was created in /OE/openembedded/recipes/u-
boot/files and that

SRC_URI_beagleboard = "git://www.sakoman.net/git/u-boot-
omap3.git;branch=omap3-dev;protocol=git \
file://crofton.patch;patch=1 "

got added to OE/openembedded/recipes/u-boot/u-boot_git.bb

Verified that spi-test.patch was created in /OE/openembedded/recipes/
linux-omap-2.6.28/beagleboard/ and that

file://spi-test.patch;patch=1 \
"

made it into /OE/openembedded/packages/linux/linux-omap_2.6.28.bb

ran bitbake base-image
ran bitbake console-image
copied the brand new Angstrom-console-image-glibc-ipk-2009.X-
test-20090410-beagleboard.rootfs.tar.bz2 onto my "disk" SD card
partition and unzipped
copied the new uImage-beagleboard.bin (uImage-2.6.28-r18-
beagleboard.bin) onto the boot partition of my SD card, replacing the
old uImage
copied the new u-boot-beagleboard.bin (u-boot-
beagleboard-2008.10+r22+gitrb7038cff739684bb95853eb5bee924c2574a222e-
r22.bin) onto the boot partition of my SD card, replacing the old u-
boot.bin

fired up the beagleboard with the new SD card, booted into Angstrom.
Confirmed the existence of /dev/spidev3.0 and /dev/spidev4.0. Cross
compiled and transferred spidev_test over again, hooked up pin 19 SIMO
to my scope, and ran spidev_test. Nothing changed on the scope, still
pulled high. Connected pin 17 and pin 19 together and ran spidev_test
again, nothing shows in received data either. So I'm still stuck with
my first guess of nothing's getting out to the pin. Just to be sure I
tried this same SD card on two rev B6 boards, same result.

I must be missing something, are there any changes to other files I
should be making? Any possible conflicts I should check for?

@Hunyue Yau
I've got a seperate effort using CodeSourcery to compile u-boot

git clone git://gitorious.org/u-boot-omap3/mainline.git
git checkout --track -b omap3-dev origin/omap3-dev

I've been modifying board/omap3/beagle/beagle.h
with the pin muxing in Philip's patch above:
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*/\

and compiling with
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
make CROSS_COMPILE=arm-none-linux-gnueabi-

I'll try the clock line idea you mentioned above.



Thanks a ton for your responses, I really appreciate your help.

Andrew



On Apr 10, 9:55 pm, Hunyue Yau <ybea...@rehut.com> wrote:
> I recently went through the exercise of getting the McSPI4 and McSPI3 to work
> and I found a few odd things that might be useful.
>
> The McSPI's seem to have an odd quirk in that it requires the input driver to
> be enabled for the clock line. I came to this conclusion after checking the
> pin mux and using the sys test features of the McSPI to verify the signals
> were indeed being routed to the McSPI block.
>
> Running the test program and with a scope, I was able to verify McSPI
> clock out and MOSI. Using the sys test features (see TRM), I was able to
> read the state of the MISO line after tying it high or low through a resistor
> to either 18V or ground. My understanding of the sys test functionality is
> that the read back of the lines is totally independent from the GPIO input
> stuff.
>
> What made the loop back work for me was enabling the input receivers
> on the McSPI clock line. It is behaving as if the input shift register for the
> McSPI is gettng its clock from outside of the block (but still inside the
> chip). Prehaps this was a designed in feature to allow a seperate input clock
> that got removed at the last minute on the OMAP? Just a guess as I was
> not able to find an errata or note about this requirement. The McSPI is
> definitely more complex then the originalSPIstuff where MISO and MOSI are
> ends of the same shift register so there is only one clock.
>
> Hope this is somewhat helpful as I do not use OE.
>
> On Friday 10 April 2009 05:46, Philip Balister wrote:
>
> > On Thu, Apr 9, 2009 at 2:20 PM,  <navigatio...@gmail.com> wrote:
> > > I'm running out of options to try on this. So far I've:
>
> > > Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
> > > expa.patch) patched against openembedded (modified patch directories
> > > to /recipes/ instead of /packages/)
>
> > > Linux
> > > cleaned  bitbake -c clean -b /openembedded/recipes/linux/linux-
> > > omap_2.6.28.bb
> > > rebuilt  bitbake -b linux-omap_2.6.28.bb
> > > verified that a message appeared during build "Applying patch 'spi-
> > > test.patch'"
>
> > > U-Boot
> > > cleaned  bitbake -c clean -b /openembedded/recipes/u-boot/u-
> > > boot_git.bb
> > > rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
> > > verified that a message appeared during build "Applying patch
> > > 'crofton.patch'"
>
> > > transferred over the newly built u-boot.bin and uImage to my SD card
> > > from /tmp/deploy/glibc/images/beagleboard.
>
> > > When the system boots up I can see two registeredspidevices under /
Message has been deleted

Søren Steen CHristensen

unread,
Apr 12, 2009, 3:50:26 AM4/12/09
to beagl...@googlegroups.com
One wild guess. Dependent on the X-loader version you have in your NAND
flash, it will load pr. default load the u-boot from flash and not the one
from the SD-card. The old x-loaders have this behavior - The newer ones have
SD-card as their preferred source for u-boot...

In case you haven't done so already, please make sure that u-boot is
actually run from the SD card by:
1) checking the log during booting (one of the very first lines on the
serial console)
2) Updating the X-loader in the NAND to the latest one from the
GIT-repository in order to make sure that SD will the precedence...

Best regards - Good luck
Søren


-----Original Message-----
From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On
Behalf Of aLamkin
Sent: Saturday, April 11, 2009 10:35 PM
To: Beagle Board
Subject: [beagleboard] Re: MCSPI3 working, both ways


> definitely more complex then the originalSPIstuff where MISO and MOSI are
> ends of the same shift register so there is only one clock.
>
> Hope this is somewhat helpful as I do not use OE.
>
> On Friday 10 April 2009 05:46, Philip Balister wrote:
>
> > On Thu, Apr 9, 2009 at 2:20 PM,  <navigatio...@gmail.com> wrote:
> > > I'm running out of options to try on this. So far I've:
>
> > > Using (0001-Changes-to-make-MCSPI3-work-on-the-Beagle-Board-
> > > expa.patch) patched against openembedded (modified patch directories
> > > to /recipes/ instead of /packages/)
>
> > > Linux
> > > cleaned  bitbake -c clean -b /openembedded/recipes/linux/linux-
> > > omap_2.6.28.bb
> > > rebuilt  bitbake -b linux-omap_2.6.28.bb
> > > verified that a message appeared during build "Applying patch 'spi-
> > > test.patch'"
>
> > > U-Boot
> > > cleaned  bitbake -c clean -b /openembedded/recipes/u-boot/u-
> > > boot_git.bb
> > > rebuilt bitbake -b /openembedded/recipes/u-boot/u-boot_git.bb
> > > verified that a message appeared during build "Applying patch
> > > 'crofton.patch'"
>
> > > transferred over the newly built u-boot.bin and uImage to my SD card
> > > from /tmp/deploy/glibc/images/beagleboard.
>
> > > When the system boots up I can see two registeredspidevices under /
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.285 / Virus Database: 270.11.52/2053 - Release Date: 04/10/09
18:27:00

aLamkin

unread,
Apr 23, 2009, 9:41:02 PM4/23/09
to Beagle Board
Nice catch, thank you Soren that was it. I updated the x-loader on the
board to the latest version and now have MCSPI3 fully transmitting and
receiving data from an ADIS16354 inertial measurement unit thanks to
Philip's OE patch above.

This brings up one more question. If I wanted to also enable the
MCSPI4 port on the expansion header would I use the same settings that
are in the crofton.patch except applied to GPIO 156 158 and 159?

MUX_VAL(CP(MCBSP4_FSX), (IEN | PTD | DIS | M1)) /*SSI1_WAKE*/
\
- MUX_VAL(CP(MCBSP1_CLKR), (IDIS | PTD | DIS | M4)) /*GPIO_156*/
\
+ MUX_VAL(CP(MCBSP1_CLKR), (IEN | PTU | DIS | M1)) /*MCSPI4_CLK*/
\
MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | EN | M4)) /*GPIO_157*/
\
- MUX_VAL(CP(MCBSP1_DX), (IDIS | PTD | DIS | M4)) /*GPIO_158*/
\
+ MUX_VAL(CP(MCBSP1_DX), (IEN | PTU | DIS | M1)) /
*MCSPI4_SIMO*/\
- MUX_VAL(CP(MCBSP1_DR), (IDIS | PTD | DIS | M4)) /*GPIO_159*/
\
+ MUX_VAL(CP(MCBSP1_DR), (IEN | PTU | EN | M1)) /*MCSPI4_SOMI*/
\
MUX_VAL(CP(MCBSP_CLKS), (IEN | PTU | DIS | M0)) /
*McBSP_CLKS*/\

Just curious to see if anyone has attempted this.

Thanks,

Andrew


On Apr 12, 1:50 am, Søren Steen CHristensen

Hunyue Yau

unread,
Apr 24, 2009, 1:52:32 AM4/24/09
to beagl...@googlegroups.com
On Thursday 23 April 2009 18:41, aLamkin wrote:
> Nice catch, thank you Soren that was it. I updated the x-loader on the
> board to the latest version and now have MCSPI3 fully transmitting and
> receiving data from an ADIS16354 inertial measurement unit thanks to
> Philip's OE patch above.
>
> This brings up one more question. If I wanted to also enable the
> MCSPI4 port on the expansion header would I use the same settings that
> are in the crofton.patch except applied to GPIO 156 158 and 159?
>
> MUX_VAL(CP(MCBSP4_FSX), (IEN | PTD | DIS | M1)) /*SSI1_WAKE*/
> \
> - MUX_VAL(CP(MCBSP1_CLKR), (IDIS | PTD | DIS | M4)) /*GPIO_156*/
> \
> + MUX_VAL(CP(MCBSP1_CLKR), (IEN | PTU | DIS | M1)) /*MCSPI4_CLK*/
> \
> MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | EN | M4)) /*GPIO_157*/
> \
> - MUX_VAL(CP(MCBSP1_DX), (IDIS | PTD | DIS | M4)) /*GPIO_158*/
> \
> + MUX_VAL(CP(MCBSP1_DX), (IEN | PTU | DIS | M1)) /
> *MCSPI4_SIMO*/\
> - MUX_VAL(CP(MCBSP1_DR), (IDIS | PTD | DIS | M4)) /*GPIO_159*/
> \
> + MUX_VAL(CP(MCBSP1_DR), (IEN | PTU | EN | M1)) /*MCSPI4_SOMI*/
> \
> MUX_VAL(CP(MCBSP_CLKS), (IEN | PTU | DIS | M0)) /
> *McBSP_CLKS*/\
>
> Just curious to see if anyone has attempted this.

I had McSPI4 working in loopback with basically this change. You might also
want to enable the CS line. i.e. something like -
+ MUX_VAL(CP(MCBSP1_FSX), (IEN | PTD | EN | M1)) /*MCSPI4_CS0*/\
Reply all
Reply to author
Forward
0 new messages