Difference between revisions of "BeagleBoardPinMux"

From eLinux.org
Jump to: navigation, search
m (Improve some details)
m (Discuss register details)
Line 12: Line 12:
 
Details of OMAP35x PinMux can be found in [http://focus.ti.com/lit/ug/spruf98b/spruf98b.pdf OMAP35x Applications Processor TRM] (spruf98b.pdf) in section ''7.4.4.3 Pad Multiplexing Register Fields'' (page 814):
 
Details of OMAP35x PinMux can be found in [http://focus.ti.com/lit/ug/spruf98b/spruf98b.pdf OMAP35x Applications Processor TRM] (spruf98b.pdf) in section ''7.4.4.3 Pad Multiplexing Register Fields'' (page 814):
  
* Each ball (pin) can (but don't must) have up to 8 different functionalities assigned to. These are called ''Mode 0'' to ''Mode 7''.
+
* 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 ball (pin) muxing is controlled by 16bit. So two balls (pins) are controlled by one 32bit register inside OMAP3. Each register can be written/read by 16bit or 32bit accesses.
+
* 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 ball (pin) functionality which is controlled by the lower 16bit of the 32bit register ([15-0]).
+
* 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 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''
+
* 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''
 +
 
 +
Details of 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 above
 +
* Bit [8] and bit [24] select if the pin is an input or a bi-directional pin.
 +
* 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.
 +
 
 +
Off- and wake configuration is possible, too, but isn't discussed here.
  
 
==Beagle==
 
==Beagle==

Revision as of 01:29, 29 May 2009

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

Hardware

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

OMAP3

Details of OMAP35x PinMux can be found in OMAP35x Applications Processor TRM (spruf98b.pdf) in section 7.4.4.3 Pad Multiplexing Register Fields (page 814):

  • 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

Details of 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 above
  • Bit [8] and bit [24] select if the pin is an input or a bi-directional pin.
  • 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.

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

Beagle

Details of Beagle's expansion header usage can be found in BeagleBoard System Reference Manual in table 20 Expansion connector signals (page 96).

tbd.

Software

Controlling the hardware interface (i.e. writing the registers with appropriate values) described above can be done by any software. Up to know, default configuration is that initial pin mux is done by bootloader U-Boot, and later can be overwritten by 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).
  • Kernel's pin mux is known to be somehow broken. While different boards need different pin mux, recent Linux kernel has only one pin mux configuration, which then obviously don't fit any special board. Therefore, kernel's pin mux (see below) is disabled unless you enabled it intentionally. Kernel's pin mux needs some major re-write.

U-Boot

Main PinMux configuration in done in bootloader U-Boot. For beagle, see file board/omap3/beagle/beagle.h.

tbd.

Linux kernel

Some additional PinMux configuration is done by 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).

tbd.

Examples

tbd.