NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

Pinmux Switching from NAND to PCI

From Texas Instruments Wiki
Jump to: navigation, search

Introduction[edit]

This document describes how to configure the DM6467 to boot from a NAND device and then switch modes to act as a PCI slave after boot. A block diagram is provided to show connectivity to the bus switching devices, which are required to route the shared EMIF and PCI signals to the NAND and PCI bus, respectively. This document also explains the software considerations needed for switching the mux mode from NAND to PCI during the boot sequence.


The EMIF and PCI peripherals of the DM6467 share many of the same pins, so special consideration is needed when connecting to both a NAND device and a PCI bus. In general, on-the-fly switching between a NAND device and a PCI bus is not supported on the DM6467. For example, when the DM6467 is accessing the NAND memory, it will be unable to respond to the PCI bus, which can put the PCI master in an unknown state. Unless it can be guaranteed that no PCI master will attempt to access the DM6467 during this time, switching away from the PCI bus will require a system reset before it can be switched back.

This document provides a way to boot from a NAND device and then switch to PCI mode after boot. It is important to note that this solution is only valid for embedded systems. Systems with PCI add-in cards will violate the PCI specification if this is implemented.


Implementation[edit]

Overview[edit]

The DM6467 defaults to EMIF mode after reset, so the NAND can be accessed for boot without any special configuration. During this time, the PCI bus must be held in reset to prevent any PCI masters from attempting to access the DM6467. Once the boot memory in NAND has been copied to the DDR, the PCI pins are switched to the PCI bus, and the PCI bus is taken out of reset.

In case that the NAND memory must be updated after boot, the system must be reset afterwards to put the PCI bus in a known state.

Hardware Requirements[edit]

Figure 1 shows the block diagram for connecting the DM6467 to both a NAND device and the PCI bus. For 8-bit NAND devices, two FET muxes (SN74CBT16214) are used to connect the data and control signals for the NAND to either the NAND device or the PCI bus. For 16-bit NAND devices, three FET muxes are needed. The PCI bus may be directly connected to the FET muxes without the use of a PCI bridge.

A GPIO is used to control the FET muxes as well as to hold the PCI bus in reset when the DSP is in EMIF mode. The GPIO will also drive the PCI_RST high once the DSP has switched to PCI mode. In this document, GPIO[2] is used; however, as long as the GPIO is not pinmuxed with the NAND or PCI signals, any GPIO may be used.

A pull-down resistor is needed on the GPIO[2] in order to keep the PCI bus in reset when the DM6467 is initially powered on. Additionally, a pull-up resistor is needed on the CS2 pin of the NAND for when the FET mux has switched to the PCI bus.

WARNING: The DM6467 PCI_RST signal should not be connected to the PCI bus. Doing so will hold the DM6467 in reset when the FET mux initially switches from NAND to the PCI bus.

Figure 1. Hardware Implementation Block Diagram

Software Requirements[edit]

The following steps should be taken in software to boot from the NAND device and switch the DM6467 pinmux to PCI during operation:

  1. During U-Boot, copy the boot parameters, Linux kernel, and a minimal file system from the NAND to the DDR. A NAND file system cannot be used, because the NAND will be inaccessible after boot. In addition, there is no support for file systems on PCI HDD devices because currently there is no software support for DM6467 as a PCI master device.
  2. In order to prevent the DMSoC from resetting once the pinmux is changed to PCI mode, GPIO[13] must be driven high first. In board_init during Linux boot-up:
    1. Set the DM6467 pinmux to enable the GPIO pins
    2. Set the GPIOs as outputs
    3. Drive GPIO[13] high
    4. Set the DM6467 pinmux to enable the PCI pins
    5. Drive GPIO[2] high to take the PCI bus out of reset and select B2 of the FET mux.

Example code is provided below:

 static void board_init(void)
 {
   #define REG_PINMUX0 __REG(0x01C40000)
   #define REG_GPIO_DIR01 __REG(0x01C67010)
   #define REG_GPIO_OUT_DATA01 __REG(0x01C67014)
 
   /* Setup PSCs for Required Components */
   board_setup_psc(DAVINCI_GPSC_ARMDOMAIN, DAVINCI_DM646X_LPSC_GPIO, 1);
   board_setup_psc(DAVINCI_GPSC_ARMDOMAIN, DAVINCI_DM646X_LPSC_PCI, 1);
   ...
 
   /* Set Mux Mode to GPIO */
   REG_PINMUX0 = 0x2;
    
   /* Set Direction of GPIOs to ‘OUT’ */
   REG_GPIO_DIR01 = 0x0;
     
   /* Drive GPIO[13] High */
   REG_GPIO_OUT_DATA01 = 0x2000;
    
   /* Set Mux Mode to PCI */
   REG_PINMUX0 = 0x4;
    
   /* Drive GPIO[2] High */
   REG_GPIO_OUT_DATA01 = 0x2004;
 }


Using the DM6467 EVM[edit]

The DM6467 EVM board has the mux switches implemented already. The Altera CPLD on the board controls the mux switches depending on whether or not the EVM is plugged into a PCI backplane. To instead control the switches with a GPIO, the CPLD must be reprogrammed with a modified firmware. The original source can be found on the Spectrum Digital website[1]. An Altera CPLD programming cable is required to flash the new firmware.

A modified version of the CPLD firmware is also provided which uses GPIO[2] as the mux switch control Davincihd_revf_modified.zip.

Please note that the EVM will not hold the PCI bus in reset without hardware modification, so this may only be used if the PCI master will not attempt to access the slave when it is set to NAND mode.

E2e.jpg {{
  1. switchcategory:MultiCore=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Pinmux Switching from NAND to PCI here.

Keystone=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Pinmux Switching from NAND to PCI here.

C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article Pinmux Switching from NAND to PCI here. For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Pinmux Switching from NAND to PCI here.

}}

Hyperlink blue.png Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity