Newbie Problems: Cross Compilation and McBSP with Overo Waterstorm and Alcatraz Board

[thfr]

Hello Gumstix Community,

I happy to see such an active and helpful user group because I really
need help :)

At first, my intention: I want to implement a simple transmission
protocol called "Fast Serial Bus" (FSB) with which I want to handle the
data from another device (CMX981 by CML Microcircuits). The CMX981
supplies the clock signal, the words are 16 or 32 bits and there are
frame sync signals for each direction marking the beginning of a word.
Here is an illustration of the protocol:
https://dl.dropboxusercontent.com/u/207133/cml_cmx981_fsb_operation.png
. CML suggested the use of McBSP. Afterwards, I need to implement a Pi/4 DQPSK
Demodulator because the RX path delivers only pairs of I/Q constellation
data.

Right now, I am struggling with a lot of newbie problems since my
experience with embedded systems is rather limited. Also for now, I
don't have a SD card, so I have only the stock Angstrom and probably
need a cross compilation environment which would be my first problem. I
am stuck with windows on my working PC but have Arch Linux (private
laptop) and Ubuntu (VM) at my disposal. I have seen tutorials setting up
an Open Embedded environment and the Gumstix introduction to
cross-compilation (http://gumstix.org/basic-cross-compilation.html) is
just compiling a kernel with gcc-arm-linux-gnueabi.

The next problem is McBSP pinout. There are now dedicated pins for this
on the Alcatraz, but searching through your mailing list I read that
certain pins can configured as McBSP signals. Searching through the
documentation, I didn't find a way that explains this feature.

In Summary:
1. Do I need a Open Embedded ? If yes, how to set it up correctly and on
what system? (up-to-date tutorial?)
2. How to get McBSP signals on pins of the Alcatraz board ?

I don't mind RTFMs at all if you can point my to the right manuals or
tutorials.


------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Andy Walls]

On Thu, 2013-08-22 at 10:41 +0700, Thomas Frank wrote:
> Hello Gumstix Community,

[snip]

> Right now, I am struggling with a lot of newbie problems since my
> experience with embedded systems is rather limited. Also for now, I
> don't have a SD card, so I have only the stock Angstrom and probably
> need a cross compilation environment which would be my first problem. I
> am stuck with windows on my working PC but have Arch Linux (private
> laptop) and Ubuntu (VM) at my disposal. I have seen tutorials setting up
> an Open Embedded environment and the Gumstix introduction to
> cross-compilation (http://gumstix.org/basic-cross-compilation.html) is
> just compiling a kernel with gcc-arm-linux-gnueabi.
>
> The next problem is McBSP pinout. There are now dedicated pins for this
> on the Alcatraz, but searching through your mailing list I read that
> certain pins can configured as McBSP signals. Searching through the
> documentation I have, I didn't find a way that explains this feature.
>
> In Summary:
> 1. Do I need a Open Embedded ? If yes, how to set it up correctly and on
> what system? (up-to-date tutorial?)

You're likely going to need a customized U-Boot and/or kernel to get the
pin-mux set up properly and to make use of the McBSP for something other
than sound/audio.

I'd recommend a Yocto build.  The learning curve can be high, but in the
end, keeping up to date with the latest features is easier.

http://gumstix.org/software-development/yocto-project.html
https://github.com/gumstix/Gumstix-YoctoProject-Repo

Skipping ahead some steps...

To build the image files:

$ bitbake gumstix-console-image
(Takes about 2.5 hours for me on my 4-core laptop.  A VM will take much
longer.)

To build a cross compilation toolchain, that only uses headers and
libraries that are installed in the target image:

$ bitbake gumstix-console-image -c populate_sdk


> 2. How to get McBSP signals on pins of the Alcatraz board ?

You will need to consult the TI OMAP Technical Reference Manual (freely
available from TI), the Gumstix Overo Reference document, and the
Alcatraz schematic (freely available from Gumstix) to understand the
pin-mux and what pins you can use.

If your electrical design needs pins configured ASAP, you will probably
need to modify u-boot source files:
        board/overo/overo.c
        board/overo/overo.h

If not, you can defer configuration of the pin mux to the linux kernel:
        arch/arm/mach-omap2/board-overo.c
or in a custom kernel module, or maybe from user space using debugfs.

When setting the pin mux, to avoid frying hardware you must *avoid*:
        floating CMOS inputs
        bus fights on outputs
        driving the OMAP I/O pins before the SYSEN signal is asserted


Regards,
Andy

> I don't mind RTFMs at all if you can point my to the right manuals or
> tutorials.



------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Peter A. Bigot]

