I am trying to enable UART2 available on expansion header. In order to
do so I made the required changes in u-boot-main/board/OMAP3/beagle/
beagle.h file under the section labeled bluetooth. I referred to
previous posts on the forum and OMAP TRM to achieve this.
Next u-boot.bin was build from beagle.h using following instructions
arm-2007q3 toolchain from codesorcery.
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
make CROSS_COMPILE=arm-none-linux-gnueabi-
Now using this u-boot.bin along with kernel version 2.6.28 and
Angstrom filesystem, I was not able to track any activity on UART2
pins (i.e. pin 6--> Tx and pin 8--> Rx on expansion header for BB ver-
B7). To check this I tried a simple C program which continuously sends
letter 'A' and 'B' to /dev/ttyS1 (i.e. UART2). I also tried checking
this with "cp /dev/random /dev/ttyS1" command but only to see constant
1.8V on the pins (in both cases).
With the above problems I am not sure if there is some problem with
the changes I did in beagle.h or the way I am testing the
functionality. Can anyone tell me if the changes done in beagle.h are
correct or not.
Has anyone one succeeded in getting UART2 or UART1 functional. Any
suggestions and help will be appreciated.
I am trying to enable UART2 available on expansion header. In order to
do so I made the required changes in u-boot-main/board/OMAP3/beagle/
beagle.h file under the section labeled bluetooth. I referred to
previous posts on the forum and OMAP TRM to achieve this.
Next u-boot.bin was build from beagle.h using following instructions
arm-2007q3 toolchain from codesorcery.
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
make CROSS_COMPILE=arm-none-linux-gnueabi-
Now using this u-boot.bin along with kernel version 2.6.28 and
Angstrom filesystem, I was not able to track any activity on UART2
pins (i.e. pin 6--> Tx and pin 8--> Rx on expansion header for BB ver-
B7). To check this I tried a simple C program which continuously sends
letter 'A' and 'B' to /dev/ttyS1 (i.e. UART2). I also tried checking
this with "cp /dev/random /dev/ttyS1" command but only to see constant
1.8V on the pins (in both cases).
With the above problems I am not sure if there is some problem with
the changes I did in beagle.h or the way I am testing the
functionality. Can anyone tell me if the changes done in beagle.h are
correct or not.
Has anyone one succeeded in getting UART2 or UART1 functional. Any
suggestions and help will be appreciated.
The expansion header UART works fine for me. I had it talking to another board
using ppp in software via a level shifter since the other end was a 3.3V
system. The biggest thing to keep in mind is your board version. Released Rev
B's and RevC's have a different pin mapping for the UART. This is done to
gain PWM functionality, I don't have the docs in front of me so I can't
comment at the moment if you got the right signals. The other thing is, I
used the kernel pinmux not U-boot. All these custom U-boot versions is really
unsustainable.
Also, if you are verifying the pin outs and signal names for the pinmux,
please refer to the schematics for your revision of the board (either RevB or
RevC2 or newer). Older versions of the SRM had a typo in one of the table
that I think impacts this.
What are you using to measure the 1.8V? Some things like DMM's or older stuff
like VTMM/VOM's often can't see the changes. Other things you can try are:
making a hard loop on RX/TX (_AFTER_ verifying pinmux to make sure RX is
really setup without the output drivers) or alternatively, put an open
collector output buffer between RX and TX.
Having said that about the U-boot pinmux stuff, are there specific complaints
from within the Beagle community about pinmux in the kernel. There are 2
basic things I have heard so far - "it is broken" without specifics and there
was one report of it hanging on boot on a RevC a few weeks ago. Is there any
other reasons? If it is only the hang, then that can be fixed.
My board version is B7 and I followed the schematics on SRM for B7 to
make the necessary changes.
I am not familiar with how to edit kernel pinmux ... any reference or
document available on
playing with kernel pinmux will be helpful.
On your second feedback ... I was using DMM to see the changes .. may
be not a good idea .. will try
using osilloscope.
Other think I am little confused about what do u mean by hard loop on
RX/TX ? ( As per my understanding
its like loopback i.e. connecting Rx directly to Tx). Am I right?
My board version is B7 and I followed the schematics on SRM for B7 to
make the necessary changes.
I am not familiar with how to edit kernel pinmux ... any reference or
document available on
playing with kernel pinmux will be helpful.
I have a write up from when I did the interboard communcations stuff. It is on
my website (see my .sig). There is a page on the pinmux and another on the
expansion header.
On your second feedback ... I was using DMM to see the changes .. may
be not a good idea .. will try
using osilloscope.
Other think I am little confused about what do u mean by hard loop on
RX/TX ? ( As per my understanding
its like loopback i.e. connecting Rx directly to Tx). Am I right?
Yes. That is exactly what I mean. The only danger is if you have both sides
with the output driver enabled and you risk frying something. An open
collector setup would give you a measure of safety if things are really out
of hand in the software. When I did the initial testing, I verified the
setup then used some test jumpers between the 2 pins on the expansion
headers. 0.1pitched headers made it easy to it.
I was going through your website and had couple of questions.
For the pinmux configurations I followed http://www.hy-research.com/omap3_pinmux.html
In above document you talked about the complete flow as mentioned in
following lines.
When you talk about mux.h and mux.c files, what package should be
used get those
files or how to get those files.
"To configure the pin mux functionality in Linux the following steps
needs to be taken:
1. See if there is a definition for the pin and functionality
needed in arch/arm/plat-omap/mux.h in the omap34xx_index enumerated
type. If it is not there, one needs to be added. In older kernels it
is in include/asm-arm/arch-omap/mux.h
2. If there is a definition in mux.h, verify the functionality
called out in arch/arm/mach-omap2/mux.c. Otherwise, the functionality
associated with the enumerated tag needs to be defined in mux.c.
3. Call omap_cfg_reg with the tag to invoke the functionality. "
I have been following your steps, but like Amit, I am not able to get
any response from UART2. I am using a BeagleBoard Rev B6, which shows
the available pins to use for UART2 are GPIO 140, 141, 142, and 143 in
"option C", or Mode 1 according to the latest TRM from TI. These are
the pins for MCBSP3_DX, DR, CLKX, and FSX when in Mode 0. So I made
the following changes to mux.c:
where I changed the MUX_MODE from the default value of 4, to the
desired value of 1. I then added the following lines to board-
omap3beagle.c in the omap3_beagle_init() function:
I then compiled the new uImage and put it on the board to run. After
booting up, I now see pin 6 as low instead of high, but I see no
change on my oscilloscope when doing an echo on the port.
Any help you could give would be greatly appreciated.
These changes to the code I made worked. The only other things I had
to do were to go into menuconfig and change the setting to allow
multiplexing, and then I had to include the mkimage path when
compiling the uImage. The final change that made everything work was
to turn off flow control, and I started seeing messages come out on my
oscilloscope.
I read your posts, but am little confused ... I could not figure out
from where to get mux.c and menufonfig and mkimage. Are these files
somewhere
in u-boot-main
I will be great if you could make a short tutorial about how to
get serial port working.
Heyy Amith have u solved that UART2 problem?
i too want to use UART2 as my serial console and UART3 for IR.
If u got solution plz let me the solution....
Hi Amith, i am too working on Beagle board B7, and i want to change
the default serial console from UART3 to UART2 in u-boot,since i want
to use UART3 for IR receiver, but i couldn't be able achieve this, if
u got any solutions of it plz let share it .....
i donated my beagleboard rev b with the special computing acrylic case into the hackers for charity auction at defcon, so if anyones around this weekend, pop by their booth and take a peek, i added some other interesting bits too.