QorIQナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

QorIQ Knowledge Base

ラベル

ディスカッション

ソート順:
QorIQ Device Virtualization with KVM: Performance vs Flexibility
記事全体を表示
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
記事全体を表示
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 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.
記事全体を表示
Time Sensitive Networking(TSN) is an extension to traditional Ethernet networks, providing a set of standards compatible with IEEE 802.1 and 802.3. TSN aims to provide guarantees for deterministic latency and packet loss under congestion, allowing critical and non-critical traffic to be converged in the same network. This document introduces basic concept of Time Sensitive Networking, LS1028 TSN switch and using TSN features on LS1028ARDB. TSN Introduction TSN in LS1028 Using TSN features on LS1028ARDB
記事全体を表示
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 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!!
記事全体を表示
Hello everyone, I have P1010 + FPGA control board. FPGA chip is mounted on the P1010's IFC interface. FPGA and P1010 is isolated by isolate buffer chip. One Norflash chip is also mounted on the P1010's IFC interface too. The file system built on Norflash. The OS read files from file system at any time are correct. Unfortunately, Once the FPGA is running, The OS write file to the file system will cause file system failure. But if the FPGA stop running, the write operate there will be no errors. I use the test fpga code which just have 1 logic and have nothing input or output pin, all pin . O, Who encountered such a issues? How it happened?
記事全体を表示
I have the p2041rdb Borad. (P2041RDB-PB) I got the vxWorks BSP from the WindRiber site. I read a target.ref file. then compiled the bootrom and kernel. I can the Tffs, SATA, .. but I can't Pcie. shell log -> **************************************************************************************************************************************** >vxBusShow Registered Bus Types:   MII_Bus @ 0x002eb1ec   PCI_Bus @ 0x002eae5c   PLB_Bus @ 0x002eae78 Registered Device Drivers:   ppcIntCtlr at 0x002e92c4 on bus PLB_Bus, funcs @ 0x002e92b8   m85xxTimerDev at 0x002eada8 on bus PLB_Bus, funcs @ 0x002ead8c   fslSata at 0x002eb2f8 on bus PLB_Bus, funcs @ 0x002eb2e0   fslDma at 0x002e9f28 on bus PLB_Bus, funcs @ 0x002e9f1c   epic at 0x002ea0bc on bus PLB_Bus, funcs @ 0x002ea068   dtsec at 0x002eb0d0 on bus PLB_Bus, funcs @ 0x002eb000   ns16550 at 0x002ea4a8 on bus PLB_Bus, funcs @ 0x002ea3d8   ns16550 at 0x002ea460 on bus PCI_Bus, funcs @ 0x002ea3d8   dtsecMdio at 0x002eb2a0 on bus PLB_Bus, funcs @ 0x002eb274   genericPhy at 0x002eb234 on bus MII_Bus, funcs @ 0x002eb228   miiBus at 0x002eb1a4 on bus PCI_Bus, funcs @ 0x002eb148   miiBus at 0x002eb164 on bus PLB_Bus, funcs @ 0x002eb148   m85xxPci at 0x002e9e38 on bus PLB_Bus, funcs @ 0x002e9e2c   m85xxCCSR at 0x002ea134 on bus PLB_Bus, funcs @ 0x002ea128   QorIQFman at 0x002ea270 on bus PLB_Bus, funcs @ 0x002ea254   QorIQBman at 0x002ea214 on bus PLB_Bus, funcs @ 0x002ea1f8   fslGpio at 0x002ea1b8 on bus PLB_Bus, funcs @ 0x002ea19c   QorIQQman at 0x002ea350 on bus PLB_Bus, funcs @ 0x002ea32c   QorIQPciEx at 0x002e9edc on bus PLB_Bus, funcs @ 0x002e9e78   QorIQLaw at 0x002ea2ec on bus PLB_Bus, funcs @ 0x002ea2b0   plbCtlr at 0x002eaea0 on bus PLB_Bus, funcs @ 0x002eae94 Busses and Devices Present:   PLB_Bus @ 0x002fe368 with bridge @ 0x002eaee0     Device Instances:         ppcIntCtlr unit 0 on PLB_Bus @ 0x002ff328 with busInfo 0x00000000         epic unit 0 on PLB_Bus @ 0x002ff428 with busInfo 0x00000000         ns16550 unit 0 on PLB_Bus @ 0x002ff628 with busInfo 0x00000000         ns16550 unit 1 on PLB_Bus @ 0x002ff828 with busInfo 0x00000000         ns16550 unit 2 on PLB_Bus @ 0x002ffa28 with busInfo 0x00000000         ns16550 unit 3 on PLB_Bus @ 0x002ffc28 with busInfo 0x00000000         fslGpio unit 0 on PLB_Bus @ 0x002ffe28 with busInfo 0x00000000         QorIQLaw unit 0 on PLB_Bus @ 0x002fff28 with busInfo 0x0         QorIQBman unit 0 on PLB_Bus @ 0x00300028 with busInfo 0x00000000         QorIQQman unit 0 on PLB_Bus @ 0x00300128 with busInfo 0x00000000         QorIQFman unit 0 on PLB_Bus @ 0x00300228 with busInfo 0x00000000         QorIQPciEx unit 1 on PLB_Bus @ 0x0030d328 with busInfo 0x00000000         dtsec unit 0 on PLB_Bus @ 0x0030d628 with busInfo 0x0         dtsec unit 1 on PLB_Bus @ 0x0030d728 with busInfo 0x0         dtsec unit 2 on PLB_Bus @ 0x0030d828 with busInfo 0x0         dtsec unit 3 on PLB_Bus @ 0x0030d928 with busInfo 0x0         dtsec unit 4 on PLB_Bus @ 0x0030da28 with busInfo 0x0         dtsecMdio unit 0 on PLB_Bus @ 0x0030db28 with busInfo 0x00000000         m85xxTimerDev unit 0 on PLB_Bus @ 0x0030dc28 with busInfo 0x00000000         fslSata unit 0 on PLB_Bus @ 0x0030dd28 with busInfo 0x00000000         fslSata unit 1 on PLB_Bus @ 0x0030de28 with busInfo 0x00000000         fslDma unit 0 on PLB_Bus @ 0x0030df28 with busInfo 0x00000000         fslDma unit 1 on PLB_Bus @ 0x0030e028 with busInfo 0x00000000         miiBus unit 0 on PLB_Bus @ 0x0030e128 with busInfo 0x002fefa8         miiBus unit 1 on PLB_Bus @ 0x00312328 with busInfo 0x002fef68         miiBus unit 2 on PLB_Bus @ 0x00312528 with busInfo 0x002fefe8         miiBus unit 3 on PLB_Bus @ 0x00312728 with busInfo 0x002ff028         miiBus unit 4 on PLB_Bus @ 0x00312928 with busInfo 0x002ff068     Orphan Devices:   MII_Bus @ 0x002fefa8 with bridge @ 0x0030e128     Device Instances:         genericPhy unit 0 on MII_Bus @ 0x0030e228 with busInfo 0x00000000     Orphan Devices:   MII_Bus @ 0x002fef68 with bridge @ 0x00312328     Device Instances:         genericPhy unit 1 on MII_Bus @ 0x00312428 with busInfo 0x00000000     Orphan Devices:   MII_Bus @ 0x002fefe8 with bridge @ 0x00312528     Device Instances:         genericPhy unit 2 on MII_Bus @ 0x00312628 with busInfo 0x00000000     Orphan Devices:   MII_Bus @ 0x002ff028 with bridge @ 0x00312728     Device Instances:         genericPhy unit 3 on MII_Bus @ 0x00312828 with busInfo 0x00000000     Orphan Devices:   MII_Bus @ 0x002ff068 with bridge @ 0x00312928     Device Instances:         genericPhy unit 4 on MII_Bus @ 0x00312a28 with busInfo 0x00000000     Orphan Devices: value = 1 = 0x1 -> pciDeviceShow value = -1 = 0xffffffff **************************************************************************************************************************************** I used rcw file that rcw_5g_1500mhz.bin (RR_PH_0x19)
記事全体を表示
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.
記事全体を表示
The NCSW - NetComm Software - is a package to help speed development on Freescale PowerQUICC and QorIQ processor platforms. It contains NCDD - NetComm Device Drivers - and some other components. Here take P3041 I2C supported in version GA_4.7 as an example to analyze the NetComm Software structure and device driver usage. CW PA 10.3 is used to be compatible for the use case code.
記事全体を表示
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
記事全体を表示
DPDK is a user space packet processing framework. OVS-DPDK is a popular software switching package which uses DPDK as the underlying platform. 1. LSDK 1809 Images Deployment 2. Ovs-dpdk Basic Switching 3. Ovs-dpdk MPLS (MultiProtocol Label) Pop_mpls Example 4. DPDK PACKETGEN
記事全体を表示
This is the P2020RDB IPV4 forwarding performace test using SmartBit.
記事全体を表示
This presentation starts by giving  introduction to SDN (Software Defined Networking) and NFV (Network Function Virtualization) technology.  It provides overview of performance challenges and how Freescale hardware & software solutions help in mitigating the performance challenges.
記事全体を表示
Secure edge computing solution is required in secure manufacturing, secure Enrollment, secure device monitoring, secure container and application deployment. This documents introduces trust architecture on Layerscape platform, trust software solution and user application development with OpenSSL Engine to offload encrypt/decrypt on hardware secure module.
記事全体を表示
        A quick demo setup to toggle hue bulb using LS1021A IoT host processor and MKW20 zigbee. Here we make a lighting  demo through two steps setup. The first step is using TWR-KW20 EVB to control hue bulb through PC tool called test tool.  The next step is moving to LS1021 as host processor instead of PC test tool.  We use KW20 USB dongle, LS1021A and Hue Bulb. KW20 USB dongle is configured as Zigbee Coordinator through Beekit and LS1021A connect this KW20 USB dongle, then LS1021A issue On/Off commands to toggle hue bulb. Then you can make a quick demo using Freescale’s LS1021A and MKW20 series