On 08/22/2013 07:23 AM, Andy Walls wrote:
> You're likely going to need a customized U-Boot and/or kernel to get the
> pin-mux set up properly and to make use of the McBSP for something other
> than sound/audio.
>
> I'd recommend a Yocto build.  The learning curve can be high, but in the
> end, keeping up to date with the latest features is easier.
>
> http://gumstix.org/software-development/yocto-project.html
> https://github.com/gumstix/Gumstix-YoctoProject-Repo

Keep in mind http://gumstix.8.x6.nabble.com/McBSP-Driver-td4967321.html 
which ultimately leads to
http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 which
explains that much of the McBSP support for anything other than audio
was removed starting with Linux 3.3.  You'd need to review that to
determine whether you need to use Linux 3.2, or would need to make
significant customizations to the kernel.  I believe 3.2 is still
technically an option in dylan (Yocto 1.4), but expect it to be dropped
from Yocto 1.5 coming out in October.

Peter

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[the suicidal eggroll]

The OE Angstrom build still uses the 3.2 kernel and works well for
McBSP.  I'm currently using that build with the Overo STORM modules and
a custom expansion board to interface with a TI DSP via McBSP3, and soon
to a CPLD on another board via McBSP5.

Thomas - see the following links for some additional assistance:

Setting up the OE Angstrom build environment:
http://gumstix.8.x6.nabble.com/Building-the-stable-Overo-Angstom-image-td4967694.html

Gumstix McBSP kernel module example (for an old kernel, but still helpful):
http://gumstix.8.x6.nabble.com/DMA-McBSP-help-td667552.html

u-boot pin muxing is pretty straight forward, basically just edit
overo-oe/tmp/work/overo-angstrom-linux-gnueabi/u-boot*/git/board/overo/overo.h
and change the input enable flag, pull up/down direction, pull up/down
enable, and "mode" to what you need for the pins you're interested in
(see Gumstix schematics for what pins you have available to you) and
then rebuild.  For permanent changes you'll need to make a patch file
and incorporate that into your bitbake recipe.  jumpnowtek used to have
a page on that, but it looks like it's been converted to yocto.  Still
might be of some use:
http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=55&Itemid=61

For more on the "mode" see the OMAP TRM:
http://www.ti.com/lit/ug/sprugn4r/sprugn4r.pdf (section 7.4.4.3 pages
773 to 783)

The OMAP chips on OVERO have 5 McBSPs, but only two of them are
available on the 70-pins (3 and 5), both of which are 4 pin McBSPs (DR,
DX, and a common CLK and FS).  It sounds like you might need a 6-pin
McBSP, unless you can configure the CMX981 to synchronize the input and
output clock and FS?  Something to look into.  See more in the above
linked TRM, chapter 21.

-Adam


On 08/22/2013 07:03 AM, Peter A. Bigot wrote:

> On 08/22/2013 07:23 AM, Andy Walls wrote:
>> You're likely going to need a customized U-Boot and/or kernel to get the
>> pin-mux set up properly and to make use of the McBSP for something other
>> than sound/audio.
>>
>> I'd recommend a Yocto build.  The learning curve can be high, but in the
>> end, keeping up to date with the latest features is easier.
>>
>> http://gumstix.org/software-development/yocto-project.html
>> https://github.com/gumstix/Gumstix-YoctoProject-Repo
> Keep in mind http://gumstix.8.x6.nabble.com/McBSP-Driver-td4967321.html
> which ultimately leads to
> http://comments.gmane.org/gmane.linux.ports.arm.omap/91842 which
> explains that much of the McBSP support for anything other than audio
> was removed starting with Linux 3.3.  You'd need to review that to
> determine whether you need to use Linux 3.2, or would need to make
> significant customizations to the kernel.  I believe 3.2 is still
> technically an option in dylan (Yocto 1.4), but expect it to be dropped
> from Yocto 1.5 coming out in October.
>
> Peter
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Scott Ellis]

