This document describes how to setup the LS1046A RDB as a PCIe End Point(EP) to be link trained and enumerated by the host system. The LS1046A RDB in this scenario is essentially being used to emulate a PCIe Add-in Card in PCIe-EP mode. LS1046ARDB Modifications for PCIe-EP Environment setting up MSI interrupt testing

This tutorial details the basics of how to boot up a Freescale T4240QDS board and also explains how to build an image in yocto and boot it up on the board. The intended audience is an absolute beginner who is new to the yocto build and working on a board like T4240 Download the QorIQ SDK from freescale’s site. The SDK site can be found in: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SDKLINUX The version that is used in this documentation is version 1.4. Version 1.4 can be found in: http://www.freescale.com/webapp/sps/site/overview.jsp?code=QORIQSDK_1.4 The SDK has 3 important components, The source ISO – The actual SDK source that we are going to use. The cache state ISO – These files contain sstate-cache directory, i.e all packages pre-downloaded, this makes the build run faster. The image ISO – These are pre-built images for all Freescale targets. This is not required for this tutorial, since we are building our own images. The name of the source ISO that you are looking for is: QorIQ Linux SDK v1.4 Yocto Source ISO Once you click  Source, go ahead and login when the site prompts. Download the source ISO, we are going to work on this. Open a terminal Create the iso directory qoriq@usernsl-Veriton-Series:~$ sudo mkdir /media/sourceiso Mount the iso. qoriq@usernsl-Veriton-Series:~$ sudo mount -o loop Downloads/QorIQ-SDK-V1.4-SOURCE-20130625-yocto.iso /media/sourceiso/ Change into source directory qoriq@usernsl-Veriton-Series:~$ cd /media/sourceiso/ Copy the source SDK qoriq@usernsl-Veriton-Series:/media/sourceiso$ sudo cp yocto.tar.gz ~/ Change into working directory qoriq@usernsl-Veriton-Series:/media/sourceiso$ cd Create the root SDK directory qoriq@usernsl-Veriton-Series:~$ mkdir yocto Move the gzip file into directory qoriq@usernsl-Veriton-Series:~$ mv yocto.tar.gz yocto/ Change into working directory qoriq@usernsl-Veriton-Series:~$ cd yocto/ Unzip the source qoriq@usernsl-Veriton-Series:~/yocto$ tar xvf yocto.tar.gz View the source files/directories qoriq@usernsl-Veriton-Series:~/yocto$ ls bitbake LICENSE meta-fsl-ppc meta-oe  meta-yocto README sources documentation meta meta-fsl-ppc-toolchain meta-skeleton meta-yocto-bsp README.hardware yocto.tar.gz fsl-setup-poky meta-fsl-networking meta-hob meta-virtualization oe-init-build-env scripts Preparing the kernel Freescale kernel is configured in the layer ‘yocto/meta-fsl-ppc/recipes-kernel/linux’ folder. It containes recipes (.bb) files that tell the SDK how to download/configure/install the kernel. There are 2 portions to the kernel configuration, one is the kernel itself (linux-qoriq-sdk.bb file) and the kernel headers (linux-qoriq-sdk-headers.bb file). First we are going to show how to prepare the kernel to change the kernel sources within the kernel recipes. This can help us modify the sources. Move into home directory qoriq@usernsl-Veriton-Series:~/yocto$ cd .. Download the freescale kernel that is going to be built for the target qoriq@usernsl-Veriton-Series:~$ git clone git://git.freescale.com/ppc/sdk/linux.git Cloning into 'linux'... remote: Counting objects: 2931244, done. remote: Compressing objects: 100% (481548/481548), done. remote: Total 2931244 (delta 2449497), reused 2902973 (delta 2421384) Receiving objects: 100% (2931244/2931244), 581.84 MiB | 92 KiB/s, done. Resolving deltas: 100% (2449497/2449497), done. Rename the kernel tree to the Yocto compatible directory (this makes  the build run error free, with minimal changes) qoriq@usernsl-Veriton-Series:~$ mv linux/ linux-qoriq-sdk Create a gzip file of the kernel source qoriq@usernsl-Veriton-Series:~$ tar zcvf linux-qoriq-sdk.tar.gz linux-qoriq-sdk/ Generate the md5sum of the kernel gzip, (used in the build conf file) qoriq@usernsl-Veriton-Series:~$ md5sum linux-qoriq-sdk.tar.gz 986feb8581d3521f295884270d7cc5f2 linux-qoriq-sdk.tar.gz Now the kernel is ready to be given as input to the build environment.  The kernel sources (from where the kernel is downloaded/fetched) is, by default, the freescale git repository. Since we downloaded the kernel from the same repository we should remember to change the kernel sources to the gzip file that we created. We show how to do this, further in this tutorial. The Build proceedure These are the build commands to generate the images. Change into the yocto directory qoriq@usernsl-Veriton-Series:~ cd yocto Source the environment qoriq@usernsl-Veriton-Series:~/yocto$ source fsl-setup-poky -m Configuring for t4240qds board type Creating an yocto build output at /home/qoriq/yocto/ build_t4240qds_release Run the following commands to start a build:           bitbake fsl-image-core           bitbake fsl-image-lsb-sdk           bitbake fsl-image-flash           bitbake fsl-image-full           bitbake fsl-image-kvm           bitbake fsl-image-minimal To return to this build environment later please run:           source /home/qoriq/yocto/build_t4240qds_release/SOURCE_THIS Sourcing the environment makes all the yocto commands(bitbake, runqemu, runqemu-extract-sdk, yocto-layer etc.) available, it also creates a default environment that can be configured to build for various different architectures and machines. The two important configuration files that need to be modified are:                conf/local.conf                conf/bblayers.conf We will see what these files contain and what we are going to modify. Open conf/local.conf qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release$ nano conf/local.conf Find the line that has : #BB_NUMBER_THREADS = "4" Uncomment the line and change it into BB_NUMBER_THREADS = "8" This creates 8 threads and does the build in parallel. Find the line that has: #PARALLEL_MAKE = "-j 4" Uncomment and change it into PARALLEL_MAKE = "-j 8" This variable is sent as parameter to all make invocation and performs the make in parallel with 8 threads Find the line that has: MACHINE ??= "qemux86" And replace with: MACHINE ??= "t4240qds" This variable determines the machine that the image is built for.  “qemux86” is a x86 image that can be run virtually on the host system. “t4240qds” is the machine that we are building the images for. Hit Ctrl + X to exit Configuring kernel recipes Move to yocto folder qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release $ cd .. Change into the kernel recipe directory qoriq@usernsl-Veriton-Series:~/yocto$ cd meta-fsl-ppc/recipes-kernel/linux/ The directory contains a set of files. All .bb files are recipes and they contain configurations to fetch/configure/compile/install packages.All .inc files are include files, they are included within the corresponding .bb file with the “require “ command The files linux-qoriq-sdk.* are files that configure the kernel. The files linux-qoriq-sdk-headers.* are files that configure the header files for the kernel We need to separate the sources for the kernel and the headers and then configure the kernel sources to point to the kernel that we have already zipped and made available Make a copy of linux-qoriq-sdk.inc and keep it as linux-qoriq-sdk-headers.inc qoriq@usernsl-Veriton-Series:~/yocto/meta-fsl-ppc/recipes-kernel/linux$ cp linux-qoriq-sdk.inc linux-qoriq-sdk-headers.inc Open linux-qoriq-sdk-headers.inc qoriq@usernsl-Veriton-Series:~/yocto/meta-fsl-ppc/recipes-kernel/linux$ nano linux-qoriq-sdk-headers.bb Find the line that has: require recipes-kernel/linux/linux-qoriq-sdk.inc Edit it to: require recipes-kernel/linux/linux-qoriq-sdk-headers.inc We have separated the sources for the kernel and the headers, now we proceed to edit the sources of the kernel Open linux-qoriq-sdk.inc file qoriq@usernsl-Veriton-Series:~/yocto/meta-fsl-ppc/recipes-kernel/linux$ nano linux-qoriq-sdk.inc Edit the file to look like: ## File starts here ## LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" PV = "3.8" INC_PR = "r9" #SRCREV = "4b66366af2d77de68f4bd6548d07421e13d3df05" #SRC_URI = "git://git.freescale.com/ppc/sdk/linux.git \ # " SRC_URI = "file:///home/qoriq/linux-qoriq-sdk.tar.gz" SRC_URI[md5sum] = "986feb8581d3521f295884270d7cc5f2" KSRC ?= "" S = '${@base_conditional("KSRC", "", "${WORKDIR}/linux-qoriq-sdk", "${KSRC}", d)}' # make everything compatible for the time being COMPATIBLE_MACHINE_$MACHINE = "$MACHINE" python () { ma = d.getVar("DISTRO_FEATURES", True) arch = d.getVar("OVERRIDES", True) # the : after the arch is to skip the message on 64b if not "multiarch" in ma and ("e5500:" in arch or "e6500:" inarch): arch requires multiarch to be in DISTRO_FEATURES") promote_kernel = d.getVar('BUILD_64BIT_KERNEL') if promote_kernel == "1":      raise bb.parse.SkipPackage("Building the kernel for this      d.setVar('KERNEL_CC_append', ' -m64')      d.setVar('KERNEL_LD_append', ' -melf64ppc') error_qa = d.getVar('ERROR_QA', True) if 'arch' in error_qa:      d.setVar('ERROR_QA', error_qa.replace(' arch', '')) all_qa = d.getVar('ALL_QA', True) if 'arch' in all_qa:      d.setVar('ALL_QA', all_qa.replace(' arch', '')) ## File ends here ## (( Note: It is adviceable to copy the entire contents above and replace with the contents of the file. If you are unable to copy the above source and have it properly aligned, follow the list of changes below and change it manually: Find the variable INC_PR and set it to INC_PR = “r9” Comment out the existing SRCREV and SRC_URI variable: SRCREV = "4b66366af2d77de68f4bd6548d07421e13d3df05" SRC_URI = "git://git.freescale.com/ppc/sdk/linux.git \ " And replace with the sources you had built SRC_URI = file:///home/qoriq/linux-qoriq-sdk.tar.gz SRC_URI[md5sum] = “986feb8581d3521f295884270d7cc5f2” Make sure the entered md5sum matches that of the kernel source available in that particular location. The build sets a variable S as: S = '${@base_conditional("KSRC", "", "${WORKDIR}/git", "${KSRC}", d)}' We need to modify it as: S = '${@base_conditional("KSRC", "", "${WORKDIR}/linux-qoriq-sdk", "${KSRC}", d)}' )) Building the image Now we are ready to run the build, After sourcing the environment, we find that the bitbake (build command) can generate various images:           bitbake fsl-image-core           bitbake fsl-image-lsb-sdk           bitbake fsl-image-flash           bitbake fsl-image-full           bitbake fsl-image-kvm           bitbake fsl-image-minimal These images provide various different functionality within the image, we are going to use the image: fsl-image-core as it can generate a bootable and minimal image with adequate functionality. The build can take a long time to run. Change to build directory qoriq@usernsl-Veriton-Series:~/yocto/meta-fsl-ppc/recipes-kernel/linux$ cd ~/yocto/build_t4240qds_release/ qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release$ bitbake fsl-image-core Loading cache: 100% |#################################################################################################| ETA: 00:00:00 Loaded 3120 entries from dependency cache. Build Configuration: BB_VERSION = "1.18.0" BUILD_SYS = "i686-linux" NATIVELSBSTRING = "Ubuntu-12.04" TARGET_SYS = "powerpc-fsl_networking-linux" MACHINE = "t4240qds" DISTRO = "fsl-networking" DISTRO_VERSION = "1.4" TUNE_FEATURES = "m32 fpu-hard e6500 altivec" TARGET_FPU = "hard" meta meta-yocto meta-yocto-bsp = "sdk-v1.4.x:5a7532143a49f59a5c85b08d3daf574fb1eccd8d" meta-fsl-ppc = "sdk-v1.4.x:f9fd0a617eb6913f87335c551918315ff4ebe18c" meta-fsl-ppc-toolchain = "sdk-v1.4.x:8ec94cec04527cb971c125b1ddd2c5375034d723" meta-virtualization = "sdk-v1.4.x:ad6df4f59cd7646f61db29e8fa51f878329d6f93" meta-fsl-networking = "(nobranch):00f7a535029ca7ef8c96ba8e9916d4742166bab0" meta-oe meta-networking = "sdk-v1.4.x:7c8dd8f096b64a709175d37a08a4fb02ca263616" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 3164 tasks of which 3162 didn't need to be rerun and all succeeded. Create a temporary folder to extract the root filesystem qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release$ mkdir ~/rootfs Extract to the folder qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release$ runqemu-extract-sdk tmp/deploy/images/fsl-image-core-t4240qds-20140218104652.rootfs.tar.gz ../../rootfs (( Note: that the tar.gz file contains the root filesystem of the build and the timestamp in the filename may vary. But essentially the file that has to be extracted will be in the form:                     fsl-image-core-t4240qds-<timestamp>.rootfs.tar.gz )) Adding packages into the root filesystem Follow this set of instructions if you want to add a sample package into the root directory, else these can be skipped. There are multiple ways with which a package can be included, refer the yocto manual for a complete list of techniques. This tutorial gives an easy way to achieve this. In the yocto, main root directory we can find various directories like “meta-*” these directories contain recipes to include packages/kernels etc. These are called layers. To create a package we are going to create a new layer and within which we are going to create a recipe and thereby a .bb file that configures the package. The package that we are showing is the GNU package, htop. (( Note: This set of instructions depends on the packages that is being installed, but this works for mostly GNU-licensed packages )) Move to the home directory qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release $ cd Download the package qoriq@usernsl-Veriton-Series:~$ wget http://hisham.hm/htop/releases/1.0.2/htop-1.0.2.tar.gz --2014-02-24 14:14:40-- http://hisham.hm/htop/releases/1.0.2/htop-1.0.2.tar.gz Resolving hisham.hm (hisham.hm)... 69.163.170.116 Connecting to hisham.hm (hisham.hm)|69.163.170.116|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 388499 (379K) [application/x-tar] Saving to: `htop-1.0.2.tar.gz.1' 100%[======================================>] 3,88,499 169K/s in 2.2s 2014-02-24 14:14:44 (169 KB/s) - `htop-1.0.2.tar.gz.1' saved [388499/388499] Extract the package qoriq@usernsl-Veriton-Series:~$ tar xvf htop-1.0.2.tar.gz Check the md5sum of the package and make note of it qoriq@usernsl-Veriton-Series:~$ md5sum htop-1.0.2.tar.gz 0d01cca8df3349c74569cefebbd9919e htop-1.0.2.tar.gz Check the md5sum of the COPYING file (This is to check the license of the package) Change into the directory qoriq@usernsl-Veriton-Series:~$ cd htop-1.0.2/ Check the md5sum of the package and make note of it qoriq@usernsl-Veriton-Series:~/htop-1.0.2$ md5sum COPYING c312653532e8e669f30e5ec8bdc23be3 COPYING Yocto has a wide set of commands/scripts, yocto-layer is one such command that creates a layer. Initially we are going to create a new layer and within that layer we are going to create a recipe within the layer and the necessary .bb file to configure the package. Move into the yocto directory qoriq@usernsl-Veriton-Series:~$ cd yocto Create the layer qoriq@usernsl-Veriton-Series:~/yocto$ yocto-layer create mylayer Please enter the layer priority you'd like to use for the layer: [default: 6] <hit Enter> Would you like to have an example recipe created? (y/n) [default: n] <hit Enter> Would you like to have an example bbappend file created? (y/n) [default: n] <hit Enter> New layer created in meta-mylayer. qoriq@usernsl-Veriton-Series:~/yocto$ cd meta-mylayer/ Create the package directory qoriq@usernsl-Veriton-Series:~/yocto/meta-mylayer/hello$ mkdir htop Change into directory qoriq@usernsl-Veriton-Series:~/yocto/meta-mylayer/hello$ cd htop Create the config file qoriq@usernsl-Veriton-Series:~/yocto/meta-mylayer/htop$ nano htop_1.0.2.bb (( Note: Naming the .bb file depends on the version of the package that is being included,the format to follow is:                <package-name>_<version number>.bb )) The contents of the bb file should be like: ## File starts here ## DESCRIPTION = "Htop performance monitor" SECTION = "performance monitor" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=c312653532e8e669f30e5ec8bdc23be3" PR = "r0" SRC_URI = "file:///home/qoriq/htop-1.0.2.tar.gz" SRC_URI[md5sum] = "0d01cca8df3349c74569cefebbd9919e" inherit autotools gettext ## File ends here ## Make sure you have entered the md5sum values that you have generated, and they match perfectly. Now the layer you have created should be added into the layers file conf/bblayers.conf This file includes all the layers (of packages, kernels and other configurations) into the build, since we created a new yocto layer we need to include it in this file. Change to build directory qoriq@usernsl-Veriton-Series:~/yocto/meta-mylayer/htop$ cd ../../build_t4240qds_release Open the bblayers file qoriq@usernsl-Veriton-Series:~/yocto/build_t4240qds_release$ nano conf/bblayers.conf Find the BBLAYERS variable: BBLAYERS ?= " \                          /home/qoriq/yocto/meta \                          /home/qoriq/yocto/meta-yocto \                          /home/qoriq/yocto/meta-yocto-bsp \                          /home/qoriq/yocto/meta-fsl-ppc \                          /home/qoriq/yocto/meta-fsl-ppc-toolchain \                          /home/qoriq/yocto/meta-virtualization \                          /home/qoriq/yocto/meta-fsl-networking \                          /home/qoriq/yocto/meta-oe/meta-oe \                          /home/qoriq/yocto/meta-oe/meta-networking \ " Append the location of your layer in the end BBLAYERS ?= " \ /home/qoriq/yocto/meta \ /home/qoriq/yocto/meta-yocto \ /home/qoriq/yocto/meta-yocto-bsp \ /home/qoriq/yocto/meta-fsl-ppc \ /home/qoriq/yocto/meta-fsl-ppc-toolchain \ /home/qoriq/yocto/meta-virtualization \ /home/qoriq/yocto/meta-fsl-networking \ /home/qoriq/yocto/meta-oe/meta-oe \ /home/qoriq/yocto/meta-oe/meta-networking \ /home/qoriq/yocto/meta-mylayer \ " Save and proceed to build (as given above). SD card layout The SD card should contain a single ext2 partition which holds the uImage files and the root filesystem. Insert the SD card into the host machine, and using the mount command figure out the where it is mounted and the tag of the device. Format the disk qoriq@usernsl-Veriton-Series:~$ sudo fdisk /dev/sdc (( Note: The device ID of your SD card can be found out by running the mount command )) Delete all partitions Command (m for help): d Selected partition 1 Print the number of partitions (Hit p and then enter) Command (m for help): p Disk /dev/sdc: 3965 MB, 3965190144 bytes 4 heads, 12 sectors/track, 161344 cylinders, total 7744512 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x558eef06 Device Boot Start End Blocks Id System As expected the partition table shows empty Create new partition (Hit n and press Enter) Command (m for help): n Partition type: p primary (0 primary, 0 extended, 4 free) e extended Select (default p): <Hit Enter> Using default response p Partition number (1-4, default 1): <Hit Enter> Using default value 1 First sector (2048-7744511, default 2048): <Hit Enter> Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-7744511, default 7744511): Using default value 7744511 Print to see new partition (Hit p and then Enter) Command (m for help): p Disk /dev/sdc: 3965 MB, 3965190144 bytes 4 heads, 12 sectors/track, 161344 cylinders, total 7744512 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x558eef06 Device Boot Start End Blocks Id System /dev/sdc1 2048 7744511 3871232 83 Linux Write the changes and exit (Hit w and then Enter) Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used atthe next reboot or after you run partprobe(8) or kpartx(8) Syncing disks. Create the ext2 filesystem in the created partition qoriq@usernsl-Veriton-Series:~$ mkfs.ext2 /dev/sdc1 Copy the kernel image into the SD card qoriq@usernsl-Veriton-Series:~$ sudo cp -d yocto/build_t4240qds_release/tmp/deploy/images/uImage* /media/7e19cd10-3ed8-436d-956c-3fdb14c84e3d/ (( Note: The –d option is necessary, it preserves all symbolic links )) Change into the root directory qoriq@usernsl-Veriton-Series:~ $ cd rootfs Copy root filesystem into the SD card qoriq@usernsl-Veriton-Series:~/rootfs$ sudo cp -Rd * /media/7e19cd10-3ed8-436d-956c-3fdb14c84e3d/ Sync qoriq@usernsl-Veriton-Series:~/rootfs$ sync Unmount qoriq@usernsl-Veriton-Series:~/rootfs$ sudo umount /media/7e19cd10-3ed8-436d-956c-3fdb14c84e3d/ T4240QDS Booting Open the serial console with qoriq@usernsl-Veriton-Series:~ $ sudo gtkterm Open Configuration -> Port and set the Baudrate to 115200. Insert the SD card into the machine and power up. A u-boot prompt appears, hit Enter to disrupt automatic booting. Once you see the u-boot console, you’ll need to configure the environment variables Hit print to see all environment variables, mine look like: => print baudrate=115200 bdev=sda3 bootargs=root=/dev/mmcblk0p1 rw rootdelay=5 console=ttyS0,115200 bootcmd=setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=5 console=$consoledev,$baudrate;mmcinfo;ext2load mmc 0:1 $loadaddr $bootfile;ext2load mmc 0:1 $fdtaddr $fdtfile; bootm $loadaddr - $fdtaddr bootdelay=10 bootfile=uImage c=ffe consoledev=ttyS0 ethact=FM1@DTSEC5 ethprime=FM1@DTSEC1 fdtaddr=0x17200000 fdtfile=uImage-t4240qds.dtb filesize=0x3df080 fman_ucode=0xeff40000 gatewayip=10.116.65.1 hwconfig=fsl_ddr:ctlr_intlv=3way_4KB,bank_intlv=auto;usb1:dr_mode=host,phy_type=utmi ipaddr=10.116.65.32 loadaddr=0x10000000 netdev=eth0 netmask=255.255.255.0 nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr ramdiskaddr=0x02000000 ramdiskfile=t4240qds/ramdisk.uboot rootpath=/opt/nfsroot serverip=10.116.65.38 stderr=serial stdin=serial stdout=serial tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr+$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize uboot="u-boot.bin" ubootaddr=0xeff80000 Environment size: 1564/8188 bytes There are a few variables that you need to modify, and they are: $bootfile – file that is used as a kernel to boot $fdtfile – the device tree file specific to the T4240 from the yocto build $loadaddr – The temporary RAM address to which the kernel is loaded temporarily before being loadedinto the working memory space $fdtaddr – The temporary RAM address to which the device tree is loaded temporarily $bootargs – The boot argument that sets the root parameter to denote where the root filesystem is to be looked for and other variables such as baudrate etc. The values that I set are specific to the files I built, but other variables are common. The $loadaddr should hold a value 0x10000000 The $fdtaddr should hold a value 0x17200000 To set the values : => editenv boot file edit: uImage => editenv fdtfile edit: uImage-t4240qds.dtb => editenv loadaddr edit: 0x10000000 => editenv fdtaddr edit: 0x17200000 => savenenv Now go ahead and boot the machine, with: => setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=5 console=$consoledev,$baudrate;mmcinfo;ext2load mmc 0:1 $loadaddr $bootfile;ext2load mmc 0:1 $fdtaddr $fdtfile; bootm $loadaddr - $fdtaddr (( Note: Break down of the above command: => setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=5 console=$consoledev,$baudrate The previous command sets the location of the root filesystem, in this case, it is the MMC card, /dev/mmcblk0p1 => mmcinfo The above command prints out the details of the MMC card => ext2load mmc 0:1 $loadaddr $bootfile The above command reads the kernel image from the filesystem to the temporary RAM address for the machine to boot => ext2load mmc 0:1 $fdtaddr $fdtfile; The above command reads the fdtfile into RAM memory => bootm $loadaddr - $fdtaddr The above command issues the boot command with kernel addresses and fdt address as inputs )) Here the “root=” variable sets the device ID of the root filesystem and ext2load reads a file from an ext2 filesystem.The boot proceeds and then you see a login prompt with… INIT: Entering runlevel: 5 Starting Dropbear SSH server: dropbear. Starting network benchmark server: netserver. Starting system log daemon...0 Starting kernel log daemon...0 Stopping Bootlog daemon: bootlogd. Poky 9.0 (Yocto Project 1.4 Reference Distro) 1.4 t4240qds ttyS0 t4240qds login: Go ahead and login! t4240qds login: root root@t4240qds:~# You can verify that the build works with root@t4240qds:~# uname -a Linux t4240qds 3.8.13-rt9-QorIQ-SDK-V1.4 #1 SMP Tue Feb 18 12:26:03 IST 2014 ppc64 GNU/Linux The build date shows the date the image was built! If you have included the htop GNU package into the root filesystem, you can test it out. root@t4240qds:~# htop This opens the htop application!!

