As P1025RM.pdf shows, one can multiplex some pins such as, LAD8/GE_PA0 multiplexing. My design uses LOCAL BUS (nor flash) and UTOPIA at the same time. Can I design my product like this in view of pin multiplexing? LAD8 must be used as local bus pin. For UTOPIA, this pin serves as PA0, which is UTOPIA TX address 4. Usually this UTOPIA signal can be not-used. P1025 Reference Manual chapter 12.5.1.2 states that LAD [0:15] can carry both A [0:15] and A [16:31] via ABSWAP setting switching. How can I use it to skip LAD8 to address local bus device? ABSWAP is not used dynamically. It should be set either 0 or 1 but not be switched from time to time. In this case only A [16:31] (from LAD) is available when ABSWAP is used (set to 1). In this case this can only be used if customer requires 16 bit or fewer address lines. In P1025/P1016, for UTOPIA pins UPC1_RxADDR [2:4]/UPC1_TxADDR [2:4], each signal has two pins described in p1025RM. Based on this, can I use any one of the pins LAD08 or MDVAL for UPC1_TxADDR [4]? For LAD08, I'll assign this pin for LOCAL BUS. Yes, you can use any one of the 2 pins for these signals using PMUXCR register. UPC1_TxADDR [4] can be either the one multiplexed with LAD08 or MDVAL. You can assign LAD08 pin for LOCAL BUS. Also remind you that, UPC1_TxADDR 4] is MSB, if only 4-bit UTOPIA address is needed, just use UPC1_TxADDR [0:3] and this LAD08/UPC1_TxADDR[4] pin can be configured as LAD08 by clearing PMUXCR[QE1] bit to 0. In P1025/P1016, I saw that LOE/ LGPL2/ LFRE in the same line, but in P1016EC.pdf, only LGPL2 is present in B14-pin description and I cannot find LOE/LFRE. Can LOE/LFRE (GPCM read enable) signal use B14-pin? LOE/LFRE (GPCM read enable) signal can use B14-pin. For LGPLx pins, we only put the LPGLx in our hardware spec. You can find all other multiplexed function from P1025/P1016 reference manual.

What is requirement for the voltage ripple of DDR3 controller MVref? The nominal value of MVref is 1.5V. 1%, +/- 7.5mV is the tolerance value for MVref (ripple range). Can you please explain the RDRVR resistance for DDR3 SDRAM memory interface? RDRVR is the "Driver" resistance. It is the resistance at the driver side. Half strength is ~40 ohms and full strength is ~20 ohms. How can I determine the power rating of the resistor connected to MDIC0 and MDIC1 for both half strength and full strength? The MDIC resistors connected to MDIC [0:1] signals used for either full or half drive strength calibration do not draw much current. So you can use 1/16W rated resistors for either half or full drive calibration.

For P1013/P1022, when I am using a DDR controller with a 64-bit interface with a 32-bit memory sub system, which lanes should I use? When a 64-bit DDR interface is configured in a 32-bit data bus width, lanes [0:3] (MDQ [0:31]) will be used.

