This topic shows steps to customize LITB by using a different kernel image instead of the existing kernel image. Browse to the FlexBuild installation directory. Modify the kernel image in linux_arm64_LS.its. $ vi configs/linux/linux_arm64_LS.its Save the changes done in the file. Generate LITB using flex-builder. $ source setup.env $ flex-builder -i mkitb -r <distro_type>:<distro_scale> -a <arch> For example: $ source setup.env $ flex-builder -i mkitb -r ubuntu:main -a arm64 INSTRUCTION: mkitb DISTRO TYPE: ubuntu DISTRO SCALE: main .... .... /home/flexbuild_lsdk2004/build/images/lsdk2004_ubuntu_main_LS_arm64.itb [Done]   Note: To create .itb file directly from .its file, run this command: mkimage -f <xyz.its> <xyz.itb> Connect to the board console via terminal and run following commands at U-boot to boot the board with customized LITB. => ping $serverip Using e1000#0 device host 192.168.3.1 is alive => Using e1000#0 device host 192.168.3.1 is alive => tftp 0xa0000000 lsdk2004_ubuntu_main_LS_arm64.itb Using e1000#0 device TFTP from server 192.168.3.1; our IP address is 192.168.3.49 Filename 'lsdk2004_ubuntu_main_LS_arm64.itb'. Load address: 0xa0000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# #################################### 9.8 MiB/s done Bytes transferred = 683506200 (28bd7a18 hex) => bootm 0xa0000000#lx2160ardb ## Loading kernel from FIT Image at a0000000 ... Using 'lx2160ardb' configuration Trying 'kernel' kernel subimage Description: ARM64 Kernel Created: 2021-02-03 6:01:29 UTC Type: Kernel Image Compression: gzip compressed Data Start: 0xa00000d0 Data Size: 14086432 Bytes = 13.4 MiB   Check timestamp in boot log to ensure that the board is booted with the updated kernel image in the customized LITB.   Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083] [ 0.000000] Linux version 5.4.3 (test@Ubuntu-18) (gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)) #1 SMP PREEMPT Wed Feb 3 00:04:09 IST 2021 [ 0.000000] Machine model: NXP Layerscape LX2160ARDB [ 0.000000] earlycon: pl11 at MMIO32 0x00000000021c0000 (options '') [ 0.000000] printk: bootconsole [pl11] enabled [ 0.000000] efi: Getting EFI parameters from FDT:  

To extract kernel, rootfs, and dtb images from the Linux ITB (LITB) image: Browse to the folder containing LITB. For example: $ cd flexbuild_lsdk2004/build/images/ To list the header information of LITB, use the following command: $ dumpimage -l <name of the image> $ dumpimage -l lsdk2004_ubuntu_main_LS_arm64.itb FIT description: arm64 kernel, ramdisk and FDT blob Created: Tue Feb 2 18:54:19 2021 Image 0 (kernel) Description: ARM64 Kernel Created: Tue Feb 2 18:54:19 2021 Type: Kernel Image Compression: gzip compressed Data Size: 14086432 Bytes = 13756.28 kB = 13.43 MB Architecture: AArch64 OS: Linux Load Address: 0x84080000 Entry Point: 0x84080000 Hash algo: crc32 Hash value: 1980d6fd Image 1 (initrd) Description: initrd for arm64 Created: Tue Feb 2 18:54:19 2021 Type: RAMDisk Image Compression: uncompressed Data Size: 668988861 Bytes = 653309.43 kB = 638.00 MB Architecture: AArch64 OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: crc32 Hash value: 24aa3c08 Image 2 (ls1012ardb-dtb) Description: ls1012ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 14335 Bytes = 14.00 kB = 0.01 MB Architecture: AArch64 Hash algo: crc32 Hash value: 383a8118 Image 3 (ls1012aqds-dtb) Description: ls1012aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 15972 Bytes = 15.60 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: 7d133305 Image 4 (ls1012afrwy-dtb) Description: ls1012afrwy-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 15316 Bytes = 14.96 kB = 0.01 MB Architecture: AArch64 Hash algo: crc32 Hash value: 7c456ca3 Image 5 (ls1028ardb-dtb) Description: ls1028ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 19767 Bytes = 19.30 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: db86fa4f Image 6 (ls1028aqds-dtb) Description: ls1028aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 24733 Bytes = 24.15 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: e0b7a722 Image 7 (ls1043ardb-dtb) Description: ls1043ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 41085 Bytes = 40.12 kB = 0.04 MB Architecture: AArch64 Hash algo: crc32 Hash value: fcc6502c Image 8 (ls1043aqds-dtb) Description: ls1043aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 34544 Bytes = 33.73 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: 45f82fba Image 9 (ls1046ardb-dtb) Description: ls1046ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 40270 Bytes = 39.33 kB = 0.04 MB Architecture: AArch64 Hash algo: crc32 Hash value: 013f5024 Image 10 (ls1046aqds-dtb) Description: ls1046aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 34317 Bytes = 33.51 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: be066013 Image 11 (ls1046afrwy-dtb) Description: ls1046afrwy-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 31528 Bytes = 30.79 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: d872df6c Image 12 (ls1088ardb-dtb) Description: ls1088ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 19523 Bytes = 19.07 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: 403066bc Image 13 (ls1088aqds-dtb) Description: ls1088aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 19415 Bytes = 18.96 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: a2bf2786 Image 14 (ls2088ardb-dtb) Description: ls2088ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 29838 Bytes = 29.14 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: 0069fe03 Image 15 (ls2088aqds-dtb) Description: ls2088aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 23557 Bytes = 23.00 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: e8e9dfa7 Image 16 (lx2160ardb-dtb) Description: lx2160ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 32643 Bytes = 31.88 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: e5859b31 Image 17 (lx2160aqds-dtb) Description: lx2160aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 27740 Bytes = 27.09 kB = 0.03 MB Architecture: AArch64 Hash algo: crc32 Hash value: f644de1e To extract a particular image from LITB, use the following command:  $ dumpimage -i <name of the image> -T <type> [-p position] [-o outfile] data_file For example: To extract the kernel image: $ dumpimage -T flat_dt -i lsdk2004_ubuntu_main_LS_arm64.itb -p 0 kernel Extracted: Image 0 (kernel) Description: ARM64 Kernel Created: Tue Feb 2 18:54:19 2021 Type: Kernel Image Compression: gzip compressed Data Size: 14086432 Bytes = 13756.28 kB = 13.43 MB Architecture: AArch64 OS: Linux Load Address: 0x84080000 Entry Point: 0x84080000 Hash algo: crc32 Hash value: 1980d6fd To extract the rootfs image: $ dumpimage -T flat_dt -i lsdk2004_ubuntu_main_LS_arm64.itb -p 1 rootfs Extracted: Image 1 (initrd) Description: initrd for arm64 Created: Tue Feb 2 18:54:19 2021 Type: RAMDisk Image Compression: uncompressed Data Size: 668988861 Bytes = 653309.43 kB = 638.00 MB Architecture: AArch64 OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: crc32 Hash value: 24aa3c08 To extract ls1012ardb-dtb (at position 2) and ls1012aqds-dtb (at position 3): $ dumpimage -T flat_dt -i lsdk2004_ubuntu_main_LS_arm64.itb -p 2 dtb1 Extracted: Image 2 (ls1012ardb-dtb) Description: ls1012ardb-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 14335 Bytes = 14.00 kB = 0.01 MB Architecture: AArch64 Hash algo: crc32 Hash value: 383a8118 $ dumpimage -T flat_dt -i lsdk2004_ubuntu_main_LS_arm64.itb -p 3 dtb2 Extracted: Image 3 (ls1012aqds-dtb) Description: ls1012aqds-dtb Created: Tue Feb 2 18:54:19 2021 Type: Flat Device Tree Compression: uncompressed Data Size: 15972 Bytes = 15.60 kB = 0.02 MB Architecture: AArch64 Hash algo: crc32 Hash value: 7d133305      

