Quantcast

Tobi Expansion Board UART pins?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tobi Expansion Board UART pins?

Donny3000
I know this issue has been brought up before, but all of my search brought up topics with old dates (2009 and earlier).  I know changes have been made to the design of the expansion boards since 2009, so I thought I would raise the question again to get answers pertaining to the latest revisions of the H/W.  So my questions are:

1.) Which UARTs are pulled out to the 40-pin header and aren't configured for any other H/W?
2.) Which /dev entries do those UARTs map to in the rootfs?
3.) If the UARTs are being for other H/W, what are the correct changes that need to be made to free up a UART?

If these questions have been addressed recently (answers/instructions from 2011 - present) to match the latest generation of the Gumstix Hardware, I apologize for posting a duplicate topic.  But, I have been having a heck of a time trying to find up-to-date information on how to use interface with the UARTs on the expansion boards (Tobi in my case).  If anyone can provide assistance or direct me to some working answers it would be greatly appreciated.  Thanks in advance.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Kartik Mohta
On Mon, Apr 30, 2012 at 2:06 AM, Donny3000 <[hidden email]> wrote:
> I know this issue has been brought up before, but all of my search brought up
> topics with old dates (2009 and earlier).  I know changes have been made to
> the design of the expansion boards since 2009, so I thought I would raise
> the question again to get answers pertaining to the latest revisions of the
> H/W.  So my questions are:
>
> 1.) Which UARTs are pulled out to the 40-pin header and aren't configured
> for any other H/W?

Looking at http://www.gumstix.org/hardware-design/overo-coms/74-overo-connectors/97-gumstix-overo-series-40-pin-header.html,
UART1 and UART3 are available on the 40 pin header. By default UART2
is used for the bluetooth module and UART3 is used for the console
port so the only available one is UART1.

> 2.) Which //dev/ entries do those UARTs map to in the rootfs?
On kernels 2.6.37+:
UART1: /dev/ttyO0
UART2: /dev/ttyO1
UART3: /dev/ttyO2

On older kernels, just change ttyOx to ttySx.

> 3.) If the UARTs are being for other H/W, what are the correct changes that
> need to be made to free up a UART?

If your application does not require bluetooth you can route UART2
TX/RX to the header pins labelled GPIO146 and GPIO147. One way to do
this is to change the u-boot board config, see
http://gumstix.8.n6.nabble.com/Using-UART-2-on-an-Overo-td660403.html
for details. I guess you can also disable the console output and use
UART3 but it would make it very inconvenient to debug any problems.

--
Kartik

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Donny3000
Thanks Kartik for your response.  I read the link regarding the 40-pin header and saw where the the UART1 TX/RX pins are located (pins 9 and 10).  But, how do I know that the ttyO0 is working correctly and sending/receiving data?  I hooked up an Oscilloscope to pin 10 (TX) of the 40-ping header to see if the pin was toggling (wrote a python script to write an ASCII 'U' to the /dev/ttyO0 every 100ms), but I didn't see anything.  I haven't make any changes to either u-boot or the kernel, but I shouldn't have to if UART1 is already pulled out to the header right?  What other things can I check to make sure UART1 is actually working and configured appropriately?  To give some context, I'm using the omap3-console-image of the overo-2011.03 branch.

-Donald

kartikmohta wrote
On Mon, Apr 30, 2012 at 2:06 AM, Donny3000 <[hidden email]> wrote:
> I know this issue has been brought up before, but all of my search brought up
> topics with old dates (2009 and earlier).  I know changes have been made to
> the design of the expansion boards since 2009, so I thought I would raise
> the question again to get answers pertaining to the latest revisions of the
> H/W.  So my questions are:
>
> 1.) Which UARTs are pulled out to the 40-pin header and aren't configured
> for any other H/W?

Looking at http://www.gumstix.org/hardware-design/overo-coms/74-overo-connectors/97-gumstix-overo-series-40-pin-header.html,
UART1 and UART3 are available on the 40 pin header. By default UART2
is used for the bluetooth module and UART3 is used for the console
port so the only available one is UART1.

> 2.) Which //dev/ entries do those UARTs map to in the rootfs?
On kernels 2.6.37+:
UART1: /dev/ttyO0
UART2: /dev/ttyO1
UART3: /dev/ttyO2

On older kernels, just change ttyOx to ttySx.

