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.
Graduate Research Assistant --MS Computer
Engineering University of
Idaho Moscow, Idaho 83844