LS1021xA series product starts to support QSPI flash booting. But booting from QSPI flash isn't the same as booting from SPI flash. QSPI booting use XIP(Execute in place) method just like NOR Flash booting. The memory map start address assigned to QSPI flash is 0x4000000. You need to put your code at the right location. And another key point you should be noted is data endian format between QSPI controller and ARM AMBA AXI bus. Any binary file burned into QSPI Flash should be done Byte-Swap process first. Our Ls1021xA Bsp has provided this function at Tcl script file named “byte_swap.tcl”. Follow the below command to finish this process . tclsh ./byte_swap.tcl ./<original file name>.bin ./<Byte-swap file name>.bin 8 Then Boot up system from SD/MMC media. Burn the image file into QSPI Flash by following commands. =>tftp 0x81000000 rcw_qspiboot_swap.bin (Measure this binary file contains PBI command: 0xee0200, 0x40010000 This is  the Workaround for u-boot address ) => sf probe => sf erase 0 0x10000 => sf write 0x81000000 0 0x100 => tftp 0x82000000 u-boot-qspiboot_swap.bin => sf erase 0x10000 0x90000 => sf write 0x82000000 0x10000 0x80000

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 ]

Virtualization solutions are hardware and software technologies which provide an abstraction layer that enables running multiple operating systems on a single system. There are three kinds of virtualization solutions provided in Freescale Linux SDK, they are KVM/QEMU, Hypervisor(Topaz) and Linux Container. This document introduces Freescale Hypervisor(Topaz) technology. 1 Freescle Hypervisor overview The Freescale hypervisor is a layer of software that enables the efficient and secure partitioning of a multi-core system. Hypervisor is focused on static partitioning (supervised AMP), a system’s CPUs, memory and I/O devices can be divided into logical partitions. These partitions are isolated from one another, and the configuration is fixed until a reconfiguration and the system reboot.  So far, hypervisor is supported on e500mc/e5500/e6500 platform. 1.1 Hypervisor Boot sequence Hypervisor must be booted with an ePAPR compliant boot program such as u-boot. U-boot loads the hypervisor program image into memory, configures the hardware device tree and loads it into memory with the bootargs property on /chosen node set to specify the address of the hypervisor configuration tree. Then u-boot transfer control to the hypervisor image on the boot CPU. Hypervisor initializes each partition and boots guest OS Create a guests device tree and copy to the partition’s memory. Load all images into the partition’s memory as specified by the load-image-table,    guest-image, and linux-rootfs properties. Initializes the virtual CPU Transfer control to the guest operating system on the boot CPU for that partition. 1.2  Guest Physical Address Guest software executing in a partition sees a physical address space created by the hypervisor that may not directly correspond to the true physical addresses in the system hardware. Hypervisor  maintains  this mapping of the guest physical to the true physical addresses, which is completely transparent to guest software. Hardware TLBs contains mapping of guest virtual addresses to true physical addresses. Figure 1-1 guest physical and true physical addresses 1.3 Hypervisor device trees The hypervisor configuration tree contains all hypervisor configuration parameters and partition definition information. Based on this configuration tree, the hypervisor dynamically creates ePAPR-compliant guest device trees for each partition. A guest device tree describes the resources available to the partition including—CPUs, memory, I/O devices, and other virtual resources. Figure 1-2 Hypervisor configuration trees The following is a simple example about partition definition in hypervisor device tree.  The partition contains two CPUs, one memory region, and a UART I/O device. // =============================================== // Partition 1 // =============================================== Part1 {        compatible = “partition”;        cpus = <2 2>;        guest-image = <0 0xe8200000 0  0 0  0x200000>;        linux-rootfs = <0 0xe9000000 0  0 0x01300000 0 0x02800000>;        dtb-window = <0 0x01000000 0 0x10000>;       gpma { compatible = “guest-phys-mem-area”;                                   phys-mem = <&pma1>;                                   guest-addr = <0 0>;      };      Serial2 : serial2 {                Device = “/soc/serial@11d500”; }; }; The cpus property specifies that the partition has 2 CPUs starting at physical#2, cpu 2-3, those cpus map to virtual cpus 0-1 in the partition. The vcpu(virtual CPU)emulates a physical CPU, and the behavior of instructions, registers, and exceptions on the vcpu is nearly identical to the physical CPU being emulated. The guest-image property specifies the source address, destination address, and size of an image to be executed when a partition is started. In the example, the guest’s program image to be loaded is located at true physical 0xe2000000. It is to be copied to guest physical 0x0. The max size of the image is 0x200000. The linux-rootfs property specifies the source/destination and size of Linux root filesystem. The root filesystem image to be loaded is located at physical address 0xe9000000. It is to be copied to guest physical 0x01300000. The max size of the image is 0x02800000. The dtb-window defines a 64KB window at address 0x01000000 where the guest DTB should be loaded. The gpma property defines one guest physical memory area corresponding to physical memory area pmal.  The guest physical area for the gpma is 0x0. 2 . How to Set up Hypervisor In Linux SDK, the default configuration is for setting up hypervisor from NOR Flash, this document will introduce how to modify hypervisor device tree and boot hypervisor system from RAM. 2.1 Modify hypervisor device tree In SDK 1.6 hv.dts, there is a node defining one physical memory area for booting from RAM, so all the images should be deployed inside this area.   images_pma: images_pma { compatible = "phys-mem-area"; addr = <0x0 0x78000000>;  // Used for boot-from-RAM size = <0x0 0x04000000>;  // 64MB   }; Modify the guest images addresses as the following.   part1 { // Indicates that it is a partition node compatible = "partition"; label = "p1-linux"; // CPUs #0 to #6 are assigned to this partition cpus = <0 6>; guest-image = <0x0 0x78020000 0 0 0 0x700000>; linux-rootfs = <0x0 0x79300000 0 0x01300000 0 0x02800000>; dtb-window = <0 0x1000000 0 0x20000>; ... ... part2 { compatible = "partition"; label = "p2-linux"; // CPU #7 is assigned to this partition cpus = <7 1>; guest-image = <0x0 0x78020000 0 0 0 0x700000>; linux-rootfs = <0x0 0x79300000 0 0x01300000 0 0x02800000>; dtb-window = <0 0x1000000 0 0x20000>;              … …   } 2.2 Deploy hypervisor images Under u-boot prompt, deploy the following images. =>tftp 78020000  uImage-p4080ds.bin =>tftp 79300000  fsl-image-core-p4080ds.ext2.gz.u-boot =>tftp 78700000  hv.uImage =>tftp 0x78800000  uImage-p4080ds-usdpaa.dtb =>tftp 0x78900000 hv.dtb Here specify the physical address of hv.dtb from u-boot environment. =>setenv bootargs config-addr=0x78900000 console= ttyS0,115200 =>bootm 0x78700000 - 0x78800000 2.3 Use mux_server to connect to partitions Use the mux_servre to the target board to ensure that individual UART streams are decoded correctly on the host side. mux_server -exec "bft connect P4080DS-1" 18900 18901 18902& Note: “bft connect P4080DS-1” is the command to connect to the UART console. If the device is attached at /dev/ttyS0 and export mux channels, the command should be as the following. mux_server  /dev/ttyS0 18900 18901 18902& socat -,raw,echo=0 tcp:0:18900 socat -,raw,echo=0 tcp:0:18901 socat -,raw,echo=0 tcp:0:18902

