1. Different connecting for USB Super-Speed signals. 2. Pin MUX configuration for USB1(USB 3.0) 3. Linux Kernel configuration 4. Device Tree updating 5. Verify on the target board.

1. Secure boot Overview Non PBL platform supports two boot modes, trusted/secure boot and legacy/non secure boot.Secure boot where boot images are validated against a digital signature before executing, only OEM’s signed boot images can be executed on these SOCs. Legacy/non-secure boot where boots happens from various boot targets. 1.1 ITS bit Intent to secure(ITS) bit, the most important fuse value at power on reset stage. If the user set ITS, the system is operated in a secure and trusted manner, interfaces, memory permissions and MMU configurations will be locked down until trusted software is executed. After the ITS bit is set, the system jumps to an internal secure ROM fro booting, regardless of value provided in the boot location POR. When execution begins from internal boot ROM(IBR), it checks the cfg_rom_loc value which indicates the source of the external secure boot code location. The IBR is to determine if the external secure boot code(ESBC) is valid before allowing the code to execute. If the user doesn’t want to fuse the ITS bit, he can set CFG_SB_DIS to 0 to pass the system control to IBR.   1.2 ESBC with CF header and CSF header The I2C boot sequencer provides a way to configure the system using a set of address data stored in I2C EEPROM, the boot sequencer works only in the legacy mode.  In the secure boot mode, the boot sequencer is disabled, the same functionality is achieved by adding a similar data structure called a CF header, this header is on lines of the SD/MMC and eSPI data structure containing the control and configuration words. IBR running on the core first authenticates the CF header and then executes the configuration words. ESBC with CF and CSF(Command Sequence File) Header prepended to it. The CF header contains legacy mode fields, configuration words to initialized destination interface like DDR, ESBC header pointer. The CSF header includes lengths and offset which allow the IBR to located the operands used in ESBC image validation, as well as describe the size and location of the ESBC image itself. 1.3 ESBC and boot script ESBC can be a monolithic image including u-boot, device trees, boot firmware, drivers along with OS and applications. The standard u-boot reserves a small space for storing environment variables, this space is typically the sector above or below the u-boot. In acase of secure boot, the micro CONFIG_ENV_IS_NOWHERE is used and environment is compiled in u-boot image called default environment, users are not be able to edit this environment, they cannot read to u-boot prompt either in case of secure boot.   ESBC validates a file called boot script, it contains information about the next image, e.g. Linux, HV etc. Boot script is a text file which contains u-boot commands. ESBC would validate this boot script before executing commands in it. Secure boot flow with all images loaded in NOR Flash. (1) IBR code would validate the ESBC code. (2) On successful validation, ESBC code would run, it then validates the boot script. (3) On successful validation of boot script, commands in boot script would be executed. (4) The boot script contains commands to validate next level images, i.e rootfs, linux uImage and device tree. (5) Once all the images are validated, bootm command in boot script would be executed which would pass control to linux 1.4  Steps to generate secure boot images Build secure boot u-boot Edit meta-fsl-ppc/conf/machine/<platform>.conf, modify  UBOOT_MACHINES = "<platform_uboot_config>" to UBOOT_MACHINES = "<platform_uboot_config>_SECBOOT" e.g. UBOOT_MACHINES = "BSC9132QDS_NAND_SECURE_BOOT " Rebuild u-boot       $ bitbake -c clean u-boot       $ bitbake u-boot 2. Signing the images Users can sign all the images with same public/private key pair or different key pairs to sign the images. This document will describe the same key pair method. CST tool provided in Yocto Linux SDK is used for signing the images, which is built for the host and can be run from the host machine. In Yocto, run the command “bitbake cst-native”, and the binaries can be found in build_<machine>_release/tmp/sysroot/ x86_64-linux/usr/bin/cst. CSF header needs to be generated for all the images. The following describes the process of signing images. Generate the key pair to be used for signing the image. ./gen_keys 1024 Key pair – public key file – srk.pub  and private key in srk.priv would be generated. Obtain hash string of the key pair generated to be programmed in SFP. ./uni_sign --hash This would provide a 256bit hash string of the key pair generated in the previous step. Create CF and CSF headers  for u-boot image. Execute the binaries uni_cfsign and uni_sign to generate signature over CF Header and CSF header. Example for BSC9132, generate CF header file cf_hdr.out. ./uni_cfsign input_files/uni_cfsign/bsc9132/input_nand_secure        ESBC Header generation,  ESBC header file is named esbc_hdr.out. ./uni_sign --file input_files/uni_sign/bsc9132/input_uboot_nand_secure Create CSF header for Linux uImage ./uni_sign --file input_files/uni_sign/ bsc9132/ input_uimage_secure Create CSF header for rootfs ./uni_sign --file input_files/uni_sign/ bsc9132/ input_rootfs_secure Create CSF Header for hardware device tree ./uni_sign --file input_files/uni_sign/<platform>/input_dtb_secure Write Boot script Create a text file bootscript.txt with following commands. For BSC9132 esbc_validate 0x88040000 esbc_validate 0x88080000 esbc_validate 0x88800000 bootm 88082000 88802000 88042000 Generate header over bootscript.txt which will be consumed by uboot command source ./tmp/sysroots/x86_64-linux/usr/bin/mkimage -A ppc -T script -a 0 -e 0x40 -d  bootscript.txt     bootscript Generate CSF header for the boot script /uni_sign --file input_files/uni_sign/ bsc9132/ input_bootscript_secure 3. Running secure boot on BSC9132QDS board Configuring the target board in secure boot mode, the following methods could be used. (a). Programming the ITS fuse. (b). Use FPGA image to program (CFG_SB_DIS) = 0 in DUT Configuration Register 12. (1). OTPMK can be blown using CCS, the follow commands are use to blow the OTPMK with CCS. Consider the OTPMK key obtained is : ef0f928b52255d2bfc05be5419fd8d724241ecedfbaaaddbf2f246989fb271c1 ccs::write_mem 1 0xff7e705c 4 0 0xef0f928b ccs::write_mem 1 0xff7e7060 4 0 0x52255d2b ccs::write_mem 1 0xff7e7064 4 0 0xfc05be54 ccs::write_mem 1 0xff7e7068 4 0 0x19fd8d72 ccs::write_mem 1 0xff7e706c 4 0 0x4241eced ccs::write_mem 1 0xff7e7070 4 0 0xfbaaaddb ccs::write_mem 1 0xff7e7074 4 0 0xf2f24698 ccs::write_mem 1 0xff7e7078 4 0 0x9fb271c1 Permanently fuse the values written in shadow register above ccs::write_mem 1 0xff7e7020 4 0 0x2 (2) ESBC uboot image and its CF and CSF headers are flashed in NAND flash. All the other images are flashed in NOR flash. Power on the board. You have booted from NOR flash normally. Give following commands    on the uboot prompt: => nand erase.chip => tftp 1000000 cf_hdr.out => tftp 1002000 esbc_hdr.out => tftp 1004000 u-boot.bin => nand write 1000000 0 120000 (3) Give a power on cycle to the board. For method (a), on power on, IBR code would get control, validate the ESBC image. ESBC image would further validate the signed linux, rootfs and dtb images Linux would come up. For method(b), on power on cycle, write SRKH, UIDs in the SFP shadow registers. Bring the core out of hold off  by writing to EEBPCR register. On doing this, the secure boot flow as mentioned above would execute. Using I2C commands to put the core in boot hold off, the following register needs to be changed The values to be programmed in this register are as follows: Boot Mode Defualt Value Value with Boot Hold Off Enabled NAND 0x9e 0x97 NOR 0xfe 0xf7 SPI 0x6e 0x67 SD 0x7e 0x77 So the I2C commands will be: CFG_SB_DIS = 0 =>i2c mw.l 0x66 0x6c 0xc7 Core in boot HOLD off =>i2c mw.l 0x66 0x6b 0x97    <value from table above> Change LBMAP if ROM_LOC is changed. =>i2c mw.l 0x66 0x50 0x44 Copy all BRDCFG/DUTCFG registers to their respective shadow registers. =>i2c mw.l 0x66 0x10 0x60 Lock the register values. =>i2c mw.l 0x66 0x10 0x30 ->reset Write the keys in SFP_SRKRH shadow registers from CCS. 097fb4eaea7aa38eec7c724bf3288a3b68ebfeebe30bd00176d386d905b650ed ccs::write_mem 1 0xff7e707c 4 0 0x097fb4ea ccs::write_mem 1 0xff7e7080 4 0 0xea7aa38e ccs::write_mem 1 0xff7e7084 4 0 0xec7c724b ccs::write_mem 1 0xff7e7088 4 0 0xf3288a3b ccs::write_mem 1 0xff7e708c 4 0 0x68ebfeeb ccs::write_mem 1 0xff7e7090 4 0 0xe30bd001 ccs::write_mem 1 0xff7e7094 4 0 0x76d386d9 ccs::write_mem 1 0xff7e7098 4 0 0x05b650ed Write the OEMID and FSLID in shadow registers ccs::write_mem 1 0xff7e709c 4 0 0x99999999   (OEM UID) ccs::write_mem 1 0xff7e70b0 4 0 0x11111111   (FSL UID) Get the core out of boot hold off. ccs::write_mem 1 0xff701010 4 0 0x01000000 (4) The boot log for NAND secure boot U-Boot 2013.01-00096-gc8c8ae0 (Nov 29 2013 - 20:11:18) CPU0:  BSC9132E, Version: 1.0, (0x86180010) Core:  E500, Version: 5.1, (0x80211151) Clock Configuration:        CPU0:1000 MHz, CPU1:1000 MHz,        CCB:500 MHz,        DDR:400 MHz (800 MT/s data rate) (Asynchronous), IFC:125  MHz L1:    D-cache 32 kB enabled        I-cache 32 kB enabled Board: BSC9132QDS Sys ID: 0x1f, Sys Ver: 0x31, FPGA Ver: 0x78, IFC chip select:NAND I2C:   ready SPI:   ready DRAM:  1 GiB (DDR3, 32-bit, CL=6, ECC off) Flash: 128 MiB L2:    512 KB enabled NAND:  128 MiB MMC:  FSL_SDHC: 0 Using default environment EEPROM: NXID v1 PCIe1: Root Complex of PCIe Slot, x1, regs @ 0xff70a000   01:00.0 - 8086:10b9 - Network controller PCIe1: Bus 00 - 01 In:    serial Out:   serial Err:   serial Net:   e1000: 00:15:17:1e:22:9e        eTSEC1 [PRIME], eTSEC2, e1000#0 Warning: e1000#0 using MAC address from net device Hit any key to stop autoboot:  0 esbc_validate command successful ## Executing script at 88022000 esbc_validate command successful Job Queue Output status 40000516 ERROR :: 4000000 :: Error in status of the job submitted to SEC SNVS state transitioning to Soft Fail. SNVS state transitioning to Non Secure. esbc_validate command successful WARNING: adjusting available memory to 30000000 ## Booting kernel from Legacy Image at 88082000 ...    Image Name: Linux-3.8.13-rt9    Created: 2013-11-22   8:10:07 UTC    Image Type: PowerPC Linux Kernel Image (gzip compressed)    Data Size: 4103863 Bytes = 3.9 MiB    Load Address: 00000000    Entry Point: 00000000    Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 88802000 ...    Image Name: fsl-image-flash-bsc9132qds-20131    Created: 2013-11-10   1:40:54 UTC    Image Type: PowerPC Linux RAMDisk Image (gzip compressed)    Data Size: 6679841 Bytes = 6.4 MiB    Load Address: 00000000    Entry Point: 00000000    Verifying Checksum ... OK ## Flattened Device Tree blob at 88042000    Booting using the fdt blob at 0x88042000    Uncompressing Kernel Image ... OK    Loading Ramdisk to 2f9a1000, end 2ffffd21 ... OK    Loading Device Tree to 03ff7000, end 03fff6b5 ... OK WARNING: Missing crypto node Using BSC9132 QDS machine description Memory CAM mapping: 256/256/256 Mb, residual: 256Mb Linux version 3.8.13-rt9(gcc version 4.7.3 (GCC) ) #29 SMP Fri Nov 22 16:10:03 CST 2013 Found initrd at 0xef9a1000:0xeffffd21 CPU maps initialized for 1 thread per core bootconsole [udbg0] enabled setup_arch: bootmem bsc913x_qds_setup_arch() bsc913x board from Freescale Semiconductor arch: exit Zone ranges:   DMA [mem 0x00000000-0x2fffffff]   Normal empty     HighMem  [mem 0x30000000-0x3fffffff]

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.