記事全体を表示
When will you have the final version of the ASK append RCX? The final version is already set for mass production. How do you use the crypto engine? The OCF (Open BSD Cryptogrpahic Framework) is a service virtualization layer implemented inside the kernel that provides uniform access to accelerator functionality by hiding card-specific details behind a carefully designed API.  The LS1024A provides an OCF-based cryptographic driver interfacing Linux security applications and the LS1024A Elliptic 1802 crypto accelerator. What is CMM? CMM stands for Conntrack Monitor Module.  It monitors the Linux connection table and adds/removes connection from the PFE connection table. I get an error when adding a bridge entry via CMM. This error usually crops up if a manual bridge command is attempted while the auto-bridge module (ABM) is disabled.  Try enabling the module then make the bridge in Linux.  The ABM will see this and set up PFE appropriately without you having to do any manual bridging commands. What are the power ramping requirements? The power ramping curve of the LS1024A is linear.  Power supplies will begin at almost the same time, but usually from low voltage to high voltage.  Refer to Section 31.2 of the QorIQ LS1024A Data Sheet for further information on this topic. My RTP Relay isn't working properly. Check that the correct sockets have been created properly. How do I make the RGMII work (RGMII delay)? The LS1024A does not have internal RGMII clock/data delays.  The delay element must be enabled in the external device (switch/PHY), or something must be taken care of in layout, which is not recommended.  Typical symptoms are that the GEMAC can only transfer at low speeds (e.g. 10kbps), or the GEMAC can work at 100Mbps/full duplex, but not at 1000Mbps.
記事全体を表示
Hi all, One of the function of this patch is to add MD5 authentication support in Kernel2.6.35. Another is when user set a specific IPSEC encryption and authentication, it will display the information through console. BTW, I'm using P1010RDB for verification. Share with you guys~ 1.       drivers\crypto\caam\Algapi.c +          #define printf(args...)  printk(args) +          #define printf(args...)  printk(args) . . . 164         switch (authsize * 😎 { 165         case 96: 166         -                              if (ctx->alg_op != OP_ALG_ALGSEL_SHA1) { 167         -                                              dev_err(dev, "h/w doesn't support %d-bit ICV trunc." 168         -                                                              " length with chosen authentication algorithm", 169         -                                                              authsize * 8); 170         -                                              return -EOPNOTSUPP; 171         -                              } 172         -                              ctx->class2_alg_type = AUTH_TYPE_IPSEC_SHA1HMAC_96; +                             if (ctx->alg_op == OP_ALG_ALGSEL_MD5){ +                                              ctx->class2_alg_type = AUTH_TYPE_IPSEC_MD5HMAC_96; +                                             printf("AUTH_TYPE : MD5\n"); +                                             if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_AESCBC) +                                                            printf("ALO_TYPE : AES\n"); +                                             else if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_3DESCBC) +                                                            printf("ALO_TYPE : 3DES\n"); +                                             else if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_DESCBC) +                                                            printf("ALO_TYPE : DES\n"); +                              } +                              else if (ctx->alg_op == OP_ALG_ALGSEL_SHA1){ +                                             ctx->class2_alg_type = AUTH_TYPE_IPSEC_SHA1HMAC_96; +                                             printf("AUTH_TYPE : SHA1\n"); +                             if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_AESCBC) +                                                            printf("ALO_TYPE : AES\n"); +                             else if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_3DESCBC) +                                                            printf("ALO_TYPE : 3DES\n"); +                             else if (ctx->class1_alg_type == CIPHER_TYPE_IPSEC_DESCBC) +                                                            printf("ALO_TYPE : DES\n"); +                             } +                             else { +                                             dev_err(dev, "h/w doesn't support %d-bit ICV trunc." +                                              " length with chosen authentication algorithm", +                                              authsize * 8); +                                             return -EOPNOTSUPP; +                              }                                                                break; . . . 1243       static struct caam_alg_template driver_algs[] = { 1244                       /* single-pass ipsec_esp descriptor */ +             { +                             .name = "authenc(hmac(md5),cbc(aes))", +                             .driver_name = "authenc-hmac-md5-cbc-aes-caam", +                             .blocksize = AES_BLOCK_SIZE, +                             .aead = { +                                             .setkey = aead_authenc_setkey, +                                             .setauthsize = aead_authenc_setauthsize, +                                             .encrypt = aead_authenc_encrypt_first, +                                             .decrypt = aead_authenc_decrypt_first, +                                             .givencrypt = aead_authenc_givencrypt_first, +                                             .geniv = "<built-in>", +                                             .ivsize = AES_BLOCK_SIZE, +                                             .maxauthsize = MD5_DIGEST_SIZE, +                                             }, +                             .class1_alg_type = CIPHER_TYPE_IPSEC_AESCBC, +                             .class2_alg_type = AUTH_TYPE_IPSEC_MD5HMAC_96, +                             .alg_op = OP_ALG_ALGSEL_MD5, +                             }, +             { +                             .name = "authenc(hmac(md5),cbc(des3_ede))", +                             .driver_name = "authenc-hmac-md5-cbc-des3_ede-caam", +                             .blocksize = DES3_EDE_BLOCK_SIZE, +                             .aead = { +                                             .setkey = aead_authenc_setkey, +                                             .setauthsize = aead_authenc_setauthsize, +                                             .encrypt = aead_authenc_encrypt_first, +                                             .decrypt = aead_authenc_decrypt_first, +                                             .givencrypt = aead_authenc_givencrypt_first, +                                             .geniv = "<built-in>", +                                             .ivsize = DES3_EDE_BLOCK_SIZE, +                                             .maxauthsize = MD5_DIGEST_SIZE, +                                             }, +                             .class1_alg_type = CIPHER_TYPE_IPSEC_3DESCBC, +                             .class2_alg_type = AUTH_TYPE_IPSEC_MD5HMAC_96, +                             .alg_op = OP_ALG_ALGSEL_MD5, +             }, +             { +                             .name = "authenc(hmac(md5),cbc(des))", +                             .driver_name = "authenc-hmac-md5-cbc-des-caam", +                             .blocksize = DES_BLOCK_SIZE, +                             .aead = { +                                             .setkey = aead_authenc_setkey, +                                             .setauthsize = aead_authenc_setauthsize, +                                             .encrypt = aead_authenc_encrypt_first, +                                             .decrypt = aead_authenc_decrypt_first, +                                             .givencrypt = aead_authenc_givencrypt_first, +                                             .geniv = "<built-in>", +                                             .ivsize = DES_BLOCK_SIZE, +                                             .maxauthsize = MD5_DIGEST_SIZE, +                                             }, +                             .class1_alg_type = CIPHER_TYPE_IPSEC_DESCBC, +                             .class2_alg_type = AUTH_TYPE_IPSEC_MD5HMAC_96, +                             .alg_op = OP_ALG_ALGSEL_MD5, +             }, 1245                       { 1246                                       .name = "authenc(hmac(sha1),cbc(aes))", 1247                                       .driver_name = "authenc-hmac-sha1-cbc-aes-caam", . . 2.       drivers\crypto\caam\compat.h 58           #include <crypto/algapi.h> 59           #include <crypto/aes.h> 60           #include <crypto/des.h> 61           #include <crypto/sha.h> +             #include <crypto/md5.h> 62           #include <crypto/aead.h> 63           #include <crypto/authenc.h> 64           #include <crypto/scatterwalk.h>
記事全体を表示