I'd like to use GPIO140-142 (pins 4,6,10 on the expansion header) for
GPIO (and in the future McBSP3) but can't seem to get control of them.
I've configured their pinmuxes in Mode4 in both u-boot and in the
kernel board init file, yet they still seem to be muxed to UART2
(sending text to /dev/ttyS1 toggles pin6).
I've seen this in several different kernel versions - both the 2.6.29
from Angstrom Stable, as well as the 2.6.32 from Unstable. Disabling
the initialization of the serial ports eliminates /dev/ttyS* and
prevents toggling pin6 but doesn't free these pins up for GPIO.
It seems that the pinmuxes for these pins are being re-set to UART2
somewhere else in the kernel, outside for the board init file. I've
checked the serial init code and that doesn't appear to be doing it,
so I'm at a loss for where else to look. Any suggestions?
Interesting. I checked my .confg files and
CONFIG_OMAP_LL_DEBUG_UART3=y is set in both of them. Since my problem
is with UART2, I'm not sure if there's any connection but I'll hunt
down where LL_DEBUG lives and check.
Looks like LL_DEBUG controls where the "Uncompressing Linux... done,
booting the kernel." message goes. That happens prior to the board
init process where I'm explicitly setting up the pinmux (and
confirming it's set right), so I don't think that's part of the
problem here.
Maybe I need to write a loadable module to access the pinmux from
userspace - that would help me override anything that happens late in
the boot process. Just need to figure out how to do that...
Thanks - that works and shows that the pinmuxes are set to mode 4 as I
had hoped. That raises an interesting question as to why GPIO isn't
talking to them, and why the UART2 TX output is coming through
instead.
This is a rev C2 board - I thought that all the expansion pin changes
happened between rev B* and C*, so I should be working with the newer
configuration. Need to go back and check that...