T2080PCIe_RDB SPI reboot failure problem

T2080 rev1.1 has fixed the MEM_PLL_RAT issue. but, the set flow is different than T2080 rev1.0. The flow is in the attached doc.

Sometimes you encoutner thisSD/eMMC issue ,"Card did notrespond to voltage select! ". You could add debug message to see the communication between SD/eMMC and host. #define  DEBUG #define CONFIG_MMC_TRACE  & add debug message in mmc.c (driver/mmc) int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) { .. printf("CMD_SEND:%d\n",cmd->cmdidx); printf("\t\tARG\t\t\t0x%08X\n", cmd->cmdarg); .. } => mmcinfo CMD_SEND:0                ARG                     0x00000000             MMC_RSP_NONE CMD_SEND:8 ARG                     0x000001AA           MMC_RSP_R1,5,6,7        0x00000001 CMD_SEND:55 ARG                     0x00000000 MMC_RSP_R1,5,6,7         0x00000001 CMD_SEND:0 ARG                     0x00000000 MMC_RSP_NONE

CodeWarrior Development Suite for Networking Applications to support software development on QorIQ Layerscape devices.

This is a procedure to enable QorIQ GPIOs in Linux Kernel 

Hypervisor Deployment The Freescale embedded hypervisor is a layer of software that enables the efficient and secure partitioning of a multicore system. A system's CPUs, memory, and I/O devices can be divided into groupings or partitions, as shown in the figure below. Each partition is capable of executing a guest operating system. Figure 1. Partitioning with the Hypervisor in a Multicore Environment Hypervisor DTB changes: The partitioning information is defined in hypervisor package file called hv.dts. By default, the hv.dts file has only 2 interfaces and a mac-less interface defined per partition.  For IPSec demo we need to place all the interfaces within the 1st partition and the attached file has the full source code details. To extract the HV DTB source code, use the bitbake command: bitbake -c patch hv-cfg Build the final binaries using the bitbake command: bitbake fsl-image-core The above command would compile all the binaries required (including hv-2p-lnx-lnx.dtb) Now, the kernel, hypervisor image, device tree, hypervisor device tree and ramdisk filesystem can be flashed onto the board. These steps should be done assuming the user already has switched to the alternate bank.             Step 1: Programming Kernel to Flash TFTP the kernel image to RAM, then copy it to the flash address 0xe8020000. Execute the following commands at the U-Boot prompt to program the kernel to flash: =>tftp 1000000 uImage-t1040rdb.bin =>erase e8020000 +$filesize =>cp.b 1000000 e8020000 $filesize Step 2: Programming Ramdisk Filesystem to Flash TFTP the ramdisk file system to RAM, then copy it to the flash at address 0xe9300000. Execute the following commands at U-Boot prompt to program the ramdisk to flash: =>tftp 1000000 fsl-image-core-t1040rdb.ext2.gz.u-boot =>erase e9300000 +$filesize =>cp.b 1000000 e9300000 $filesize Step 3: Programming Hypervisor Image to Flash TFTP the hypervisor images to RAM, then copy it to the flash at address 0xe8700000. Execute the following commands at U-Boot prompt to program the hypervisor image to flash: =>tftp 1000000 hv.uImage =>erase e8700000 +$filesize =>cp.b 1000000 e8700000 $filesize Step 4: Programming Kernel dtb to Flash TFTP the kernel dtb file to ram, then copy it to the flash at address 0xe8800000. Execute the following commands at U-Boot prompt to program the kernel dtb to flash: Target Deployment - for hv-2p mode deployment: =>tftp 1000000 uImage-t1040rdb.dtb =>erase e8800000 +$filesize =>cp.b 1000000 e8800000 $filesize Program "hv-2p-lnx-lnx.dtb" to 0xe8900000 =>tftp 1000000 hv-2p-lnx-lnx.dtb =>erase e8900000 +$filesize =>cp.b 1000000 e8900000 $filesize           Step 5: Booting Up the System As of now, all the DPAA devices on this platform are given to partition 1. The kernel can boot up automatically after the board is powered on with the correct U-Boot environment. The following command can also be used to boot up the board at U-Boot prompt: =>setenv bootargs config-addr=0xfe8900000 console=ttyS0,115200 =>setenv bootcmd 'bootm 0xfe8700000 - 0xfe8800000' =>saveenv =>boot Step 6: Setup IPSec demo as described in the following link IPSec demo on T1040RDB