> 3.) If the UARTs are being for other H/W, what are the correct changes that
> need to be made to free up a UART?

If your application does not require bluetooth you can route UART2
TX/RX to the header pins labelled GPIO146 and GPIO147. One way to do
this is to change the u-boot board config, see
http://gumstix.8.n6.nabble.com/Using-UART-2-on-an-Overo-td660403.html
for details. I guess you can also disable the console output and use
UART3 but it would make it very inconvenient to debug any problems.

--
Kartik

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Kartik Mohta
Do note that the voltage level on the Overo I/O pins in 1.8V.
I don't have an oscilloscope on hand, but checking the average voltage
on pin 10 using a multimeter, I see it change (drop) in the voltage
when I start sending on /dev/ttyO0. Does it show a constant 1.8V on
yours? And just to clarify, what kernel version are you running
(output of uname -a)?

On Tue, May 1, 2012 at 12:53 PM, Donny3000 <[hidden email]> wrote:

> Thanks Kartik for your response.  I read the link regarding the 40-pin header
> and saw where the the UART1 TX/RX pins are located (pins 9 and 10).  But,
> how do I know that the ttyO0 is working correctly and sending/receiving
> data?  I hooked up an Oscilloscope to pin 10 (TX) of the 40-ping header to
> see if the pin was toggling (wrote a python script to write an ASCII 'U' to
> the /dev/ttyO0 every 100ms), but I didn't see anything.  I haven't make any
> changes to either u-boot or the kernel, but I shouldn't have to if UART1 is
> already pulled out to the header right?  What other things can I check to
> make sure UART1 is actually working and configured appropriately?  To give
> some context, I'm using the omap3-console-image of the overo-2011.03 branch.
>
> -Donald
>
>
> kartikmohta wrote
>>
>> On Mon, Apr 30, 2012 at 2:06 AM, Donny3000 &lt;donald.poole@&gt; wrote:
>>> I know this issue has been brought up before, but all of my search
>>> brought up
>>> topics with old dates (2009 and earlier).  I know changes have been made
>>> to
>>> the design of the expansion boards since 2009, so I thought I would raise
>>> the question again to get answers pertaining to the latest revisions of
>>> the
>>> H/W.  So my questions are:
>>>
>>> 1.) Which UARTs are pulled out to the 40-pin header and aren't configured
>>> for any other H/W?
>>
>> Looking at
>> http://www.gumstix.org/hardware-design/overo-coms/74-overo-connectors/97-gumstix-overo-series-40-pin-header.html,
>> UART1 and UART3 are available on the 40 pin header. By default UART2
>> is used for the bluetooth module and UART3 is used for the console
>> port so the only available one is UART1.
>>
>>> 2.) Which //dev/ entries do those UARTs map to in the rootfs?
>> On kernels 2.6.37+:
>> UART1: /dev/ttyO0
>> UART2: /dev/ttyO1
>> UART3: /dev/ttyO2
>>
>> On older kernels, just change ttyOx to ttySx.
>>
>>> 3.) If the UARTs are being for other H/W, what are the correct changes
>>> that
>>> need to be made to free up a UART?
>>
>> If your application does not require bluetooth you can route UART2
>> TX/RX to the header pins labelled GPIO146 and GPIO147. One way to do
>> this is to change the u-boot board config, see
>> http://gumstix.8.n6.nabble.com/Using-UART-2-on-an-Overo-td660403.html
>> for details. I guess you can also disable the console output and use
>> UART3 but it would make it very inconvenient to debug any problems.
>>
>> --
>> Kartik
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@.sourceforge
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
>
> --
> View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p4944030.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users



--
Kartik

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Akram Hameed
Been a long time since I went down this road, but unless you have a busted
TOBI, your UART should be where you describe.

One thing to note: the pins may be muxed as GPIO by default in your u-boot.
It was my suspicion that the default u-boot configuration gave you GPIO
(mode 4) rather than uart, but I may just be misremembering from an ancient
build.  Can check your sysfs to see if gpios 148 & 151 are present
(/sys/class/gpio), if they are, then you will need to patch mux.h in u-boot.

I can check the source if necessary, but then again, you are probably just
as capable of this yourself ;-)

-----Original Message-----
From: Kartik Mohta [mailto:[hidden email]]
Sent: Wednesday, 2 May 2012 6:37 AM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] Tobi Expansion Board UART pins?