> I believe 3.2 is still technically an option in dylan (Yocto 1.4), but expect it to be dropped
> from Yocto 1.5 coming out in October.

Where are you getting that information from?

I know for sure that 3.2 kernels are supported by Yocto 1.4, it's what I use.

How would Yocto restrict the kernel recipe used anyway?

Are they changing the kernel bb classes?

[Scott Ellis]

u-boot recipe bbappend and mux patch for McBSP3 use off the expansion board.

Only CLKX, FSX and DR are muxed. I'm not using the DX line for this project.

scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat u-boot_2013.07.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

PRINC := "${@int(PRINC) + 1}"

SRC_URI += " \
    file://mcbsp3-mux.patch \
    file://minimal-boot-args.patch \
 "

scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat u-boot-2013.07/mcbsp3-mux.patch
diff --git git/board/overo/overo.h-orig git/board/overo/overo.h
index b984a54..eaa3069 100644
--- git/board/overo/overo.h-orig
+++ git/board/overo/overo.h
@@ -224,9 +224,9 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\
  MUX_VAL(CP(MCBSP3_FSX), (IEN  | PTD | DIS | M1)) /*UART2_RX*/\
  MUX_VAL(CP(UART2_CTS), (IEN  | PTD | DIS | M4)) /*GPIO_144 - LCD_EN*/\
- MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M4)) /*GPIO_145*/\
- MUX_VAL(CP(UART2_TX), (IEN  | PTD | DIS | M4)) /*GPIO_146*/\
- MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M4)) /*GPIO_147*/\
+ MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M1)) /*MCBSP3_DR*/\
+ MUX_VAL(CP(UART2_TX), (IEN  | PTD | DIS | M1)) /*MCBSP3_CLKX*/\
+ MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M1)) /*MCBSP3_FSX*/\
  MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/\
  MUX_VAL(CP(UART1_RTS), (IEN  | PTU | DIS | M4)) /*GPIO_149*/ \
  MUX_VAL(CP(UART1_CTS), (IEN  | PTU | DIS | M4)) /*GPIO_150-MMC3_WP*/\

[Peter A. Bigot]

On 08/22/2013 01:26 PM, Scott Ellis wrote:

>> I believe 3.2 is still technically an option in dylan (Yocto 1.4), but
> expect it to be dropped
>> from Yocto 1.5 coming out in October.
> Where are you getting that information from?
>
> I know for sure that 3.2 kernels are supported by Yocto 1.4, it's what I
> use.
>
> How would Yocto restrict the kernel recipe used anyway?
>
> Are they changing the kernel bb classes?

I was speaking of Yocto specifically with reference to linux-yocto, the
kernel recipes that are used by the Yocto developers and supposedly
supported and tested within each release across multiple platforms.  
The linux-yocto_3.2 recipe has been removed from oe-core master, so it
won't be tested in 1.5.

Of course, one can always make it work in an external layer with a
forked recipe like linux-gumstix, but it'll get harder and harder as the
overall infrastructure keeps up with current package releases which will
expect features from newer kernels.  Device trees are becoming standard
(see, for example, BeagleBone Black), and I expect that to have a
significant effect on the infrastructure including kernel bb classes.

For Dylan the preferred kernel was 3.8; from what I've seen I expect
3.10 to be the standard in Yocto 1.5, though I haven't personally built
with the current Yocto master branch yet.  Much of what I'm doing now is
trying to get some baseline validation of Gumstix capabilities with the
3.5 kernel used in meta-gumstix so I can move ASAP to 3.10 and be
prepared for the new Yocto release in September/October.  I'm doing that
using the linux-yocto recipe framework instead of the linux-gumstix one,
because the former is much more suited to customization and
documentation of kernel options across similar (and dissimilar) machines.

Peter

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[thfr]

Thank you all for providing so much information.

On 22.08.2013 23:29, Adam Reynolds wrote:
> The OMAP chips on OVERO have 5 McBSPs, but only two of them are
> available on the 70-pins (3 and 5), both of which are 4 pin McBSPs (DR,
> DX, and a common CLK and FS).  It sounds like you might need a 6-pin
> McBSP, unless you can configure the CMX981 to synchronize the input and
> output clock and FS?  Something to look into.  See more in the above
> linked TRM, chapter 21.
>
> -Adam

