Do we have an internal pull up on LA20 pin in P1015E? According to hardware spec for P1015/P1024, 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 P1015E (80ED0211) OR P1011E (80ED0011)? According to hardware spec for P1015/P1024, 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.

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.

Should I tie "UART_RTS_B01" to "0" while configuring signals sampled at reset in P1011? If eTSEC1 is required in RGMII mode then the POR configuration pins should be set to {EC_MDC,TSEC1_TXD0,TSEC1_TXD7} = {010} and if eTSEC3 is required in RGMII mode then {UART_RTS0,UART_RTS1,TSEC_1588_ALARM_OUT2} = {101} As all above signals default POR value is 1, you have to specify the signals that should be externally pull-down through a resistor when ever logic zero is required

For P1013/22, what is the maximum bit rate clock for SSI? Is it really 12.285MHz or can it be run up to platform clock / 8? Maximum bit rate clock for SSI is as per hardware spec i.e. 12.285MHz. This is the maximum speed at which the SSI IP is guaranteed to work. From a system perspective it is possible to clock it at a higher speed, but for P1013 that is not supported. If platform clock is 400MHz, please use appropriate values of DIV2, PSR and PM to ensure that the bit rate clock for SSI does not exceed 12.285MHz. Can you please confirm that the P1022 ethernet input clock is actually 2 clocks: one for each eTSEC, with name TSECn_GTX_CLK125/GPIOm? The p1022 ballmap spreadsheet only shows one gtx_clk125 pin (like the 8536), but the current data sheet (Revision E) indicates there are two. The ball map shows only primary functions of a pin. By default both the eTSECs would share the same clock i.e TSEC1_GTX_CLK125 @Y29. If required, user can opt to use separate clock for eTSEC2 . The separate clock for eTSEC2 is multiplexed with TSEC_1588_TRIG_IN1@AH27 and can be configured using PMUXCR[6:7]. The SD card spec requires SD clock to supply for at least 74 clock cycles. On the other hand, the eSDHC controller in P1022 supplies about 13 SD clock cycles (with 180 degrees phase shift) at power up. Will SD card have any reliability issue by this fewer clock cycles than what is required by spec? No, SD card should not have the reliability issue. 74 clocks can be supplied by setting SYSCTL [INITA]. The 180 degree phase shift will not affect card or eSDHC IP block's operation. The phase shift is due to the synchronizer.

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

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

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.

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