Do note that the voltage level on the Overo I/O pins in 1.8V.
I don't have an oscilloscope on hand, but checking the average voltage on
pin 10 using a multimeter, I see it change (drop) in the voltage when I
start sending on /dev/ttyO0. Does it show a constant 1.8V on yours? And just
to clarify, what kernel version are you running (output of uname -a)?

On Tue, May 1, 2012 at 12:53 PM, Donny3000 <[hidden email]> wrote:

> Thanks Kartik for your response.  I read the link regarding the 40-pin
> header and saw where the the UART1 TX/RX pins are located (pins 9 and
> 10).  But, how do I know that the ttyO0 is working correctly and
> sending/receiving data?  I hooked up an Oscilloscope to pin 10 (TX) of
> the 40-ping header to see if the pin was toggling (wrote a python
> script to write an ASCII 'U' to the /dev/ttyO0 every 100ms), but I
> didn't see anything.  I haven't make any changes to either u-boot or
> the kernel, but I shouldn't have to if UART1 is already pulled out to
> the header right?  What other things can I check to make sure UART1 is
> actually working and configured appropriately?  To give some context, I'm
> using the omap3-console-image of the overo-2011.03 branch.
>
> -Donald
>
>
> kartikmohta wrote
>>
>> On Mon, Apr 30, 2012 at 2:06 AM, Donny3000 &lt;donald.poole@&gt; wrote:
>>> I know this issue has been brought up before, but all of my search
>>> brought up topics with old dates (2009 and earlier).  I know changes
>>> have been made to the design of the expansion boards since 2009, so
>>> I thought I would raise the question again to get answers pertaining
>>> to the latest revisions of the H/W.  So my questions are:
>>>
>>> 1.) Which UARTs are pulled out to the 40-pin header and aren't
>>> configured for any other H/W?
>>
>> Looking at
>> http://www.gumstix.org/hardware-design/overo-coms/74-overo-connectors
>> /97-gumstix-overo-series-40-pin-header.html,
>> UART1 and UART3 are available on the 40 pin header. By default UART2
>> is used for the bluetooth module and UART3 is used for the console
>> port so the only available one is UART1.
>>
>>> 2.) Which //dev/ entries do those UARTs map to in the rootfs?
>> On kernels 2.6.37+:
>> UART1: /dev/ttyO0
>> UART2: /dev/ttyO1
>> UART3: /dev/ttyO2
>>
>> On older kernels, just change ttyOx to ttySx.
>>
>>> 3.) If the UARTs are being for other H/W, what are the correct
>>> changes that need to be made to free up a UART?
>>
>> If your application does not require bluetooth you can route UART2
>> TX/RX to the header pins labelled GPIO146 and GPIO147. One way to do
>> this is to change the u-boot board config, see
>> http://gumstix.8.n6.nabble.com/Using-UART-2-on-an-Overo-td660403.html
>> for details. I guess you can also disable the console output and use
>> UART3 but it would make it very inconvenient to debug any problems.
>>
>> --
>> Kartik
>>
>> ---------------------------------------------------------------------
>> ---------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@.sourceforge
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
>
> --
> View this message in context:
> http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp494008
> 4p4944030.html Sent from the Gumstix mailing list archive at
> Nabble.com.
>
> ----------------------------------------------------------------------
> --------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users



--
Kartik

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Donny3000
In reply to this post by Kartik Mohta
Yes, when I measure the voltage of pin 10 with a DMM, it shows a constant 1.8V.  When I execute uname -a, this is what I get: Linux overo 3.2.0 #1 PREEMPT Tue May 1 10:33:23 CDT 2012 armv7l GNU/Linux.  So, I'm running the 3.2.0 kernel.  Not sure what I'm doing wrong.  BTW, this is the python script I'm running to toggle the pin:

from time import sleep
import sys

if __name__ == "__main__":
    fd = open(sys.argv[1], "w")
    print "Writing data to %s" % sys.argv[1]
    try:
        while 1:
            fd.write("U")
            sleep(1)
    except KeyboardInterrupt:
        fd.close()
        print "Closing serial port %s" % sys.argv[1]


My assumption is that this should work to toggle the pin so I could see something with a DMM or Oscilloscope, but I could be wrong.