In a previous document, I went through the basic steps of building SDK 1.3.2 for the first time. Now I'm ready to deploy the images onto my target, a P3041DS system. Fortunately my P3041 already has a U-boot and linux install on it. So I can just try and update the SDK from within U-boot. I boot up my trusty terminal - I use putty, and connect to my local COM port at 115200 baudrate. My Ubuntu server already has a tftp server installed, and I link my images over from the SDK build/deploy/images directory over to the /tftpboot directory. The QorIQ_SDK_Infocenter.pdf document within the install has information on the flash bank usage for the current SDK. Make sure you use the document and flash map from the current SDK, as things change. I ended up with a system that didn't boot when I used the older location for the fman uCode (from SDK 1.x) on the SDK 1.3.2 system. Here is a table from the document that shows the flash map for a couple of the QorIQ DS system. It's important to note here that this covers the NOR flash - which is what I'm currently using. You may want to experiment with using NAND or SPI based flash instead - but for my purposes I'm going to re-image NOR flash. The NOR on these development systems is banked, meaning that the most significant address line is tied to a DIP switch. So I can have multiple images in Flash at one time, and switch between them (especially helpful when I mistakenly corrupt one). I'm currently in bank0 (which is the "current bank" in the table above). From this, I see that the addresses I should be interested in are located at: Name Address rcw 0xe8000000 Linux.uImage 0xe8020000 uBoot 0xeff800000 fman uCode 0xeff40000 device tree 0xe8800000 linux rootfs 0xe9300000 To verify that this is correct, I can dump out my RCW: And I can also dump out my current U-boot (which should always start with an ASCII header identifying it): at this point I can start updating the images directly from my TFTP server. I have my tftp server already defined via the U-boot environment serverip, so I just tftp the U-boot image to a randomly picked address in RAM of 0x100000. The transfer went ok, so I can burn it into flash now. I will first erase the flash starting at 0xeff80000. Since U-boot is 0x80000 size, I'll erase from 0xeff80000 for size 0x80000. Apparently my sectors were protected. So I need to unprotect first, then erase again. And by reading the flash, I verify that it has been erased (erased NOR always reads back all 0xF's) So, now I can burn the flash: I use a binary copy. And then verify that the image was written correctly. Then we go through the same technique with the other images. I'll burn the fman ucode as well: Then for the actual images and dtb, you have an option of burning them, but I'll tftp them instead. For this I created a U-boot environment variable called ramboot, and point the image names to the paths on my server: At this point I can save the environment to flash via a saveenv command in U-boot. I'll re-boot into the new U-boot to make sure it works (if it doesn't for some reason, I can jump back to a different U-boot I had previously burned in the alternate bank, or else I'll have to use a debugger to re-burn the flash). Then, from within U-boot I can run ramboot, and if all goes well it should fetch the images and boot all the way into the new SDK. Eventually it should boot all the way to a linux prompt.

      A shared-MAC device is one that can be used from two Linux and/or USDPAA partitions. Shared-MAC net device can be used in two scenarios, two or more Linux separate partitions under control of hypervisor(topaz), one Linux and one USDPAA running in the same partition.       1. DPAA Ethernet Driver Types       2. BMan Driver for shared-MAC and MAC-less port       3. QMan Driver for shared-MAC and MAC-less port       4. Running  Shared-MAC between USDPAA and Linux

If unused, how do I terminate following pins in P1011/P1020: SDHC_DATA[0:2], SDHC_DAT3, SPI_CS[0:3]/SDHC_DAT[4:7] and SPI_CS0_B/SDHC_DATA4? All the 3 pins SDHC_DATA[0:2], SDHC_DAT3 and SPI_CS[0:3]/SDHC_DAT[4:7] should be don't care if not used. Please leave SPI_CS0_B.SDHC_DATA4 as floating when not used. I have designed my P1011 board based on the older hardware spec, and found that AVDD_CORE0 and AVDD_CORE1 were swapped in newer hardware spec. At this time, it is difficult to cut the pattern for the current AVDD_CORE1. So 1.0V power applied to AVDD_CORE1 though core 1 is not used. Does this cause any problem? If AVDD_CORE1 is powered in single core device, there'll be no problem. But if AVDD_CORE0 is not powered in single core device, the device may not boot up. How should I handle pin W26,F16 pins in P1020? Just let them "NC", or need connect them to AVdd? If AVDD_CORE1 is not powered up i.e. connected to 1.0V, the single core p101x device cannot be boot up. Please implement the AVDD circuit at this stage.

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

Time division multiplexing(TDM) is a communication term for multiplexing several channels on the same link. QUICC multi-channel controller(QMC) is a firmware package which uses a unified communication controller(UCC) working in slow mode. The QMC is used to emulates up to 64 time-division serial channels through a time-division-multiplexed(TDM) physical interface. Each of QMC channels can be independently programmed to support either HDLC or transparent protocols. This document introduces TDM QMC driver implementation in Linux Kernel for the processors with QE UCC working in slow mode. Data flow over a QMC channel involves a TDM line and a UCC, working in slow mode. For each channel, Tx data flow consists of data transfer from the external memory to the TDM physical connection. Rx data flow consists of data transfer from the TDM physical connection to the external memory. In both data flows, the major stations are: data buffers, UCC, and the TDM line. Please refer to the following figure for the data flow, the driver requires to configure two levels of routing tables. The first level consists of the SI RAM routing tables, Tx and Rx, which are common to other controllers as well. 1. QE TDM QMC Driver Introduction 2. Driver Architecture and Components 2.1 QMC Driver Memory Allocation 2.2 QMC and TDM Devices Initialization 2.2.1 SI RAM entry initialization 2.2.2 UCC Slow Mode QMC Initialization 2.2.3 QMC Channel Initialization 2.2.4 QMC TSA Slot Initialization 2.3 QMC Channel Interrupt Handling 2.4 QMC and TDM Configuration 2.4.1 Enable and Configure QMC Channel 2.4.2 Enable QMC 2.4.3 Enable TDM 3. QMC TDM Driver Calling Sequence 4. QMC TDM DTS Definition 5. Configure QMC TDM Driver and Running the Testing Program

