This page is about Pin Multiplex (PinMux) on the BeagleBoard. The OMAP3 chip has fewer balls (pins) than the internal logic which provides functionality. So each ball (pin) of the OMAP3 can have different functionality (e.g. GPIO or I2C.TX). This is controlled by internal OMAP3 registers. This page tries to give some details of where some information about OMAP3 pin mux can be found in hardware and how this is controlled by software, mainly by U-Boot and the Linux kernel. The information on this page can be used then e.g. to re-configure pins exposed on Beagle's expansion connector.

OMAP3

Each pad (ball, pin) can (but must not) have up to 8 different functionalities assigned to. These are called Mode 0 to Mode 7.

Each pad (ball, pin) muxing is controlled by 16bit. So two pads (balls, pins) are controlled by one 32bit register inside OMAP3. Each register can be written/read by 16bit or 32bit accesses.

The name of the register is normally formed by the name of Mode0 pad (ball, pin) functionality which is controlled by the lower 16bit of the 32bit register ([15-0]). So don't be confused by register name: The register can configure functionality which isn't reflected by the name.

The physical address of the register is given in the table, too. To configure the pad (ball, pin) which is controlled by the upper 16bit of the register ([31-16]) you can do this by a 16bit access to physical_register_address + 0x2

Note that the same functionality can be at different pads. E.g. UART1_TX functionality can be on pad controlled by CONTROL_PADCONF_UART1_TX register (Mode0) or CONTROL_PADCONF_DSS_DATA6 (Mode2). Make sure that you only configure each logical function on a single pin.

Details of the PinMux register itself be found in same TRM (spruf98b.pdf) in section 7.4.4 Pad functional Multiplexing and Configuration (page 810):

Bits [2-0] and bits [18-16] control the MuxMode of pad A and pad B controlled by this register. Here you can select one of the 8 MuxModes Mode0 to Mode7 you get from table discussed above.

Bit [3] and bit [19] select if OMAP3 internal pull-up/-down should be enabled. If pull-up/-down is enabled by this bit, bit [4] and bit [20] configure if it should be a pull-up or a pull-down.

Bit [8] and bit [24] select if the pin is an input or a bi-directional pin.

Beagle

Details of the Beagle's expansion header usage can be found in the BeagleBoard System Reference Manual in Table 20 Expansion connector signals (page 96). This expansion exposes 22 pads (balls, pins) of the OMAP3 for your individual use. If you need signals that are not muxed by default, you have to configure the pins yourself.

Table 20 (page 96) in Beagle SRM gives you an overview of which signals can be muxed to which expansion pin.

MUX:0, MUX:1, MUX:2 and MUX:3 in table 20 in Beagle SRM correspond to what is called Mode0 to Mode4 in OMAP35x Applications Processor TRM.

To get an idea which CONTROL_PADCONF_xxx you have to touch for correct pin mux, take signal name of Beagle SRM MUX:0 and look for the same Mode0 in the OMAP35x Applications Processor TRM. Example:

Table 21 (page 97) in Beagle SRM gives an overview of expansion header signals from functionality group point of view.

Warning: The expansion header is 1.8V! In most cases you will need to apply level shifting to make use of its signals. See hardware interfacing for hardware suggestions for level shifting.

Connectors

0.1"/2.54mm Headers

Male Header Major Leage TSHS-114-D-06-A-T-LF

Female Header Major League LSWSS-114-D-02-T-LF

0.05"/1.27mm Headers

Male Header

Samtec FTSH-110-01-F-D

FCI 20021111-00020T4LF

Female Header

Samtec SFMC-110-T1-F-D

FCI 20021311-00020T4LF

Software

Controlling the hardware interface (i.e. writing the registers with appropriate values) described above can be done by any software. Up to now, default configuration is that initial pin mux is done by bootloader, U-Boot, and can be later overwritten by the Linux kernel.

Default configuration is that pin mux is set board specific by U-Boot and kernel's pin mux is disabled (i.e. kernel's CONFIG_OMAP_MUX is not set, see below).

