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

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.

        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>

T4160 Block Diagram

Simple example T4240QDS project that incorporates the Mentor Graphics Embedded Performance Library (MEPL) to add Altivec coding.

Note (11/25): FAEs slowly replying with FAQs. This section is essentially created to help all Freescale Layerscape 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 Freescale QorIQ Processing Platform products.                        Frequently Asked Questions (FAQ) Tips & Tricks QorIQ LS1 Devices QorIQ LS1 Devices QorIQ LS2 Devices QorIQ LS2 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 Freescale Community to grow while mutually helping each other and help reduce design times by providing hands-on solution to tricky problems and questions. QorIQ LS1 Devices LS1020A/LS1021A/LS1022A FAQs LS102x FAQs LS102MA/LS1024A FAQs LS102MA/LS1024A Specific FAQs LS1043A 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 [ top of page ] QorIQ LS1 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 LS2 Devices LS2085A FAQs P2010/P2020 Clocking Specific FAQs P2010/P2020 DDR Specific FAQs P2010/P2020 eSDHC Specific FAQs QorIQ LS2 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 ]

What IDE is recommended for programming the LS1020A/LS1021A/LS1022A? The LS1 series is optimized for CodeWarrior, whose latest version, for ARMv7 can be found at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW-LS-ARM7&fsrch=1. What is the LS102xA product family's enablement schedule up to 2016? The launch calendar for the LS102xA family is shown in the figure below. Can one CodeWarrior license cover both LS102x QDS and TWR? The full CW product can be used with either the TWR or QDS board through the CW-TAP probe. Does CodeWarrior for LS1 support flash (NOR/NAND) programming? Yes, CodeWarrior supports both NOR and NAND programming for QDS and TWR. Over what power range is LS102x designed for? LS102x is designed for operation under 3W.  Its ability to yield over 5000 Coremarks at a frequency of up to 1GHz separates the LS102x family from competitors in delivering improved performance without increased power consumption. How fast does the LS102x family run? The LS102x family can run between 600 MHz and and 1 GHz. What endianness does LS102x follow? The LS1 is based on the ARMv7 architecture, which is natively little-endian.  However, ARMv7 supports big-endian using the CPC15 register.  More significantly, many LS1 peripherals, like Ethernet and integrated flash controller (IFC), follow big-endian.  Therefore, LS1 is really a mixed-endian system and one must be mindful of a peripheral's endianness when programming the LS1.

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:~#

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

Here is the vlan set up folw on P1010RDB.

More and more customers are using the Freescale Linux SDK/BSP for customized development, however, some use a stable but old kernel version. This is different from the Freescale publicly released SDK. In order to manage the gap and help apply the Freescale SDK/BSP more efficiently, Freescale provides backported Linux SDK/BSP according to the customer's kernel version requirements. This lecture summarizes the strategy and key technology of the backport, introduces the latest proactive backport model based on git release and will help expedite product development using Freescale Linux releases.

Here is the NAT set up flow on P1010RDB.