kartikmohta wrote
Do note that the voltage level on the Overo I/O pins in 1.8V.
I don't have an oscilloscope on hand, but checking the average voltage
on pin 10 using a multimeter, I see it change (drop) in the voltage
when I start sending on /dev/ttyO0. Does it show a constant 1.8V on
yours? And just to clarify, what kernel version are you running
(output of uname -a)?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Donny3000
In reply to this post by Akram Hameed
I'm not sure if you meant the overo.h file or the mux.h file, but I'll post what I believe is the relevant content of both.  Looking through the u-boot source tree at the file board/overo/overo.h, it looks like pins 148 & 151, UART1 TX/RX pins are configured as UART.  This is what I'm looking at around line 215 of the overo.h file:

/*Bluetooth*/\
        MUX_VAL(CP(MCBSP3_DX), (IEN  | PTD | DIS | M1)) /*UART2_CTS*/\
        MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M1)) /*UART2_RTS*/\
        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(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*/\
        MUX_VAL(CP(UART1_RX), (IEN  | PTD | DIS | M0)) /*UART1_RX*/\
        MUX_VAL(CP(MCBSP4_CLKX), (IEN  | PTD | DIS | M0)) /*McBSP4_CLKX*/\
        MUX_VAL(CP(MCBSP4_DR), (IEN  | PTD | DIS | M0)) /*McBSP4_DR*/\
        MUX_VAL(CP(MCBSP4_DX), (IEN  | PTD | DIS | M0)) /*McBSP4_DX*/\
        MUX_VAL(CP(MCBSP4_FSX), (IEN  | PTD | DIS | M0)) /*McBSP4_FSX*/\
        MUX_VAL(CP(MCBSP1_CLKR), (IEN  | PTD | DIS | M0)) /*McBSP1_CLKR*/\
        MUX_VAL(CP(MCBSP1_FSR), (IEN  | PTD | DIS | M0)) /*McBSP1_FSR*/\
        MUX_VAL(CP(MCBSP1_DX), (IEN  | PTD | DIS | M0)) /*McBSP1_DX*/\
        MUX_VAL(CP(MCBSP1_DR), (IEN  | PTD | DIS | M0)) /*McBSP1_DR*/\
        MUX_VAL(CP(MCBSP_CLKS), (IEN  | PTU | DIS | M0)) /*McBSP_CLKS*/\
        MUX_VAL(CP(MCBSP1_FSX), (IEN  | PTD | DIS | M0)) /*McBSP1_FSX*/\
        MUX_VAL(CP(MCBSP1_CLKX), (IEN  | PTD | DIS | M0)) /*McBSP1_CLKX*/\


I could be looking at the wrong section of the file or misinterpreting the MUX_VAL macro, but it looks like UART1 is configured as a UART.  This is all under the assumption that UART1 is the free UART (/dev/ttyO0) pulled out to the 40-pin header, which I believe it is as Kartik mentioned earlier in the topic.  Within the arch/arm/include/asm/arch-omap3/mux.h file I found thses addresses defined for UART1 around line 230:

/*Modem Interface */
#define CONTROL_PADCONF_UART1_TX 0x017C
#define CONTROL_PADCONF_UART1_RTS 0x017E
#define CONTROL_PADCONF_UART1_CTS 0x0180
#define CONTROL_PADCONF_UART1_RX 0x0182


According to the AM/DM37x Technical Reference Manual, this seems to be correct.  When I show a directory listing of the /sys/class/gpio folder, this is what I have:

root@overo:~# ls /sys/class/gpio/
export   gpio15   gpio168      gpiochip160  gpiochip64
gpio144  gpio16   gpiochip0    gpiochip192  gpiochip96
gpio145  gpio164  gpiochip128  gpiochip32   unexport


So, it appears that I don't have the GPIOs 148 & 151 present, which would suggest that they aren't configured as GPIOs, correct?  If so, the section of overo.h that I posted above seems to contradict the output of /sys/class/gpio.

It looks like we are getting closer to determining the issue, but I'm not sure where to look next.

Akram Hameed wrote
Been a long time since I went down this road, but unless you have a busted
TOBI, your UART should be where you describe.

One thing to note: the pins may be muxed as GPIO by default in your u-boot.
It was my suspicion that the default u-boot configuration gave you GPIO
(mode 4) rather than uart, but I may just be misremembering from an ancient
build.  Can check your sysfs to see if gpios 148 & 151 are present
(/sys/class/gpio), if they are, then you will need to patch mux.h in u-boot.

I can check the source if necessary, but then again, you are probably just
as capable of this yourself ;-)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Kartik Mohta
On Wed, May 2, 2012 at 3:10 AM, Donny3000 <[hidden email]> wrote:
>        /*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*/\
>        /*MUX_VAL(CP(UART1_RX),         (IEN  | PTD | DIS | M0)) /*UART1_RX*/\*/