ARM Cortex A57 and A53 L1/L2 cache error reporting The attached patch adds error detection for A53 and A57 cores. Hardware error injection is supported on A53. Software error injection is supported on both. For hardware error injection on A53 to work, proper access to L2ACTLR_EL1, CPUACTLR_EL1 needs to be granted by EL3 firmware. This is done by making an SMC call in the driver. Failure to enable access disables hardware error injection. For error interrupt to work, another SMC call enables access to L2ECTLR_EL1. Failure to enable access disables interrupt for error reporting.   CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be used for checking L1 and L2 memory errors. However, only A53 supports double-bit error injection to L1 and L2 memory. This driver uses the hardware error injection when available, but also provides a way to inject errors by software. Both A53 and A57 supports interrupt when multi-bit errors happen.   To use hardware error injection and the interrupt, proper access needs to be granted in ACTLR_EL3 (and/or ACTLR_EL2) register by EL3 firmware SMC call. Correctable errors do not trigger such interrupt. This driver uses dynamic polling internal to check for errors. The more errors detected, the more frequently it polls. Combining with interrupt, this driver can detect correctable and uncorrectable errors. However, if the uncorrectable errors cause system abort exception, this driver is not able to report errors in time.     Building PPA Image Please make sure the PPA source which you are using includes commit 781d7b513c2b44e7, PPA source code in LSDK later than1809, which includes this commit, so you could use PPA image provided in LSDK 1809 or the later release. In addition, You need to enable "dbg" when building PPA. If you use LSDK build environment, please add "dbg" in ppa build command in packages/firmware/Makefile as the following, then rebuild ppa with command "$ flex-builder -c ppa -m ls1043ardb" and get ppa image in build/firmware/ppa/soc-ls1043/ppa.itb. socname=`echo $(MACHINE)|tr -cd [:digit:]` && \ ./build rdb-fit dbg ls$$socname && cp soc-ls$$socname/build/obj/ppa.itb $(FBDIR)/build/firmware/ppa/soc-ls$$socname && \ If you want build PPA manually with the standalone Toolchain, you could build PPA image with the command "./build prod rdb-fit dbg ls1043". Please deploy PPA image at 0x60400000 on NOR flash(the current bank).   L1/L2 cache error detection and correction EDAC feature verification   NXP LSDK 19.03 devel localhost login: root Password: Last login: Fri May 17 00:11:26 UTC 2019 on ttyS0 Welcome to NXP LSDK 19.03 devel (GNU/Linux 4.14.16-dirty aarch64)    * Support:        https://www.nxp.com/lsdk  * Documentation:  https://lsdk.github.io setting 31 rows and 111 columns root@localhost:~# ls /sys/devices/system/edac/cpu_cache/ cpu_cache0  l1_ce_sw_inject  l1_ue_sw_inject  l2_ue_hw_inject  log_ce  panic_on_ue device      l1_ue_hw_inject  l2_ce_sw_inject  l2_ue_sw_inject  log_ue  poll_msec   root@localhost:~#  echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [   74.831916] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [   74.831916] ' echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject^C root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject [   80.192338] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [   80.192338] ' root@localhost:~# root@localhost:~# root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [  109.647966] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  109.647966] ' [  109.659012] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  109.659012] '   root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [  136.271980] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  136.271980] ' [  136.283027] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  136.283027] '   root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject [  157.352298] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 2 [  157.352298] ' root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l2_ue_sw_inject root@localhost:~# [  183.375947] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  183.375947] '   root@localhost:~#  echo 1 > /sys/devices/system/edac/cpu_cache/l2_ue_hw_inject [  186.928679] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  186.928679] ' root@localhost:~# [  191.055944] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  191.055944] '   root@localhost:~# dmesg | grep EDAC [    1.819380] EDAC MC: Ver: 3.0.0 [    3.423554] EDAC DEVICE0: Giving out device to module edac-a53 controller cortex_edac_l1_l2: DEV edac-a53 (POLLED) [   74.831898] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [   74.831910] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [   74.831916] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [   80.192307] EDAC cortex_edac_l1_l2: CPU 1 L1-D Data RAM error(s) detected [   80.192326] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000089000002) [   80.192338] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  109.647919] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [  109.647938] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [  109.647942] EDAC cortex_edac_l1_l2: CPU 1 L1-I Tag RAM error(s) detected [  109.647955] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000080000000) [  109.647966] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  109.659012] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  136.271933] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [  136.271951] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [  136.271956] EDAC cortex_edac_l1_l2: CPU 1 L1-I Tag RAM error(s) detected [  136.271969] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000080000000) [  136.271980] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  136.283027] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  157.352268] EDAC cortex_edac_l1_l2: CPU 2 L1-D Data RAM error(s) detected [  157.352287] EDAC cortex_edac_l1_l2: CPU 2 L1 fatal error(s) detected (0x8000000089180002) [  157.352298] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 2 [  183.375931] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x8000000080000000) [  183.375947] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  186.928662] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x80000000910c4058) [  186.928679] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  191.055928] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x80000000910d0868) [  191.055944] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 root@localhost:~#