Older Linux kernel's pin mux was somewhat broken. While different boards need different configuration, the Linux kernel had only one pin mux configuration (in arch/arm/mach-omap2/mux.c), which then obviously didn't fit any specific board. Therefore, kernel's pin mux (see below) is disabled unless you enable it intentionally.

Recent (2.6.32 at least) kernels place the mux configuration in individual board files (for the Beagle, this is arch/arm/mach-omap2/board-omap3beagle.c). You will still need to make sure that the CONFIG_OMAP_MUX option is set, however. See below for how to modify this file.

U-Boot

Primary PinMux configuration in done in bootloader U-Boot. For beagle, see file board/ti/beagle/beagle.h in the U-Boot sources.

To do pin mux as described above U-Boot uses some macro magic to configure what is given by OMAP3 hardware. E.g.:

MUX_VAL(CP(MCBSP3_DX), (IEN | PTD | DIS | M4)) /*GPIO_140*/\

MCBSP3_DX: This is the register name without CONTROL_PADCONF_*. I.e. looking into OMAP3xx TRM, this is CONTROL_PADCONF_MCBSP3_DX[15:0] register at physical address 0x4800216C. Mux mode for this pad is

MODE0: MCBPS3_TX

MODE1: UART2_CTS

MODE4: GPIO_140

M4: Here, mux MODE4 is selected, enabling GPIO_140 functionality on this pin. This is marked by the trailing comment.

IEN: This enables input, i.e. this is pad is configured bi-directional

DIS: Disable pull-up/pull-down

PTD: Pull type down, ignored if pull is disabled by DIS

Linux kernel

Older Kernels

Some additional PinMux configuration is done by the Linux kernel, too. Note that this has to be enabled by CONFIG_OMAP_MUX, else this isn't executed. This is done in file arch/arm/mach-omap2/mux.c (section CONFIG_ARCH_OMAP34XX).

Linux kernel uses some different syntax compared to U-Boot for pin mux, but logic is the same. E.g.

OMAP34XX_MUX_MODE4: Same as M4 like in U-Boot. Configure mux MODE4 here.

OMAP34XX_PIN_OUTPUT or OMAP34XX_PIN_INPUT_PULLUP: One macro for the different modes. Done with 3 orred macros in U-Boot.

Recent Kernels

More recent kernels (2.6.32 at least) have improved the infrastructure for pin mux configuration. Follow these directions to perform configuration in these kernels.

1. Determine which pin you wish to mux, and which setting you'd like to use

Take a look at the BeagleBoard System Reference Manual, section 8.19, and
figure out which pin (2–24) on the expansion header you'd like to
configure, and to which setting you'd like it to be set. The newer
versions of the SRM are preferable, since they list the name of the ball
on the OMAP associated with that pin (under the OMAP column). (N.B.: in the C4 SRM, see page 96.)

2. Figure out the name the kernel uses for that ball

In your kernel tree, open up the file arch/arm/mach-omap2/mux34xx.c. This
contains a bunch of preprocessor magic which is intended to make your life
easier.

First locate the appropriate ball definition for the OMAP package being used.
The following are available:

The C4 BeagleBoard uses a CBB (the full chip number is OMAP3530DCBB72 according
to p. 18 of the C4 SRM, which has a CBB package
[1]). So the correct
ball definition may be found starting on line 1346 at the definition of the
omap3_cbb_ball array.

Using the name of the ball that you found in step one (it'll typically be
2 letters followed by 1 or 2 numbers), search for the
lowercase (e.g., if the ball name was AE5, search for ae5). This will bring
you to a line with a _OMAP3_BALLENTRY() macro; the first parameter is what
you're interested in, so remember it. In the case of AE5, the first parameter
is MCBSP3_FSX.

3. Add an entry for each ball you wish to configure to the board_mux array

Search through arch/arm/mach-omap2/board-omap3beagle.c until you find an
array of type struct omap_board_mux called board_mux. This will likely be in a block conditional on CONFIG_OMAP_MUX, so you need to have the
CONFIG_OMAP_MUX option set in your kernel config. There will likely only
be one entry, which will look like:

{.reg_offset = OMAP_MUX_TERMINATOR },

