I don’t use SDHC, and we use SPI at 2.5V (CVDD=2.5V). In this case for P4080 unused SDHC pins are pulled up to 2.5V. If I want to maintain compatibility with P4040, what happens when unused SDHC pins (SDHC_DATA [0-3], SDHC_CMD) in P4040 are pulled up to 2.5V instead of 3.3V? As long as the pullup on these pins satisfies the minimum Vih of 2.0 V for a 3.3V input then this would be ok. Alternative is to pull to ground. I want to lower the CPU power consumption with make CPU frequency from 1.2GHz to 1 GHz or 800 MHz for P4080 hardware. When P4080 core is configured to be 1GHZ/ 800 MHz, what is the core’s power consumption? If you disable L2 cache, you can use 47mW/100MHz per core for lower bins. If L2 is not disabled, then you need to use 65mW/100MHz per core for the lower bin. If I don’t use SDHC, how should I connect the SDHC_DATA and SDHC_CLK? SDHC is output signal and you can leave as NC. It shouldn't matter to either pull-up or pull-down for unused SDHC interfaces. In Freescale P4080_DS schematics, the "HRST" button is connected to the LRST_B signal which is routed to the FPGA. What logic is applied to the LRST_B signal inside the FPGA, and what is the FPGA output signal connected to on the CPU? LRST is one of the Reset sources that is coming from the Pushbutton. It will cause: CPU_PORESET CPU_TRST And Peripheral_reset (PHY_RST_B, GEN_RST_B, SGMII_XAUI_SLOT_RST_B) Does access to CCSR & DCSR registers require CoreNet usage in P4080? Can a SEU single-bit error in any CoreNet register prevent further reading from internal config registers? Yes, CCSR/DCSR accesses go through CoreNet. There is no ECC on CCSR internal registers so there is no automatic scrubbing or repair that is possible. So such prevention is not possible. I have NOR Flash, NAND Flash, NVRAM and CPLD connected on eLBC with data buffer in between. All devices are in high impedance when not selected. Should the OE of data buffer be connected to GND directly or by using “AND” gate with CS0, CS1…CSn as the OE? It should be “AND”ed with all used CSn to generate the OE. This can prevent any potential data bus conflict. I do not use Secure Boot feature in my P4080 design. What should I do with Vdd_LP pin? If Secure Boot feature is not to be used, VDD_LP can be left unconnected, but should be tied to GND to reduce noise.

Usually, when I turn on the option of "reset target on launch" CW resets CPU again while connecting to CPU. With P4040, 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.

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 P2040 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].

Do we have an internal pull up on LA20 pin in P4040E? According to hardware spec for P4040, LA20 pin is a reset configuration pin. It has a weak internal pull-up P-FET which is enabled only when the processor is in the reset state. This pull-up is designed such that it can be overpowered by an external 4.7-kΩ pull-down resistor. Assuming that I did not include a pull up or pull down and assuming no device was asserting LA20--what state do we sample at POR? If LA20 is left floating at POR, would one read the SVR for P4040E (80ED0211) OR P1011E (80ED0011)? According to hardware spec for P4040, LA20 pin "must be pulled down with a 4.7K resistor". So the default in case that a design doesn't include an external pull (as required by the spec) is for it to sample as a '1'. Leaving the pin NC (floating) at POR is effectively an out of spec configuration.

For P2010/P2020, is any way that the CPU can read and write the full 72-bit wide DDR memory bus, bypassing the ECC logic? I want to know if the memory controller can be configured for the 72-bit wide DDR memory bus to bypass the ECC logic. It is not possible to bypass the ECC and read/write using full 72-bit wide bus. The controller uses the last byte lane to generate ECC info and cannot be bypassed. For P2010/P2020 DDR SDRAM refresh, can you please advise how to "exactly" calculate the appropriate value of [REFINT] if such worst case scenario in which refresh command issue timing is postponed is taken into account? The refresh interval should be set as high as allowable by the DRAM specifications. This should be calculated by using tREFI in the DRAM specifications, which may depend upon the operating temperature of the DRAM. In addition, to allow a memory transaction in progress to be completed when the refresh interval is reached and not violating the device refresh period, set the REFINT value to a value less than that calculated by using tREFI. The value selected for REFINT could be larger than tREFI if the DDR_SDRAM_CFG[NUM_PR] has a value higher than 1. To calculate the max possible value when DDR_SDRAM_CFG[NUM_PR] is higher than 1, use the following formula: (tREFI/clk period) x (NUM_PR) = REFINT A timing tDISKEW (skew between MDQS and MDQ) is depicted in DDR2 and DDR3 SDRAM Interface Input Timing Diagram in P2010/P2020 Hardware spec. For measuring tDISKEW, please instruct me from which point of the MDQS waveform and to which point of MDQ waveform should be measured? For measuring MDQS, it should be at the cross point. For case of MDQ it is derated to the VREF. Why does MCK to MDQS Skew tDDKHMH has such a high value of +/-525ps for DDR3 800M data rate for P2010/P2020? I am afraid that write-leveling can NOT remove all internal MCK to MDQS skew from tDDKHMH. Can you please let me know how much internal skew will be removed after write-leveling? tDDKHMH value of +/-525ps for P2010 part is a conservative value in the HW spec. For DDR3 with write leveling enabled, this AC timing parameter would be a non-factor.

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.

