Jump to: navigation, search

This page is about Pin Multiplexor (pin mux) 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.


This section tries to give an idea how pin mux on OMAP3 works, and looks at the Beagle-specific hardware documentation for the expansion connector.


Details of OMAP35x pin mux can be found in OMAP35x Applications Processor TRM (spruf98y.pdf) in section Pad Multiplexing Register Fields (page 782) (or, if you are using the BeagleBoard-xM it's section on page 2434 of the DM3730 TRM):

  • 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, or Section 13.4.4 page 2430 for the -xM):

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

Off- and wake configuration is possible, too, but isn't discussed here.


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 20 in Beagle SRM MUX:0: MMC2_DAT7 -> Table 7-4 in OMAP35x Applications Processor TRM Mode0 MMC2_DAT7: CONTROL_PADCONF_MMC2_DAT6 register, physical 16bit address 0x4800216A.
  • 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.


0.1"/2.54mm Headers

0.05"/1.27mm Headers


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.


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.

  • AE4_34XX_GPIO136_OUT: These are only strings which are used for debug output. This string consists of two parts:
    • the pad name (e.g. AE4) is from OMAP34x and will be different for different OMAPs and different packages
    • the resulting functionality (compare U-Boot's trailing comment)
  • 0x164 and 0x16c: This is the address offset from base address. Looking into OMAP35x TRM this is
    • 0x164: CONTROL_PADCONF_MMC2_DAT4[15:0] at physical address 0x48002164.
    • 0x16c: CONTROL_PADCONF_MCBSP3_DX[15:0] at physical address 0x4800216C.
  • 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.

NOTE: Although these instructions may be correct, there is a problem with enabling mux-ing in at least some kernels. If your root filesystem will not mount after following these instructions, you can revert to your old kernel and try setting mux values through u-boot. Skip to the next section for this.

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:

 ~/omap-2.6.32 $ grep -n omap_ball arch/arm/mach-omap2/mux34xx.c
 677:struct omap_ball __initdata omap3_cbc_ball[] = {
 1033:struct omap_ball __initdata omap3_cus_ball[] = {
 1346:struct omap_ball __initdata omap3_cbb_ball[] = {
 1774:struct omap_ball __initdata omap36xx_cbp_ball[] = {
 2071:   struct omap_ball *package_balls;

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:


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. 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 final board_mux[] array would be:

 static struct omap_board_mux board_mux[] __initdata = {
 	{ .reg_offset = OMAP_MUX_TERMINATOR },

Setting Mux Through u-boot

Some quick instructions on how to use u-boot to mux pins. This assumes you are using OpenEmbedded and bitbake.

Start by:

bitbake u-boot -c configure
gvim tmp/work/beagleboard-angstrom-linux-gnueabi/u-boot-<VERSION>/git/board/ti/beagle/beagle.h

Look in the table in 'Pin Mux Cross Reference Table' and find the pin you want to use. In my case I want to use pin 24. This is BB Description I2C2_SCL and GPIO 168.

Find the BB Description in the beagle.h file and alter it's Mux setting from (probably) M0 to M4. I found:

	MUX_VAL(CP(I2C2_SCL),       (IEN  | PTU | EN  | M0)) /*I2C2_SCL*/\ 

and changed it to:

	MUX_VAL(CP(I2C2_SCL),       (IEN  | PTU | EN  | M4)) /*I2C2_SCL*/\ 


bitbake u-boot -c compile
cd tmp/work/beagleboard-angstrom-linux-gnueabi/u-boot-<VERSION>/git
(assuming your boot flash partition is mounted as /media/boot)
cp u-boot.bin /media/boot

Boot up and log in to your Beagleboard. Now we'll do a simple test:

cd /sys/class/gpio/
echo 168 > export
cd gpio168
echo out > direction
echo 1 > value
echo 0 > value

A word of warning about beagle.h

Be careful when editing board/ti/beagle/beagle.h. A given pin may appear in more than one place. Changing the first occurrence may not make the change you want. For example, I wanted to use PWMs. Lines 228-230

	MUX_VAL(CP(UART2_RTS),		(IEN  | PTD | DIS | M4)) /*GPIO_145*/\
	MUX_VAL(CP(UART2_TX),		(IEN  | PTD | DIS | M4)) /*GPIO_146*/\
	MUX_VAL(CP(UART2_RX),		(IEN  | PTD | DIS | M4)) /*GPIO_147*/\

looked like the right place to switch from Mode 4 to Mode 2. However later in the file were

	MUX_VAL(CP(UART2_CTS),		(IEN  | PTU | EN  | M2)) /*UART2_CTS*/\


	MUX_VAL(CP(UART2_CTS),		(IEN  | PTU | EN  | M2)) /*UART2_CTS*/\
	MUX_VAL(CP(UART2_TX),		(IDIS | PTD | DIS | M2)) /*UART2_TX*/\

The first group starts at line 388 and the second line 400. Note the UART2_TX and UART2_RTS are overwritten (thought a quick grep shows that UART_RX is not). To use all three PWMs, I use the lines above to switch to Mode 2. (I didn't have to use the UART2_CTS line, but decided to keep all the UART2 lines together.)

Pin Mux Cross Reference Table

BB J3 - Pin number on the BeagleBoard Expansion connector
BB Description - BeagleBoard System Reference Manual Figure 46
RevB GPIO - GPIO on BeagleBoard RevB expansion connector
RevC GPIO - GPIO on BeagleBoard RevC expansion connector
OMAP35xx Pin RevB - OMAP Processor pin number for RevB Board
OMAP35xx Pin RevC - OMAP Processor pin number for RevC Board
U-BOOT - Pin description as defined in /board/omap3/beagle/beagle.h
KERNEL - Pin description as defined in /arch/arm/mach-omap2/mux.c - Angstrom Kernel V2.6.29-R42
OFFSET - Offset as defined in OMAP35xx Technical Reference Manual Section

1 1V8
2 5V
3 MMC_DAT7 139 139 AE3 AE3 MMC_DAT7 AE3_3430_USB3HS_TTL_NXT 0x16A
4 MCBSP3_DX 140 144 AF6 AB26 MCBSP3_DX AF6_3430_USB3HS_TTL_D4 0x16C
5 MMC2_DAT6 138 138 AF3 AF3 MMC2_DAT6 AF3_3430_USB3HS_TTL_DIR 0x168
6 MCBSP3_CLKX 142 146 AF5 AA25 MCBSP3_CLKX AF5_3430_USB3HS_TTL_D6 0x170
7 MMC2_DAT5 137 137 AH3 AH3 MMC2_DAT5 AH3_3430_USB3HS_TTL_STP 0x166
8 MCBSP3_FSX 143 143 AE5 AE5 MCBSP3_FSX AE5_3430_USB3HS_TTL_D7 0x172
9 MMC2_DAT4 136 136 AE4 AE4 MMC2_DAT4 AE4_34XX_GPIO136_OUT 0x164
10 MCBSP3_DR 141 145 AE6 AB25 MCBSP3_DR AE6_34XX_GPIO141_OUT 0x16E
11 MMC2_DAT3 135 135 AF4 AF4 MMC2_DAT3 AF4_34XX_GPIO135_OUT 0x162
12 MCBSP1_DX 158 158 V21 V21 MCBSP1_DX V21_34XX_GPIO158 0x190
13 MMC2_DAT2 134 134 AG4 AG4 MMC2_DAT2 AG4_34XX_GPIO134_OUT 0x160
14 MCBSP1_CLKX 162 162 W21 W21 MCBSP1_CLKX W21_34XX_GPIO162_UP 0x198
15 MMC2_DAT1 133 133 AH4 AH4 MMC2_DAT1 AH4_34XX_GPIO133_OUT 0x15E
16 MCBSP1_FSX 161 161 K26 K26 MCBSP1_FSX K26_34XX_GPIO161_UP 0x196
17 MMC2_DAT0 132 132 AH5 AH5 MMC2_DAT0 AH5_34XX_GPIO132 0x15C
18 MCBSP1_DR 159 159 U21 U21 MCBSP1_DR U21_34XX_GPIO159_UP 0x192
19 MMC2_CMD 131 131 AG5 AG5 MMC2_CMD AG5_34XX_GPIO131_OUT 0x15A
20 MCBSP1_CLKR 156 156 Y21 Y21 MCBSP1_CLKR Y21_34XX_GPIO156_UP 0x18C
21 MMC2_CLK0 130 130 AE2 AE2 MMC2_CLK0 AE2_34XX_GPIO130_OUT 0x158
22 MCBSP1_FSR 157 157 AA21 AA21 MCBSP1_FSR AA21_34XX_GPIO157_OUT 0x18E
23 I2C2_SDA 183 183 AE15 AE15 I2C2_SDA AE15_34XX_GPIO183_OUT 0x1C0
24 I2C2_SCL 168 168 AF15 AF15 I2C2_SCL AF15_34XX_GPIO168_OUT 0x1BE
25 REGEN -
26 nRESET -
27 GND -
28 GND -


Add your examples here: What has to be changed to get which signal on expansion connector

MMC2 via TXS0206 or TXS02612

	MUX_VAL(CP(MMC2_CLK),		(IEN  | PTU | EN  | M0)) /*MMC2_CLK*/\
	MUX_VAL(CP(MMC2_CMD),		(IEN  | PTU | EN  | M0)) /*MMC2_CMD*/\
	MUX_VAL(CP(MMC2_DAT0),		(IEN  | PTU | EN  | M0)) /*MMC2_DAT0*/\
	MUX_VAL(CP(MMC2_DAT1),		(IEN  | PTU | EN  | M0)) /*MMC2_DAT1*/\
	MUX_VAL(CP(MMC2_DAT2),		(IEN  | PTU | EN  | M0)) /*MMC2_DAT2*/\
	MUX_VAL(CP(MMC2_DAT3),		(IEN  | PTU | EN  | M0)) /*MMC2_DAT3*/\
	MUX_VAL(CP(MMC2_DAT4),		(IEN  | PTU | EN  | M7)) /*GPIO_136 reserved*/\
	MUX_VAL(CP(MMC2_DAT5),		(IEN  | PTU | EN  | M7)) /*GPIO_137 reserved*/\
	MUX_VAL(CP(MMC2_DAT6),		(IEN  | PTU | EN  | M7)) /*GPIO_138 reserved*/\
	MUX_VAL(CP(MMC2_DAT7),		(IEN  | PTU | EN  | M7)) /*GPIO_139 reserved*/\

NOTE: This example is for 4-bit interface. IEN has to be set for bi-directional lines including CLK


This example uses kernel pin mux to enable configure UART2. These changes were made to a Rev B6, so be sure to check your reference manual and TRM from TI for the proper pins.

Begin by navigating to your kernel's /arch/arm/mach-omap2 folder and edit mux.c as follows:

MUX_CFG_34XX("AF6_34XX_GPIO140_UP", 0x16c,
MUX_CFG_34XX("AE6_34XX_GPIO141", 0x16e,
               OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170,
               OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172,
               OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT) 

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:

MUX_CFG_34XX("AD25_34XX_GPIO147", 0x17a,

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); :

	omap_cfg_reg(AF6_34XX_GPIO140); //CTS
	omap_cfg_reg(AE6_34XX_GPIO141); //RTS
	omap_cfg_reg(AF5_34XX_GPIO142); //TX
	omap_cfg_reg(AE5_34XX_GPIO143); //RX

This invokes the changes to the pin settings that we made in mux.c. Now navigate to arch/arm/plat-omap/include/mach/mux.h and add the following line to the enum at the bottom:


Now you must use kernel's make menuconfig to enable (hit 'Y') kernel pin mux and gpio support as follows:

System Type --> TI OMAP Implementations --> OMAP multiplexing support
Device Drivers --> GPIO Support --> /sys/class/gpio/... (sysfs interface)

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.

UART2 enabling within U-boot

This example is made for revision C4, please check reference manual and TI TRM for proper pins.

As a general rule, in order to get u-boot multiplexing work you need to disable kernel multiplexer.

To do so use kernel make menuconfig and set:

Symbol: OMAP_MUX [=n]                                                                                                   
Location: System Type -> TI OMAP Common Features

Go to u-boot sources (the example is for v2010.03), navigate to board/ti/beagle/ and open beagle.h header file.
Here are defined a set of macros used for multiplexer setup. Those macros are used by u-boot board init functions, defined in beagle.c in the same directory.
Find the macro related to you board revision (MUX_BEAGLE_C() in the example) and add the following lines at its end:

	/*UART2 on bb pins 4 (CTS) 6 (TX) 8 (RX) 10 (RTS) */\
	MUX_VAL(CP(UART2_CTS),		(IDIS | PTU | EN  | M4)) /*UART2_CTS*/\
	MUX_VAL(CP(UART2_TX),		(IDIS | PTD | DIS | M0)) /*UART2_TX*/\
	MUX_VAL(CP(MCBSP3_FSX), 	(IEN  | PTD | DIS | M1)) /*UART2_RX*/ \
	/*unset alternative UART2 pins, to avoid double muxing*/ \
	MUX_VAL(CP(UART2_RX),		(IDIS | PTD | DIS | M4)) /*alternative UART2_RX*/\
        MUX_VAL(CP(MCBSP3_DX),		(IEN  | PTD | DIS | M4)) /*OLD UART2_CTS*/\

(please note that MCBSP3_DX, MCBSP3_DR and MCBSP3_CLKX UART2 functionalities are not listed in BeagleBoard reference manual, but only in TI's TRM)
Warning: when disabling alternative functionalities for some pin (UART2_RX, in example) do not set safe mode (M7), but use M4 instead. That's because some pins are also used for other functions. UART2_RX pin is used for enabling EHCI hub, and if set to M7 EHCI will stop working.

Macro's syntax is described here.

Now save you work and close.
Rebuild u-boot and copy the resulting u-boot.bin to your sd card;
reboot and test uart2 the usual way, shorting Rx and Tx pins and echoing something to /dev/ttyS1, or as explained before using stty command.

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 Ax/Bx 0 0 0 0 According to [2]
5 xM C 2 0 1 0

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.


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

tbd: Add details

Vendor and Device IDs

List of Vendor and Device IDs

Entry Vendor Device Vendor ID Device ID PinMux Comment
1 TinCanTools Zippy 0x0001 0x0001 Zippy details Limited Availability
2 TinCanTools Zippy2 0x0001 0x0002 Zippy2 details Out of Production
3 TinCanTools Trainer 0x0001 0x0004 Trainer details REV.B NOW AVAILABLE
4 TinCanTools ShowDog 0x0001 0x0003 ShowDog details
5 Gumstix Summit 0x0002 0x0001 Overo expansion
6 Gumstix Tobi 0x0002 0x0002 Overo expansion
7 Gumstix Tobi Duo 0x0002 0x0003 Overo expansion
8 Gumstix Palo35 0x0002 0x0004 Overo expansion
9 Gumstix Palo43 0x0002 0x0005 Overo expansion
10 Gumstix Chestnut43 0x0002 0x0006 Overo expansion
11 Gumstix Pinto 0x0002 0x0007 Overo expansion
12 Gumstix Gallop43 0x0002 0x0008 Overo expansion
13 Gumstix Alto35 0x0002 0x0009 Overo Expansion
14 Gumstix Stagecoach 0x0002 0x000A Overo Expansion
15 Gumstix Thumbo 0x0002 0x000B Overo Expansion
16 Gumstix Turtlecore 0x0002 0x000C Overo Expansion
17 Gumstix Arbor43C 0x0002 0x000D Overo Expansion
18 Gumstix Arbor50C 0x0002 0x000E Overo Expansion
19 Gumstix Arbor70C 0x0002 0x000F Overo Expansion
20 Gumstix Pepper SBC 0x0002 0x0030 Pepper SBC
21 Gumstix Pepper DVI SBC 0x0002 0x0031 Pepper SBC
22 Ettus Research USRP Embedded 0x0003 0x0001
23 HY Research TBD 0x0004 TBD
24 MENTOREL BlueShark 0x0005 0x0001 SODIMM SOM
25 KBADC Beagle FPGA 0x0006 0x0001 FPGA Expansion board
26 Liquidware BeagleTouch 0x0007 0x0001 BeagleTouch details OLED Display Module
27 Brainmux LCDog 0x0008 0x0001 LCD Interface Module
28 Brainmux LCDogTouch 0x0008 0x0002 LCD Interface Module w/Touch Controller
29 StackFoundry Hardhat 0x0009 0x0001 Industrial IO board
30 Special Computing Place holder 0x000A 0x0001
31 Beagleboardtoys Wifi adapter 0x000B 0x0001
32 Beagleboardtoys VGA adapter 0x000B 0x0002 VGA_adapter details NOW AVAILABLE
33 Beagleboard toys LCD adapter 0x000B 0x0003 LCD_adapter details
34 TinCanTools Barker 0x0001 0x0004 PRE-PRODUCTION
35 TinCanTools BeaconBoard 0x0001 0x0005 BETA TESTING
36 Beagleboardtoys ULCD LITE 0x000B 0x0004
37 romscraj boardGloveSock 0x000C 0x0001 PRE-PRODUCTION
38 KITT Engineering AD/DA Board 0x000D 0x0001 Design stage
39 Owl-Art Un-Ltd. Level Shift & IIC Board 0x000E 0x0001 Prototype stage
40 bct electronic GmbH brettl3 0x000F 0x0001 Prototype stage
41 Conexiona Telecom SMART 0x0010 0x0001 Design Stage
42 SPI Multiplexor 0x0011 0x0001 Hardware first articles, Driver in development
43 bct electronic GmbH brettl4 0x000F 0x0002 Prototype stage
44 FlightTronics Almtracker3 0x0012 0x0003 Almtracker 3 (APRS Cape)
45 LSR COM6L Adapter Board 0x0013 0x0001 NOW AVAILABLE
46 Dataplicity Vivaldi 0x0014 0x0001
47 Dataplicity Verdi 0x0014 0x0002
48 Cognitronics & Sensor Systems, CITEC, Bielefeld University AMiRo Cognition Board 0x0015 0x0001 Overo robot expansion board

Allocation of vendor and device IDs

Vendor and device IDs of the expansion boards are self managed by the vendors[1]. If you are a developer of a expansion board for BeagleBoards and want to allocate a vendor ID, then just add a row to the list of expansionboards and pick a yet unused number (e.g. max(vendorID) + 1) as your vendor ID. This ID should be used for all expansion boards you build for the BeagleBoard. The device ID is used to differentiate the expansion boards of the same vendor.

Board description

TinCantools Zippy

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

  • Battery Backed RTC
  • Second MMC slot
  • 10BaseT Ethernet(ENC28j60)
  • Second RS-232
  • +5V level I2C

See Beagle Zippy page for more details.

PinMux: See Zippy PinMux patch.

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

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.

tbd: Add pin mux description for this board.

Beagle VGA Board

VGA Adaptor board to interface Beagle and standard VGA monitors

Liquidware BeagleTouch

The BeagleTouch is a 480×272 resolution and 262K color touchscreen OLED display, with a 20 mm speaker, 1-Watt audio driver codec, USB serial terminal interface, the BeagleTouch snaps directly onto the BeagleBoard to help create a handheld tablet computer.

BeagleTouch BeagleBoardPinMUX

Expansion Pin BeagleBoard C4 BeagleTouch Req Pin State
1 1V8 1V8
2 5V 5V

SPI Multiplexor

4 GPIO pins control selection of 1 of 16 SPI slaves. Interfaces to BeagleboardxM expansion connector and utilizes SPI channel 3 chip select 0.