The Precision Time Protocol (PTP) is a protocol used to synchronize clock throughout a computer network. PTP was originally defined in IEEE1588-2002 standard. To use PTP functionality in DPDK, users can use DPDK example application “ptpclient” present in DPDK source code, ptpclient application uses DPDK IEEE1588 API to communicate with a PTP master clock to synchronize the time on NIC and, optionally, on the Linux system. IEEE1588 Introduction Compile the Application Running the Application Code Explanation

Many of the QorIQ processors have CPC (L3 CoreNet platform cache), such as P2040, P3041, P4080, B4860 and T1040 etc. CPC is a CoreNet-compliant target device. It could also be configured as memory-mapped SRAM, or combination of cache and SRAM. Here describe how to configure CPC to be SRAM.

This document describes rate limiting solution implementation with QoS features of SJA1105 switch to handle the congestion of competing traffic flows, including the software architecture on TSN platforms, ingress traffic policer, prioritizing configuration, Time-Aware Scheduler in 802.1Qbv engine through SJA1105 switch and using IEEE 1588(Precision Time Protocol) to synchronize the SJA1105 PTP clocks.       Software Solution Architecture on TSN Platform        Ingress Traffic Policer        Prioritizing Configuration        Time-Aware Scheduler         Using IEEE 1588 to Synchronize the SJA1105 PTP Clocks