I wanted to choose boot location for P2040. Does P2040 supports GPCM 16 bit NOR boot? Yes, P2040 supports GPCM 16 bit NOR boot. It can be done by configuring 4 bits (bit 192 to 195) of RCW source location to 1101. If I use NOR FLASH as boot device, can NOR FLASH be used as RCW storage device? Do I need an extra SPI flash is required or not? Yes, you can use NOR flash and the options are 0x1100 and 0x1101 (listed in the table 4-26 in P2040 Reference Manual). Does P2040 support to boot from SPI flash? Yes, P2040 can boot from SPI flash. But it is different from booting from NOR flash. One eSPI pre-bootloader is required.

For P1021 eTSEC, can I connect eTSEC RGMII with other vendor CPU/FPGA which also supports RGMII Ethernet MAC? In other words, the other side of eTSEC is not a PHY, but a MAC. You can definitely do that but you should remember to connect TX signals of P1021 to RX signals of another MAC and vice versa for MAC mode RGMII as shown below: P10xx_TXD [0:3] -> FPGA_RXD [0:3] P10xx_TX_CTL->FPGA_RX_CTL P10xx_TX_CLK->FPGA_RX_CLK P10xx_RXD [0:3]<-FPGA_TXD[0:3] P10xx_RX_CTL<-FPGA_TX_CTL P10xx_RX_CLK<-FPGA_TX_CLK Also, you have to take the clock delay into consideration. If I didn’t use RGMII, can MDIO/MDC and LVdd be configured at 3.3V for P1012/P1021? The LVdd bank can be operated at 2.5V (for RGMII) and 3.3V(MII/RMII). All the eTSEC IOs including MDIO and MDC can operate at both the voltages. I measured the rise/fall time for RMII interface (800ps) to be lower than P1012/P1021 hardware Spec requirement (min 1ns). Is that a problem? How can I rectify it? When a requirement/condition is specified in hardware spec, it means that we test/guarantee our device to work at that particular condition. For RMII, the hardware spec is inherited from the RMII spec, which states that the rise and fall time should be from 1ns to 5ns. The reason behind is that the RMII spec wants to simplify the layout requirement such that no termination or impedance matching is needed. Although it can be said that a faster rise/fall time is not likely to cause a failure, in order to meet the hardware spec and/or the RMII spec, below steps are recommended: 1. match impedance and add serial termination for the CLK, or 2. use a slower CLK source

