Has anyone been able to use devmem2 at runtime to re-mux Overo UART2 Tx/Rx to the GPIO146_PWM11/GPIO147_PWM8 signals on the 40-pin TOBI header?  I have successfully re-muxed these signals using a modified u-boot, but I'm wondering whether the same thing can be done in a shell script using devmem2 after the kernel has booted. 

So far, I've tried running the following bash script under a (2.6.39) factory console image to try and adjust the mux settings :

#!/bin/sh
# Clear the existing UART2 mapping to the BT module
devmem2 0x4800216C w 0
devmem2 0x48002170 w 0

# Map UART2 to TOBI pin signals
devmem2 0x48002178 w 0x01000000


This results in the following console output:
Memory mapped at address 0x401e0000.
Read at address  0x4800216C (0x401e016c): 0x00000000
Write at address 0x4800216C (0x401e016c): 0x00000000, readback 0x00000000
/dev/mem opened.
Memory mapped at address 0x402e2000.
Read at address  0x48002179 (0x402e2178): 0x01000000
Write at address 0x48002179 (0x402e2178): 0x00000000, readback 0x00000000
/dev/mem opened.
Memory mapped at address 0x40126000.
Read at address  0x48002178 (0x40126178): 0x00000000
Write at address 0x48002178 (0x40126178): 0x01000000, readback 0x01000000

I have an oscilloscope connected to the GPIO146_PWM11 pin on the TOBI board so that I can observe whether serial data is present.  To check whether the mux changes have been applied, I run:
echo 'hello' > /dev/ttyO1

The echo command does not appear to work, however.  The command does not return (i.e. I have to Ctrl-C out of it), and my scope shows no activity on the Tx pin.  For what it's worth, I did verify that the scope *does* show activity when my console image with a modified u-boot is used.

I can continue to use my custom image with mapping done in u-boot, but I'd love to know whether the devmem2 approach is also possible.

Best Regards,

Dave Billin

Graduate Research Assistant --MS Computer Engineering
University of Idaho
Moscow, Idaho 83844

e-mail: david.billin@vandals.uidaho.edu