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.
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.
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
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 P5010 board, bit 7 of the SW8 is used to select which SD/MMC slot is used. If SW8 = 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) 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.