For QorIQ Processors you could find documents from official website: Submit Form And below document list in this place: SDK/DPAA/Networking: Using QMAN Dedicated and Pool Channels in USDPAA and Linux Kernel LS2085 NADK Based IPSEC Application Communicating with AIOP DPAA Ethernet Interfaces Shared-MAC between two Linux Partitions under Hypervisor(Topaz) IPv6+AES.docx T1040 L2Switch Software Support IPSec demo on T1040RDB hv.dts IPSec on Freescale Hypervisor (Topaz) and T1040 (T1042) Rate limiting in DPAA QorIQ QMan CEETM Implementation in USDPAA Read T2080 XFI link status Shared-MAC and MAC-less Implementation in DPAA Linux Kernel Driver P2020RDB IPV4 forwarding performance test.pdf Set up NAT on QorIQ RDB Set up VLAN on QorIQ RDB SDK/Virtualization: FTF-DES-F1254_QorIQ Device Virtualization.pdf Virtualization Solutions in Freescale Linux SDK(1)– Hypervisor(topaz) Tools/Build/Debug: FTF-DES-F1321-QorIQ-Debug.pptx AMF-DES-T1053 - Open Source Tools Development Tools for ARM® Architectures .pptx AMF-DES-T1052 - QorIQ DevTools for Layerscape Family Products Applications.pptx AMF-SNT-T1045-Freeescale-Solutions-targeting-SDN-NFV-markets-with-ARM64-processors.pptx Modify T2080 rev1.1 MEM_PLL_RAT w/ using QCVS4.1.1 Using external GNU toolchain with CodeWarrior for QorIQ LS series – ARMv7 ISA QorIQ SDK build for T4240QDS - Beginner's guide Introducing the Scenarios Tool QorIQ Linux SDK 1.6 Working With Yocto T4240QDS_Altivec_example_with_MEPL.zip Building uboot/kernel/test-application out of Yocto Changing RootFS in SDK 1.3.2 Adding a new Flash Device to Codewarrior 10.x Building SDK 1.3.2 Boot/Board: LS2085 u-boot Workflow T2080PCIeRDB_SPI_reboot failure.pdf How to Flash/Reflash U-Boot and Linux to a Freescale Digital Networking Board System Boot from SD/MMC Card with SDK 1.6 images Secure boot for Non-PBL Platform Booting from QSPI on LS102xA Firmware update for LS1-TWR Switches on PSC9131RDB Re-flashing the P3041DS Deploying SDK 1.3.2 Solutions: AMF-SNT-T1045-Freeescale-Solutions-targeting-SDN-NFV-markets-with-ARM64-processors.pptx NEXCOM Introduces Appliance Based on Freescale QorIQ T4240 SoC and Aims for Gbps UTM Throughput Others: T4240QDS_Altivec_example_with_MEPL.zip A quick demo setup to toggle hue bulb using LS1021A IoT host processor and MKW20 zigbee QorIQ_Linux_kernel_GPIO_enable.pdf Announcements I2C NCSW Use Case FTF-DES-F1253 Lunch and Learn: Expedite Your Product Development with Linux SDK Backport Technolog Processors/Cores: L1 D-Cache Flushing Using CPC as SRAM