Were the lines for UART1 TX and RX commented out in the original file?
If yes, which version of u-boot are you using?

--
Kartik

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Donny3000
kartikmohta wrote
On Wed, May 2, 2012 at 3:10 AM, Donny3000 <[hidden email]> wrote:
>        /*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*/\
>        /*MUX_VAL(CP(UART1_RX),         (IEN  | PTD | DIS | M0)) /*UART1_RX*/\*/

Were the lines for UART1 TX and RX commented out in the original file?
If yes, which version of u-boot are you using?

--
Kartik
No, they were not commented out in the original file.  But, I did a fresh build of everything to go back to square one and now it's working as it should.  I put an o-scope back on the pin I now I see it toggling as I would expect.  Thanks to everyone for there assitance!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Akram Hameed
In reply to this post by Donny3000
Sorry 'bout that Donny, was working off memory, overo.h was the file I
intended for you to look at.

-----Original Message-----
From: Donny3000 [mailto:[hidden email]]
Sent: Wednesday, 2 May 2012 5:11 PM
To: [hidden email]
Subject: Re: [Gumstix-users] Tobi Expansion Board UART pins?

I'm not sure if you meant the overo.h file or the mux.h file, but I'll
post what I believe is the relevant content of both.  Looking through the
u-boot source tree at the file /board/overo/overo.h/, it looks like pins
148 & 151,
UART1 TX/RX pins are configured as UART.  This is what I'm looking at
around line 215 of the overo.h file:

//*Bluetooth*/\
        MUX_VAL(CP(MCBSP3_DX), (IEN  | PTD | DIS | M1))
/*UART2_CTS*/\
        MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M1))
/*UART2_RTS*/\
        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(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*/\
        /*MUX_VAL(CP(UART1_RX), (IEN  | PTD | DIS | M0))
/*UART1_RX*/\*/
        MUX_VAL(CP(MCBSP4_CLKX), (IEN  | PTD | DIS | M0))
/*McBSP4_CLKX*/\
        MUX_VAL(CP(MCBSP4_DR), (IEN  | PTD | DIS | M0))
/*McBSP4_DR*/\
        MUX_VAL(CP(MCBSP4_DX), (IEN  | PTD | DIS | M0))
/*McBSP4_DX*/\
        MUX_VAL(CP(MCBSP4_FSX), (IEN  | PTD | DIS | M0))
/*McBSP4_FSX*/\
        MUX_VAL(CP(MCBSP1_CLKR), (IEN  | PTD | DIS | M0))
/*McBSP1_CLKR*/\
        MUX_VAL(CP(MCBSP1_FSR), (IEN  | PTD | DIS | M0))
/*McBSP1_FSR*/\
        MUX_VAL(CP(MCBSP1_DX), (IEN  | PTD | DIS | M0))
/*McBSP1_DX*/\
        MUX_VAL(CP(MCBSP1_DR), (IEN  | PTD | DIS | M0))
/*McBSP1_DR*/\
        MUX_VAL(CP(MCBSP_CLKS), (IEN  | PTU | DIS | M0))
/*McBSP_CLKS*/\
        MUX_VAL(CP(MCBSP1_FSX), (IEN  | PTD | DIS | M0))
/*McBSP1_FSX*/\
        MUX_VAL(CP(MCBSP1_CLKX), (IEN  | PTD | DIS | M0))
/*McBSP1_CLKX*/\/

I could be looking at the wrong section of the file or misinterpreting the
/MUX_VAL/ macro, but it looks like UART1 is configured as a UART.  This is
all under the assumption that UART1 is the free UART (/dev/ttyO0) pulled
out to the 40-pin header, which I believe it is as Kartik mentioned
earlier in the topic.  Within the /arch/arm/include/asm/arch-omap3/mux.h/
file I found thses addresses defined for UART1 around line 230:

//*Modem Interface */
#define CONTROL_PADCONF_UART1_TX 0x017C
#define CONTROL_PADCONF_UART1_RTS 0x017E
#define CONTROL_PADCONF_UART1_CTS 0x0180
#define CONTROL_PADCONF_UART1_RX 0x0182/

According to the  http://www.ti.com/lit/ug/sprugn4p/sprugn4p.pdf AM/DM37x
Technical Reference Manual , this seems to be correct.  When I show a
directory listing of the //sys/class/gpio/ folder, this is what I have:

/root@overo:~# ls /sys/class/gpio/
export   gpio15   gpio168      gpiochip160  gpiochip64
gpio144  gpio16   gpiochip0    gpiochip192  gpiochip96
gpio145  gpio164  gpiochip128  gpiochip32   unexport/

So, it appears that I don't have the GPIOs 148 & 151 present, which would
suggest that they aren't configured as GPIOs, correct?  If so, the section
of /overo.h/ that I posted above seems to contradict the output of
//sys/class/gpio/.

It looks like we are getting closer to determining the issue, but I'm not
sure where to look next.


Akram Hameed wrote

>
> Been a long time since I went down this road, but unless you have a
> busted TOBI, your UART should be where you describe.
>
> One thing to note: the pins may be muxed as GPIO by default in your
> u-boot.
> It was my suspicion that the default u-boot configuration gave you
> GPIO (mode 4) rather than uart, but I may just be misremembering from
> an ancient build.  Can check your sysfs to see if gpios 148 & 151 are
> present (/sys/class/gpio), if they are, then you will need to patch
> mux.h in u-boot.
>
> I can check the source if necessary, but then again, you are probably
> just as capable of this yourself ;-)
>

