QorIQ Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

QorIQ Knowledge Base

Labels

Discussions

Sort by:
Table of Contents Booting from On-Chip ROM (eSDHC or eSPI) What does on-chip ROM do? The on-chip ROM includes both an eSDHC device driver and an eSPI driver. The driver code copies data from either an SD card/MMC or from an EEPROM with an SPI interface to a temporary memory location. The on-chip ROM is internally mapped to 0xFFFF_E000 when booting from either an SD card/MMC or from an EEPROM.The on-chip boot ROM code uses the information from the SD card/MMC or the EEPROM to configure a temporary memory, such as the L2 cache or a DDR, before it copies a U-Boot image to this temporary memory. After SD card/MMC- or EEPROM-specific configurations are set up and all the image code is copied, the e500 core jumps to the address specified at offset 0x60 in the configurations and starts to execute the code from the temporary memory. Avoiding On-Chip ROM Configuration Issues Using TLB1 The on-chip ROM code configures the first entry of the table lookaside buffer 1 (TLB1) to access up to 4 Gbytes starting from address 0x0000. Although the user configuration easily copies the image to any specified temporary memory location, it may conflict with the U-Boot configuration. Building a RAM-Based U-Boot Under Linux Both SD card/MMC and EEPROM booting use the same RAM-based U-Boot image. A RAM-based U-Boot is different from a NOR Flash-based U-Boot in the following ways: A NOR Flash can perform random accesses, but an SD card/MMC or EEPROM cannot be accessed directly. The starting address of the RAM-based U-Boot is different than a NOR Flash-based U-Boot.After copying the U-Boot image to offset 0x58 in the control words section of the data structure, the on-chip ROM jumps to the location specified at offset 0x60. The requirements for building a RAM-based U-Boot under Linux are as follows: Use a compile time header file to assign the starting location for a U-Boot. The initialization code for the U-Boot must be changed to fit the different U-Boot options. Due to the first entry of TLB1 configuration already in the boot ROM code, the RAM-based U-Boot may need to manage different TLBs or need to change the first entry of the TLB1, if necessary. The U-Boot environment variables must be saved to an SD card/MMC or an EEPROM, and the corresponding code dealing with the environment must be changed to save the variables Note that in the Freescale BSP, cmd_nvedit.c and env_common.c are changed, and env_sdcard.c is added to handle the environment variables. Preparing the image using boot_format boot_format is a booting utility application When booting from an SD card/MMC, boot_format puts the configuration file and the RAM-based U-Boot image on the card (Section 4.3, “Putting a Boot Image on an SD Card/MMC”). When booting from an EEPROM, boot_format generates a binary image that is used to boot from this EEPROM(Section 4.4, “Generating a Binary File for eSPI Booting,” and Section 4.5, “Putting a Booting Image on an EEPROM”). boot_format runs under a regular Linux machine and requires a super user mode to run. After typing boot_format, the following information displays: [root@b08938-02 new_tool]# ./boot_format Usage: ./boot_format config_file image -sd dev [-o out_config] | -spi out_image    Where: config_file: includes boot signature and configuration words image: the U-Boot image for booting from eSDHC/eSPI dev: SDCard’s device node (e.g. /dev/sdb, /dev/mmcblk0) out_image: boot image in SPI mode out_config: modified configure file for SD mode Generating binary file for eSPI routine Perform the following sequence of tasks to generate a binary file using boot_format: Copy the application boot_format to a directory on a Linux machine. Copy the EEPROM configuration file and the U-Boot image to the same directory as boot_format. If not logged in as a super user, switch to super user mode using su. Type ./boot_format config_file image -spi out_image. Generate the booting image “out_image” that is put on the EEPROM in one of the following ways: — Use the EEPROM writer, which is supplied from EEPROM manufacture or a tool supplier. — Write the booting image to an EEPROM under the Linux environment after booting from another method first. Required POR configurations for booting from on-chip RAM 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). At least one LAW must be configured for successful booting using DDR as the temporary memory. 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 MPC8536DS 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]. Booting to Linux from an SD Card/MMC 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 (p1011ds.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 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 in Section 4.3, “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 p1011ds.dtb /mnt/tmp) to the root directory of the FAT system. Unmount the FAT system (umount /mnt/tmp). TIP After copying the kernel file step is performed properly, all the required files and information are on the SD card/MMC. If a Linux desk PC is used: Unplug the SD card/MMC from this PC. Plug the SD card/MMC into a system that is going to boot from this card. Configure the system to boot from an SD card/MMC Stop the U-Boot before it loads the Linux kernel by typing any key. Change the bootcmd parameter by typing the following: setenv sdboot ‘setenv bootargs root=/dev/mmcblk0p2 rw rootfstype=ext2 rootdelay=5 console=ttyS0,115200;mmcinfo; fatload mmc 0:1 1000000 /uImage; fatload mmc 0:1 c00000 /p1011ds.dtb; bootm 1000000 - c00000’ Save the bootcmd parameter by typing save. Continue to boot the system to the Linux prompt by entering run sdboot.
View full article
This section is essentially created to help all QorIQ Processing Platform users ranging from customers to designers to help provide the best solution to the most frequently encountered questions and  some handy tips & tricks related to QorIQ Processing Platform products.                                                   Frequently Asked Questions (FAQ) Tips & Tricks QorIQ P1 Devices QorIQ P1 Devices QorIQ P2 Devices QorIQ P2 Devices QorIQ P3 Devices QorIQ P3 Devices QorIQ P4 Devices QorIQ P4 Devices QorIQ P5 Devices QorIQ P5 Devices Feel free to browse through the various product FAQs to get answers to most commonly encountered questions on topics like DDR3, Ethernet (eTSEC), Booting, USB, Hardware Spec/Reference Manual and more. Also browse through the tips & tricks to help you with your design. Drop a comment or two on how we can keep building these pages. Also, feel free to give your suggestions on what you feel should be added to the FAQs or to the FAQ section as a whole. We intend the NXP Community to grow while mutually helping each other and by reducing design times by providing hands-on solution to tricky problems and questions. QorIQ P1 Devices P1010/1014 FAQs P1010/P1014 DDR Specific FAQs P1010/P1014 Ethernet (eTSEC) Specific FAQs P1010/P1014 USB Specific FAQs P1020/P1011 FAQs 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 P1021/P1012 FAQs P1021/P1012 eSPI/FLASH Specific FAQs P1021/P1012 Ethernet (eTSEC) Specific FAQs P1021/P1012 Memory Controller/DDR Specific FAQs P1022/P1013 FAQs P1022/P1013 Clocking Specific FAQs P1022/P1013 DDR Specific FAQs P1022/P1013 Hardware    Specifications/Reference Manual Specific FAQs P1022/P1013 PCIe Specific FAQs P1022/P1013 Power Management Specific FAQs P1023/P1017 FAQs P1023/P1017 Clocking Specific FAQs P1023/P1017 DDR Specific FAQs P1023/P1017 PCIe Specific FAQs P1024/P1015 FAQs P1024/P1015 Clocking Specific FAQs P1024/P1015 eSPI/FLASH Specific FAQs P1024/P1015 Ethernet Specific FAQs P1024/P1015 Reset Configuration Specific FAQs P1024/P1015 Software Tools - CodeWarrior Specific FAQs P1025/P1016 FAQs P1025/P1016 Clocking Specific FAQs P1025/P1016 DDR Specific FAQs P1025/P1016 Hardware Specifications/Reference Manual Specific FAQs P1025/P1016 QUICC Engine Specific FAQs [ top of page ] QorIQ P1 Devices - Tips & Tricks                                            Booting P1020/P1011 from On-Chip ROM (eSDHC or eSPI) Booting P1021/P1012 from On-Chip ROM (eSDHC or eSPI) Booting P1022/P1013 from On-Chip ROM (eSDHC or eSPI) Booting to Linux from an SD Card/MMC for P1020/P1011 Booting to Linux from an SD Card/MMC for P1021/P1012 Booting to Linux from an SD Card/MMC for P1022/P1013 Enabling SD Interface on P1010 Reference Design Board Enabling SD Interface on P1023 Reference Design Board Enabling SD Interface on P1024 Reference Design Board Enabling SD Interface on P1025 Reference Design Board Hardware and Design Layout/Guidelines for P1010 DDR3 SRAM Interfaces Hardware and Design Layout/Guidelines for P1023 DDR3 SRAM Interfaces Hardware and Design  Layout/Guidelines for P1024 DDR3 SRAM Interfaces Hardware and Design Layout/Guidelines for P1025 DDR3 SRAM Interfaces [ top of page ] QorIQ P2 Devices P2010/P2020 FAQs P2010/P2020 Clocking Specific FAQs P2010/P2020 DDR Specific FAQs P2010/P2020 eSDHC Specific FAQs P2040/P2041 FAQs P2040/P2041 Clocking Specific FAQs P2040/P2041 Ethernet Specific FAQs P2040/P2041 Local Bus Specific FAQs P2040/P2041 PCIe Specific FAQs P2040/P2041 Pre-Boot Loader/Boot Sequencer Specific FAQs P2040/P2041 USB Specific FAQs P2040/P2041Hardware Specifications/Reference Manual Specific FAQs [ top of page ] QorIQ P2 Devices - Tips & Tricks    Booting P2010 from On-Chip ROM (eSDHC or eSPI) Booting P2040/P2041 from On-Chip ROM (eSDHC or eSPI) Booting to Linux from an SD Card/MMC for P2010 Booting to Linux from an SD Card/MMC for P2040/P2041 Enabling SD Interface on P2020 Reference Design Board Hardware and Design Layout/Guidelines for P2020 DDR3 SRAM Interfaces [ top of page ] QorIQ P3 Devices P3041 FAQs P3041 DDR Specific FAQs P3041 Ethernet Specific FAQs P3041 Hardware Specifications/Reference Manual Specific FAQs P3041 USB Specific FAQs [ top of page ] QorIQ P3 Devices - Tips & Tricks Hardware and Design Layout/Guidelines for P3041 DDR3 SRAM Interfaces [ top of page ] QorIQ P4 Devices                   P4040 FAQs P4040 Clocking Specific FAQs P4040 eSPI/FLASH Specific FAQs P4040 Ethernet Specific FAQs P4040 Reset Configuration Specific FAQs P4040 Software Tools - CodeWarrior Specific FAQs P4080 FAQs P4080 DDR Specific FAQs P4080 Ethernet Specific FAQs P4080 Hardware Specifications/Reference Manual Specific FAQs P4080 USB Specific FAQs [ top of page ] QorIQ P4 Devices - Tip & Tricks Booting P4080 from On-Chip ROM (eSDHC or eSPI) Booting to Linux from an SD Card/MMC for P4080 Hardware and Design Layout/Guidelines for P4040 DDR3 SRAM Interfaces [ top of page ] QorIQ P5 Devices P5020/P5010 FAQs P5020/P5010 COP/JTAG Specific FAQs P5020/P5010 Device Ratings Specific FAQs P5020/P5010 Hardware Specifications/Reference Manual Specific FAQs [ top of page ] QorIQ P5 Devices - Tips & Tricks Booting P5010 from On-Chip ROM (eSDHC or eSPI) Booting to Linux from an SD Card/MMC for P5010 Hardware and Design Layout/Guidelines for P5020 DDR3 SRAM Interfaces [ top of page ]
View full article
DPDMUX is a device like DPSW (Switch) which allows switching of packets within the DPAA2 blocks. This application adds DPDMUX support in DPDK, uses LS2088ARDB as an example platform for demonstrating the use case that traffic bifurcation between DPDK and Linux Kernel using DPDMUX on DPAA2 platform.
View full article