For transmitting and receiving, I have to use the clock supplied by the CMX981 and feed it to the input clock for all McBSPs (mcbsp_clks). Since there is no receiving frame sync signal (from the overo perspective) on McBSP{2,3,4,5}, do you think I could use another (non-mcbsp) signal for this purpose? I have to detect the falling edge of the frame sync to know when the word began on the receiving data stream. Additionally, I probably have to adhere to the distance between receiving and transmitting data words of 10 to 12 clock cycles. It seems like there is no setting for the CMX981 changing that.

Best Regards,
Thomas


------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[the suicidal eggroll]

Does the CMX981 pulse its output CLK and FS during the receive cycle, or does it only pulse them during transmit and then silently wait for a reply?  From your message it sounds like it's always running the clock, but only pulses the FS on transmit and it's up to the Overo to pulse its own FS when it replies.

You might be able to use a GPIO to act as an FS, however I don't know if you'd be able to do it within that 10-12 clock cycle window.  What speed is the CMX981's clock running?

This page has some info about controlling a GPIO from the kernel:
http://jumpnowtek.com/index.php?option=com_content&view=article&id=54&Itemid=60

-Adam

On 8/23/2013 4:15 AM, Thomas Frank wrote:

Thank you all for providing so much information.

On 22.08.2013 23:29, Adam Reynolds wrote:
> The OMAP chips on OVERO have 5 McBSPs, but only two of them are
> available on the 70-pins (3 and 5), both of which are 4 pin McBSPs (DR,
> DX, and a common CLK and FS).  It sounds like you might need a 6-pin
> McBSP, unless you can configure the CMX981 to synchronize the input and
> output clock and FS?  Something to look into.  See more in the above
> linked TRM, chapter 21.
>
> -Adam

For transmitting and receiving, I have to use the clock supplied by the CMX981 and feed it to the input clock for all McBSPs (mcbsp_clks). Since there is no receiving frame sync signal (from the overo perspective) on McBSP{2,3,4,5}, do you think I could use another (non-mcbsp) signal for this purpose? I have to detect the falling edge of the frame sync to know when the word began on the receiving data stream. Additionally, I probably have to adhere to the distance between receiving and transmitting data words of 10 to 12 clock cycles. It seems like there is no setting for the CMX981 changing that.

Best Regards,
Thomas

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[thfr]

On 23.08.2013 22:13, Adam Reynolds wrote:

Does the CMX981 pulse its output CLK and FS during the receive cycle, or does it only pulse them during transmit and then silently wait for a reply?  From your message it sounds like it's always running the clock, but only pulses the FS on transmit and it's up to the Overo to pulse its own FS when it replies.

You might be able to use a GPIO to act as an FS, however I don't know if you'd be able to do it within that 10-12 clock cycle window.  What speed is the CMX981's clock running?

This page has some info about controlling a GPIO from the kernel:
http://jumpnowtek.com/index.php?option=com_content&view=article&id=54&Itemid=60

-Adam

Thanks for the link Adam. The serial clock (SCLK) of the CMX981 is always running and can be set to 2.2815, 4.563 or 9.126 MHz. And you are completely right, the CMX981 only sends data and the according framesync. The Overo has to generate a the active-high FS (1 SCLK cycle) and then send the data.

Best regards,
Thomas

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[thfr]

Hello,

I didn't get the openembedded environement to compile so I tried yocto and succeed in building the gumstix-console-image with default configuration (linux kernel 3.5). I tried to change the linux-kernel by in including PREFERRED_VERSION_linux-gumstix = "3.2" in the conf/local.conf in the build directory, because there is a linux-gumstix_3.2 recipe in meta-gumstix. Unfortunately, the recipe is restricted to the MACHINE="pepper" and will not be build for the overo. How do I get the overo recipe ?

Best regards,
Thomas

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Scott Ellis]

You can go into the linux-gumstix_3.2.bb recipe and modify the compatible machine line

COMPATIBLE_MACHINE = "pepper|overo"