Prerequisites: The board should be running Linux and connected to terminal console. Note: For log level debug support, the restool version should be LSDK-2003-RC1 or above and MC version should be 10.20.0 or above. To check restool version: $ root@localhost:~# restool -v restool LSDK-20.04 To check MC version: root@localhost:~# restool -m MC firmware version: 10.24.0 For debugging, use the ls-debug script available in the LSDK rootfs. There is no need to create the debug object. ls-debug -h ls-debug options -h, --help ls-debug help information -ts, --timestamp=X Enable/Disable timestamp printing, X is ON or OFF -c, --console=X Enable/Disable printing in UART console, X is ON or OFF -l, --log=X Enable/Disable printing in DDR log, X is ON or OF -u, --uart=X Set UART ID of the console, X = [0 - 4], 0 = OFF -ll, --level=X Set logging level, X = [0 - 5] 0: Global 1: Debug 2: Info 3: Warning 4: Error 5: Critical -m, mem, --memory Dump information about memory modules available dpxy.z Dump information about MC respective object   For example, to enable logging in console with log level INFO: $ ls-debug --log=on --console=on --level=2 dpdbg.0 created DDR log printing ON UART console printing ON Log level set to 2 $ root@localhost:~# ls-debug --memory Memory dumped information available in MC log/console $ root@localhost:~# cat `find /dev/ -name "*mc_console"` [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_get_obj for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dpdbg_open on DPDBG [I, RESMAN] Handling command: dpdbg_dump on DPDBG [I, DPNI] Memory info: [I, DPNI] MC DDR #1 cacheable memory [I, DPNI] Total: 134217728 bytes [I, DPNI] Used: 14802708 bytes [I, DPNI] Free: 119415020 bytes [I, DPNI] MC DDR #1 non-cacheable memory [I, DPNI] Total: 50331648 bytes [I, DPNI] Used: 27680 bytes [I, DPNI] Free: 50303968 bytes [I, DPNI] DMEM1 memory [I, DPNI] Total: 81920 bytes [I, DPNI] Used: 27168 bytes [I, DPNI] Free: 54752 bytes [I, DPNI] DMEM2 memory [I, DPNI] Total: 81920 bytes [I, DPNI] Used: 27168 bytes [I, DPNI] Free: 54752 bytes [I, DPNI] DDR #1 memory [I, DPNI] Total: 1610612736 bytes [I, DPNI] Used: 143163392 bytes [I, DPNI] Free: 1467449344 bytes [I, DPNI] PEB memory [I, DPNI] Total: 2097152 bytes [I, DPNI] Used: 524288 bytes [I, DPNI] Free: 1572864 bytes [I, DPNI] DP-DDR memory [I, DPNI] Total: 4294967296 bytes [I, DPNI] Used: 0 bytes [I, DPNI] Free: 4294967296 bytes [I, RESMAN] Handling command: dpdbg_close on DPDBG [I, RESMAN] Handling command: dprc_close for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_set_irq_mask for DPRC 1 on portal id 0 [I, RESMAN] Handling command: dprc_set_irq_enable for DPRC 1 on portal id 0 root@localhost:~#

  Note: MCFBA{L/H} that is used to dump the MC log buffer is valid only after the following command is executed: fsl_mc start mc  ${mc_addr} ${dpc_addr} Run the above command first, then MCFBA contents will be valid. To display the MC log buffer in U-Boot for debug purpose, when MC console is not available: Determine the MC firmware base. At the U-Boot prompt, perform md at 0x8340020 (this is MCFBA{L/H}) => md 0x8340020 10 08340020: e0000006 00000027 00060000 00000000 ....'........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ The value at 08340024 is the MCFBAH address. In this case, it is 00000027. The value at 08340020 is the MCFBAL address. In this case, it is e0000000. So you can build the MCFBA base address as:  0x27e0000000. Run the following command to start the MC if it is not booted already. run mcinitcmd Dump the log buffer structure at offset 0x01000000 into the MC firmware base 0x27e1000000 (as per the example). md 27e1000000 27e1000000: 4d430100 00000000 01400000 00300000 ..CM......@...0. 27e1000010: 000000b1 00000000 00000000 00000000 ................ 27e1000020: 00000000 00000000 00000000 00000000 ................ 27e1000030: 00000000 00000000 00000000 00000000 ................ 4d430100 = magic number, 400000 = log buffer offset, 00300000 = log buffer length Dump the content of the log buffer. md 27e1400000   The output size can be increased by specifying the number of objects.  md 27e1400000 <num> For example: md 27e1400000 20 In case that the log buffer has more information, you can extend the output of md by replacing 20 with a greater value.          

To boot a Layerscape board with an empty DPL file: Create an empty DPL file, content.dts. For example: /dts-v1/; / { dpl-version = <0x0000000a>; containers { dprc@1 { compatible = "fsl,dprc"; parent = "none"; options = "DPRC_CFG_OPT_SPAWN_ALLOWED", "DPRC_CFG_OPT_ALLOC_ALLOWED", "DPRC_CFG_OPT_IRQ_CFG_ALLOWED"; objects { obj_set@dpmcp { type = "dpmcp"; ids = <0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd>; }; }; }; }; objects { dpmcp@1 { compatible = "fsl,dpmcp"; }; dpmcp@2 { compatible = "fsl,dpmcp"; }; dpmcp@3 { compatible = "fsl,dpmcp"; }; dpmcp@4 { compatible = "fsl,dpmcp"; }; dpmcp@5 { compatible = "fsl,dpmcp"; }; dpmcp@6 { compatible = "fsl,dpmcp"; }; dpmcp@7 { compatible = "fsl,dpmcp"; }; dpmcp@8 { compatible = "fsl,dpmcp"; }; dpmcp@9 { compatible = "fsl,dpmcp"; }; dpmcp@10 { compatible = "fsl,dpmcp"; }; dpmcp@11 { compatible = "fsl,dpmcp"; }; dpmcp@12 { compatible = "fsl,dpmcp"; }; dpmcp@13 { compatible = "fsl,dpmcp"; }; dpmcp@14 { compatible = "fsl,dpmcp"; }; dpmcp@15 { compatible = "fsl,dpmcp"; }; dpmcp@16 { compatible = "fsl,dpmcp"; }; dpmcp@17 { compatible = "fsl,dpmcp"; }; dpmcp@18 { compatible = "fsl,dpmcp"; }; dpmcp@19 { compatible = "fsl,dpmcp"; }; }; }; ​ Note: There is no network object capable of receiving Ethernet frames in the DPL file. You can create more dpmcps if the number of objects that will be created dynamically is high. Generate the DPL file using content.dts. dtc -I dts -O dtb -o dpl.dtb content.dts​ Flash the DPL file, dpl.dtb to the alternate bank.  tftp 0x80000000 dpl.dtb; i2c mw 66 50 20;sf probe; sf erase 0x00D00000 +$filesize && sf write 0x80000000 0x00D00000 $filesize​ Boot the board. After the board boots, create a dpmac. (Make sure you create a DPMAC that is valid based on the selected SERDES protocol configured by the RCW). restool dpmac create --mac-id=3​ Probe the dpmac driver. restool dprc assign dprc.1 --object=dpmac.3 --plugged=1​ Create a network interface. ls-addni dpmac.3​ Save contents as content_new.dts. restool dprc generate-dpl dprc.1 > content_new.dts​    