You will add one entry for each ball to this array, before that
terminating element.

To do this, use the OMAP3_MUX() helper macro, which takes two parameters;
the first is the name you found in the previous step (e.g. MCBSP_FSX), and
the second is the mux mode you desire. This mux mode takes the form of
OMAP_MUX_MODEx, where x is the mode.

As an all encompassing example, say you want to set pin 8 on the expansion
header to mode 1, in order to have UART2_RX muxed in on that pin. You
would add:

OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE1),

to the board_mux[] array.

But, were you to try that, it wouldn't work! That's because a UART2_RX
must be set as an input in order to receive data. So, take a look at
arch/arm/mach-omap2/mux.h, which defines the valid modes to be used in the
OMAP3_MUX helper. In this example, we want OMAP_PIN_INPUT, but your application may differ. So, the correct addition would be:

This will change MUX pins 140, 141, 142, and 143 to mode 1, which is defined in the TRM from TI as UART2 functionality. The next thing you will need to do is define another pin as UART2_RX won't work unless you define it, so do this:

This defines it so that UART2_RX is only being used once as RX. Now you need to invoke these changes, while in the mach-omap2 folder, edit board-omap3beagle.c. Add the following lines to the omap3_beagle_init(void) function after omap_cfg_reg(J25_34XX_GPIO170); :

With these changes, compilie the Linux kernel following the steps on making the uImage.

Now copy the resulting uImage file to your SD card and reboot. When running the console image of Angstrom, you may need to run the command:

stty -F /dev/ttyS1 -crtscts

This will turn of the RTS/CTS handshaking, and allow the UART to run properly.

That should be it, an easy way to test is to run the command "echo "test" > /dev/ttyS1" and monitor the TX line with an oscilloscope.

Main Board

Board IDs

Entry

Board revision

Board ID

GPIO173

GPIO172

GPIO171

Comment

1

Ax/Bx

7

1

1

1

2

C1/C2/C3

6

1

1

0

3

C4

5

1

0

1

4

xM

0

0

0

0

Revision xM due H2 2010

Expansion boards

Using Beagle's expansion connector, different expansion boards with different functionality can be added. Depending on expansion's functionality, different pin mux for signals on expansion connector might be needed. To be able to auto-configure this expansion header pin mux by software, it was decided that all expansion boards shall have an EEPROM connected to expansions I2C containing a vendor and device ID. Based on this ID, readable by software, the pin mux can be configured.

Hardware

EEPROM used for this is AT24 EEPROM (AT24C01B). By three pins (A0 to A2) the I2C address can be configured to I2C address 0x50. Via Beagle's expansion header it is connected to OMAP3 I2C bus #2.

EEPROM: AT24C01B

I2C bus: 2

I2C address: 0x50

Note: I2C address 0x50 conflicts with DVI/HDMI EDID.

EEPROM content

Byte

0

1

2

3

4

5

-

Usage

Vendor ID

Vendor ID

Device ID

Device ID

Rev Num

Content

DATA

Vendor ID is a 16bit Manufacturer Identification

Product ID is a 16bit Product Identification

Rev Num is a 8bit Product Revision Number

Content is a 8bit Number which describes the content of the remaining EEPROM Data

TinCantools Zippy2

The BeagleBuddy Zippy2 Ethernet Combo Board is an expansion board for the BeagleBoard that adds the following:

Battery Backed RTC

Second MMC slot

100BaseT Ethernet(Micrell Part)

Second RS-232

+5V level I2C

AT24 EEPROM

tbd: Add pin mux description for this board.

TinCantools Trainer

The Trainer Board is an expansion board for the BeagleBoard that adds an I2C interface(+3.3v or +5v selectable), SPI(+3.3v), GPIO's(+3.3v), and an Atmega168(+3.3v or +5v selectable) connected via the second uart to the BeagleBoard. Includes a large 0.1" prototype matrix and power bus.

tbd: Add pin mux description for this board.

TinCantools ShowDog

The ShowDog Board is an expansion board for the BeagleBoard that provides support for a LCD and keyboard matrix.