To enable SD interface in SPI boot on p1024RDB: 1. Perform the following updates in u-boot a) Modify pmuxcr to enable SD bus in case of SPI boot b) Update the corresponding static mux implementation in u-boot 2. Perform the following updates in Linux a) Disable IFC from device tree and kernel defconfig The patch details to enable SD interface are given below. A zip file, AN4336SW.zip, containing the patches for u-boot and Linux accompanies this application note. The file can be downloaded from [1]. U-Boot   Extract the u-boot code from the QorIQ SDK 1.0.1 iso   Apply the patch, u-boot-p1024rdb-enabling-sd-in-spi-boot.patch   Compile the u-boot using "make" command for SPI Flash    make ARCH=powerpc   CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- p1024RDB_SPIFLASH   Use the boot_format utility to generate the spiimage. For more information, see SDK manual.   Update the SPI Flash with the above built spiimage Linux Extract the Linux source code from QorIQ SDK 1.0.1 iso Apply the patch, linux-p1024rdb-enabling-sd-in-spi-boot.patch Compile Linux using make command #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnuarch/  powerpc/configs/qoriq_sdk_nonsmp_defconfig  #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- Compile the dts ./sripts/dtc/dtc -f -I dts -O dtb -R 8 -S 0x3000  arc/powerpc/boot/dts/p1024rdb.dts.dts > p1024rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and p1024rdb.dtb, the user must be able to enable SD interface on P1024RDB. NOTE The above-mentioned changes must be done only when the user specifically requires the SD interface using SPI boot. For all other boot methods, these patches must not be used.

Does the PCIe controller go to D3 hot state automatically if the user does not configure any registers? Should the external device be in D3 hot state explicitly before P1022 goes to sleep mode? PCIe controller will not go to D3 hot state automatically. Software has to write Powerstate field of PMCSR register. If the downstream component is in D3 hot state, then permissible states for Upstream component are D0-D3hot. Refer Section 5.3.2 of Base specification 1.0a The Bus states are L1 or L2/L3 Ready if the power is going to be removed. The procedure for entry into these states is described in Section 5.3.2.1 and 5.3.2.3 What internal interrupt numbers are assigned to PCIe1 through PCIe3 in P1022? All PCIe interrupts in P1022 are error interrupts and are ORed with other error interrupts to result in "Error" which is mapped to #0 of the OPIC.

To boot to Linux from an SD card/MMC, it is assumed that all following configuration files for booting are in the same directory under a Linux machine: RAM-based U-Boot image (u-boot.bin) Kernel image (uImage) Flat device tree file (mpc8536ds.dtb) Root file syste (rootfs.ext2.gz.uboot) Latest boot-format Perform the following sequence of tasks to boot to Linux from an SD card/MMC; note that the MPC8536DS system is used as an example: Plug an empty SD card/MMC into the Linux machine. Use Linux command fdisk to create two partitions: one 512-Mbyte FAT16 and one ext2/ext3 with remainder of the available disk size. Use Linux command mkfs to create the FAT file system for the first partition. Use mkfs to create the ext2/ext3 file system for the second partitions Follow the procedure for putting a Boot Image on an SD Card/MMC. Use boot_format to put the boot image on the card. Put the root file system (rootfs.ext2.gz.uboot) on the second partition using the following commands:    — dd if=rootfs.ext2.gz.uboot of=rootfs.gz bs=64 skip=64    — gunzip rootfs.gz    — dd if=rootfs of=/dev/sdc2 Mount the FAT system (mount /dev/sdc1 /mnt/tmp). Copy the kernel file (cp uImage /mnt/tmp) and flat device tree file (cp mpc8536ds.dtb /mnt/tmp) to the root directory of the FAT system.   TIP After above step is performed properly, all the required files and information are on the SD card/MMC. Unmount the FAT system (umount /mnt/tmp). If a Linux desk PC is used: a) Unplug the SD card/MMC from this PC. b) Plug the SD card/MMC into a system that is going to boot from this card.  