The below steps describe how to measure CPU temperature and how to stress individual cores of CPU. Steps are explained with an example of LX2160A SoC. However, these steps are applicable to all Layerscape devices. Download Flexbuild and add packages in Yocto tiny Generate Yocto tiny userland Enable thermal monitoring unit and build kernel Generate .itb image Load .itb image from TFTP server to Layerscape board Validate stress package and measure CPU temperature before and after stress Step 1: Download Flexbuild and add packages in Yocto tiny On a Linux machine, download Layerscape Software Development Kit - <version>. Go to Download tabs at http://www.nxp.com/lsdk. Enter login details, accept the agreement to download the Flexbuild source tarball in the name format flexbuild_<version>.tgz. Run the following commands to extract Flexbuild files from tar archived file. $ tar xvzf flexbuild_<version>.tgz $ cd flexbuild_<verison> $ source setup.env $ flex-builder -h Add “stress” package to "IMAGE_INSTALL_append" parameter of local_arm64_tiny.conf file available in flexbuild_<version>/configs/yocto/ folder. Save and exit the file. Step 2 – Generate Yocto tiny userland Change directory to flexbuild_<version>. Clean obsolete cache data. This step is needed in case source/config has changed. $ source setup.env $ flex-builder -i clean-rfs -r yocto Run the following commands to generate Yocto-based tiny userland: $ flex-builder -i mkrfs -r yocto:tiny $flex-builder -i mklinux -r yocto:tiny $ flex-builder -i mkfw -m <machine_name> -b sd This generates the following images: rootfs_lsdk<version>_yocto_tiny_arm64.cpio.gz (~22M), lsdk<version>_yocto_tiny_LS_arm64.itb, and firmware_<machine_name>_uboot_sdboot.img. For example: rootfs_lsdk2004_yocto_tiny_arm64.cpio.gz (~22M), lsdk2004_yocto_tiny_LS_arm64.itb, and firmware_lx2160ardb_rev2_uboot_sdboot.img Step 3 Enable system monitoring unit and build kernel Change directory to flexbuild_<version>/packages/linux/linux. Enable environmental setting for cross-compiling. The following setting is applicable when you configure and build kernel on a different architecture from the target. For example, compiling an Armv8 kernel on an X86 computer. Run the following commands on Ubuntu Linux: $ export CROSS_COMPILE=aarch64-linux-gnu- $ export ARCH=arm64 Run make menuconfig command to configure settings to enable thermal monitoring unit. $ make menuconfig The command opens the kernel configuration [tree-view structure] prompt. Use the Arrow keys to navigate the menu and Enter to select the submenu. Navigate to Device Drivers --> <*> Generic Thermal sysfs driver --> [ ] Generic CPU cooling support option. Press Y key to include the option. [*] symbol indicates the option is included (shown in below figure). Similarly, include the following options to enable thermal management framework. After you include all options as mentioned in the above table, save the configuration with a file name. For example,  save the configuration file as thermal.config. Exit to come out of the Kernel Configuration prompt. Copy the configuration file to arch/arm64/configs folder. $ cp <config filename> arch/arm64/configs/ For example, $ cp thermal.config arch/arm64/configs/ Configure the kernel. Load the changed configuration for Layerscape Armv8 platform in 64-bit mode for LSDK. $ export CROSS_COMPILE=aarch64-linux-gnu- $ export ARCH=arm64 $ make distclean $ make defconfig <config filename> Build kernel image and device tree image. $ make -j8 Step 4 - Generate .itb file Generate .itb file, which includes stress package and thermal monitoring unit installed, for kernel booting. Copy the Image and Image.gz files from the /flexbuild_<version>/packages/linux/linux/arch/arm64/boot folder and to the /flexbuild_<version>/build/linux/kernel/arm64/LS folder. Change directory to flexbuild_<version>. Generate .itb image using flex-builder. $ source setup.env $ flex-builder -i mkitb -r yocto:tiny This generates lsdk2<version>_yocto_tiny_LS_arm64.itb file. For example, lsdk2004_yocto_tiny_LS_arm64.itb file. Copy the .itb image to the TFTP server. Step 5 - Load .itb image from TFTP server to Layerscape board Set up Ethernet connection between the board (for example, LX2160ARDB) and host machine on which you have configured the TFTP server. Boot the board to U-Boot prompt. U-Boot prints a list of enabled Ethernet interfaces. For example, LX2160ARDB U-Boot prints following Ethernet interfaces. DPMAC2@xlaui4, DPMAC3@xgmii, DPMAC4@xgmii, DPMAC5@25g-aui, DPMAC6@25g-aui, DPMAC17@rgmii-id, DPMAC18@rgmii-id  Set server IP address to the IP address of the host machine on which you have configured the TFTP server. => setenv serverip <ipaddress1> Set ethact and ethprime as the ethernet interface connected to the TFTP server. See LX2160ARDB Ethernet Port Mapping for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux. => setenv ethprime <name of interface connected to TFTP server> For example: => setenv ethprime DPMAC3@xgmii => setenv ethact <name of interface connected to TFTP server> For example: => setenv ethact DPMAC3@xgmii Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr <ipaddress2> => setenv netmask <subnet mask> Dynamic IP address assignment: => dhcp Save the settings. => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using DPMAC3@xgmii device host 192.168.2.1 is alive Load the .itb image from TFTP server to DDR memory of the board. => tftp 0xa0000000 <itb_file_name> For example: => tftp 0xa0000000 lsdk2004_yocto_tiny_LS_arm64.itb Boot the kernel with .itb image as follows: => bootm 0xa0000000#<board_name> For example: => bootm 0xa0000000#lx2160ardb Let the board boots to Tiny Linux. Step 6 – Validate stress package and measure CPU temperature before and after stress Check stress-ng package using which stress-ng command: # which stress-ng /usr/bin/stress-ng Check scaling_current_frequency of the cores. # cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq  For example: Check frequency of 16 cores of LX2160ARDB as follows: Check the temperature of the CPU before applying stress. # cat /sys/class/thermal/thermal_zone*/temp Apply stress by executing following command: # stress-ng -c 8 -i 1 -m 1 --vm-bytes 128M -t 60s & The command applies stress for 60 seconds. For more information on stress-ng command, run stress-ng -h command for help. Check the temperature of the CPU after applying stress. # cat /sys/class/thermal/thermal_zone*/temp For example:

