BB expansion connector clarifications

I am using BB rev. c3 and using BB SRM revision C3.0 to program the
all the expansion pins as GPIO pins. Here are my issues:

1. I think the doc needs to be corrected, pin 23 and 24 go to GPIO
mode in MUX:4 and not MUX:1 as stated in the doc. The GPIO pins
mentioned are correct, just the mux is wrong.

2. I can't seem to figure out which GPIO pins are connected to pin 4
and 10 (of the expansion port). It's neither GPIO140 nor GPIO144 for
Pin 4 and neither GPIO141 nor GPIO145 for Pin 10. Further more, when I
set pin 4 to GPIO140, I seem to loose Pin 8 on the connector (which is
configured as GPIO143). Does any one has any idea which GPIO pins
connect to expansion connections 4 and 10?

I don't know if there was an errata I missed, but I couldn't find any
with google! So, if there is an errata for the version I'm using
please post me a link. If there is no errata releases, how do I
proceed to get these corrected?

Appreciate your time.

--Krishna/.

Check the schematic and go by what you find there. I don’t think there is an issue in the documentation, but the schematic is what is in the board. You can also use the datasheet to align the pin numbers on the OMAP3530 to the expansion conenctors and their corresponding MUX functions as described in the datasheet.

I will check the documentation when I get the time.

Gerald

One more note. The modes do not correspond to the mux mode. They are only an indication of the number of functions that pin has. Again, they do not reflect the mux mode. I suggest you refer to the datasheet for the actual mux mode of each pin. The documentation in the SRM attempts not to duplicate the need for developers to refer to the datasheet and the TRM for the OMAP3530 processor for this information.

Gerald

See this from the SRM:

There are a few differences on these signals on the Rev C2 vs. the other revisions. For

the Rev C2, the signals in shaded areas replace the signals on the line above it. You will

notice that no functionality is lost, but additional feature are gained. In addition to the

new functionality, the pin muxing address and settings will need to be changed. Refer to

the OMAP3530 Technical Reference Manual for more information on how to do this.

Gerald

Thnkx for the clarification Gerald! I guess I mis-read the doc wrt the mux setting.

I got pins 4 and 10 working in gpio mode finally. U-boot was probably to blame here. Once I changed u-boot to set the signals to GPIO everything worked. I was under the impression that the kernel setting would override any thing done by u-boot, but, apparently it doesn’t over-ride, especially if u-boot enabled imput on the pins. May be a kernel bug…

–Krishna/.

Could be. I generally do all my messing with the GPIO pins in the UBoot mode. It makes my testing easier. From an application SW perspective, I just leave that to the SW people to hash out!

Gerald

Thnkx for the clarification Gerald! I guess I mis-read the doc wrt the mux setting.

I got pins 4 and 10 working in gpio mode finally. U-boot was probably to blame here. Once I changed u-boot to set the signals to GPIO everything worked. I was under the impression that the kernel setting would override any thing done by u-boot, but, apparently it doesn’t over-ride, especially if u-boot enabled imput on the pins. May be a kernel bug…

You have to set CONFIG_OMAP_MUX=y if you want to control the pin mux in the kernel.

–Krishna/.