[beagleboard] Using GPIO140-142

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?

Thanks,

Eric

Maybe the the LL_DEBUG stuff is activating the uart, I remember people complaining about that last year. Dunno if it has been fixed already.

regards,

Koen

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.

Thanks for the clue...

Eric

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...

Eric

You can do it from user land as well. See this post...
http://groups.google.com/group/beagleboard/msg/7c6a1ce256e46cfc

You should be able to use debugfs for that. The link saladino sent probably has that info :slight_smile:

regards,

Koen

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...

Eric

OK - time put on a dunce cap and stand in the corner. GPIO140-142 are
for the Rev B* boards. Rev C2 uses GPIO144-146 on those pins.

Thanks for all the help.

Eric