The below steps describe how to measure the CPU power using sensors and also describe how to stress individual cores of CPU. Steps are explained with an example of LX2160A SoC. However, these steps are applicable to all Layerscape devices. Download Flexbuild and add packages in Ubuntu:Lite Generate Ubuntu-based Lite userland (Ubuntu:Lite) Enable system monitoring unit and build kernel Generate .itb image Load .itb image from TFTP server to Layerscape board Validate stress package and measure CPU power using sensors Step 1: Download Flexbuild and add packages in Ubuntu:lite On a Linux machine, download Layerscape Software Development Kit - <version>. Go to Download tabs at http://www.nxp.com/lsdk. Enter login details, accept the agreement to download the Flexbuild source tarball in the name format flexbuild_<version>.tgz. Run the following commands to extract Flexbuild files from tar archived file. $ tar xvzf flexbuild_<version>.tgz $ cd flexbuild_<verison> $ source setup.env $ flex-builder -h Add packages for stress and power sensors in the additional_lite_packages_list file available in the flexbuild_<version>/configs/ubuntu/ folder. Add ‘stress’ and ‘lm-sensors’ packages for Ubuntu Lite as shown below: Save and exit the file. Step 2 – Generate Ubuntu:Lite image Change directory to flexbuild_<version>. Clean obsolete cache data. This step is needed in case the source/configuration has changed. $ source setup.env $ flex-builder -i clean-rfs -r ubuntu:lite Generate Ubuntu-based Lite userland using the following command: $ flex-builder -i mkrfs -r ubuntu:lite This generates rootfs_lsdk<version>_ubuntu_lite_arm64 file. For example: rootfs_lsdk2004_ubuntu_lite_arm64 file. Pack userland in tgz format (Optional step). $ flex-builder -i packrfs -r ubuntu:lite For example: rootfs_lsdk2004_ubuntu_lite_arm64.tgz (~180 M)   Step 3 Enable system monitoring unit and build kernel Change directory to flexbuild_<version>/packages/linux/linux. Enable environmental setting for cross-compiling. The following setting is applicable when you configure and build kernel on a different architecture from the target. For example, compiling an Armv8 kernel on an X86 computer. Run the following commands on Ubuntu Linux: $ export CROSS_COMPILE=aarch64-linux-gnu- $ export ARCH=arm64 Run make menuconfig command to configure settings to enable system monitoring unit for sensing power. $ make menuconfig The command opens the kernel configuration [tree-view structure] prompt. Use the Arrow keys to navigate the menu and Enter to select the submenu. Navigate to Device Drivers --> <*> Hardware Monitoring Support --> [M] Texas Instruments INA219 and compatibles option. Device Drivers-->Hardware Monitoring Support Press Y key to include the option. [*] symbol indicates the option is included (shown in below figure). This enables INA220. Texas Instruments INA219 and Compatibles option included Similarly, include the following options to enable I2C block device driver support and I2C bus multiplexing PC9547. Kernel Configure Tree View Option After you include all options as mentioned in the above table, save the configuration with a file name. For example,  save the configuration file as power.config. Exit to come out of the Kernel Configuration prompt. Copy the configuration file to arch/arm64/configs folder. $ cp <config filename> arch/arm64/configs/ For example, $ cp power.config arch/arm64/configs/ Configure the kernel. Load the changed configuration for Layerscape Armv8 platform in 64-bit mode for LSDK. $ export CROSS_COMPILE=aarch64-linux-gnu- $ export ARCH=arm64 $ make distclean $ make defconfig <config filename> Build kernel image and device tree image. $ make -j8 Step 4 - Generate .itb file Generate .itb file, which includes stress package and thermal monitoring unit installed, for kernel booting. Copy the Image and Image.gz files from the /flexbuild_<version>/packages/linux/linux/arch/arm64/boot folder and to the /flexbuild_<version>/build/linux/kernel/arm64/LS folder. Change directory to flexbuild_<version>. Generate .itb image using flex-builder. $ source setup.env $ flex-builder -i mkitb -r ubuntu:lite This generates lsdk<version>_ubuntu_lite_LS_arm64.itb file. For example, lsdk2004_ubuntu_lite_LS_arm64.itb Copy the .itb image to the TFTP server. Step 5 - Load .itb image from TFTP server to Layerscape board Set up Ethernet connection between the board (for example, LX2160ARDB) and host machine on which you have configured the TFTP server. Boot the board to U-Boot prompt. U-Boot prints a list of enabled Ethernet interfaces. For example, LX2160ARDB U-Boot prints following Ethernet interfaces. DPMAC2@xlaui4, DPMAC3@xgmii, DPMAC4@xgmii, DPMAC5@25g-aui, DPMAC6@25g-aui, DPMAC17@rgmii-id, DPMAC18@rgmii-id  Set server IP address to the IP address of the host machine on which you have configured the TFTP server. => setenv serverip <ipaddress1> Set ethact and ethprime as the ethernet interface connected to the TFTP server. See LX2160ARDB Ethernet Port Mapping  for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux. => setenv ethprime <name of interface connected to TFTP server> For example: => setenv ethprime DPMAC3@xgmii => setenv ethact <name of interface connected to TFTP server> For example: => setenv ethact DPMAC3@xgmii Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr <ipaddress2> => setenv netmask <subnet mask> Dynamic IP address assignment: => dhcp Save the settings. => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using DPMAC3@xgmii device host 192.168.2.1 is alive Load the .itb image from TFTP server to DDR memory of the board. => tftp 0xa0000000 <itb_file_name> For example: => tftp 0xa0000000 sdk2004_ubuntu_lite_LS_arm64.itb Boot the kernel with .itb image as follows: => bootm 0xa0000000#<board_name> For example: => bootm 0xa0000000#lx2160ardb Board boots to Linux prompt. Step 6 – Validate stress package and measure CPU power using sensors Validate if stress and sensors packages have been installed properly. $ which stress ./usr/bin/stress  $ which sensors ./usr/bin/sensors Measure CPU power before applying stress to the cores. $ sensors CPU power before stress Apply stress to CPU cores using the following command. # stress -c <number of cores> -i <number of IO> -m <number of vm> --vm-bytes 128M -t <time in seconds> & For example: The command applies stress for 60 seconds. For more information on stress command, run stress-h command for help. Measure CPU power after applying stress in given time interval. $ sensors

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344564 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344236 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343865 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343717 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343572 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343516     

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343225 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342787 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342651 

  The below steps are used to update composite firmware image in FlexSPI NOR flash and SD/eMMC card using an SD card. Load composite firmware image on SD card Option 1: Using HxD editor on Windows system Option 2: Using Linux system Program updated composite firmware in SD card Program updated composite firmware in FlexSPI NOR flash (DEV#0 and DEV#1) Program updated composite firmware in eMMC card NOTE: Examples shown below use the LX2160ARDB Rev 2 image names. The same examples are applicable for LX2160ARDB Rev 1 also by replacing the Rev 2 image name with the corresponding Rev 1 image name. Step 1: Load composite firmware image in SD card Option 1: Using HxD editor on Windows system The below steps describe how to use an HxD editor on a Windows machine to program firmware image on SD card without partitioning the card. NOTE: Use the following link to download the HxD editor for Windows: https://mh-nexus.de/en/hxd/. Download composite firmware image on Windows machine using the following links: For LX2160ARDB Rev1: For SD boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_sdboot.img For FlexSPI boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_xspiboot.img For eMMC boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_emmcboot.img For LX2160ARDB Rev 2: For SD boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_sdboot.img For FlexSPI boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_xspiboot.img For eMMC boot: https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_emmcboot.img Format SD card. Open HxD editor and run as administrator. Open firmware_lx2160ardb_rev2_uboot_sdboot.img binary file in HxD editor. Copy the binary file (CTRL + A and CTRL + C). Plug the SD card either directly into the slot available on your Windows machine or using a memory card adapter/reader. Open disk (SHIFT + CTRL +D). Open disk NOTE: Uncheck the 'Open as Readonly' option while opening the disk. Go to SD block (or sector) 8 (0x1000). HxD Editor - Sector 8 Paste the copied binary image content (CTRL + B). Make sure to copy the image at SD block no. 8. Save the content. Repeat above steps to load firmware_lx2160ardb_rev2_uboot_xspiboot.img and firmware_lx2160ardb_rev2_uboot_emmcboot.img binary image in SD card. For example: Load firmware_lx2160ardb_rev2_uboot_xspiboot.img image in SD card at block no. 150500 and firmware_lx2160ardb_rev2_uboot_emmcboot.img image in SD card at block no. 300500. NOTE: Make sure that you load these images in SD blocks so that the images do not get overwrite. Eject the SD card. Option 2: Using Linux system Download composite firmware image on Linux machine using the following links: For LX2160ARDB Rev1: For SD boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_sdboot.img For FlexSPI boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_xspiboot.img For eMMC boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_uboot_emmcboot.img For LX2160ARDB Rev 2: For SD boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_sdboot.img For FlexSPI boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_xspiboot.img For eMMC boot: $ wget https://www.nxp.com/lgfiles/sdk/lsdk2004/firmware_lx2160ardb_rev2_uboot_emmcboot.img Format SD card (optional, required if the card already has some data so to ensure that images have been loaded to card without conflicting with the existing data). Load composite firmware image to SD card. For SD boot: dd if=firmware_lx2160ardb_rev2_uboot_sdboot.img of=/dev/sdb bs=512 seek=8 For FlexSPI boot: dd if=firmware_lx2160ardb_rev2_uboot_xspiboot.img of=/dev/sdb bs=512 seek=150500 For eMMC boot: dd if=firmware_lx2160ardb_rev2_uboot_emmcboot.img of=/dev/sdb bs=512 seek=300500 Eject the SD card. Step 2: Program updated composite firmware in SD card NOTE: Since the updated composite firmware is now available at required block (SD start block no. 😎 in SD card, therefore, you can boot the board using SD card using following steps. Insert the SD card in SD slot of LX2160ARDB. Set switch settings to boot from SD card : SW1[1:4] = 1000  Restart the board. The board boots from updated composite firmware (SD boot) image loaded in the SD card. The U-Boot log displays: Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from SD Step 3: Program updated composite firmware in FlexSPI NOR flash (DEV#0 and DEV#1) Insert the SD card in SD slot of LX2160ARDB. Set switch settings to boot from SD card=> SW1[1:4] = 1000 Restart the board and stop at U-Boot prompt. Load firmware_lx2160ardb_rev2_uboot_xspiboot.img at 0xa0000000 (DDR address) using the following command: => mmc read 0xa0000000 <start_block_number> <block_count> where, <start_block_number> - start block number in SD card where you have loaded the firmware. For example, if you have loaded firmware at SD card block 150500, start_block_number in hex is 24be4 <block_count> - number of blocks in SD card that needs to be read as per the file size. It is calculated as ‘file size /512’ + ‘few sectors for rounding up so that last block is not missed’. If firmware file size is 52158124 (31bdeac hex), block_count is 52158124/512 = 101871 (18DEF hex) + 10 (A hex) = 101881 (18DF9 hex). For example: => mmc read 0xa0000000 24be4 18DF9 Program default FlexSPI NOR flash: =>sf probe 0:0 =>sf update 0xa0000000 0x0 <firmware_lx2160ardb_rev2_uboot_xspiboot.img _filesize_in_hex> For example: => sf update 0xa0000000 0x0 31BDEAC    Program alternate FlexSPI NOR flash: => sf probe 0:1 => sf update 0xa0000000 0x0 <firmware_lx2160ardb_rev2_uboot_xspiboot.img _filesize_in_hex>  Restart the board to boot from FlexSPI NOR flash 0 (DEV#0). Switch settings to boot from DEV#0: SW1[1:8] = 1111 1000 The U-Boot log shows the following message: Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from FlexSPI DEV#0 Restart the board to boot from FlexSPI NOR flash 1 (DEV#1) as well. Switch settings to boot from DEV#1 SW1[1:4] = 1111 1001  The U-Boot log shows the following message: Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from FlexSPI DEV#1 Step 4: Program updated composite firmware in eMMC card Insert the SD card in SD slot of LX2160ARDB. Set switch settings to boot from SD card: SW1[1:4] = 1000 Restart the board and stop at U-Boot prompt. Load firmware_lx2160ardb_rev2_uboot_emmcboot.img at 0xa0000000 (DDR address) using the following command: => mmc dev 0; mmc read 0xa0000000 <start_block_number> <block_count> where, <start_block_number> - start block number in SD card where you have loaded the firmware. For example, if you have loaded firmware at SD card block 300500, start_block_number in hex is 495D4 <block_count> - number of blocks in SD card that needs to be read as per the file size. It is calculated as ‘file size /512’ + ‘few sectors for rounding up so that last block is not missed’. If firmware file size is 52158124 (31bdeac hex), block_count is 52158124/512 = 101871 (18DEF hex) + 10 (A hex) = 101881 (18DF9 hex). For example: => mmc read 0xa000000 495D4 18DF9 Program eMMC card. => mmc dev 1; mmc write 0xa0000000 8 18DF9 Restart the board to boot from eMMC. Set switch settings to boot from eMMC card. SW1[1:8] = 1001 1000 The U-Boot log shows the following message: Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from eMMC

Follow these steps to update the Linux kernel image and device tree on the eMMC card. NOTE: Below steps are valid for both LX2160ARDB Rev 1.0 and Rev 2.0 revisions. Compiling Linux kernel images and device tree   On Linux host, clone the repository with Linux kernel image and device tree: $git clone https://source.codeaurora.org/external/qoriq/qoriq-components/linux $ cd Linux $ git checkout -b <new branch> <start point> For example, $ git checkout -b LSDK-20.04-V5.4 LSDK-20.04-V5.4 where LSDK-20.04-V5.4 refers to a tag in the format LSDK-<LSDK version>- V<kernel version> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig lsdk.config If you want to make changes to the device tree, open and edit arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts  You can make changes in the Linux kernel source code also if required. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- The binary kernel image Image and compressed kernel image Image.gz are in arch/arm64/boot/. The device tree blob fsl-lx2160a-rdb.dtb is in arch/arm64/boot/dts/freescale/. Copying the compiled kernel images and device tree to the eMMC card   Step1: Copy the kernel images and device tree from Linux host machine Ensure the eMMC card available on the reference board. Check DIP switch settings for the desired boot type. Power on the board and let the board boot to LSDK distro prompt. In case LSDK image is not deployed on the storage device on the board, execute the following command under U-Boot prompt to boot the board to TinyDistro. For FlexSPI NOR boot: => run xspi_bootcmd For SD/eMMC boot: => run sd_bootcmd Log in to LSDK distro as root/root or TinyDistro as “root”. Bring up a network interface with Linux host. Dynamic IP address assignment: # udhcpc -i <port name in Tiny/LSDKDistro> Static IP address assignment: # ifconfig <port name in Tiny/LSDKDistro> <IP address> netmask <netmask address> up For example: # ifconfig enp1s0 192.168.2.120 netmask 255.255.255.0 up  Copy the Kernel, Kernel.gz images and device tree blob fsl-lx2160a-rdb.dtb from host machine. # mkdir <destination folder> # scp <user>@<ipaddress>:<file path>/<filename> <destination folder> For example: # mkdir /kernelfiles # scp user1@192.168.2.1:/tftpboot/Image.gz /kernelfiles   Step2: Copy the kernel image and device tree to the eMMC card sudo fdisk -l to list the disks that are accessible on board. Mount the eMMC card partition that contains Linux kernel images and device tree. NOTE: Use the command cat /proc/partitions to see the list of devices, their partitions along with their sizes to make sure that the correct device and partition name have been chosen. The eMMC storage drive in the Linux PC is detected as /dev/sdX, where X is a letter such as a, b, c. Make sure to choose the correct device name, because data on this device will be replaced. If your Linux host machine supports read/write eMMC card directly without an extra eMMC card reader device, the device name of eMMC card is typically mmcblk1. In general, the Linux kernel images and device tree are stored in the second partition of the eMMC device (mmcblk1p2). For detail on storage layout on SD/eMMC/USB/SATA for LSDK images deployment, refer to section "LSDK memory layout and Userland" in Layerscape Software Development Kit User Guide. # sudo mkdir <mount_folder> # sudo mount /dev/sdX <mount_folder>  For example: # sudo mkdir /carddata # sudo mount /dev/mmcblk1p2 /carddata Replace Image, Image.gz, and fsl-lx2160a-rdb.dtb on the eMMC card with the new files copied in <destination folder> in the steps above. # sudo cp <destination folder>/Image <destination folder>/Image.gz <destination folder>/fsl-lx2160a-rdb.dtb <mount_location> For example: # sudo cp /kernelfiles/Image /kernelfiles/Image.gz /kernelfiles/fsl-lx2160a-rdb.dtb /carddata Unmount the card. for example: # sudo umount /dev/mmc1blk1p2 Reboot the board. At U-Boot prompt, run the following command to boot the board to LSDK distro using eMMC card. => run bootcmd_mmc1 If U-Boot does not find LSDK on the eMMC card, it will boot TinyDistro from lsdk_linux_arm64_ tiny.itb stored on the eMMC card.    

Trusted Firmware for Cortex-A (TF-A) is an implementation of EL3 secure firmware. TF-A replaces PPA in secure firmware role. Note: Please note the steps listed in this topic can only be performed with LSDK 18.12 and newer releases.                                                                 To migrate to the TF-A boot flow from the previous boot flow (with PPA), you need to compile the TF-A binaries, bl2_<boot_mode>.pbl and fip.bin, and flash these binaries on the specific boot medium on the board. For SD/eMMC boot, you need to compile the following TF-A binaries. TF-A binary name Components bl2_sd.pbl/bl2_emmc.pbl BL2 binary: Platform initialization binary RCW binary for SD/emmc boot  fip.bin BL31: Secure runtime firmware BL32: Trusted OS, for example, OPTEE (optional) BL33: U-Boot/UEFI image   Follow these steps to compile and deploy TF-A  binaries (bl2_sd.pbl/bl2_emmc.pbl and fip.bin) on the SD/eMMC card. Compile RCW binary Compile U-Boot binary [Optional] Compile OPTEE binary  Compile TF-A binaries (bl2_sd.pbl/bl2_emmc.pbl and fip.bin) for SD/eMMC boot Program TF-A binaries to the SD/eMMC card Step 1: Compile RCW binary You need to compile the RCW binary to build the bl2_sd.pbl/bl2_emmc.pbl binary. Clone the  rcw repository and compile the RCW binary.  $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/rcw $ cd rcw $ git checkout -b <new branch name> <LSDK tag>. For example, $  git checkout -b LSDK-20.04 LSDK-20.04 Compile RCW for Rev 1 or Rev 2 board. For LX2160ARDB Rev1: $ cd lx2160ardb For LX2160ARDB Rev2: $ cd lx2160ardb_rev2 If required, make changes to the rcw files. $ make The compiled RCW binary for SD/eMMC boot on LX2160ARDB for core frequency 2000 MHz, platform frequency 700 MHz and DDR memory data rate 2900 MT/s, with serdes1 = 19 serdes2 = 5 serdes3 = 2, rcw_2000_700_2900_19_5_2.bin is available at: rcw/lx2160ardb/XGGFF_PP_HHHH_RR_19_5_2 (For LX2160ARDB Rev 1) rcw/lx2160ardb_rev2/XGGFF_PP_HHHH_RR_19_5_2 (For LX2160ARDB Rev 2) Note: See the rcw/lx2160ardb/README or rcw/lx2160ardb_rev2/README file for an explanation of the naming convention for the directories that contain the RCW source and binary files. Step 2: Compile U-Boot binary You need to compile the u-boot.bin binary to build the fip.bin binary. Clone the u-boot repository and compile the U-Boot binary for TF-A. $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git $ cd u-boot $ git checkout -b <new branch name> LSDK-<LSDK version>. For example, $ git checkout -b LSDK-20.04 LSDK-20.04  $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ make distclean $ make lx2160ardb_tfa_defconfig $ make Note: If the make command shows the error "*** Your GCC is older than 6.0 and is not supported", ensure that you are using Ubuntu 18.04 64-bit version for building the LSDK 18.12 and above U-Boot binary.             The compiled U-Boot binary, u-boot.bin, is available at u-boot/. Step 3: [Optional] Compile OPTEE binary  You need to compile the tee.bin binary to build fip.bin with OPTEE. However, OPTEE is optional, you can skip the procedure to compile OPTEE if you want to build the FIP binary without OPTEE. Clone the optee_os repository and build the OPTEE binary.  $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/optee_os $ cd optee_os $ git checkout -b <new branch name> LSDK-<LSDK version>. For example, $ git checkout -b LSDK-20.04 LSDK-20.04 $ export ARCH=arm $ export CROSS_COMPILE=aarch64-linux-gnu- $ make CFG_ARM64_core=y PLATFORM=ls-lx2160ardb $ aarch64-linux-gnu-objcopy -v -O binary out/arm-plat-ls/core/tee.elf out/arm-plat-ls/core/tee.bin The compiled OPTEE image, tee.bin, is available at optee_os/out/arm-plat-ls/core/. Step 4: Compile TF-A binaries for SD/eMMC boot Clone the atf repository and compile the TF-A binaries, bl2_sd.pbl/bl2_emmc.pbl and fip.bin. $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/atf $ cd atf $  git checkout -b <new branch name> LSDK-<LSDK version>. For example, $ git checkout -b LSDK-20.04 LSDK-20.04 $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- Build BL2 binary with OPTEE. For SD boot: $ make PLAT=lx2160ardb bl2 SPD=opteed BOOT_MODE=sd BL32=<path_to_optee_binary>/tee.bin pbl RCW=<path_to_rcw_binary>/rcw_2000_700_2900_19_5_2.bin For eMMC boot: $ make PLAT=lx2160ardb bl2 SPD=opteed BOOT_MODE=emmc BL32=<path_to_optee_binary>/tee.bin pbl RCW=<path_to_rcw_binary>/rcw_2000_700_2900_19_5_2.bin   The compiled BL2 images, bl2.bin and bl2_sd.pbl/bl2_emmc.pbl are available at atf/build/lx2160ardb/release/. For any update in the BL2 source code or RCW binary, the bl2_sd.pbl/bl2_emmc.pbl binary needs to be recompiled.   To compile the BL2 binary without OPTEE: For SD boot: $ make PLAT=lx2160ardb bl2 BOOT_MODE=sd pbl RCW=<path_to_rcw_binary>/rcw_2000_700_2900_19_5_2.bin    For emmc boot: $ make PLAT=lx2160ardb bl2 BOOT_MODE=emmc pbl RCW=<path_to_rcw_binary>/rcw_2000_700_2900_19_5_2.bin  Build FIP binary with OPTEE and without trusted board boot. $ make PLAT=lx2160ardb fip BL33=<path_to_u-boot_binary>/u-boot.bin SPD=opteed BL32=<path_to_optee_binary>/tee.bin The compiled BL31 and FIP binaries, bl31.bin, fip.bin, are available at atf/build/lx2160ardb/release/. For any update in the BL31, BL32, or BL33 binaries, the fip.bin binary needs to be recompiled.   To compile the FIP binary without OPTEE and without trusted board boot: For SD boot: $ make PLAT=lx2160ardb fip BOOT_MODE=sd BL33=<path_to_u-boot_binary>/u-boot.bin   For eMMC boot: $ make PLAT=lx2160ardb fip BOOT_MODE=emmc BL33=<path_to_u-boot_binary>/u-boot.bin To compile the FIP binary with trusted board boot, refer the read me at <atf repository>/plat/nxp/README.TRUSTED_BOO Step 5: Program TF-A binaries to SD/eMMC card Boot LX2160ARDB from FlexSPI. Ensure that the switches are set to boot the board from FlexSPI. For booting from FlexSPI: SW1[1:8] = 1111 100X [X is 0 for FlexSPI NOR flash0 and X is 1 for FlexSPI NOR flash1] SW2[1:8] = 0000 0110 SW3[1:8] = 1111 1100 SW4[1:8] = 1011 1000 Boot from FlexSPI NOR flash0: => qixis_reset For LX2160ARDB Rev 1, in boot log, you'll see: Board: LX2160ACE Rev1.0-RDB, Board version: B, boot from FlexSPI DEV#0 For LX2160ARDB Rev 2, in boot log, you'll see: Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from FlexSPI DEV#0 Set up Ethernet connection When board boots up, U-Boot prints a list of enabled Ethernet interfaces. DPMAC2@xlaui4, DPMAC3@xgmii [PRIME], DPMAC4@xgmii, DPMAC5@25g-aui, DPMAC6@25g-aui, DPMAC17@rgmii-id, DPMAC18@rgmii-id, e1000#0 Set server IP address to the IP address of the host machine on which you have configured the TFTP server.  => setenv serverip <ipaddress1> Set ethact and ethprime as the Ethernet interface connected to the TFTP server. Note: See LX2160ARDB Ethernet port mapping for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux.                                => setenv ethprime <name of interface connected to TFTP server> For example: => setenv ethprime DPMAC3@xgmii => setenv ethact <name of interface connected to TFTP server> For example: => setenv ethact DPMAC3@xgmii Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr <ipaddress2> => setenv netmask <subnet mask> => setenv gatewayIP <gateway IP> Dynamic IP address assignment: => dhcp Save the settings. => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using DPMAC3@xgmii device host 192.168.1.1 is alive Load TF-A binaries for SD boot from the TFTP server Note: For details about the flash image layout for TF-A binaries, refer LSDK memory layout for TF-A boot flow. Flash bl2_sd.pbl: => tftp 82000000 bl2_sd.pbl => mmc dev 0; mmc write 82000000 8 <blk_cnt> Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load bl2_sd.pbl from the TFTP server, if the bytes transferred is 103353 (193b9 hex), then blk_cnt is calculated as "103353/512 = 201 (C9 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 10 (A hex) sectors, for this example, mmc write command will be: => mmc write 82000000 8 D3 Flash fip.bin: => tftp 82000000 fip.bin => mmc dev 0;  mmc write 82000000 800 <blk_cnt> Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load fip.bin from the TFTP server, if the bytes transferred is 1178967 (11fd57 hex), then blk_cnt is calculated as "1178967/512 = 2302 (8FE hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 10 (A hex) sectors, for this example, mmc write command will be: =>  mmc write 82000000 800 908 Boot from SD card: => qixis_reset sd LX2160ARDB will boot with TF-A. In the boot log, you will see: => NOTICE: BL2: v1.5(release):LSDK-20.04 NOTICE: BL2: Built : 22:01:10, Aug 20 2020 NOTICE: UDIMM 18ADF2G72AZ-3G2E1 NOTICE: DDR4 UDIMM with 2-rank 64-bit bus (x8) NOTICE: 32 GB DDR4, 64-bit, CL=22, ECC on, 256B, CS0+CS1 NOTICE: BL2: Booting BL31 NOTICE: BL31: v1.5(release):LSDK-20.04 NOTICE: BL31: Built : 22:02:07, Aug 20 2020 NOTICE: Welc U-Boot 2019.10 (Aug 14 2020 - 17:43:28 +0530) SoC: LX2160ACE Rev2.0 (0x87360020) Clock Configuration: CPU0(A72):2000 MHz CPU1(A72):2000 MHz CPU2(A72):2000 MHz CPU3(A72):2000 MHz CPU4(A72):2000 MHz CPU5(A72):2000 MHz CPU6(A72):2000 MHz CPU7(A72):2000 MHz CPU8(A72):2000 MHz CPU9(A72):2000 MHz CPU10(A72):2000 MHz CPU11(A72):2000 MHz CPU12(A72):2000 MHz CPU13(A72):2000 MHz CPU14(A72):2000 MHz CPU15(A72):2000 MHz Bus: 700 MHz DDR: 2900 MT/s Reset Configuration Word (RCW): 00000000: 50777738 24500050 00000000 00000000 00000010: 00000000 0c010000 00000000 00000000 00000020: 02e001a0 00002580 00000000 00000096 00000030: 00000000 00000000 00000000 00000000 00000040: 00000000 00000000 00000000 00000000 00000050: 00000000 00000000 00000000 00000000 00000060: 00000000 00000000 00027000 00000000 00000070: 08b30010 00150020 Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from SD Load TF-A binaries for eMMC boot from the TFTP server Note: For details about the flash image layout for TF-A binaries, refer LSDK memory layout for TF-A boot flow. Flash bl2_emmc.pbl: => tftp 82000000 bl2_emmc.pbl => mmc dev 1; mmc write 82000000 8 <blk_cnt> Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load bl2_emmc.pbl from the TFTP server, if the bytes transferred is 103353 (193b9 hex), then blk_cnt is calculated as "103353/512 = 201 (C9 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 10 (A hex) sectors, for this example, mmc write command will be: => mmc write 82000000 8 D3 Flash fip.bin: => tftp 82000000 fip.bin => mmc dev 1; mmc write 82000000 800 <blk_cnt> Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load fip.bin from the TFTP server, if the bytes transferred is 1178967 (11fd57 hex), then blk_cnt is calculated as "1178967/512 = 2302 (8FE hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 10 (A hex) sectors, for this example, mmc write command will be: =>  mmc write 82000000 800 908 Boot from eMMC card: => qixis_reset emmc LX2160ARDB will boot with TF-A. In the boot log, you will see:   => NOTICE: BL2: v1.5(release):LSDK-20.04 NOTICE: BL2: Built : 22:01:10, Aug 20 2020 NOTICE: UDIMM 18ADF2G72AZ-3G2E1 NOTICE: DDR4 UDIMM with 2-rank 64-bit bus (x8) NOTICE: 32 GB DDR4, 64-bit, CL=22, ECC on, 256B, CS0+CS1 NOTICE: BL2: Booting BL31 NOTICE: BL31: v1.5(release):LSDK-20.04 NOTICE: BL31: Built : 22:02:07, Aug 20 2020 NOTICE: Welc U-Boot 2019.10 (Aug 14 2020 - 17:43:28 +0530) SoC: LX2160ACE Rev2.0 (0x87360020) Clock Configuration: CPU0(A72):2000 MHz CPU1(A72):2000 MHz CPU2(A72):2000 MHz CPU3(A72):2000 MHz CPU4(A72):2000 MHz CPU5(A72):2000 MHz CPU6(A72):2000 MHz CPU7(A72):2000 MHz CPU8(A72):2000 MHz CPU9(A72):2000 MHz CPU10(A72):2000 MHz CPU11(A72):2000 MHz CPU12(A72):2000 MHz CPU13(A72):2000 MHz CPU14(A72):2000 MHz CPU15(A72):2000 MHz Bus: 700 MHz DDR: 2900 MT/s Reset Configuration Word (RCW): 00000000: 50777738 24500050 00000000 00000000 00000010: 00000000 0c010000 00000000 00000000 00000020: 02e001a0 00002580 00000000 00000096 00000030: 00000000 00000000 00000000 00000000 00000040: 00000000 00000000 00000000 00000000 00000050: 00000000 00000000 00000000 00000000 00000060: 00000000 00000000 00027000 00000000 00000070: 08b30010 00150020 Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from eMMC  

Follow these steps to update the DPAA2 MC firmware, DPC, and DPL images for the LX2160ARDB on the SD/eMMC card.  Below steps are valid for both LX2160ARDB Rev 1.0 and Rev 2.0 revisions. Compiling MC firmware Clone the qoriq-mc-binary repository. $ git clone https://github.com/NXP/qoriq-mc-binary.git $ cd qoriq-mc-binary/lx2160a/ $ git checkout LSDK-<LSDK version>. For example, $ git checkout LSDK-20.04 The prebuilt MC firmware image, mc_10.20.4_lx2160a.itb, is available at qoriq-mc-binary/lx2160a/. Note: The exact name of the MC firmware image may vary depending on the LSDK release version used.                  Compiling DPC and DPL images Clone the mc-utils repository and compile the DPC and DPL images. $ git clone https://source.codeaurora.org/external/qoriq/qoriq-components/mc-utils $ cd mc-utils/ $ git checkout LSDK-<LSDK version>. For example, $ git checkout LSDK-20.04 If required, make changes to the DPC and DPL files. $ make -C config/ The compiled dpc-usxgmii.dtb and dpl-eth.19.dtb images are available at /mc-utils/config/lx2160a/RDB/. Note: The exact name of the DPL and DPC images may vary depending on the LSDK release version used.             SD/eMMC card start block number for MC, DPL, and DPC images Image  SD/eMMC card start block number DPAA2 MC firmware 0x05000 = 20480 DPAA2 DPL  0x06800 = 26624 DPAA2 DPC 0x07000 = 28672   Refer the LSDK firmware and SD card start block number for complete listing of the SD card start block numbers for all LSDK firmware images.    Programming MC, DPC, and DPL images to SD/eMMC card Boot LX2160ARDB from FlexSPI. Ensure that the switches are set to boot the board from FlexSPI. SW1[1:8] = 1111 1000 SW2[1:8] = 0000 0110 SW3[1:8] = 1111 1100 SW4[1:8] = 1011 1000 Boot from FlexSPI NOR flash0: => qixis_reset For example: For LX2160ARDB, in U-Boot log, you’ll see: Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from FlexSPI DEV#0 Set up Ethernet connection When board boots up, U-Boot prints a list of enabled Ethernet interfaces. DPMAC2@xlaui4, DPMAC3@xgmii, DPMAC4@xgmii, DPMAC5@25g-aui, DPMAC6@25g-aui, DPMAC17@rgmii-id, DPMAC18@rgmii-id    Set server IP address to the IP address of the host machine on which you have configured the TFTP server.  => setenv serverip <ipaddress1> Set ethact and ethprime as the ethernet interface connected to the TFTP server. NOTE: See LX2160ARDB Ethernet Port Mapping for the mapping of Ethernet port names appearing on the chassis front panel with the port names in U-Boot and Linux. => setenv ethprime <name of interface connected to TFTP server> For example: => setenv ethprime DPMAC3@xgmii  => setenv ethact <name of interface connected to TFTP server> For example: => setenv ethact DPMAC3@xgmii  Set IP address of the board. You can set a static IP address or, if the board can connect to a dhcp server, you can use the dhcp command.  Static IP address assignment: => setenv ipaddr <ipaddress2> => setenv netmask <subnet mask> Dynamic IP address assignment: => dhcp Save the settings.       => saveenv Check the connection between the board and the TFTP server. => ping $serverip Using DPMAC3@xgmii device host 192.168.2.1 is alive  Load images from TFTP server Flash MC firmware (mc_10.20.4_lx2160a.itb): => tftp 82000000 mc_10.20.4_lx2160a.itb  Flash MC firmware to SD card: => mmc dev 0; mmc write 8200000 5000 <blk_cnt>  Flash MC firmware to eMMC card: => mmc dev 1; mmc write 8200000 5000 <blk_cnt> Here, blk_cnt refers to number of blocks in SD/eMMC card that need to be written as per the file size. For example, when you load mc_10.20.4_lx2160a.itb from the TFTP server, if the bytes transferred is 1092272 (10aab0 hex), then blk_cnt is calculated as "1092272 /512 = 2133 (855 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 10 (A hex) sectors, for this example, mmc write command will be:  => mmc write 82000000 5000 85F Flash DPAA2 DPL image. => tftp 82000000 dpl-eth.19.dtb Flash DPL image to SD card: => mmc dev 0; mmc write 8200000 6800 <blk_cnt>    Flash DPL image to eMMC card: => mmc dev 1; mmc write 8200000 6800 <blk_cnt> Here, blk_cnt refers to number of blocks in SD/eMMC card that need to be written as per the file size. For example, when you load dpl-eth.19.dtb from the TFTP server, if the bytes transferred is 4583 (11e7 hex), then blk_cnt is calculated as "4583/512 = 8 (8 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 18 (12 hex) sectors, for this example, mmc write command will be:  => mmc write 82000000 6800 12 Flash DPAA2 DPC image.    => tftp 82000000 dpc-usxgmii.dtb  Flash DPC image to SD card: => mmc dev 0; mmc write 8200000 7000 <blk_cnt> Flash DPC image to eMMC card: => mmc dev 1; mmc write 8200000 7000 <blk_cnt> Here, blk_cnt refers to number of blocks in SD card that need to be written as per the file size. For example, when you load dpc-usxgmii.dtb from the TFTP server, if the bytes transferred is 736 (2e0 hex), then blk_cnt is calculated as "736/512 = 1 (1 hex)" + "few sectors for rounding up so that last block is not missed". So, if you round up by 11 (B hex) sectors, for this example, mmc write command will be:  => mmc write 82000000 7000 B Boot the board. Boot from SD card: => qixis_reset sd Boot from eMMC card: => qixis_reset emmc LX2160ARDB will boot with updated MC firmware and DPC and DPL images. In the U-Boot log, you will see:   Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from SD ... ... fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.20.4, boot status: 0x1) Hit any key to stop autoboot:  0 =>   OR   Model: NXP Layerscape LX2160ARDB Board Board: LX2160ACE Rev2.0-RDB, Board version: B, boot from eMMC ... ... fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.20.4, boot status: 0x1) Hit any key to stop autoboot:  0 =>