To enable SD interface in SPI boot on p1023RDB: 1. Perform the following updates in u-boot a) Modify pmuxcr to enable SD bus in case of SPI boot b) Update the corresponding static mux implementation in u-boot 2. Perform the following updates in Linux a) Disable IFC from device tree and kernel defconfig The patch details to enable SD interface are given below. A zip file, AN4336SW.zip, containing the patches for u-boot and Linux accompanies this application note. The file can be downloaded from [1]. U-Boot   Extract the u-boot code from the QorIQ SDK 1.0.1 iso   Apply the patch, u-boot-p1023rdb-enabling-sd-in-spi-boot.patch   Compile the u-boot using "make" command for SPI Flash    make ARCH=powerpc   CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- p1023RDB_SPIFLASH   Use the boot_format utility to generate the spiimage. For more information, see SDK manual.   Update the SPI Flash with the above built spiimage Linux Extract the Linux source code from QorIQ SDK 1.0.1 iso Apply the patch, linux-p1023rdb-enabling-sd-in-spi-boot.patch Compile Linux using make command #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnuarch/  powerpc/configs/qoriq_sdk_nonsmp_defconfig  #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- Compile the dts ./sripts/dtc/dtc -f -I dts -O dtb -R 8 -S 0x3000  arc/powerpc/boot/dts/p1023rdb.dts.dts > p1023rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and p1023rdb.dtb, the user must be able to enable SD interface on p1023RDB. NOTE The above-mentioned changes must be done only when the user specifically requires the SD interface using SPI boot. For all other boot methods, these patches must not be used.

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 P1022 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].  

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

Table of Contents Product Information on Freescale.com P1020 Product Summary Page P1020 Documentation P1020 Software and Tools P1020 Parametrics P1020 Training Frequently Asked Questions (FAQ) P1020/P1011 Clocking Specific FAQs P1020/P1011 COP/JTAG Specific FAQs P1020/P1011 Ethernet (eTSEC) Specific FAQs P1020/P1011 Hardware Specifications/Reference Manual Specific FAQs P1020/P1011 IBIS Specific FAQs P1020/P1011 Local Bus Specific FAQs P1020/P1011 Memory Controller Specific FAQs P1020/P1011 Reset Configuration Specific FAQs P1020/P1011 SPI Specific FAQs Tips & Tricks Booting P1020/P1011 from On-Chip ROM (eSDHC or eSPI) Booting to Linux from an SD Card/MMC for P1020/P1011 Getting Started Getting Started Guide for P1020/P1011 Discussions P1020 Processor QorIQ P1 Devices Other Resources CodeWarrior for Power Architecture Processors Optimizing CodeWarrior on Power Architecture Tips for your brand new CodeWarrior TAP! (Power Architecture)

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

Does P2040 dTSEC support 1000Base-X with an opposite 1000Base-X device like FPGA? I can see it is supported in P3041 Reference Manual (RM) but there is no description regarding TBI registers in P2040RM RM revE. Yes, P2040 dTSEC support 1000Base-X with an opposite 1000Base-X device using the same TBI mode as P3041. Does P2041 support pre-emphasis on SGMII ports? If yes, please send me the reference. There is no requirement of pre-emphasis in the SGMII protocol. However, Lynx5G based products such as Lynx20/ P2041 support the pre-emphasis in the SGMII protocol. The following are the settings:- 3dB : tx_ratio_post1q[2:0] = 100, tx_eq_type[1:0] = 01, tx_sgn_post1q = 1 6dB : tx_ratio_post1q[2:0] = 110, tx_eq_type[1:0] = 01, tx_sgn_post1q = 1 Please note Lynx3G based products do not support the pre-emphasis in the SGMII protocol. 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 enable SD interface in SPI boot on P2020RDB: 1. Perform the following updates in u-boot a) Modify pmuxcr to enable SD bus in case of SPI boot b) Update the corresponding static mux implementation in u-boot 2. Perform the following updates in Linux a) Disable IFC from device tree and kernel defconfig The patch details to enable SD interface are given below. A zip file, AN4336SW.zip, containing the patches for u-boot and Linux accompanies this application note. The file can be downloaded from [1]. U-Boot   Extract the u-boot code from the QorIQ SDK 1.0.1 iso   Apply the patch, u-boot-P2020rdb-enabling-sd-in-spi-boot.patch   Compile the u-boot using "make" command for SPI Flash    make ARCH=powerpc   CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- P2020RDB_SPIFLASH   Use the boot_format utility to generate the spiimage. For more information, see SDK manual.   Update the SPI Flash with the above built spiimage Linux Extract the Linux source code from QorIQ SDK 1.0.1 iso Apply the patch, linux-P2020rdb-enabling-sd-in-spi-boot.patch Compile Linux using make command #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnuarch/  powerpc/configs/qoriq_sdk_nonsmp_defconfig  #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- Compile the dts ./sripts/dtc/dtc -f -I dts -O dtb -R 8 -S 0x3000  arc/powerpc/boot/dts/P2020rdb.dts.dts > P2020rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and P2020rdb.dtb, the user must be able to enable SD interface on P2020RDB. NOTE The above-mentioned changes must be done only when the user specifically requires the SD interface using SPI boot. For all other boot methods, these patches must not be used.