--
View this message in context:
http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p49
45464.html
Sent from the Gumstix mailing list archive at Nabble.com.

--------------------------------------------------------------------------
----
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Jonathan Kunkee
In reply to this post by Donny3000

If your kernel has the right options compiled in, /sys/kernel/debug has an omap muxing subtree that can be used to read out and correct incorrect settings in uboot--you just have to figure out the right magic numbers and pin names and then have to wait for the system to boot before your outputs are guaranteed to be valid.

I'll post my Bash code when I get a chance.

Jon

On May 2, 2012 1:13 AM, "Donny3000" <[hidden email]> wrote:
I'm not sure if you meant the overo.h file or the mux.h file, but I'll post
what I believe is the relevant content of both.  Looking through the u-boot
source tree at the file /board/overo/overo.h/, it looks like pins 148 & 151,
UART1 TX/RX pins are configured as UART.  This is what I'm looking at around
line 215 of the overo.h file:

//*Bluetooth*/\
       MUX_VAL(CP(MCBSP3_DX),          (IEN  | PTD | DIS | M1)) /*UART2_CTS*/\
       MUX_VAL(CP(MCBSP3_DR),          (IDIS | PTD | DIS | M1)) /*UART2_RTS*/\
       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(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*/\
       /*MUX_VAL(CP(UART1_RX),         (IEN  | PTD | DIS | M0)) /*UART1_RX*/\*/
       MUX_VAL(CP(MCBSP4_CLKX),        (IEN  | PTD | DIS | M0)) /*McBSP4_CLKX*/\
       MUX_VAL(CP(MCBSP4_DR),          (IEN  | PTD | DIS | M0)) /*McBSP4_DR*/\
       MUX_VAL(CP(MCBSP4_DX),          (IEN  | PTD | DIS | M0)) /*McBSP4_DX*/\
       MUX_VAL(CP(MCBSP4_FSX),         (IEN  | PTD | DIS | M0)) /*McBSP4_FSX*/\
       MUX_VAL(CP(MCBSP1_CLKR),        (IEN  | PTD | DIS | M0)) /*McBSP1_CLKR*/\
       MUX_VAL(CP(MCBSP1_FSR),         (IEN  | PTD | DIS | M0)) /*McBSP1_FSR*/\
       MUX_VAL(CP(MCBSP1_DX),          (IEN  | PTD | DIS | M0)) /*McBSP1_DX*/\
       MUX_VAL(CP(MCBSP1_DR),          (IEN  | PTD | DIS | M0)) /*McBSP1_DR*/\
       MUX_VAL(CP(MCBSP_CLKS),         (IEN  | PTU | DIS | M0)) /*McBSP_CLKS*/\
       MUX_VAL(CP(MCBSP1_FSX),         (IEN  | PTD | DIS | M0)) /*McBSP1_FSX*/\
       MUX_VAL(CP(MCBSP1_CLKX),        (IEN  | PTD | DIS | M0)) /*McBSP1_CLKX*/\/

I could be looking at the wrong section of the file or misinterpreting the
/MUX_VAL/ macro, but it looks like UART1 is configured as a UART.  This is
all under the assumption that UART1 is the free UART (/dev/ttyO0) pulled out
to the 40-pin header, which I believe it is as Kartik mentioned earlier in
the topic.  Within the /arch/arm/include/asm/arch-omap3/mux.h/ file I found
thses addresses defined for UART1 around line 230:

//*Modem Interface */
#define CONTROL_PADCONF_UART1_TX        0x017C
#define CONTROL_PADCONF_UART1_RTS       0x017E
#define CONTROL_PADCONF_UART1_CTS       0x0180
#define CONTROL_PADCONF_UART1_RX        0x0182/

According to the  http://www.ti.com/lit/ug/sprugn4p/sprugn4p.pdf AM/DM37x
Technical Reference Manual , this seems to be correct.  When I show a
directory listing of the //sys/class/gpio/ folder, this is what I have:

/root@overo:~# ls /sys/class/gpio/
export   gpio15   gpio168      gpiochip160  gpiochip64
gpio144  gpio16   gpiochip0    gpiochip192  gpiochip96
gpio145  gpio164  gpiochip128  gpiochip32   unexport/

So, it appears that I don't have the GPIOs 148 & 151 present, which would
suggest that they aren't configured as GPIOs, correct?  If so, the section
of /overo.h/ that I posted above seems to contradict the output of
//sys/class/gpio/.

It looks like we are getting closer to determining the issue, but I'm not
sure where to look next.


Akram Hameed wrote
>
> Been a long time since I went down this road, but unless you have a busted
> TOBI, your UART should be where you describe.
>
> One thing to note: the pins may be muxed as GPIO by default in your
> u-boot.
> It was my suspicion that the default u-boot configuration gave you GPIO
> (mode 4) rather than uart, but I may just be misremembering from an
> ancient
> build.  Can check your sysfs to see if gpios 148 & 151 are present
> (/sys/class/gpio), if they are, then you will need to patch mux.h in
> u-boot.
>
> I can check the source if necessary, but then again, you are probably just
> as capable of this yourself ;-)
>

