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.

Please confirm that a PCIe lane on the P1023 can be enabled after POR (configured off in h/w but turned on in s/w). If so how this would be implemented? It is possible to control PCIe Lane turned on through s/w. You can control this through SRDSCR2 [0:7]. Through this control you can power -up or power- down individual lanes separately What is the difference between two strap options for PCIe ports - 0b00 or 0b11? In terms of PCIe, options 0b00 and 0b11 are redundant, but in terms of SGMII, they are different 0b00 - 2 lanes are for PCIe; the remaining 2 lanes are powered down 0b11 - 2 lanes are for PCIe; the remaining 2 lanes are for SGMII 0b01 - 3 lanes are for PCIe; the remaining 1 lane is powered down 0b10 - 3 lanes are for PCIe; the remaining 1 lane is for SGMII When SGMII is not used, the corresponding lane(s) should be powered down to save power.

I assume that 50mV specification for P5020 includes all kinds of voltage variations, such as DC regulation, steady-state ripple and transients. Is this correct? I would like to know the maximum current step and slew rate (A/us) for P5020? That is correct. The 40mV applies to all kinds of voltage variations. Is dynamic power management such as frequency stepping supported in P5020? P5020 supports various power management modes. When less drastic frequency changes are desired, software can switch the CPU to a slower speed PLL, such as 1 GHz versus 1.5 GHz. Many cores could be switched to a slower PLL during periods of light traffic, with the ability to immediately return those cores to the full rate PLL should traffic suddenly increase. The more traditional Power Architecture single core power management modes (Core Doze, Core Nap, Core Sleep) are also available in the e5500. What is the estimated maximum current draw (amps) on the P5020 USBx_VDD_1P0 pin? For P5020, maximum USBx_VDD_1P0 pin current is 10mA per pin (phy). Does 10G interface support the magic packet wake-on-LAN feature? The dTSEC chapter clearly states that the dTSEC does, but the 10G chapter in the P5020 RM makes no mention of it. The 10G interface does not support the magic packet wake-on-LAN feature.

I would like to know if output signals of blocks which are not clocked during sleep mode are driven or not. For example, are eTSEC2 RGMII signals driven during sleep mode? Yes, they would be driven but there would be no activity on them. Please note that this is for "sleep" mode NOT "deep sleep" P1022 supports “Wake on LAN” from the Deep Sleep. If TSEC operates via SGMII it needs for SVDD,XVDD, SVDD2,VDD2, SDAVDD and SDAVDD2 (SGMII power). All these powers are switchable in the Deep Sleep. Can we leave these rails powered in the Deep Sleep and expect that the P1022 will support “Wake on LAN” via SGMII? Serdes is powered down during deep sleep, so Wake up on LAN is not supported for Deep Sleep in SGMII mode. Wake on LAN is supported for RGMII. Please note only eTSEC1 supports this feature. (Assuming eSTEC1 and eTSEC2 as the nomenclature) Are there any pull-downs for signals POWER_EN and ASLEEP on the P1022 board? Is BVDD switched off using POWER_EN? LOE has pull down via 4.7k ohms resistor as POR config. LWE has neither pull-up nor pull-down. Yes, BVdd is switched off using POWER_EN. What is the difference between P1022 and P1013 in terms of power dissipation and power management? In P1013 the Power supply pins for second core do need to be tied to their respective levels (although you can miss off the PLL filter for the unused core supply). So even when the second core is not used, it is powered. With TEST_SEL tied low (tie directly to ground) the second core is disabled and there should be no chance of accidental execution of code by second core.

P2010/P2020 H/W spec describes that Max SYSCLK frequency is 100MHz. Generically when user inputs 100MHz clock, actual clock speed become more faster. I think P2010/P2020 has enough margin for faster SYSCLK as long as I use up to 100MHz oscillator. Is my understanding correct? Yes, your understanding is correct. As long as you use 100MHz oscillator it should be fine.

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.

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 P1020 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

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.

To enable SD interface in SPI boot on P1025RDB: 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-p1025rdb-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- p1025RDB_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-p1025rdb-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/p1025rdb.dts.dts > p1025rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and p1025rdb.dtb, the user must be able to enable SD interface on p1025RDB. 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 would like to put pull-down on TRST- signal rather than using a gate to tie to HRESET- (and then switch the gate out for debug). What value of pull-down should I choose so that it will not interfere with USBTap JTAG operation. Does TRST- have an internal pullup? The TRST is active low signal in P1020, thus pulling it down will always keep JTAG in Reset position. For the proper working of SoC, The system must assert HRESET and TRST (Both active low), simultaneously. If there is no specific use-case which needs JTAG always in reset, then it is better to gate it with HRESET.

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 P1020 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 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 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

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

Can a spread spectrum clock be used for the 66.66 Mhz DDR clock of the P1023? If so what percentage spread is allowed and what modulation frequency? Yes, a spread spectrum clock can be used for 66.66 Mhz DDR clock. Please refer to below table for details: Spread Spectrum Clock Source Recommendations Parameter Min Max Unit Frequency modulation — 60 kHz Frequency spread — 1.0  % For P1023 package, which is the GTX clock pin for TSEC1 and TSEC2? According to the P1023 ballmap, V21 is the GTX clock pin of TSEC1 and T19 is the GTX clock pin of TSEC2.

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.

How can I ensure that Ethernet flow control is turned on through the register setting in P1015? Please try the below steps to enable Ethernet flow control: 1) Set MACCFG1[Rx_Flow] && MACCFG1[Tx_Flow] to 1 2) Set RCTRL[LFC] to 1. Setting the flow control bits Rx_Flow and Tx_Flow means that the MAC can detect and act on PAUSE flow control frames, receive and transmit respectively. There are two ways you can confirm or see them in action: 1) Software sending a PAUSE frame through TCTRL[TFC_PAUSE] 2) Changing some hidden FIFO threshold registers, such that the FIFO is about to overflow and that triggers eTSEC logic to send a PAUSE.