We’re glad to announce the FSL Community BSP 1.7 (codename Dizzy); it has been a busy release cycle with some new boards support added. In total we now support 42 boards from several vendors. During the 1.7 release cycle, a new SoC family support (QorlQ Layerscape1) has been included and the application and graphical stack support (better Wayland, Qt5 and Chromium support to enumerate some) has been greatly extended. This all has been accomplished with way less changes on the core BSP layer (53% less commits) which enforces the compromise of FSL Community BSP with long term quality and support. Another worth citing news is regarding the release notes. It is available online and gives an overview of supported boards, available version for default and optional packages and known issues at time of the release. The release notes has been completely reworked and extended in this release. It now offers a PDF version (for viewing and printing) alongside with the regular online one.

This session will take an in-depth look at QorIQ Data Path Acceleration Architecture (DPAA) and how each component interact with each other and the e500mc core. Discussion will include FMAN, QMAN, BMAN, SEC4, PME, SRIO manager and RAID Engine.

NEXCOM 1U network security appliance the NSA 5640 is designed for advanced Unified Threat Management (UTM) solutions with multi-Gigabit throughput. Featuring the Freescale multicore QorIQ T4240 SoC and high-speed networking and interconnect interfaces, the NSA 5640 addresses the escalating cyber threats fueled by rising network communication, bandwidth-hungry activities and number and complexity of Internet-based attacks.

This document introduce OpenIL Baremetal framework architecture using NXP Layerscape platforms, describes how to run a sample baremetal project and inter-core Communication application development based on OpenIL Baremetal framework. Inter-core communication(ICC) application works on Linux core(master) and Baremetal core(slave), provides the data transfer between cores via SGI inter-core interrupt and share memory blocks. Baremetal Framework architecture for QorIQ Layerscape platforms. Running Baremetal Binary Inter-core communication(ICC) application Development Based on Baremetal Framework Running ICC demo application

The flow is on sector 3.4.20.10.4 in QorIQ-SDK-1_7-IC-RevA, but it is wrong. So, please follow the steps in the attachment.