Section 4.4.3.11 in Reference Manual states, "Note that if SGMII mode is not selected on eTSEC1, then it is configured to be in RGMII mode." Yet the MAC is coming up disabled, not RGMII. How can I configure eTSEC1 in RGMII mode in this case? It is not possible to configure eTSEC1 in RGMII mode once it's configured in SGMII mode via POR configs. TSEC1 MAC appears to be disabled when set to mode "11" Table 4-19. Looking at the Table 15-17, it appears if I have them set ECNTRL fields and MACCFG2[I/F] fields for interface mode RGMII, with cfg_io_ports[0:1] = 11, then that should set TSEC1 to RGMII properly, with 2 independant PCIe X1 ports on SerDes SD2. Is that correct? DEVDISR[TSEC1] is 0 at reset. DEVDISR[TSEC2] = n => if PCIe is configured as x4 or SERDES is disabled, DEVDISR[TSEC2] will be disabled. DEVDISR[TSEC3]= n => if TSEC1 is used in MII, TSEC3 can be used only in SGMII. if PCIe is configured as x4 or SERDES is disabled, DEVDISR[TSEC3] = 1. Which P1010 TBI PHY register bit(s) should be used to determine SGMII link status? Is this the Remote Fault and Link Status bits of the P1010 TBI Status Register (SR) which is documented in section 15.5.4.1.2 of the P1010 Reference Manual?  Yes, this is the register (SR) which indicates link status and the above mentioned bits (Link Status/Remote Fault) are used to determine SGMII link status. The meaning of Remote Fault flag is that the PHY is not hearing (code group alignment is lost) the local end (MAC) and is sending this alarm towards the local end in hope the opposite direction works. This flag indicates unstable communication. Try reading it several times since each read clears it. If it reappears, there is something really wrong or misconfigured. The PHY normally shouldn't propagate this flag from the cable side, but check with its' documentation for the case. Read the PHY status through the management interface (MDIO) to check the status of the external link (the MIIMSTAT register). How does the P1010 TBI PHY register access work? Is only the local TBI PHY accessible from a given eTSEC's MDIO register interface or does assigning all TBI PHYs the same address result in collisions? P1010 TBI PHY register are read and written through the eTSEC MDIO registers just like external PHY registers. The address of each TBI PHY is set in the memory mapped TBIPA—TBI PHY address register. The uBoot TSEC device driver assigns the address 0x1f to all three TBI PHYs in the P1010 in their respective TBIPA registers. For the internal TBI block this is controlled by the TBIPA register for each eTSEC block. The reset value of this register is 0x0, which is not a valid PHY address. Therefore this register must be initialized for each TBI (thus SGMII) port in the system. For external PHY devices the address is typically a pin strapping option, so the designer must ensure that the PHY addresses of the external phys are different from any internal TBI that may be sharing that management interface.

For P1015, does DDRCLK and PCIe (SerDes) ref clock support a spread spectrum reference? DDRCLK and PCIe (SerDes) ref clock support spread spectrum. Please note that since SGMII doesn't support spread spectrum, if SGMII is used on any SERDES lane, spread spectrum should not be applied to SERDES REF clock. What are the DDRCLK and PCIe (SerDes) reference clock spread spectrum parameters for P1015?  DDRCLK and PCIe (SerDes) reference clock are designed to work with a spread spectrum clock (+0 to –0.5% spreading at 30–33 KHz rate is allowed), assuming both ends have same reference clock. For better results, a source without significant unintended modulation should be used.

P2041 hardware spec recommends that pins EM2_MDC and EM2_MDIO must be pulled up to 1.2 V through a 180 Ω ± 1% resistor for EM2_MDC and a 330 Ω ± 1% resistor for EM2_MDIO. If these pins are not being used and there is no 1.2V on board, what should be done to these pins? EM2_MDC can be left as floating. EM2_MDIO needs to be tied low to GND or through a 2–10 kΩ resistor to GND. P2041 Hardware spec mentions that local bus address pins LA16 and LA17 must not be pulled down during power-on reset, while P204x RDB Schematics document mentions that LA17 and LA16 are pulled down optionally for CFG_SVR [1:0]. Can you please clarify? Pin LA17 and LA16 are POR pins for CFG_SVR [1:0], and they have internal weak pull-up. To get correct SVR value for P2041, pin LA17 needs external pull low. LA16 = 1 and LA17 = 1 for P2040. LA16 = 1 and LA17 = 0 for P2041. Is IEEE 1588 supported on all 5 Ethernet ports or on only 4 ports for P2040? In the Reference Manual on page 37-3, the only restriction mentioned is that 1588 is not supported for SGMII mode when using 10/100Mbps. On page 38-1, first paragraph it is mentioned that, "The 1588 timer module interfaces to up to four 10/100/1000 or one 10G Ethernet MACs (P2041 only)." Can you please clarify? IEEE 1588 is supported on all ethernet MACs in P2040. It is supported in below combinations: P2040: The 1588 timer module interfaces to up to five 10/100/1000 Ethernet MACs, providing current time, alarm, and fiper support. What are the DC specifications of IEEE1588 pins in P2040? i.e. Vih/Vil. The DC specification of 1588 would be similar to Ethernet Management Interface DC spec. You can use the table 34 and table 35 for 1588 DC given in P2040 reference manual. To which rail should the TEST_SEL pin be pulled up to disable cores two and three, the OVdd (3.3V) rail or the Vdd (1.0V) rail? You can follow below steps to disable the two cores: 1. TEST_SEL pin must be pulled high (100 kΩ to 1 kΩ) to OVDD. 2. Disable Core2 and Core3 by setting core disable register, COREDISR[CD2] and COREDISR[CD3], to 1. Also, do not tie VDD_CB to GND as it is tied to VDD_CA_PL now. What is the consumption current of POVdd for P2040? The maximum current per eFuse block is 25mA. Since we have 2 such block, maximum current is 50mA. Note that except for programming period, POVDD must be grounded at all times (zero current). Pins F24 and E23 are documented as emi2_mdio and emi2_mdc in the P2041 data sheet and as reserved in the P2040 data sheet. Can F24 (reserved on P2040, MDC on P2041) be left floating? Can E23 (reserved on P2040, MDIO on P2041) be tied low or pulled high to a voltage other than 1.2V? What is the recommended connection for these unused pins? emi2_mdc can be left as floating, but emi2_mdio needs to be tied to GND or through a 2–10 kΩ resistor to GND. For P2040, table 12 indicates that TSEC_1588_ALARM_OUT1/EC1_TXD0 should be tied low if not used. TSEC_1588_ALARM_OUT1/EC1_TXD0 is an output, does it need to be tied low or can it be left no connect? TSEC_1588_ALARM_OUT1/EC1_TXD0 is an output, it can be left no connect.