--
View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p4945464.html
Sent from the Gumstix mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Donny3000
Thanks Jon for that tip and if do get around to posting that bash script, it would be much appreciated.  I will check my system tomorrow to see if I have /sys/kernel/debug available.  If not, do you recall what kernel option(s) I need to set in order to see the omap muxing subtree?

Jonathan Kunkee wrote
If your kernel has the right options compiled in, /sys/kernel/debug has an
omap muxing subtree that can be used to read out and correct incorrect
settings in uboot--you just have to figure out the right magic numbers and
pin names and then have to wait for the system to boot before your outputs
are guaranteed to be valid.

I'll post my Bash code when I get a chance.

Jon
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Jonathan Kunkee

This is a snippet of the script I wrote to remux a specific pin and then expose it to userspace as others have suggested.

enable_gpio()
{
    # making gpio 21 an input muxed as a gpio
        echo 0x0104 > /sys/kernel/debug/omap_mux/etk_ctl
        echo 21 > /sys/class/gpio/export
    # making it an output and assigning it a value
        echo 0x0004 > /sys/kernel/debug/omap_mux/etk_ctl
        echo 21 > /sys/class/gpio/export
        echo 1 > /sys/class/gpio/gpio21/value
}

Note that you can cat any file in that directory and get some useful output. The pin meaning selection is the least significant nibble or two; these files list potential values in numerical order starting with zero on the left. 4 should correspond with gpio21.

> //sys/kernel/debug/ available.  If not, do you recall what kernel option(s)
> I need to set in order to see the omap muxing subtree?

Looking at my config I believe it was CONFIG_OMAP_MUX=y that did it. There are other related options that you might investigate. :) You will then want to mount debugfs somewhere; that's what populates the debug subdirectory for me.

Good luck!
--Jon


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tobi Expansion Board UART pins?

Jonathan Kunkee

Hmm. Looks like etk_ctl is GPIO13. Sorry about that. I'll have to revisit that script.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Loading...