This document explains how to burn into target flash the binary files needed to boot the target board with u-boot and/or Linux from a released Digital Networking SDK. Start by identifying the SDK from which to extract the u-boot and Linux binaries.  SDK (and other BSP) files are archived here: http://linux.freescale.net/labDownload2/viewDownloads.php Enter "SDK" as your Filter Text to see only the SDK files. Pick the SDK that you want, and note the .iso files with -IMAGE- in the filenames, organized by processor cores.  For example, T4240 uses the e6500 core, so the IMAGE file with 64-bit binaries from SDK 1.7 would be QorIQ-SDK-V1.7-PPC64E6500-IMAGE-20141218-yocto.iso.  T1040 would use QorIQ-SDK-V1.7-PPCE5500-IMAGE-20141218-yocto.iso for 32-bit binaries, P1010 would use QorIQ-SDK-V1.7-PPCE500V2-IMAGE-20141218-yocto.iso, and so on.  Click on the -IMAGE- file you want and open it as a WinZIP file. The contents of each -IMAGE- .iso file are organized by specific target boards, so expand the WinZIP folder for the board you're using and you'll see the full list of all the files generated by that SDK for your board.  For example, 1.7 SDK for P2020-RDB (E500V2) would look like this: Next, refer to the Infocenter Boards page for details on what files need to go where. Expand the link for your board and click on the Flash Bank Usage link for the board you're using for board-specific details. Finally, refer to the Infocenter's System Recovery chapter for instructions on how to do the flash programming.  The two methods described are: use u-boot to download and program each file; or use the CodeWarrior Flash Programmer to do the same.  Both methods work, so use whichever method is easier. ALTERNATIVE: If you want a fully-loaded Linux system on your target board but you'd rather not have to individually flash a half-dozen files (while perhaps getting one or more of them wrong), most boards have complete, composite binary files in their -IMAGE- .iso archives.  Look in your mounted .iso file for the flash-image folder and you should see a list of files that look similar to this: Each of these _NOR_Flash.bin files includes everything from the RCW to the Linux kernel for the boards noted in their file names.  Program each file to the beginning address of the noted flash type (NAND, NOR, etc.) For example, on T4240-QDS, the beginning address of NOR is 0xE8000000, so program QorIQ_SDK_V1.7_T4240QDS-64B_20141218_NOR_Flash.bin to 0xE8000000. The advantage of this method is that you don't have to program multiple binary files, perhaps picking the wrong file or programming it to the wrong address.  The primary disadvantage is that this method takes a looooooong time since these _Flash.bin files are so large.  Also, you don't get to customize the configuration until after the file has been flashed and the board is up and running.

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]

