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 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 . 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.
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
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.
If I select a SerDes Mux config using a PCIe controller on 2 lanes, is it possible to use just one lane, although it is configured to two lanes PCIe? Do you have any advice for such configuration? A13. Yes, it is possible to use just one lane while selecting SerDes Mux config using a PCIe controller. From the P2040 SERDES options ECI will be setting PCIe2 to use lanes E & F. If you have them pinned out to x2 connector then it will automatically train down to x1 if a x1 device is inserted. If you don't want to use lane F then power lane F down during reset and set SRDSPCCR0[PEX2_CFG] to x1. What is the function of TRSTDIR bit found in Table 3-26/B1GCRA1–B1GCRJ1 Field Descriptions B1GCRA1 [TRSTDIR] in P2041 RM? It controls Lynx Tx lane reset function for multi-lane protocols. For multi-lane protocols where the lanes are from left to right (PEX, XAUI), it should be set to 1 while for protocols where the lanes are from right to left (SRIO, Aurora), it should be set to 0. For single-lane protocols (SGMII, SATA) it doesn’t matter. It is paired with BnGCRm0[1STLANE], which determines the master source clock lane for a multi-lane protocol (must always be =1 for nominal lane 0 for the protocol, e.g. lane A for PEX on lanes A-D, and =0 for all other lanes).
For P2041, if USB1 and USB2 ports are not implemented, what to do with the unused USB ports ie tie them to ground, 3.3V or leave them 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, USB2_VDD_1P8_DECAP, USB1_VDD_3P3 and USB2_VDD_3P3. The following signals should be pulled-down: USB1_VBUS_CLMP, USB2_VBUS_CLMP and USB_CLKIN. Also, pins USB_VDD_1P0 and USB2_VDD_1P0 must be tied to 1V or the platform voltage (whatever is the SOC core digital power supply) If USB_VDD_3P3 must be connected to 3.3V, will the power sequence be same as other 3.3V (OVDD) (no special power sequence for USB_VDD_3P3)? Even if PHY is not used, USB_VDD_1P0 must be tied to 1V or the platform voltage (whatever is the SOC core digital power supply), other pins can be left floating: USB1_IBIAS_REXT, USB2_IBIAS_REXT, USB1_VDD_1P8_DECAP and USB2_VDD_1P8_DECAP, USB1_VDD_3P3, USB2_VDD_3P3. If signals USB_VDD_3P3 and USB_VDD_1P8 are left floating, there is no need to take of power sequencing on these pins, only USB_VDD_1P0 must be a part of standard power sequencing requirements. If signals USB_VDD_3P3 and USB_VDD_1P8 are used (i.e. not left floating), power sequencing is to be done as under: Follow a minimum ramp time of 350us on USB_VDD_3P3(most regulators would give a 350us ramp time) and standard power sequencing on USB_VDD_1P0,USB_VDD_3P3. USB_VDD_1P8_DECAP would only have 1uF capacitor and is automatically tolerant of sequencing on rest of the supplies are sequenced properly. Also based on silicon validation: There is no power down sequencing to be followed on the PHY. There requirements were added as a backup strategy in case the new regulator in the IP had a problem. We have tested this regulator, so no power down sequencing requirements is needed. There is no need to supply any power to USB_VDD_1P8_DECAP, as the circuit is working fine.
I wanted to choose boot location for P2040. Does P2040 supports GPCM 16 bit NOR boot? Yes, P2040 supports GPCM 16 bit NOR boot. It can be done by configuring 4 bits (bit 192 to 195) of RCW source location to 1101. If I use NOR FLASH as boot device, can NOR FLASH be used as RCW storage device? Do I need an extra SPI flash is required or not? Yes, you can use NOR flash and the options are 0x1100 and 0x1101 (listed in the table 4-26 in P2040 Reference Manual). Does P2040 support to boot from SPI flash? Yes, P2040 can boot from SPI flash. But it is different from booting from NOR flash. One eSPI pre-bootloader is required.
Does P2040 dTSEC support 1000Base-X with an opposite 1000Base-X device like FPGA? I can see it is supported in P3041 Reference Manual (RM) but there is no description regarding TBI registers in P2040RM RM revE. Yes, P2040 dTSEC support 1000Base-X with an opposite 1000Base-X device using the same TBI mode as P3041. Does P2041 support pre-emphasis on SGMII ports? If yes, please send me the reference. There is no requirement of pre-emphasis in the SGMII protocol. However, Lynx5G based products such as Lynx20/ P2041 support the pre-emphasis in the SGMII protocol. The following are the settings:- 3dB : tx_ratio_post1q[2:0] = 100, tx_eq_type[1:0] = 01, tx_sgn_post1q = 1 6dB : tx_ratio_post1q[2:0] = 110, tx_eq_type[1:0] = 01, tx_sgn_post1q = 1 Please note Lynx3G based products do not support the pre-emphasis in the SGMII protocol. Is IEEE 1588 supported on all 5 Ethernet ports or on only 4 ports for P2040? In the Reference Manual on page 37-3, the only restriction mentioned is that 1588 is not supported for SGMII mode when using 10/100Mbps. On page 38-1, first paragraph it is mentioned that, "The 1588 timer module interfaces to up to four 10/100/1000 or one 10G Ethernet MACs (P2041 only)." Can you please clarify? IEEE 1588 is supported on all ethernet MACs in P2040. It is supported in below combinations: P2040: The 1588 timer module interfaces to up to five 10/100/1000 Ethernet MACs, providing current time, alarm, and fiper support. What are the DC specifications of IEEE1588 pins in P2040? i.e. Vih/Vil. The DC specification of 1588 would be similar to Ethernet Management Interface DC spec. You can use the table 34 and table 35 for 1588 DC given in P2040 reference manual.
Can you please give more details about 32 address signals for the eLBC implementation on P2040? Below is a detailed explanation of 32 address signals for the eLBC implementation on P2040: LAD[0:15] - these are multiplexed address/data signals that need to be externally latched using the LALE signal. LA[16:31] - these are dedicated address signals. LAD is the most significant address signal and LA is the least significant address signal. Can the Local Bus FCM support two, 2GByte (16Gbit) NAND devices, if they are the appropriate page size (2K SLC)? FCM can support two devices, each one is connected to a separate /CS.
What is the integrated phase noise jitter requirement for SD_REF_CLK and SYSCLK for P2041? We don't have the integrated phase noise jitter, the SYSCLK we defined the period jitter and phase noise. For SD_REF_CLK, we follow the PCIe industrial standard spec and it defined peak-to-peak jitters. What is the PLL loop bandwidth of internal PLL in P2040 which uses 100MHz and 125MHz refclks from system? The PLL loop bandwidth of internal PLL is >= 500 KHz. The PLL bandwidth varies with many factors including ref clock rate.
P2041 hardware spec recommends that pins EM2_MDC and EM2_MDIO must be pulled up to 1.2 V through a 180 Ω ± 1% resistor for EM2_MDC and a 330 Ω ± 1% resistor for EM2_MDIO. If these pins are not being used and there is no 1.2V on board, what should be done to these pins? EM2_MDC can be left as floating. EM2_MDIO needs to be tied low to GND or through a 2–10 kΩ resistor to GND. P2041 Hardware spec mentions that local bus address pins LA16 and LA17 must not be pulled down during power-on reset, while P204x RDB Schematics document mentions that LA17 and LA16 are pulled down optionally for CFG_SVR [1:0]. Can you please clarify? Pin LA17 and LA16 are POR pins for CFG_SVR [1:0], and they have internal weak pull-up. To get correct SVR value for P2041, pin LA17 needs external pull low. LA16 = 1 and LA17 = 1 for P2040. LA16 = 1 and LA17 = 0 for P2041. Is IEEE 1588 supported on all 5 Ethernet ports or on only 4 ports for P2040? In the Reference Manual on page 37-3, the only restriction mentioned is that 1588 is not supported for SGMII mode when using 10/100Mbps. On page 38-1, first paragraph it is mentioned that, "The 1588 timer module interfaces to up to four 10/100/1000 or one 10G Ethernet MACs (P2041 only)." Can you please clarify? IEEE 1588 is supported on all ethernet MACs in P2040. It is supported in below combinations: P2040: The 1588 timer module interfaces to up to five 10/100/1000 Ethernet MACs, providing current time, alarm, and fiper support. What are the DC specifications of IEEE1588 pins in P2040? i.e. Vih/Vil. The DC specification of 1588 would be similar to Ethernet Management Interface DC spec. You can use the table 34 and table 35 for 1588 DC given in P2040 reference manual. To which rail should the TEST_SEL pin be pulled up to disable cores two and three, the OVdd (3.3V) rail or the Vdd (1.0V) rail? You can follow below steps to disable the two cores: 1. TEST_SEL pin must be pulled high (100 kΩ to 1 kΩ) to OVDD. 2. Disable Core2 and Core3 by setting core disable register, COREDISR[CD2] and COREDISR[CD3], to 1. Also, do not tie VDD_CB to GND as it is tied to VDD_CA_PL now. What is the consumption current of POVdd for P2040? The maximum current per eFuse block is 25mA. Since we have 2 such block, maximum current is 50mA. Note that except for programming period, POVDD must be grounded at all times (zero current). Pins F24 and E23 are documented as emi2_mdio and emi2_mdc in the P2041 data sheet and as reserved in the P2040 data sheet. Can F24 (reserved on P2040, MDC on P2041) be left floating? Can E23 (reserved on P2040, MDIO on P2041) be tied low or pulled high to a voltage other than 1.2V? What is the recommended connection for these unused pins? emi2_mdc can be left as floating, but emi2_mdio needs to be tied to GND or through a 2–10 kΩ resistor to GND. For P2040, table 12 indicates that TSEC_1588_ALARM_OUT1/EC1_TXD0 should be tied low if not used. TSEC_1588_ALARM_OUT1/EC1_TXD0 is an output, does it need to be tied low or can it be left no connect? TSEC_1588_ALARM_OUT1/EC1_TXD0 is an output, it can be left no connect.
Can you please share throughput numbers for P2010 and eSDHC interface? The basic data rate is 200MB/s for SD/MMC cards using 4 parallel lanes and 416Mbps for MMC using 8 parallel lanes For P2010/P2020, is the SD device / card handled as a block device as it is for Compact flash device? If handled as block device is that implemented by internal logic or should it be implemented in sw / fw? Yes, P2010/P2020 is handled as a block device and it does single or multi-block read/writes. This is handled by internal logic and is set up via the eSDHC register set through the drivers. Does P2010/P2020 eSDHC interface support a SDHC card above 4GB? Yes, eSDHC interface does support a SDHC card above 4GB. The eMMC standard is introduced in JESD84-A44. The new features of the eMMC that eSDHC does not support, are not supported. However, the basic operation of the MMC card is supported.
For P2010/P2020, is any way that the CPU can read and write the full 72-bit wide DDR memory bus, bypassing the ECC logic? I want to know if the memory controller can be configured for the 72-bit wide DDR memory bus to bypass the ECC logic. It is not possible to bypass the ECC and read/write using full 72-bit wide bus. The controller uses the last byte lane to generate ECC info and cannot be bypassed. For P2010/P2020 DDR SDRAM refresh, can you please advise how to "exactly" calculate the appropriate value of [REFINT] if such worst case scenario in which refresh command issue timing is postponed is taken into account? The refresh interval should be set as high as allowable by the DRAM specifications. This should be calculated by using tREFI in the DRAM specifications, which may depend upon the operating temperature of the DRAM. In addition, to allow a memory transaction in progress to be completed when the refresh interval is reached and not violating the device refresh period, set the REFINT value to a value less than that calculated by using tREFI. The value selected for REFINT could be larger than tREFI if the DDR_SDRAM_CFG[NUM_PR] has a value higher than 1. To calculate the max possible value when DDR_SDRAM_CFG[NUM_PR] is higher than 1, use the following formula: (tREFI/clk period) x (NUM_PR) = REFINT A timing tDISKEW (skew between MDQS and MDQ) is depicted in DDR2 and DDR3 SDRAM Interface Input Timing Diagram in P2010/P2020 Hardware spec. For measuring tDISKEW, please instruct me from which point of the MDQS waveform and to which point of MDQ waveform should be measured? For measuring MDQS, it should be at the cross point. For case of MDQ it is derated to the VREF. Why does MCK to MDQS Skew tDDKHMH has such a high value of +/-525ps for DDR3 800M data rate for P2010/P2020? I am afraid that write-leveling can NOT remove all internal MCK to MDQS skew from tDDKHMH. Can you please let me know how much internal skew will be removed after write-leveling? tDDKHMH value of +/-525ps for P2010 part is a conservative value in the HW spec. For DDR3 with write leveling enabled, this AC timing parameter would be a non-factor.
P2010/P2020 H/W spec describes that Max SYSCLK frequency is 100MHz. Generically when user inputs 100MHz clock, actual clock speed become more faster. I think P2010/P2020 has enough margin for faster SYSCLK as long as I use up to 100MHz oscillator. Is my understanding correct? Yes, your understanding is correct. As long as you use 100MHz oscillator it should be fine.
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 P2040 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.
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 P1020 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.