I don’t use SDHC, and we use SPI at 2.5V (CVDD=2.5V). In this case for P3041 unused SDHC pins are pulled up to 2.5V. If I want to maintain compatibility with P4040, what happens when unused SDHC pins (SDHC_DATA [0-3], SDHC_CMD) in P4040 are pulled up to 2.5V instead of 3.3V? As long as the pullup on these pins satisfies the minimum Vih of 2.0 V for a 3.3V input then this would be ok. Alternative is to pull to ground. I want to lower the CPU power consumption with make CPU frequency from 1.2GHz to 1 GHz or 800 MHz for P1031 hardware. When P3041core is configured to be 1GHZ/ 800 MHz, what is the core’s power consumption? If you disable L2 cache, you can use 47mW/100MHz per core for lower bins. If L2 is not disabled, then you need to use 65mW/100MHz per core for the lower bin. If I don’t use SDHC, how should I connect the SDHC_DATA and SDHC_CLK? SDHC is output signal and you can leave as NC. It shouldn't matter to either pull-up or pull-down for unused SDHC interfaces. In Freescale P3041_DS schematics, the "HRST" button is connected to the LRST_B signal which is routed to the FPGA. What logic is applied to the LRST_B signal inside the FPGA, and what is the FPGA output signal connected to on the CPU? LRST is one of the Reset sources that is coming from the Pushbutton. It will cause: CPU_PORESET CPU_TRST And Peripheral_reset (PHY_RST_B, GEN_RST_B, SGMII_XAUI_SLOT_RST_B) I do not use Secure Boot feature in my P3014 design. What should I do with Vdd_LP pin? If Secure Boot feature is not to be used, VDD_LP can be left unconnected, but should be tied to GND to reduce noise. I have Nor Flash, Nand Flash, NVRAM and CPLD connected on eLBC with data buffer in between. All devices are in high impedance when not selected. Should the OE of data buffer be connected to GND directly or by using “AND” gate with CS0, CS1…CSn as the OE? It should be “AND”ed with all used CSn to generate the OE. This can prevent any potential data bus conflict. Does access to CCSR & DCSR registers require CoreNet usage in P3041? Can a SEU single-bit error in any CoreNet register prevent further reading from internal config registers? Yes, CCSR/DCSR accesses go through CoreNet. There is no ECC on CCSR internal registers so there is no automatic scrubbing or repair that is possible. So such prevention is not possible.

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.

If boot sequencer is used with eSPI FLASH, can I enable it after boot sequencing is over in P1021? If I place config in eSPI FLASH, will it just overwrite whatever boot sequencer has done? Boot sequencer serves a different purpose. It runs before the core starts. Booting from an eSPI flash, the core has to be configured correctly and starts the Boot-ROM code on-chip. It runs after the boot sequencer if any. So you can enable eSPI FLASH if boot sequencer has done all the necessary configurations. Also, the configurations in an eSPI FLASH will overwrite any memory mapped registers. I want to run P1021 SPI in "SPI slave" mode. How should I configure SPI_SEL function for QE pin PB20? When you configure pins CPPARBx[SELn]=11 and CPDIRxB[DIRn] = 11, it will configure PB20 as SPI_SEL function.

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.