Recently I was handling a problem of E500 Data Cache flush. I have a study on this. Below is a summary/record of the study, here to post it for someone who may be interested in. 1. L1 D-Cache Flushing About Data Cache flush, there’s some description in E500 reference manual as below: Any modified entries in the data cache can be copied back to memory (flushed) by using a dcbf instruction or by executing a series of 12 uniquely addressed load or dcbz instructions to each of the 128 sets. The address space should not be shared with any other process to prevent snoop hit invalidations during the flushing routine. Exceptions should be disabled during this time so that the PLRU algorithm is not disturbed. The following methods can be used to flush a region in the L1 cache: • Perform reads to any 48-Kbyte region, then execute dcbf instructions to that region. Note that a 48-Kbyte region must be used to ensure that the PLRU algorithm flushes all of the cache entries (12 x 128 sets x 32 bits = 48 Kbytes). • Perform reads from any 48-Kbyte region that is guaranteed to not be modified in the L1 cache (for example, a ROM region). • Execute dcbz instructions to any 48-Kbyte scratch section, then invalidate the cache. Note that it is necessary to use a scratch region because some zeroed lines will be cast out. … On the e500v2 the HID0 register contains a field, DCFA (data cache flush assist), that, when set, forces the data cache to ignore invalid sets on miss replacement selection and follow the replacement sequence defined by the PLRU bits. This reduces the series of uniquely addressed load or dcbz instructions to eight per set. The bit should be set just before beginning a cache flush routine and should be cleared when the series of instructions is complete. 2. The Questions As the Data Cache size is 32 Kbytes, why 48 Kbytes region needs to be performed on? The manual uses an equation “12 x 128 sets x 32 bytes = 48 Kbytes” (here I assume it should be 32 bytes instead of 32 bits), it says a series of 12 uniquely addressed load to each of the 128 sets, but there is no explanation why it’s 12, and why uniquely? And more, it mentions the HID0 register filed DCFA. It says setting this field reduces the series of uniquely addressed load to eight per set. Why? This time there are more words “forces the data cache to ignore invalid sets on miss replacement selection and follow the replacement sequence defined by the PLRU bits”, how to understand? 3. Data Cache Basics To answer the questions above, we need to focus on the miss replacement selection algorithm as it refers to. But before this we should be clear about the Data Cache organization first, and know the “invalid sets” status. The E500 reference manual use below figure to describe the L1 D-Cache organization From this figure, we get 128 sets, 8 ways per set, and 32 bytes per way, which is 128 x 8 x 32 = 32 Kbytes. Here a block, also called a line/way, contains 8 words, or 32 bytes. Where a piece of data in memory should be placed into D-Cache? In other words what’s the mapping method between memory and the Cache? Each block is loaded from 8-words boundary, i.e. physical address bits PA[27:31] are zeros. Byte within a block is located by PA[27:31]. The set is selected by physical address bits PA[20:26], totally 2 7 =128, there is one set for each PA[20:26], or we say it’s one to one mapping. The tags consist of physical address bit PA[0:19], there are totally 2 20 kinds of tags but there are only 8 ways in each set, it’s one to multiple mapping. So we need replacement algorithm, in e500 the PLRU (pseudo-least-recently-used) replacement algorithm is used. 4. Miss Replacement In the reference manual it says “This algorithm prioritizes the replacement of invalid entries over valid ones (starting with way 0). Otherwise, if all ways are valid, one is selected for replacement according to the PLRU bit encodings shown in Table 11-8.” This is where the difference happened. Let’s analyze the easy case first, if HID0 register filed DCFA is set, all the ways are treated the same, valid or invalid will be ignored, only PLRU take effect. Assume PLRU bits are all zeros, below table shows the order ways be selected: B0 B1 B2 B3 B4 B5 B6 Ways selected 0 0 0 0 0 0 0 L0 1 1 1 0 0 0 0 L4 0 1 1 0 0 1 0 L2 1 0 1 0 1 1 0 L6 0 0 0 0 1 1 1 L1 1 1 0 0 1 1 1 L5 0 1 1 0 1 0 1 L3 1 0 1 0 0 0 1 L7 After 8 replacements, all the 8 ways are selected. Change PLRU bits to other values it’s still 8 replacements, that’s way it reduce 12 uniquely addressed load to 8. Then why it’s 12 if DCFA field is not set? Assume way 0,1,2,3 are invalid and way 4,5,6,7 are valid, and PLRU bits are all zeros, we have again the table as below: B0 B1 B2 B3 B4 B5 B6 Ways selected 0 0 0 0 0 0 0 L0 1 1 0 1 0 0 0 L1 1 1 0 0 0 0 0 L2 1 0 0 0 1 0 0 L3 1 0 0 0 0 0 0 L4 0 0 1 0 0 1 0 L0 1 1 1 1 0 1 0 L6 0 1 0 1 0 1 1 L2 1 0 0 1 1 1 1 L5 0 0 1 1 1 0 1 L1 1 1 1 0 1 0 1 L7 After 11 replacements, all the 8 ways are selected. Assume way 0,1,2,3,6,7 are invalid and way 4,5 are valid, and PLRU B5 is zero, we have again the table as below: B0 B1 B2 B3 B4 B5 B6 Ways selected - - - - - 0 - L0 1 1 - 1 - 0 - L1 1 1 - 0 - 0 - L2 1 0 - 0 1 0 - L3 1 0 - 0 0 0 - L6 0 0 0 0 0 0 1 L7 0 0 0 0 0 0 0 L0 1 1 1 0 0 0 0 L4 0 1 1 0 0 1 0 L2 1 0 1 0 1 1 0 L6 0 0 0 0 1 1 1 L1 1 1 0 0 1 1 1 L5 After 12 replacements, all the 8 ways are selected. Here 12 is the maximum replacement number, any other case will finish all 8 ways selected within 12 replacements. There are Cache operation code examples in NCSW for e500, including L1 D-Cache flushing, as attached. Also the whole article in attached as individual document.

QorIQ is a important contributor to the Internet of Things with devices such as the LS1 Gateway.  Read more about the Internet of Things! Freescale Expands System Power Management Portfolio to Its QorIQ LS1 Processors for a Secure Internet of Things

SPDK (Storage Performance Development Kit) is an optimized storage reference architecture. It is initiated and developed by Intel. SPDK provides a set of tools and libraries for writing high performance, scalable, user-mode storage applications. It achieves high performance by moving all of the necessary drivers into userspace and operating in a polled mode, like DPDK.

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!!

Open source software development tools for ARM processors