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

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

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

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.

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.

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.

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

When the frames on a FQ are ready to be processed, the FQ is enqueued onto a work queue(WQ). WQ are organized into channels. A channel is a fixed, hardware-defined association of 8 work queues, also though of “priority work queues”. There are two types of WQ channels defined in QMAN: Dedicated channels, which are always serviced by a single entity. Pool channels, which are serviced by pool of like entities, such as a pool of processor cores. This document describes the basic concept regarding dedicated and pool channels, how to use dedicated and pool channels in flow order Preservation scenarios, work queue channel assignment, dedicated and pool channel used in Linux Kernel and how to modify PPAC and USDPAA QMAN driver to using dedicated channels in USDPAA applications. 1. Basic Concept of QMAN Channels 2. Dedicated Channel Used in Flow Order Preservation Scenario 3. Pool Channel Used in Order Preservation with Hold Active Scheduling 4. Work Queue Channel Assignment 5. Dedicated and Pool Channels Usage in Linux Kernel 6. Using Dedicated Channel in USDPAA

      A shared-MAC device is one that can be used from two Linux and/or USDPAA partitions. Shared-MAC net device can be used in two scenarios, two or more Linux separate partitions under control of hypervisor(topaz), one Linux and one USDPAA running in the same partition.       1. DPAA Ethernet Driver Types       2. BMan Driver for shared-MAC and MAC-less port       3. QMan Driver for shared-MAC and MAC-less port       4. Running  Shared-MAC between USDPAA and Linux

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.

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)

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)

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.

The JTAG IDCODE for P5010 is 0x0020c01d. What's the IDCODE for the P5010? Below are the JTAG IDCODES for P5010 and P5020: P5010: 0x0020_D_01D P5020: 0x0020_C_01D For P5020, COP header has COP_CHKSTP_OUT and COP_CHKSTP_IN connections. Are they actually driven by the run control device (USB TAP)? If I leave the pins appropriately terminated then I do not need to route them to an adapter cable, right? The USBtap does not use these signals at all. It's okay to leave these pins on the cop header as a NC. You do not need to route them to an adapter cable. For P5020, VDD_SENSE on COP header uses 10-Ohm to OVDD while VIO VSense on Aurora header uses 1K pull-up to OVDD. If I use the 1K Ohm then it will be okay for the USB TAP, right? Yes, this is okay for the USB TAP. They definitely use the VDD_SENSE pin, but they draw very little current, so there's almost no voltage drop. COP header has a COP_SRESET# connection on pin #11 which connects to HRESET# on the P5020. The Aurora header does not have this connection. Is it actually necessary for COP header to drive HRESET# on the P5020 device? The USB TAP does not use the /SRESET pin on the COP header at all. You don't need to route this to the COP header also. You can leave it NC.

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.

If I don’t use the USB interface in the 4080, can I leave USBx_VDD_3P3 and USBx_VDD_1P0 pins not connected? In P4040 they are reserve with note do not connect. Can they be connected to 3.3V and 1.0V respectively? USB_VDD_1P0 must be tied to 1V or the platform voltage (based on whatever the SOC core digital power supply is). USB_VDD_3P3 can be left floating. If I don’t use USB, is it safe to leave USBx_IBIAS_REXT and USBx_VDD_1P8_DECAP unconnected? If USB is not to be used at all, keep the following USB signals floating : USB1_IBIAS_REXT, USB2_IBIAS_REXT, USB1_VDD_1P8_DECAP and USB2_VDD_1P8_DECAP, USB1_VDD_3P3, USB2_VDD_3P3.

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.

The SGMII SerDes of the 4080 can operate at either 1.25G or 2.5G. Is there a register to configure this or it just depends on the clock multipliers of the SerDes PLL? As long as you select the RCW settings for SRDS_PRTCL and the DIV and RATIO settings to select the clock speed, the SerDes registers will default to the correct value based on those RCW settings. Does P4080 SerDes in XAUI mode support 10GBase-CX4 (IEEE802.3 clause54)? In other words, are SerDes XAUI receivers and transmitters capable of communication over a 15 meter 10GBase-CX4 cable? P4080 is not designed for such long distances. An appropriate 10GBASE-CX4 PHY is needed to support such distances.