This application note describes how to write u-boot in SD/MMC card with boot-format application for non-PBL platform. Use QorIQ Configuration Suite (QCS) PBL tool to generate PBL images for Corenet platform SD boot. Deploy Rootfs filesystem to boot Kernel and filesystem from SD/MMC card.

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.

This application note introduces how to install and use Yocto to customize and generate required images. QorIQ SDK 1.6 installation and build environment setting up procedures. Using script fsl-setup-poky to create a build project and explaining specific parameters related with local configuration file. Yocto Image types and generation, and how to modify variables in machine configuration file to generate required images. How to run specific bitbake tasks, and how to configure and rebuild u-boot and Linux Kernel. How to create customized rootfs image recipes to add and remove packages list, use ROOTFS_POSTPROCESS_COMMAND to modify RFS content before image generation. Using merge-files package to add users’ own files into root file system. Creating new package recipes in Yocto build environment.

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.

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

IPSec Performance Reproducibility Procedure on T1040RDB platform 1. Enable ASF in Linux Kernel           Step 1: Launch the kernel menu using the command: bitbake -c menuconfig virtual/kernel      Step 2: Enable ASF under Device Driver -> Networking device support -> Application Specific Fastpath      Step 3: Build the final binaries that needs to be loaded on T1040RDB using the command : bitbake fsl-image-core NOTE: The ASF modules are compiled as dynamically loadable modules and placed in the ROOTFS under the path /usr/driver/asf/min and /usr/driver/asf/full 2. Steps to boot the board with 2 cores:  (optional) => cpu 2 disable => cpu 3 disable => boot Board configuration after Linux is up A. Enable ip_forwarding and Linux performance parameters echo 1 > /proc/sys/net/ipv4/ip_forward echo 9000 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout echo 9000 >/proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream B. Insmod ASF ko’s cd /usr/driver/asf/min insmod asf.ko insmod asfctrl.ko insmod asfipsec.ko insmod asfctrl_ipsec.ko C. Run fmc command : cd /usr/driver/asf/scripts/fmc/ fmc -s Soft_FragParser.xml -p asf-fman-perf-policy.xml -c asf-cfg-perf-2041.xml -a D. Assign interface IP addresses and routes according to setup. Left DUT: ifconfig fm1-gb0 172.18.18.10 netmask 255.255.0.0 up ifconfig fm1-gb3 200.200.200.10/24 up ifconfig fm1-gb1 172.20.20.10 netmask 255.255.0.0 up ifconfig fm1-gb4 20.20.20.10/24 up route add -net 192.168.1.0/24 gw 172.18.18.2 route add default gw 200.200.200.20 route add -net 172.168.1.0/24 gw 172.20.20.2 route add -net 172.168.2.0/24 gw 20.20.20.20 arp -s 172.18.18.2 00:00:00:00:00:01 (optional) arp -s 172.20.20.2 00:00:00:00:00:02 (optional) Right DUT: ifconfig fm1-gb0 172.19.19.10 netmask 255.255.0.0 up ifconfig fm1-gb3 200.200.200.20/24 up ifconfig fm1-gb1 172.21.21.10 netmask 255.255.0.0 up ifconfig fm1-gb4 20.20.20.20/24 up route add -net 192.168.2.0/24 gw 172.19.19.2 route add default gw 200.200.200.10 route add -net 172.168.2.0/24 gw 172.21.21.2 route add -net 172.168.1.0/24 gw 20.20.20.10 arp -s 172.19.19.2 00:00:00:00:00:02 (optional) arp -s 172.21.21.2 00:00:00:00:00:04 (optional) E. Configure IPSec policies and SAs (attached below that needs to be downloaded to the box via tftp or sftp) Left DUT: ./left_tun-4port-v1.txt Right DUT: ./right_tun-4port-v1.txt F. Switch settings killall -9 l2sw_bin l2sw_bin Using UIO: /dev/uio0 Mapped register memory @ 0xb7b3f000 Chipid: 099530e9 fsl_dpa ethernet.17 fm1-gb0: Err FD status = 0x00040000 fsl_dpa ethernet.18 fm1-gb1: Err FD status = 0x00040000 l2switch> l2switch>mac add 00:00:00:00:00:01 3 [MAC 00:00...00:01 is reachable on port 3] m2switch>mac add 00:00:00:00:00:03 7 l2switch>mac add 00:04:9f:03:30:f6 8 [MAC of fm1-gb0] l2switch>mac add 00:04:9f:03:30:f7 9 [MAC of fm1-gb1] l2switch>mac dump [Displays MACDB of switch (static & Dynamic)] Type VID MAC Address Ports ------ --- ----------------- ----- Static 1 00:00:00:00:00:01 3 Static 1 00:00:00:00:00:03 7 Static 1 00:04:9f:03:30:f6 8 Static 1 00:04:9f:03:30:f7 9 Static entries: 4 Dynamic entries: 0 l2switch> l2switch>^Z [Press ctrl+z to stop the process] [1]+ Stopped(SIGTSTP) l2sw_bin root@t1040rdb:/mnt/sridhar/asf-bins/qos/bin/full# killall -9 l2sw_bin G. Configure IXIA/STC to generate the traffic with 128 flows. H. Start the traffic from both end and verify all the flows are offloaded and packet is going through IPSec ASF. Note: Except switch settings everything is similar to previous performance releases by IDC. I. The ASF flow can be observed using the following command cat /proc/asf/flow_debug Script files PFA in attachment

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.

This document introduces how to implement Ethernet flow control in DPDK by setting BMAN hardware and software portal depletion entry and exit thresholds. Hardware and Software Portal Depletion Threshold Registers   BMAN Pool hardware Threshold configuration in DPDK.   Pause Quanta Configuration in DPDK Flow control configuration Implementation in DPDK  

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

Trusted Execution Environment(TEE) is for ARM-based chips supporting TrustZone technology. NXP released LSDK integrates Open Portable TEE(OP-TEE), which is an open source project which contains a full implementation to make up a complete Trusted Execution Environment. This document will introduce OP-TEE architecture, OP-TEE OS loading and initialization, TA and CA communication in OPTEE runtime workflow, how to develop OP-TEE Trusted Application in LSDK environment.

This is a procedure to enable QorIQ GPIOs in Linux Kernel 

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