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 /