Or add your own customization layer and add it in a kernel bbappend recipe

COMPATIBLE_MACHINE .= "|overo"
or
COMPATIBLE_MACHINE_overo = "overo"

[thfr]

On 27.08.2013 17:58, Scott Ellis wrote:

> You can go into the linux-gumstix_3.2.bb recipe and modify the compatible
> machine line
>
> COMPATIBLE_MACHINE = "pepper|overo"
>
> Or add your own customization layer and add it in a kernel bbappend recipe
>
> COMPATIBLE_MACHINE .= "|overo"
> or
> COMPATIBLE_MACHINE_overo = "overo"
>

The pepper recipe pulls from the am335x-32 branch and not from the
omap-3.2 branch and what about the defconfig?

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[thfr]

By accident, I read the Introduction to Cross Compilation again and took Sakoman's kernel configuration from there. The kernel from the omap-3.2 branch compiled :)

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Scott Ellis]

Right. Sorry about that.

I also override the SRC_URI in my bbapend.

The layer I'm using is here.

https://github.com/Pansenti/meta-pansenti/tree/master/recipes-kernel/linux

Gumstix kernels are pulled from the gumstix repo.

[thfr]

On 23.08.2013 01:33, Scott Ellis wrote:
> u-boot recipe bbappend and mux patch for McBSP3 use off the expansion board.
>
> Only CLKX, FSX and DR are muxed. I'm not using the DX line for this project.
>
> scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat
> u-boot_2013.07.bbappend
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> PRINC := "${@int(PRINC) + 1}"
>
> SRC_URI += " \
>      file://mcbsp3-mux.patch \
>      file://minimal-boot-args.patch \
>   "
>
> scott@hex:~/fit-overo/meta-fit-overo/recipes-bsp/u-boot$ cat
> u-boot-2013.07/mcbsp3-mux.patch
> diff --git git/board/overo/overo.h-orig git/board/overo/overo.h
> index b984a54..eaa3069 100644
> --- git/board/overo/overo.h-orig
> +++ git/board/overo/overo.h
> @@ -224,9 +224,9 @@ const omap3_sysinfo sysinfo = {
>   MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\
>   MUX_VAL(CP(MCBSP3_FSX), (IEN  | PTD | DIS | M1)) /*UART2_RX*/\
>   MUX_VAL(CP(UART2_CTS), (IEN  | PTD | DIS | M4)) /*GPIO_144 - LCD_EN*/\
> - MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M4)) /*GPIO_145*/\
> - MUX_VAL(CP(UART2_TX), (IEN  | PTD | DIS | M4)) /*GPIO_146*/\
> - MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M4)) /*GPIO_147*/\
> + MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M1)) /*MCBSP3_DR*/\
> + MUX_VAL(CP(UART2_TX), (IEN  | PTD | DIS | M1)) /*MCBSP3_CLKX*/\
> + MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M1)) /*MCBSP3_FSX*/\
>   MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/\
>   MUX_VAL(CP(UART1_RTS), (IEN  | PTU | DIS | M4)) /*GPIO_149*/ \
>   MUX_VAL(CP(UART1_CTS), (IEN  | PTU | DIS | M4)) /*GPIO_150-MMC3_WP*/\

Why did you set every pin as IEN (input enable). My first guess would
be to disable input if the pin is only an output pin.

gumstix-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Scott Ellis]

The clocks for McBSP (and SPI) need to be inputs.

Here's a working system with an McBSP3 driver (I just happened to be working on one)

=== MCBSP3_CLKX mux

root@overo:~# devmem2 0x48002178 h
/dev/mem opened.
Memory mapped at address 0x4015c000.
Read at address  0x48002178 (0x4015c178): 0x0101

=== MCBSP3_FSX mux

root@overo:~# devmem2 0x4800217a h
/dev/mem opened.
Memory mapped at address 0x40157000.
Read at address  0x4800217A (0x4015717a): 0x0101

=== The driver

root@overo:~# lsmod
Module                  Size  Used by
ads1278                 8677  0

=== A userland test program

root@overo:~# ./adswatch

