Can the P1015 eSPI controller address 4-byte (32-bit) addressable EEPROMs in any situation? Yes, eSPI controller addresses 4-byte addressable EEPROMs in any situation. For P1015, is it possible to boot from a 4-byte EEPROM using the on-chip ROM? No. The software in the on-chip ROM only supports 16-bit addressable or 24-bit addressable EEPROMs.

Can P1022 GPIO signals drive LEDs directly? What is the output current requirement (Iol / Ioh) for GPIO signals? Yes, P1022 GPIO signals can drive LEDs directly. When GPIO is driven HIGH, to maintain a voltage of 2.4V, no more than 2mA should be drawn from the IO and conversely to maintain a 0.4V when GPIO is driven LOW no more than 2mA should be sunk into the IO. Current limiting would have to be done through external resistors. Below are the current and voltage requirements: @3.3V Input high voltage VIH 2V Input low voltage VIL 0.8V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –2 mA) VOH 2.4V Output low voltage (OVDD = min, IOL = 2 mA) VOL 0.4V @2.5V Input high voltage VIH 1.7V Input low voltage VIL 0.7V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –2 mA) VOH 1.7V Output low voltage (OVDD = min, IOL = 2 mA) VOL 0.7V @1.8V Input high voltage VIH 1.2V Input low voltage VIL 0.6V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –0.5 mA) VOH 1.35V Output low voltage (OVDD = min, IOL = 0.5 mA) VOL 0.4V Which registers are used to control the I/O states and data of GPIO1[], GPIO2[] and GPIO3[] signals when they are multiplexed as GPIO? Below registers are used to control the I/O states and data of GPIO1[], GPIO2[] and GPIO3[] signals: For GPIO1: Reg Correct Offset GPDIR : 0X000 GPODR : 0X004 GPDAT : 0X008 GPIER : 0X00C GPIMR : 0X010 GPICR : 0X014 For GPIO2: Reg Correct Offset GPDIR : 0X100 GPODR : 0X104 GPDAT : 0X108 GPIER : 0X10C GPIMR : 0X110 GPICR : 0X114 For GPIO3: Reg Correct Offset GPDIR : 0X200 GPODR : 0X204 GPDAT : 0X208 GPIER : 0X20C GPIMR : 0X210 GPICR : 0X214 P1022 Hardware Spec mentions that “USB1_STP pin must be set to the proper state during POR config”. Can you please elaborate on what could possibly be the proper setting for POR? USB1_STP is a personality pin with as yet undefined function when it is 1'b0. Please ensure that this pin is not pulled low during POR for P1022 and P1013. P1022EC revision F defines output delay time for eSDHC interface in table 52. Is there any specification regarding "output hold" time? If not, how should I consider about it? The min value of Output delay time becomes the output hold. ( Half clock period - |min khov| ) becomes the input hold for the receiver chip. How is the selection between eLBC and DIU signals done in P1022? Is it done through SPI signals? Why are SPI signals "-" in data phase of 16-bit GPCM? Selection between eLBC and DIU signals is done via PMUXCR [eLBC_DIU], and INDEPENDENTLY selection between eSPI, eLBC or eSDHC signals is done via PMUXCR[SPI_eLBC]. Thus for SPI signals user only needs to use PMUXCR[SPI_eLBC]. And for 32-bit GPCM user has to set BOTH PMUXCR[eLBC_DIU] and PMUXCR[SPI_eLBC]. Using the TDM interface in shared mode (Tx clk and sync are used for Tx and Rx), are pullups / pulldowns required for TDM_RCK and TDM_RFS in P1022? Actually the multiplexing happens at the SoC level and the selection of shared mode happens at the IP level, hence pins would not automatically revert to GPIO. It is recommended to be pulled to OVdd by 2k-10k. Can you please describe the procedure for timer soft reset and reconfiguration for P1022? Software must do the following before asserting TMR_CTRL[TMSR]: 1) Place the controller in graceful transmit stop (DMACTL[GTS]=1, wait for IEVENTGn[GTSC]=1) 2) Disable receive (MACCFG1[RX_EN]=0) Note: After setting timer soft reset (TMR_CTRL[TMSR]), software must leave the bit high for at least three 1588 reference clocks or tx_clk cycles, whichever is slower, before clearing the bit. How should I handle 2 CKSTP_OUT signals for P1022? Note 11 on Table 1 in the P1013EC states that these need a weak pullup resistor. However, Table 4-13 in the P1022RM shows that these 2 signal default to 1 (as part of cfg_rom_loc). Do these pins need pullups? The internal pull up for por_cfg pins is only for the duration when HRESET is asserted. So after POR pull up will be required. For handling this kind of a situation a tri state buffer with Enable tied to HRESET can be used. Add pull down at buffer input and pull up at buffer output. While HRESET is asserted, the pull down is visible on the buffer output. After HRESET deassertion, buffer output is tri stated and pull up on the output of buffer pulls up the CKSTP_OUT signal.