Can you give detailed information about P1011/20 clock in sources - SYSCLK, DDCCLK and eTSEC_Clock_125? Do these CLOCK source in support Spread Spectrum? What about SD_REF_CLK/SD_REF_CLK#? The spread spectrum parameters table in P1020 HW Spec is valid for SYSCLK and DDRCLK. Spread spectrum clock is not supported for EC_GTX_CLK125 (RGMII). For SERDES, SD_REF_CLK/SD_REF_CLK_B are designed to work with a spread spectrum clock (+0 to –0.5% spreading at 30–33 KHz rate is allowed), assuming both ends have same reference clock. For better results, a source without significant unintended modulation should be used. Please note that since SGMII doesn't support spread spectrum, if SGMII is used on any SERDES lane, spread spectrum should not be applied to SERDES REF Clock.

Can you please share throughput numbers for P2010 and eSDHC interface? The basic data rate is 200MB/s for SD/MMC cards using 4 parallel lanes and 416Mbps for MMC using 8 parallel lanes For P2010/P2020, is the SD device / card handled as a block device as it is for Compact flash device? If handled as block device is that implemented by internal logic or should it be implemented in sw / fw? Yes, P2010/P2020 is handled as a block device and it does single or multi-block read/writes. This is handled by internal logic and is set up via the eSDHC register set through the drivers. Does P2010/P2020 eSDHC interface support a SDHC card above 4GB? Yes, eSDHC interface does support a SDHC card above 4GB. The eMMC standard is introduced in JESD84-A44. The new features of the eMMC that eSDHC does not support, are not supported. However, the basic operation of the MMC card is supported.

The on-chip ROM code does not set up any local access windows (LAWs). Access to the CCSR address space or the L2 cache does not require a LAW. It is the user’s responsibility to set up a LAW through a control word address/data pair for the desired target address and execution starting address (which is typically in either DDR or local bus memory space). Required Configurations for SD Card/MMC Booting The configuration settings required to boot from an SD card/MMC are as follows: Ensure that cfg_rom_loc[0:3] (Boot_Rom_Loc) are driven with a value of 0b0111. Only one core can be in booting mode. If your device has multiple cores, all other cores must be in a boot hold-off mode. The CPU boot configuration input, cfg_cpux_boot, should be 0, where x is from 1 to n (n = the number of cores). Booting from the eSDHC interface can occur from different SD card slots if multiple SD card slots are designed on the board. In this case, ensure the appropriate SD card/MMC is selected For example, on the P4080 board, bit 7 of the SW8 is used to select which SD/MMC slot is used. If SW8[7] = 1, an SD card/MMC must be put to the external SD card/MMC slot (J1). TIP The polarity of the SDHC_CD signal should be active-low.  Required Configurations for EEPROM Booting The configuration settings required to boot from an EEPROM are as follows: Ensure that cfg_rom_loc[0:3] (Boot_Rom_Loc) are driven with a value of 0b0110. Only one core can be in booting mode. If your device has multiple cores, all other cores must be in a boot hold-off mode. The CPU boot configuration input, cfg_cpux_boot, should be 0, where x is from 1 to n (n = the number of cores). The eSPI chip select 0 (SPI_CS[0]) must be connected to the EEPROM that is used for booting. No other chip select can be used for booting. This is because during booting, the eSPI controller is configured to operate in master mode. Booting from the eSPI interface only works with SPI_CS[0].

