From: Donny3000 <don...@sw...> - 2012-04-30 06:06:14
|
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. -- View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Kartik M. <kar...@gm...> - 2012-04-30 06:59:23
|
On Mon, Apr 30, 2012 at 2:06 AM, Donny3000 <don...@sw...> 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 |
From: Donny3000 <don...@sw...> - 2012-05-01 16:54:01
|
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 <donald.poole@> 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. |
From: Kartik M. <kar...@gm...> - 2012-05-01 20:37:34
|
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 <don...@sw...> 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 <donald.poole@> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Kartik |
From: Donny3000 <don...@sw...> - 2012-05-02 05:44:52
|
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)? > -- View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p4945360.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Akram H. <ak...@aq...> - 2012-05-02 00:17:15
|
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:kar...@gm...] 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 <don...@sw...> 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 <donald.poole@> 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 > gum...@li... > 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 gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Donny3000 <don...@sw...> - 2012-05-02 07:10:56
|
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. |
From: Akram H. <ak...@aq...> - 2012-05-02 23:30:21
|
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:don...@sw...] Sent: Wednesday, 2 May 2012 5:11 PM To: gum...@li... 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 gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Kartik M. <kar...@gm...> - 2012-05-02 18:23:57
|
On Wed, May 2, 2012 at 3:10 AM, Donny3000 <don...@sw...> 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 |
From: Donny3000 <don...@sw...> - 2012-05-02 18:50:41
|
kartikmohta wrote > > On Wed, May 2, 2012 at 3:10 AM, Donny3000 <donald.poole@> 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! -- View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p4947030.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Jonathan K. <jon...@gm...> - 2012-05-03 03:14:59
|
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" <don...@sw...> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Donny3000 <don...@sw...> - 2012-05-03 04:16:05
|
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 -- View this message in context: http://gumstix.8.n6.nabble.com/Tobi-Expansion-Board-UART-pins-tp4940084p4948287.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Jonathan K. <jon...@gm...> - 2012-05-03 05:41:28
|
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 |
From: Jonathan K. <jon...@gm...> - 2012-05-03 05:38:34
|
Hmm. Looks like etk_ctl is GPIO13. Sorry about that. I'll have to revisit that script. |