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.

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

I recently pulled down SDK 1.3.2 from Freescale's SDK download site and had a chance to try and install it on a P3041DS system I have lying around. There's a lot of info in the ISO, but I thought I'd go through an initial build step by step to document what the flow is. First thing to note is that there is more than one ISO image available. I already have a Ubuntu lucid machine, that I use as a build machine. So I didn't need the virtual images. I'll need the source file - so I downloaded QorIQ_SDK_V1-3-2_SOURCE_ISO, and I am going to try this on a P3041, so I downloaded the e500mc binary. The binary isn't necessary, but it speeds up the builds significantly. When they've finished downloading, the first thing to do is mount the source ISO Within the source ISO there's an install script. I run that and let it do it's thing. Important to note that there's documentation contained within the document's directory. If you go to documents/START_HERE.html you will get html based documentation on the SDK. And, if you keep drilling down and go to documents/sdk_documentation/pdf there are some pdf documents for various features. The document QorIQ_SDK_Infocenter.pdf is a complete collection of the SDK documentation taken from the Freescale infocenter site. Once, the source is install, I do the same for the binary. Make sure you install the binary on top of the source (i.e. in the same directory). We then call the FSL poky script - which sets up the build. In this command the -m tells it what machine you're going to build to. -j indicates the number of jobs for make to spawn, and -t is how many bitbake tasks to be run in parallel. At this point I'm ready to build. I have some options for which image I want to build - I'll go with the core image, which contains some of the more common packages. So, at this point I need to make sure I'm in the build_p3041ds_release directory, and issue the command bitbake fsl-image-core which initiates the build process. When all is said and done, I can find my images in the build_p3041ds_release/tmp/demply/images directory. In my case, I have quite a few images because I've actually built the core and full images. Next, I have to grab these images and deploy them to my target.

Can you explain me the detailed description of bit functionality in field Error Capture ECC (ECE) for P1012/P1021? Following is the correct description of bits in Error Capture ECC (ECE): 0:7 -8-bit ECC for the 16 bits in beats 0 & 4 in 16-bit bus mode; should be ignored for 32-bit and 64-bit mode 8:15 -8-bit ECC for the 16 bits in beats 1 & 5 in 16-bit bus mode; should be ignored for 32-bit and 64-bit bus mode 16:23 -8-bit ECC for the 16 bits in beats 2 & 6 in 16-bit bus mode; for the 32 bits in beats 0 & 2 & 4 & 6 in 32-bit bus mode; should be ignored for 64-bit mode 24:31 -8-bit ECC for the 16 bits in beats 3 & 7 in 16-bit bus mode; for the 32 bits in beats 1 & 3 & 5 & 7 in 32-bit bus mode; should be used for every beat in 64-bit mode Bits 0:15 bits are not reserved in P1012/P1021. How can I support GPCM based Local Bus (like a boot NOR FLASH) on memory controller part with all 4 TDM ports in use due to pin mux restrictions in P1012/P1021? You can boot from GPCM as the pins as configured as eLBC signals by default. But if you intent to use them simultaneously, you cannot. You'll have to use some isolation logic on board to switch from one protocol to other. Is there a possibility to support higher density of DDR2/3 with P1021 at a later stage in design? For example JEDEC specifies 8Gbits density for DDR3. Yes, there is a possibility to support higher density devices in P1021. For a single discrete memory (single chip select), the max memory size that can be supported is 4GB. With a single chip-select we can support max of 4 GB, so with two chip-select we can support a maximum of 8 GB with two discrete devices. HW spec.

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.

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

Do you have any additional info on the USB VBUSCLMP pin. The manual says that it is the divided down Vbus. What is the divisor? The P1010 RDB schematic has a diode protecting this pin. What are the critical specifications for the diode? The diode was supposed to be used for in OTG mode. Since the USB phy in P1010 doesn't support OTG, you may choose to ignore it. The VBUS operates at 5V. But VBUSCLMP operates at 3.3V. So you should implement a potential divider to bring down 5V to 3.3V as shown in RDB. In case using on-chip USB PHY, low-speed mode is not supported at all? Or it can be supported if operating in "Host" mode? Low-speed mode (LS) is supported in Host mode but not in device mode. Can you tell me whether USB internal PHY on P1010 supports UTMI+ Level3 or not? UTMI+ Level3 is supported in P1010 Please advise how power supply to USB port should be controlled when using on-chip USB PHY. Without controlling through IFC bus (via CPLD) like P1010RDB schematic, is there other way to control for it? DRVVBUS should be used to control the external VBUS supply. By mistake this signal has been shown as a ULPI signal in P1010 RM because of which P1010RDB designer have not used it for externals VBUS control. About USBVDD1_8(J21,K21), on HWspec Table1 Notes 20 says that "20.This pin should be connected to Vss through 1μF.No need to supply power to this pin. 1.8V output may be observed on this pin during normal working conditions." Is it okay to tie J21 and K21 pins together and connect to Vss via a "single" 1uF capacitor? Or 1uF cap is required for each pin respectively? It should be okay to combine both the pins and connecting to Vss via single 1uF capacitor. If the whole USB (controller and PHY) is not used, user still needs to supply USBVDD3_3 power, Right? What is the reason?  Yes it is required to provide USBVDD3_3 even if USB controller and PHY are not used at all. This is a requirement from design to keep the logic in a sane state. If the whole USB is not used, does user need to follow power sequencing of USBVDD3_3, assuming USBVDD3_3 supply needs to be present? Following the sequence between USBVDD3_3 and other 3.3V supplies is not required. It is must to provide supply to USBVDD3_3 even if the USB PHY is not used. A suggestion, if USB PHY is not used customer can supply this pin with the same regulator which would be used to supply other 3.3V supply pins of SoC. Make sure that the ramp rate constraint is still followed for USBVDD3_3.

To enable SD interface in SPI boot on P1010RDB: 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-p1010rdb-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- P1010RDB_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-p1010rdb-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/p1010rdb.dts.dts > p1010rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and p1010rdb.dtb, the user must be able to enable SD interface on P1010RDB. 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.

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.

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

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.

Referring to P1011 IBIS model, there are models of various pin type. Could you please provide brief description on each model name shown below (Extracted from P1010 IBIS file)? 1) DDR related inputs: ddr2_drvr_18, ddr2_drvr_35, ddr2_rcvr_150, ddr2_rcvr_50, ddr2_rcvr_75, ddr2_rcvr_noterm, ddr3_drvr_17, ddr3_drvr_40, ddr3_rcvr_120, ddr3_rcvr_60, ddr3_rcvr_noterm 2) opdalg_out, pouv_out, rx_pzctl, tx_pzctl, ptrmr100_cm 3) v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb For DDR related models: Model name shows DDR type and driver impedance. For example, ddr2_drvr_18 should be used for DDR2 and 18 ohm drive strength. For opdalg_out, pouv_out, ptrmr100_cm, rx_pzctl, tx_pzctl - The pins using these models don't have any other choice of model. For v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb - These should be chosen for the interfaces with LVCMOS I/Os like eLBC. The numbers in the name depict the voltage level, e.g. v180_in_wb is applicable for 1.8V receiver. For other models - Those are not utilized directly for any pin so user can ignore them.

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.

If SPI is not being used, how should SPI_CLK and SPI_MOSI be terminated in P1020/P1011? SPI_CLK and SPI_MOSI should be pulled up, if not used.

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

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

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.

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.

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.

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.