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" <donald.poole@swri.org> 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
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users