Porting the most recent version of u-boot and Linux to the newest QorIQ P5 family devices can present challenges. Enabling peripherals such as UARTs, USB, flash and using the flat device tree structure for Linux requires coordination between u-boot and the kernel. The P5 family includes the Data Path Acceleration Architecture (DPAA) for network processing and a RAID engine. Furthermore, system partitioning accomplished with the hypervisor and kernel-based virtual machine allows for resource sharing and access control. In this class you will learn how these challenges are overcome, which tools are used, how to enable the memory controller to support DDR3, multiple PCI Express® and DPAA on these multicore devices, and examine other components such as the hypervisor and User Space Data Path Acceleration Architecture (USDPAA) that constitute the SDK.

P1010 has only a single pair of MCK signal, while my device has four Chip Select signals. In a scenario connecting a lot of memory devices under four CS, can the single pair of MCK really drive all of memory devices which are connected by fly-by topology on each CS? In case of P1010 (which has only one MCK), is it really practical to connect DDR3 memory devices under all of four CS? Would it be necessary to use "external CLK buffer" in such a case using four CS? P1010 was designed for low-cost systems, and as such some of the pins seen on other QorIQ devices (CKE2/3, ODT2/3) were removed to save on cost. For a single-rank, fly-by topology, only one CS would be used. If more ranks were needed, this would be addressed with stacked memories (DDR3 devices that take up to four CS signals). How does one set up the P1010 or P1014 for a 16 bit data bus size? To set the data bus width, you need to set DDR_SDRAM_CFG[DBW] bits of the register given in section 9.4.1.7, Page-9-20 of P1010RM Rev-B. Is it allowed to use four chip-selects with P1010? In my understanding, one ODT signal should be used and be controlled per chip-select? However P1010 has two MODT. P1010 is designed to use only one chip select with discrete DDR3 DRAM. This requires one CS, one ODT, and one CKE with one clock pair. Additional CS/ODT/CKE are designed for using stacked die DDR3 DRAMs. The four CS, two ODT & CKE, are useful if dual or quad stacked die discrete DDR3 DRAM were used. For the write leveling, does the P1010 use DQ[0,8,16,24] or use all DQ bit to drive status back to the DDR controller? P1010 DDR controller can support the write leveling status on any of the data bits within the data byte from a JEDEC standard DDR3 SDRAM.

The SGMII SerDes of the 3041 can operate at either 1.25G or 2.5G. Is there a register to configure this or it just depends on the clock multipliers of the SerDes PLL? As long as you select the RCW settings for SRDS_PRTCL and the DIV and RATIO settings to select the clock speed, the SerDes registers will default to the correct value based on those RCW settings. Does P3041 SerDes in XAUI mode support 10GBase-CX4 (IEEE802.3 clause54)? In other words, are SerDes XAUI receivers and transmitters capable of communication over a 15 meter 10GBase-CX4 cable? P3041 is not designed for such long distances. An appropriate 10GBASE-CX4 PHY is needed to support such distances.

Usually, when I turn on the option of "reset target on launch" CW resets CPU again while connecting to CPU. With P1015, CodeWarrior (CW) does not connect to CPU when the option is on, only when I disable the option, CW can connect to CPU. What could be the problem? . "Reset target on launch" asserts HRESET to the target, thereby resetting the hardware. In most cases this is a required step, but where you don't want to assert HRESET or where your Target Initialization (.cfg) file does this for you with the "reset 1" command, you can do without this option enabled. "P10xx-P20xxRDB_P1011_jtag.txt" JTAG Configuration file is required by 8.8 CW PA for all single-core P10xx processors. Please load the “P20xxRDB_P1011_jtag.txt" JTAG Configuration file in your USB TAP configuration panel you mentioned about. 1) Set MACCFG1[Rx_Flow] && MACCFG1[Tx_Flow] to 1 2) Set RCTRL[LFC] to 1.