According to Recommended Operating Conditions for P5020 in P5020 HW Spec, GVDD = 1.35V/1.5V while XVDD = 1.5V/1.8V. What power should I use for the XVDD? 1.5V? 1.8V? According to P4080 specs, XVDD = GVDD. Does this mean that I should read XVDD = GVDD = 1.35V/1.5V? Please refer to the P5020 Hardware spec and you will see that for 5020 XVDD!= GVDD. Hence, we recommend you to choose the XVDD input voltage based on the requirements of the device(s) that you will connect to this interface and your power consumption requirements for this block. According to the P5020RM the bit SEC_VIO3 in HPSVSR register is set when TMP_DETECT goes low. What will happen when LP_TMP_DETECT goes low? When LP_TMP_DETECT goes low, it should set the ET1D (External Tamper 1 Detect) bit in the LPSR (LP Status Register). LP_TMP_DETECT is enabled by first setting the ET1_EN bit of the LPTDCR (LP Tamper Detect Configuration Register). Please note that this input is disabled at reset, and must be enabled by software. When enabled, LP_TMP_DETECT going low will cause the Zeroizable Master Key to be cleared. Depending on the value of the LPSV_CFG (LP Security Violation Configuration) field in the HPSVCR (HP Security Violation Control Register), LP_TMP_DETECT may cause the System Security Monitor State to go to fail. This will cause Critical Security Parameters (CSPs) in CAAM to be cleared. Note that when enabled and LP_TMP_DETECT goes low, all of this will occur asynchronously, without need of the clock. On the other hand, when TMP_DETECT goes low, that is captured synchronously and therefore requires a clock. Can you please list the power-up sequencing steps for P5020? P5020 requires that its power rails be applied in a specific sequence in order to ensure proper device operation. These requirements are as follows for power up: 1. Bring up OVDD, LVDD, BVDD, CVDD, and USB_VDD_3P3. Drive POVDD = GND. - PORESET input must be driven asserted and held during this step - IO_VSEL inputs must be driven during this step and held stable during normal operation. - USB_VDD_3P3 rise time (10% to 90%) has a minimum of 350 ms. 2. Bring up VDD_PL, VDD_CA, VDD_CB, SVDD, AVDD (cores, platform, DDR, SerDes) and USB_VDD_1P0. VDD_PL and USB_VDD_1P0 must be ramped up simultaneously. 3. Bring up GVDD and XVDD. Since USBx_VDD_1P0 and VDD_PL are both 1.0V and they have to ramp up simultaneously, would it be safe to generate both voltages from the same regulator (i.e. connected to the same voltage plane)? Or is there a specific reason to keep them separate? USBx_VDD_1P0 and VDD_PL can be powered from the same regulator for P5020 since they are both 1.0V, but they need to be filtered per the HW spec. If I don't intend to use the #LP_TMP_DETECT pin on my P5020 design, should I just connect it to 3.3V through a 4.7K resistor? Also, should I connect the VDD_LP pin directly to 3.3V? P5 features low power tamper detect support signals (LP_TMP_DETECT and VDD_LP). If this feature is not to be used on P5, LP_TMP_DETECT (AE28) and VDD_LP (AD28) can be left unconnected, but should be tied to GND to reduce noise. What is the output impedances for each of the following functional blocks of the P5020: 1) Local Bus interface utilities signals | 3.3V 2) DDR3 signal | 1.5V 3) eTSEC/10/100 signals | 2.5V 4) DUART, system control, JTAG | 3.3V 5) I2C | 3.3V 6) eSPI and SD/MMC | 3.3V? The output impedance is 45 ohm for all but DDR. For it is 40 ohm for half strength mode and 20 ohm for full strength mode. For P5020, are signals EC_RX_ER and EC2_RX_ER in MII mode? Yes, EC2_RX_ER (pin AH29) and EC1_GTX_CLK125 (pin AK34) are in MII mode. EC1_TX_CLK with EC1_GTX_CLK125 acts as the primary function and EC1_TX_CLK performs the secondary mux functionality.

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

P1016 spec says that the QUICC engine periodically polls its Rx/Tx rings and if a BD is not empty, checks the ownership flag and moves to the next step. How does the user application trigger/control the QE to start polling? For TX BD ring, (after configured) QE will periodically poll the ring and process the BD that is not empty and then move to next BD. When a BD is actually transmitted, a "transmission complete" event (and interrupt if enabled) will be generated, so the BD/Buffer can be released. For RX BD ring, (after configured) QE will pre-fetch a BD and then process the BD when data is received. When a packet (frame) is received, a "received" event (and interrupt if enabled) will be generated, so the BD/Buffer can be released/processed. If no empty BD is available during the pre-fetch, an "out-of-BD" error will be reported. Is there any suggested approach to determining the tx/rx ring buffer sizes on the peripherals that interface to the UCC? How can I decide on the ring size? The bandwidth would be 45 Mbps. The MTU on the serial interface can range up to 16k Bytes. Even if MTU could be 16K bytes, the average frame could be much smaller. Find out the average frame size and pick up a buffer size that is bit larger than the average frame size. This usually creates a good balance of efficiency between processing time and memory usage. It is much more efficient in terms of processing time to process a frame of 16K in one BD/Buffer of 16K size than in 16 BDs/Buffers of 1K size. However, if all buffers are 16K size while 90% of the frames are 1K, most memory is wasted. Generally, the ring size should be equal to the number of BD’s required to accommodate the largest possible frame size + 4 extra BDs. However, over here the bandwidth is relatively high (45M) and could be quite bursty. Hence we would suggest starting with "TWO largest possible frame size + 4 extra BDs"

Product Information on Freescale.com P1010 Product Summary Page P1010 Documentation P1010 Software and Tools P1010 Parametrics P1010 Training Frequently Asked Questions (FAQ) P1010/P1014 USB Specific FAQs   P1010/P1014 Ethernet (eTSEC) Specific FAQs   P1010/P1014 DDR Specific FAQs   Tips and Tricks Enabling SD Interface on P1010 Reference Design Board   Hardware and Design Layout/Guidelines for P1010 DDR3 SRAM Interfaces   Other Resources CodeWarrior for Power Architecture Processors Optimizing CodeWarrior on Power Architecture Tips for your brand new CodeWarrior TAP! (Power Architecture)

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.