===== Driver config =====
  block_size:       8192
  state:            MCBSP_REQUESTED | MCBSP_CONFIG_SET
  mode:             HIGH SPEED
  mcbsp_clkdiv      16
  trigger_duration: 10 us
  flash_delay:      1000 us
  flash_duration:   5000 us
  cycle_duration:   100 ms
=========================


(use ctrl-c to stop)

Total: 157   Blocks: 9  Elapsed: 101  Samples/sec: 22811       ^C

(GETTING DATA)

=== Remux MCBSP3_CLKX as an output

root@overo:~# devmem2 0x48002178 h 0x0001
/dev/mem opened.
Memory mapped at address 0x400b9000.
Read at address  0x48002178 (0x400b9178): 0x0101
Write at address 0x48002178 (0x400b9178): 0x0001, readback 0x0001

=== Test the driver

root@overo:~# ./adswatch

===== Driver config =====
  block_size:       8192
  state:            MCBSP_REQUESTED
  mode:             HIGH SPEED
  mcbsp_clkdiv      16
  trigger_duration: 10 us
  flash_delay:      1000 us
  flash_duration:   5000 us
  cycle_duration:   100 ms
=========================


(use ctrl-c to stop)

(NO DATA)

=== Put the mux for CLKX back to input

root@overo:~# devmem2 0x48002178 h 0x0101
/dev/mem opened.
Memory mapped at address 0x40162000.
Read at address  0x48002178 (0x40162178): 0x0001
Write at address 0x48002178 (0x40162178): 0x0101, readback 0x0101

=== Test the driver

root@overo:~# ./adswatch

===== Driver config =====
  block_size:       8192
  state:            MCBSP_REQUESTED | MCBSP_CONFIG_SET
  mode:             HIGH SPEED
  mcbsp_clkdiv      16
  trigger_duration: 10 us
  flash_delay:      1000 us
  flash_duration:   5000 us
  cycle_duration:   100 ms
=========================


(use ctrl-c to stop)

Total: 111   Blocks: 10  Elapsed: 101  Samples/sec: 25346       ^C

(GETTING DATA)

=== Remux MCBSP3_FSX as an output

root@overo:~# devmem2 0x4800217a h 0x0001
/dev/mem opened.
Memory mapped at address 0x400a4000.
Read at address  0x4800217A (0x400a417a): 0x0101
Write at address 0x4800217A (0x400a417a): 0x0001, readback 0x0001

=== Test the driver

root@overo:~# ./adswatch

===== Driver config =====
  block_size:       8192
  state:            MCBSP_REQUESTED | MCBSP_CONFIG_SET
  mode:             HIGH SPEED
  mcbsp_clkdiv      16
  trigger_duration: 10 us
  flash_delay:      1000 us
  flash_duration:   5000 us
  cycle_duration:   100 ms
=========================


(use ctrl-c to stop)

(NO DATA)


=== Put the FSX mux back to inpu

root@overo:~# devmem2 0x4800217a h 0x0101
/dev/mem opened.
Memory mapped at address 0x4005e000.
Read at address  0x4800217A (0x4005e17a): 0x0001
Write at address 0x4800217A (0x4005e17a): 0x0101, readback 0x0101

=== Test the driver

root@overo:~# ./adswatch

===== Driver config =====
  block_size:       8192
  state:            MCBSP_REQUESTED | MCBSP_CONFIG_SET
  mode:             HIGH SPEED
  mcbsp_clkdiv      16
  trigger_duration: 10 us
  flash_delay:      1000 us
  flash_duration:   5000 us
  cycle_duration:   100 ms
=========================


(use ctrl-c to stop)

Total: 407   Blocks: 10  Elapsed: 101  Samples/sec: 25346       ^C

(GETTING DATA)

[thfr]

That seems greats, I did not know that those connections are so flexible. Does it mean that every signal ending with an "X" like FSX can be used bidirectional? For my problem, I am thinking about following connection scheme:
  

Is that possible?
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Scott Ellis]

The docs say the CLKX and FSX can be used in either direction, but I've
never tried it. My guess is it will work.

In all my drivers so far, the McBSP has been the source for both the
clock and frame sync lines.

[the suicidal eggroll]

I'm running the McBSPs on my system in slave mode.  CLK and FS are generated by the external device, the only output from the Overo is DX.