QorIQ LS1012A BSP v0 - my-boardclub.com · 8.1 OpenSSL Offload User's Guide ... 9.1.4 How to Call...
Transcript of QorIQ LS1012A BSP v0 - my-boardclub.com · 8.1 OpenSSL Offload User's Guide ... 9.1.4 How to Call...
QorIQ LS1012A BSP v0.5
NXP Semiconductors Document Number: QORIQLS1012ABSP05
Rev. 0, Dec 2016
Contents
Chapter 1 SDK Overview................................................................................ 81.1 What's New.......................................................................................................................... 81.2 Components.........................................................................................................................81.3 Known Issues.......................................................................................................................9
Chapter 2 Getting Started.............................................................................122.1 Yocto SDK File System Images......................................................................................... 12
2.1.1 fsl-image-minimal................................................................................................................ 122.1.2 fsl-image-mfgtool.................................................................................................................122.1.3 fsl-image-full........................................................................................................................ 132.1.4 fsl-image-core......................................................................................................................132.1.5 fsl-image-virt........................................................................................................................14
2.2 Essential Build Instructions................................................................................................142.2.1 Install the SDK.................................................................................................................... 142.2.2 Host Environment............................................................................................................... 152.2.3 Setup Poky..........................................................................................................................162.2.4 Builds.................................................................................................................................. 16
2.3 Additional Instructions for Developers................................................................................172.3.1 Customizing U-Boot............................................................................................................ 172.3.2 Customizing Linux Kernel................................................................................................... 182.3.3 Patching Packages..............................................................................................................192.3.4 Extract Source Code...........................................................................................................192.3.5 Customize Root Filesystem................................................................................................ 202.3.6 Native Packages................................................................................................................. 202.3.7 Standalone Toolchain......................................................................................................... 212.3.8 Shared State(sstate) Cache ...............................................................................................212.3.9 Yocto FAQ........................................................................................................................... 212.3.10 BitBake User Manual........................................................................................................ 24
Chapter 3 Deploy U-Boot, Linux Kernel, and Root Filesystem to aReference Design Board (RDB)................................................................25
3.1 Introduction........................................................................................................................253.2 Basic Host Set-up..............................................................................................................253.3 Target Board Set-up...........................................................................................................263.4 Optimzing Boot Flow (Fast Boot).......................................................................................283.5 Supported Boards..............................................................................................................29
3.5.1 LS1012ARDB...................................................................................................................... 303.5.1.1 Overview............................................................................................................................... 303.5.1.2 Switch Settings...................................................................................................................... 303.5.1.3 U-Boot Environment Variables.............................................................................................. 30
3.5.1.3.1 U-Boot Environment Variable "hwconfig"................................................................303.5.1.3.2 Configuring U-Boot Network Parameters............................................................... 31
3.5.1.4 RCW (Reset Configuration Word) and Ethernet Interfaces................................................... 313.5.1.5 System Memory Map............................................................................................................ 313.5.1.6 Flash Bank Usage.................................................................................................................323.5.1.7 Programming a New U-Boot, RCW, and PPA Firmware........................................................333.5.1.8 Deployment........................................................................................................................... 34
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 20162 NXP Semiconductors
3.5.1.8.1 Ramdisk Deployment from TFTP........................................................................... 343.5.1.8.2 Ramdisk Deployment from Flash........................................................................... 353.5.1.8.3 NFS Deployment.................................................................................................... 363.5.1.8.4 SD Deployment...................................................................................................... 36
3.5.1.9 Check 'Link Up' for Serial Ethernet Interfaces....................................................................... 373.5.1.10 Basic Networking Ping Test.................................................................................................38
3.5.2 FRDM-LS1012A.................................................................................................................. 433.5.2.1 Switch Settings..................................................................................................................... 433.5.2.2 U-Boot Environment Variables..............................................................................................43
3.5.2.2.1 U-Boot Environment Variable "hwconfig"............................................................... 433.5.2.2.2 Configuring U-Boot Network Parameters...............................................................44
3.5.2.3 RCW (Reset Configuration Word) and Ethernet Interfaces...................................................443.5.2.4 System Memory Map............................................................................................................453.5.2.5 Flash Bank Usage................................................................................................................ 453.5.2.6 Programming a New U-Boot and RCW.................................................................................463.5.2.7 Deployment...........................................................................................................................47
3.5.2.7.1 Ramdisk Deployment from TFTP........................................................................... 473.5.2.7.2 Ramdisk Deployment from Flash............................................................................473.5.2.7.3 NFS Deployment.................................................................................................... 48
3.5.2.8 Check 'Link Up' for Serial Ethernet Interfaces...................................................................... 493.5.2.9 Basic Networking Ping Test.................................................................................................. 50
Chapter 4 System Recovery.........................................................................544.1 Environment Setup............................................................................................................ 54
4.1.1 Environment Setup (Common)............................................................................................544.2 Image Recovery.................................................................................................................54
4.2.1 Recover system with already working U-Boot.....................................................................544.2.2 Recover system using CodeWarrior Flash Programmer..................................................... 55
Chapter 5 About Yocto Project.................................................................... 575.1 Yocto Project Quick Start................................................................................................... 575.2 Application Development Toolkit User's Guide.................................................................. 575.3 Board Support Packages - Developer's Guide.................................................................. 575.4 Yocto Project Development Manual................................................................................... 575.5 Yocto Project Linux Kernel Development Manual.............................................................. 575.6 Yocto Project Profiling and Tracing Manual........................................................................ 585.7 Yocto Project Reference Manual........................................................................................ 58
Chapter 6 Linux Kernel Drivers....................................................................596.1 Audio..................................................................................................................................59
6.1.1 SAI User Manual LS1012A.................................................................................................. 596.2 DMA Controller ................................................................................................................. 61
6.2.1 Enhanced Direct Memory Access Driver (ARM).................................................................616.2.1.1 eDMA User Manual............................................................................................................... 61
6.3 Enhanced Secured Digital Host Controller (eSDHC).........................................................646.3.1 eSDHC Driver User Manual................................................................................................64
6.4 PCI Express Interface Controller....................................................................................... 696.4.1 PCIe Linux Driver................................................................................................................696.4.2 EDAC Driver User Manual.................................................................................................. 726.4.3 PCIe Advanced Error Reporting User Manual.................................................................... 756.4.4 PCIe Remove and Rescan User Manual............................................................................ 776.4.5 PCIe Endpoint User Manual............................................................................................... 78
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 3
6.5 Packet Forward Engine (PFE) Network Driver.................................................................. 836.5.1 Introduction......................................................................................................................... 83
6.5.1.1 Overview............................................................................................................................... 836.5.1.2 Purpose................................................................................................................................. 836.5.1.3 Features................................................................................................................................ 83
6.5.2 High level decomposition and data flow..............................................................................836.5.3 NAPI support...................................................................................................................... 856.5.4 Interrupt coalescing............................................................................................................ 856.5.5 Checksum offloading.......................................................................................................... 856.5.6 Scatter gather support........................................................................................................ 856.5.7 Ethtool support................................................................................................................... 85
6.6 Real Time Clock (off-chip)................................................................................................. 866.6.1 RTC Driver User Manual (Linux BSP)................................................................................ 86
6.7 SATA Controller..................................................................................................................886.7.1 NXP Native SATA User Manual........................................................................................... 88
6.8 Serial Peripheral Interface................................................................................................. 906.8.1 DSPI Device Driver User Manual........................................................................................90
6.8.1.1 DSPI Device Driver User Manual.......................................................................................... 916.9 Universal Serial Bus Interfaces..........................................................................................92
6.9.1 USB 2.0 Host Driver........................................................................................................... 926.9.1.1 USB 2.0 Host Driver User Manual.........................................................................................92
6.9.2 USB Gadget Network Driver User Manual....................................................................... 1056.9.2.1 USB Gadget for Network Devices.......................................................................................105
6.9.3 USB 3.0 Host/Peripheral Linux Driver User Manual......................................................... 1096.9.3.1 USB 3.0 Host/Peripheral Linux Driver User Manual............................................................110
6.10 Watchdog Timers........................................................................................................... 1206.10.1 Watchdog Device Driver User Manual............................................................................ 120
Chapter 7 Additional Linux Use Cases......................................................1247.1 Power Management..........................................................................................................124
7.1.1 Power Management User Manual......................................................................................1247.1.2 CPU Frequency Switching User Manual............................................................................ 1267.1.3 System Monitor.................................................................................................................. 128
7.1.3.1 Power Monitor User Manual.................................................................................................1287.1.3.2 Thermal Monitor User Manual..............................................................................................1337.1.3.3 Web-based System Monitor User Guide.............................................................................. 135
7.2 Real Time Application Note.............................................................................................. 1377.2.1 Real Time Application Note............................................................................................... 137
Chapter 8 Linux User Space.......................................................................1398.1 OpenSSL Offload User's Guide....................................................................................... 139
8.1.1 Overview........................................................................................................................... 1398.1.1.1 OpenSSL Software architecture...........................................................................................139
8.1.1.1.1 OpenSSL’s ENGINE Interface............................................................................... 1408.1.1.1.2 NXP solution for OpenSSL hardware offloading ...................................................140
8.1.2 Building OpenSSL with hardware offloading support........................................................ 1418.1.3 Nginx offloading with OpenSSL.........................................................................................1418.1.4 Valid TLS Ciphersuites based on TLS protocol version.....................................................143
Chapter 9 Boot Loaders..............................................................................1499.1 Primary Protected Application (PPA) User's Guide.......................................................... 149
9.1.1 Introduction........................................................................................................................149
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 20164 NXP Semiconductors
9.1.1.1 Rationale and Scope............................................................................................................1499.1.1.2 References...........................................................................................................................1499.1.1.3 Definitions............................................................................................................................ 150
9.1.2 Boot Flow Architecture.......................................................................................................1509.1.2.1 LS1043A/LS1012A Boot Flow..............................................................................................150
9.1.3 Loading and Initializing the PPA........................................................................................ 1539.1.4 How to Call SMC/PSCI functions...................................................................................... 1539.1.5 PSCI Function List.............................................................................................................154
9.1.5.1 PSCI_VERSION..................................................................................................................1549.1.5.2 CPU_ON............................................................................................................................. 1559.1.5.3 CPU_OFF............................................................................................................................1559.1.5.4 CPU_SUSPEND................................................................................................................. 1569.1.5.5 AFFINITY_INFO..................................................................................................................1569.1.5.6 SYSTEM_OFF..................................................................................................................... 1579.1.5.7 SYSTEM_RESET................................................................................................................ 1579.1.5.8 PSCI Return Code Values................................................................................................... 1579.1.5.9 PSCI Functions Implemented, by SoC................................................................................ 158
9.1.6 SMC Function List............................................................................................................. 1589.1.6.1 Function Count - SMC64..................................................................................................... 1589.1.6.2 Function Count - SMC32..................................................................................................... 1599.1.6.3 Get UUID.............................................................................................................................1599.1.6.4 Get Revision........................................................................................................................ 159
9.1.7 Building the PPA................................................................................................................1609.1.8 System Considerations When Calling SMC & PSCI Functions......................................... 160
9.2 Secure Boot: PBL Based Platforms.................................................................................1619.2.1 Introduction....................................................................................................................... 1619.2.2 Secure Boot Process........................................................................................................ 1629.2.3 Pre-Boot Phase.................................................................................................................1639.2.4 ISBC Phase...................................................................................................................... 165
9.2.4.1 Flow.................................................................................................................................... 1659.2.4.2 SRKs...................................................................................................................................1669.2.4.3 Key Revocation................................................................................................................... 1669.2.4.4 Alternate Image support..................................................................................................... 1679.2.4.5 ESBC with CSF Header......................................................................................................167
9.2.5 ESBC Phase.....................................................................................................................1679.2.5.1 Boot script...........................................................................................................................168
9.2.5.1.1 Where to place the boot script?............................................................................1689.2.5.1.2 Chain of Trust....................................................................................................... 1689.2.5.1.3 Chain of Trust with Confidentiality........................................................................ 170
9.2.6 Next Executable Phase.....................................................................................................1739.2.7 CST Tool........................................................................................................................... 173
9.2.7.1 KEY GENERATION............................................................................................................. 1739.2.7.1.1 gen_keys............................................................................................................... 1739.2.7.1.2 gen_drv_drbg........................................................................................................1759.2.7.1.3 gen_otpmk_drbg................................................................................................... 176
9.2.7.2 CSF HEADER GENERATION............................................................................................. 1779.2.7.2.1 Default Usage.......................................................................................................1789.2.7.2.2 Verbose Mode.......................................................................................................1819.2.7.2.3 Public Key/ SRK Hash Generation Only............................................................... 1829.2.7.2.4 Key Extension.......................................................................................................1829.2.7.2.5 Image Hash Generation....................................................................................... 1899.2.7.2.6 Help...................................................................................................................... 190
9.2.7.3 Code Signing Tool Walkthrough...........................................................................................1909.2.8 Product execution..............................................................................................................192
9.2.8.1 Getting started.................................................................................................................... 192
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 5
9.2.8.1.1 Environment for Secure Boot................................................................................1929.2.8.1.2 SDK Images required for the demo...................................................................... 192
9.2.8.2 Chain of Trust......................................................................................................................1939.2.8.2.1 Other Images Required for demo.........................................................................1939.2.8.2.2 Bootscript and Signing the images...................................................................... 1939.2.8.2.3 Running secure boot (Chain of Trust).................................................................. 197
9.2.8.3 Chain of Trust with Confidentiality.......................................................................................1989.2.8.3.1 Other Images Required for demo.........................................................................1999.2.8.3.2 Encap Bootscript..................................................................................................1999.2.8.3.3 Decap Bootscript................................................................................................. 1999.2.8.3.4 Creating CSF Headers.........................................................................................2009.2.8.3.5 Running secure boot (Chain of Trust with Confidentiality)................................... 200
9.2.8.4 NAND Secure Boot (Chain of Trust)................................................................................... 2029.2.8.4.1 Running NAND Secure boot (Chain of Trust)...................................................... 202
9.2.8.5 NAND Secure Boot (Chain of Trust with Confidentiality).................................................... 2049.2.8.5.1 Running NAND Secure boot (Chain of Trust with Confidentiality)....................... 205
9.2.9 Troubleshooting.................................................................................................................2079.2.10 CSF Header Data Structure Definition............................................................................ 2079.2.11 ISBC Validation error codes............................................................................................ 2259.2.12 ESBC Validation error codes.......................................................................................... 2309.2.13 Address Map used for demo...........................................................................................2329.2.14 Useful U-Boot and CCS Commands...............................................................................2399.2.15 Trust Architecture and SFP Information.......................................................................... 2459.2.16 QCVS Tool Usage...........................................................................................................245
Chapter 10 Virtualization............................................................................ 25210.1 KVM/QEMU................................................................................................................... 252
10.1.1 KVM/QEMU Release Notes............................................................................................ 25210.1.2 KVM for ARM Architecture Users Guide and Reference................................................. 252
10.1.2.1 Introduction to KVM and QEMU........................................................................................ 25210.1.2.1.1 Overview............................................................................................................. 25210.1.2.1.2 Organization of this Document............................................................................25310.1.2.1.3 Virtual Machine Overview................................................................................... 25410.1.2.1.4 Introduction to KVM and QEMU..........................................................................25410.1.2.1.5 Device Tree Overview......................................................................................... 25610.1.2.1.6 References..........................................................................................................25610.1.2.1.7 For More Information...........................................................................................257
10.1.2.2 Building QEMU and KVM.................................................................................................. 25710.1.2.2.1 Overview.............................................................................................................25710.1.2.2.2 Building Linux with KVM..................................................................................... 25710.1.2.2.3 Building QEMU...................................................................................................26110.1.2.2.4 Creating a host Linux root filesystem..................................................................261
10.1.2.3 Using QEMU and KVM......................................................................................................26210.1.2.3.1 Overview of Using QEMU...................................................................................26210.1.2.3.2 Virtual Machine Memory.................................................................................... 26410.1.2.3.3 Virtual network interfaces................................................................................... 26510.1.2.3.4 VMs and the Linux Scheduler.............................................................................265
10.1.2.4 Virtual machine reference..................................................................................................26610.1.2.4.1 VM Overview...................................................................................................... 26610.1.2.4.2 Memory Map of Virtual I/O Devices....................................................................26610.1.2.4.3 Virtual machine state at initialization.................................................................. 26710.1.2.4.4 Virtual CPUs.......................................................................................................26810.1.2.4.5 VGIC...................................................................................................................268
10.1.2.5 Debugging virtual machines.............................................................................................. 269
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 20166 NXP Semiconductors
10.1.2.5.1 QEMU Monitor....................................................................................................26910.1.2.5.2 QEMU GDB Stub................................................................................................269
10.1.2.6 KVM/QEMU How-to's........................................................................................................ 27110.1.2.6.1 Quick-start Steps to Build and Deploy KVM Using Yocto................................... 27110.1.2.6.2 Quick-start Steps to Run KVM Using Hugetlbfs................................................. 27310.1.2.6.3 How to Use Virtual Network Interfaces Using Virtio........................................... 27510.1.2.6.4 How to use vhost-net with virtio..........................................................................27610.1.2.6.5 Debugging: How to Examine Initial Virtual Machine State with QEMU.............. 27710.1.2.6.6 Debugging: How to Profile Virtualization Overhead with KVM............................278
Contents
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 7
Chapter 1SDK Overview
1.1 What's NewNXP Digital Networking is pleased to announce the release of LS1012A BSP v0.5 supporting LS1012A rev 1.0 processor onRDB and FRDM boards.. This is the follow on release to SDK v0.4 release. The additional functionalities supported in thisrelease are Checksum offload to PFE hardware, 2.5G SGMII Ethernet support (QDS only), memcpy offload to CAAM's DMA,PSCI enabled for 32-bit, power management support in 32-bit kernel, support for Rev D RDB and Rev C FRDM.
For more information on QorIQ LS1012A see the QorIQ LS1012A Low Power Communication Processor summary page.
1.2 ComponentsTop-level components in LS1012A SDK
• Yocto
• GNU Toolchain
• U-Boot Boot Loader
• Linux Kernel and Virtualization
• Linux Kernel and Device Drivers
• Reduced system boot time
Yocto and Toolchain
• Yocto/Poky 2.0 "jethro"
• gcc-linaro-4.9-r2015.06, glibc-linaro-2.20-r2014.11, binutils-linaro-2.25-r2015.01, gdb-7.10.1
U-Boot Boot Loader
• U-Boot 2016.01
• ARMv8 core
• Primary Protected Application (PPA)
• Non-secure boot, Generic Timers, DDR, I2C, QSPI flash, UART1, USB 3 mass storage & Gadget, PFE based Ethernetsupport
• LS1012A RDB : DSPI, eSDHC, PCIe, SATA, USB 2 mass storage, Secure Boot (QSPI as source)
Linux Kernel Core, Virtualization
• Linux kernel 4.1.8
• Real Time
• ARMv8: AARCH64, 64-bit effective addressing, Kernel-based Virtual Machine (KVM)
• ARMv8: AARCH32 (Components not supported in 32 bit mode - PPA, Power Management, Real Time, Linux kernel Cryptodriver , Secure Boot)
Linux Kernel Device Drivers
SDK Overview
What's New
QorIQ LS1012A BSP v0.5, Rev. 0, December 20168 NXP Semiconductors
• Crypto driver supporting SEC 5 (CAAM)
• DDR, DUART, DSPI, I2C
• PFE Ethernet (Packet Rx/Tx)
• PHY support: RGMII, SGMII
• SAI/I2S
• UART, USB 3 mass storage
• Watchdog
• LS1012A RDB : DSPI, eSDHC, PCIe, PHY (RGMII), SATA, USB 2 mass storage
1.3 Known Issues
ID Description Disposition Opened in Resolved in Workaround
QLINUX-6520 Latency is beyond125us whentesting rt_ptsemaon LS1012ARDB.
Open LS1012A BSP v0.5
QLINUX-5894 The latency whenrunning cyclictestis heavier withipfwd run.
Open LS1012A BSP v0.5
QLINUX-5875 Kernel call traceduringrt_fully_pistress_test run.
Open LS1012A BSP v0.5
QUBOOT-1682 Checkpatch Errorsin PFE module.
Open LS1012A BSP v0.5
QLINUX-5883 The ppfe port doesnot work afterpowermanagement isentered and exitedrepeatedly.
Open LS1012A BSP v0.5
QLINUX-5841 Linux IPfwd forsmall frame sizehas moredegradationcompared withSDK v0.2 onLS1012ARDB.
Open LS1012A BSP v0.5
Table continues on the next page...
SDK Overview
Known Issues
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 9
Table continued from the previous page...
QLINUX-6522 The kernel couldnot resume andcall trace whentesting PM onLS1012ARDB.
Open LS1012A BSP v0.5
QLINUX-6529 Sec self for CE andNeon tested failedonls1012ardb-32bit.
Open LS1012A BSP v0.5
QLINUX-5768 LS1012:rmmod ofPFE modulescrashes thekernel.
Open LS1012A SDKv0.2
QSDK-3237 LS1012A PPA:PPA binary is notgetting detectedwith BSP 0.5firmware.
Resolved LS1012A BSP v0.5 LS1012A BSP v0.5
QLINUX-5876 Kernel Call Tracewhile testingce_sec_tcrypto_aes with 32-bitkernel.
Resolved LS1012A SDKv0.4
LS1012A BSP v0.5
QLINUX-5877 Error message“DMA Error”appears whiletestingsec_tcrypto_3desandsec_tcrypto_aeswith 32-bit kernel.
Resolved LS1012A SDKv0.4
LS1012A BSP v0.5
QLINUX-5878 Kernel hang whentestingsec_tcrypto_deswith 32-bit kernel.
Resolved LS1012A SDKv0.4
LS1012A BSP v0.5
QLINUX-6508 Kernel crashesduring boot with64K pagesize.
Resolved LS1012A SDKv0.4
LS1012A BSP v0.5
Table continues on the next page...
SDK Overview
Known Issues
QorIQ LS1012A BSP v0.5, Rev. 0, December 201610 NXP Semiconductors
Table continued from the previous page...
QUBOOT-1737 If code warrior isused to program u-boot or RCW, theflash gets intoinvalid state.
Resolved LS1012A SDKv0.3
LatestCodeWarriorRelease
Use Code-Warriorto program the 64MB SDK image(LS1012) therebyprogramming theentire flash. Afterpower recycle, theboard will startfunctioning.
QUBOOT-1691 USB 3.0 USBHarddiskenumeration issueis faced withcertain disks.
Resolved/Duplicate
LS1012A SDKv0.3
LS1012A BSP v0.5
QSDK-2982 Inconsistentbehavior whilereading QSPIusing U-boot cmds"sf read" and "md"commands.
Not an Issue LS1012A SDKv0.3
LS1012A BSP v0.5
QLINUX-5849 Jumboframefloodping causescall trace with 64-bit kernel.
Resolved LS1012A SDKv0.3
LS1012A BSP v0.5
SDK Overview
Known Issues
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 11
Chapter 2Getting Started
Yocto Project is an open-source collaboration project for embedded Linux developers. Yocto Project uses the Poky buildsystem to make Linux images. For complete information about Yocto Project, see https://www.yoctoproject.org/.
2.1 SDK File System ImagesThis section describes the file system images that can be built using standard Yocto Project recipes included with the NXPSDK.
The file system images contain the programs, scripts, and other files that make up Linux user space. There are five standardimages. They are described in the following sections.
In the SDK installation directory, look in meta-freescale/recipes-fsl/images for files that define these images.
Where to start: “fsl-image-full” contains a rich set of standard Linux features and all special NXP SDK-specific features.It is the best starting point for exploration and evaluation.
2.1.1 fsl-image-minimal: A Barebones Starting Point forProducts
Contents:
This is a barebones image. It contains a small file set that allows Linux to boot and little else.
Purpose:
This image is intended as a starting point for product development. Users may add packages to it to form an image thattargets their particular project or purpose. Packages may be added by editing conf/local.conf and adding new packages tobe built and installed via
IMAGE_INSTALL_append = " package1 package2 etc"
Then, rebuild the image using bitbake. The result will be an image that is small enough for simple flash devices and is narrowlyfocused on a specific goal.
Users must add packages to “fsl-image-minimal” to make it useful. Thus it is not intended for “out-of-the-box” evaluation.Instead, use it as the basis for targeted images for your specific product.
2.1.2 fsl-image-mfgtool: A Small Flash Image for ManagingDisks and Larger Images
Contents:
This is a small image that NXP preprograms into the flash on development boards. On many boards, the image is stored ina NOR flash and is loaded into a RAM disk when Linux boots. It contains disk management functions as described in thenext section.
Purpose:
This image is intended to help users to load much larger images onto disks or disk-like devices such as SDHC cards or USBthumb drives. Thus, this image contains networking support to transfer images and also standard Linux disk and file systemmanipulation commands.
NXP preloads “fsl-image-full” (see below) onto disks on development boards that have them. For these boards, “fsl-image-mfgtool” can be used to restore the larger disk image if it becomes corrupted.
Getting Started
SDK File System Images
QorIQ LS1012A BSP v0.5, Rev. 0, December 201612 NXP Semiconductors
Users will find that it is often convenient to work with larger images and may wish to install “fsl-image-full” onto a disk-typedevice and use it with NXP development boards that do not come with a disk drive.
The networking and disk management commands that NXP supplies are standard Linux commands. They are, in fact,identical on all architectures and thus are not unique to NXP. Users with Linux experience will find them familiar. They include:
• ifconfig, ip, route, etc. (configure networking)
• ftp (transfer files via the network)
• scp (another way to transfer files via the network)
• date and rdate (set date and time)
• fdisk (partition disks and disk-type devices)
• mkfs (make file systems)
• tar (extract file system images, and more)
• fsck (check file systems)
• mount/umount (mount and umount file systems)
2.1.3 fsl-image-full: A Full-Featured Image, Useful Out-of-BoxContents:
This is a large image that contains many standard Linux commands and features including native (target-resident) versionsof the GNU tools including gcc and gdb.
If you boot this image, the resulting Linux environment will be much like a command-line on a full desktop-type Linux systemrather than an embedded system.
Purpose:
While this type of image may not be appropriate for a final embedded product, it can be very helpful for many developmentand evaluation tasks. The reason is the full set of standard Linux facilities that are already present in the image. In fact, usersmay find that they can use this image instead of installing the Yocto Project-based NXP SDK onto a development system, atleast initially.
For this reason, “fsl-image-full” is preinstalled on the disk drives of NXP development boards that have disks.
For example, the image is complete enough that the standard Linux open source command sequence “configure; make”stands a decent chance of working for arbitrary open source packages that do not happen to be on the image already.
To be clear, the NXP SDK is a Yocto Project/Poky-derived embedded distribution. However, the Yocto Project standard Linuxpackage set is large enough that if one enables a lot of the available packages, the result begins to have the feel of desk topLinux. NXP added the special NXP-specific packages, and the result is “fsl-image-full.” It is intended for “out-of-the-box”evaluation because it is rather complete.
2.1.4 fsl-image-core: A Small Image with NXP-SpecificPackages Present
Contents:
This is a small image somewhat like “fsl-image-minimal” except it contains all of the NXP-specific SDK packages.
Purpose:
This image is useful for evaluating the NXP-specific software packages in the context of a file system image that is muchmore embedded-oriented than “fsl-image-full”.
Getting Started
SDK File System Images
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 13
Embedded file system images contain fewer helpful tools and utilities by definition. They are intended to support an embeddedproduct’s functionality rather than a developer’s tasks. Thus, it can be convenient to begin with “fsl-image-core” for evaluationand planning and then later narrowly extend “fsl-image-minimal” to support your embedded product.
2.1.5 fsl-image-virt: An image for KVM deploymentContents:
This is an image which contains the specific packages needed to enable virtualization.
Purpose:
This image is useful for virtualization scenarios (KVM, libvirt, lxc). It contains:
• the guest root filesystem
• the guest image (uImage format for Power based architectures and zImage for ARM based architectures)
• QEMU
• all necessary libraries and tools for libvirt and lxc support
2.2 Essential Build InstructionsThe following sections are essential to the build process and must be performed when using Yocto Project to build the SDK.In order to install the SDK, prepare the host environment, setup Poky, and perform builds, follow the instructions in thesubsequent sections. When these steps are completed, the build process will be complete. Linux images that have been builtwill be found in the following directory: build_<machine>/tmp/deploy/images/<machine>
See Additional Instructions for Developers for more information on using Yocto Project.
2.2.1 Install the SDKHow to install Yocto Project on the host machine.
1. Mount the ISO on your machine:
$ sudo mount -o loop LS1012A-SDK-<target>-<yyyymmdd>-yocto.iso /mnt/cdrom
2. As a non-root user, install Yocto Project:
$ /mnt/cdrom/install
3. When you are prompted to input the install path, ensure that the current user has the correct permission for the installpath.
There is no uninstall script. To uninstall Yocto Project, you can remove the <yocto_install_path>/LS1012A-SDK-<yyyymmdd>-yocto directory manually.
* The source ISO contains the package source tarballs and yocto recipes. It can be installed and
used to do non-cache build.
* The cache ISO contains the pre-built cache binaries. To avoid a long time build, you can install
the source ISO and the cache ISO in the same installation folder.
* The image ISO includes all prebuilt images: flash images, standalone toolchain installer, HD rootfs
images and small images.
* The source ISO can be used separately. The core ISO and the source ISO should work together.
NOTE
Getting Started
Essential Build Instructions
QorIQ LS1012A BSP v0.5, Rev. 0, December 201614 NXP Semiconductors
2.2.2 Prepare the Host EnvironmentYocto Project requires some packages to be installed on the host.
The following steps are used to prepare the Yocto Project environment.
1. In general, Yocto Project can work on most recent Linux distributions with Python-2.7.3 or greater(excluding python3which is not supported), git-1.7.8 or greater, tar-1.24 or greater and required packages installed. The default Python isnot 2.7.x on some Linux distros, e.g. CentOS 6.5 installs python 2.6.6. Please follow below instructions to install thePython 2.7.x in custom path instead of override the system default python, the override may cause system utilitiesbreaking.
$ wget https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tar.xz[NOTE: Python 2.7.3 and python 2.7.5 can be used as well.]$ tar -xf Python-2.7.6.tar.xz$ cd Python-2.7.6$ ./configure --prefix=/opt/python-2.7.6$ make$ sudo make installPlease run below export command to ensure python 2.7.x is used for Yocto build.$ export PATH=/opt/python-2.7.6/bin:$PATH
Yocto Project supports typical Linux distributions:Ubuntu, Fedora, CentOS, Debian, OpenSUSE, etc. More Linuxdistributions are continually being verified. This SDK has been verified on following Linux distributions: Ubuntu 14.04,centos-7.1.1503,Debian 8.2, Fedora 22 and OpenSUSE 13.2
For a list of the Linux distributions tested by the Yocto Project community see SANITY_TESTED_DISTROS in poky/meta-yocto/conf/distro/poky.conf.
The following is the detailed package list on the CentOS hosts:
$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat SDL-devel xterm
For the Fedora hosts:
$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \findutils which SDL-devel xterm
For Ubuntu and Debian hosts:
$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat libsdl1.2-dev xterm
Extra packages are needed for Ubuntu-64b:
$ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 ia32-libs lib32ncurses5-dev
For OpenSUSE host:
$ sudo zypper install python gcc gcc-c++ libtool subversion git chrpath automake make wgetdiffstat makeinfo freeglut-devel libSDL-devel
Getting Started
Essential Build Instructions
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 15
2.2.3 Set Up PokySource the following poky script to set up your environment for your particular Freescale platform. This script needs to berun once for each terminal, before you begin building source code.
$ . ./fsl-setup-env -m <machine>
For example:
$ . ./fsl-setup-env -m ls1012afrdm
The following shows the usage text for the fsl-setup-env command:
Usage:
$ . ./fsl-setup-env -hUsage: . fsl-setup-env -m <machine>Supported machines:ls1012afrdm-32b ls1012afrdm ls1012ardb-32b ls1012ardbOptional parameters:* [-m machine]: the target machine to be built.* [-b path]: non-default path of project build folder.* [-j jobs]: number of jobs for make to spawn during the compilation stage.* [-t tasks]: number of BitBake tasks that can be issued in parallel.* [-d path]: non-default path of DL_DIR (downloaded source)* [-c path]: non-default path of SSTATE_DIR (shared state Cache)* [-g]: enable Carrier Grade Linux* [-l]: lite mode. To help conserve disk space, deletes the buildingdirectory once the package is built.* [-h]: help
2.2.4 BuildsHow to set up a cross compile environment and perform builds
Follow these steps to do builds using Yocto Project. Be sure to set up the host environment before doing these steps.
1. $ cd <sdk-install-dir>/build_<machine>
2. $ bitbake <image-target>
Where <image-target> is one of the following:
• fsl-image-minimal: contains basic packages to boot up a board
• fsl-image-core: contains common open source packages and FSL specific packages.
• fsl-image-full: contains all packages in the full package list.
• fsl-image-kernelitb: A FIT image comprising the Linux image, dtb and rootfs image.
• fsl-image-mfgtool: contains all the user space apps needed to deploy the fsl-image-flash image to a USB stick,hard drive, or other large physical media.
• fsl-image-virt: contains toolkit to interact with the virtualization capabilities of Linux
• fsl-toolchain: the cross compiler binary package
• package-name(u-boot): build a specific package
Contents of the Built Images Directory:
Getting Started
Essential Build Instructions
QorIQ LS1012A BSP v0.5, Rev. 0, December 201616 NXP Semiconductors
A Yocto build produces images that will be located in the following directory:
<sdk-install-dir>/build_<machine>/tmp/deploy/images/<machine>/
The following list shows the typical directory/image files (exact contents depend on the setting of the <IMAGE_FSTYPES>variable):
• fsl-image-<machine>.ext2.gz.u-boot - ramdisk image that can be loaded with U-Boot
• fsl-image-<machine>.ext2.gz - gzipped ramdisk image
• fsl-image-<machine>.tar.gz - gzipped tar archive of the image
• kernel-<machine>.itb - kernel (itb).
• Image-<machine>.bin - kernel binary of the image
• u-boot-<machine>.bin - U-Boot binary image that can be programmed into board Flash
• Image-<machine>.dtb - device tree binary (dtb).
• rcw/*/rcw_*.bin - rcw
2.3 Additional Instructions for DevelopersThis section describes additional "How To" instructions for getting started with Yocto Project.
Each set of instructions is aimed towards developers that are interested in modifying and configuring the source beyond thedefault build. Each section will describe instructions on how to use Yocto Project to achieve a specific development task.
2.3.1 Customizing U-BootHow to Configure and Rebuild U-Boot
To Modify U-boot Configuration
Modify UBOOT_CONFIG. Values for UBOOT_CONFIG are listed in <sdk-install-dir>/sources/meta-freescale/conf/ machine/<machine>.conf. E.g. UBOOT_CONFIG ??= "qspi"
To Modify U-Boot Source Code
If source code has already been installed, please skip steps 1 & 2 and proceed modifying source code.
1. $ bitbake -c cleansstate u-boot
Other helpful bitbake cleaning commands:
bitbake -c clean <target>
• Removes work directory in build_<machine>/tmp/work
bitbake -c cleansstate <target>
• Removes work directory in build_<machine>/tmp/work
• Removes cache files in <sdk-install-dir>/sstate-cache/ directory.
NOTE
2. $ bitbake -c patch u-boot
3. $ cd <S> and modify the source code
Use bitbake -e u-boot | grep ^S= to get value of <S>.
NOTE
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 17
To Rebuild U-Boot Image:
1. $ cd build_<machine>
2. $ bitbake -c compile -f u-boot
3. $ bitbake u-boot
U-Boot image can be found in build_<machine>/tmp/deploy/images/<machine>/
NOTE
2.3.2 Linux KernelHow to Configure and Rebuild the Linux Kernel
1. Modify kernel source code
a. $ bitbake -c cleansstate virtual/kernel
b. $ bitbake -c patch virtual/kernel
c. $ cd <S> and change the source code
Use bitbake -e <package-name> | grep ^S= get the value of <S>.
NOTE
2. Change the kernel defconfig
a. $ update KERNEL_DEFCONFIG variable in meta-freescale/conf/machine/<machine>.conf
3. Change dts
a. $ update KERNEL_DEVICETREE variable in meta-freescale/conf/machine/<machine>.conf
4. Do menuconfig
a. $ bitbake -c menuconfig virtual/kernel
If you are going to reuse this new kernel configuration for future builds, tell menuconfig to "Save
Configuration to Alternate File" and give it an absolute path of /tmp/my-defconfig. If you do not
do this, the new defconfig file will be removed when doing a clean/cleansstate/cleanall
for kernel.
NOTE
This runs the normal kernel menuconfig within the Yocto environment. If the kernel configure UI
cannot open, edit /<yocto_install_path>/build_<machine>_.../conf/local.conf
and add the following based on your environment (prior to issuing the bitbake command).
For a non-X11 environment:
• OE_TERMINAL = "screen"
The following commands can be used for the other environments:
For a GNOME environment (default):
• OE_TERMINAL = "gnome"
For a KDE environment:
• OE_TERMINAL = "konsole"
For non-GNOME and non-KDE environments:
• OE_TERMINAL = "xterm"
NOTE
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 201618 NXP Semiconductors
5. Rebuild Kernel image
a. $ cd build_<machine>
b. $ bitbake -c compile -f virtual/kernel
c. $ bitbake virtual/kernel
Kernel images can be found in build_<machine>/tmp/deploy/images/<machine>/
NOTE
2.3.3 Patching PackagesHow to Patch and Rebuild a Package
1. $ cd <sdk-install-dir>/build_<machine>
2. $ bitbake -c cleansstate <package-name>
3. $ cd <RECIPE_FOLDER>
Use bitbake <package-name> -e | grep ^FILE_DIR to get the value of <RECIPE_FOLDER>
NOTE
4. $ mkdir -p <RECIPE_FOLDER>/files
5. Copy patch into <RECIPE_FOLDER>/files
6. Modify <BB_FILE> and add follow content in package-name-<version>.bb file
SRC_URI += "file://<name-of-patch1> \ file://<name-of-patch2> \ ... \ file://<name-of-patchn>"
7. Rebuild this package:
$ bitbake <package-name>
2.3.4 Extract Source CodeHow to Extract the Source Code for a Package
To extract the source code of a package, do the following:
1. $ bitbake -c cleansstate <package-name>
2. $ bitbake -c patch <package-name>
3. $ cd <S>
Use bitbake -e <package-name> | grep ^S= to get the value of <S>.
NOTE
For example, to do a U-boot of a LS1012AFRDM processor.
1. $ bitbake -c cleansstate u-boot
2. $ bitbake -c patch u-boot
U-boot source code is installed in the folder: build_ls1012afrdm/tmp/work/ls1012afrdm-
fsl-linux/u-boot-qoriq/2016.01+git-r0/
NOTE
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 19
2.3.5 Customize Root FilesystemHow to Customize a Root Filesystem
Packages included in a rootfs can be customized by editing the corresponding recipe:
fsl-image-mfgtool:sources/meta-freescale/recipes-fsl/images/fsl-image-mfgtool.bbfsl-image-core:sources/meta-freescale/recipes-fsl/images/fsl-image-core.bbfsl-image-full:sources/meta-freescale/recipes-fsl/images/fsl-image-full.bbfsl-image-virt: sources/meta-freescale/recipes-fsl/images/fsl-image-virt.bbfsl-image-minimal:sources/meta-freescale/recipes-fsl/images/fsl-image-minimal.bbfsl-image-kernelitb:sources/meta-freescale/recipes-fsl/images/fsl-image-kernelitb.bbfsl-toolchain:sources/meta-freescale/recipes-fsl/images/fsl-tooichain.bb
The rootfs type can be customized by setting the IMAGE_FSTYPES variable in the above recipes.
Supported rootfs types include the following:
cpiocpio.gz cpio.xz cpio.lzmacramfsext2ext2.gz ext2.gz.u-bootext2.bz2.u-bootext3ext3.gz.u-boot ext2.lzmajffs2livesquashfssquashfs-lzma ubitartar.gztar.bz2 tar.xz
Path of source tarballs and patches:
• Package source tarballs are in the folder named sources, which is in the same folder level as build_<machine>.
• Patches are in the corresponding recipe folder
Specify the preferred version of package:
<PREFERRED_VERSION_pkgname> is used to configure the required version of a package.
If <PREFERRED_VERSION> is not defined, Yocto will pick up the recent version. For example, to downgrade Samba from 3.4.0to 3.1.0: add PREFERRED_VERSION_samba = "3.1.0" in meta-freescale/conf/machine/<machine>.conf
Rebuild rootfs:
$ bitbake <image-target>
2.3.6 Native PackagesHow to Build Native Packages for the Host
Native packages such as cst-native are supported in Yocto. To build a native package, do the following:
$ bitbake cst-native
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 201620 NXP Semiconductors
The binaries can be found in build_<machine>/tmp/sysroots/x86_64-linux
NOTE
2.3.7 Standalone toolchainBuild and install the standalone toolchain with Yocto:
1. $ . ./fsl-setup-env -m <machine>
2. $ bitbake fsl-toolchain
3. $ cd build_<machine>/tmp/deploy/sdk
4. $ ./fsl-qoriq-glibc-<host-system>-<core>-toolchain-<release>.sh
The default installation path for standalone toolchain is /opt/fsl-qoriq/LS1012A-SDK. The
install folder can be specified during the installation procedure.
NOTE
To use the installed toolchain, go the the location where the toolchain is installed and source the environment-setup-<core>file. This will set up the correct path to the build tools and also export some environment variables relevant for development(eg. $CC, $ARCH, $CROSS_COMPILE, $LDFLAGS etc).
To invoke the compiler, use the $CC variable (eg. $CC <source files>).
This is a sysrooted toolchain. This means that GCC will start to look for target fragments and
libraries (eg. crt*, libgcc.a) starting from the path specified by the sysroot. The default sysroot is
preconfigured at build time to point to /opt/fsl-qoriq/<sdk_version>/sysroots/
<target_architecture>. If the toolchain is installed in a location other than the default one (/
opt/fsl-qoriq/), the --sysroot=<path_to_target_sysroot> parameter needs to be
passed to GCC. When invoking the compiler through the $CC variable, there is no need to pass the
--sysroot parameter as it is already included in the variable (check by running echo $CC).
NOTE
2.3.8 Shared State (sstate) CacheBitBake has the capability to accelerate builds based on previously built output. This is done using "shared state" files whichcan be thought of as cache objects and this option determines where those files are placed. The shared state cache (sstate-cache), as pointed to by SSTATE_DIR.
1. Use the following setting in local.conf:
SSTATE_DIR="<absolute_path_of_cache_folder>" e.g. SSTATE_DIR = "/home/yocto/sdk/sstate-cache/"
Some packages have no caches because the ISO uses 4GB of space. Thus, cache size is limited
by ISO size. Some packages (e.g. u-boot, kernel, rcw, depmodwrapper-cross, keymaps, base-files,
merge-files, shadow-securetty, etc.) have no caches and building them requires about 20 minutes.
NOTE
2.3.9 FAQFrequently Asked Question about Yocto
Q: How to install source code, modify source code and rebuild u-boot/kernel?.
A: Use the following steps:
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 21
1. $ cd <sdk-install-dir>/build_<machine>
2. If the source code has been installed, please skip this step.
• $ bitbake -c patch <package-name>
• $ cd <S> and do change
Use bitbake -e <package-name> | grep ^S = to get the value of <S>.
NOTE
3. Modify configure (dts can also be modified):
• Modify the UBOOT_CONFIG variable in meta-freescale/conf/machine/<machine>.conf or update theKERNEL_DEFCONFIG variable in meta-freescale/conf/machine/<machine>.conf
4. Rebuild images:
• $ cd <sdk-install-dir>/build_<machine>
• $ bitbake -c compile -f <package-name>
• $ bitbake <package-name>
u-boot.bin, Image and dtb files can be found in build_<machine>/tmp/deploy/images/
<machine>.
Or set <ARCH> and <CROSS_COMPILE> and build the u-boot/kernel manually
NOTE
Q: How to build u-boot/kernel with debugger (CodeWarrior support)?
A: For u-boot:
1. $ cd <sdk-install-dir>/build_<machine>
2. $ bitbake -c cleansstate u-boot
3. Modify the u-boot-qoriq_<version>.bb file and add following content:
• $ cd meta-freescale/recipes-bsp/u-boot
• $ add 'EXTRA_OEMAKE += "CONFIG_CW=1"' in u-boot-qoriq_<version>.bb file
4. Rebuild u-boot:
• $ bitbake u-boot
For kernel:
1. $ cd <sdk-install-dir>.
2. If kernel source code is not installed, install the kernel source code first.
• $ bitbake -c cleansstate virtual/kernel
• $ bitbake -c patch virtual/kernel
3. Configure kernel to enable CW support:
• $ bitbake -c menuconfig virtual/kernel
• Enable Kernel hacking -> Include CodeWarrior kernel debugging in kernel configuration UI.
4. Rebuild kernel:
• $ bitbake virtual/kernel
Q: How to view the content of rootfs
A: The expanded rootfs is in <IMAGE_ROOTFS>
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 201622 NXP Semiconductors
Use bitbake -e <rootfs-name> | grep ^IMAGE_ROOTFS= to get the value of
<IMAGE_ROOTFS>.
NOTE
Q: How to display packages which are included in current rootfs image?
A: There are three methods :
• $hob
• $bitbake -e <image-target> | grep IMAGE_INSTALL
• $bitbake -g <image-target>
Q: How to add a pre-built binary into the rootfs
A: Do the following:
1. $ cd <sdk-install-dir>.
2. Add the files:
• $ cd meta-freescale/recipes-extended/merge-files
• Put the files into merge-files/merge/, e.g. put bash into merge-files/merge/usr, bash will be included in usr/ of thenew rootfs.
3. Build new rootfs image:
• $ bitbake <rootfs-target>
Q: Example of using dtc to reverse to a dts from a dtb
A: Do the following
1. $ export PATH=<path-of-dtc>:$PATH
2. $ dtc -I dtb -O dts -o name-of-dts name-of-dtb
Q: How to build fsl-toolchain?
A: Do the following
1.$bitbake fsl-toolchain
fsl-qoriq-glibc-x86_64-<target>-toolchain-<VERSION>.sh can be found in
build_<machine>/tmp/deploy/sdk/
NOTE
fsl-qoriq-glibc-x86_64-<target>-toolchain-<VERSION>.sh runs and the toolchain can be installed
in special path
NOTE
Q: Fail to get source tarball of a packages with wget.
A: Use the --no-check-certificates optionwhen Yocto uses wget to fetch source tarball from internet, the option is onlyavailable when wget was configured at build time with SSH support. Ensure that wget on your host is built with SSH support.
Q: How to include toolchain in rootfs?
A: The toolchain runs on target board, which is the same exact version as the cross tools in this SDK, is only included infsl-image-full rootfs, if you want to add toolchain into other rootfs images, do the following:
1. Edit fsl-image-minimal.bb/fsl-image-core.bb/fsl-image-xxx.bb to add packagegroup-core-buildessential inthe IMAGE_INSTALL variable.
2. $ bitbake <rootfs-target>.
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 23
Q: how to use standalone toolchain to build kernel?
A: If you want to build the linux kernel using toolchain, you can do the following:
1. cd <toolchain-install-path>
2. source environment-setup-<core>-fsl-linux
3. export LDFLAGS=""
4. cd <linux_source_ path>
5. make mrproper
6. ./scripts/kconfig/merge_config.sh arch/arm64/configs/defconfig arch/arm64/configs/freescale.config
7. make
2.3.10 BitBake User ManualBitBake is a tool for executing tasks and managing metadata.
BitBake is, at its simplest, a tool for executing tasks and managing metadata. As such, its similarities to GNU make and otherbuild tools are readily apparent. It was inspired by Portage, the package management system used by the Gentoo Linuxdistribution. BitBake is the basis of the OpenEmbedded project (www.openembedded.org), which is being used to build andmaintain a number of embedded Linux distributions, including OpenZaurus and Familiar.
This document is not available in PDF form. However, you may obtain the latest document at http://docs.openembedded.org/bitbake
Getting Started
Additional Instructions for Developers
QorIQ LS1012A BSP v0.5, Rev. 0, December 201624 NXP Semiconductors
Chapter 3Deploy U-Boot, Linux Kernel, and Root Filesystemto a Reference Design Board (RDB)
3.1 IntroductionThis chapter describes how to deploy U-Boot, Linux kernel and root file system to the NXP Reference Design Board (RDB) .The guide starts with generic host and target board pre-requisites. This is followed by board-specifc configuration:
• Switch Settings
• U-Boot environment Variables
• Device Microcodes
• Management Complex (MC), DPC, DPL
• Reset Configuration Word (RCW) and Ethernet Interfaces (if applicable)
• System Memory Map
• Flash Bank Usage
The "Switch Settings" section within each guide shows the default switch settings for the reference design board. If moreinformation is needed beyond the scope of the default configuration, refer to the reference design board's Quick Start Guideand Reference Manual/ User Manual.
For reference design boards with more than one QSPI flash, the "Programming a New U-Boot, RCW, Management Complex"section describes how the user can individually or simultaneously update U-Boot, RCW, and Management Complex, DPC,DPL by flashing them to the board's second QSPI flash prior to deployment.
Once the board is set-up and configured appropriately, select one of the following deployment methods:
• Ramdisk deployment from TFTP
• Ramdisk deployment from Flash
• NFS deployment
• Harddisk deployment (if applicable)
• SD deployment (if applicable)
• Hypervisor deployment (if applicable)
Each of these guides will step you through the deployment method of your choice.
3.2 Basic Host Set-upSince TFTP will be used to download files onto the target board, a TFTP server must be running on your host system. If youare going to use NFS deployment then an NFS server must also be running on your host system.
Once TFTP and NFS servers are installed, use the following generic instructions to complete the host set-up:
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Introduction
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 25
1. Create the tftboot directory.
mkdir /tftpboot
2. Copy over kernel, bootloader, and flash filesystem images for your deployment to the /tftpboot directory:
cp <yocto_work_dir>/build_<platform>_release/tmp/deploy/images/* /tftpboot
3. Use Yocto Project to generate a tar.gz type file system, and uncompress it in <nfs_root_path>.
4. Edit /etc/exports and add the following line:
<nfs_root_path> <target_board_IP> (rw,no_root_squash, async)
5. Edit /etc/xinetd.d/tftp to enable TFTP server:
service tftp{disable= nosocket_type= dgramprotocol= udpwait= yesuser= rootserver= /usr/sbin/in.tftpdserver_args= /tftpboot}
6. Restart the nfs and tftp servers on your host:
/etc/init.d/xinetd restart/etc/init.d/nfs restart
7. Connect the board to the network.
8. Connect the target to the host via a cross cable serial connection.
9. Open a serial console tool on the host system and set it up to talk to the target board:
• Select appropriate serial device.
• Configure the serial port with the following settings: Baud rate = 115,200; Data = 8 bit; Parity = none; Stop = 1 bit; Flowcontrol = none.
• Power on board and see the console prompt.
(i) The Linux distribution running on your host will determine the specific instructions to use.
(ii) Steps 3 and 4 are only necessary when using NFS deployment.
NOTE
3.3 Target Board Set-upOnce the host set-up is complete, follow these steps to set-up and power on the target board:
1. Power off the Target board system if the power is already on.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Target Board Set-up
QorIQ LS1012A BSP v0.5, Rev. 0, December 201626 NXP Semiconductors
2. Connect the Target board to the network via an Ethernet port on the board.
3. Connect the Target board to the host machine via the serial port with an RS-232 cable and the joined NXP adaptor cable,if needed.
4. Start the serial console tool on the host system.
5. Verify that all switches and jumpers are setup correctly as described in the board's Reference Manual/User Guide.
6. Power on the board.
Below is an example of a typical U-Boot log:
U-Boot 2016.01LS1012A-SDK+g7944a94 (Aug 27 2016 - 04:43:01 +0800)
SoC: LS1012AE (0x87040010)Clock Configuration: CPU0(A53):800 MHz Bus: 250 MHz DDR: 1000 MT/sReset Configuration Word (RCW): 00000000: 08000008 00000000 00000000 00000000 00000010: 33050000 c000000c 40000000 00001800 00000020: 00000000 00000000 00000000 000c4571 00000030: 00000000 00c28120 00000096 00000000I2C: readyDRAM: 510 MiBUsing SERDES1 Protocol: 13061 (0x3305)SF: Detected S25FS512S_256K with page size 512 Bytes, erase size 128 KiB, total 64 MiBIn: serialOut: serialErr: serialModel: LS1012A FREEDOM BoardBoard: LS1012AFRDM Net: cbus_baseaddr: 0000000004000000, ddr_baseaddr: 0000000083800000, ddr_phys_baseaddr: 03800000class init completetmu init completebmu1 init: donebmu2 init: doneGPI1 init completeGPI2 init completeHGPI init completehif_tx_desc_init: Tx desc_base: 0000000083e40400, base_pa: 03e40400, desc_count: 64hif_rx_desc_init: Rx desc base: 0000000083e40000, base_pa: 03e40000, desc_count: 64HIF tx desc: base_va: 0000000083e40400, base_pa: 03e40400HIF init completebmu1 enabledbmu2 enabledpfe_hw_init: donepfe_firmware_initpfe_load_elf: no of sections: 13pfe_firmware_init: class firmware loadedpfe_load_elf: no of sections: 10pfe_firmware_init: tmu firmware loadedls1012a_configure_serdes 0ls1012a_configure_serdes 1pfe_eth0, pfe_eth1Hit any key to stop autoboot: 0
If the target board does not have a working U-Boot, see System Recovery on page 54.
NOTE
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Target Board Set-up
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 27
3.4 Optimizing Boot Flow (Fast Boot)
Introduction
Fast boot means booting the system to Linux prompt in as less time as possible. The exact time is counted from the momentpower button is pressed on the board till Linux login prompt comes up.
Requirement
Many industrial and Internet of Things (IoT) customers are looking for systems with minimal boot-up time. They want theirsoftware and stacks to be up and running on top of Linux in no time. This creates a requirement of the system coming ontothe Linux prompt as soon as possible.
Components Affected
Boot time reduction optimizations are done at various places: RCW, U-Boot, Linux and root filesystem. This section talksabout the fast boot feature which is included as a part of this release.
Enabling Fast boot
Fast-boot is enabled by default at all possible places: RCW, U-Boot, Linux and root filesystem. As a result fast-boot in thedefault boot as a part of latest SDK release.
Fast Boot versus Normal Boot Process
The user will see some changes in the log which appears on the console when linux is booted. Some of the Linux boot-upmessages have been suppressed and they will not be visible anymore. To see all the kernel messages/Linux boot-upmessages, use the dmesg command. See an example of Linux boot log below:
## Loading kernel from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM64 Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x9600013c Data Size: 12502016 Bytes = 11.9 MiB Architecture: AArch64 OS: Linux Load Address: 0x80080000 Entry Point: 0x80080000## Loading ramdisk from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'ramdisk@1' ramdisk subimage Description: Ramdisk Type: RAMDisk Image Compression: uncompressed Data Start: 0x96bef354 Data Size: 24512880 Bytes = 23.4 MiB Architecture: AArch64 OS: Linux Load Address: unavailable Entry Point: unavailable## Loading fdt from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'fdt@1' fdt subimage
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Optimizing Boot Flow (Fast Boot)
QorIQ LS1012A BSP v0.5, Rev. 0, December 201628 NXP Semiconductors
Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x96bec5f0 Data Size: 11490 Bytes = 11.2 KiB Architecture: AArch64 Loading fdt from 0x96bec5f0 to 0x90000000 Booting using the fdt blob at 0x90000000 Loading Kernel Image ... OK Using Device Tree in place at 0000000090000000, end 0000000090005ce1
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0[ 0.000000] Initializing cgroup subsys cpu[ 0.000000] Linux version 4.1.8-rt8+g19202f1 (jenkins@neptune) (gcc version 4.9.4 20150629 (prerelease) (Linaro GCC 4.9-2015.06) ) #1 SMP Mon Aug 22 04:38:44 CST 2016[ 0.000000] CPU: AArch64 Processor [410fd034] revision 4[ 0.000000] Detected VIPT I-cache on CPU0[ 0.000000] alternatives: enabling workaround for ARM erratum 845719[ 0.000000] earlycon: Early serial console at MMIO 0x21c0500 (options '')[ 0.000000] bootconsole [uart0] enabled[ 0.048225] No BMan portals available![ 0.054167] No QMan portals available![ 0.197414] Freescale FM module, FMD API version 21.1.0[ 0.202816] Freescale FM Ports module[ 0.211351] vfio_fsl_mc_driver_init: Driver registration fails as no fsl_mc_bus found[ 0.669450] fsl-mc bus not found, restool driver registration failed[ 0.939507] usb usb1-port1: over-current condition[ 0.944339] usb usb2-port1: over-current conditionINIT: version 2.88 bootingStarting udev[ 3.077683] pe_load_ddr_section: load address(3fb0000) and elf file address(ffff0000003fb000) rcvdPopulating dev cachehwclock: can't open '/dev/misc/rtc': No such file or directorySun Aug 21 20:53:13 UTC 2016hwclock: can't open '/dev/misc/rtc': No such file or directoryRunning postinst /etc/rpm-postinsts/100-sysvinit-inittab...Running postinst /etc/rpm-postinsts/101-inetutils-inetd...Running postinst /etc/rpm-postinsts/102-inetutils-ftpd...update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing) Removing any system startup links for run-postinsts ...INIT: Entering runlevel: 5Configuring network interfaces... done.Starting system log daemon...0Starting kernel log daemon...0Starting internet superserver: xinetd.
QorIQ SDK (FSL Reference Distro) 2.0 ls1012afrdm /dev/ttyS0
ls1012afrdm login:
3.5 Supported Boards
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 29
3.5.1 LS1012ARDB
3.5.1.1 OverviewThe LS1012A reference design board (RDB) is the high-performance computing, evaluation, and development platform thatsupports the QorIQ LS1012A processor. This guide provides board-specific configuration and instructions for differentmethods of deploying U-Boot, Linux kernel and root file system to the target board.
3.5.1.2 Switch SettingsThe RDB has user selectable switches for evaluating different boot options i.e. QSPI Flash 1 for the LS1012A device. Tablebelow lists the default switch settings and the description of these settings.
Table 1. Switch configuration
1 2 3 4 5 6 7 8
SW1 1 0 1 0 0 1 1 0
SW2 0 0 0 0 0 0 0 0
Below are additional switch settings for alternate boot option i.e QSPI Flash2.
Table 2. Switch configuration
1 2 3 4 5 6 7 8
SW1 1 0 1 0 0 1 1 0
SW2 0 0 0 0 0 0 1 0
3.5.1.3 U-Boot Environment VariablesThe following sections will guide the users on how to set the U-Boot environment and configure the U-Boot networkparameters.
3.5.1.3.1 U-Boot Environment Variable "hwconfig"Environment variable "hwconfig" is used within the U-Boot bootloader to convey information about desired hardwareconfigurations. It is an ordinary environment variable in that:
• It can be set in the U-Boot prompt using the "setenv" command.
• It can be removed from the U-Boot environment by setting it to an empty value, i.e.
=>setenv hwconfig
• It can be modified in the U-Boot command prompt using the "editenv" command.
• It can be saved in the U-Boot environment via the "saveenv" command.
Variable "hwconfig" is set to a sequence of option:value entries separated by semicolons.The default setting for for "hwconfig"on LS1012ARDB is as follows:
hwconfig = fsl_ddr:bank_intlv=auto
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201630 NXP Semiconductors
3.5.1.3.2 Configuring U-Boot Network ParametersTo support TFTP based deployments, set up the U-Boot environment once, and save it, so that settings persist on subsequentresets.
=>setenv ipaddr <board_ipaddress>=>setenv serverip <tftp_serverip>=>setenv gatewayip <your_gatewayip>=>setenv ethaddr <mac addr0>=>setenv eth1addr <mac addr1>=>setenv ethprime <ethx>=>setenv ethact <ethx>=>setenv netmask 255.255.x.x=>saveenv
(i) <ethx> is the Ethernet port on the board connected to the Linux boot server.
(ii) "netmask" is subnet mask for the Linux boot server's network.
NOTE
Below is one example of the MAC address configuration corresponding to the set up above. Change these values to MACaddresses appropriate for your board.
=>setenv ethaddr 00:04:9F:02:00:FD=>setenv eth1addr 00:04:9F:02:01:FD
=>saveenv
Now the flashed version of U-Boot is ready for performing TFTP based deployments.
Possible <ethx> value
• pfe_eth0
• pfe_eth1
3.5.1.4 RCW (Reset Configuration Word) and Ethernet InterfacesThe following RCW binary is used on the LS1012ARDB board
RR_SPNH_3508/PBL_0x35_0x08_800_250_1000_default.bin
This RCW enables
• Boot from QSPI
• 800MHz Core, 250MHz Platfrom, 1000MT/s DDR
• SDHC1, SDHC2, I2C1,
• SerDes Protocol 0x3508
• PCIe, SATA,
• RGMII, SGMII
• USB 3.0
3.5.1.5 System Memory MapIn 64-bit u-boot, there is a 1:1 mapping of physical address and effective address. After system startup, the boot loader mapsphysical address and effective address as shown in the following table:
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 31
Start Physical Address End Physical Address Memory Type Size
0x00_0000_0000 0x00_00FF_FFFF Secure Boot ROM 1MB
0x00_0100_0000 0x00_0FFF_FFFF CCSR 240MB
0x00_1000_0000 0x00_1000_FFFF OCRAM1 64KB
0x00_1001_0000 0x00_1001_FFFF OCRAM2 64 KB
0x00_4000_0000 0x00_5FFF_FFFF QSPI 512MB
0x00_8000_0000 0x00_FFFF_FFFF DRAM 2GB
0x08_8000_0000 0x0F_FFFF_FFFF DRAM2 30G
0x40_0000_0000 0x47_FFFF_FFFF PCI Express1 32G
3.5.1.6 Flash Bank UsageLS1012ARDB has 2 QSPI flash connected over QSPI contoller.
Only one QSPI flash is available at a time depending upon the board switch settings. These switch settings can also beoverriden by I2C commands.
To protect the default U-Boot in flash1 (aka bank1), it is a convention employed by NXP to deploy work images into the flash2(aka bank2), and then switch to the flash2 (aka bank2) for testing. Switching to the flash2 (aka bank2) can be done in softwareusing I2C commands and effectively swaps the flash1 (aka bank1) with the flash2 (aka bank2). This protects flash1 and keepsthe board bootable under all circumstances.
U-Boot 2016.01-g5ab5bba (Jun 14 2016 - 12:56:17 +0530)
SoC: LS1012AE (0x87040010)Clock Configuration: CPU0(A53):800 MHz Bus: 250 MHz DDR: 1000 MT/sReset Configuration Word (RCW): 00000000: 08000008 00000000 00000000 00000000 00000010: 35080000 c000000c 40000000 00001800 00000020: 00000000 00000000 00000000 00014571 00000030: 00000000 18c2a120 00000096 00000000I2C: readyDRAM: 1022 MiBMMU warning: gd->secure_ram is not maintained, disabled.SEC: RNG instantiatedUsing SERDES1 Protocol: 13576 (0x3508)MMC: FSL_SDHC: 0, FSL_SDHC: 1SF: Detected S25FS512S_256K with page size 512 Bytes, erase size 128 KiB, total 64 MiBPCIe1: Root Complex no link, regs @ 0x3400000In: serialOut: serialErr: serialModel: LS1012A RDB BoardBoard: LS1012ARDB Version: RevB, boot from QSPI: bank1SATA link 0 timeout.AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x1 impl SATA modeflags: 64bit ncq pm clo only pmp fbss pio slum part ccc apstFound 0 device(s).SCSI: Net: cbus_baseaddr: 0000000004000000, ddr_baseaddr: 0000000083800000, ddr_phys_baseaddr:
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201632 NXP Semiconductors
03800000class init completetmu init completebmu1 init: donebmu2 init: doneGPI1 init completeGPI2 init completeHGPI init completehif_tx_desc_init: Tx desc_base: 0000000083e40400, base_pa: 03e40400, desc_count: 64hif_rx_desc_init: Rx desc base: 0000000083e40000, base_pa: 03e40000, desc_count: 64HIF tx desc: base_va: 0000000083e40400, base_pa: 03e40400HIF init completebmu1 enabledbmu2 enabledpfe_hw_init: donepfe_firmware_initpfe_load_elf: no of sections: 13pfe_firmware_init: class firmware loadedpfe_load_elf: no of sections: 10pfe_firmware_init: tmu firmware loadedls1012a_configure_serdes 0pfe_eth0, pfe_eth1Hit any key to stop autoboot: 0=>
How to boot from flash 2 (aka bank2)
1. To check which bank booted, refer to “Board: LS1012ARDB Version: RevB, boot from QSPI: bank1" in the U-Bootlogs.
2. I2C commands to flash2 bank2 switch “ i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf5 “
3. Program QSPI flash as per flash layout
4. To boot from bank2 give “reset” command.
5. To move back to bank 1 from bank 2, power on/off the board or use “i2c mw 0x24 0x3 0xf4 “ and then give “reset”command.
QSPI flash Layout
Image Size Start Address
RCW + PBI 1MB 0x4000_0000
U-boot boot loader + PFE binary 1MB 0x4010_0000
U-boot Env 1MB 0x4020_0000
PPA FIT image 2MB 0x4050_0000
Kernel ITB 59MB 0x40A0_0000
3.5.1.7 Programming a New U-Boot, RCW, and PPA FirmwareThe following sections will discuss how to individually update U-Boot and RCW. For specific addresses, please refer to theQSPI Flash Memory Map as a reference.
Please refer to Configuring U-Boot Network Parameters to make sure all necessary U-Boot parameters have been set.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 33
Programming a New U-Boot. By default, an existing U-Boot is run in flash1 after the system is powered on or after a hardreset is performed. To flash U-Boot to the alternate flash/bank, first switch to flash 1 (bank 0) by performing a hard reset orby typing reset. Then use the following commands to change flash2/bank1 and program a new U-Boot and then switch tothat flash2 or alternate bank where the new U-Boot is flashed:
=>i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf5 =>tftp 0x80000000 <u-boot_file_name>.bin =>sf probe 0:0=>sf erase 0x100000 +$filesize=>sf write 0x80000000 0x100000 $filesize=> reset
Programming a New RCW:To program a new RCW, first switch to flash1 (bank 0) by performing a hard reset or by typingreset. Next, load the new RCW to RAM by downloading it via TFTP and then copying it to flash2 at offset 0x000000. Executethe following commands at the U-Boot prompt to program the RCW to flash and reset to alternate bank.
=>i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf5 =>tftp 0x80000000 <rcw_file_name>.bin =>sf probe 0:0=>sf erase 0x0 +$filesize=>sf write 0x80000000 0x0 $filesize=> reset
RCW and U-Boot binary must be byte swapped using command (tclsh ./byte_swap.tcl u-boot-
dtb.bin u-boot-dtb_swap.bin 8)
NOTE
Programming a New Primary Protected Application (PPA) Firmware: To program a new PPA firmware, first switch tobank 0 by performing a hard reset or by typing reset. Next, load the new PPA firmware to RAM by downloading it via TFTPand then copying it to flash at address 0x500000. 0x500000 is the location of PPA firmware in the alternate bank. Then executethe following commands at the U-Boot prompt to program the PPA firmware to flash and reset to alternate bank.
=> tftp 0x80000000 <ppa_file_name>.itb => sf probe 0:0=> sf erase 0x500000 +$filesize=> sf write 0x80000000 0x500000 $filesize=> reset
All the files which are to be flashed need to be byte-swapped.
NOTE
3.5.1.8 DeploymentEach of these guides will step you through the deployment method of your choice. Please refer to the board's NOR FlashMemory Map within Flash Bank Usage as reference for specific addresses.
3.5.1.8.1 Ramdisk Deployment from TFTP1. Setting U-Boot Environment
The images generated by Yocto allow you to perform ramdisk deployment. Before performing ramdisk deployment, theU-Boot environment variables need to be configured.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201634 NXP Semiconductors
Refer to Configuring U-Boot Network Parameters to set the U-Boot environment variables. In addition, execute thefollowing commands at the U-Boot prompt to prepare for ramdisk deployment from TFTP:
=>setenv bootargs ‘ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500'=>saveenv
ramdisk_size needs to be set if the ramdisk uncompress file size is bigger than default setting. It
should be more than ramdisk uncompress file size. The file size information is printed in Yocto build
log.
NOTE
2. Booting Up the System
Execute the following commands to TFTP the images to the board, then boot into Linux.
=>tftp 0xa0000000 <kernel_itb_name>=>bootm 0xa0000000
Now the board will boot into Linux using the images generated by Yocto.
3.5.1.8.2 Ramdisk Deployment from FlashProgramming the kernel and ramdisk into flash will allow you to boot up the board afterwards without the need to re-downloadimages.
1. Setting U-Boot Environment
The images generated by Yocto allow you to perform ramdisk deployment from flash. Before performing ramdiskdeployment from flash, the U-Boot environment variables need to be configured. Refer to Configuring U-Boot NetworkParameters to set the U-Boot environment variables. In addition, execute the following commands at the U-Boot promptto prepare for NFS deployment from flash:
=>setenv bootcmd ‘run ramargs; pfe stop; sf probe 0:0; sf read 0x96000000 0xa00000 0x2800000; bootm 0x96000000
Now U-Boot is ready for flash deployment.
2. Programming Kernel ITB to QSPI Flash
The kernel should be downloaded to the RAM using TFTP then copied to the flash address <kernel_itb_addr>. At the U-Boot prompt, use the following commands to program the kernel to flash:
=>tftp 0x96000000 <kernel ITB> =>sf probe 0:0; =>sf erase <kernel_itb_addr> $filesize =>sf write 0x96000000 <kernel_itb_addr> $filesize
3. Booting Up the System
The kernel can boot up automatically after the board is powered on, or the following command can be used to boot upthe board at U-Boot prompt:
=>boot
or
=> run ramargs; pfe stop; sf probe 0:0; sf read 0x96000000 0xa00000 0x2800000; bootm 0x96000000
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 35
3.5.1.8.3 NFS Deployment1. Generating File System with Yocto
Use Yocto to generate a tar.gz type file system, and uncompress it for NFS deployment.
2. Setting Host NFS Server Environment
a. On the Linux host NFS server, add the following line in the file /etc/exports:
<nfs_root_path> <board_ipaddress>(rw,no_root_squash,async)
b. Restart the NFS service:
/etc/init.d/nfs restart
nfs_root_path: the NFS root directory path on NFS server.
NOTE
3. Setting U-Boot Environment
The NFS file system generated by Yocto allows you to perform NFS deployment. Before performing NFS deployment, theU-Boot environment variables need to be configured. Refer to Configuring U-Boot Network Parameters on page 31 to setthe U-Boot environment variables. In addition, execute the following commands at the U-Boot prompt to prepare for NFSdeployment:
=>setenv bootargs root=/dev/nfs rw nfsroot=<tftp_serverip>:<nfs_root_path> ip=<board_ipaddr>:<tftp_serverip>:<your_gatewayip>:<your_netmask>:<board_name>:eth0:off console=ttyS0,115200=>setenv netdev <ethx>=>saveenv
<ethx> is the port connected on the Linux boot network.
NOTE
Now U-Boot is ready for NFS deployment.
4. Booting up the System
TFTP the kernel image to the board, then boot it up.
=>tftp 96000000 kernel.itb; =>bootm 96000000:kernel@1 - 96000000:fdt@1
Now the board will boot up with NFS filesystem.
3.5.1.8.4 SD DeploymentPartition SD Card
1. Insert SD card into the Linux Host PC.
2. Use the "fdisk" command to repartition the SD card.
# fdisk /dev/sdb
3. Use the mkfs.ext2 command to creat the filesystem.
#mkfs.ext2 /dev/sdb1
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201636 NXP Semiconductors
When connecting the SD card on Linux host, look for the log messages on the Linux console and
accordingly, only format that device (which represents SD card).
NOTE
1. Insert SD card into the Linux Host PC.
2. Create temp director in host PC and mount the ext2 partition to the temp
#mkdir temp#mount /dev/sdb1 temp
3. Copy the FIT Kernel Image to the SD card partition.
#cp kernel.itb temp/
4. Copy the Root File System to the SD card partition.
#cp fsl-image-core-ls1043ardb_<release date>.rootfs.tar.gz temp/ #tar xvfz fsl-image-core-ls1043ardb_<release date>.rootfs.tar.gz #rm fsl-image-core-ls1043ardb_<release date>.rootfs.tar.gz temp/
5. Umount the temp director
#umount temp
Setting U-Boot Environment
• Execute the following commands at the U-Boot prompt
=> setenv bootcmd "ext2load mmc 0 a0000000 kernel.itb && bootm a0000000"
• Using the Ramdisk as the Root File Systemp
=> setenv bootargs "root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 console=ttyS0,115200"
• Using the Ext2 Partition of SD card as the Root File Systemp
=> setenv bootargs "root=/dev/mmcblk0p1 rw earlycon=uart8250,0x21c0500 console=ttyS0,115200"
• Saving the environment
=>saveenv
Note: The kernel.itb is the name of your FIT Image, you can use the ext2ls command to list it at the U-Boot prompt
3.5.1.9 Check 'Link Up' for Serial Ethernet InterfacesThis section provides some basic checks that can be performed in U-Boot to help diagnose the cause of the networkingerrors when experiencing problems with Ethernet interfaces.
Check Communication to External PHY
In order to check if U-Boot can communicate with the PHYs on the board, use the U-Boot command mdio list. The U-Bootcommand mdio list will display all manageable Ethernet PHYs.
Example:
=> mdio listPFE_MDIO:1 - RealTek RTL8211F <--> pfe_eth12 - RealTek RTL8211F <--> pfe_eth0
The results from the mdio list command above show that U-Boot was able to see PHYs on each of the RGMII/SGMIIinterfaces.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 37
Check Link Status for External PHY
In order to check the status of a RGMII/SGMII link, use the mdio read command. Since this is a Clause 22 device, we passtwo arguments to the mdio read command.
mdio read <PHY address> <REGISTER Address>
Example:
=> mdio read pfe_eth0 1Reading from bus PFE_MDIOPHY at address 2:1 - 0x79ad=> mdio read pfe_eth1 1Reading from bus PFE_MDIOPHY at address 1:1 - 0x79ad
The link partner (“copper side”) link status bit is in Register #1 on the PHY. The 'Link Status' bit is bit #2 (from the left) of thelast nibble. In the example above, the nibble of interest is "d" (d = b'1101'), and therefore the 'Link Status' = 1, which means'link up'. If the link were down this bit would be a "0," and we would see 0x7989.
3.5.1.10 Basic Networking Ping Test
U-BOOT
The LS1012ARDB has one SGMII and one RGMII. The log below shows how to ping from those 2 interfaces.
U-Boot 2016.01-gc423721 (Jun 27 2016 - 13:06:22 +0530)
SoC: LS1012AE (0x87040010)Clock Configuration: CPU0(A53):800 MHz Bus: 250 MHz DDR: 1000 MT/sReset Configuration Word (RCW): 00000000: 08000008 00000000 00000000 00000000 00000010: 35080000 c000000c 40000000 00001800 00000020: 00000000 00000000 00000000 00014571 00000030: 00000000 18c2a120 00000096 00000000I2C: readyDRAM: 1022 MiBMMU warning: gd->secure_ram is not maintained, disabled.SEC: RNG instantiatedUsing SERDES1 Protocol: 13576 (0x3508)MMC: FSL_SDHC: 0, FSL_SDHC: 1SF: Detected S25FS512S_256K with page size 512 Bytes, erase size 128 KiB, total 64 MiBPCIe1: Root Complex no link, regs @ 0x3400000In: serialOut: serialErr: serialModel: LS1012A RDB BoardBoard: LS1012ARDB Version: RevB, boot from QSPI: bank1SATA link 0 timeout.AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x1 impl SATA modeflags: 64bit ncq pm clo only pmp fbss pio slum part ccc apstFound 0 device(s).SCSI: Net: cbus_baseaddr: 0000000004000000, ddr_baseaddr: 0000000083800000, ddr_phys_baseaddr: 03800000class init complete
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201638 NXP Semiconductors
tmu init completebmu1 init: donebmu2 init: doneGPI1 init completeGPI2 init completeHGPI init completehif_tx_desc_init: Tx desc_base: 0000000083e40400, base_pa: 03e40400, desc_count: 64hif_rx_desc_init: Rx desc base: 0000000083e40000, base_pa: 03e40000, desc_count: 64HIF tx desc: base_va: 0000000083e40400, base_pa: 03e40400HIF init completebmu1 enabledbmu2 enabledpfe_hw_init: donepfe_firmware_initpfe_load_elf: no of sections: 13pfe_firmware_init: class firmware loadedpfe_load_elf: no of sections: 10pfe_firmware_init: tmu firmware loadedls1012a_configure_serdes 0pfe_eth0, pfe_eth1Hit any key to stop autoboot: 0=> setenv ethaddr 11:22:33:44:55:55=> setenv eth1addr 11:22:33:44:55:66=> setenv serverip 192.168.1.1;setenv ipaddr 192.168.1.136=> ping $serveripSpeed detected 3e8Using pfe_eth0 devicehost 192.168.1.1 is alive=> edit ethactedit: pfe_eth1=> ping $serveripSpeed detected 3e8Using pfe_eth1 devicehost 192.168.1.1 is alive
LINUX
To enable PFE in Linux, first stop PFE in U-Boot. In order to do this, first bring the kernel-ls1012a-rdb.itb via PFE interfacethen type pfe stop command on the U-Boot prompt:
=> tftp 0xa0000000 kernel-ls1012a-rdb.itbSpeed detected 3e8Using pfe_eth1 deviceTFTP from server 192.168.1.1; our IP address is 192.168.1.136Filename 'kernel-ls1012a-rdb.itb'.Load address: 0xa0000000Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# #################################################################
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 39
################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############ 5.6 MiB/sdoneBytes transferred = 38342491 (2490f5b hex)=> pfe stopStopping PFE...=> bootm 0xa0000000## Loading kernel from FIT Image at a0000000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM64 Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0xa00000dc Data Size: 12482048 Bytes = 11.9 MiB Architecture: AArch64 OS: Linux Load Address: 0x80080000 Entry Point: 0x80080000## Loading ramdisk from FIT Image at a0000000 ... Using 'config@1' configuration Trying 'ramdisk@1' ramdisk subimage Description: LS2 Ramdisk Type: RAMDisk Image Compression: uncompressed Data Start: 0xa0be9ba4 Data Size: 25849963 Bytes = 24.7 MiB Architecture: AArch64 OS: Linux Load Address: unavailable Entry Point: unavailable## Loading fdt from FIT Image at a0000000 ... Using 'config@1' configuration
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201640 NXP Semiconductors
Trying 'fdt@1' fdt subimage Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0xa0be7790 Data Size: 9101 Bytes = 8.9 KiB Architecture: AArch64 Loading fdt from 0xa0be7790 to 0x90000000 Booting using the fdt blob at 0x90000000 Loading Kernel Image ... OK Using Device Tree in place at 0000000090000000, end 000000009000538cStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0[ 0.000000] Initializing cgroup subsys cpu[ 0.000000] Linux version 4.1.8-rt8+g2511ec0 (jenkins@neptune) (gcc version 4.9.4 20150629 (prerelease) (Linaro GCC 4.9-2015.06) ) #1 SMP Sat Aug 27 04:44:19 CST 2016[ 0.000000] CPU: AArch64 Processor [410fd034] revision 4[ 0.000000] Detected VIPT I-cache on CPU0[ 0.000000] alternatives: enabling workaround for ARM erratum 845719[ 0.000000] earlycon: Early serial console at MMIO 0x21c0500 (options '')[ 0.000000] bootconsole [uart0] enabled[ 0.046613] No BMan portals available![ 0.052448] No QMan portals available![ 0.186759] Freescale FM module, FMD API version 21.1.0[ 0.192162] Freescale FM Ports module[ 0.200605] vfio_fsl_mc_driver_init: Driver registration fails as no fsl_mc_bus found[ 0.658570] fsl-mc bus not found, restool driver registration failed[ 0.927488] usb usb1-port1: over-current condition[ 0.932320] usb usb2-port1: over-current conditionINIT: version 2.88 bootingStarting udev[ 3.038179] pe_load_ddr_section: load address(3fb0000) and elf file address(ffff0000003fb000) rcvdPopulating dev cachehwclock: can't open '/dev/misc/rtc': No such file or directoryFri Aug 26 20:58:57 UTC 2016hwclock: can't open '/dev/misc/rtc': No such file or directoryRunning postinst /etc/rpm-postinsts/100-sysvinit-inittab...Running postinst /etc/rpm-postinsts/101-inetutils-inetd...Running postinst /etc/rpm-postinsts/102-inetutils-ftpd...update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)Removing any system startup links for run-postinsts ...INIT: Entering runlevel: 5Configuring network interfaces... done.Starting system log daemon...0Starting kernel log daemon...0Starting internet superserver: xinetd.
QorIQ SDK (FSL Reference Distro) 2.0 ls1012ardb /dev/ttyS0
ls1012ardb login: rootroot@ls1012ardb:~# find / -name pfe.ko/lib/modules/4.1.8+g4b2f599/kernel/drivers/staging/fsl_ppfe/pfe.koroot@ls1012ardb:~# insmod /lib/modules/4.1.8+g4b2f599/kernel/drivers/staging/fsl_ppfe/pfe.ko[ 39.882345] pfe: module is from the staging directory, the quality is unknown, you have been warned.[ 39.895444] cbus_baseaddr: ffff000000880000, ddr_baseaddr: ffff800003400000, ddr_phys_baseaddr: 83400000, ddr_size: c00000[ 39.907048] pfe_hw_init
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 41
[ 39.909498] CLASS version: 20[ 39.912466] TMU version: 1011231[ 39.916024] BMU1 version: 21[ 39.918907] BMU2 version: 21[ 39.921787] EGPI1 version: 50[ 39.924754] EGPI2 version: 50[ 39.928157] HGPI version: 50[ 39.931041] GPT version: 0[ 39.933747] HIF version: 10[ 39.936851] HIF NOPCY version: 10[ 39.940171] bmu_init(1) done[ 39.943053] bmu_init(2) done[ 39.948670] class_init() done[ 39.961678] tmu_init() done[ 39.964475] gpi_init(1) done[ 39.967585] gpi_init(2) done[ 39.970469] gpi_init(hif) done[ 39.973523] bmu_enable(1) done[ 39.976899] bmu_enable(2) done[ 39.979957] pfe_hif_lib_init[ 39.983049] pfe_hif_init[ 39.985582] pfe_hif_alloc_descr[ 39.989399] pfe_hif_init_buffers[ 39.992789] pfe_firmware_init[ 39.996492] pfe_load_elf[ 39.999043] pe_load_ddr_section: load address(3fb0000) and elf file address(ffff00000050b000) rcvd[ 40.032785] PFE binary version: pfe_ls1012a_00_1-dirty[ 40.037965] pfe_firmware_init: class firmware loaded 0xa60 0xc3010000[ 40.044415] pfe_load_elf[ 40.048328] pfe_firmware_init: tmu firmware loaded 0x200[ 40.053668] pfe_ctrl_init[ 40.056631] pfe_ctrl_init finished[ 40.060039] pfe_eth_init[ 40.062614] pfe_eth_mdio_init[ 40.066072] pfe_ctrl_timer[ 40.076155] libphy: Comcerto MDIO Bus: probed[ 40.082466] pfe_phy_init interface 3[ 40.175983] eth0: pfe_eth_init_one: created interface, baseaddr: ffff000000a80000[ 40.192945] pfe_phy_init interface 7[ 40.276066] eth1: pfe_eth_init_one: created interface, baseaddr: ffff000000aa0000[ 40.283643] pfe_debugfs_initroot@ls1012ardb:~# ifconfig -aeth0 Link encap:Ethernet HWaddr 00:1a:2b:3c:4d:5e BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr 00:aa:bb:cc:dd:ee BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201642 NXP Semiconductors
UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
sit0 Link encap:UNSPEC HWaddr 00-00-00-00-3A-30-30-30-00-00-00-00-00-00-00-00is insmod a NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@ls1012ardb:~# ifconfig eth1 192.168.1.34 up[ 62.478999] eth1: pfe_eth_open[ 62.482403] hif_process_client_req: register client_id 1[ 62.487772] pfe_hif_client_register[ 62.491755] eth1: pfe_gemac_initroot@ls1012ardb:~# [ 67.275999] eth1: Link is Up - 1Gbps/Full - flow control rx/tx
root@ls1012ardb:~#root@ls1012ardb:~#root@ls1012ardb:~#root@ls1012ardb:~# ping 192.168.1.1PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=1.81 ms64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.883 ms^C--- 192.168.1.1 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1001msrtt min/avg/max/mdev = 0.883/1.347/1.811/0.464 msroot@ls1012ardb:~#
Yocto users do not need to install the pfe.ko module. However, developers who are building the
kernel need to install the pfe.ko module. Once the pfe.ko module is installed, the pfe interfaces will
function like normal ethernet interfaces e.g. eth0, eth1.
NOTE
3.5.2 FRDM-LS1012A
3.5.2.1 Switch Settings
No On-Board Switch setting available
3.5.2.2 U-Boot Environment VariablesThe following sections will guide the users on how to set the U-Boot environment and configure the U-Boot networkparameters.
3.5.2.2.1 U-Boot Environment Variable "hwconfig"Environment variable "hwconfig" is used within the U-Boot bootloader to convey information about desired hardwareconfigurations. It is an ordinary environment variable in that:
• It can be set in the U-Boot prompt using the "setenv" command.
• It can be removed from the U-Boot environment by setting it to an empty value, i.e.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 43
=>setenv hwconfig
• It can be modified in the U-Boot command prompt using the "editenv" command.
• It can be saved in the U-Boot environment via the "saveenv" command.
Variable "hwconfig" is set to a sequence of option:value entries separated by semicolons.The default setting for for "hwconfig"on LS1012ARDB is as follows:
hwconfig = fsl_ddr:bank_intlv=auto
3.5.2.2.2 Configuring U-Boot Network ParametersTo support TFTP based deployments, set up the U-Boot environment once, and save it, so that settings persist on subsequentresets.
=>setenv ipaddr <board_ipaddress>=>setenv serverip <tftp_serverip>=>setenv gatewayip <your_gatewayip>=>setenv ethaddr <mac addr0>=>setenv eth1addr <mac addr1>=>setenv ethprime <ethx>=>setenv ethact <ethx>=>setenv netmask 255.255.x.x=>saveenv
(i) <ethx> is the Ethernet port on the board connected to the Linux boot server.
(ii) "netmask" is subnet mask for the Linux boot server's network.
NOTE
Below is one example of the MAC address configuration corresponding to the set up above. Change these values to MACaddresses appropriate for your board.
=>setenv ethaddr 00:04:9F:02:00:FD=>setenv eth1addr 00:04:9F:02:01:FD
=>saveenv
Now the flashed version of U-Boot is ready for performing TFTP based deployments.
Possible <ethx> value
• pfe_eth0
• pfe_eth1
3.5.2.3 RCW (Reset Configuration Word) and Ethernet InterfacesThe following RCW binary is used on the FRDM-LS1012A board:
S_SPNN_3305/PBL_0x33_0x05_800_250_1000_default.bin
This RCW enables:
• Boot from QSPI
• 800MHz Core, 250MHz Platfrom, 1000MT/s DDR
• I2C1,
• SerDes Protocol 0x3505
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201644 NXP Semiconductors
• SGMII, SGMII
• USB 3.0
3.5.2.4 System Memory Map
In 64-bit u-boot, there is a 1:1 mapping of physical address and effective address. After system startup, the boot loader mapsphysical address and effective address as shown in the following table:
Start Physical Address End Physical Address Memory Type Size
0x00_0000_0000 0x00_00FF_FFFF Secure Boot ROM 1MB
0x00_0100_0000 0x00_0FFF_FFFF CCSR 240MB
0x00_1000_0000 0x00_1000_FFFF OCRAM1 64KB
0x00_1001_0000 0x00_1001_FFFF OCRAM2 64 KB
0x00_4000_0000 0x00_5FFF_FFFF QSPI 512MB
0x00_8000_0000 0x00_FFFF_FFFF DRAM 2GB
0x08_8000_0000 0x0F_FFFF_FFFF DRAM2 30G
0x40_0000_0000 0x47_FFFF_FFFF PCI Express1 32G
3.5.2.5 Flash Bank UsageThe FRDM-LS1012A only has one QSPI flash connected over QSPI contoller.
U-Boot 2016.01-g1c18d6a (Jun 17 2016 - 15:15:39 +0530)
SoC: LS1012AE (0x87040010)Clock Configuration: CPU0(A53):800 MHz Bus: 250 MHz DDR: 1000 MT/sReset Configuration Word (RCW): 00000000: 08000008 00000000 00000000 00000000 00000010: 33050000 c000000c 40000000 00001800 00000020: 00000000 00000000 00000000 000c4571 00000030: 00000000 00c28120 00000096 00000000I2C: readyDRAM: 510 MiBMMU warning: gd->secure_ram is not maintained, disabled.Using SERDES1 Protocol: 13061 (0x3305)SF: Detected S25FS512S_256K with page size 512 Bytes, erase size 128 KiB, total 64 MiBIn: serialOut: serialErr: serialModel: LS1012A FREEDOM BoardBoard: LS1012AFRDM Net: cbus_baseaddr: 0000000004000000, ddr_baseaddr: 0000000083800000, ddr_phys_baseaddr: 03800000class init completetmu init completebmu1 init: donebmu2 init: done
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 45
GPI1 init completeGPI2 init completeHGPI init completehif_tx_desc_init: Tx desc_base: 0000000083e40400, base_pa: 03e40400, desc_count: 64hif_rx_desc_init: Rx desc base: 0000000083e40000, base_pa: 03e40000, desc_count: 64HIF tx desc: base_va: 0000000083e40400, base_pa: 03e40400HIF init completebmu1 enabledbmu2 enabledpfe_hw_init: donepfe_firmware_initpfe_load_elf: no of sections: 13pfe_firmware_init: class firmware loadedpfe_load_elf: no of sections: 10pfe_firmware_init: tmu firmware loadedls1012a_configure_serdes 0ls1012a_configure_serdes 1pfe_eth0, pfe_eth1Hit any key to stop autoboot: 0
QSPI flash Layout
Image Size Start Address
RCW + PBI 1MB 0x4000_0000
U-boot boot loader + PPFE binary 1MB 0x4010_0000
U-boot Env 1MB 0x4020_0000
PPA FIT image 2MB 0x4050_0000
Kernel ITB 59MB 0x40A0_0000
3.5.2.6 Programming a New U-Boot and RCW
The following sections will discuss how to individually update U-Boot and RCW. For specific addresses, please refer to theQSPI Flash Memory Map as a reference.
Please refer to Configuring U-Boot Network Parameters to make sure all necessary U-Boot parameters have been set.
Programming a New U-Boot. Use the commands below to update images:
=>tftp 0x80000000 <u-boot_file_name>.bin =>sf probe 0:0=>sf erase 0x100000 0xa0000=>sf write 0x80000000 0x100000 $filesize=> reset
The commands above will only program a new U-Boot. Programming a new RCW will be discussed in the next section.
Programming a New RCW:Use the commands below to update images:
=>tftp 0x80000000 <rcw_file_name>.bin =>sf probe 0:0=>sf erase 0x0 40000=>sf write 0x80000000 0x0 $filesize=> reset
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201646 NXP Semiconductors
Note: RCW and U-Boot binaries must be byte swapped using command (tclsh ./byte_swap.tcl u-boot-dtb.bin u-boot-dtb_swap.bin 8). The ./byte_swap.tcl script is included as a part od the RCW source code.
3.5.2.7 DeploymentEach of these guides will step you through the deployment method of your choice. Please refer to the board's NOR FlashMemory Map within Flash Bank Usage as reference for specific addresses.
3.5.2.7.1 Ramdisk Deployment from TFTP1. Setting U-Boot Environment
The images generated by Yocto allow you to perform ramdisk deployment. Before performing ramdisk deployment, theU-Boot environment variables need to be configured.
Refer to Configuring U-Boot Network Parameters to set the U-Boot environment variables. In addition, execute thefollowing commands at the U-Boot prompt to prepare for ramdisk deployment from TFTP:
=>setenv bootargs ‘ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500'=>saveenv
ramdisk_size needs to be set if the ramdisk uncompress file size is bigger than default setting. It
should be more than ramdisk uncompress file size. The file size information is printed in Yocto build
log.
NOTE
2. Booting Up the System
Execute the following commands to TFTP the images to the board, then boot into Linux.
=>tftp 0x96000000 <kernel_itb_name>=>bootm 0x96000000
The DDR load address for LS1012ARDB is different from FRDM-LS1012A. Using the wrong address
could crash Linux.
NOTE
Now the board will boot into Linux using the images generated by Yocto.
3.5.2.7.2 Ramdisk Deployment from FlashProgramming the kernel and ramdisk into flash will allow you to boot up the board afterwards without the need to re-downloadimages.
1. Setting U-Boot Environment
The images generated by Yocto allow you to perform ramdisk deployment from flash. Before performing ramdiskdeployment from flash, the U-Boot environment variables need to be configured. Refer to Configuring U-Boot NetworkParameters to set the U-Boot environment variables. In addition, execute the following commands at the U-Boot promptto prepare for NFS deployment from flash:
=>setenv bootcmd ‘run ramargs; pfe stop; sf probe 0:0; sf read 0x96000000 0xa00000 0x2800000; bootm 0x96000000
Now U-Boot is ready for flash deployment.
2. Programming Kernel ITB to QSPI Flash
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 47
The kernel should be downloaded to the RAM using TFTP then copied to the flash address <kernel_itb_addr>. At the U-Boot prompt, use the following commands to program the kernel to flash:
=>tftp 0x96000000 <kernel ITB> =>sf probe 0:0; =>sf erase <kernel_itb_addr> $filesize =>sf write 0x96000000 <kernel_itb_addr> $filesize
3. Booting Up the System
The kernel can boot up automatically after the board is powered on, or the following command can be used to boot upthe board at U-Boot prompt:
=>boot
or
=> run ramargs; pfe stop; sf probe 0:0; sf read 0x96000000 0xa00000 0x2800000; bootm 0x96000000
3.5.2.7.3 NFS Deployment1. Generating File System with Yocto
Use Yocto to generate a tar.gz type file system, and uncompress it for NFS deployment.
2. Setting Host NFS Server Environment
a. On the Linux host NFS server, add the following line in the file /etc/exports:
<nfs_root_path> <board_ipaddress>(rw,no_root_squash,async)
b. Restart the NFS service:
/etc/init.d/nfs restart
nfs_root_path: the NFS root directory path on NFS server.
NOTE
3. Setting U-Boot Environment
The NFS file system generated by Yocto allows you to perform NFS deployment. Before performing NFS deployment, theU-Boot environment variables need to be configured. Refer to Configuring U-Boot Network Parameters on page 31 to setthe U-Boot environment variables. In addition, execute the following commands at the U-Boot prompt to prepare for NFSdeployment:
=>setenv bootargs root=/dev/nfs rw nfsroot=<tftp_serverip>:<nfs_root_path> ip=<board_ipaddr>:<tftp_serverip>:<your_gatewayip>:<your_netmask>:<board_name>:eth0:off console=ttyS0,115200=>setenv netdev <ethx>=>saveenv
<ethx> is the port connected on the Linux boot network.
NOTE
Now U-Boot is ready for NFS deployment.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201648 NXP Semiconductors
4. Booting up the System
TFTP the kernel image to the board, then boot it up.
=>tftp 96000000 kernel.itb; =>bootm 96000000:kernel@1 - 96000000:fdt@1
Now the board will boot up with NFS filesystem.
3.5.2.8 Check 'Link Up' for Serial Ethernet InterfacesThis section provides some basic checks that can be performed in U-Boot to help diagnose the cause of the networkingerrors when experiencing problems with Ethernet interfaces.
Check Communication to External PHY
In order to check if U-Boot can communicate with the PHYs on the board, use the U-Boot command mdio list. The U-Bootcommand mdio list will display all manageable Ethernet PHYs.
Example:
=> mdio listPFE_MDIO:1 - RealTek RTL8211F <--> pfe_eth12 - RealTek RTL8211F <--> pfe_eth0
The results from the mdio list command above show that U-Boot was able to see PHYs on each of the SGMII interfaces.
Check Link Status for External PHY
In order to check the status of a SGMII link, use the mdio read command. Since this is a Clause 22 device, we pass twoarguments to the mdio read command.
mdio read <PHY address> <REGISTER Address>
Example:
=> mdio read pfe_eth0 1Reading from bus PFE_MDIOPHY at address 2:1 - 0x79ad=> mdio read pfe_eth1 1Reading from bus PFE_MDIOPHY at address 1:1 - 0x79ad
The link partner (“copper side”) link status bit is in Register #1 on the PHY. The 'Link Status' bit is bit #2 (from the left) of thelast nibble. In the above example the nibble of interest is "d" (d = b'1101'), and therefore the 'Link Status' = 1, which means'link up'. If the link were down this bit would be a "0," and we would see 0x7989.
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 49
3.5.2.9 Basic Networking Ping Test
U-BOOT
The LS1012FRDM has 2 SGMII interfaces. The log below shows how to ping from those 2 interfaces.
U-Boot 2016.01-g1c18d6a (Jun 17 2016 - 15:15:39 +0530)SoC: LS1012AE (0x87040010)Clock Configuration:CPU0(A53):800 MHzBus: 250 MHz DDR: 1000 MT/sReset Configuration Word (RCW):00000000: 08000008 00000000 00000000 0000000000000010: 33050000 c000000c 40000000 0000180000000020: 00000000 00000000 00000000 000c457100000030: 00000000 00c28120 00000096 00000000I2C: readyDRAM: 510 MiBMMU warning: gd->secure_ram is not maintained, disabled.Using SERDES1 Protocol: 13061 (0x3305)SF: Detected S25FS512S_256K with page size 512 Bytes, erase size 128 KiB, total 64 MiBIn: serialOut: serialErr: serialModel: LS1012A FREEDOM BoardBoard: LS1012AFRDM Net: cbus_baseaddr: 0000000004000000, ddr_baseaddr:0000000083800000, ddr_phys_baseaddr: 03800000class init completetmu init completebmu1 init: donebmu2 init: doneGPI1 init completeGPI2 init completeHGPI init completehif_tx_desc_init: Tx desc_base: 0000000083e40400, base_pa: 03e40400, desc_count: 64hif_rx_desc_init: Rx desc base: 0000000083e40000, base_pa: 03e40000, desc_count: 64HIF tx desc: base_va: 0000000083e40400, base_pa: 03e40400HIF init completebmu1 enabledbmu2 enabledpfe_hw_init: donepfe_firmware_initpfe_load_elf: no of sections: 13pfe_firmware_init: class firmware loadedpfe_load_elf: no of sections: 10pfe_firmware_init: tmu firmware loadedls1012a_configure_serdes 0ls1012a_configure_serdes 1pfe_eth0, pfe_eth1Hit any key to stop autoboot: 0=> setenv ethaddr 11:22:33:44:55:55=> setenv eth1addr 11:22:33:44:55:66=> setenv serverip 192.168.5.124;setenv ipaddr 192.168.5.136=> edit ethactedit: pfe_eth1=> ping $serveripSpeed detected 3e8Using pfe_eth1 devicehost 192.168.5.124 is alive
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201650 NXP Semiconductors
=> edit ethactedit: pfe_eth0=> ping $serveripSpeed detected 3e8Using pfe_eth0 devicehost 192.168.5.124 is alive=>
LINUX
To enable PFE in Linux, First we need to stop pfe in u-boot but first bring
the kernel-ls1012a-frdm.itb via pfe interface, then perform pfe stop
On U-Boot prompt:
=> tftp 0x96000000 kernel-ls1012a-frdm.itbSpeed detected 3e8Using pfe_eth0 deviceTFTP from server 192.168.5.124; our IP address is 192.168.5.125Filename 'kernel-ls1012a-frdm.itb'.Load address: 0x96000000Loading:############################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################2.5 MiB/sdoneBytes transferred = 40631911 (26bfe67 hex)=> pfe stopStopping PFE...=> bootm 0x96000000## Loading kernel from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM64 Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x9600013c Data Size: 12502016 Bytes = 11.9 MiB Architecture: AArch64 OS: Linux Load Address: 0x80080000 Entry Point: 0x80080000## Loading ramdisk from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'ramdisk@1' ramdisk subimage Description: Ramdisk Type: RAMDisk Image Compression: uncompressed Data Start: 0x96bef354
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 51
Data Size: 24491924 Bytes = 23.4 MiB Architecture: AArch64 OS: Linux Load Address: unavailable Entry Point: unavailable## Loading fdt from FIT Image at 96000000 ... Using 'config@1' configuration Trying 'fdt@1' fdt subimage Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x96bec5f0 Data Size: 11490 Bytes = 11.2 KiB Architecture: AArch64 Loading fdt from 0x96bec5f0 to 0x90000000 Booting using the fdt blob at 0x90000000 Loading Kernel Image ... OK Using Device Tree in place at 0000000090000000, end 0000000090005ce1
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0[ 0.000000] Initializing cgroup subsys cpu[ 0.000000] Linux version 4.1.8-rt8+g2511ec0 (jenkins@neptune) (gcc version 4.9.4 20150629 (prerelease) (Linaro GCC 4.9-2015.06) ) #1 SMP Sat Aug 27 04:44:19 CST 2016[ 0.000000] CPU: AArch64 Processor [410fd034] revision 4[ 0.000000] Detected VIPT I-cache on CPU0[ 0.000000] alternatives: enabling workaround for ARM erratum 845719[ 0.000000] earlycon: Early serial console at MMIO 0x21c0500 (options '')[ 0.000000] bootconsole [uart0] enabled[ 0.046613] No BMan portals available![ 0.052448] No QMan portals available![ 0.186759] Freescale FM module, FMD API version 21.1.0[ 0.192162] Freescale FM Ports module[ 0.200605] vfio_fsl_mc_driver_init: Driver registration fails as no fsl_mc_bus found[ 0.658570] fsl-mc bus not found, restool driver registration failed[ 0.927488] usb usb1-port1: over-current condition[ 0.932320] usb usb2-port1: over-current conditionINIT: version 2.88 bootingStarting udev[ 3.038179] pe_load_ddr_section: load address(3fb0000) and elf file address(ffff0000003fb000) rcvdPopulating dev cachehwclock: can't open '/dev/misc/rtc': No such file or directoryFri Aug 26 20:58:57 UTC 2016hwclock: can't open '/dev/misc/rtc': No such file or directoryRunning postinst /etc/rpm-postinsts/100-sysvinit-inittab...Running postinst /etc/rpm-postinsts/101-inetutils-inetd...Running postinst /etc/rpm-postinsts/102-inetutils-ftpd...update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)Removing any system startup links for run-postinsts ...INIT: Entering runlevel: 5Configuring network interfaces... done.Starting system log daemon...0Starting kernel log daemon...0Starting internet superserver: xinetd.
QorIQ SDK (FSL Reference Distro) 2.0 ls1012afrdm /dev/ttyS0
ls1012afrdm login:
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 201652 NXP Semiconductors
root@ls1012afrdm:~#root@ls1012afrdm:~# [ 48.955650] eth0: Link is Up - 1Gbps/Full - flow control rx/txroot@ls1012afrdm:~# ping 192.168.5.124PING 192.168.5.124 (192.168.5.124) 56(84) bytes of data.64 bytes from 192.168.5.124: icmp_seq=1 ttl=128 time=1.92 ms64 bytes from 192.168.5.124: icmp_seq=2 ttl=128 time=1.51 ms64 bytes from 192.168.5.124: icmp_seq=3 ttl=128 time=1.44 ms^C--- 192.168.5.124 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2002msrtt min/avg/max/mdev = 1.440/1.625/1.925/0.214 msroot@ls1012afrdm:~#root@ls1012afrdm:~# ifconfig -aeth0 Link encap:Ethernet HWaddr 00:1a:2b:3c:4d:5einet addr:192.168.5.125 Bcast:192.168.5.255 Mask:255.255.255.0inet6 addr: fe80::21a:2bff:fe3c:4d5e/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:39 errors:0 dropped:0 overruns:0 frame:0TX packets:11 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:9165 (8.9 KiB) TX bytes:894 (894.0 B)eth1 Link encap:Ethernet HWaddr 00:aa:bb:cc:dd:eeBROADCAST MULTICAST MTU:1500 Metric:1RX packets:0 errors:0 dropped:0 overruns:0 frame:0TX packets:0 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)lo Link encap:Local Loopbackinet addr:127.0.0.1 Mask:255.0.0.0inet6 addr: ::1/128 Scope:HostUP LOOPBACK RUNNING MTU:65536 Metric:1RX packets:0 errors:0 dropped:0 overruns:0 frame:0TX packets:0 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)sit0 Link encap:UNSPEC HWaddr 00-00-00-00-3A-30-30-30-00-00-00-00-00-00-00-00NOARP MTU:1480 Metric:1RX packets:0 errors:0 dropped:0 overruns:0 frame:0TX packets:0 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)root@ls1012afrdm:~#
Yocto users do not need to install the pfe.ko module. However, developers who are building the
kernel need to install the pfe.ko module. Once the pfe.ko module is installed, the pfe interfaces will
function like normal ethernet interfaces e.g. eth0, eth1.
NOTE
Deploy U-Boot, Linux Kernel, and Root Filesystem to a Reference Design Board (RDB)
Supported Boards
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 53
Chapter 4System Recovery
4.1 Environment Setup
4.1.1 Environment Setup (Common)The section describes the related setup for system recovery
1. Required Materials
• Target board
• The related recovery image files
2. Host PC setup
The host PC should have a serial-terminal program capable of running at 115,200bps, 8-N-1, for communicating with U-Boot running on the target board.
3. Target board setup
a. Power off the target board system if the power is already on.
b. If U-Boot runs on this board, and U-Boot commands will be used to reflash the U-Boot images, connect the targetboard to the network via the eTSEC port on the board.
c. Connect the target board to the host machine via the serial port with an RS-232 cable and the joined NXP adaptercable, if needed.
d. Set up the serial terminal in the host machine with 115,200bps, 8-N-1, no flow control.
e. Verify all the switches and jumpers are set up correctly to default values described in <Hardware configurations> asdescribed in the Switch Settings section of the board's Software Deployment Guide
f. Connect the JTAG cable for your CodeWarrior TAP or Gigabit TAP to the board if you will be using the CodeWarriorFlash Programmer to recover the board image.
g. Power on the board.
4.2 Image Recovery
4.2.1 Recover system with already working U-BootTarget Board Setup
1. Power off the target board system if the power is already on.
2. Connect the target board to the network via the eTSEC port on the board.
3. Connect the target board to the host machine via the serial port with an RS-232 cable and the joined NXP adaptor cable,if needed.
4. Set up the serial terminal in the host machine with 115,200bps, 8-N-1, no flow control.
5. Verify all the switches and jumpers are setup correctly to default value described in the board's "Switch Settings" sectionin the board's Software Deployment Guide.
System Recovery
Environment Setup
QorIQ LS1012A BSP v0.5, Rev. 0, December 201654 NXP Semiconductors
6. Power on the board.
Refer to the “Programming a New U-Boot…” section in the Software Deployment Guide for the target board to be recovered.
4.2.2 Recover system using CodeWarrior Flash Programmer
Environment Setup
Required Materials
• Target board.
• CodeWarrior for Power Architecture v10.x (for Windows or Linux)
• CodeWarrior TAP or Gigabit TAP run control device.
• The related recovery image files.
Host PC setup
The host PC is assumed to be running Windows 7, or one of the supported distributions of Linux (refer to the CodeWarriorPA10 Release Notes for the list of supported Linux distributions).
This machine should have latest CodeWarrior PA10 installed and working correctly. If the run control device is a CodeWarriorTAP used over USB, then the USB drivers should be installed automatically when the device is plugged in. If the run controldevice is a CodeWarrior TAP used over Ethernet, or a Gigabit TAP, then both the host PC and TAP should be connected tothe network, and communications between them should be verified.
Target board setup
1. Power off the Target board system if the power is already on.
2. Connect the Target board to the host machine via the serial port with an RS-232 cable and the joined NXP adaptorcable, if needed.
3. Set up the serial terminal in the host machine with 115,200bps, 8-N-1, no flow control.
4. Verify all the switches and jumpers are set up correctly to default values described in the "Switch Settings" section inthe board's Software Deployment Guide.
5. Connect the TAP's JTAG cable to the board.
6. Power on the board.
System Recovery
1. Start the CodeWarrior PA10 or ARMv7 IDE.
2. For LS102x targets, see Chapter 3 of Getting Started for ARMv7 Processors.pdf in the CodeWarrior ARMv7installation for steps on creating a BareBoard Core0 project for the LS102x processor on this target board. For otherQorIQ targets, see Quick Start for PA 10 Processors.pdf in the CodeWarrior PA10 installation for steps on creating aBareBoard AMP Core0 project for the QorIQ processor on this target board. In the "Debug Target Settings Page", of theprocedure for creating a new project, uncheck the 'Download' option, and enable the 'Download SRAM' option, ifavailable.
3. Select your CodeWarrior TAP or Gigabit TAP as your debug connection type. For CodeWarrior TAP, select “USB” or“Ethernet” as the connection medium.
4. Build the project.
5. Bring up the Target Tasks view: go to Window>Show View>Other>Debug>Target Task.
6. Import the Flash Profile:
a. In the Target Tasks view, click on the Import button. A file-browser window will appear, showing the"Flash_Programmer" folder.
System Recovery
Image Recovery
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 55
b. Open the "Flash_Programmer" folder, then the folder associated with the processor family on this target board.
c. Select the configuration file for the particular target and flash device to be programmed on this target board, andclick OK to import it. This file will appear in the Target Tasks view.
7. In the board's Software Deployment Guide, locate the “Flash Bank Usage” section for the target board to be recovered.
a. Identify the NOR/NAND/SPI flash memory map that applies to the flash to be programmed. For the following steps,if the target flash supports multiple banks, choose the starting addresses for ‘Bank0’ or ‘current bank’, asappropriate.
b. Identify the starting address for the u-boot image.
c. Identify the starting address for the RCW image (if applicable).
d. Identify the starting address for the PPA image (if applicable).
e. Identify the starting address for the ucode/microcode (if applicable).
f. Identify the starting address for the dtb image.
g. Identify the starting address for the RamDisk image.
h. Identify the starting address for the Linux Kernel image.
8. Configure Flash Programmer.
a. Double-click on the file name that was imported with the flash profile, to bring up the Flash Programmer Task view.
b. Click on 'Add Action'>'Program/Verify'.
c. Set 'File Type' to "Binary".
d. Click on 'File System' and navigate to the folder containing the u-boot binary image.
e. Enable "Erase sectors before program".
f. Enable "Apply address offset", and enter the starting address where this binary recovery image will be flashed (seethe tables in the previous step for examples).
g. (OPTIONAL) Enable 'Verify after program' to verify that the flash programming was successful.
h. Repeat steps (starting with Click 'Add Action') above for each binary image file to be programmed into flash.
9. Execute Flash Programming.
a. In the Target Tasks view, right-click on the imported filename and select the green Execute button to launch theprogrammer.
b. If Execute is not green, the debugger is not running. The debugger must be running for this flash programmer towork.
c. When finished flashing, terminate the debugger.
10.This is the end of the process. Now the boot loader, kernel and root file system are programmed to flash.
11. Reset or power-cycle the board and verify that u-boot appears in the board’s serial terminal.
System Recovery
Image Recovery
QorIQ LS1012A BSP v0.5, Rev. 0, December 201656 NXP Semiconductors
Chapter 5About Yocto Project
5.1 Yocto Project Quick StartThe Yocto Project Quick Start explains basic concepts and the use of its core components. Step through a simple exampleto show how to build a small image and run it using the QEMU emulator.
For more information see the Yocto Project Quick Start
5.2 Application Development Toolkit User's GuideThe Application Development Toolkit consists of an architecture-specific cross-toolchain and a matching sysroot that are bothbuilt by the Yocto Project build system Poky.
For more information see the Application Development Toolkit User's Guide located in the following SDK directory:sdk_documentation/pdf/yocto/adt-manual.pdf
For more information see the Application Development Toolkit User's Guide
5.3 Board Support Packages - Developer's GuideA Board Support Package (BSP) is a collection of information that defines how to support a particular hardware device, setof devices, or hardware platform. The BSP includes information about the hardware features present on the device and kernelconfiguration information along with any additional hardware drivers required.
For more information see the Board Support Packages - Developer's Guide located in the following SDK directory:sdk_documentation/pdf/yocto/bsp-guide.pdf
For more information see the Board Support Packages - Developer's Guide
5.4 Yocto Project Development ManualUse a Yocto Project to develop embedded Linux images and user-space applications to run on targeted devices.
For more information see the Yocto Project Development Manual located in the following SDK directory: sdk_documentation/pdf/yocto/dev-manual.pdf
For more information see the Yocto Project Development Manual
5.5 Yocto Project Linux Kernel Development ManualThe Yocto Project Linux Kernel Development Manual describes how to work with Linux Yocto kernels and provides someconceptual information on the construction of the Yocto Linux kernel tree.
For more information see the Yocto Project Linux Kernel Development Manual located in the following SDK directory:sdk_documentation/pdf/yocto/kernel-dev.pdf
About Yocto Project
Yocto Project Quick Start
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 57
For more information see the Yocto Project Linux Kernel Development Manual
5.6 Yocto Project Profiling and Tracing ManualThe Yocto Project Profiling and Tracing Manual presents a set of common and generally useful tracing and profilingschemes along with their applications (as appropriate) to each tool.
For more information see the Yocto Project Profiling and Tracing Manual located in the following SDK directory:sdk_documentation/pdf/yocto/profile-manual.pdf
For more information see the Yocto Project Profiling and Tracing Manual
5.7 Yocto Project Reference ManualThe Yocto Project uses the Poky build tool to construct complete Linux images.
For more information see the Yocto Project Reference Manual located in the following SDK directory:sdk_documentation/pdf/yocto/poky-ref-manual.pdf
For more information see the Yocto Project Reference Manual
About Yocto Project
Yocto Project Profiling and Tracing Manual
QorIQ LS1012A BSP v0.5, Rev. 0, December 201658 NXP Semiconductors
Chapter 6Linux Kernel Drivers
6.1 Audio
6.1.1 SAI User Manual LS1012A
Description
This document describes how to configure and test SAI audio driver for LS1012A FRDM board. The integrated I2S moduleis NXP's Synchronous Audio Interface (SAI). The codec is SGTL5000 stereo audio codec.
RCW configuration
Refer to the below table for the RCW for Audio on the LS1012A FRDM board.
Board RCW
LS1012A FRDM Bit 364, EC1_EXT_SAI2_TX = 1; Bit 365,EC1_EXT_SAI2_RX =1; Bit 366-367, EC1_BASE = 00
Kernel Configure Options Tree View
Kernel Configure Tree View Options Description
Device Drivers ---> <*> I2C support ---> [*] Enable compatibility bits for old user-space [*] I2C device interface [*] I2C bus multiplexing support Multiplexer I2C Chip support ---> <*> Philips PCA954x I2C Mux/switches [*] Autoselect pertinent helper modules I2C Hardware Bus support ---> <*> IMX I2C interface <*> Voltage and Current Regulator Support ---> [*] Regulator debug support [*] Provide a dummy regulator if regulator lookups fail [*] Fixed voltage regulator support <*> Sound card support <*> Advanced Linux Sound Architecture -> [*] OSS PCM (digital audio) API [*] OSS PCM (digital audio) API - Include plugin system [*] Support old ALSA API [*] Verbose procfs contents ALSA for SoC audio support ---> SoC Audio for Freescale CPUs --->
Enable ALSA SOC driver, I2Cdriver and EDMA driver.
Linux Kernel Drivers
Audio
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 59
Kernel Configure Tree View Options Description
<*> Synchronous Audio Interface (SAI) module support CODEC drivers ---> <*> Freescale SGTL5000 CODEC <*> ASoC Simple sound card support <*> DMA Engine support ---> <*> Freescale eDMA engine support support
Identifier
Below are the configure identifiers which are used in kernel source code and default configuration files.
Option Values Default Value Description
CONFIG_I2C_IMX y/m/n y I2C driver needed forconfiguring SGTL5000
CONFIG_SOUND y/m/n y Enable sound card support
CONFIG_SND y/m/n y Enable advanced Linuxsound architecture supports
CONFIG_SND_PCM_OSS y/m/n y Enable OSS digital audio
CONFIG_SND_PCM_OSS_PLUGINS
y/m/n y Support conversion ofchannels, formats and rates
CONFIG_SND_SUPPORT_OLD_API
y/m/n y Enable support old ALSAAPI
CONFIG_SND_SOC_FSL_SAI
y/m/n y Enable SAI module support
CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM
y/m/n y Enable generic dma enginefor PCM
CONFIG_SND_SIMPLE_CARD
y/m/n y Enable generic simplesound card support
CONFIG_SND_SOC_SGTL5000
y/m/n y Enable codec sgtl5000support
CONFIG_FSL_EMDA y/m/n y Enable EDMA enginesupport
Source FilesThe driver source is maintained in the Linux kernel source tree.
Source File Description
sound/soc/fsl ALSA SOC driver source
Verification in Linux
1. The following messages will be shown in the kernel boot process.
sgtl5000 5-000a: sgtl5000 revision 0x11
Linux Kernel Drivers
Audio
QorIQ LS1012A BSP v0.5, Rev. 0, December 201660 NXP Semiconductors
sgtl5000 5-000a: Using internal LDO instead of VDDD......asoc-simple-card sound: sgtl5000 <-> 2b60000.sai mapping ok......ALSA device list: #0: 2b60000.sai-sgtl5000
2. If the device nodes don't already exist, create directory /dev/snd/, and create device nodes with the followingcommands in /dev/snd/ directory.
mknod controlC0 c 116 0mknod pcmC0D0c c 116 24mknod pcmC0D0p c 116 16
3. On LS1012A FRDM board, the LineOut interface is J8 and the LineIn interface is J13
4. Run the following aplay commands to test playback. Run the following arecord command to test record.
aplay -f S16_LE -r 44100 -t wav -c 2 44k-16bit-stereo.wav
arecord -d 10 -f S16_LE -r 44100 -t wav -c 2 44k-16bit-stereo-10s.wavaplay -f S16_LE -r 44100 -t wav -c 2 44k-16bit-stereo-10s.wav
5. Use alsamixer to adjust the volume for playing by the option “PCM” and recording gain by the option "Mic" . Usealsamixer to choose LINE IN or MIC.
6.2 DMA Controller
6.2.1 Enhanced Direct Memory Access Driver (ARM)
6.2.1.1 eDMA User Manual
Description
The SoC integrates NXP's Enhanced Direct Memory Access module. Slave device such as I2C or SAI can deploy the DMAfunctionality to accelerate the transfer and release the CPU from heavy load.
Kernel Configure Options
Tree View
Below are the configure options need to be set/unset while doing "make menuconfig" for kernel
Kernel Configure Tree View Options Description
Device Drivers --->
[*] DMA Engine support ---> --->
<*> Freescale eDMA engine support
DMA engine subsystem driver and eDMA driver support
Linux Kernel Drivers
DMA Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 61
Identifier
Below are the configure identifiers which are used in kernel source code and default configuration files.
Option Values Default Value Description
CONFIG_FSL_EDMA y/m/n n eDMA Driver
Device Tree Binding
Device Tree Node
Below is an example device tree node required by this feature. Note that it may has differences among platforms.
edma0: edma@2c00000 { #dma-cells = <2>; compatible = "fsl,vf610-edma"; reg = <0x0 0x2c00000 0x0 0x10000>, <0x0 0x2c10000 0x0 0x10000>, <0x0 0x2c20000 0x0 0x10000>; interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "edma-tx", "edma-err"; dma-channels = <32>; big-endian; clock-names = "dmamux0", "dmamux1"; clocks = <&platform_clk 1>, <&platform_clk 1>; };
Device Tree Node Binding for Slave Device
Below is the device tree node binding for a slave device which deploy the eDMA functionality.
i2c0: i2c@2180000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,vf610-i2c"; reg = <0x0 0x2180000 0x0 0x10000>; interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; clock-names = "i2c"; clocks = <&platform_clk 1>; dmas = <&edma0 1 39>, <&edma0 1 38>; dma-names = "tx", "rx"; status = "disabled"; };
Source Files
The following source files are related the this feature in Linux kernel.
Table 3. Source Files
Source File Description
drivers/dma/fsl-edma.c The eDMA driver file
Linux Kernel Drivers
DMA Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201662 NXP Semiconductors
Verification in Linux
1. Use the slave device which deploy the eDMA functionality to verify the eDMA driver, below is a verification with the I2Csalve.
root@ls1021aqds:~# i2cdetect 0WARNING! This program can confuse your I2C bus, cause data loss and worse!I will probe file /dev/i2c-0.I will probe address range 0x03-0x77.Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f00: -- -- -- -- -- -- -- -- -- -- -- -- --10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --70: -- -- -- -- -- -- -- --root@ls1021aqds:~# i2cdump 0 0x69 i 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef00: 05 07 ff ff 5d 55 10 55 11 05 1e 00 e8 03 b5 ff ??..]U?U???.???.10: ff e8 03 95 00 00 00 00 aa fe 9a 00 00 00 00 78 .???....???....x20: 05 12 04 ff 00 7f 40 14 1d 60 3c 83 05 00 40 00 ???..?@??`<[email protected]: fe 80 c6 29 00 00 00 7a 00 ff ff ff ff ff ff ff ???)...z........40: 05 07 ff ff 5d 55 10 55 11 05 1e 00 e8 03 b5 ff ??..]U?U???.???.50: ff e8 03 95 00 00 00 00 aa fe 9a 00 00 00 00 78 .???....???....x60: 05 12 04 ff 00 7f 40 14 1d 60 3c 83 05 00 40 00 ???..?@??`<[email protected]: fe 80 c6 29 00 00 00 7a 00 ff ff ff ff ff ff ff ???)...z........80: 07 ff ff 5d 55 10 55 11 05 1e 00 e8 03 b5 ff ff ?..]U?U???.???..90: e8 03 95 00 00 00 00 aa fe 9a 00 00 00 00 78 00 ???....???....x.a0: 12 04 ff 00 7f 40 14 1d 60 3c 83 05 00 40 00 fe ??..?@??`<??.@.?b0: 80 c6 29 00 00 00 7a 00 ff ff ff ff ff ff ff ff ??)...z.........c0: 07 ff ff 5d 55 10 55 11 05 1e 00 e8 03 b5 ff ff ?..]U?U???.???..d0: e8 03 95 00 00 00 00 aa fe 9a 00 00 00 00 78 00 ???....???....x.e0: 12 04 ff 00 7f 40 14 1d 60 3c 83 05 00 40 00 fe ??..?@??`<??.@.?f0: 80 c6 29 00 00 00 7a 00 ff ff ff ff ff ff ff ff ??)...z.........root@ls1021aqds:~# cat /proc/interrupts CPU0 CPU1 29: 0 0 GIC 29 arch_timer 30: 5563 5567 GIC 30 arch_timer112: 260 0 GIC 112 fsl-lpuart120: 32 0 GIC 120 2180000.i2c121: 0 0 GIC 121 2190000.i2c167: 8 0 GIC 167 eDMAIPI0: 0 1 CPU wakeup interruptsIPI1: 0 0 Timer broadcast interruptsIPI2: 1388 1653 Rescheduling interruptsIPI3: 0 0 Function call interruptsIPI4: 2 4 Single function call interruptsIPI5: 0 0 CPU stop interruptsErr: 0root@ls1021aqds:~#
Linux Kernel Drivers
DMA Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 63
6.3 Enhanced Secured Digital Host Controller (eSDHC)
6.3.1 eSDHC Driver User Manual
Description
The enhanced SD Host Controller(eSDHC) provides an interface between the host system and MMC/SD cards.
The eSDHC supports 1/4-bit data modes and bus clock frequency up to 50MHz
Module Loading
The eSDHC device driver support either kernel built-in or module.
U-boot Configuration
Runtime options
Env Variable Env Description Sub option Option Description
hwconfig Hardware configuration for u-boot setenv hwconfig sdhc Enable esdhc for the kernel
Kernel Configure Options
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers ---> <*> MMC/SD/SDIO card support ---> <*> MMC block device driver (8) Number of minors per block device [*] Use bounce buffer for simple hosts
Enables SD/MMC block devicedriver support
*** MMC/SD/SDIO Host Controller Drivers *** <*> Secure Digital Host Controller Interface support <*> SDHCI platform and OF driver helper [*] SDHCI OF support for the NXP eSDHC controller
Enables NXP eSDHC driversupport
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_MMC y/n n Enable SD/MMC bus protocol
CONFIG_MMC_BLOCK y/n y Enable SD/MMC block device driver support
Table continues on the next page...
Linux Kernel Drivers
Enhanced Secured Digital Host Controller (eSDHC)
QorIQ LS1012A BSP v0.5, Rev. 0, December 201664 NXP Semiconductors
Table continued from the previous page...
Option Values Default Value Description
CONFIG_MMC_BLOCK_MINORS integer 8 Number of minors per block device
CONFIG_MMC_BLOCK_BOUNCE y/n y Enable continuous physical memory for transmit
CONFIG_MMC_SDHCI y/n y Enable generic sdhc interface
CONFIG_MMC_SDHCI_PLTFM y/n y Enable common helper function support for sdhciplatform and OF drivers
CONFIG_MMC_SDHCI_OF_ESDHC y/n y Enable NXP eSDHC support
Device Tree Binding
Property Type Status Description
compatible String Required Should be 'fsl,esdhc'
reg integer Required Register map
Default node:
qoriq-esdhc-0.dtsi:sdhc: sdhc@114000 { compatible = "fsl,esdhc"; reg = <0x114000 0x1000>; interrupts = <48 2 0 0>; clock-frequency = <0>;};
For special platform (T1040 as example):/include/ "qoriq-esdhc-0.dtsi" sdhc@114000 { compatible = "fsl,t1040-esdhc", "fsl,esdhc"; fsl,iommu-parent = <&pamu0>; fsl,liodn-reg = <&guts 0x530>; /* eSDHCLIODNR */ sdhci,auto-cmd12; rcpm-wakeup = <&rcpm 0x00000080>; };
NOTE: For different platform, the compatilbe can be different. And the property "sdhci, auto-cmd12" is option.
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/mmc/host/sdhci.c Linux SDHCI driver support
drivers/mmc/host/sdhci-pltfm.c Linux SDHCI platform devices support driver
drivers/mmc/host/sdhci-of-esdhc.c Linux eSDHC driver
Linux Kernel Drivers
Enhanced Secured Digital Host Controller (eSDHC)
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 65
User Space Application
The following applications will be used during functional or performance testing. Please refer to the SDK UM document forthe detailed build procedure.
CommandName
Description PackageName
iozone IOzone is a filesystem benchmark tool. The benchmark generates and measures avariety of file operations.The benchmark tests file I/O performance for the followingoperations: Read, write, re-read, re-write, read backwards, read strided, fread, fwrite,random read, pread ,mmap, aio_read, aio_write.
iozone
Verification in U-boot
The u-boot log:
=> mmcinfoDevice: FSL_ESDHC Manufacturer ID: 3 OEM: 5344 Name: SD02G Tran Speed: 25000000 Rd Block Len: 512 SD version 2.0 High Capacity: No Capacity: 2032664576 Bus Width: 4-bit => mmc read 0 10000 0 1 MMC read: dev # 0, block # 0, count 1 ... 1 blocks read: OK => mmc part 0 Partition Map for MMC device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type
1 16 3970032 b
Verification in Linux
Add environment value
=> setenv hwconfig sdhc
The booting log
......sdhci: Secure Digital Host Controller Interface driversdhci: Copyright(c) Pierre Ossmanmmc0: SDHCI controller on ffe2e000.sdhci-of [ffe2e000.sdhci-of] using PIO......mmc0: new SD card at address 87e2mmcblk0: mmc0:87e2 SD02G 1.89 GiB
Linux Kernel Drivers
Enhanced Secured Digital Host Controller (eSDHC)
QorIQ LS1012A BSP v0.5, Rev. 0, December 201666 NXP Semiconductors
mmcblk0: p1
Check the disk
~ # fdisk -l /dev/mmcblk0
disk /dev/mmcblk0: 2032 MB, 2032664576 bytes
63 heads, 62 sectors/track, 1016 cylinders
Units = cylinders of 3906 * 512 = 1999872 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 1016 1984217 b Win95 FAT32 ~ #
Mount the file system and operate the card.
~ #
~ # mkdir /mnt/sd
~ # mount -t vfat /dev/mmcblk0p1 /mnt/sd
~ # ls /mnt/sd/
vim
~ # cp /bin/busybox /mnt/sd
~ # ls /mnt/sd
busybox vim
~ # umount /mnt/sd
~ # mount -t vfat /dev/mmcblk0p1 /mnt/sd
~ # ls /mnt/sd
busybox vim
~ #
Benchmarking
~ #
~ # # iozone -Rab ./iosdresult/result -i 0 -i 1 -f test -n
512M -g 1G -r 64K
Linux Kernel Drivers
Enhanced Secured Digital Host Controller (eSDHC)
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 67
Iozone: Performance Test of File I/O
Version $Revision: 3.263 $
Compiled for 32 bit mode.
Build: linux-arm
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million,
Jean-Marc Zucconi, Jeff Blomberg,
Erik Habbinga, Kris Strecker, Walter Wong.
Run began: Wed Feb 16 20:33:04 2011
Excel chart generation enabled
Auto Mode
Using minimum file size of 524288 kilobytes.
Using maximum file size of 1048576 kilobytes.
Record Size 64 KB
Command line used: iozone -Rab ./iosdresult/result -i 0 -i 1 -f test -n 512M -g 1G -r 64K
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
524288 64 7040 7253 371022 372079
1048576 64 6537 6566 9857 10203
Linux Kernel Drivers
Enhanced Secured Digital Host Controller (eSDHC)
QorIQ LS1012A BSP v0.5, Rev. 0, December 201668 NXP Semiconductors
Known Bugs, Limitations, or Technical Issues
1. Call trace when run "iozone" to test SDCARD performace on some platforms
workaround:increase the timeout value (in kernel configuration) and decrease the dirty_ratio in proc file system.
1) menuconfig:
Kernel hacking
(xxx) Default timeout for hung task detection (in seconds)
Note: the xxx may be 400 seconds or greater
2) modify 'proce file system':
echo xx > /proc/sys/vm/dirty_ratio
echo xx > /proc/sys/vm/dirty_background_ratio
Note: the xx may be 10 or 5, which meas 10% or 5%, the default is 20%.
2. The platform whose card is required to work on a special transfer mode which is not FS or HS mode needs a specialrcw. (e.g. rcw_66_15_1800MHz_emmc_ddr.rcw is for t2080qds eMMC DDR mode. Because of pin multiplexing with SPI,SPI would not work when eMMC card works on DDR mode)
6.4 PCI Express Interface Controller
6.4.1 PCIe Linux Driver
Module Loading
The MPC85xx/Layerscape PCIE host bridge support code is compiled into the kernel. It is not available as a module.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Bus support ---> [*] PCI support [*] Message Signaled Interrupts (MSI and MSI-X)
Enable PCI host bridge andmessage support
Bus support ---> PCI host controller drivers ---> [*] Freescale Layerscape PCIe controller
Enable NXP LayerscapePCIe controller
Device Drivers ---> [*]Network device support ---> [*]Ethernet device support ---> [*] Intel devices ---> <*> Intel (R) PRO/1000 PCI-Express Gigabit Ethernet support
Intel PRO/1000 PCI-Expresssupport
Table continues on the next page...
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 69
Table continued from the previous page...
Kernel Configure Tree View Options Description
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) ---> <*> Silicon Image 3124/3132 SATA support
Enable support for SiliconImage 3124/3132 Serial ATA.
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_PCI y/n y Enable PCI host bridge
CONFIG_PCI_MSI y/n y Message support
CONFIG_PCI_LAYERSCAPE y/n y Enable PCI for Layerscape
CONFIG_E1000E y/m/n y Enable Intel Pro/1000 driver
CONFIG_SATA_SIL y/m/n y Silicon Image SATA support
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
arch/powerpc/sysdev/fsl_pci.c The MPC85XX platform PCIE host bridge support source
drivers/pci/host/pci-layerscape.c The Layerscape platform PCIE host bridge support source
drivers/net/ethernet/intel/e1000e/ Intel Pro/1000 driver source code
drivers/ata/sata_sil.c Silicon Image source code
SATA Card Test Procedure
the user can use commandfdisk, mke2fs mount to operate the ide disk.After kernel boots up, please follow the log to operate:
[root@pX0XX /root]# fdisk -l
Disk /dev/sda: 85.8 GB, 85899345920 bytes255 heads, 63 sectors/track, 10443 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sda doesn't contain a valid partition table
[root@pX0XX /root]# fdisk /dev/sdaDevice contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabelBuilding a new DOS disklabel. Changes will remain in memory only,
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201670 NXP Semiconductors
until you decide to write them. After that the previous contentwon't be recoverable.
The number of cylinders for this disk is set to 10443.There is nothing wrong with that, but this is larger than 1024,and could in certain setups cause problems with:1) software that runs at boot time (e.g., old versions of LILO)2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): nCommand action e extended p primary partition (1-4)pPartition number (1-4): 1First cylinder (1-10443, default 1): Using default value 1Last cylinder or +size or +sizeM or +sizeK (1-10443, default 10443): 100
Command (m for help): wThe partition table has been altered!
Calling ioctl() to re-read partition tablesd 0:0:0:0: [sda] 167772160 512-byte hardware sectors (85899 MB)sd 0:0:0:0: [sda] Write Protect is offsd 0:0:0:0: [sda] Asking for cache data failedsd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1
[root@pX0XX /root]# mke2fs /dev/sda1mke2fs 1.34 (25-Jul-2003)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)100576 inodes, 200804 blocks10040 blocks (5.00%) reserved for the super userFirst data block=07 block groups32768 blocks per group, 32768 fragments per group14368 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840
Writing inode tables: done Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 31 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@pX0XX /root]# mkdir sda1_test[root@pX0XX /root]# mount /dev/sda1 sda1_test/[root@pX0XX /root]# cp /bin/tar sda1_test/[root@pX0XX /root]#
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 71
Ethernet Card Test Procedure
• plug Intel Pro/1000e network card into standard PCI-E slot on a board. After linux bootup, ifconfig ethx ip address andnetmask, then do ping testing.
Tips: x ethernet interface number, an example is as the following for Intel e1000 network card is eth0.
For example:
After kernel boot up, bring up with the pci Ethernet card
ifconfig ethx 192.168.20.100
ip address should not be conficted with other Ethernet port.
In Linux window, run ping 192.168.20.101
Known Bugs, Limitations, or Technical Issues
• LSI-SAS card cannot be used on the second PCIe controller when system enables more than one PCIe controller. Usecode modification below to workaround this issue:
--- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -511,7 +511,7 @@ int __init fsl_add_bridge(struct platform_device *pdev, int is_primary) printk(KERN_WARNING "Can't get bus-range for %s, assume" " bus 0\n", dev->full_name); - pci_add_flags(PCI_REASSIGN_ALL_BUS); + pci_add_flags(PCI_ENABLE_PROC_DOMAINS); hose = pcibios_alloc_controller(dev); if (!hose) return -ENOMEM; @@ -846,7 +846,7 @@ int __init mpc83xx_add_bridge(struct device_node *dev) " bus 0\n", dev->full_name); } - pci_add_flags(PCI_REASSIGN_ALL_BUS); + pci_add_flags(PCI_ENABLE_PROC_DOMAINS); hose = pcibios_alloc_controller(dev); if (!hose) return -ENOMEM;
6.4.2 EDAC Driver User Manual
Description
The EDAC kernel module's goal is to detect and report errors that occur within the computer system running under Linux.
Note
Currently the EDAC wasn't supported on P5040/P5020 64bit.
Module Loading
Linux EDAC Driver supports kernel built-in or module.
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201672 NXP Semiconductors
Kernel Configure Options
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers ---> <*> EDAC (Error Detection And Correction) reporting ---> <*> Main Memory EDAC (Error Detection And Correction) reporting <*> Freescale MPC83xx / MPC85xx
Enables EDAC supportfor 85xx platform
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_EDAC_MM_EDAC y/n y/n Enables EDAC core support
CONFIG_EDAC_MPC85XX y/n y/n Enables EDAC NXP 85xx support
Device Tree Binding
Property Type Status Description
compatible String Required Should be 'fsl,qoriq-memory-controller', 'fsl,p4080-pcie'
reg integer Required Register map
Default node:
ddr1: memory-controller@8000 { compatible = "fsl,qoriq-memory-controller-v4.4", "fsl,qoriq-memory-controller"; reg = <0x8000 0x1000>; interrupts = <16 2 1 23>;};
/* controller at 0x200000 */pci0 { compatible = "fsl,p4080-pcie"; device_type = "pci"; #size-cells = <2>; #address-cells = <3>; bus-range = <0x0 0xff>; clock-frequency = <33333333>; interrupts = <16 2 1 15>; };
Source Files
The driver source is maintained in the Linux kernel source tree.
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 73
Source File Description
drivers/edac/edac_core.c Enables EDAC core support
drivers/edac/mpc85xx_edac.c Enables EDAC NXP 85xx support
Kernel boot message:
........ ........EDAC MC: Ver: 2.1.0Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista SoftwareEDAC MC0: Giving out device to 'MPC85xx_edac' 'mpc85xx_mc_err': DEV mpc85xx_mc_errMPC85xx_edac acquired irq 16 for MCMPC85xx_edac MC err registeredEDAC MC1: Giving out device to 'MPC85xx_edac' 'mpc85xx_mc_err': DEV mpc85xx_mc_errMPC85xx_edac acquired irq 16 for MCMPC85xx_edac MC err registeredEDAC PCI0: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe200000.pcie' (INTERRUPT)MPC85xx_edac acquired irq 16 for PCI ErrMPC85xx_edac PCI err registeredEDAC PCI1: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe201000.pcie' (INTERRUPT)MPC85xx_edac acquired irq 16 for PCI ErrMPC85xx_edac PCI err registeredEDAC PCI2: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe202000.pcie' (INTERRUPT)MPC85xx_edac acquired irq 16 for PCI ErrMPC85xx_edac PCI err registeredTesting edac driver is start.PCIE error(s) detectedPCIE ERR_DR register: 0x00020000PCIE ERR_CAP_STAT register: 0x80000001PCIE ERR_CAP_R0 register: 0x00000800PCIE ERR_CAP_R1 register: 0x00000000PCIE ERR_CAP_R2 register: 0x00000000PCIE ERR_CAP_R3 register: 0x00000000 ........ ........ ........p4080 login: rootPassword: [root@p4080 root]#
Test Procedure:
[root@p4080 root]# [root@p4080 root]# cat /proc/interrupts |grep EDAC 16: 1 0 0 0 0 0 0 0 OpenPIC Level [EDAC] MC err, [EDAC] MC err, [EDAC] PCI err, [EDAC] PCI err, [EDAC] PCI err[root@p4080 root]# [root@p4080 root]#
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201674 NXP Semiconductors
Now, see that whether the total number of interrupt 16 of EDAC is zero or less than twenty. If it is that, EDAC driver is OK.
6.4.3 PCIe Advanced Error Reporting User Manual
DescriptionHow to test the PCI Express Advanced Error Reporting (AER) function.
Testing the PCIe AER error recovery code in actual environment is quite difficult because it is hard to trigger real hardwareerrors. So we use a software tool based error injection to fake various kinds of PCIe errors.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Bus options ---> [*] PCI Express support [*] Root Port Advanced Error Reporting support <*> PCIe AER error injector support
enable PCI-Express AER and AER-INJECTOR inkernel
Kernel compile-time Configuration Options
Option Values Default Value Description
CONFIG_PCIEAER y/n y Enable AER
CONFIG_PCIEAER_INJECT y/n n Enables AER INJECT
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/pci/pcie/aer/*.c AER driver support
• Prepare aer-inject test tool
1, Download aer-inject test utility.
2, Write a test config filee.g. $ vi aer-cfg AER DOMAIN 0001 BUS 1 DEV 0 FN 0 COR_STATUS BAD_TLP HEADER_LOG 0 1 2 3 NOTE:error type can be ["COR_STATUS", "UNCOR_STATUS"]
Corrected error can be:["BAD_TLP", "RCVR", "BAD_DLLP", "REP_ROLL", "REP_TIMER"]
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 75
Uncorrected non-fatal error can be:["POISON_TLP", "COMP_TIME", "COMP_ABORT", "UNX_COMP", "ECRC", "UNSUP"]
Uncorrected fatal error can be: ["TRAIN", "DLP", "FCP", "RX_OVER", "MALF_TLP"]
• Test Steps
1, insert a pcie device in PCI slot of board, ensure the pcie device has AER capability, e.g. e1000e PCIe NIC network card.
2, In u-boot prompt, add "pcie_ports=native" in bootargs command-line.=> setenv othbootargs pcie_ports=native
3, boot the kernel and filesystem.=> tftp 1000000 uImage;tftp 2000000 board.dtb; tftp 3000000 rootfs.ext2.gz.uboot; bootm 1000000 3000000 2000000 4, check AER device and config# zcat /proc/config.gz|grep -i CONFIG_PCIEAER_INJECTCONFIG_PCIEAER_INJECT=y
# cat /proc/cmdlineroot=/dev/ram rw console=ttyS0,115200 pcie_ports=nativecheck "pcie_ports=native" has been set.
# ls /dev/aer_inject Check if the aer injector device is created.
# lspci00:00.0 Class 0604: 1957:041001:00.0 Class 0200: 8086:10d3e.g. here device "01:00.0" is the PCIe NIC e1000 network card in the test scenario.
5, Download aer-inject and aer-cfg from host to test-board$ scp aer-inject aer-cfg root@test-board-ip:~
6, ensure the pcie device domain-number/bus-number/device-number/function-number in aer-cfg is accordant to those in the output of lspci
7, Run aer-inject, corresponding error information will be reported as below and AER will recover PCIE device according to the type of errors.# ./aer-inject aer-cfgexample of error report as below: pcieport 0000:00:00.0: AER: Corrected error received: id=0100e1000e 0000:01:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0100(Receiver ID)e1000e 0000:01:00.0: device [8086:10d3] error status/mask=00000040/00002000e1000e 0000:01:00.0: [ 6] Bad TLP root@p1010rdb:~#
8, The pcie device(e1000e PCIE NIC) should still work after AER error recovery. # ping 192.168.1.1 -c 2 -s 64PING 192.168.1.1 (192.168.1.1): 64 data bytes72 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.272 ms72 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.210 ms--- 192.168.1.1 ping statistics ---2 packets transmitted, 2 packets received, 0% packet loss
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201676 NXP Semiconductors
round-trip min/avg/max/stddev = 0.210/0.241/0.272/0.031 ms
Note:
On some legacy platforms with legacy PCI conroller(e.g. some non-DPAA platforms), hardware doesn't support Fatal errortype for AER, just support Non-Fatal error.
Generally, DPAA platforms with new PCIE controller can support both Fatal error and Non-Fatal error.
6.4.4 PCI-e Remove and Rescan User Manual
DescriptionDescribes how to remove and rescan a PCI-e device under runtime Linux system.
U-boot ConfigurationUse the default configurations.
Kernel Configure OptionsUse the default configurations, make sure the configure option is set while doing "make menuconfig" for kernel.
Kernel Configure Tree View Options Description
Device Drivers --->[*] Network device support--->[*] Ethernet (1000 Mbit) --->[*] Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support
This option enables kernel support for Intel PCI-e e1000enetwork card
Below are the configure identifiers which are used in kernel source code and default configuration files.
Option Values Default Value Description
CONFIG_E1000E y/n y Intel PCI-e e1000e network card driver
Device Tree Binding
Use the default dtb file.
Verification in Linux
Make sure the PCI-e controller which you add the PCI-e e1000e network card to works as RC mode. Use the kernel, dtb andramdisk rootfs to boot the board.
1. Suppose the PCI-e device under /sys/bus/pci/devices/0001\:03\:00.0 is the Intel PCI-e e1000e network card, recognized as eth0. The/sys/bus/pci/devices/0001\:02\:00.0 is the bus of network card. Configure an ip and ping another host which is in the same subnet, make sure the network card works well.
# ls /sys/bus/pci/devices/0001\:03\:00.0/net eth0 # ifconfig eth0 10.193.20.100 # ping -I eth0 10.193.20.31
2. Remove the PCI-e network card from system.
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 77
# echo 1 > /sys/bus/pci/devices/0001\:03\:00.0/remove e1000e 0001:03:00.0 eth0: removed PHC
3. Check whether the PCI-e network card still exist in system. All should fail. # ifconfig eth0 # ls /sys/bus/pci/devices/0001\:03\:00.0
4. Rescan it from the bus. # echo 1 > /sys/bus/pci/devices/0001\:02\:00.0/rescan
5. Check whether the device is rescanned and works well. # ls /sys/bus/pci/devices/0001\:03\:00.0 # ifconfig eth0 10.193.20.100 # ping -I eth0 10.193.20.31
6. All the commands of step 5 should success.
Known Bugs, Limitations, or Technical Issues
The support of PCI-e device remove rescan on powerpc platform is first added in NXP LInux SDK 1.4(kernel version: 3.8.4).If it fail, the PCI-e device will be rescaned, but the driver of the device will fail to loaded.
6.4.5 PCIE EP
Description
SKMM (Secure Key Management Module) is Linux user space implementation for accelerating the encryption/decryptionoperations on the NXP processors with SEC engine. SKMM consists of two parts of software, the host kernel driver and theapplication on EP side. The host driver interfaces with OpenSSL or sysfs to pass the encryption/decryption operations to EPside by abstract request and the EP application parses the abstract request to do the encryption/decryption operations, passthe results to host side. The key point here is the private key used is only kept in EP side and is invisible to host side. Alsothe private key(s) is stored in NOR flash using blob mechanism for protecting the key across system power cycles.
SKMM has two sub use cases:
• - SKMM with PCIe data path. (For now, only SKMM with PCIe data path is supported.)
For SKMM with PCIe data path, the two boards are connected through the PCIe interface, the requests are sent to EPthrough PCIe interface.
• - SKMM with Ethernet data path.
Requests are sent to the EP through the Ethernet port.
Platforms Supported
• P4080DS
• T4240QDS
Compiling SKMM code
Refer to SDK Documentation provided with this release for installing and using Yocto for Image compilation and building.
How to configure and build Host images for PowerPC
1. Change directory to Yocto, execute commands to configure kernel
> source ./poky/fsl-setup-poky -m <board-type> -j 12 -t 12
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201678 NXP Semiconductors
#> bitbake -c menuconfig linux-qoriq-sdk
To P4080DS and T4240QDS: Location: -> Device Drivers -> DMA Engine support ->[*] NXP Elo and Elo Plus DMA support (enable the option) [ ] Network: TCP receive copy offload (disable the option)
2. Execute Commands to build uImage with DMA enabled
#> bitbake linux-qoriq-sdk
3. Execute Command to generate RFS with kernel modules for host and SKMM application for EP
#> bitbake fsl-image-core
How to configure and build Host images for X86:
When using X86 as Host of SKMM, need a Linux distribution to be installed to X86 PC, suggested
using Ubuntu 12.04 64bit.
NOTE
1. Change directory to Yocto, then extract the SKMM Host source code as following:
#> source ./poky/fsl-setup-poky -m <board-type> -j 12 -t 12#> bitbake -c patch skmmhost
2. The source code will be in tmp/work/<board -type>-fsl_networking-linux/skmmhost/git-r0/git/. Copy thesource directory to your X86 Host machine for building.
3. Change the directory to the top of the SKMM Host’s source code, execute the command:
#> make ARCH=x86_64 KERNEL_DIR=/lib/modules/$(uname -r)/build
4. The driver modules will be built in the current directory, named “fsl_crypto.ko” and “rsa_test.ko”.
How to configure and build EP kernel:
1. Change the directory to Yocto, then execute commands to configure the kernel:
#> source ./poky/fsl-setup-poky -m <board-type> -j 12 -t 12#> bitbake -c menuconfig linux-qoriq-sdk
• For P4080ds: Location:
-> Cryptographic API ->[*] Hardware crypto devices -> < > NXP CAAM-Multicore driver backend (disable the option) -> Device Drivers -> <*> Userspace I/O drivers -> <*> NXP SEC support(disable the option)
• For T4240qds: Location:
-> Cryptographic API
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 79
->[*] Hardware crypto devices -> < > NXP CAAM-Multicore driver backend (disable the option) -> Device Drivers -> <*> Userspace I/O drivers -> <*> NXP SEC support(disable the option) -> <*> VFIO Non-Privileged userspace driver framework(enable the option) -> <*> VFIO support for Fresscale PCI Endpoint devices(enable the option)
2. Execute command to build the kernel image
#> bitbake linux-qoriq-sdk
3. Execute command to generate RFS with SKMM application for EP
#> bitbake fsl-image-core
Configure physical connection
EP
• For P4080ds, route the PCIe cable between slot #1 and the Host.
• For T4240qds, route the PCIe cable between slot #5 and the Host.
Host
• For P4080ds, route the PCIe cable between slot #3 and the EP
• For X86, route the PCIe cable between X86 PCIe slot with the x4 to x1 connector, and the EP
• For T4240qds, route the PCIe cable between slot #7 and the EP
How to operate EP
Store all the images for PowerPC machine on the tftp server. Configure the board IP and tftp server IP on the u-bootenvironment using following commands, the third step is to reserve memory for SKMM, it couldn’t be ignored.
For P4080ds as EP
1.
#> setenv ipaddr <board ip >#> setenv serverip <tftp server ip >#> setenv bootargs “$bootargs usdpaa_mem=256m”#> save
2. Program RCW with R_PPPNN_0x5/rcw_ep_1500mhz.bin to flash.
3. Execute following command at u-boot prompt to boot the board
#> tftp 1000000 uImage-<bsp>.bin#> tftp 2000000 fsl-image-core-<bsp>.ext2.gz.uboot#> tftp c00000 uImage-<bsp>.dtb#> bootm 1000000 2000000 c00000
4. Once the Linux Image boots, enter username=root and password=root to logon.
5. If the SKMM application is being run for the first time, update private key into Nor flash MTD4.
root@p4080:flash_eraseall /dev/mtd4root@p4080:skmm_$(host) /dev/mtd4 update-key ~/.skmm/RSA_priv3
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201680 NXP Semiconductors
skmm_$(host) is the application for different Host. For x86 its name is "skmm_x86_64", for
PowerPC its is "skmm_powerpc", please check the application used is correct to Host.
NOTE
6. Run SKMM application, then EP will wait for request offloaded
root@p4080:skmm_$(host) /dev/mtd4
For T4240qds as EP
1.
#> setenv ipaddr <board ip >#> setenv serverip <tftp server ip >#> setenv bootargs “$bootargs usdpaa_mem=256m”#> save
2. Program RCW with “RR_XXSSPRPH_1_28_6_12/rcw_1_28_6_12_pexep_1666MHz.bin”
#> tftp 1000000 uImage-<bsp>.bin#> tftp 2000000 fsl-image-core-<bsp>.ext2.gz.uboot#> tftp c00000 uImage-<bsp>.dtb#> fdt addr $fdtaddr;fdt mknod /localbus/nor partition@7000000;#> fdt set /localbus/nor/partition@7000000 reg <0x07000000 0x00100000>;#> fdt set /localbus/nor/partition@7000000 label "blob";#> bootm $loadaddr - $fdtaddr;
3. Once the Linux Image boots, enter username=root and password=root to logon.
4. If the SKMM application is being run for the first time, update private key into Nor flash MTD0
root@t4240:flash_eraseall /dev/mtd0root@t4240:skmm_$(host) /dev/mtd0 update-key ~/.skmm/RSA_priv3
skmm_$(host) is the application for different Host. For x86 its name is "skmm_x86_64", for
PowerPC its is "skmm_powerpc", please check the application used is correct to Host.
NOTE
5. Run SKMM application, then EP will wait for request offloaded
root@t4240:skmm_$(host) /dev/mtd0
How to operate Host
1. boot up PowerPC Host:
2. Configure the board IP and tftp server IP on the u-boot environment using following commands:
#> setenv ipaddr <board ip >#> setenv serverip <tftp server ip >#> save
3. Execute following command at u-boot prompt to boot the board
#> tftp 1000000 uImage-<bsp>.bin#> tftp 2000000 fsl-image-core-<bsp>.ext2.gz.uboot
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 81
#> tftp c00000 uImage-<bsp>.dtb#> bootm 1000000 2000000 c00000
4. Once the Linux Image boots, enter username=root and password=root to logon.
5. Insmod the module to start the test process
Root #>:insmod /lib/modules/$(uname -r)/extra/fsl_crypto.ko dev_config_file=/etc/skmm/skmm_crypto.cfg
6. boot up X86 Host
7. There is no specific setup for X86, change directory to c293_skmm_host copied from Yocto, and make sure themodules has been generated.
8. Insert the module to start the test process
• For PowerPC Host:
Root #>:insmod /lib/modules/$(uname -r)/extra/fsl_crypto.ko dev_config_file=/etc/skmm/skmm_crypto.cfg
• For X86 Host:
root #>:insmod fsl_crypto.ko dev_config_file=crypto.cfg
How to test
When you complete one of RSA public key test or private key test, you have to reboot both HOST and EP, and reload thefsl_crypto.ko module above, then move on another function test step.
For PowerPC as Host RSA public key: Root #>:insmod /lib/modules/$(uname -r)/extra/rsa_test.ko op=rsa_pub RSA private key: Root #>:insmod /lib/modules/$(uname -r)/extra/rsa_test.ko op=rsa_priv3
For x86 as Host RSA_public key: root #>:insmod rsa_test.ko op=rsa_pub RSA private key: root #>:insmod rsa_test.ko op=rsa_priv3
Because PowerPC haven't supported PCIe hotplug yet, removing fsl_crypto.ko module will cause a Host kernel call trace
Funtion test result
If there was nothing “ERROR” log printed, it means test result was correct, but if the console prints the words like “!!!!! Notmatching byte got [xx] original [%0x] at index [xx]”(note: xx is a number of 0 to127 ), it means test failed.
Performance test
RSA pubilc key:Root #>:echo "RSA_PUB_OP_1K" >/sys/fsl_crypto/fsl_crypto_1/test-i/test_nameRSA private key: Root #>:echo "RSA_PRV_OP_1K" >/sys/fsl_crypto/fsl_crypto_1/test-i/test_name
After console prints the start time and end time, it means the test process is finished, then please use the formula bellow tocalculate the performance ops/s (The number of crypto operations in a second):
Ops/s = Host cpu Frequency / ((end time – start time) / 5000)
Linux Kernel Drivers
PCI Express Interface Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201682 NXP Semiconductors
For example, to P4080ds, Cpu Frequency is 1.5GHz(1.5 x 109). 5000 is the number of crypto operations (it is the defaultsetting for performance test), it has been hard code, so it couldn’t be modified.
6.5 Packet Forward Engine (PFE) Network Driver
6.5.1 Introduction
6.5.1.1 OverviewThis section describes the Linux driver which enables support for Ethernet on Packet Forward Engine (PFE) hardware.EMACs are part of PFE IP, to receive/transmit packets through EMAC interface it should be accessed through PFE interfaceby programing it.
6.5.1.2 PurposeThe purpose of this section is to provide a user guide and configuration details for the PFE driver, and a high-level view ofthe driver’s structure, as well as to describe its major functionalities with a focus on the features provided by the PFE IP.
6.5.1.3 FeaturesThis section provides an overview of the major PFE features:
• MAC Layer.
• MAC Address Filter.
• Interrupt for Tx/Rx packets.
• Scatter/Gather support.
• Interrupt coalescing.
• TCP/UDP checksum verification and generation.
6.5.2 High level decomposition and data flowA system level block view, from a network device perspective, may be depicted as follows:
Linux Kernel Drivers
Packet Forward Engine (PFE) Network Driver
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 83
HIF/Ethernet client driver
Eth1
HIF driver layer
PFE
Eth0
Linux network stack
H
PHY PHY
MAC MACHW
Kernel
Network protocol handler/ioctl interface
User application
ethtool package
iproute2 package
Figure 1. High level decomposition and data flow block level view
The PFE, MAC and PHY are the hardware blocks, the kernel networking stack along with the network driver are running inthe Kernel space, and finally ethtool and iproute2 are examples of user space tools used for configuring the network devices.
The PFE hardware supports one HIF RX and TX descriptor queues to send and receive packets through PFE. Both networkinterface traffic is multiplexed and send over HIF queue.
User space packages like ethtool and iproute are used to configure the network device parameters. The ethtool interface isextended to provide support for filer programming. The kernel space module for the network driver is the most importantblock as it communicates with both the user space and the H/W IP to control the processing of packets.
The basic functionality of any Ethernet driver is to handle the reception of packets from an ingress port (might includechecksum calculation, header verification, etc), as well as the transmission of packets on the egress port (might includechecksum re-calculation, header manipulation, etc). There are also the device configuration and control functionalities, anddevice status reporting. When the Ethernet driver is actually implementing these functionalities, it needs to interact with thecore (Kernel) as well as the hardware IP (the Ethernet controller).
The PFE Linux kernel module has following two main parts:
• HIF driver layer:This part of the driver talks with HIF hardware interface and send and receive the packets from it. Itreceives packets from HIF interface and identifies from which MAC interface it received and send the packet tocorresponding client driver queue. Similarly, if there is any pending packet from client queue to transmit packet it takes andinserts the HIF header and put it into the HIF queue. It uses the NAPI to receive packets and send it to corresponding clientqueues and triggers client to process packets from the queue.
• HIF/Ethernet client driver: Ethernet client driver is a hardware independent driver and registers with the HIF driver totransmit and receive packet through HIF interface. For each interface one instance of client driver should be register withthe HIF driver layer, other side it registers with Linux kernel stack as network interface. Each client driver will have softwarequeues to communicate with HIF driver layer. Each client driver registers with NAPI and indicate packets to the stackthrough the NAPI poll.
Linux Kernel Drivers
Packet Forward Engine (PFE) Network Driver
QorIQ LS1012A BSP v0.5, Rev. 0, December 201684 NXP Semiconductors
6.5.3 NAPI supportPFE HIF driver layer uses NAPI handling for Rx path processing, the Linux polling mechanism being triggered by framereceive interrupts. The driver registers irqs for receive and the NAPI (polling) handlers are provided to the Kernel. Similarly,HIF Ethernet client driver also uses NAPI handling to processes software queues and pass them to the Kernel Network stack.
On the receive path:
• When the receive interrupt gets triggered, a softirq for the polling function on Rx is scheduled.
• The RX_SOFTIRQ thread is raised by the Kernel, and the HIF Rx queues will be processed by the driver's polling functionand the incoming packets are being passed to client Rx queues and triggers the client NAPI handling.
• HIF/Ethernet client NAPI poll receives packets from client Rx queues and passes to the Network stack.
6.5.4 Interrupt coalescingOn a high speed network interface the rate of packet reception and transmission can be as high as the CPUs would bespending most of the time servicing these interrupts. With the interrupt coalescing feature, packets are collected and onesingle interrupt is generated for multiple packets to avoid flooding the system with interrupts from the Ethernet device.
PFE hardware supports hardware coalescing for receive interrupts, complemented by timer-based thresholds. PFE driverprovides basic support for setting the coalescing parameters via ethtool -C by implementing the “rx-usec” option.
6.5.5 Checksum offloadingFor large frames, offload of checksum verification saves a significant fraction of the CPU cycles that would otherwise be spentby the TCP/IP stack. IP packet fragmentation and re-assembly, and TCP stream establishment and tear-down are notperformed in hardware.
On Tx side, PFE hardware provides IPv4/IPv6 and TCP/UDP header checksum generation. On the Rx side, PFE driver letsthe Kernel know that checksum verification is not required if valid IP headers or TCP/UDP headers were found and validsums were verified, by setting the CHECKSUM_UNNECESSARY flag. On Tx side, the checksum is generated (offloaded)for TCP/UDP packets over IPv4 based on the pseudo-header checksum (phcs) provided by the Linux networking stack. PFELinux driver instructs the stack about its ability to provide partial checksumming, based on the phcs for TCP/UDP packets,by setting the NETIF_F_IP_CSUM device capability flag. PFE hardware doesn’t support per packet based checksumcalculation control, it should be enabled or disabled for all packets.
6.5.6 Scatter gather supportScatter-Gather I/O is a method by which a single procedure call sequentially writes data from multiple buffers to a single datastream or reads data from a data stream to multiple buffers. The buffers are given in a vector of buffers. Scatter/gather refersto the process of gathering data from, or scattering data into, the given set of buffers. The I/O can be performed synchronouslyor asynchronously to this procedure.
On the Tx side, PFE HIF interface supports "gathering" big packets from multiple buffers. This ability is signaled by the driverto the Linux network stack by setting the NETIF_F_SG device hardware feature flag. The driver takes into account the numberof fragments composing the packet that is going to be transmitted, and places each fragment into consecutive BD ring buffersbefore issuing the command to start sending the frame.
On the Rx side, the PFE HIF interface is capable of "scattering" big packets into multiple fixed size buffers having consecutivebuffer descriptors (BDs).
6.5.7 Ethtool supportNon-exhaustive list of the most notable ethtool commands implemented by PFE Linux driver:
Linux Kernel Drivers
Packet Forward Engine (PFE) Network Driver
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 85
• Commands • Description
• ethtool -C • rx-usecs N • Set Rx interrupt coalescing inmicrosecs(‘usecs’).
• ethtool -K • rx on|off
• tx on|off
• Set UDP/TCP checksum offloadingenabled or disabled.
• ethtool -S • • Show interface statistics, Linuxspecific counters and various MAC H/W counters.
6.6 Real Time Clock (off-chip)
6.6.1 RTC Driver User Manual (Linux BSP)
Linux SDK for QorIQ Processors
DescriptionProvides the RTC function.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers-> Real Time Clock--> [*] Set system time from RTC on startup and resume (new) (rtc0) RTC used to set the system time (new) <[*] /sys/class/rtc/rtcN (sysfs) <[*] /proc/driver/rtc (procfs for rtc0) <[*] /dev/rtcN (character devices)
Enable RTC driver
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_RTC_LIB y/m/n y Enable RTC lib
CONFIG_RTC_CLASS y/m/n y Enable generic RTC class support
CONFIG_RTC_HCTOSYS y/n y Set the system time from RTC when startup and resume
CONFIG_RTC_HCTOSYS_DEVICE "rtc0" RTC used to set the system time
CONFIG_RTC_INTF_SYSFS y/m/n y Enable RTC to use sysfs
CONFIG_RTC_INTF_PROC y/m/n y Use RTC through the proc interface
Table continues on the next page...
Linux Kernel Drivers
Real Time Clock (off-chip)
QorIQ LS1012A BSP v0.5, Rev. 0, December 201686 NXP Semiconductors
Table continued from the previous page...
Option Values Default Value Description
CONFIG_RTC_INTF_DEV y/m/n y Enable RTC to use /dev interface
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/rtc/ Linux RTC driver
Device Tree Binding
Preferred node name: rtc
Property Type Status Description
compatible string Required Should be "dallas,ds3232"
Default node:
i2c@3000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl-i2c"; reg = <0x3000 0x100>; interrupts = <43 2>; interrupt-parent = <&mpic>; dfsrr; rtc@68 { compatible = "dallas,ds3232"; reg = <0x68>; }; };
Verification in Linux
Here is the rtc booting log
... rtc-ds3232 1-0068: rtc core: registered ds3232 as rtc0 MC object device driver dpaa2_rtc registered rtc-ds3232 0-0068: setting system clock to 2000-01-01 00:00:51 UTC (946684851) ... NOTE: Please refer to the related DTS file to enable the RTC driver before building. For example, LS2080AQDS board, should enable the below option: <*> Dallas/Maxim DS3232
Linux Kernel Drivers
Real Time Clock (off-chip)
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 87
Change the RTC time in Linux Kernel
~ # ls /dev/rtc -l lrwxrwxrwx 1 root root 4 Jan 11 17:55 /dev/rtc -> rtc0 ~ # date Sat Jan 1 00:01:38 UTC 2000 ~ # hwclock Sat Jan 1 00:01:41 2000 0.000000 seconds ~ # date 011115502011 Tue Jan 11 15:50:00 UTC 2011 ~ # hwclock -w ~ # hwclock Tue Jan 11 15:50:36 2011 0.000000 seconds ~ # date 011115502010 Mon Jan 11 15:50:00 UTC 2010 ~ # hwclock -s ~ # date Tue Jan 11 15:50:49 UTC 2011 ~ # NOTE: Before using the rtc driver, make sure the /dev/rtc node in your file system is correct. Otherwise, you need to make correct node for /dev/rtc
6.7 SATA Controller
6.7.1 NXP Native SATA Driver User Manual
DescriptionThe driver supports NXP native SATA controller.
Module Loading
SATA driver supports either kernel built-in or module.
Kernel Configure Tree View Options Description
Device Drivers---> <*> Serial ATA and Parallel ATA drivers --->--- Serial ATA and Parallel ATA drivers<*> AHCI SATA support<*> Freescale QorIQ AHCI SATA support
Enables SATA controllersupport on ARM-based SoCs
Linux Kernel Drivers
SATA Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 201688 NXP Semiconductors
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_SATA_AHCI=y y/m/n y Enables SATA controller
CONFIG_SATA_AHCI_QORIQ=y y/m/n y Enables SATA controller
Source FilesThe driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/ata/ahci_qoriq.c Platform AHCI SATA support
Test Procedure
Please follow the following steps to use USB in Simics(1) Boot up the kernel...fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver initscsi0 : sata_fslata1: SATA max UDMA/133 irq 74fsl-sata ffe19000.sata: Sata FSL Platform/CSB Driver initscsi1 : sata_fslata2: SATA max UDMA/133 irq 41...(2) The disk will be found by kernel....ata1: Signature Update detected @ 504 msecsata2: No Device OR PHYRDY change,Hstatus = 0xa0000000ata2: SATA link down (SStatus 0 SControl 300)ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)ata1.00: ATA-8: WDC WD1600AAJS-22WAA0, 58.01D58, max UDMA/133ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 16/32)ata1.00: configured for UDMA/133scsi 0:0:0:0: Direct-Access ATA WDC WD1600AAJS-2 58.0 PQ: 0 ANSI: 5sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)sd 0:0:0:0: Attached scsi generic sg0 type 0sd 0:0:0:0: [sda] Write Protect is offsd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 >sd 0:0:0:0: [sda] Attached SCSI disk
(3)play with the disk according to the following log.[root@ls2088 root]# fdisk -l /dev/sda Disk /dev/sda: 160.0 GB, 160041885696 bytes255 heads, 63 sectors/track, 19457 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System/dev/sda1 1 237 1903671 83 Linux/dev/sda2 238 480 1951897+ 82 Linux swap/dev/sda3 481 9852 75280590 83 Linux/dev/sda4 9853 19457 77152162+ f Win95 Ext'd (LBA)
Linux Kernel Drivers
SATA Controller
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 89
/dev/sda5 9853 14655 38580066 83 Linux/dev/sda6 14656 19457 38572033+ 83 Linux[root@ls1088 root]# [root@ls1088 root]# mke2fs /dev/sda1mke2fs 1.41.4 (27-Jan-2009)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)65280 inodes, 261048 blocks13052 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=2684354568 block groups32768 blocks per group, 32768 fragments per group8160 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376
Writing inode tables: done Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 22 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.[root@ls2088 root]# [root@ls2088 root]# mkdir sata[root@ls2088 root]# mount /dev/sda1 sata[root@ls2088 root]# ls sata/lost+found[root@ls2088 root]# cp /bin/busybox sata/[root@ls2088 root]# umount sata/[root@ls2088 root]# mount /dev/sda1 sata/[root@ls2088 root]# ls sata/busybox lost+found[root@ls2088 root]# umount sata/[root@ls2088 root]# mount /dev/sda3 /mnt[root@ls2088 root]# dfFilesystem 1K-blocks Used Available Use% Mounted onrootfs 852019676 794801552 13937948 99% //dev/root 852019676 794801552 13937948 99% /tmpfs 1036480 52 1036428 1% /devshm 1036480 0 1036480 0% /dev/shm/dev/sda3 74098076 4033092 66300956 6% /mnt
Known Bugs, Limitations, or Technical Issues
• CDROM is not supported due to the silicon limitation
6.8 Serial Peripheral Interface
6.8.1 DSPI Device Driver User Manual
Linux Kernel Drivers
Serial Peripheral Interface
QorIQ LS1012A BSP v0.5, Rev. 0, December 201690 NXP Semiconductors
6.8.1.1 DSPI Device Driver User ManualLS1021-QDS board - U-Boot Configuration
Use QSPI boot mode to boot LS1021A-QDS board.
SW1[1:8]+SW2[1]=0100_0101+0SW6[1:4]=0b'1111
QDS X-nor card hardware configuration
SW1[1:4]=1000SW4[1:4]=1111SW3[1:4]=0001
J3: short 1-2, J4: short 1-2. This configuration can make DSPI device and QSPI device work at same time in X-nor card.
Kernel Configure Tree View Options
Device Drivers ---> [*] SPI support ---> <*> Freescale DSPI controller
Device Drivers ---> <*> Memory Technology Device (MTD) support ---> Self-contained MTD device drivers ---> <*> Support for AT45xxx DataFlash
Compile-time Configuration Options
Config Values Default Value Description
CONFIG_SPI_FSL_DSPI y/n yEnable DSPI module
CONFIG_MTD_DATAFLASH y/n yEnables MTD devices for DSPI flash
Verification in U-Boot LS1021a-qds
Verification in U-Boot:
=> sf probe 1:0SF: Detected AT45DB021D with page size 256 Bytes, erase size 2 KiB, total 256 KiB => sf erase 0 10000SF: 65536 bytes @ 0x0 Erased: OK => sf write 82000000 0 1000SF: 4096 bytes @ 0x0 Written: OK=> sf read 81100000 0 1000SF: 4096 bytes @ 0x0 Read: OK
Linux Kernel Drivers
Serial Peripheral Interface
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 91
=> cm.b 81100000 82000000 1000Total of 4096 byte(s) were the same
Verification in Linux:
The booting log
......mtd_dataflash spi0.0: at45db021d (256 KBytes) pagesize 256 bytes (OTP)6Freescale DSPI master initialized......
Erase the DSPI flash
~ # mtd_debug erase /dev/mtd0 0x1100000 65536Erased 65536 bytes from address 0x00000000 in flash
Write the DSPI flash
~ # dd if=/bin/tempfile.debianutils of=tp bs=4096 count=1 ~ # mtd_debug write /dev/mtd0 0 4096 tpCopied 4096 bytes from tp to address 0x00000000 in flash
Read the DSPI flash
~ # mtd_debug read /dev/mtd0 0 4096 dump_file
Copied 4096 bytes from address 0x00000000 in flash to dump_file
Check Read and Write
Use compare tools(yacto has tools named diff).~ # diff tp dump_file~ #If diff command has no print, the DSPI verification is passed.
6.9 Universal Serial Bus Interfaces
6.9.1 USB 2.0 Host Driver
6.9.1.1 USB 2.0 Host Driver User Manual
DescriptionThe driver supports USB controller in host mode
Module LoadingThe USB Host driver in linux supports either kernel built-in or module driver. U-boot USB driver is always built-in
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 201692 NXP Semiconductors
U-Boot Compile Time Configuration Options
U-Boot Configure Options Description
#define CONFIG_HAS_FSL_DR_USB
#ifdef CONFIG_HAS_FSL_DR_USB#define CONFIG_USB_EHCI
#ifdef CONFIG_USB_EHCI#define CONFIG_CMD_USB#define CONFIG_USB_STORAGE#define CONFIG_USB_EHCI_FSL#define CONFIG_EHCI_HCD_INIT_AFTER_RESET#define CONFIG_CMD_EXT2
Enables USB host Dual Role controller support. Defined insideplatform config file: include/configs/<platform.h>.
CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
Enable internal UTMI Phy support. Required only for SoCs havinginternal UTMI PHY. Defined inside file: arch/powerpc/include/asm/config_mpc85xx.h
CONFIG_USB_MAX_CONTROLLER_COUNT
Tell maximum no. of USB controllers in this SoC. Defined insidefile: arch/powerpc/include/asm/config_mpc85xx.h
U-Boot Source Files
The driver source is maintained in the U-boot source in following files
Source File Description
drivers/usb/host/ehci-fsl.c EHCI FSL USB host controller driver
common/cmd_usb.c Common usb command file
drivers/usb/host/ehci-hcd.c EHCI USB host controller driver
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers--->
USB support --->
[*] Support for Host-side USB
Enables USB hostcontroller support
Device Drivers--->
USB support --->
Enables EHCI HostController Driver andtransaction translator.
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 93
Table continued from the previous page...
Kernel Configure Tree View Options Description
<*> EHCI HCD (USB 2.0) support
-*- Root Hub Transaction Translators
[ ] Improved Transaction Translator scheduling (EXPERIMENTAL)
[*] Support for Freescale on-chip EHCI USB controller
[*] EHCI support for PPC USB controller on OF platform bus
<*> OHCI HCD support
[*] OHCI support for PPC USB controller on OF platform bus
[*] Support big endian HC
[*] Support little endian HC
[*] OHCI support for PCI-bus USB controllers
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_USB y/m/n y Enables USB host controller
CONFIG_USB_EHCI_HCD y/m/n y Enables EHCI HCD
CONFIG_USB_EHCI_ROOT_HUB_TT y/n y Enables EHCI to support USB1.1 device
CONFIG_USB_OHCI_HCD y/m/n y Enables OHCI HCD
Kernel Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/usb/host/ehci-fsl.c EHCI USB host controller driver
arch/powerpc/sysdev/fsl_soc.c Hook between OF tree and platform device
drivers/usb/host/ohci_hcd.c OHCI USB host controller driver
Device Tree Binding
usb@22000 {
#address-cells = <1>;
#size-cells = <0>;
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 201694 NXP Semiconductors
compatible = "fsl-usb2-<controller-type>-v<controller version>",
"fsl-usb2-<controller-type>";
reg = <0x22000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <28 0x2>;
phy_type = "ulpi"; /* ulpi/utmi/utmi_dual */
dr_mode = "host" /* host, peripheral */
};
controller-type: dr(dual-role), mph(multi-port-host) controller-version: 1.6, 2.2, or earlier default
mode is always host
NOTE
Verification in U-Boot
U-boot environment to specify usb phy and usb mode type
=> setenv hwconfig 'usb<controller-no>:dr_mode=<mode>,phy_type=<phy_type>;<next usb controller>'
For example:For socs having single usb controller and ULPI phy=> setenv hwconfig 'usb1:dr_mode=host,phy_type=ulpi'
For socs having single usb controller and UTMI phy=> setenv hwconfig 'usb1:dr_mode=host,phy_type=utmi'
For socs having two usb controllers and ULPI phys only=> setenv hwconfig 'usb1:dr_mode=host,phy_type=ulpi;usb2:dr_mode=host,phy_type=ulpi'
Then use usb start to start the usb device
=> usb start
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
=> usb dev
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 95
USB device 0: Vendor: SanDisk Rev: 8.02 Prod: Cruzer Colors+
Type: Removable Hard Disk
Capacity: 7663.9 MB = 7.4 GB (15695871 x 512)
=> usb tree
Device Tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | |+-2 Mass Storage (480 Mb/s, 500mA) JetFlash Mass Storage Device 63ZOA56O8TZFZ0AC => usb info1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 2048 Interval 255ms
2: Mass Storage, USB Revision 2.0 - JetFlash Mass Storage Device 63ZOA56O8TZFZ0AC - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x8564 Product 0x1000 Version 17.0 Configuration: 1 - Interfaces: 1 Bus Powered 500mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512
=> md 200000002000000: 02992004 02060002 08462cc0 84990329 .. ......F,....)02000010: 00c48e24 82181008 06501810 01a80004 ...$.....P......02000020: 083d3881 00808270 40a00000 b012a502 [email protected]: d4000088 28840b45 80028200 40244400 ....(..E....@$D.02000040: 022b1004 04842482 20610b81 0494d020 .+....$. a..... 02000050: 8012b628 08200100 010c6300 0411b880 ...(. ....c.....02000060: 42400200 8004a4c8 29802818 904000c0 B@......).([email protected]: 08210200 2040a8c0 448aae00 a0000000 .!.. @..D.......02000080: 2800c800 04b62080 60199885 02a62324 (..... .`.....#$02000090: 04870a08 a0008000 18020003 0281a232 ...............2020000a0: 50414020 4000850b 02044c00 10013018 PA@ @.....L...0.020000b0: 00208810 000c2280 081805a8 88800010 . ....".........020000c0: 000c020a 0012b024 01282c02 00808181 .......$.(,.....020000d0: 00010824 0160b602 81621008 00828082 ...$.`...b......020000e0: 38d0f028 42010e03 1d242290 02000120 8..(B....$".... 020000f0: 6c217230 00920800 20200d40 41c08011 l!r0.... .@A...
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 201696 NXP Semiconductors
=> mw 2000000 ffffaaaa 100=> md 200000002000000: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000010: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000020: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000030: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000040: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000050: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000060: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000070: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000080: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................02000090: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000a0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000b0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000c0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000d0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000e0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................020000f0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................=> usb write 2000000 0 100
USB write: device 0 block # 0, count 256 ... 256 blocks write: OK=> md 100000001000000: fbf3eae6 2feeffbf dbf7775d ff5bebf7 ..../.....w].[..01000010: abefefaf 7dbb3e3b bfffb5bb bfb86a7f ....}.>;......j.01000020: eff7b68f deaadfff eebf7bff bd7fed1f ..........{.....01000030: ffef7deb e7bfbbef dfeff7df 7f3ffcba ..}..........?..01000040: ab3bfbfe dfdee69b ffe18fd5 ff3e777f .;...........>w.01000050: da7effef bfabff7f f58ef768 9ffffeff .~.........h....01000060: cfebf8b0 f1b7dfef e9eefbfe f37bbadb .............{..01000070: b7f34ea2 da7efbff dfdff7ff f7effde3 ..N..~..........01000080: fffbebff fe56ff5d 6ffd7ffd ff87efdf .....V.]o.......01000090: b6bfafac ddebfbfb ffacebfd f87bff9f .............{..010000a0: ffebffff ff7e7ff9 aefefd7f 5f7f5ebf .....~......_.^.010000b0: 6fe87e7b fabfdbcf d3faefad 6fbb5e7a o.~{........o.^z010000c0: f6af86de ffdb7bbf ff5ff6ba bfa4bfdf ......{.._......010000d0: ffbfa87f ffe67fcd efeffb9a 9b7e6a6f .............~jo010000e0: fffcf76f efbfeebb ffaceab1 5cfbfffe ...o........\...010000f0: edebffde e29fefff deaeafdb f97bdff5 .............{..=> usb read 1000000 0 100
USB read: device 0 block # 0, count 256 ... 256 blocks read: OK=> md 100000001000000: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000010: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000020: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000030: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000040: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000050: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000060: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000070: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000080: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................01000090: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000a0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000b0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000c0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000d0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000e0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................010000f0: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ................=>
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 97
Verification in Linux
· Kernel configuration for USB memory stick support
* Device Drivers---> SCSI Device Support---> SCSI Device Support ---> <*> SCSI disk support
* Device Drivers---> SCSI Device Support---> SCSI Device Support ---> <*> SCSI generic support
* Device Drivers---> USB Support---> [*] USB Mass Storage Support
(The user can enable it either in kernel mode (set option as True) or as module (set option as Module)).
* File Systems---> DOS/FAT/NT Filesystems---> <*> MSDOS fs support
* File Systems---> DOS/FAT/NT Filesystems---> <*> VFAT(Window-95)fs support
* File Systems---> DOS/FAT/NT Filesystems---> VFAT(Window-95)fs support---> Default codepage for FAT - 437
* File Systems---> DOS/FAT/NT Filesystems---> VFAT(Window-95)fs support---> Default iocharset for FAT - "iso8859-1"
* File Systems---> Partition Types---> [*] Advanced partition selection
* File Systems---> Partition Types---> [*] PC BIOS (MSDOS partition tables) support
* File Systems---> Native Language Support---> Base native language support---> (iso8859-1) Default NLS Option
* File Systems---> Native Language Support---> Base native language support---> <*> Codepage 437 (United States, Canada)
* File Systems---> Native Language Support---> Base native language support---> <*> NLS ISO 8859-1 (Latin 1; Western European Languages)
· plug in memory stick
~ # usb 1-1: new high speed USB device using fsl-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
scsi 6:0:0:0: Direct-Access SanDisk Cruzer 7.01 PQ: 0 ANSI: 0 CCS
sd 6:0:0:0: [sda] 3907583 512-byte hardware sectors: (2.00 GB/1.86 GiB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Assuming drive cache: write through
sd 6:0:0:0: [sda] 3907583 512-byte hardware sectors: (2.00 GB/1.86 GiB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Assuming drive cache: write through
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 201698 NXP Semiconductors
sda: sda1
sd 6:0:0:0: [sda] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg0 type 0
scsi 6:0:0:1: CD-ROM SanDisk Cruzer 7.01 PQ: 0 ANSI: 0
sr0: scsi3-mmc drive: 48x/48x tray
Uniform CD-ROM driver Revision: 3.20
sr 6:0:0:1: Attached scsi generic sg1 type 5
~ # fdisk -l
Disk /dev/sda: 2000 MB, 2000682496 bytes
64 heads, 63 sectors/track, 969 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 969 1953439+ b Win95 FAT32
~ # mount -t vfat /dev/sda1 /mnt/cdrom/
~ # cd /mnt/cdrom/
/mnt/cdrom # ls
/mnt/cdrom # cp /usr/sbin/wd_keepalive .
/mnt/cdrom # ls
wd_keepalive
/mnt/cdrom # cd ..
/mnt # umount /mnt/cdrom/
====================================================================================To create ext2 file-system on USB flash drive, follow below steps:# fdisk /dev/sdaDevice contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabelBuilding a new DOS disklabel. Changes will remain in memory only,until you decide to write them. After that the previous contentwon't be recoverable.
Command (m for help): nCommand action e extended p primary partition (1-4)
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 99
pPartition number (1-4): 1First cylinder (1-1011, default 1): Using default value 1Last cylinder or +size or +sizeM or +sizeK (1-1011, default 1011): Using default value 1011
Command (m for help): wThe partition table has been altered!
Calling ioctl() to re-read partition tablesd 2:0:0:0: [sda] Test WP failed, assume Write Enabledsd 2:0:0:0: [sda] Assuming drive cache: write through sda: sda1[root@p5020 root]# mke2fs /dev/sda1mke2fs 1.41.4Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)65536 inodes, 262094 blocks13104 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=2684354568 block groups32768 blocks per group, 32768 fragments per group8192 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376
Writing inode tables: done Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 38 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.[root@p5020 /root]# mount /dev/sda1 /mnt
· Kernel configuration for USB Human Input Devices support
* Device Drivers--->
[*] HID Devices --->
-*- Generic HID support
<*> USB Human Interface Device (full HID) support
Input device support --->
-*- Generic input layer (needed for keyboard, mouse, ...)
<*> Mouse interface
[*] Provide legacy /dev/psaux device
(1024) Horizontal screen resolution
(768) Vertical screen resolution
[*] Keyboards --->
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016100 NXP Semiconductors
<*> AT keyboard
[*] Mice --->
<*> PS/2 mouse
[*] ALPS PS/2 mouse protocol extension
[*] Logitech PS/2++ mouse protocol extension
[*] Synaptics PS/2 mouse protocol extension
[*] IBM Trackpoint PS/2 mouse protocol extension
· plug in USB keyboard
~ # usb 1-1: new full speed USB device using fsl-ehci and address 3
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
usb 1-1.1: new full speed USB device using fsl-ehci and address 4
usb 1-1.1: configuration #1 chosen from 1 choice
input: Dell Dell USB Keyboard Hub as /class/input/input1
generic-usb 0003:413C:2002.0002: input: USB HID v1.10 Keyboard [Dell Dell USB Ke yboard Hub] on usb-fsl-ehci.0-1.1/input0
input: Dell Dell USB Keyboard Hub as /class/input/input2
generic-usb 0003:413C:2002.0003: input: USB HID v1.10 Device [Dell Dell USB Keyb
· plug in USB mouse
~ # usb 1-1: new low speed USB device using fsl-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
input: HID 413c:3010 as /class/input/input0
generic-usb 0003:413C:3010.0001: input: USB HID v1.00 Mouse [HID 413c:3010] on u
Power Management
Following Pwr. Mgmt. features are supported:
1) Sleep
2) Deep Sleep
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 101
Pwr. Mgmt. Kernel Configuration Option(s)
Kernel Configure Tree View Options Description
Kernel options--->
[*] Suspend to RAM and standby [*] Hibernation (aka 'suspend to disk') () Default resume partition (NEW)
Enable Power Management feature
Platform support --> CPU Frequency scaling --> [*] CPU Frequency scaling <*> CPU frequency translation statistics Default CPUFreq governor (userspace) --> -*- 'userspace' governor for userspace frequency scaling
CPU Frequency drivers --> [*] Support for Freescale MPC85xx CPU freq
Enable the CPU frequency driver
Verification in Linux
Sleep Capability
A system can be put into Suspend state, and can also be Resumed (woken-up) by USB. For this the following needs to bedone:
1. Enable USB remote wake-up capability before putting the system into Suspend state
~ # echo enabled >/sys/bus/usb/devices/usb1/power/wakeup
2. Insert/Remove a USB flash drive into USB port after the system is put into SUSPEND state. This will bring the system outof the SUSPEND state
# echo standby > /sys/power/statePM: Syncing filesystems ... done.Freezing user space processes ... (elapsed 0.01 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.Suspending console(s) (use no_console_suspend to debug)sd 0:0:0:0: [sda] Synchronizing SCSI cachesd 0:0:0:0: [sda] Stopping diskPM: suspend of devices complete after 519.108 msecsPM: late suspend of devices complete after 0.489 msecsPM: noirq suspend of devices complete after 0.555 msecsDisabling non-boot CPUs ...
USB Flash drive inserted --->
Enabling non-boot CPUs ...CPU1 is upPM: noirq resume of devices complete after 0.513 msecsPM: early resume of devices complete after 0.349 msecsfsl-lbc ffe05000.localbus: Chip select error: LTESR 0x00080000
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016102 NXP Semiconductors
/pcie@ffe09000: PCICSRBAR @ 0xfff00000/pcie@ffe0a000: PCICSRBAR @ 0x0/pcie@ffe0a000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering./pcie@ffe0a000: DMA window size is 0x0/pcie@ffe0b000: PCICSRBAR @ 0x0/pcie@ffe0b000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering./pcie@ffe0b000: DMA window size is 0x0pci 0000:00:00.0: enabling device (0106 -> 0107)pci 0001:02:00.0: enabling device (0106 -> 0107)pci 0002:04:00.0: enabling device (0106 -> 0107)ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000ata2: SATA link down (SStatus 0 SControl 300)ata1: Signature Update detected @ 504 msecsata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)ata1.00: configured for UDMA/133sd 0:0:0:0: [sda] Starting diskPM: resume of devices complete after 5419.653 msecsRestarting tasks ... done.root@p1022ds:~# usb 1-1: new high-speed USB device number 2 using fsl-ehciscsi2 : usb-storage 1-1:1.0scsi 2:0:0:0: Direct-Access SRT USB 1100 PQ: 0 ANSI: 4sd 2:0:0:0: Attached scsi generic sg1 type 0sd 2:0:0:0: [sdb] 15568896 512-byte logical blocks: (7.97 GB/7.42 GiB)sd 2:0:0:0: [sdb] Write Protect is offsd 2:0:0:0: [sdb] Mode Sense: 43 00 00 00sd 2:0:0:0: [sdb] No Caching mode page presentsd 2:0:0:0: [sdb] Assuming drive cache: write throughsd 2:0:0:0: [sdb] No Caching mode page presentsd 2:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1sd 2:0:0:0: [sdb] No Caching mode page presentsd 2:0:0:0: [sdb] Assuming drive cache: write throughsd 2:0:0:0: [sdb] Attached SCSI removable diskFAT-fs (sdb): error, fat_get_cluster: invalid cluster chain (i_pos 0)FAT-fs (sdb): Filesystem has been set read-only
Deep Sleep Capability
USB working across Deep sleep using Timer Interrupt
System is put into deep sleep using the following command :
~# echo 30 > /sys/devices/system/mpic/timer_wakeup;echo mem > /sys/power/statePM: Syncing filesystems ... done.mmc0: card e624 removedFreezing user space processes ... (elapsed 0.001 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.Suspending console(s) (use no_console_suspend to debug)sd 0:0:0:0: [sda] Synchronizing SCSI cachesd 0:0:0:0: [sda] Stopping diskPM: suspend of devices complete after 316.061 msecsPM: late suspend of devices complete after 0.217 msecsPM: noirq suspend of devices complete after 31.099 msecsDisabling non-boot CPUs .../pcie@ffe240000: PCICSRBAR @ 0xff000000/pcie@ffe240000: Setup 64-bit PCI DMA window/pcie@ffe240000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering.
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 103
/pcie@ffe240000: DMA window size is 0xe0000000/pcie@ffe250000: PCICSRBAR @ 0xff000000/pcie@ffe250000: Setup 64-bit PCI DMA window/pcie@ffe250000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering./pcie@ffe250000: DMA window size is 0xe0000000/pcie@ffe260000: PCICSRBAR @ 0x0/pcie@ffe260000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering./pcie@ffe260000: DMA window size is 0x0/pcie@ffe270000: PCICSRBAR @ 0xff000000/pcie@ffe270000: Setup 64-bit PCI DMA window/pcie@ffe270000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering./pcie@ffe270000: DMA window size is 0xe0000000
After 30 seconds, system comes out of deep sleep and usb storage device is successfully detected
Enabling non-boot CPUs ...CPU1 is upCPU2 is upCPU3 is upPM: noirq resume of devices complete after 63.844 msecsPM: early resume of devices complete after 0.166 msecscaam ffe300000.crypto: Instantiated RNG4 SH0caam ffe300000.crypto: Instantiated RNG4 SH1ata2: No Device OR PHYRDY change,Hstatus = 0x80000000ata2: SATA link down (SStatus 10 SControl 300)ata1: Signature Update detected @ 504 msecsata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)ata1.00: configured for UDMA/133sd 0:0:0:0: [sda] Starting diskPM: resume of devices complete after 4461.429 msecsRestarting tasks ... done.usb 1-1: USB disconnect, device number 3root@t1040rdb:~# EXT2-fs (sdb1): previous I/O error to superblock detected
EXT2-fs (sdb1): previous I/O error to superblock detected
EXT2-fs (sdb1): previous I/O error to superblock detected
EXT2-fs (sdb1): previous I/O error to superblock detected
mmc0: new high speed SDHC card at address e624mmcblk0: mmc0:e624 SU08G 7.40 GiB mmcblk0: p1usb 1-1: new high-speed USB device number 4 using fsl-ehciusb-storage 1-1:1.0: USB Mass Storage device detectedscsi4 : usb-storage 1-1:1.0scsi 4:0:0:0: Direct-Access JetFlash Transcend 4GB 8.07 PQ: 0 ANSI: 4sd 4:0:0:0: Attached scsi generic sg1 type 0sd 4:0:0:0: [sdb] 7843200 512-byte logical blocks: (4.01 GB/3.73 GiB)sd 4:0:0:0: [sdb] Write Protect is offsd 4:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1sd 4:0:0:0: [sdb] Attached SCSI removable disk
Deep Sleep using USB wake-up interrupt
This feature is not yet supported.
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016104 NXP Semiconductors
Known Bugs, Limitations, or Technical Issues
1. Across system Deep Sleep, if a device is already mounted, it may get umounted automatically. Hence, to use it again,the user needs to re-mount the device
2. USB remote wake-up during system Deep-Sleep is not yet supported
3. On some platforms where USB2 controller is muxed with some other IP, USB2 is disabled in default platformconfigurations inside both U-boot and Linux. For more details, please refer Platform BSP/Board User Manuals
4. Dual-Utmi Phy HW register restoration requirement for System Deep-Sleep feature: Some SoCs have a new utmi phyversion called "dual-utmi" phy (for example: T1040, T1042, T1020, T1022, T2080, T2081: rev1.0 and rev1.1 ). This dual-phy hw registers need to be saved and restored across system Deep-Sleep. Hence, a code is added in u-boot usbdriver that identifies all socs having this dual-utmi phy, and adds "dual_utmi" in phy_type property. This is used todetermine if all phy registers are to be saved (during system-suspend) and restored (during system-resume). Inabsence of restoration of dual-phy hw registers, system restore during deep-sleep is going to fail - system hangs andgoes into non-recoverable state.
6.9.2 USB Gadget Network Driver User Manual
6.9.2.1 USB 2.0 Gadget Network Driver User Manual
DescriptionThe NXP processor has a High speed Dual-Role(DR) USB controller, which supports device mode
Module Loading
USB device controller driver can be built in kernel or compiled as a module.
Gadget drivers are recommended to be built as modules, because parameters will be passed as module parameter
Table 4. Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers ---> USB support ---> <*> Support for Host-side USB <*> EHCI HCD (USB 2.0) support -*- Root Hub Transaction Translators [ ] Use Xilinx usb host EHCI controller core [*] Support for Freescale PPC on-chip EHCI USB controller
Need to enable CONFIG_USB_FSL_MPH_DR_OF
Table continues on the next page...
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 105
Table 4. Kernel Configure Tree View Options (continued)
Kernel Configure Tree View Options Description
Device Drivers ---> USB support ---> USB Gadget Support ---> < M > Support for USB Gadgets USB Peripheral Controller (Freescale Highspeed USB DR Peripheral Controller) ---> Freescale Highspeed USB DR Peripheral Controller
Enable NXP USB Device Controller support
Device Drivers ---> USB support ---> USB Gadget Support ---> < M > Support for USB Gadgets USB Gadget Drivers <M> Ethernet Gadget (with CDC Ethernet support) [*]RNDIS support (NEW) [ ]Ethernet Emulation Model (EEM) support (NEW)
Enable USB Gadget support
Table 5. Compile-time Configuration Options
Options Values Default Description
CONFIG_USB_SUPPORT y/n/m Ym Enable USB Support
CONFIG_USB_FSL_MPH_DR_OF
y/n/m Y Enable NXP EHCI USBcontroller
CONFIG_USB_GADGET y/n/m m Enable USB Gadgetmodules
CONFIG_USB_GADGET_FSL_USB2
y/n/m m Enable NXP USB peripheralcontroller
CONFIG_USB_ETH y/n/m m Enable Ethernet Gadget
CONFIG_USB_ETH_RNDIS
y/n y Enable Ethernet Gadget
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016106 NXP Semiconductors
Source Files
The driver source is maintained in the Linux kernel source tree.
Table 6. Source Files
Source File Description
drivers/usb/gadget/fsl_usb2_udc.c NXP USB peripheral controller driver
drivers/usb/host/fsl-mph-dr-of.c Hook between OF tree and platform device
drivers/usb/gadget/ether.c Ethernet gadget driver
Drivers/usb/gadget/rndis.[ch] Microsoft’s RNDIS support
Device Tree Entry
usb@22000 {
#address-cells = <1>; #size-cells = <0>; compatible = "fsl-usb2-<controller-type>-v<controller version>", "fsl-usb2-<controller-type>"; reg = <0x22000 0x1000>; /* specifies register base addr, soc dependent */ interrupt-parent = <&mpic>; interrupts = <28 0x2>; /* specifies usb interrupt line, soc dependent */ phy_type = "ulpi"; /* phy can be ulpi(external)/utmi(internal) */ dr_mode = "peripheral" /* this entry specifies usb mode */ };
Controller-type: dr(dual-role), mph(multi-port-host) controller-version: 1.6, 2.2, or earlier default
mode is always host. It can be either changed to peripheral inside the dts entry like above. In this
case re-compilation of dts is required. DR mode can also be changed to peripheral via u-boot
command line. This won't require DTS recompilation, and can work with default DTS For USB1
controller.
NOTE
=> setenv hwconfig 'usb1:dr_mode=peripheral,phy_type=<ulpi/utmi>
Test Procedure
For board specific changes (required for USB Gadget mode), please refer to the board BSP User Manual.
1. Bring all USB Gadget modules (driver/usb/gadget/*.ko including fs/configfs/configfs.ko) onto the target board.
2. Load device controller driver and test ethernet gadget
Load FSL gadget driver module udc-core.ko & fsl_usb2_udc.ko
bash# insmod udc-core.kobash# insmod fsl_usb2_udc.ko
Load Ethernet modules
bash# insmod configfs.ko
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 107
bash# insmod libcomposite.kobash# insmod u_ether.kobash# insmod u_rndis.kobash# insmod usb_f_rndis.kobash# insmod usb_f_ecm.kobash# insmod usb_f_ecm_subset.kobash# insmod g_ether.kousing random self ethernet addressusing random host ethernet addressusb0: HOST MAC 82:14:b4:63:d1:85usb0: MAC 4a:b1:59:3b:b3:bdusing random self ethernet addressusing random host ethernet addressg_ether gadget: Ethernet Gadget, version: Memorial Day 2008g_ether gadget: g_ether ready
bash# ifconfig usb0usb0 Link encap:Ethernet HWaddr 5e:0c:de:2f:f9:0f BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
3. Assign an IP to usb0
bash# ifconfig usb0 10.232.1.11 netmask 255.255.255.0 upIPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
bash# ifconfig usb0
usb0 usb0 Link encap:Ethernet HWaddr 5e:0c:de:2f:f9:0f inet addr:10.232.1.11 Bcast:10.232.1.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
4. Connect a USB cable between target board USB port and the USB port on Windows host machine.
As soon as USB cable is plugged into a Windows XP host, the following message displays:
http://embedded.seattle.intel-research.net/wiki/index.php?title=Setting_up_USBnet#Install_the_RNDIS_Driver
5. Download linux.inf from either of the following, and install the Windows XP RNDIS driver as mentioned in the previousstep:
http://www.davehylands.com/linux/gumstix/usbnet/linux.infhttp://embedded.seattle.intel-research.net/wiki/files/linux.inf
For Windows 7, driver will automatically install.
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016108 NXP Semiconductors
6. As soon as driver installed on host, the following message displays on the target:
bash# g_ether gadget: high-speed config #2: RNDISIPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
7. Once the RNDIS driver is installed, configured, and loaded, configure the IP address for the new network device.
For example, assign 10.232.1.10 as IP to the RNDIS device and run ipconfig to verify the network configuration.
8. Now run ping both ways to check the connectivity between RNDIS@Windows and usb0@linux
D:\Profiles>ping 10.232.1.11
Pinging 10.232.1.11 with 32 bytes of data:
Reply from 10.232.1.11: bytes=32 time<1ms TTL=64Reply from 10.232.1.11: bytes=32 time<1ms TTL=64Reply from 10.232.1.11: bytes=32 time<1ms TTL=64
Ping statistics for 10.232.1.11: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
bash# ping 10.232.1.10
PING 10.232.1.10 (10.232.1.10): 56 data bytes
64 bytes from 10.232.1.10: seq=0 ttl=128 time=4.352 ms64 bytes from 10.232.1.10: seq=1 ttl=128 time=1.015 ms64 bytes from 10.232.1.10: seq=2 ttl=128 time=0.974 ms64 bytes from 10.232.1.10: seq=3 ttl=128 time=0.935 ms64 bytes from 10.232.1.10: seq=4 ttl=128 time=1.021 ms
--- 10.232.1.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max = 0.935/1.659/4.352 ms
Known Bugs, Limitations, or Technical Issues
If a board/platform is having multiple USB controller, they cannot be simultaneously used in "gadget/peripheral" mode. Pleasedo not set dr_mode as “peripheral” for both the controllers at the same time.
Supporting Documentation
Linux USB gadget framework - http://www.linux-usb.org/gadget/
Please refer to http://embedded.seattle.intel-research.net/wiki/index.php?title=Setting_up_USBnet for setting up the RNDISon Windows XP.
Linux USBnet @ http://www.linux-usb.org/usbnet/
6.9.3 USB 3.0 Host/Peripheral Linux Driver User Manual
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 109
6.9.3.1 USB 3.0 Host/Peripheral Linux Driver User Manual
Description
The driver supports xHCI SuperSpeed (SS) Dual-Role-Device (DRD) controller
Main features of xHCI controller
• Supports operation as a standalone USB xHCI host controller
• USB dual-role operation and can be configured as host or device
• Super-speed (5 GT/s), High-speed (480 Mbps), full-speed (12 Mbps), and low-speed (1.5 Mbps) operations
• Supports operation as a standalone single port USB
• Supports eight programmable, bidirectional USB endpoints
• OTG (On-The-Go) 2.0 compliant, which includes both device and host capability.
Modes of Operation
• Host Mode: SS/HS/FS/LS
• Device Mode: SS/HS/FS
• OTG: HS/FS/LS
Super-speed operation is not supported when OTG is enabled NOTE
This document explains working of HS Host and HS Device in Linux
NOTE
Module LoadingThe default kernel configuration enables support for USB_DWC3 as built-in kernel module.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers--->
USB support --->
[*] Support for Host-side USB
Enables USB host controller support
Device Drivers--->
USB support ---> <*> xHCI HCD (USB 3.0) support
Enables XHCI Host Controller Driverand transaction translator
Table continues on the next page...
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016110 NXP Semiconductors
Table continued from the previous page...
Kernel Configure Tree View Options Description
Device Drivers--->
USB support ---> <*> USB Mass Storage support
[ ] USB Mass Storage verbose debug
Enable support for USB mass storagedevices. This is the driver needed forUSB flash devices, and memory sticks
<*> Sound card support ---><*> Advanced Linux Sound Architecture ---> <*> OSS Mixer API <*> OSS PCM (digital audio) API [*] OSS PCM (digital audio) API - Include plugin system [*] Support old ALSA API [*] USB sound devices ---> <*> USB Audio/MIDI driver
Enables support for USB Audio devices.This driver is needed for USBmicrophone.
Device Drivers--->
USB support ---> <*> USB Gadget Support --->
<M> USB Gadget Drivers < > USB functions configurable through configfs < > Gadget Zero (DEVELOPMENT) <M> Ethernet Gadget (with CDC Ethernet support) [*] RNDIS support [ ] Ethernet Emulation Model (EEM) support < > Network Control Model (NCM) support < > Gadget Filesystem < > Function Filesystem <M> Mass Storage Gadget < > Serial Gadget (with CDC ACM and CDC OBEX support)
Note: Required only for USB Gadget/Peripheral Support
• Enable driver for peripheral/devicecontroller
• Enable Ethernet Gadget Client driver
• Enable Mass Storage Client driver
Device Drivers--->
<*> DesignWare USB3 DRD Core Support DWC3 Mode Selection (Dual Role mode) --->
Enable XHCI DRD Core Support
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_USB y/m/n y Enables USB host controller
CONFIG_USB_XHCI_HCD y/m/n y Enables XHCI HCD
CONFIG_USB_DWC3 y/m/n y Enables DWC3 Controller
Table continues on the next page...
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 111
Table continued from the previous page...
Option Values Default Value Description
CONFIG_USB_GADGET y/m/n n Enables USB peripheral device
CONFIG_USB_ETH y/m/n n Enable Ethernet style communication
CONFIG_USB_MASS_STORAGE m/n n Enable USB Mass Storage disk drive
CONFIG_SOUND y/m/n y Enables Sound Card Support
CONFIG_SND y/m/n y Enables ALSA (Advanced Linux Sound Architecture)
CONFIG_SND_MIXER_OSS y/m/n y Enables OSS Mixer API
CONFIG_SND_PCM_OSS y/m/n y Enables OSS PCM (digital audio) API
CONFIG_SND_PCM_OSS_PLUGINS y/n y Enables OSS PCM (digital audio) API - Include pluginsystem
CONFIG_SND_SUPPORT_OLD_API y/n y Enables old ALSA API
CONFIG_SND_USB y/n n Enables USB sound devices
CONFIG_SND_USB_AUDIO y/m/n n Enables USB Audio/MIDI driver
NOTE: USB Audio configuration options default value is listed for LS1021A platform.
Source Files
The driver source is maintained in the Linux kernel source tree in below files
Table continued from the previous page...
Source File Description
drivers/usb/host/xhci-* xhci platform driver
drivers/usb/gadget/mass_storage.c USB Mass Storage
drivers/usb/gadget/ether.c Ethernet gadget driver
Device Tree Binding for Host
usb@3100000 { compatible = "snps,dwc3"; reg = <0x0 0x3100000 0x0 0x10000>; interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; dr_mode = "host; };
Device Tree Binding for Peripheral
Note: with multiple USB controller, just one can be peripheral mode at a time.
usb@3100000 { compatible = "snps,dwc3";
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016112 NXP Semiconductors
reg = <0x0 0x3100000 0x0 0x10000>; interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; dr_mode = "peripheral; maximum-speed = "super-speed"; };
Host Testing
Following are serial console logs that appear during bootup if dr_mode set to host in device-tree
usbcore: registered new interface driver usbfsusbcore: registered new interface driver hubusbcore: registered new device driver usb xhci-hcd xhci-hcd.0.auto: xHCI Host Controllerxhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1xhci-hcd xhci-hcd.0.auto: irq 125, io mem 0x03100000hub 1-0:1.0: USB hub foundhub 1-0:1.0: 1 port detectedxhci-hcd xhci-hcd.0.auto: xHCI Host Controllerxhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2hub 2-0:1.0: USB hub foundhub 2-0:1.0: 1 port detectedusbcore: registered new interface driver usb-storage
Following are serial-console logs after connecting a USB flash drive
For High-Speed Device attachusb 1-1.2: new high-speed USB device number 3 using xhci-hcdusb-storage 1-1.2:1.0: USB Mass Storage device detectedscsi0 : usb-storage 1-1.2:1.0scsi 0:0:0:0: Direct-Access SanDisk Cruzer 7.01 PQ: 0 ANSI: 0 CCSsd 0:0:0:0: [sda] 1957887 512-byte logical blocks: (1.00 GB/955 MiB)sd 0:0:0:0: Attached scsi generic sg0 type 0sd 0:0:0:0: [sda] Write Protect is offsd 0:0:0:0: [sda] No Caching mode page foundsd 0:0:0:0: [sda] Assuming drive cache: write throughsd 0:0:0:0: [sda] No Caching mode page foundsd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1sd 0:0:0:0: [sda] No Caching mode page foundsd 0:0:0:0: [sda] Assuming drive cache: write throughsd 0:0:0:0: [sda] Attached SCSI removable disk
For Super-Speed Device attach# usb 2-1: new SuperSpeed USB device number 2 using xhci-hcdusb 2-1: Parent hub missing LPM exit latency info. Power management will be impacted.usb-storage 2-1:1.0: USB Mass Storage device detectedscsi0 : usb-storage 2-1:1.0scsi 0:0:0:0: Direct-Access SanDisk Extreme 0001 PQ: 0 ANSI: 6sd 0:0:0:0: [sda] 31277232 512-byte logical blocks: (16.0 GB/14.9 GiB)sd 0:0:0:0: Attached scsi generic sg0 type 0sd 0:0:0:0: [sda] Write Protect is offsd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda:sd 0:0:0:0: [sda] Attached SCSI removable diskFAT-fs (sda): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 113
Make filesystem and mount connected USB flash drive using below commands
root@freescale /$ fdisk -l
Disk /dev/sda: 16.0 GB, 16013942784 bytes255 heads, 63 sectors/track, 1946 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System/dev/sda1 1 1946 15631213+ 83 Linuxroot@freescale /$root@freescale /$ dfFilesystem 1K-blocks Used Available Use% Mounted onshm 516684 0 516684 0% /dev/shmrwfs 512 0 512 0% /mnt/rwfsroot@freescale /$root@freescale /$root@freescale /$root@freescale /$root@freescale /$ fdisk /dev/sda
The number of cylinders for this disk is set to 1946.There is nothing wrong with that, but this is larger than 1024,and could in certain setups cause problems with:1) software that runs at boot time (e.g., old versions of LILO)2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): dSelected partition 1
Command (m for help): nCommand action e extended p primary partition (1-4)pPartition number (1-4): 1First cylinder (1-1946, default 1): Using default value 1Last cylinder or +size or +sizeM or +sizeK (1-1946, default 1946): Using default value 1946
Command (m for help): wThe partition table has been alter sda: sda1ed!
Calling ioctl() to re-read partition tableroot@freescale /$root@freescale /$root@freescale /$ fdisk -l
Disk /dev/sda: 16.0 GB, 16013942784 bytes255 heads, 63 sectors/track, 1946 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System/dev/sda1 1 1946 15631213+ 83 Linuxroot@freescale /$ dfFilesystem 1K-blocks Used Available Use% Mounted onshm 516684 0 516684 0% /dev/shmrwfs 512 0 512 0% /mnt/rwfsroot@freescale /$ mkdir my_mnt
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016114 NXP Semiconductors
root@freescale /$root@freescale /$root@freescale /$ mkfs.ext2 /dev/sda1Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)977280 inodes, 3907803 blocks195390 blocks (5%) reserved for the super userFirst data block=0Maximum filesystem blocks=4194304120 block groups32768 blocks per group, 32768 fragments per group8144 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208root@freescale /$root@freescale /$root@freescale /$root@freescale /$root@freescale /$root@freescale /$ mount /dev/sda1 my_mnt/root@freescale /$root@freescale /$root@freescale /$root@freescale /$ dfFilesystem 1K-blocks Used Available Use% Mounted onshm 516684 0 516684 0% /dev/shmrwfs 512 0 512 0% /mnt/rwfs/dev/sda1 15385852 20 14604272 0% /my_mntroot@freescale /$
Test by wring/reading data on mount drive
root@freescale /$ dd if=/dev/urandom of=/tmp/123 bs=1M count=100100+0 records in100+0 records out104857600 bytes (100.0MB) copied, 54.535026 seconds, 1.8MB/sroot@freescale /$root@freescale /$root@freescale /$root@freescale /$ cp /tmp/123 /my_mnt/.root@freescale /$ syncroot@freescale /$ ls /my_mnt/123 lost+foundroot@freescale /$
Peripheral testing with Win7 as Host
In gadget mode standard USB cables with micro plug should be used.
NOTE
Below Message will appear during bootup if dr_mode set as peripheral in device-tree
usbcore: registered new interface driver usbfsusbcore: registered new interface driver hubusbcore: registered new device driver usb
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 115
usbcore: registered new interface driver usb-storage
Make sure "dr_mode" contains "peripheral" string
root@freescale /$# cat /proc/device-tree/soc/usb\@3100000/dwc3/dr_mode peripheral root@freescale /$
Move all below modeules to platform
fs/configfs/configfs.kodriver/usb/gadget/libcomposite.kodriver/usb/gadget/g_mass_storage.kodriver/usb/gadget/u_rndis.kodriver/usb/gadget/u_ether.kodriver/usb/gadget/usb_f_ecm.kodriver/usb/gadget/usb_f_ecm_subset.kodriver/usb/gadget/usb_f_rndis.kodriver/usb/gadget/g_ether.ko
Mass Storage Gadget
To use ramdisk as a backing store use the following
root@freescale /$ mkdir /mnt/ramdriveroot@freescale /$ mount -t tmpfs tmpfs /mnt/ramdrive -o size=600Mroot@freescale /$ dd if=/dev/zero of=/mnt/ramdrive/vfat-file bs=1M count=500root@freescale /$ mke2fs -F /mnt/ramdrive/vfat-fileroot@freescale /$ insmod configfs.koroot@freescale /$ insmod libcomposite.koroot@freescale /$ insmod usb_f_mass_storage.koroot@freescale /$ insmod g_mass_storage.ko file=/mnt/ramdrive/vfat-file stall=n
We will get below messages
[ 39.987594] g_mass_storage gadget: Mass Storage Function, version: 2009/09/11[ 39.994822] g_mass_storage gadget: Number of LUNs=1[ 39.989240] lun0: LUN: file: /home/backing_file_20mb[ 39.994367] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11[ 39.990902] g_mass_storage gadget: userspace failed to provide iSerialNumber[ 39.987547] g_mass_storage gadget: g_mass_storage ready
Attached ***USB3.0 only*** gadget cable to host and you will get below message. Now Storage is ready to use.
g_mass_storage gadget: super-speed config #1: Linux File-Backed Storage
Speaker and Microphone
1. Aplay utility can be used to list the available sound cards e.g. Here Jabra 410 USB speaker is detected as a secondsound card and can be addressed as –D hw:1,0 OR –c1:
[root@freescale ~]$ aplay –l**** List of PLAYBACK Hardware Devices **** card 0: FSLVF610TWRBOAR [FSL-VF610-TWR-BOARD], device 0: HiFi sgtl5000-0 [ ] Subdevices: 1/1 Subdevice #0: subdevice #0
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016116 NXP Semiconductors
card 1: USB [Jabra SPEAK 410 USB], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0
2. Sample wav file can be played using the below command:
[root@freescale ~]$ aplay -D hw:1,0 LYNC_fsringing.wavPlaying WAVE 'LYNC_fsringing.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
3. Sample wav file can be recorded using the below command:
[root@freescale ~]$ arecord -f S16_LE -t wav -Dhw:1,0 -r 16000 foobar.wav -d 5Recording WAVE 'foobar.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono
NOTE: If recorded audio is not played, try to use "-D plughw:1,0" in above command.
4. Audio controls can be checked using the below command, control details and name of the controls can be checked fromoutput of “amixer –c1” as below:
[root@freescale ~]$ amixer –c1 controlsnumid=3,iface=MIXER,name='PCM Playback Switch'numid=4,iface=MIXER,name='PCM Playback Volume'numid=5,iface=MIXER,name='Headset Capture Switch'numid=6,iface=MIXER,name='Headset Capture Volume'numid=2,iface=PCM,name='Capture Channel Map'numid=1,iface=PCM,name='Playback Channel Map'
[root@freescale ~]$ amixer –c1Simple mixer control 'PCM',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 11 Mono: Playback 4 [36%] [-20.00dB] [on]
Simple mixer control 'Headset',0 Capabilities: cvolume cvolume-joined cswitch cswitch-joined penum Capture channels: Mono Limits: Capture 0 - 7 Mono: Capture 5 [71%] [0.00dB] [on]
For Example, in above output there are two controls named “PCM” and “Headset” for Speaker and microphonerespectively.
Sample Audio controls Usage:
a. mute/unmute
[root@freescale ~]$ amixer -c1 set PCM muteSimple mixer control 'PCM',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 11 Mono: Playback 2 [18%] [-28.00dB] [off] [root@freescale ~]$ amixer -c1 set PCM unmuteSimple mixer control 'PCM',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 11 Mono: Playback 2 [18%] [-28.00dB] [on]
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 117
b. volume up/down – Below commands are trying to set volume to 11 and 2 performing volume up and down respectively.
root@freescale ~]$ amixer -c1 set PCM 11 Simple mixer control 'PCM',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 11 Mono: Playback 11 [100%] [8.00dB] [on] [root@freescale ~]$ amixer -c1 set PCM 2 Simple mixer control 'PCM',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 11 Mono: Playback 2 [18%] [-28.00dB] [on]
Ethernet Gadget
To use Ethernet gadget use the following
root@freescale /$ insmod configfs.koroot@freescale /$ insmod libcomposite.ko root@freescale /$ insmod u_ether.koroot@freescale /$ insmod u_rndis.koroot@freescale /$ insmod usb_f_ecm.koroot@freescale /$ insmod usb_f_ecm_subset.koroot@freescale /$ insmod usb_f_rndis.koroot@freescale /$ insmod g_ether.ko
We will get below messages
[ 28.692611] using random self ethernet address[ 28.697156] using random host ethernet address[ 28.694271] usb0: HOST MAC 82:96:69:7e:a5:7d[ 28.698928] usb0: MAC 72:00:a5:80:2b:e8[ 28.692586] using random self ethernet address[ 28.697080] using random host ethernet address[ 28.691368] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008[ 28.698028] g_ether gadget: g_ether ready
Make sure USB0 ethernet interface is available after this
root@freescale /$ ifconfig -acan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:158
can1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:159
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016118 NXP Semiconductors
eth0 Link encap:Ethernet HWaddr 00:E0:0C:BC:E5:60 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr 00:E0:0C:BC:E5:61 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth2 Link encap:Ethernet HWaddr 00:E0:0C:BC:E5:62 inet addr:10.232.132.212 Bcast:10.232.135.255 Mask:255.255.252.0 inet6 addr: fe80::2e0:cff:febc:e562/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2311 errors:0 dropped:3 overruns:0 frame:0 TX packets:66 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:290810 (283.9 KiB) TX bytes:8976 (8.7 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 B) TX bytes:100 (100.0 B)
sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
usb0 Link encap:Ethernet HWaddr 72:00:A5:80:2B:E8 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Attached the cable with Win7 and Configure RNDS interface in windows under "Control Panel -> Network and Internet ->Network Connections" and set IP Address
Set IP Address in Platform and start Ping
root@freescale /$ ifconfig usb0 10.232.1.11root@freescale /$ root@freescale /$ root@freescale /$ ping usb 10.232.1.10PING 10.232.1.10 (10.232.1.10): 56 data bytes64 bytes from 10.232.1.10: seq=0 ttl=128 time=5.294 ms64 bytes from 10.232.1.10: seq=1 ttl=128 time=6.101 ms
Linux Kernel Drivers
Universal Serial Bus Interfaces
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 119
64 bytes from 10.232.1.10: seq=2 ttl=128 time=4.170 ms64 bytes from 10.232.1.10: seq=3 ttl=128 time=4.233 ms
Known Bugs, Limitations, or Technical Issues
• Some issue with Pen drives from Kingston/Transcend. This have noticed some patches floating in open-source for theseissues, and also found that open-source USB community trying to fix.
• Linux allow only one peripheral at one time. Please make sure When DWC3 set as Peripheral the other should not beset in same mode.
• Erratum:A-009116 (Frame length of USB3 controller for USB2.0 and USB3.0 operation is incorrect) impacts some socslike LS1020A/LS1021A because of which some USB2.0 and USB3.0 devices may not work properly, and hence, a swworkaround is needed. This sw workaround involves programing following registers of XHCI controller as: GFLADJ[5:0]= 20H and GFLADJ[7] = 1. This is already done via u-boot and linux codebase.
6.10 Watchdog Timers
6.10.1 Watchdog Device Driver User Manual
DescriptionWatchdog driver description here.
Module LoadingWatchdog device driver support kernel built-in mode.
U-Boot Configuration
Runtime options
Env Variable Env Description Sub option Option Description
bootargs Kernel command line argumentpassed to kernel
setenv othbootargswdt_period=35
Sets the watchdog timer periodtimeout
Kernel Configure Options
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers --->
[*] Watchdog Timer Support --->
[*] Disable watchdog shutdown on close
[*] PowerPC Book-E Watchdog Timer
PowerPC Book-E Watchdog Timer
Linux Kernel Drivers
Watchdog Timers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016120 NXP Semiconductors
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_BOOKE_WDT y/n y PowerPC Book-E Watchdog Timer
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/char/watchdog/booke_wdt.c PowerPC Book-E Watchdog Timer
User Space Application
The following applications will be used during functional or performance testing. Please refer to the SDK UM document forthe detailed build procedure.
Command Name Description Package Name
watch watchdog is a daemon for watchdog feeding watchdog
Verification in Linux
· set nfs rootfs
build a rootfs image which includes watchdog daemon.
· et booting parameter
on the u-boot prompt, set following parameter
set nfsargs "setenv bootargs wdt_period=35 root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off
console=$consoledev,$baudrate $othbootargs"
set nfsboot "run nfsargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr"
run nfsboot
Note: wdt_period is watchdog timeout period, set it with proper value depending on your board bus frequency.
Linux Kernel Drivers
Watchdog Timers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 121
Also wdt_period is inversely proportional to watchdog expiry time ie. Higher the wdt_period, lower the watchdog expiry time.
So if we increase wdt_period to high, watchdog will expiry early.
· check watchdog feeding operation
after system boots up, check the screen output, if you see
...
PowerPC Book-E Watchdog Timer Enabled (wdt_period=35)
...
it means watchdog module loads successfully
login in system, run command "watchdog /dev/watchdog"
root@p1020rdb:~# watchdog /dev/watchdog
root@p1020rdb:~# ps -ae | grep watchdog
3285 ? 00:00:00 watchdog
root@p1020rdb:~#
Linux Kernel Drivers
Watchdog Timers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016122 NXP Semiconductors
wait for some minutes, if system is still alive, watchdog feeding is OK
· check watchdog reboot operation
run command "killall"
root@p1020rdb:~# killall -9 watchdog
root@p1020rdb:~#
root@p1020rdb:~# ps -ae | grep watchdog
root@p1020rdb:~#
root@p1020rdb:~# PowerPC Book-E Watchdog Exception
wait for some seconds, if system reboots, watchdog reboot operation is OK
Known Bugs, Limitations, or Technical Issues
· On the T4240RDB board, if you will use watchdog, please disable the following menu configuration in kernel Location: |--> Device Drivers |--> Hardware Monitoring support (HWMON [=n]) Or they are conflicting with each other.
Linux Kernel Drivers
Watchdog Timers
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 123
Chapter 7Additional Linux Use Cases
7.1 Power Management
7.1.1 Power Management User Manual
Linux SDK for QorIQ Processors
Description
QorIQ Processors have features to minimize power consumption at several different levels. All processors support a sleepmode (LPM20). Some processors, such as T1040, LS1021, LS1046, also support a deep sleep mode (LPM35).
The following power management features are supported on various QorIQ processors:
• Dynamic power management
• Shutting down unused IP blocks
• Cores support low power modes (such as PW15)
• Processors enter low power state (LPM20, LPM35)
• LPM20 mode: most part of processor clocks are shut down
• LPM35 mode: power is removed to cores, cache and IP blocks of the processor such as DIU, eLBC, PEX, eTSEC,USB, SATA, eSDHC etc.
• CPU hotplug: If cores are down at runtime, they will enter low power state.
The wake-up event sources caused quitting from low power mode are listed as below:
• Wake on LAN (WoL) using magic packet
• Wake by MPIC timer or FlexTimer
• Wake by Internal and external interrupts
For more information on a specific processor, refer to processor Reference Manual.
Kernel Configure Tree View Options
For ARM platforms
Kernel Configure Tree View Options Description
Power management options --> [*] Suspend to RAM and standby
Enable sleep feature
Device Drivers ---> SOC (System On Chip) specific Drivers --->
Enable the FTM alarm(FlexTimer module) driver
Table continues on the next page...
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016124 NXP Semiconductors
Table continued from the previous page...
Kernel Configure Tree View Options Description
[*] Layerscape Soc Drivers [*] FTM alarm driver
CPU Power Management --->CPU Idle --->[*] CPU idle PM support[*] Ladder governor (for periodic timer tick)-*- Menu governor (for tickless system) ARM CPU Idle Drivers ---> [*] Generic ARM/ARM64 CPU idle Driver
Enable the CPU Idle driver
Table continues on the next page...
Compile-time Configuration Options
Linux Framework Hardware Feature Platform Kernel Config
Suspend LPM20 LS1012, LS1021,LS1046
CONFIG_SUSPEND
wake by Flextimer LS1012, LS1021,LS1046
CONFIG_FTM_ALARM
CPU idle PW15 LS1012, LS1021,LS1046
CONFIG_ARM_CPUIDLE
Device Tree Binding
Property Type Description
fsl,#rcpm-wakeup-cells unsigned int the number of cells in "rcpm-wakeup" except the pointer to "rcpm"
rcpm-wakeup unsigned int require if the IP block can work as a wakeup source
For processors integrated RCPM
rcpm: rcpm@1ee2000 { compatible = "fsl,ls1046a-rcpm", "fsl,qoriq-rcpm-2.1"; reg = <0x0 0x1ee2000 0x0 0x1000>; fsl,#rcpm-wakeup-cells = <1>; };
ftm0: ftm0@29d0000 { compatible = "fsl,ftm-alarm"; reg = <0x0 0x29d0000 0x0 0x10000>; interrupts = <0 86 0x4>; big-endian; rcpm-wakeup = <&rcpm 0x0 0x20000000>;
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 125
status = "okay"; };
Refer to the Linux document: Documentation/devicetree/bindings/soc/fsl/rcpm.txt
Source Files
The source files are maintained in the Linux kernel source tree.
Source File Description
drivers/soc/fsl/layerscape/rcpm.c the RCPM driver needed by the sleep feature
drivers/soc/fsl/layerscape/ftm_alarm.c the FTM timer driver worked as a wakeup source
drivers/cpuidle/cpuidle-arm.c the cpuidle driver for ARM core
Verification in Linux
• Cpuidle Driver
The cpuidle driver can switch CPU state according to the idle policy (governor). For more information, please see"Documentation/cpuidle/sysfs.txt" in kernel source code.
/* Check the cpuidle driver which is currently used. */# cat /sys/devices/system/cpu/cpuidle/current_driver
/* Check the following directory to see the detailed statistic information of each state on each CPU. *//sys/devices/system/cpu/cpu0/cpuidle/state0//sys/devices/system/cpu/cpu0/cpuidle/state1/
Supporting Documentation
• QorIQ processor reference manuals
7.1.2 CPU Frequency Switching User Manual
Linux SDK for QorIQ Processors
Abbreviations and Acronyms
DFS: Dynamic Frequency Scaling
Description
QorIQ Processors support DFS (Dynamic Frequency Switching) feature, also known as CPU Frequency Switch, which canchange the frequency of cores dynamically.
For more information on a specific processor, refer to processor Reference Manual.
Kernel Configure Tree View Options Description
CPU Power Management -->
Enable the CPU frequencydriver
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016126 NXP Semiconductors
Kernel Configure Tree View Options Description
CPU Frequency scaling --> [*] CPU Frequency scaling <*> CPU frequency translation statistics Default CPUFreq governor (userspace) --> -*- 'userspace' governor for userspace frequency scaling ARM CPU frequency scaling drivers --> <*> CPU frequency scaling driver for Freescale QorIQ SoCs
Compile-time Configuration Options
Linux Framework Hardware Feature Platform Kernel Config
cpufreq DFS ALL CONFIG_CPU_FREQ,CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE
cpufreq DFS Layerscape CONFIG_QORIQ_CPUFREQ
User Space Application
Simply using command "cat" and "echo" can verify this feature.
Device Tree Binding
Property Type Status Description
#clock-cells unsigned int Required The number of cells in a clock-specifier
clocks handle Required Clock source handle
compatible String Required Compatible strings
reg unsigned int Required register address range
Table continues on the next page...
clockgen: clocking@1ee1000 { compatible = "fsl,ls1012a-clockgen"; reg = <0x0 0x1ee1000 0x0 0x1000>; #clock-cells = <2>; clocks = <&sysclk>;};
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 127
Table continued from the previous page...
Source File Description
drivers/cpufreq/qoriq_cpufreq.c CPU frequency scaling driver for qoriq chips
Verification in Linux
• CPU frequency mode
In order to test the CPU frequency scaling feature, we need to enable the CPU frequency feature on the menuconfig and choose the USERSPACE governor.You can learn more about CPU frequency scaling feature by referring to the kernel documents.They all are put under Documentation/cpu-freq/ directory.For example: all the information about governors is put in Documentation/cpu-freq/governors.txt.
Test step:1. list all the frequencies a core can support (take cpu 0 for example) : # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies1199999 599999 299999 799999 399999 199999 1066666 533333 266666
2. check the CPU's current frequency# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq1199999
3. change the CPU's frequency we expect:# echo 799999 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
You can check the CPU's current frequency again to confirm if the frequency transition is successful.
Please note that if the frequency you want to change to doesn't support by current CPU, kernel willround up or down to one CPU supports.
7.1.3 System Monitor
7.1.3.1 Power Monitor User Manual
Description
There are two methods currently we can use to measure the power consumption which are called online and offline powermonitoring respectively. The difference between them is that offline power monitoring support measuring power consumptionduring sleep or deep sleep.
The Power Monitor can be supported on P4080DS/P5020DS/P5040DS/T4240QDS board.
This User guide uses the T4240QDS board as an example.
Online Power Monitoring
The Lm-sensors tool ( download from http://dl.lm-sensors.org/lm-sensors/releases) will be used to read the power/temperature from on-boards sensors. The drivers vary from sensor to sensor. Basically they would be INA220, ZL6100 andADT7461 etc.
The device driver support either a built-in kernel or module loading.
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016128 NXP Semiconductors
Kernel Configure Tree View Options
Option Description
Device Drivers ---> <*> Hardware Monitoring support ---> <*> Texas Instruments INA219 and compatibles
Enables INA220
Device Drivers ---> [*] Enable compatibility bits for old user-space <*> I2C device interface [*] Autoselect pertinent helper modules I2C Hardware Bus support ---> <*> MPC107/824x/85xx/512x/52xx/83xx/86xx
Enables I2C block device driver support
Device Drivers ---> <*> I2C bus multiplexing support Multiplexer I2C Chip support ---> <*> Philips PCA954x I2C Mux/switches
Enables I2C bus multiplexing PCA9547
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_I2C_MPC y/n y Enable I2C bus protocol
SENSORS_INA2XX y/n y Enables INA220
CONFIG_I2C_MUX_PCA954x y/n y Enables I2C multiplexing PCA9547
Device Tree Binding
Property Type Status Description
compatible String Required "Philips,pca9547" for pca9547
reg integer Required reg = <0x77>
compatible String Required "ti,ina220" for ina220
reg integer Required reg = <the i2c address of ina220>
Default node: i2c@118000 { pca9547@77 { compatible = "philips,pca9547"; reg = <0x77>; #address-cells = <1>; #size-cells = <0>;
channel@2 { #address-cells = <1>; #size-cells = <0>; reg = <0x2>;
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 129
ina220@40 { compatible = "ti,ina220"; reg = <0x40>; shunt-resistor = <1000>; };
ina220@41 { compatible = "ti,ina220"; reg = <0x41>; shunt-resistor = <1000>; };
ina220@44 { compatible = "ti,ina220"; reg = <0x44>; shunt-resistor = <1000>; };
ina220@45 { compatible = "ti,ina220"; reg = <0x45>; shunt-resistor = <1000>; };
ina220@46 { compatible = "ti,ina220"; reg = <0x46>; shunt-resistor = <1000>; };
ina220@47 { compatible = "ti,ina220"; reg = <0x47>; shunt-resistor = <1000>; }; }; };
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/i2c/muxes/i2c-mux-pca954x.c PCA9547 driver
drivers/hwmon/ina2xx.c ina220 driver
Test Procedure
Do the following to validate under the kernel
1. The bootup information is displayed:
......i2c /dev entries drivermpc-i2c ffe118000.i2c: timeout 1000000 usmpc-i2c ffe118100.i2c: timeout 1000000 usmpc-i2c ffe119000.i2c: timeout 1000000 usmpc-i2c ffe119100.i2c: timeout 1000000 us
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016130 NXP Semiconductors
i2c i2c-0: Added multiplexed i2c bus 6i2c i2c-0: Added multiplexed i2c bus 7i2c i2c-0: Added multiplexed i2c bus 8i2c i2c-0: Added multiplexed i2c bus 9i2c i2c-0: Added multiplexed i2c bus 10i2c i2c-0: Added multiplexed i2c bus 11i2c i2c-0: Added multiplexed i2c bus 12i2c i2c-0: Added multiplexed i2c bus 13pca954x 0-0077: registered 8 multiplexed busses for I2C mux pca9547ina2xx 8-0040: power monitor ina220 (Rshunt = 1000 uOhm)ina2xx 8-0041: power monitor ina220 (Rshunt = 1000 uOhm)ina2xx 8-0045: power monitor ina220 (Rshunt = 1000 uOhm)ina2xx 8-0046: power monitor ina220 (Rshunt = 1000 uOhm)ina2xx 8-0047: power monitor ina220 (Rshunt = 1000 uOhm)ina2xx 8-0044: power monitor ina220 (Rshunt = 1000 uOhm)......
2.
# sensorsina220-i2c-8-40Adapter: i2c-0-mux (chan_id 2)in0: +0.08 Vin1: +1.06 Vpower1: 35.00 Wcurr1: +32.77 A
ina220-i2c-8-41Adapter: i2c-0-mux (chan_id 2)in0: +0.01 Vin1: +0.01 Vpower1: 60.00 mWcurr1: +6.62 A
ina220-i2c-8-45Adapter: i2c-0-mux (chan_id 2)in0: +0.01 Vin1: +0.00 Vpower1: 60.00 mWcurr1: +8.20 A
ina220-i2c-8-46Adapter: i2c-0-mux (chan_id 2)in0: +0.01 Vin1: +0.01 Vpower1: 60.00 mWcurr1: +6.60 A
ina220-i2c-8-47Adapter: i2c-0-mux (chan_id 2)in0: +0.01 Vin1: +0.02 Vpower1: 140.00 mWcurr1: +7.40 A
ina220-i2c-8-44Adapter: i2c-0-mux (chan_id 2)in0: +0.00 Vin1: +1.51 V
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 131
power1: 1.86 Wcurr1: +1.23 A
Please make sure to include the "sensors" command in your rootfs
NOTE
Offline Power Monitoring
Inside the FPGA of some NXP QorIQ (PowerPC) reference boards is a microprocessor called the General Purpose Processor(GSMA). Running on the GSMA is the Data Collection Manager (DCM), which is used to periodically read and tally voltage,current, and temperature measurements from the on-board sensors. You can use this feature to measure power consumptionwhile running tests, without having the host CPU perform those measurements.
This method support measuring power consumption when kernel is in sleep or deep sleep status. It gets the average powervalue of period from the time DCM starts to the time it ends.
Module Loading
The device driver support either kernel built-in or module.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers --->[*] Misc devices ---> <*> Freescale Data Collection Manager (DCM) driver
Enables DCM driver
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_FSL_DCM y/n y Enable DCM module
Device Tree Binding
Property Type Status Description
compatible String Required "fsl,t4240qds-fpga", "fsl,fpga-qixis"
reg Integer Required reg = <3 0 0x300>
Default node: ifc: localbus@ffe124000 { board-control@3,0 { compatible = "fsl,t4240qds-fpga", "fsl,fpga-qixis"; reg = <3 0 0x300>; };
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/misc/fsl_dcm.c DCM driver
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016132 NXP Semiconductors
Test Procedure
Do the following to validate under the Kernel:
1. The bootup information is displayed:
......Freescale Data Collection Module is installed.......
2. Start measuring measure power
# echo 1 > /sys/devices/platform/fsl-dcm.0/control
3. Stop measuring power
#echo 0 > /sys/devices/platform/fsl-dcm.0/control
4. Display the average power consumption
#cat /sys/devices/platform/fsl-dcm.0/result
Name Average==================== ================CPU voltage: 1068 (mV)CPU current: 25910 (mA)DDR voltage: 1348 (mV)DDR current: 740 (mA)CPU temperature: 38 (C)
7.1.3.2 Thermal Monitor User Manual
Description
The Temperature Monitoring function is provided by the chip ADT7461.
This driver exports the values of Temperature to SYSFS. The user space lm-sensors tools can get and display these values.
Kernel Configure Tree View Options
Kernel Configure Tree View Options Description
Device Drivers ---> [*] Hardware Monitoring support ---> [*] National Semiconductor LM90 and compatibles
Enable thermal monitor chip driver like ADT7461.
Device Drivers ---> <*> I2C bus multiplexing support ---> Multiplexer I2C Chip support ---> <*> Philips PCA954x I2C Mux/switches
Enable I2C PCA954x multiplexer support
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 133
Compile-time Configuration Options
Option Values Default Value Description
CONFIG_HWMON y/m/n n Enable Hardware Monitor
CONFIG_SENSORS_LM90 y/m/n n Enable ATD7461 driver
CONFIG_I2C_MUX y/m/n n Enable I2C bus multiplexing support
CONFIG_I2C_MUX_PCA954x y/m/n n Enable PCA954x driver
Device Tree Binding
adt7461@4c { compatible = "adi,adt7461"; reg = <0x4c>; };
pca9547@77 { compatible = "philips,pca9547"; reg = <0x77>; };
Source Files
The driver source is maintained in the Linux kernel source tree.
Source File Description
drivers/hwmon/hwmon.c Linux hwmon subsystem support
drivers/hwmon/lm90.c ADT7461 chip driver
drivers/i2c/i2c-mux.c I2C bus multiplexing support
drivers/i2c/muxes/pca954x.c PCA954x chip driver
Verification in Linux
There are two ways to get temperature results.
1. You can manually read the thermal interfaces in sysfs:~$ ls /sys/class/hwmon/hwmon1/devicesalarms temp1_crit temp1_min_alarm temp2_max_alarmdriver temp1_crit_alarm temp2_crit temp2_minhwmon temp1_crit_hyst temp2_crit_alarm temp2_min_alarmmodalias temp1_input temp2_crit_hyst temp2_offsetname temp1_max temp2_fault ueventpower temp1_max_alarm temp2_input update_intervalsubsystem temp1_min temp2_max
~$ cat /sys/class/hwmon/hwmon1/devices/temp1_input29000
2. You can use lm_sensors tools as follows.~ # sensors adt7461-i2c-1-4c
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016134 NXP Semiconductors
Adapter: MPC adaptertemp1: +34.0 C (low = +0.0 C, high = +85.0 C) (crit = +85.0 C, hyst = +75.0 C)temp2: +48.5 C (low = +0.0 C, high = +85.0 C) (crit = +85.0 C, hyst = +75.0 C)
lm_sensors is integrated into Yocto file system by default. If there is no "sensors" command in your rootfs just addlmsensors-sensors package and build your own rootfs using Yocto:
IMAGE_INSTALL += "lmsensors-sensors"
7.1.3.3 Web-based System Monitor User GuideMonitors the health of a system using a web browser in real time.
Description
Web-based System Monitor is a tool for monitoring the health of your system using a web browser in real time. The followingprocedures will guide you to setup the system monitor.
Kernel requirements
The raw data of this monitor system is collected from hardware monitor chips. So before you setup this monitor system youshould enable the hwmon subsystem and drivers of monitor chips in the kernel. Kernel configure details are listed below.
Kernel Configure Tree View Options Description
Device Drivers ---> [*] Hardware Monitoring support ---> [*] National Semiconductor LM90 and compatibles [*] Texas Instruments INA219 and compatibles
Enable monitor chip drivers likeADT7461(ADT7481)/INA220, etc.
Device Drivers ---> <*> I2C bus multiplexing support ---> Multiplexer I2C Chip support ---> <*> Philips PCA954x I2C Mux/switches
Enable I2C PCA954x multiplexer support
Some monitor chips may not be included in the device tree. In this case you could add the device manually. Take adt7461on T4240QDS as an example: the monitor is attached to I2C multiplexer PCA954x channel 3 in address 0x43. T4240QDShas 4 I2C controllers so the channel index of multiplexer start from 4 (represent the channel 0). ADT7461 is connected tochannel 3 which indexed as 7. Use the flowing command to add the device to kernel:
~$ echo adt7461 0x4c > /sys/bus/i2c/devices/i2c-7/new_device
Rootfs requirements
You could use the fsl-image-full rootfs in which all packages needed are included.
Or you can build your own rootfs using Yotco. Please follow the steps below.
1. Add following package group to your rootfs recipes like fsl-image-core.bb:
IMAGE_INSTALL += "packagegroup-fsl-monitor"
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 135
2. If you are using ramdisk boot please add following settings to local.conf to get enough space for monitor systems:
IMAGE_ROOTFS_EXTRA_SPACE = "100000"
This will add 100000KB (100MB) more space to rootfs for monitor database. Each sensor needs
about 10MB more space for logging raw data.
NOTE
Setting up system monitor
The monitor system will be setup automatically. What you need to do is to make sure that the network on board is working.Then you can monitor the system via any web browser by visiting: http://your.ip.address/senspix/sensors.cgi. This resultspage will refresh itself for every 10 seconds.
If you need to re-setup the system you could enter /usr/rrd directory and run:
$ make clean$ make
The System Monitor only works when system time is right. So you should guarantee that.
NOTE
How to configure the system monitor
The monitor results you see is based on the configuration file: "monitor.conf". It's automatically generated by scanning thehwmon subsystem. You could manually modify it too. Here is how:
1. Each line of this configuration file represents one monitor curve. It contains four fields formatted as follows:
SENSDEV:MONITOR_TERM:DURATION:DESCRIPTION
SENSDEV: The sensor data can be monitored from /sys/class/hwmon/ interfaces. Each sensor has a corresponding folderdistinguished by hwmon# like hwmon0 or hwmon1. SENSDEV is the folder name.
MONITOR_TERM: This is the item you want to read like temp1 or temp2 etc.
DURATION: This is how long you want to see the results. You can set minute/hour/day here.
DESCRIPTION: This DESCRIPTION will show up on the result picture helping you to understand the contents of thecurve.
2. You could add/remove/resort the configuration file. After modifying it, you could enter the /usr/rrd directory and run:
$ make config
3. Then the monitor results will be updated to what you configured.
Run demo
We also provide scripts to cycle the system through different PM low power states to form a out-of-box demo for PM features.Please enter /usr/pm_demo directory and simply run:
$ ./pm_demo.sh
The output of the script will state the current PM features. It helps you to understand the system monitor results better.
The demo could be terminated by CTRL-C and will apply the default PM features back.
NOTE
Additional Linux Use Cases
Power Management
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016136 NXP Semiconductors
7.2 Real Time Application Note
7.2.1 Application Note on Real Time
Introduction
Baseband use-cases like 3G/4G have strict timelines to accomplish some particular jobs. Real Time (RT) feature availablein the operating system aims at creating an environment to meet these time critical processing requirements. There arevarious approaches available for providing RT feature.
NXP uses Linux PREEMPT_RT patch (also known as RT patch) to meet these requirements. PREEMPT_RT patch can bepulled from kernel.org git repository
For more information regarding PREEMPT_RT refer to kernel.org wiki page
PREEMPT_RT Patch in SDK
PREEMPT_RT patch is applied in the kernel available with this SDK. By default, RT feature is disabled in all the defconfigsof this SDK, except the one mentioned in later section.
Please note that, once one enable RT feature, throughput-performance of the system might decrease (and this decrease isexpected as per design of RT).
Support Status
Hardware: Currently supported only for P4080DS, B4860qds, TWR-LS1021A, LS1012A, LS2080
Software: Linux (with PREEMPT_RT patch), (SMP-Linux: non KVM)
Compilation Option
Default Kernel Defconfig
Kernel Configure Option
Tree view
For enabling RT in defconfig using "make menuconfig" for kernel
Kernel Configure Tree View Options Description
Kernel options ---> Preemption Model (Fully Preemptible Kernel (RT)) ---> (X) Fully Preemptible Kernel (RT)
These options enable RT inLinux.
Identifier
Below are the configure identifiers which are used in kernel source code and default configuration files.
Option Values Default Value to enable RT Description
CONFIG_SLAB y/n y Enable SLAB Support
Table continues on the next page...
Additional Linux Use Cases
Real Time Application Note
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 137
Table continued from the previous page...
Option Values Default Value to enable RT Description
CONFIG_HIGHMEM y/n n Disable highmem support
CONFIG_PREEMPT_RT_FULL y/n y Enable Full RT support
Device Tree Binding
No RT specific changes required
Verification in Linux
To verify that PREEMPT_RT Patch is applied and RT is enabled in Linux configuration after Linux has booted, check Linuxversion on Linux prompt, one should see pattern “PREEMPT RT” in the version string. Eg:
root@bsc913x:~# uname -a
Linux bsc913x 3.8.13-rt6+ #52 PREEMPT RT Wed May 22 12:26:51 IST 2013 ppc GNU/Linux
Test Tool
RT-tests suit contains various test applications like cyclictest, hackbench, etc to measure latencies and induce various testloads. It come as package in yocto (can be build in rootfs) or can be downloaded from kernel.org git repository.
PREEMPT_RT feature provides RTT (Real Time throttling) feature. For details on RTT, refer to
“Documentation/scheduler/sched-rt-group.txt” in Linux source code. RTT might get triggered in
case of heavy traffic leading to high latency. It can be disabled by:
[root@bsc913x]#echo -1 > /proc/sys/kernel/sched_rt_runtime_us
NOTE
Supporting Documentation
https://rt.wiki.kernel.org
Known Limitations
On non-DPAA SoCs like LS1021, LS1021 with PREEMPT_RT enabled kernel, while running IPv4 forwarding benchmarkingscenarios (including the IPSec forwarding benchmark) or pi-stress test-case, which are inherently CPU and traffic intensive,sometimes RCU stalls dumps were observed in dmesg. There is no negative impact on occurrence of this RCU stall dumps,the system continues to run as before.
(For IPv4, IPSEC forwarding test-cases, refer to Benchmark Reproducibility Guides in SDK documentation). Note: TCP/UPDTermination testing does not cause this issue even though CPU utilization is 100%.
Workaround: The above kind of use-case for a real-time device is unlikely. If the above kind of scenario is expected to occurin a device, the device should have some provisions to reduce the CPU load by throttling the low priority jobs.Or limit thetraffic. Or use TCP/UDP terminating type traffic
Additional Linux Use Cases
Real Time Application Note
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016138 NXP Semiconductors
Chapter 8Linux User Space
8.1 OpenSSL Offload User's Guide
8.1.1 OverviewThe Secure Socket Layer (SSL) protocol is the most widely deployed application protocol to protect data during transmissionby encrypting the data using popular cipher algorithms such as AES, DES and 3DES.
Apart from encryption it also provides message authentication services using popular hash/digest algorithms such as SHA1and MD5. SSL is widely used in application web servers (HTTP) and other applications such as SMTP POP3, IMAP, Proxyservers etc., where protection of data in transit is essential for data integrity
There are various version of SSL protocol such as TLSv1, SSLv3 that are commonly used. Other newer versions are available,such as TLSv2, TLSv3 and DTLS (Datagram TLS). Of all the SSL protocol versions, TLSv1 and SSLv3 are in common use.
This document introduces NXP SSL acceleration solution on QorIQ platforms using OpenSSL:
1. OpenSSL software architecture
2. Building OpenSSL with hardware offload support
3. Examples of OpenSSL Offloading
8.1.1.1 OpenSSL Software architectureThe SSL protocol is implemented as a library in OpenSSL - the most popular library distribution in Linux and BSD systems.The OpenSSL library has several sub-components such as:
1. SSL protocol library
2. Crypto library (Symmetric and Asymmetric cipher support, digest support etc.)
3. Certificate Management
The following figure presents the general interconnect architecture for OpenSSL. Each relevant layer is represented with aclear separation between Linux User Space and Linux Kernel Space.
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 139
Figure 2. OpenSSL interface with Linux kernel
8.1.1.1.1 OpenSSL’s ENGINE InterfaceOpenSSL Crypto library provides Symmetric and Asymmetric (PKI) cipher support that is used in a wide variety of applicationssuch as OpenSSH, OpenVPN, PGP, IKE, XML-SEC etc. The OpenSSL Crypto library provides software support for:
1. Cipher algorithms
2. Digest algorithms
3. Random number generation
4. Public Key Infrastructure
Apart from the software support, the OpenSSL can offload these functions to hardware accelerators via the ENGINE interface.The ENGINE interface provides callback hooks that integrate hardware accelerators with the crypto library. The callbackhooks provide the glue logic to interface with the hardware accelerators. Generic offloading of cipher and digests algorithmsthrough Linux kernel is possible with cryptodev engine.
8.1.1.1.2 NXP solution for OpenSSL hardware offloadingThe following layers can be observed in NXP's solution for OpenSSL hardware offloading:
• OpenSSL (user space) - implements the SSL protocol
• cryptodev-engine (user space) - implements the OpenSSL ENGINE interface; talks to cryptodev-linux (/dev/crypto) viaioctls, offloading cryptographic operations in kernel
• cryptodev-linux (kernel space) - Linux module that translates ioctl requests from cryptodev-engine into calls to Linux CryptoAPI
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016140 NXP Semiconductors
• Linux Crypto API (kernel space) - Linux kernel crypto abstraction layer
• CAAM driver (kernel space) - Linux device driver for the CAAM (Cryptographic Acceleration and Assurance Module) cryptoengine
The following are offloaded in hardware in current SDK:
• protocols: TLS v1.0
• cipher modes:
• one-shot (a single ioctl for both encryption and authentication): AES128-SHA, AES256-SHA
• two-shot (two ioctls - one for encryption, the other for authentication): all combinations of AES with SHA1, allcombinations of DES and 3DES with SHA1
8.1.2 Building OpenSSL with hardware offloading support1. Build the fsl-image-core rootfs for ls1012ardb (similar for other platforms); this will automatically deploy OpenSSL
1.0.2h with cryptodev-engine support:
$ bitbake fsl-image-core
2. Boot the board and load the cryptodev kernel module:
root@ls1012ardb:~# modprobe cryptodevcryptodev: driver 1.8 loaded.
3. Check that OpenSSL detected cryptodev:
root@ls1012ardb:~# openssl engine(cryptodev) BSD cryptodev engine(dynamic) Dynamic engine loading support
8.1.3 Nginx offloading with OpenSSLIn this section, a client-server example will be presented. There are two options of testing and validating the OpenSSL TLS1.0 Offloading:
• Web Server running on the NXP QorIQ Board - client (e.g. HTTPS browser) on third party equipment
• Web Server running on a third party equipment, client running on the NXP QorIQ board
Test Scenario 1 is commonly used when a NXP Board is used as an HTTPS server responding to request from various SSLclients (e.g. web browsers). TLS record offload show performance improvement when the HTTPS is used to transfer largeamount of data between server and client.
The examples below use nginx web server and "openssl s_client" utility as client.
Building a custom OpenSSL and a web server
Manually building openssl and nginx is no longer required with NXP SDK full image. For other images (like core or minimal)you just customize the image recipe files to add nginx. Nginx is required only for test scenario 1 and the following line shouldbe added in the bitbake image file (e.g. fsl-image-minimal.bb):
IMAGE_INSTALL += "nginx"
Unlike "openssl s_client", nginx will not use cryptodev by default. To enable cipher offloading through cryptodev, the enginemust be enabled in nginx configuration file. Edit this file for the nginx server in board's filesystem:
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 141
/etc/nginx/nginx.conf:
ssl_engine cryptodev;worker_processes 4;worker_cpu_affinity 0001 0010 0100 1000; #for 4 Core CPU; For 2 Core CPU worker_cpu_affinity 01 10;... # HTTPS server # server { listen 443; server_name localhost;
ssl on; ssl_certificate server.crt; ssl_certificate_key server.key; ssl_session_timeout 5m; ssl_protocols TLSv1; ssl_ciphers AES128-SHA:AES256-SHA; ssl_prefer_server_ciphers on;
location / { root /var/www/localhost/html; index index.html index.htm; } }...
Worker processes and affinity should be set according to the number of CPU cores available on the platform.
Insert cryptodev module and basic checks
Cryptodev must be installed and loaded before testing record layer acceleration. This step is required before openssl or nginxare started.
$ modprobe cryptodevcryptodev: driver 1.8 loaded.$ openssl versionOpenSSL 1.0.2h (...)$ openssl engine(cryptodev) BSD cryptodev engine(dynamic) Dynamic engine loading support
If cryptodev driver is not loaded, openssl will report only dynamic engine support and all operations will be done in user-space without HW acceleration.
If crypto testing module (tcrypt) was built into the kernel, it can be used to check if TLS support is available. This step isoptional however. Kernel algorithms (including TLS) are visible only after their first use. If tcrypt is missing, grep may not showanything:
$ modprobe tcrypt$ grep tls /proc/cryptoname : tls10(hmac(sha1),cbc(aes))driver : tls10-hmac-sha1-cbc-aes-caam
Offloading operations can be monitored with the interrupt counters for CAAM JR interfaces:
root@ls1012ardb:~# cat /proc/interrupts | grep -i jr 28: 2 GIC 103 Level 1710000.jr
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016142 NXP Semiconductors
29: 17835482 GIC 104 Level 1720000.jr 30: 17280913 GIC 105 Level 1730000.jr 31: 0 GIC 106 Level 1740000.jr
Testing TLS
To verify TLS record offload, the minimum setup requires a testing board and a web server with support for TLS1.0, eithernginx, apache, lighttpd. We will use the second test scenario and prepare a 100MB file on server side, and transfer it with anhttps client over the network.
Figure 3. Test setup
Openssl s_client command will be used on NXP board to make the connection with the server:
$ openssl s_client
The command can be scripted and run without further intervention:
$ echo GET /index.html | openssl s_client –connect <server_ip>:443 –cipher AES128-SHA –tls1 –quiet
The option "-quiet" can be removed to see more details about the TLS session.
OpenSSL will use automatically the HW acceleration if cryptodev module is loaded in the kernel. No further configuration isnecessary. If cryptodev module is removed, openssl operations will fall back to software in user-space so this can be usedeffectively to check the hardware support.
8.1.4 Valid TLS Ciphersuites based on TLS protocol versionIn order to avoid compatibility issues cipher suite vs protocol version, the following list (extracted from OpenSSL) representthe compatibility list.
Table 7. OpenSSL CipherSuite Compatibility
CipherSuite TLS ProtocolVersion
SSL_RSA_WITH_NULL_MD5 SSL3.0
SSL_RSA_WITH_NULL_SHA SSL3.0
Table continues on the next page...
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 143
Table 7. OpenSSL CipherSuite Compatibility (continued)
CipherSuite TLS ProtocolVersion
SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL3.0
SSL_RSA_WITH_RC4_128_MD5 SSL3.0
SSL_RSA_WITH_RC4_128_SHA SSL3.0
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL3.0
SSL_RSA_WITH_IDEA_CBC_SHA SSL3.0
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_RSA_WITH_DES_CBC_SHA SSL3.0
SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_DH_DSS_WITH_DES_CBC_SHA SSL3.0
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_DH_RSA_WITH_DES_CBC_SHA SSL3.0
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_DHE_DSS_WITH_DES_CBC_SHA SSL3.0
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_DHE_RSA_WITH_DES_CBC_SHA SSL3.0
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL3.0
SSL_DH_anon_WITH_RC4_128_MD5 SSL3.0
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL3.0
SSL_DH_anon_WITH_DES_CBC_SHA SSL3.0
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL3.0
SSL_FORTEZZA_KEA_WITH_NULL_SHA SSL3.0
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA SSL3.0
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA SSL3.0
TLS_RSA_WITH_NULL_MD5 TLS1.0
TLS_RSA_WITH_NULL_SHA TLS1.0
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS1.0
Table continues on the next page...
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016144 NXP Semiconductors
Table 7. OpenSSL CipherSuite Compatibility (continued)
CipherSuite TLS ProtocolVersion
TLS_RSA_WITH_RC4_128_MD5 TLS1.0
TLS_RSA_WITH_RC4_128_SHA TLS1.0
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS1.0
TLS_RSA_WITH_IDEA_CBC_SHA TLS1.0
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_RSA_WITH_DES_CBC_SHA TLS1.0
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_DES_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_DES_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_DES_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_DES_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS1.0
TLS_DH_anon_WITH_RC4_128_MD5 TLS1.0
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS1.0
TLS_DH_anon_WITH_DES_CBC_SHA TLS1.0
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_RSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_RSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_AES_128_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_AES_256_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS1.0
Table continues on the next page...
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 145
Table 7. OpenSSL CipherSuite Compatibility (continued)
CipherSuite TLS ProtocolVersion
TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_DH_anon_WITH_AES_128_CBC_SHA TLS1.0
TLS_DH_anon_WITH_AES_256_CBC_SHA TLS1.0
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS1.0
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA TLS1.0
TLS_RSA_WITH_SEED_CBC_SHA TLS1.0
TLS_DH_DSS_WITH_SEED_CBC_SHA TLS1.0
TLS_DH_RSA_WITH_SEED_CBC_SHA TLS1.0
TLS_DHE_DSS_WITH_SEED_CBC_SHA TLS1.0
TLS_DHE_RSA_WITH_SEED_CBC_SHA TLS1.0
TLS_DH_anon_WITH_SEED_CBC_SHA TLS1.0
TLS_ECDH_RSA_WITH_NULL_SHA TLS1.0
TLS_ECDH_RSA_WITH_RC4_128_SHA TLS1.0
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_ECDH_ECDSA_WITH_NULL_SHA TLS1.0
TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS1.0
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS1.0
Table continues on the next page...
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016146 NXP Semiconductors
Table 7. OpenSSL CipherSuite Compatibility (continued)
CipherSuite TLS ProtocolVersion
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_ECDHE_RSA_WITH_NULL_SHA TLS1.0
TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS1.0
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS1.0
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS1.0
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS1.0
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1.0
TLS_ECDH_anon_WITH_NULL_SHA TLS1.0
TLS_ECDH_anon_WITH_RC4_128_SHA TLS1.0
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS1.0
TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS1.0
TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS1.0
TLS_RSA_WITH_NULL_SHA256 TLS1.2
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_RSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_RSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS1.2
Table continues on the next page...
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 147
Table 7. OpenSSL CipherSuite Compatibility (continued)
CipherSuite TLS ProtocolVersion
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS1.2
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS1.2
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS1.2
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS1.2
TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS1.2
TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS1.2
TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS1.2
TLS_DH_anon_WITH_AES_256_GCM_SHA384 TLS1.2
Linux User Space
OpenSSL Offload User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016148 NXP Semiconductors
Chapter 9Boot Loaders
9.1 Primary Protected Application (PPA) User's Guide
9.1.1 Introduction
9.1.1.1 Rationale and ScopeThis document is the Specification and Users Guide for a loadable secure services firmware component running in TrustZone.This component, called the Primary Protected Application (PPA), has the following characteristics:
• Is loaded into the secure side of an ARM core early in the boot process
• Remains resident after boot
• Provides secure services for boot software and runtime software
• Contains a Secure Monitor, which controls access to/from the secure world
• Implements services behind a std abstract interface (published by ARM)
• Has the secure world exception vectors and handlers
• Is the focal point for implementing the Platform Security Policy
Each of these will be discussed in detail in the sections that follow. Although secure boot and other boot components suchas bootloaders and bootrom will be mentioned here, this specification is not intended to exhaustively cover secure boot,bootloaders (such as UEFI and U-boot), or bootrom code.
The phrase “secure world’, used heavily in this doc, refers to ARM TrustZone, and vice-versa. The phrase “secure monitor”refers to the ARM v8 definition of a software entity that runs at EL3 and controls access to/from the secure world. Do notconfuse “secure monitor” in this context with “security monitor”, which is a hardware component of the QorIq Trust Architecture.
There are a number of compelling reasons for having a resident secure services layer:
1. The secure services layer is first-and-foremost a focal point for implementation of a Platform Security Policy.
2. ARM cores come out of reset executing in the secure world.
3. The non-secure world needs an agent to perform tasks in the secure world
4. The PSCI interface, which is ARM’s abstract power mgmt interface, runs in the secure world.
5. A resident secure firmware can streamline bootloaders, making it easier to support multiple bootloaders.
6. The PPA is the foundation upon which a deeper TrustZone software stack can be built.
9.1.1.2 References[1] LS1043A SoC Architecture Specification v0.3.0
[2] SMC Calling Convention, ARM Ltd, 2013
[3] ARM Architecture Reference Manual, Armv8 Edition, beta
[4] LS1043 PRL, Revision 0.7
[5] QorIQ Chassis Architecture Specification, Generation 2.1, Revision 0.8
[6] LS1 Trust Architecture, Chapter 10
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 149
[7] Layerscape Chassis Architecture Specification, Generation 3, v0.9
[8] ARM Trusted Firmware Design
[10] LS2 Boot Interfaces Programmers Guide, v1.5
[11] Power State Coordination Interface, ARM Ltd, 2012-2013
9.1.1.3 DefinitionsAP – Application Processor, same as GPP
ATF – ARM Trusted Firmware
Bootloader – FW that loads the OS kernel (uboot, uefi)
ESBC – External Secure Boot Code, image validation code in the bootloader
GPP – General Purpose Processor
ISBC – Internal Secure Boot Code, image validation code in the bootrom
OCRAM – On-Chip RAM
PPA – Primary Protected Application, the secure monitor and associated functions that comprise the base EL3 sw foundation
Protected – Higher-privilege sw, such as a hypervisor
PSCI – Power State Coordination Interface, an ARM std interface
Secure – SW or components that are isolated by the TrustZone architecture
Secure Monitor – the SW running at EL3 that controls the gateway from the non-secure world to the secure world
Security Monitor – a HW feature of the QorIQ Trust Architecture
SCP
SMC – an ARM instruction which generates an exception, and an ARM std interface based on that excepton call
SP – Service Processor, an auxiliary core that performs initial boot functions on the SoC
TPM – Trusted Platform Module, a specification of the Trusted Computing Group
Trusted Architecture (TA) – a security architecture found in the QorIq family of SoCs, including the ARM-based QorIq products
TrustZone (TZ) – an isolation context provided as part of the ARM architecture; an infrastructure for building securesubsystems
9.1.2 Boot Flow Architecture
9.1.2.1 LS1043A/LS1012A Boot Flow
Component Load Sequence
1. GPP Bootrom loads/validates* 1st stage bootloader
2. 1st stage bootloader loads/validates* 2nd stage bootloader
3. 1st stage bootloader loads/validates* PPA
4. 2nd stage bootloader loads/validates* kernel
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016150 NXP Semiconductors
PPA
GPPBootrom
1st StageBootloader*
1
3
2
Secure World Non Secure World
2nd StageBootloader*
4
KernelEL3init
securemonitor
SMCLib
TBD PSCIEL3 boot component
EL2/EL1 boot component
EL3 boot/runtime
EL2/EL1 runtime
Legend * images validated if secure boot enabled
Figure 4. Component Load Sequence
Boot execution Order
1. Execution begins in the PBI State Machine when the SoC comes out of reset
2. After PBI, execution starts with bootcore in GPP bootrom
3. Bootcore branches to 1st stage bootloader running in EL3
4. Bootcore in 1st stage bootloader branches to EL3 init code in PPA
5. When bootcore completes EL3 init, it branches to 2nd stage bootloader in EL2
6. Bootcore in 2nd stage bootloader branches to Linux kernel in EL1
7. Kernel calls PSCI (cpu_on) to release secondary cores (LS1043A only)
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 151
PPA
GPPBootrom
1st StageBootloader*
3
45
Secure World Non Secure World
2nd StageBootloader*
6
KernelEL3init
securemonitor
SMCLib
TBD PSCI
EL3 boot component
EL2/EL1 boot component
EL3 boot/runtime
EL2/EL1 runtime
Legend
7
2
1
PBI StateMachine
SoCreset
Figure 5. Boot Execution Order
Secondary core execution path
1. Execution starts in the GPP bootrom when secondary core released from reset
2. If core is marked to be disabled, core enters power-down sequence in bootrom
3. Cores not disabled branch to EL3 init code in PPA
4. Upon completion of EL3 init, cores branch to start address at EL2 in kernel
LS1012A does not have secondary cores
NOTE
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016152 NXP Semiconductors
PPA
GPPBootrom
1st StageBootloader*
3
4
Secure World Non Secure World
2nd StageBootloader*
Kernel
EL3init
securemonitor
SMCLib
TBD PSCI
EL3 boot component
EL2/EL1 boot component
EL3 boot/runtime
EL2/EL1 runtime
Legend
2
1
corereset
powerdown
Figure 6. Secondary Core Execution Path
9.1.3 Loading and Initializing the PPA• The PPA must be loaded to a 64Kb boundary
• Copy the binary image to the load address – the component installing the PPA MUST be executing at EL3
• PPA should be loaded to an address in secure memory - recommend a 2MB secure region in DDR (but PPA can be testedin non-secure DDR)
• After copying the image file to DDR, clean the data cache by VA (all virtual address ranges affected by PPA load) , andinvalidate the instruction cache
• The PPA initialization runs at EL3 – but the PPA transfers control back to the address loaded in BOOTLOCPTR at EL2 –you must write the start address of the EL2 portion of your bootloader into BOOTLOCPTR before initializing the PPA
• After writing the EL2 start address in BOOTLOCPTR, initialize the PPA by branching to its start address
9.1.4 How to Call SMC/PSCI functions• SMC functions obey the ARM ABI
• SMC functions treat registers x0-x12 as volatile, all others are preserved
• To call an SMC/PSCI function, load the registers according to the table below, then execute an “SMC 0x0” instruction
• If the function specifies a return value, it will be found in register x0
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 153
• Return values, including error returns, are returned in x0
• The “SMC 0x0” instruction generates an exception – after the exception is processed in the secure monitor (when theSMC function has completed), control will return to the instruction following the “SMC 0x0”
• Please refer to [2] for more details of the SMC calling convention
• Note: currently, only SMC “fast calls” are implemented (including PSCI). This means that while the calling core is in thesecure world, interrupts to the core are masked.
SMC input parameters:
Register Meaning
X0 Function ID (see Section 5, 6)
X1 First optional parameter
X2 Second optional parameter
X3 Third optional parameter
SMC return values:
Register Meaning
X0 Return value, Error return code
9.1.5 PSCI Function ListPlease see [11] for details of the PSCI function interface. Keep in mind that the PSCI interface is a subset of the SMC CallingConvention [2].
9.1.5.1 PSCI_VERSIONGet the Version number of this PSCI implementation.
Function ID: 0x8400_0000
Input parameters:
Register Meaning
X0 Function ID
No other inputs
Return values:
Register Meaning
X0 bits[31:16] Major Version Number
X0 bits [15:0] Minor Version Number
Currently, the PSCI v0.2 specification is implemented. Thus, the Major Version Number returned is 0x0, and the Minor VersionNumber returned is 0x2.
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016154 NXP Semiconductors
9.1.5.2 CPU_ONRelease a secondary core from reset, or from the CPU_OFF state.
Function ID: 0xC400_0000
Input Parameters:
Register Meaning
X0 Function ID
X1 Target CPU, in MPIDR format (see [11])
X2 Start address (Physical)
X3 Context ID
Return Values:
Register Return Code (see 5.8)
X0 SUCCESS
“ INVALID_PARAMETERS
“ ALREADY_ON
“ ON_PENDING
“ INTERNAL_FAILURE
When cores are delivered to the Start Address, they will be executing at EL2.
NOTE
9.1.5.3 CPU_OFFPower down the calling core.
Function ID: 0x8400_0002
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
Register Return Code (see 5.8)
Function does not return if successful
X0 DENIED
Note that this function is called on the core that is to be powered down. There is no mechanism to power down one core fromanother core. By definition, a power-down state is a state without retention, so the caller must save whatever state is neededwhen the core resumes execution.
The only way to restart a core after a call to CPU_OFF is with a call to CPU_ON.
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 155
If successful, this function does not return.
9.1.5.4 CPU_SUSPENDPut the calling core/cluster/system into a low-power state.
Function ID: 0xC400_0001
Input Parameters (see [11]):
Register Meaning
X0 Function ID
X1 Power_State
X2 Start_Address (Physical)
X3 Context_Id
Return Values:
Register Return Code (see 5.8)
X0 SUCCESS
“ INVALID_PARAMETERS
Note that this function is called on the core/cluster/system that is to be suspended. There is no mechanism to suspend onecore from another core. There are two available power states, Standby and Power-Down (see [11]).
For cluster low-power states, all cores of the cluster except this final core must already be in the requested power state. Thefunction checks to see if this is the “last core standing” of the cluster – if it is the last core, the core is suspended along withthe cluster. If this function is called when there is more than one active core in the cluster, the function will return with theINVALID_PARAMETERS value in x0.
Likewise for system power-down, the function checks to see if this is the last active gpp core in the SoC. If it is the last activecore, then the core is suspended along with the SoC. If it is not the last active core, then the function returns with the errorvalue INVALID_PARAMETERS in x0.
The input parameters to this function describe a complex interface. Please see [11] for details of how to use this function call.
If successful, this function does not return.
9.1.5.5 AFFINITY_INFOGet information about a specific affinity level.
Function ID: 0xC400_0004
Input Parameters (see [11]):
Register Meaning
X0 Function ID
X1 Target_Affinity
X2 Lowest_Affinity
Return Values:
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016156 NXP Semiconductors
Register Return Codes (see 5.8, 5.8.1)
X0 ON_PENDING
“ OFF
“ ON
“ INVALID_PARAMETERS
“ NOT_PRESENT
“ DISABLED
9.1.5.6 SYSTEM_OFFPower down the entire system.
Function ID: 0x8400_0008
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
The function does not return.
9.1.5.7 SYSTEM_RESETPerform a hard reset on the entire system.
Function ID: 0x8400_0009
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
The function does not return.
9.1.5.8 PSCI Return Code Values
Mnemonic Value
SUCCESS 0
NOT_SUPPORTED -1
INVALID_PARAMETERS -2
DENIED -3
Table continues on the next page...
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 157
Table continued from the previous page...
ALREADY_ON -4
ON_PENDING -5
INTERNAL_FAILURE -6
NOT_PRESENT -7
DISABLED -8
PSCI Return Codes Specific to Affinity_Info
Mnemonic Value
ON 0
OFF 1
ON_PENDING 2
9.1.5.9 PSCI Functions Implemented, by SoC
LS1012A
CPU_ON N/A
CPU_OFF N/A
AFFINITY_INFO
CPU_SUSPEND WIP
PSCI_VERSION
SYSTEM_RESET
SYSTEM_OFF X
9.1.6 SMC Function ListPlease see [2] for details of the SMC function interface.
9.1.6.1 Function Count - SMC64Return the number of functions implemented by the smc64 interface, including this function and PSCI functions using thisinterface.
Uses smc64 interface.
Function ID: 0xC200_FF00
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016158 NXP Semiconductors
Register Value
X0 Smc64 function count
9.1.6.2 Function Count - SMC32Return the number of functions implemented by the smc32 interface, including this function and PSCI functions using thisinterface.
Uses smc32 interface.
Function ID: 0x8200_FF00
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
Register Value
X0 Smc32 function count
9.1.6.3 Get UUIDReturn the 128-bit UUID uniquely identifying this SMC implementation.
Uses the smc32 interface.
Function ID: 0x8200_FF01
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
Register Value
X0 Bytes [3:0] of UUID
X1 Bytes [7:4] of UUID
X2 Bytes [11:8] of UUID
X3 Bytes [15:12] of UUID
9.1.6.4 Get RevisionReturn the major and minor revision numbers of the SIP portion of this SMC implementation.
Uses smc32 interface.
Function ID: 0x8200_FF03
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 159
Input Parameters:
Register Meaning
X0 Function ID
Return Values:
Register Value
X0 Major revision number of sip-smc
X1 Minor revision number of sip-smc
9.1.7 Building the PPAIn the SDK, the PPA image will be built as part of the Yocto recipe.
9.1.8 System Considerations When Calling SMC & PSCIFunctions
There is always the possibility that malware will attempt to execute an SMC. The affects of this may be mitigated with threemethods:
1. Insure that calling an smc/psci function can never corrupt the machine
2. Insure that calling an smc/psci function can never lower the security stance of the machine
3. Provide only one place in the system, a kernel driver, from which all smc calls are made
Items (1) & (2) mean that even if malware successfully makes an smc call, the effects of that call will not open the system upto an attack. Take careful note of item (2) – this means that any EL3 configuration that lowers the security of the system mustbe set in the PPA initialization phase, and not as a dynamic smc function.
Item (3) allows the PPA to determine if an unauthorized access has been attempted. Since the smc call generates anexception, the register ELR_EL3 is loaded, by hw, with the return address of the caller. If there is only one place in the systemwhere smc calls are made from, then the PPA can be configured to register the return address. Malware, attempting to makean smc call, will have a different return address. The secure monitor in the PPA can detect this different return address, andreject the request. In addition, the secure monitor can return to the authorized return address with a security violation error.To enable this capability in later revisions of the PPA, the kernel developer should implement a kernel driver where all smccalls are made from.
Boot Loaders
Primary Protected Application (PPA) User's Guide
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016160 NXP Semiconductors
Non-secure World Secure World
EL1secure access driver
malware
SMC
SMC
illegal access attempttrapped by PPA
PPAexception
return address
security error returned toregistered access point
EL3
Figure 7. System Considerations When Calling SMC and PSCI Functions
9.2 Secure Boot: PBL Based Platforms
9.2.1 IntroductionThis document is intended for end-users to demonstrate the image validation process. The image validation can be split intostages, where each stage performs a specific function and validates the subsequent stage before passing control to thatstage. In the example, the ESBC is Freescale provided reference code referred to as ESBC uboot.
Chain ofTrust
ESBC uboot performs minimal SoC configuration before validating the Next Executable using the sameCSF header format as the ISBC used to validate ESBC Uboot. The CSF Header and signature are addedto the Next Executable using the Freescale Code Signing Tool.
Figure 8. Chain of Trust
Chain of Trust withconfidentiality
The validated ESBC uboot image is allowed to use the One Time Programmable MasterKey to decrypt system secrets. Cryptographic blob mechanism is used to establish Chainof trust with confidentiality.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 161
Figure 9. Chain of Trust with confidentiality
This document provides more details on the secure boot flow, ISBC, ESBC and Freescale Code signing tool.
9.2.2 Secure boot ProcessSecure boot process uses a digital signature validation routine already present in INTERNAL BOOT ROM. This routineperforms validation using HW bound RSA public key to decrypt the signed hash and compare it to a freshly calculated hashover the same system image. If the comparison passes, the image can be considered as authentic.
The complete process can be broken down into following phases:
• Pre Boot Phase
1. PBL
2. SFP
• ISBC
• ESBC
The Complete Secure boot Process is shown in the Figure below.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016162 NXP Semiconductors
Figure 10. Secure Boot Process
9.2.3 Pre-Boot PhaseWhen the processor is powered on, reset control logic blocks all device activity (including scan and debug activity) until fusevalues can be accurately sensed. The most important fuse value at this stage of operation is the ‘Intent to Secure’ (ITS) bit.When an OEM sets ITS, they intend for the system to operate in a secure and trusted manner.
The two main components involved during this process are :
The security fuse processor (SFP) has two roles. The first is to physically burn fuses during device provisioning. The secondis to use these provisioned values to enforce security policy in the pre-boot phase, and to securely pass provisioned keysand other secret values to other hardware blocks when the system is in a trusted/secure state.
PreBoot Loader (PBL) is the micro-sequencer that can simplify system boot by configuring the DDR memory controllers tomore optimal settings and copying code and data from low speed memory into DDR. This allows subsequent phases of bootto operate at higher speed. The setting of ITS determines where the PBL is allowed to read and write. The use of the PBL ismandatory when performing secure boot. At a minimum, the PBL must read a command file from a location determined bythe Reset Configuration Word (RCW) and perform a store of a value to the ESBC Pointer Register within the SoC. If the PBLdoesn’t perform this operation (or sets the ESBC pointer to the wrong value), the ISBC will fail to validate the ESBC. Oncethe PBL has completed any operations defined by its command file, the PBL is disabled until the next Power on Reset andthe Boot Phase begins.
Some example PBI commands used in the demo are given below. The commands are embedded in the RCW's mentionedin the SDK Images required for the demo
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 163
NOR SECURE BOOT
• P3/P4/P5
#LAW for ESBC 09000cd0 00000000 09138000 00000000 (Flush command) 09000cd4 c0000000 09138000 00000000 (Flush command) 09000cd8 81f0001d 09138000 00000000(FLUSH command)# Scratch Register 090e0200 c0b00000
• T1/T2/T4/B4
#LAW for ESBC 09000c10 00000000 09000c14 c0000000 09000c18 81f0001b# LAW for CPC/SRAM 09000d00 00000000 09000d04 bff00000 09000d08 81000013 # Scratch Registers 090e0200 c0b00000 090e0208 c0c00000 # CPC SRAM 09010100 00000000 09010104 bff00009 # CPC Configuration 09010f00 08000000 09010000 80000000
NAND SECURE BOOT
• P3/P5
# SCRATCH REGISTER 090e0200 bff00000 09138000 00000000 (Flush Command)# CPC1 SRAM 09010000 00200400 09010100 00000000 09010104 bff0000b 09010f00 08000000 09010000 80000000 09138000 00000000 (Flush Command)# LAW for CPC/SRAM 09000d00 00000000 09000d04 bff00000 09000d08 81000013 09138000 00000000 (Flush Command)# Alternate Configuration Space Configuration 09000010 00000000 09000014 bf000000 09000018 81000000 09138000 00000000 (Flush Command)# CPC2 Cache 09110000 80000403
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016164 NXP Semiconductors
09110020 2d170008 09110024 00100008 09110028 00100008 0911002c 00100008 09138000 00000000 (Flush Command)
/* hdr_uboot.out and u-boot.bin must also be loaded on NAND * ALT_CONFIG_WRITE command must be used for the same. * Starting offset for ALT_CONFIG_WRITE command would be * hdr_uboot.out - 0xf00000 * u-boot.bin - 0xf40000 */
The ISBC is capable of reading from NOR flash connected to the Local Bus, on-chip memory configured as SRAM, or mainmemory. Unless the ESBC is stored in NOR flash, the developer is required to create a PBL Image that copies the image tobe validated from NVRAM to main memory or internal SRAM prior to writing the SCRATCHRW1 Register and executing theISBC code.
To assist with the creation of PBL Images (for both normal and Trust systems), Freescale offers a PBL Image Tool.
Note that it is possible for an attacker to modify the board to direct the PBL to the wrong non-volatile memory interface, orchange the PBL Image and CSF Header pointer, however this will result in a secure boot failure and the system remainingin an idle loop indefinitely.
9.2.4 ISBC Phase9.2.4.1 Flow in the ISBC CodeWith the PBL disabled and all external masters blocked by the PAMUs, CPU 0 is released from boot hold-off and beginsexecuting instructions from a hardwired location within the Internal BootROM. The instructions inside the Internal BootROMare Freescale developed code known as the Internal Secure Boot Code (ISBC). The ISBC leads CPU 0 to perform thefollowing actions:
1. Who am I check? - CPU 0 reads its Processor ID Register, and if it finds any value besides physical CPU 0, the CPUenters a loop. This insures that only CPU 0 executes the ISBC.
2. Sec_Mon check - CPU 0 confirms that the Sec_Mon is in the Check state. If not, it writes a ‘fail’ bit in a Sec_Mon controlregister, leading to a state transition.
3. ESBC pointer read - CPU 0 reads the ESBC Pointer Register, and then reads the word at the indicated address, whichis the first word of the Command Sequence File Header which precedes the ESBC itself. If the contents of the word don’tmatch a hard coded preamble value, the ISBC takes this to mean it has not found a valid CSF and cannot proceed. Thisleads to a fail, as described in #2 above.
4. CSF parsing and public key check - If CPU 0 finds a valid CSF header, it parses the CSF header to locate the publickey to be used to validate the code. There can be a single public key or a table of 4 public keys present in the header.The Secure Fuse Processor doesn’t actually store a public key, it stores a SHA-256 hash of the public key/table of 4 keys.This is done to allow support for up to 4096b keys without an excessively large fuse block. If the hash of the public keyfails to match the stored hash, secure boot fails.
5. Signature validation - With the validated public key, CPU 0 decrypts the digital signature stored with the CSF header.The ISBC then uses the ESBC lengths and pointer fields in the CSF header to calculate a hash over the code. The ISBCchecks that the CSF header is included in the address range to be hashed. Option flags in the CSF header tell the ISBCwhether the Freescale Unique ID and the OEM Unique ID (in the Secure Fuse Processor) are included in the hashcalculation. Including these IDs allows the image to be bound to a single platform. If the decrypted hash and generatedhash don’t match, secure boot fails.
6. ESBC First Instruction Pointer check - One final check is performed by the ISBC. This check confirms that the FirstInstruction Pointer in the CSF header falls within the range of the addresses included in the previous hash. If the pointer
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 165
is valid, the ISBC writes a ‘PASS’ bit in a Sec_Mon command register, the state machine transitions to ‘Trusted’, and theOTPMK is made available to the SEC.
7. In case of failure , for Trust v2.0 devices , secondary flag is checked in the CSF header. If set, ISBC reads the CSF headerpointer form SCRATCHRW3 location and repeats from step 4.
There are many reasons the ISBC could fail to validate the ESBC. Technicians with debug access can check theSCRATCHRW2 Register to obtain an error code. For a list of error codes refer ISBC Validation Error Codes.
9.2.4.2 Super Root keys (SRKs) and signing keysThese are RSA public and private key pairs. Private keys are used to sign the images and public keys are used to validatethe image during ISBC and ESBC phase.
Public keys are embedded in the header and the hash of srk table is fused in SRKH register of SFP.
These are Hardware Bound Keys, once the hash is fused the public private key pair can't be modified.
Keys of sizes 1k, 2k and 4k are supported in FSL Secure Boot Process.
It is the OEM’s responsibility to tightly control access to the RSA private signature key. If this key is ever exposed, attackerswill be able to generate alternate images that will pass secure boot.
If this key is ever lost, the OEM will be unable to update the image.
9.2.4.3 Key RevocationTrust Architecture 2.0 introduces support for revoking the RSA public keys used by the ISBC to verify the ESBC. The RSApublic keys used for this purpose are called super root keys.
OEM can use either a single key or a list of upto 4 super root keys in the Trust Arch v2.0 devices.
In the Freescale Code Signing Tool (CST), the OEM defines whether the device uses a single super root key, or offers a listof super root keys. If using a single super root key, a new flag bit in the CSF header will indicate “Key”, otherwise the flag willindicate “Key List”. Assuming key list, the OEM can populate a list of up to 4 super root keys for trust arch v2.0 onwardsplatforms . And calculates a SHA-256 hash over the list. This hash is written to the SRKH registers in the SFP.
As part of code signing, the OEM defines which key in the key list is to be used for validating the image. This key number isincluded as a new field in the CSF header.
During secure boot, the ISBC determines whether a key list is in use. If the key list is valid, the ISBC checks the key numberindicated in the CSF header against the revocation fuses in the SFP’s OEM Security Policy Register (SFP_OSPR). If the keyis revoked, the image validation fails.
In order to prevent unauthorized revocation of keys, SFP provides a bit (Write Disable). If the bit is
set, the Key revocation bits cannot be written to.
In regular operation, the ESBC (early Trusted S/W) needs to set the SFP Write Disable bit. When
circumstances call for revoking a key, the OEM will use an ESBC image with “Write Disable” bit not
set. So, the SFP will be in a state in which key revocation fuses can be set.
Logically after revoking the required key(s), the OEM would then load a new signed ESBC image
with code to set the "Write Disable" bit, with new CSF header indicating which of the remaining
non-revoked key to use.
So, only the possessor of a legitimate RSA private key can enable key revocation.
NOTE
One possible motivation for an OEM to revoke a super root key is the loss of the associated RSA private key to an attacker.If the attacker has gained access to a legitimate RSA private key, and the attacker can turn on power to the fuse programmingcircuitry, then the attacker could maliciously revoke keys. To prevent this from being used to permanently disable the system,one super root key does not have an associated revocation fuse.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016166 NXP Semiconductors
9.2.4.4 Alternate Image SupportTrust 2.0 onwards will support a primary and alternate image, where failure to find a valid image at the Primary location willcause the ISBC to check a configured alternate location.
To execute, the alternate image must be validated using a non-revoked public key as defined by its CSF Header. A validalternate image has same rights and privileges as a valid primary image.
This feature helps to reduce risk of corrupting single valid image during firmware update or as a result of Flash block wear-out.
To enable this feature, create PBI with pointers for both Primary and Alternate Images (HW PBL uses SCRATCHRW1 &SCRATCHRW3).
9.2.4.5 ESBC with CSF HeaderESBC is the generic name for the code that the ISBC validates. A few ESBC scenarios are described in later sections.
The figure below provides an example of an ESBC with CSF (Command Sequence File) Header. The CSF Header includeslengths and offset which allow the ISBC to locate the operands used in ESBC image validation, as well as describe the sizeand location of the ESBC image itself.
Note: CSF Header and ESBC Header may be used synonymously in this and other Freescale Trust Architecturedocumentation.
Figure 11. ESBC with CSF Header
9.2.5 ESBC PhaseUnlike the ISBC, which is in an internal ROM and therefore unchangeable, the ESBC is Freescale-supplied referencecode, and can be changed by OEMs. The remainder of this section is the description of a reasonable secure boot chain oftrust based on Freescale's reference software for secure boot. Depending on the requirement, ESBC can be a monolithicimage - including uboot, device trees, boot firmware, drivers along with the OS and applications or can be mini-uboot.
Freescale provided ESBC consists of standard u-boot which has been signed using a private key. U-boot reserves a smallspace for storing environment variables. This space is typically one sector above or below the u-boot and is stored onpersistent storage devices like NOR flash if macro CONFIG_ENV_IS_IN_FLASH is used. In case of secure boot, macro
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 167
CONFIG_ENV_IS_NOWHERE is used and so, environment is compiled in uboot image and is called default environment.This default environment can't be stored on flash devices. User won't be able to edit this environment also as he can't reachto uboot prompt in case of secure boot. There is default boot command for secure boot in this default environment whichexecutes on autoboot.
ESBC validates a file called boot script and on successful validation execute the commands in the boot script.
There are many reasons ESBC could fail to validate Client images or boot script. The error status message along with thecode is printed on the u-boot console. For a list of error codes refer ESBC Validation Error Codes.
Users are free to use Freescale ESBC as it is provided or to use it as reference to modify their own secure boot system.
On Soc's with ARMv8 core (eg:- LS1043, LS1012), during ISBC phase in Internal Boot ROM, SMMU
(which by default is in by-pass mode) is configured to allow only secure transactions from CAAM.
The security policy w.r.t. SMMU in ESBC phase must be decided by the user/customer. So,
currently in ESBC (U-Boot), SMMU is configured back to by-pass mode allowing all transactions
(secure as well as non-secure).
NOTE
9.2.5.1 Boot scriptBootscript is a U-Boot script image which contains u-boot commands. ESBC would validate this boot script before executingcommands in it.
1. Boot script can have any commands which u-boot supports. No checking on the allowed
commands in boot script. Since it is validated image, assumption is that commands in boot
script would be correct.
2. If some basic scripting error done in boot script like unknown command, missing arguments,
the required usage of that command and core is put in infinite loop.
3. After execution of commands in boot script, if control reaches back in u-boot, error message
would be printed on u-boot console and core would be put in spin loop by command esbc_halt.
4. Scatter gather images not supported with validate command.
5. If ITS fuse is blown, any error in verification of the image would result in system reset. The error
would be printed on console before system goes for a reset.
NOTE
9.2.5.1.1 Where to place the boot script?Freescale's ESBC u-boot expects the boot script to be loaded in flash as specified in address map for different platformsunder the topic 'Appendix <platform> Secure Boot Demo'. ESBC u-boot code assumes that the public/private key pair usedto sign the boot script is same as that was used while signing the u-boot image. If user used different key pair to sign theimage, hash of the N and E component of the key pair should be defined in macro:
CONFIG_BOOTSCRIPT_KEY_HASH.
Note - The hash defined should be hex value, 256 bits long.
Both the above macros can be defined or changed in the configuration file secure_boot.h at the following location in u-bootcode:
u-boot/arch/powerpc//include/asm/fsl_secure_boot.h
Two new commands called esbc_validate and esbc_halt have been added in Freescale ESBC u-boot.
9.2.5.1.2 Chain of TrustBoot script contains information about the next level of images, e.g. Linux, HV, etc. ESBC validates these images as per theirpublic keys and then executes bootm command to pass-on the control to next image.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016168 NXP Semiconductors
Users are free to use Freescale ESBC as it is provided or to use it as reference to modify their own secure boot system.
Figure below shows the Chain of trust established for Validation with this ESBC u-boot.
Figure 12. Secure boot flow (Chain of Trust)
9.2.5.1.2.1 Sample Boot ScriptA sample boot script would look like:
... esbc_validate <Img1 header addr> <pub_key hash> esbc_validate <Img2 header addr> <pub_key hash> esbc_validate <Img3 header addr> <pub_key hash> ... bootm <img1 addr> <img2 addr> <img3 addr>
9.2.5.1.2.1.1 esbc_validate commandesbc_validate img_hdr [pub_key_hash]
Input arguments:
img_hdr - Location of CSF Header of the image to be validated
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 169
pub_key_hash - hash of the public key used to verify the image. This is optional parameter. If not provided, code makes theassumption that the key pair used to sign the image is same as that used with ISBC. So the hash of the key in the header ischecked against the hash available in SRK fuse for verification.
Description:
The command would do the following:
• Perform CSF header validation on the address passed in the image header. During parsing of the header, imageaddress in stored in an environment variable which is later used in source command in default secure boot command.
• Signature checks on the image
9.2.5.1.2.1.2 esbc_halt commandesbc_halt (no arguments)
Description:
The command would do the following:
This command puts core in spin loop.
After successful validation of images, bootm command in bootscript should execute and control should never reach back touboot. If somehow, control reaches back to uboot (eg. bootm not present in bootscript), core should just spin.
9.2.5.1.3 Chain of Trust with ConfidentialityTo establish chain of trust with confidentiality, cryptgraphic blob mechanism can be used. In this chain of trust, validatedimage is allowed to use the One Time Programmable Master Key to decrypt system secrets.
Two bootscripts are to be used. First encap bootscripts is used which creates a blob of the LINUX images and saves them.After this the system is booted after replacing the encap bootscript with decap bootscript which decapsulates the blobs andboot the LINUX with the images.
Figures below show the Chain of trust with confidentiality (Encapsulation and Decapsulation).
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016170 NXP Semiconductors
Figure 13. Chain of Trust with Confidentiality (Encapsulation)
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 171
Figure 14. Chain of Trust with Confidentiality (Decapsulation)
9.2.5.1.3.1 Sample Encap Boot ScriptA sample encap boot script would look like:
...blob enc <Img1 addr> <Img1 dest addr> <Img1 size> <key_modifier address> erase <encap Img1 addr> +<encap Imag1 size>cp.b <Img1 dest addr> <encap Img1 addr> <encap Imag1 size>
blob enc <Img2 addr> <Img2 dest addr> <Img2 size> <key_modifier address> erase <encap Img2 addr> +<encap Imag2 size>cp.b <Img2 dest addr> <encap Img2 addr> <encap Imag2 size>
blob enc <Img3 addr> <Img3 dest addr> <Img3 size> <key_modifier address> erase <encap Img3 addr> +<encap Imag3 size>cp.b <Img3 dest addr> <encap Img3 addr> <encap Img3 size>
...
9.2.5.1.3.1.1 blob enc commandblob enc <src location> <dst location> <length> <key_modifier address>
Input arguments:
src location - Address of the image to be encapsulated
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016172 NXP Semiconductors
dst location - Address where the blob will be created
length - Size of the image to be encapsulated
key_modifier address - Address where a random number 16 bytes long(key modifier) is placed
Description:
The command would do the following:
• Create a cryptographic blob of the image placed at src location and place the blob at dst location.
9.2.5.1.3.2 Sample Decap Boot ScriptA sample decap boot script would look like:
...blob dec <Img1 blob addr> <Img1 dest addr> <expected Img1 size> <key_modifier address> blob dec <Img2 blob addr> <Img2 dest addr> <expected Img2 size> <key_modifier address> blob dec <Img3 blob addr> <Img3 dest addr> <expected Img3 size> <key_modifier address> ...bootm <Img1 dest addr> <Img2 dest addr> <Img3 dest addr>
9.2.5.1.3.2.1 blob dec commandblob dec <src location> <dst location> <length> <key_modifier address>
Input arguments:
src location - Address of the image blob to be decapsulated
dst location - Address where the decapsulated image will be placed
length - Expected Size of the image after decapsulation.
key_modifier address - Address where key modifier (Same as that used for Encapsulation) is placed
Description:
The command would do the following:
• Decapsulate the blob placed at src location and place the decapsulated data of expected size at dst location.
9.2.6 Next Executable (Linux Phase)The bootloader (ESBC) finishes the platform initialization and passed control to the Linux image. The boot-chain can befurther extended to be able to sign application which would be running on Linux prompt. Further RTIC can be integrated toverify memory regions using Security Engine (SEC) during run time.
9.2.7 CST Tool9.2.7.1 KEY GENERATION9.2.7.1.1 gen_keysThis utility generates a RSA public and private key pair using OPENSSL APIs. The key pair consists of 3 parts: N, E and D.
N – Modulus
E – Encryption exponent
D – Decryption exponent
Public Key - It is a combination of E and N components.
Private Key - It is a combination of D and N components.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 173
It is the OEM’s responsibility to tightly control access to the RSA private signature key. If this key is ever exposed, attackerswill be able to generate alternate images that will pass secure boot. If this key is ever lost, the OEM will be unable to updatethe image.
Features
• The application allows the user to generate 3 sizes keys. The sizes allowed are - 1024 bits, 2048 bits and 4096 bits.
• It generates RSA key pairs in PEM format.
• Keys are generated and stored in the files. User can provide filenames through command line option.
Usage
./gen_keys [OPTION] SIZE
SIZE refers to size of public key in bits. (Modulus size).
Sizes supported -- 1024, 2048, 4096. The generated keys would be in PEM format.
Options:
-h,--help Usage of the command
-k,--pubkey File where Public key would be stored in PEM format(default = srk.pub)
-p,--privkey File where Private key would be stored in PEM format(default = srk.priv)
Usage Example
$ ./gen_keys 1024
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Generated SRK pair stored in : PUBLIC KEY srk.pub PRIVATE KEY srk.pri
$ ./gen_keys 4096 -k my.pub -p my.pri
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016174 NXP Semiconductors
Generated SRK pair stored in : PUBLIC KEY my.pub PRIVATE KEY my.pri
9.2.7.1.2 gen_drv_drbgThis utility in the Code Signing Tool inserts hamming code in a user defined 64b hexadecimal string, or generate a 64bhexadecimal random number and inserts the hamming code in it which can be used as Debug Response Value.
For random number generation, Hash_DRBG library is used. The Hash_DRBG is an
implementation of the NIST approved DRBG(Deterministic Random Bit Generator), specified in
SP800-90A. The entropy source is the Linux /dev/random.
NOTE
Features:
• Generates random numbers, which can be used if user defined string is not provided, to generate Debug Responsevalue.
• Calculates and embeds the hamming code in the hexadecimal string.
Usage:
./gen_drv_drbg <Hamming_algo> [string]
Hamming_algo : Platforms
A1 : T10xx, T20xx, T4xxx, P4080rev1, B4xxx
A2 : LSx
B : P10xx, P20xx, P30xx, P4080rev2, P4080rev3, P50xx, BSC913x, C29x
string : 8 byte string
In case string is not specified, the utility generates an 8 byte random number and embeds hamming code in it.
Usage Example:
$ ./gen_drv_drbg A2
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
Input string not providedGenerating a random string-------------------------------------------* Hash_DRBG library invoked* Seed being taken from /dev/random-------------------------------------------Random Key Genearted is:f4bfc65e16284dbbDRV[63:0] after Hamming Code is:f4bfc65f16294daf NAME | BITS | VALUE _________|______________|____________
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 175
DRV 0 | 63 - 32 | f4bfc65f DRV 1 | 31 - 0 | 16294daf
$ ./gen_drv_drbg A2 1652afe595631dec
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
DRV[63:0] after Hamming Code is:1652afe495631cea NAME | BITS | VALUE _________|______________|____________DRV 0 | 63 - 32 | 1652afe4 DRV 1 | 31 - 0 | 95631cea
9.2.7.1.3 gen_otpmk_drbgThis utility in the Code Signing Tool inserts hamming code in a user defined 256b hexadecimal string, or generate a 256bhexadecimal random number and inserts the hamming code in it which can be used as OTPMK value.
For random number generation, Hash_DRBG library is used. The Hash_DRBG is an
implementation of the NIST approved DRBG(Deterministic Random Bit Generator), specified in
SP800-90A. The entropy source is the Linux /dev/random.
NOTE
Features:
• Generates random numbers, which can be used if user defined string is not provided, to generate OTPMK value.
• Calculates and embeds the hamming code in the hexadecimal string.
Usage:
./gen_otpmk_drbg <bit_order> [string]
<bit_order> : (1 or 2) OTPMK Bit Ordering Scheme in SFP
1 : BSC913x, P1010, P3, P4, P5, C29x
2 : T1, T2, T4, B4, LSx
<string> : 32 byte string
In case string is not specified, the utility generates a 32 bytes random number and embeds hamming code in it.
Usage Example:
$ ./gen_otpmk_drbg 2
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
Input string not providedGenerating a random string-------------------------------------------* Hash_DRBG library invoked
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016176 NXP Semiconductors
* Seed being taken from /dev/random-------------------------------------------OTPMK[255:0] is:3feac02ce3583ad9077ab70f3a398cd71955f8bffa3191428cb25bb6bffb3113
NAME | BITS | VALUE _________|______________|____________OTPMKR 0 | 255-224 | 3feac02c OTPMKR 1 | 223-192 | e3583ad9 OTPMKR 2 | 191-160 | 077ab70f OTPMKR 3 | 159-128 | 3a398cd7 OTPMKR 4 | 127- 96 | 1955f8bf OTPMKR 5 | 95- 64 | fa319142 OTPMKR 6 | 63- 32 | 8cb25bb6 OTPMKR 7 | 31- 0 | bffb3113
$ ./gen_otpmk_drbg 2 1234567856485626a6f6e6174858583847720673534a8958c983774b848438fe
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
OTPMK[255:0] is:ce3c563856584664a6b66617485a5e3d46720673534a8958c983774b848438fe
NAME | BITS | VALUE _________|______________|____________OTPMKR 0 | 255-224 | ce3c5638 OTPMKR 1 | 223-192 | 56584664 OTPMKR 2 | 191-160 | a6b66617 OTPMKR 3 | 159-128 | 485a5e3d OTPMKR 4 | 127- 96 | 46720673 OTPMKR 5 | 95- 64 | 534a8958 OTPMKR 6 | 63- 32 | c983774b OTPMKR 7 | 31- 0 | 848438fe
9.2.7.2 CSF Header Generationuni_sign tool can be used for the following functions :
• CSF header generation along with signature for both ISBC and ESBC phase
• CSF header generation without signature if private key is not provided
Usage:
If INPUT file does not have ESBC = 1, uni_sign invokes create_hdr_isbc else it will invoke create_hdr_esbc
To view usage of tool:
$ ./uni_sign --help
#----------------------------------------------------# #------- -------- -------- -------# #------- CST (Code Signing Tool) Version 2.0 -------# #------- -------- -------- -------# #----------------------------------------------------#
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 177
Correct Usage of Tool is:
./create_hdr_isbc [options] <input_file> --verbose Display header Info after Creation --hash Print the SRK(Public key) hash. --img_hash Header is generated without Signature. Image Hash is stored in a separate file. --help Show the Help for Tool Usage.
<input_file> Contains all information required by tool
************************************************************** uni_sign is a wrapper script over the TOOL* Correct Usage (Description as specified above):** ./uni_sign [options] <input_file>**************************************************************
9.2.7.2.1 Default UsageWhen uni_sign is executed without any option i.e. only providing the input file as the argument, it parses the required fieldsfrom the input file and creates the CSF header as described in 5.2 along with the Public Key/ SRK Hash, Digital Signatureand SG Table to create a combined binary.
Usage :: $./uni_sign <input_file>
Example
$ ./uni_sign input_uboot_secure
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Key Hash :9288723a0253229000a70bcbaa9d3aa1acb70f6369e1e81c9225319d9a364e2a
HEADER file hdr_uboot.out created
9.2.7.2.1.1 Sample Input File and OutputSample input file to generate CSF Header is as follows –
---------------------------------------------------# Specify the platform. [Mandatory]# Choose Platform - 1010/1040/2041/3041/4080/5020/5040/9131/9132/9164/4240/C290PLATFORM=4240# ESBC Flag. Specify ESBC=0 to sign u-boot and ESBC=1 to sign ESBC images.(default is 0)ESBC=0---------------------------------------------------# Entry Point/Image start address field in the header.[Mandatory]# (default=ADDRESS of first file specified in images)ENTRY_POINT=cffffffc---------------------------------------------------
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016178 NXP Semiconductors
# Specify the file name of the keys seperated by comma.# The number of files and key select should lie between 1 and 4 for 1040 and C290.# For rest of the platforms only one key is required and key select should not be provided.
# USAGE (for 4080/5020/5040/3041/2041/1010/913x): PRI_KEY = <key1.pri># USAGE (for 1040/C290/9164/4240): PRI_KEY = <key1.pri>, <key2.pri>, <key3.pri>, <key4.pri>
# PRI_KEY (Default private key :srk.pri) - [Optional]PRI_KEY=srk.pri# PUB_KEY (Default public key :srk.pub) - [Optional]PUB_KEY=srk.pub# Please provide KEY_SELECT(between 1 to 4) (Required for 1040/C290/9164/4240 only) - [Optional]KEY_SELECT=---------------------------------------------------# Specify SG table address, only for (2041/3041/4080/5020/5040) with ESBC=0 - [Optional]SG_TABLE_ADDR=---------------------------------------------------# Specify the target where image will be loaded. (Default is NOR_16B) - [Optional]# Only required for Non-PBL Devices (1010/1040/9131/9132i/C290)# Select from - NOR_8B/NOR_16B/NAND_8B_512/NAND_8B_2K/NAND_8B_4K/NAND_16B_512/NAND_16B_2K/NAND_16B_4K/SD/MMC/SPIIMAGE_TARGET=---------------------------------------------------# Specify IMAGE, Max 8 images are possible. DST_ADDR is required only for Non-PBL Platform. [Mandatory]# USAGE : IMAGE_NO = {IMAGE_NAME, SRC_ADDR, DST_ADDR}IMAGE_1={u-boot.bin,cff40000,ffffffff}IMAGE_2={,,}IMAGE_3={,,}IMAGE_4={,,}IMAGE_5={,,}IMAGE_6={,,}IMAGE_7={,,}IMAGE_8={,,}---------------------------------------------------# Specify OEM AND FSL ID to be populated in header. [Optional]# e.g FSL_UID=11111111FSL_UID=OEM_UID=---------------------------------------------------# Specify the file names of csf header and sg table. (Default :hdr.out) [Optional]OUTPUT_HDR_FILENAME=hdr_uboot.out
# Specify the file names of hash file and sign file.HASH_FILENAME=img_hash.outINPUT_SIGN_FILENAME=sign.out
# Specify the signature size.It is mandatory when neither public key nor private key is specified.# Signature size would be [0x80 for 1k key, 0x100 for 2k key, and 0x200 for 4k key].SIGN_SIZE=---------------------------------------------------# Specify the output file name of sg table. (Default :sg_table.out). [Optional]# Please note that OUTPUT SG BIN is only required for 2041/3041/4080/5020/5040 when ESBC flag is not set.OUTPUT_SG_BIN=---------------------------------------------------# Following fields are Required for 4240/9164/1040/C290 only
# Specify House keeping Area# Required for 4240/9164/1040/C290 only when ESBC flag is not set. [Mandatory]
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 179
HK_AREA_POINTER=bff00000HK_AREA_SIZE=00010000---------------------------------------------------# Following field Required for 4240/9164/1040/C290 only# Specify Secondary Image Flag. (0 or 1) - [Optional]# (Default is 0)SEC_IMAGE=---------------------------------------------------
Table 8. Description of fields.
Field Field Description
PLATFORM To identify the platform/SoC for which CF Header needs tobe created.
ESBC Don’t set this flag when code signing is being performed onthe image directly verified by the ISBC. For later images inthe chain of trust, set this flag.
ENTRY_POINT Entry Point address / Image start address field in the header.
PRI_KEY Private key filename to be used for signing the image. (Filehas to be in PEM format) (default = srk.pri generated bygen_keys command) FILE1 [,FILE2, FILE3, FILE4]. Multiplekey support for Trust Arch v2.x devices only.
PUB_KEY Public key filename in PEM format. (default = srk.pubgenerated by gen_keys) FILE1 [,FILE2, FILE3, FILE4].Multiple key support for Trust Arch v2.x devices only.
KEY_SELECT Specify the key to be used in signature generation whenmore than one key has been given as input. (Default=1,first key will be selected)
IMAGE_1 - IMAGE_8 Create Entries for SG Table in the format { IMAGE_NAME,SRC_ADDR, DST_ADDR }
OEM_UID OEM UID to be populated in the header.
OEM_UID_1 OEM UID 1 to be populated in the header. Required Onlyfor ls1
FSL_UID FSL UID to be populated in header.
FSL_UID_1 FSL UID 1 to be populated in header.Required Only for ls1
HK_AREA_POINTER House Keeping Area Starting Pointer Required by Sec(Required for Trust Arch v2.x devices only when esbcoption is not provided)
HKAREA_SIZE House Keeping Area Size (Required for Trust Arch v2.xdevices only when esbc option is not provided)
OUTPUT_HDR_FILENAME Name of the combined header binary to be created by tool
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016180 NXP Semiconductors
Table 8. Description of fields. (continued)
Field Field Description
SG_TABLE_ADDR Specify SG_TABLE Address where Scatter Gather table ispresent for 2041/3041/4080/5020/5040 when ESBC=0.
OUTPUT_SG_BIN Specify the output file name of sg table.
IMAGE_TARGET Specify the target where image will be loaded.Ex:NOR_8B/NOR_16B/NAND_8B_512/NAND_8B_2K/NAND_8B_4K/ NAND_16B_512/NAND_16B_2K/NAND_16B_4K/SD/MMC/SPI
SEC_IMG Flag for Secondary Image. Required for Trust Arch v2.xdevices only
MP_FLAG Specify Manufacturing Protection Flag. Available for LS1only.
VERBOSE Specify Verbose option. Contents of header generated willbe printed.
9.2.7.2.2 Verbose Mode (--verbose)Verbose mode can be used to display extra information while creating the header. If selected, along with header creation,the tool will also display information about Output header and SG_TABLE entries..
Usage :: $./uni_sign --verbose <input_file>
Example
$ ./uni_sign --verbose input_uboot_secure
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Key Hash :9288723a0253229000a70bcbaa9d3aa1acb70f6369e1e81c9225319d9a364e2a
Image Hash :6c0048c92079b5e44152634a16d2463b808b5fd6ae23e7c42dcd30f49efafa8e********** HEADER **************barker:0x68392781srk_table_offset 200srk_table_flag(8) : 1srk_sel(8) : 1num_srk_entries(16) : 3psign 1410, length 128uid_flag 0sfp_wp(8) : 0sec_image_flag(8) : 0uid_flag(16) : 0psgtable 1400 num_entries 1img start cffffffcFSL UID 0OEM UID 0
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 181
sg_flag 1hkptr bff00000hksize 10000********** SG TABLE ************no of entries 1entry 0 len 786432 ptr cff40000SIGFNATURE file sign.out createdHEADER file hdr_uboot.out created
9.2.7.2.3 Public Key/ SRK Hash Generation Only (--hash)The Hash of the Public Key or SRK Table as selected by user in the input file while signing the images needs to be fused inthe SFP block. So if user wants to get the value of SRK Hash, this option can be used.
Usage :: $./uni_sign --hash <input_file>
Example
$./uni_sign --hash input_uboot_secure
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Key Hash :478c14568d8f76e822a2d483489a5ed9752c7c453b1fe5351f085a57fae2a30f
9.2.7.2.4 ISBC Key Extension (IE)9.2.7.2.4.1 IntroductionThe ISBC Key Extension feature allows the user to extend the ISBC and the number of keys available for signature validation.The ISBC uses a key directly bound to the silicon via the SRKH, the ISBC extension code (added to downstream images ina chain of trust) use IE_Keys, which are validated by the ISBC.
9.2.7.2.4.2 How it worksIf IE feature is enabled in input file, the CST signs the image along with a number of public keys. Logically, it will be usedwhen signing Boot 1 (bootloader), so that the bootloader and downstream images in the chain of trust can use keys whicharen't directly bound to the silicon via the SRKH. Decoupling the chain of trust from the hardware super root keys minimizesthe need to perform hardware key revocation.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016182 NXP Semiconductors
Figure 15. Execution and Verification of Images using Key_Ext feature.
Next stage images are signed with corresponding pair of Extension private keys list, not HW private
keys.
Key Extension feature is applicable only for NOR secure Boot. It is not applicable for
RAMBOOT (where data has to be copied onto RAM, eg:- NAND, SD, SPI)
NOTE
9.2.7.2.4.3 IE Key Structure
Table 9. IE Key Structure which is embedded in header and placed in memory.
Offset Data Bits [0:31]
0x00-0x03 This 32 bit word can be used to represent which keys from the table below havebeen revoked and are no longer available for use. Each bit represents 1 Key, Bit0 represents Key 1 in the table ….Bit 31 is the 32nd key in the table
0x04-0x07 Total number of keys (Max N = 32 as 32 bit key revocation field is provided)
0x08-0x0b Key 1 length.
0x0c-0x40b Key 1 value.
0x40c-0x40f Key 2 length.
0x410-0x80f Key 2 value.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 183
Table 9. IE Key Structure which is embedded in header and placed in memory. (continued)
Offset Data Bits [0:31]
- -
- Key N value
9.2.7.2.4.4 Sample Input File and OutputThis file is same as file described above in <link to 4.1.2> except fields required for IE Key extension highlighted in red.
---------------------------------------------------# Specify the platform. [Mandatory]# Choose Platform - 1040/2080/2041/3041/4080/5020/5040/4860/4240/LS1PLATFORM=1040# ESBC Flag. Specify ESBC=0 to sign u-boot and ESBC=1 to sign ESBC images.(default is 0)ESBC=0# ESBC Header address. It contains address where ESBC header is loaded in memory.ESBC_HDRADDR=c0b00000---------------------------------------------------# Entry Point/Image start address field in the header.[Mandatory]# (default=ADDRESS of first file specified in images)ENTRY_POINT=cffffffc---------------------------------------------------# Specify the file name of the keys seperated by comma.# The number of files and key select should lie between 1 and 4 for 1040/2080 and C290.# For rest of the platforms only one key is required and key select should not be provided.
# USAGE (for 4080/5020/5040/3041/2041/1010/913x): PRI_KEY = <key1.pri># USAGE (for 1040/2080/C290/4860/4240): PRI_KEY = <key1.pri>,<key2.pri>,<key3.pri>,<key4.pri>
# PRI_KEY (Default private key :srk.pri) - [Optional]PRI_KEY=srk.pri# PUB_KEY (Default public key :srk.pub) - [Optional]PUB_KEY=srk.pub# Please provide KEY_SELECT(between 1 to 4) (Required for 1040/2080/C290/4860/4240 only) - [Optional]KEY_SELECT=
# Specify the file name of the extension keys seperated by comma.# USAGE : IE_KEY = <key1.pub>,<key2.pub>,<key3.pub>,<key4.pub>,<key5.pub>IE_KEY=<iekey1k_1.pub>,<iekey1k_2.pub>,<iekey1k_3.pub>,<iekey2k_1.pub>,<iekey2k_2.pub>,<iekey2k_3.pub>,<iekey4k_1.pub>,<iekey4k_2.pub>
# Please provide Revoke keys. - [Optional]# Provide key numbers from available ie keys to be revoked. Max n-1 keys can be revoked. n is total number of IE keys.# LSb represents key0 and MSb represents key 31. So total 32 keys are supported.IE_REVOC=1,7---------------------------------------------------# Specify SG table address, only for (2041/3041/4080/5020/5040) with ESBC=0 - [Optional]SG_TABLE_ADDR=---------------------------------------------------# Specify the target where image will be loaded. (Default is NOR_16B) - [Optional]# Only required for Non-PBL Devices (1010/9131/9132/C290)# Select from - NOR_8B/NOR_16B/NAND_8B_512/NAND_8B_2K/NAND_8B_4K/NAND_16B_512/NAND_16B_2K/NAND_16B_4K/SD/MMC/SPI
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016184 NXP Semiconductors
IMAGE_TARGET=---------------------------------------------------# Specify IMAGE, Max 8 images are possible. DST_ADDR is required only for Non-PBL Platform. [Mandatory]# In case using IE_KEY, Max 7 images are possible. [Mandatory]# USAGE : IMAGE_NO = {IMAGE_NAME, SRC_ADDR, DST_ADDR}IMAGE_1={u-boot.bin,cff40000,ffffffff}IMAGE_2={,,}IMAGE_3={,,}IMAGE_4={,,}IMAGE_5={,,}IMAGE_6={,,}IMAGE_7={,,}---------------------------------------------------# Specify OEM AND FSL ID to be populated in header. [Optional]# e.g FSL_UID=11111111FSL_UID=OEM_UID=---------------------------------------------------# Specify the file names of csf header and sg table. (Default :hdr.out) [Optional]OUTPUT_HDR_FILENAME=hdr_uboot.out
# Specify the file names of hash file and sign file.HASH_FILENAME=img_hash.outINPUT_SIGN_FILENAME=sign.out
# Specify the signature size.It is mandatory when neither public key nor private key is specified.# Signature size would be [0x80 for 1k key, 0x100 for 2k key, and 0x200 for 4k key].SIGN_SIZE=---------------------------------------------------# Specify the output file name of sg table. (Default :sg_table.out). [Optional]# Please note that OUTPUT SG BIN is only required for 2041/3041/4080/5020/5040 when ESBC flag is not set.OUTPUT_SG_BIN=---------------------------------------------------# Following fields are Required for 4240/4860/1040/2080/C290 only
# Specify House keeping Area# Required for 4240/4860/1040/2080/C290 only when ESBC flag is not set. [Mandatory]HK_AREA_POINTER=bff00000HK_AREA_SIZE=00010000---------------------------------------------------# Following field Required for 4240/4860/1040/2080/C290 only# Specify Secondary Image Flag. (0 or 1) - [Optional]# (Default is 0)SEC_IMAGE=---------------------------------------------------
Table 10. Description of new fields introduced.
Field Field Description
ESBC_HDRADDR ESBC Header address. It contains location of ESBC headerin the memory
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 185
Table 10. Description of new fields introduced. (continued)
Field Field Description
IE_KEY Extension Public key filenames to be used by further levelimages. (File has to be in PEM format) FILE1 [,FILE2, FILE3,FILE4].
IE_REVOC Revoked keys numbers from available ie keys. If a key iscompromised then this feature helps to avoid that key usage.Max n-1 keys can be revoked. n is total number of IE keysand less than equal to 32.Ex.[1,3,5]
OUTPUT
Highlighted fields shows IE structure is embedded in the CSF header.
9.2.7.2.4.5 Generate Header for Next Level Images (bootscript, rootfs, dtb,linux).
IE key table generated in previous is embedded along with the CSF header for u-boot. Boot ROM code verifies these keysalong with the bootloader. For the rest of the images in the chain of trust, user can use the keys in the IE key table. The IE
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016186 NXP Semiconductors
Key Table is in the memory already, the sample input file needs to have the IE Key number to be used.(IE_KEY_SEL). Thecorresponding private key of the file needs to be provided for signature to be generated (PRI_KEY).
This sample file is same as file described above in <link to 4.1.2> except fields required for IE Key extension highlighted inred.
CSF Header for bootscript
---------------------------------------------------# Specify the platform. [Mandatory]# Choose Platform - 1040/2080/2041/3041/4080/5020/5040/4860/4240/LS1PLATFORM=1040# ESBC Flag. Specify ESBC=0 to sign u-boot and ESBC=1 to sign ESBC images.(default is 0)ESBC=1---------------------------------------------------# Entry Point/Image start address field in the header.[Mandatory]# (default=ADDRESS of first file specified in images)ENTRY_POINT=e8a00000---------------------------------------------------# Specify the file name of the keys seperated by comma.# The number of files and key select should lie between 1 and 4 for 1040/2080 and C290.# For rest of the platforms only one key is required and key select should not be provided.
# USAGE (for 4080/5020/5040/3041/2041/1010/913x): PRI_KEY = <key1.pri># USAGE (for 1040/2080/C290/4860/4240): PRI_KEY = <key1.pri>, <key2.pri>, <key3.pri>, <key4.pri>
# PRI_KEY (Default private key :srk.pri) - [Optional]PRI_KEY=iekey4k_2.pri# PUB_KEY (Default public key :srk.pub) - [Optional]PUB_KEY=# Please provide KEY_SELECT(between 1 to 4) (Required for 1040/2080/C290/9164/4240 only) - [Optional]KEY_SELECT=---------------------------------------------------# Specify SG table address, only for (2041/3041/4080/5020/5040) with ESBC=0 - [Optional]SG_TABLE_ADDR=---------------------------------------------------# Specify IE_KEY to be used for signature verification. [Mandatory]IE_KEY_SEL=8---------------------------------------------------# Specify the target where image will be loaded. (Default is NOR_16B) - [Optional]# Only required for Non-PBL Devices (1010/9131/9132/C290)# Select from - NOR_8B/NOR_16B/NAND_8B_512/NAND_8B_2K/NAND_8B_4K/NAND_16B_512/NAND_16B_2K/NAND_16B_4K/SD/MMC/SPIIMAGE_TARGET=---------------------------------------------------# Specify IMAGE, Max 8 images are possible. DST_ADDR is required only for Non-PBL Platform. [Mandatory]# In case using IE_KEY, Max 1 image is possible. [Mandatory]# USAGE : IMAGE_NO = {IMAGE_NAME, SRC_ADDR, DST_ADDR}IMAGE_1={bootscript,e8a00000,ffffffff}IMAGE_2={,,}IMAGE_3={,,}IMAGE_4={,,}IMAGE_5={,,}IMAGE_6={,,}IMAGE_7={,,}IMAGE_8={,,}---------------------------------------------------
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 187
# Specify OEM AND FSL ID to be populated in header. [Optional]# e.g FSL_UID=11111111FSL_UID=OEM_UID=---------------------------------------------------# Specify the file names of csf header. (Default :hdr.out) [Optional]OUTPUT_HDR_FILENAME=hdr_bs.out
# Specify the file names of hash file and sign file.HASH_FILENAME=img_hash.outINPUT_SIGN_FILENAME=sign.out
# Specify the signature size.It is mandatory when neither public key nor private key is specified.# Signature size would be [0x80 for 1k key, 0x100 for 2k key, and 0x200 for 4k key].SIGN_SIZE=0x200---------------------------------------------------# Specify the output file name of sg table. (Default :sg_table.out). [Optional]# Please note that OUTPUT SG BIN is only required for 2041/3041/4080/5020/5040 when ESBC flag is not set.OUTPUT_SG_BIN=
---------------------------------------------------# Following fields are Required for 4240/9164/1040/2080/C290 only
# Specify House keeping Area# Required for 42409164/1040/2080/C290 only when ESBC flag is not set. [Mandatory]HK_AREA_POINTER=HK_AREA_SIZE=---------------------------------------------------# Following field Required for 4240/9164/1040/2080/C290 only# Specify Secondary Image Flag. (0 or 1) - [Optional]# (Default is 0)SEC_IMAGE=---------------------------------------------------
Table 11. Description of new fields introduced.
Field Field Description
IE_KEY_SEL IE_KEY number for public key in IE Key table to be used forsignature verification of ESBC image.
OUTPUT
Given below is a snapshot of header generated in which highlighted fields indicates IE flag is ON and IE KEY SELECT i.e.key to be used to verify image is embedded in header.
Highlighted fields shows IE key select in CSF header.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016188 NXP Semiconductors
9.2.7.2.5 Image Hash Generation (--img_hash)9.2.7.2.5.1 IntroductionThe -img_hash generation feature provides OEMs with the ability to perform code signing in a secure environment whichdoes not run the FSL Code Signing Tool.
When used in conjunction with the IE Key List feature, the user generates the IE key list and the list of hardware public keys(those bound to the silicon with the SRKH), and passes them to the CST for inclusion in the ESBC image hash calculation.The CST generates the appropriate CSF header, S/G table, and key lists, then calculates and exports the SHA256 hash.The OEM then RSA encrypts the hash with one of the private keys associated with the public key provided to verify thesignature.
The signature, which must be in PKCS#1v1.5 format, is then appended to the ESBC. See section 4.7 for more informationon appending.
9.2.7.2.5.2 Features• Generates hash file in binary format which contains SHA256 hash of CSF header along with keys(SRK table, IE keys), SG
table and its entries.
• Generates output header binary file based on the fields specified in input file.
• Output header binary file doesn’t contain signature.
• Provides flexibility to manually append signature at the end of output header file. User’s can use their own custom tool togenerate the signature. The signature offset chosen in the header is such that the signature can be appended at the endof the header file.
• This option does not require private key to be provided. But the corresponding Public key from the public/private key pairmust be provided to calculate correct SHA256 hash.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 189
Usage Example:
./uni_sign --img_hash input_uboot_nor_secure
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Key Hash :f1f18e7eaeb28cee50a30f5ba5d270b3e71b2c7c8382507ca8e7e4c110547eb2
HASH file hash.out createdHEADER file esbc_hdr.out created
9.2.7.2.6 Help (--help)It prints help menu describing various options available.
9.2.7.3 Code Signing Tool WalkthroughStep-1)
Yocto installs the cst package at the following location:
tmp/sysroots/x86_64-linux/usr/bin/cst
OR
In the Yocto environment, the user can use below commands to rebuild cst:
1. bitbake cst-native –c cleanall
2. bitbake cst-native
Step-2)
cd tmp/sysroots/x86_64-linux/usr/bin/cst
gen_keys and uni_sign binaries are available in cst.
Note : LD_LIBRARY_PATH should be set to the library path in yocto workspace. <project_folder_path>/tmp/sysroots/x86_64-linux/usr/lib
Step-3)
Generate private key public key pair -
./gen_keys 1024
• Here, 1024 refers to the size of public key Modulus in bits.
• Other allowed sizes are - 2048 bits, 4096 bits.
• See help -
NOTE
bash-2.05a$ ./gen_keys -h
Step-4)
Put all the images (limited by number 8) you want to sign using OPENSSL RSA APIs in current directory.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016190 NXP Semiconductors
Step-5)
Execute the binary uni_cfsign to generate signature over CSF header and ESBC images.
CSF Header Generation
Example taken for B4860:
$ ./uni_sign input_files/uni_sign/b4860/input_uboot_nor_secure
===============================================================This product includes software developed by the OpenSSL Projectfor use in the OpenSSL Toolkit (http://www.openssl.org/)This product includes cryptographic software written byEric Young ([email protected])===============================================================
Key Hash :a9bb28a23c641e13b58c19a7fc48dfd8660a29895ebbc8bd0beba432e04c0785
HEADER file hdr_uboot.out created
The header would look like this:
00000000 68 39 27 81 00 00 02 00 00 00 01 00 00 00 14 00 |h9'.............|00000010 00 00 00 80 00 00 16 00 00 00 00 01 11 07 f0 00 |................|00000020 00 00 00 01 00 00 00 01 11 11 11 11 99 99 99 99 |................|00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000200 cc fe 4d fc 20 c1 6d ba 77 42 51 c2 4d c4 5b 45 |..M. .m.wBQ.M.[E|00000210 41 e2 88 a9 55 d0 49 7b 86 fe 5a 85 89 68 b7 db |A...U.I{..Z..h..|00000220 89 ef b7 2d 2a 1f 5b 74 4d 9c 7a c7 54 a9 b0 ff |...-*.[tM.z.T...|00000230 cf a6 1c ed 3d f3 de 8d cc 91 ae 5f 60 b4 88 ab |....=......_`...|00000240 a5 70 0b 20 73 30 75 38 5b 1b 51 22 e7 2f fd a6 |.p. s0u8[.Q"./..|00000250 65 00 07 4a 78 5d 1e ee 81 b8 a6 c4 81 e5 bc be |e..Jx]..........|00000260 dc 64 09 c0 07 91 7a 36 ab 7c 0c e0 ab b1 01 bb |.d....z6.|......|00000270 de a0 e2 56 65 0a 29 73 67 57 d3 ba 1f 52 7a 5f |...Ve.)sgW...Rz_|00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*000002f0 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 |................|00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00001400 b3 6e 9e d5 3a 47 c6 44 4e 09 ff 29 0d a5 a1 c3 |.n..:G.DN..)....|00001410 32 f3 b5 50 c6 42 f0 5b 59 29 f6 7d 57 0d 0a f9 |2..P.B.[Y).}W...|00001420 22 d6 d8 68 57 85 2a e9 dd 15 18 c1 eb d3 03 d6 |"..hW.*.........|00001430 8f 79 27 60 fa 4b 8c 1c 3e 7c db e6 3e 72 fd 8d |.y'`.K..>|..>r..|00001440 50 25 d9 ee 0f 30 5a 3a cf 7e d4 3a dc 98 bc c9 |P%...0Z:.~.:....|00001450 34 b3 8f 13 35 2e 55 1a f5 92 98 32 71 9c 8d 5b |4...5.U....2q..[|00001460 8c f0 80 d2 1c 38 d5 a1 77 07 38 49 7c 7d 01 2f |.....8..w.8I|}./|00001470 a1 c4 08 43 f5 af 67 7f d2 eb b9 e4 84 6c e1 77 |...C..g......l.w|00001480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00001600 00 08 00 00 00 00 00 08 00 00 40 00 11 00 00 00 |..........@.....|
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 191
9.2.8 Product executionThis section presents the steps needed to be followed in order to properly run the software product according to itsintended use and functionalities.
9.2.8.1 Getting startedThe example below demonstrates the secure-boot flow with all the images loaded in NOR Flash.
Steps in the demo would be:
1. ISBC code would validate the ESBC code.
2. On successful validation, ESBC code would run, which would then validate the boot script.
3. On successful validation of boot script, commands in boot script would be executed.
4. The boot script contains commands to validate next level images, i.e rootfs, linux uImage and device tree.
5. Once all the images are validated, bootm command in boot script would be executed which would pass control to linux.
For PowerPC SoC's, ISBC expects the code to be validated i.e. ESBC code to be within 0 - 3.5G
address map. In the demo we map the flash to address 0xc0000000 for the ISBC code to validate
ESBC in NOR Flash using PBI commands. Once the control reaches the ESBC code the earlier
mapping of flash is removed and flash is mapped to address 0xe0000000.
NOTE
For useful commands of U-Boot and CCS, refer to commands for different platforms under the topic 'Appendix<platform> Secure Boot Demo'
9.2.8.1.1 Environment for Secure BootThere are 2 ways in which secure boot can be initiated:
• Set SB_EN bit in RCW to 1.
• Programming the ITS fuse.
In a manufacturing environment, it is recommended that all fuses be programmed at once, including the ITS and OEM SectionWrite Protect bits. In a prototyping environment, it may be preferable to leave ITS and Write Protect unprogrammed (relyingon RCW to initiate secure boot) until the developer has confidence in the secure boot process.
Two different RCW's are provided for the demo purpose:
1. The RCW which has SB_EN bit set as 0 (sben0) and can be used when ITS = 1 i.e user wants to initiate secure bootflow using fuse.
2. The RCW which has the SB_EN bit set as 1 (sben1)and can be used when user wants to initiate secure boot usingRCW.
9.2.8.1.2 SDK Images required for the demoGiven below are the images required for the demo which are built with Yocto as part of the SDK:
1. RCW with PBI commands
2. ESBC (U-Boot)
3. uImage (Linux Image) *
4. rootfs Image *
5. Device tree *
Please refer to User Manual QorIQ DPAA SDK for detailed description on how to run Yocto Build. Once the build processfinishes, all the binaries would be present at the following location:
build_<platform>_release/tmp/deploy/images
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016192 NXP Semiconductors
The images will be created with the following names:
u-boot-secure-boot.bin U-Boot binary image for Secure Boot
uImage-<platform>.bin kernel image that can be loaded with U-Boot
fsl-image-core-<platform>.ext2.gz.u-boot ramdisk filesystem image that can be loaded with U-Boot
uImage-<platform>.dtb device tree binary(dtb) for kernel bootup
RCW files will be present in the path build_<platform>_release/tmp/deploy/images/rcw
* Some platforms with ARMv8 core have support for LINUX boot using a single kernel FIT image
instead of 3 separate images (uImage, rootfs and DTB)
NOTE
9.2.8.2 Chain of TrustThis section presents the steps needed to be followed in order to execute Chain of Trust.
Steps in the demo would be:
1. ISBC code would validate the ESBC code.
2. On successful validation, ESBC code would run, which would then validate the boot script.
3. On successful validation of boot script, commands in boot script would be executed.
4. The boot script contains commands to validate next level images, i.e rootfs, linux uImage and device tree.
5. Once all the images are validated, bootm command in boot script would be executed which would pass control to linux.
9.2.8.2.1 Other images required for the demoApart from SDK images described above, the following images are also required:
1. CSF Header of the ESBC u-boot image
2. CSF Header of the uImage *
3. CSF Header of the rootfs image *
4. CSF Header of the device tree *
5. Boot Script
6. CSF Header of the boot script
The following section describes how to create the CSF headers and boot script.
* Some platforms with ARMv8 core have support for LINUX boot using a single kernel FIT image
instead of 3 separate images (uImage, rootfs and DTB). For these platforms a single CSF Header
is required.
NOTE
9.2.8.2.2 Boot Script and Signing the imagesUser can sign all the images with same public/private key pair or can use different key pairs to sign the images. Section belowdescribes both the processes.
CST tool used for signing the images is provided as a package with yocto and is built for host. It can be run from your hostmachine.
Install path for CST binaries in yocto:
tmp/sysroots/x86_64-linux/usr/bin/cst/
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 193
CST uses openssl libraries, version 0.9.8.
In the Yocto environment, the user needs to use below commands to rebuild cst:
1. bitbake cst-native –c cleanall
2. bitbake cst-native
3. Modify the CST source code if needed.
4. bitbake cst-native –c cleanall
5. bitbake cst-native –c patch
Note: after step5, CST binary will be put to build_<platform_release/tmp/sysroots/x86_64-linux/usr/bin/cst/ directory.
Table 12. Platforms supported in SDK for Secure Boot
Soc <platform> supported in SDK <platform> supported in CST
B4860 b4860qds b4860
P2041 p2041rdb p3_p4_p5
P3041 p3041ds p3_p4_p5
P4080 p4080ds p3_p4_p5
P5020 p5020ds p3_p4_p5
P5040 p5040ds p3_p4_p5
T1024 t1024rdb t1_t2_t4
T104x t1040rdb, t1042rdb t1_t2_t4
T2080 t2080qds, t2080rdb t1_t2_t4
T4240 t4240qds t1_t2_t4
LS1021 ls1021aqds ls1
LS1021 ls1021atwr ls1
LS1043 ls1043ardb ls1043
LS1043 ls1043aqds ls1043
LS1012 ls1012ardb ls1012
Some platforms with ARMv8 core have support for LINUX boot using a single kernel FIT image
instead of 3 separate images (uImage, rootfs and DTB).
For such platforms, in CST as well instead of 3 different input files for signing uImage, rootfs and
dtb, there is a single input file named input_kernel_secure which can be used to sign the single
kernel FIT image.
This applies to all subsequent sections below.
NOTE
9.2.8.2.2.1 Signing the images using same key pairCSF header needs to be generated for all the images. More details on the commands provided by CST can be found inSection .
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016194 NXP Semiconductors
1. Generate the key pair to be used for signing the image
./gen_keys 1024
Key pair - public key file - srk.pub and private key in srk.priv would be generated.
2. Obtain hash string of the key pair generated to be programmed in SFP
./uni_sign --hash input_files/uni_sign/<platform>/input_uboot_secure
This would provide you the 256 bit hash in form of string of the key pair generated in the previous step. The hash has tobe programmed in the SRK hash Fuse.
3. Create CSF header for u-boot Image.
./uni_sign input_files/uni_sign/<platform>/input_uboot_secure
The input fields are specified in input_uboot_secure file. Please ensure that the filename mentioned in theinput_uboot_secure is same as copied in the cst directory.
4. Create CSF header for Linux uImage
./uni_sign input_files/uni_sign/<platform>/input_uimage_secure
uImage.bin would be validated form u-boot. The flash address used here is according to the address map of u-boot.Please ensure that filename mentioned in the input_uimage_secure is same as copied in the cst directory.
5. Create CSF header for rootfs
./uni_sign input_files/uni_sign/<platform>/input_rootfs_secure
Please make sure that filename mentioned in the input_rootfs_secure is same as copied in the cst
directory
6. Create CSF Header for hardware device tree
./uni_sign input_files/uni_sign/<platform>/input_dtb_secure
Please make sure that filename mentioned in the input_dtb_secure is same as copied in the cst
directory
7. Create Boot script
Bootscript is a U-Boot script image. Steps to create bootscript are given below :
a. Create a text file bootscript.txt with following commands.
esbc_validate <uImage CSF Header address> esbc_validate <dtb CSF Header address> esbc_validate <rootfs CSF Header address> bootm <uImage Address> <rootfs address> <dtb address>
b. Then you will have to use the mkimage tool to convert this text file into a U-Boot image (using the image type script)
powerpc arch:: /tmp/sysroots/x86_64-linux/usr/bin/mkimage -A ppc -T script -a 0 -e 0x40 -dbootscript.txt bootscript
arm arch:: /tmp/sysroots/x86_64-linux/usr/bin/mkimage -A arm -T script -a 0 -e 0x40 -dbootscript.txt bootscript
8. Generate CSF hdr for the boot script
./uni_sign input_files/uni_sign/<platform>/input_bootscript_secure
The fields can be changed in the input files for the images based on the requirement.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 195
9.2.8.2.2.2 Signing the images using different key pairIf boot script is also signed with a different key, remember to define the macro "CONFIG_BOOTSCRIPT_KEY_HASH" withthe hash of the key used to sign the boot script in file arch/powerpc/asm/include/fsl_secure_boot.h. ESBC u-boot wouldhave to be recompiled if any change in this file is made.
1. Generate the key pair to be used for signing the image
./gen_keys 1024 -p u-boot.priv -k u-boot.pub
Key pair - public key file - u-boot.pub and private key in u-boot.priv would be generated.
2. Obtain hash string of the key pair generated to be programmed in SFP
./uni_sign --hash input_files/uni_sign/<platform>/input_uboot_secure
This would provide you the 256 bit hash in form of string of the key pair generated in the previous step. The hash has tobe programmed in the SRK hash Fuse.
3. Create CSF header for u-boot Image.
Open input_files/uni_sign/<platform>/input_uboot_secure and change PRI_KEY and PUB_KEY to u-noot.priv and u-boot.pub respectively and run the following command.
./uni_sign input_files/uni_sign/<platform>/input_uboot_secure
4. Create CSF header for Linux uImage using different key pair.
Repeat step 1 to generate another key pair.
./gen_keys 1024 -p lnx.priv -k lnx.pub
Open input_files/uni_sign/<platform>/input_uimage_secure and change PRI_KEY and PUB_KEY to lnx.priv
and lnx.pub respectively and run the following command. ./uni_sign input_files/uni_sign/<platform>/
input_uimage_secure
Remember the "Key Hash" printed as it would be required in esbc_validate command in boot script. Say the hash of thekey is <lnx_key_hash>
5. Create CSF header for rootfs
./gen_keys 1024 -p rootfs.priv -k rootfs.pub
Open input_files/uni_sign/<platform>/input_rootfs_secure and change PRI_KEY and PUB_KEY to
rootfs.priv and rootfs.pub respectively and run the following command.
./uni_sign input_files/uni_sign/<platform>/input_rootfs_secure
Remember the "Key Hash" printed as it would be required in esbc_validate command in boot script. Say the hash of thekey is <rootfs_key_hash>
6. Create CSF Header for hardware device tree
./gen_keys 1024 -p dtb.priv -k dtb.pub
Open input_files/uni_sign/<platform>/input_dtb_secure and change PRI_KEY and PUB_KEY to dtb.privand dtb.pub respectively and run the following command. ./uni_sign input_files/uni_sign/<platform>/
input_dtb_secure
Remember the "Key Hash" printed as it would be required in esbc_validate command in boot script. Say the hash of thekey is <dtb_key_hash>
7. Write Boot script
Bootscript is a U-Boot script image. Steps to create bootscript are given below :
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016196 NXP Semiconductors
a. Create a text file bootscript.txt with following commands.
esbc_validate <uImage CSF Header address> <lnx_key_hash> esbc_validate <dtb CSF Header address> <dtb_key_hash> esbc_validate <rootfs CSF Header address> <rootfs_key_hahs> bootm <uImage Address> <rootfs address> <dtb address>
Hashes would be the 256 bit string hash. These are the hashes of the key used to sign the
respective images.
NOTE
b. Generate header over bootscript.txt which will be consumed by uboot command source
powerpc arch :: tmp/sysroots/x86_64-linux/usr/bin/mkimage -A ppc -T script -a 0 -e 0x40 -d bootscript.txt bootscript
arm arch :: tmp/sysroots/x86_64-linux/usr/bin/mkimage -A arm -T script -a 0 -e 0x40 -d bootscript.txt bootscript
8. Generate CSF hdr for the boot script
./gen_keys 1024 -p bs.priv -k bs.pub
Open input_files/uni_sign/<platform>/input_dtb_secure and change PRI_KEY and PUB_KEY to bs.priv andbs.pub respectively and run the following command.
./uni_sign input_files/uni_sign/<platform>/input_dtb_secure
9.2.8.2.3 Running secure boot (Chain of Trust)1. Setup the board for secure boot flow. You can choose any if the flows mentioned below.
a. Flow A
Program the ITS fuse. Use RCW with SB_EN=0
Or
b. Flow B
For protyping phase, don't blow the ITS fuse, but use rcw with SB_EN = 1.
Note: For P3/P4/P5, if ITS fuse is blown, then ITF fuse must also be blown. (The value of ITS and ITF fusemust be identical.)
2. Blow other required fuses on the board. (OTPMK and SRK hash[1]) For more details regarding fuse blowing, CCS andBoot Hold Off, refer to Platform reference manual and Trust Architecture User Guide.
SRK hash in the fuse should be same as the hash of the key pair being used to sign the ESBC u-
boot. Step 2 of Signing the images using same key pair on page 194
For testing purpose, the SRK Hash can be written in the mirror registers.
gen_otpmk_drbg utility in cst can be used to generate otpmk key.
NOTE
3. Flash all the generated images at locations as described in the address map ( specified for different platforms underthe topic 'Appendix <platform> Secure Boot Demo' ).
[1] Blowing of OTPMKis essential to run secure boot for both Production (Flow A) and Prototyping/Development (Flow B).
For SRK Hash,in Development Mode (Flow B), there is a workaround to avoid blowing fuses. For this use RCW withBOOT_HO = 1. This will put the core in Boot Hold off stage. Then a CCS can be connected via JTAG.
Write the SRK Hash value in SFP mirror registers and then release the core out of Boot Hold off by writing to CoreRelease Register in DCFG.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 197
a. Flow A - All the images would have to be flashed at the current bank addresses. Once ITS fuse is blown, thecontrol would automatically shift to ISBC on power on.
b. If you are using Flow B, you can use alternate bank for demo purpose. This would mean flashing the images onalternate bank addresses from Bank0 and then switching to Bank4.
4. Give a power on cycle to the board.
a. For Flow A and Flow B (Secure boot Images flashed on default Bank)
• On power on, ISBC code would get control, validate the ESBC image.
• ESBC image would further validate the signed linux, rootfs and dtb images
• Linux would come up
b. Flow B (Secure boot Images flashed on alternate Bank)
• On power on cycle, u-boot prompt on bank 0 would come up.
• On switching to alternate bank, the secure boot flow as mentioned above would execute.
9.2.8.3 Chain of Trust with ConfidentialityThis section presents the steps needed to be followed in order to execute Chain of Trust with confidentiality.
The demo would be divided into two parts:
1. Creating /encrypting images in form of blobs.
2. Decrypting the images, and booting from decrypted images.
Steps in the demo would be:
Step 1: Creating blobs
1. ISBC code would validate the ESBC code.
2. On successful validation, ESBC code would run, which would then validate the boot script.
3. On successful validation of boot script, commands in boot script would be executed.
4. The boot script contains commands to encapsullate next level images, i.e rootfs, linux uImage and device tree.
blob encapsulation command::
blob enc src dst len km - Encapsulate and create blob of data
$len - Number of bytes to be encapsulated.
$src - The address where image to be encapsulated is present.
$dst - The address where encapsulated image will be stored.
$km - It is the address where the key modifier is stored. The modifier is required and used as key for cryptographic operation.Key modifier should be 16 bytes long.
Step 2: Decrypting blob and booting
1. ISBC code would validate the ESBC code.
2. On successful validation, ESBC code would run, which would then validate the boot script.
3. On successful validation of boot script, commands in boot script would be executed.
4. The boot script contains commands to decapsulate/decrypt next level images, i.e rootfs, linux uImage and device tree.
5. After decryption, bootm command would be executed in boot script to pass control to Linux.
blob decapsulation command::
blob dec src dst len km - Decapsulate the image and recover the data
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016198 NXP Semiconductors
$len - Number of bytes to be decapsulated.
$src - The address where encapsulated image is present.
$dst - The address where decapsulated image will be stored.
$km - It is the address where the key modifier is stored. The modifier is required and used as key for cryptographic operation.Key modifier should be 16 bytes long. It should be same as passed while encapsulating the image.
9.2.8.3.1 Other images required for the demoApart from SDK images described above, the following images are also required:
1. Encap Boot script
2. Decap Boot script
3. CSF header for ESBC u-boot Image
4. CSF Header of the encap boot script
5. CSF Header of the decap boot script
The following section describes how to create the CSF headers and boot script.
9.2.8.3.2 Encap Bootscript1. Create a bootscript_en.txt file with following commands:
blob enc <uImage address> 0x10000000 <uImage size> <key_modifier address>
erase <encapsulated uImage address> +<encapsulated uImage size>cp.b 0x10000000 <encapsulated uImage address> <encapsulated uImage size>
blob enc <rootfs address> 0x20000000 <rootfs size> <key_modifier address>
erase <encapsulated rootfs address> +<encapsulated rootfs size>cp.b 0x20000000 <encapsulated rootfs address> <encapsulated rootfs size>
blob enc <dtb address> 0x1000000 <dtb size> <key_modifier address>
erase <encapsulated dtb address> +<encapsulated dtb size>cp.b 0x1000000 <encapsulated dtb address> <encapsulated dtb size>
For the addresses to load images refer Section for different platforms under the topic 'Appendix <platform> Secure BootDemo'
2. Use the mkimage tool to convert this text file into a U-Boot image (using the image type script)
/tmp/sysroots/x86_64-linux/usr/bin/mkimage -A ppc -T script -a 0 -e 0x40 -d bootscript_en.txt bootscript_encap
9.2.8.3.3 Decap Bootscript1. Create a bootscript_de.txt file with following commands:
blob dec <encapsulated uImage address> 0x10000000 <uImage size + 0x30> <key_modifier address>
blob dec <encapsulated rootfs address> 0x20000000 <rootfs size + 0x30> <key_modifier address>
blob dec <encapsulated dtb address> 0x1000000 <dtb size + 0x30> <key_modifier address>
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 199
bootm 0x10000000 0x20000000 0x1000000
For the addresses to load images refer section for different platforms under the topic 'Appendix <platform> Secure BootDemo'
The script decapsulates/decrypts the blob created by earlier boot script and boots using them.
0x30(48 bytes) should be added in the size of encapsulated images while decapsulating them.
Always 48B are added at the end of the encapsulated image which needs to be added while
providing the size of image to be decapsulated in blob dec command.
NOTE
2. Use the mkimage tool to convert this text file into a U-Boot image (using the image type script)
/tmp/sysroots/x86_64-linux/usr/bin/mkimage -A ppc -T script -a 0 -e 0x40 -d bootscript_de.txt bootscript_decap
9.2.8.3.4 Creating CSF Headers• CSF Header for ESBC
Use the command given below to generate the hdr for u-boot binary.
./uni_sign input_files/uni_sign/<platform>/<input file for uboot>
Please change the binary name as per your uboot binary in “IMAGE_1”.
• CSF Header for bootscript_encap and bootscript_decap
Use the command given below to generate the headers for bootscripts
./uni_sign input_files/uni_sign/<platform>/<input file for bootscript>
Please change the binary name as per your bootscript in “IMAGE_1”.
9.2.8.3.5 Running secure boot (Chain of Trust with Confidentiality)1. Setup the board for secure boot flow. You can choose any if the flows mentioned below.
a. Flow A
Program the ITS fuse. Use RCW with SB_EN=0
Or
b. Flow B
For protyping phase, don't blow the ITS fuse, but use rcw with SB_EN = 1.
Note: For P3/P4/P5, if ITS fuse is blown, then ITF fuse must also be blown. (The value of ITS and ITF fusemust be identical.)
2. Blow other required fuses on the board. (OTPMK and SRK hash[2]) For more details regarding fuse blowing, CCS andBoot Hold Off, refer to Platform reference manual and Trust Architecture User Guide.
[2] Blowing of OTPMKis essential to run secure boot for both Production (Flow A) and Prototyping/Development (Flow B).
For SRK Hash,in Development Mode (Flow B), there is a workaround to avoid blowing fuses. For this use RCW withBOOT_HO = 1. This will put the core in Boot Hold off stage. Then a CCS can be connected via JTAG.
Write the SRK Hash value in SFP mirror registers and then release the core out of Boot Hold off by writing to CoreRelease Register in DCFG.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016200 NXP Semiconductors
SRK hash in the fuse should be same as the hash of the key pair being used to sign the ESBC u-
boot.
For testing purpose, the SRK Hash can be written in the mirror registers.
gen_otpmk_drbg utility in cst can be used to generate otpmk key.
NOTE
3. Flash all the generated images at locations as described in the address map specified for different platforms under thetopic 'Appendix <platform> Secure Boot Demo'
• Uboot binary
• CSF Header of uboot
• Linux uImage
• Rootfs
• Device tree
• bootscript_encap
• CSF Header for bootscript_encap
a. Flow A - All the images would have to be flashed at the current bank addresses. Once ITS fuse is blown, thecontrol would automatically shift to ISBC on power on.
b. If you are using Flow B, you can use alternate bank for demo purpose. This would mean flashing the images onalternate bank addresses from Bank0 and then switching to Bank4.
4. Give a power on cycle to the board.
a. For Flow A and Flow B (Secure boot Images flashed on default Bank)
• On power on, ISBC code would get control, validate the ESBC image.
• ESBC image would further validate the bootscript.
• Bootscript would encapsulate the Linux, rootfs and device tree and store the blobs at the desired locations.
b. Flow B (Secure boot Images flashed on alternate Bank)
• On power on cycle, u-boot prompt on bank 0 would come up.
• On switching to alternate bank, the secure boot flow as mentioned above would execute.
5. Give a power on cycle to the board.
6. Replace the encap bootscript and its CSF header with decap bootscript and the CSF header of the decap bootscriptrespectively.
7. Give a power on cycle to the board.
a. For Flow A and Flow B (Secure boot Images flashed on default Bank)
• On power on, ISBC code would get control, validate the ESBC image.
• ESBC image would further validate the bootscript.
• Bootscript would decapsulate the Linux, rootfs and device tree bloband store them on DDR
• Bootm commnd in bootscript would execute on successful decapsulation
• Linux prompt would come up. .
b. Flow B (Secure boot Images flashed on alternate Bank)
• On power on cycle, u-boot prompt on bank 0 would come up.
• On switching to alternate bank, the secure boot flow as mentioned above would execute.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 201
9.2.8.4 NAND Secure Boot (Chain of Trust)This section presents the steps and images needed for running Secure Boot Chain of Trust from NAND on P3/P5.
The procedure for running Secure boot from NAND is same as Secure Boot from NAND. The only difference is that in caseof NOR, image is not required to be copied from NOR while in case of NAND, images have to be copied from NAND to SRAM/DDR before validation.
Images Required for Demo
1. PBL.bin
The PBL.bin is generated using QCVS Tool. It creates the RCW along with PBI commands. ESBC (U-boot) and CSFHeader for U-Boot are added using ACS_WRITE PBI commands. (For details/screenshots refer Using QCVS Tool (SecureBoot From NAND) on page 245)
2. uImage (Linux Image)
3. rootfs
4. dtb (Device Tree)
5. CSF Header of the uImage
6. CSF Header of the rootfs image
7. CSF Header of the device tree
8. Boot Script
9. CSF Header of the Boot Script
Boot Script
The sample bootscript.txt would have the following commands:
# Read uImage & Headernand read <uImage DDR> <uImage NAND> <uImage size>nand read <uImage Header DDR> <uImage Header NAND> <uImage Header size>
# Read rootfs & Headernand read <rootfs DDR> <rootfs NAND> <rootfs size>nand read <rootfs Header DDR> <rootfs Header NAND> <rootfs Header size>
# Read dtb & Headernand read <dtb DDR> <dtb NAND> <dtb size>nand read <dtb Header DDR> <dtb Header NAND> <dtb Header size>
# Validate and Bootesbc_validate <uImage Header DDR>esbc_validate <DTB Header DDR>esbc_validate <rootfs Header DDR>bootm <uImage DDR> <rootfs DDR> <dtb DDR>
Image Signing
The image signing process will remain same as in case of NOR #unique_225
<platform> will be p3_p4_p5/nand
ISBC Key Extension Feature is not applicable for Secure Boot from NAND.
NOTE
9.2.8.4.1 Running Secure Boot Chain of Trust (from NAND)1. Setup the board for secure boot flow. You can choose any if the flows mentioned below.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016202 NXP Semiconductors
a. Flow A
Program the ITS fuse. Use RCW with SB_EN=0
Or
b. Flow B
For protyping phase, don't blow the ITS fuse, but use rcw with SB_EN = 1.
Note: For P3/P5, if ITS fuse is blown, then ITF fuse must also be blown. (The value of ITS and ITF fuse mustbe identical.)
2. Blow other required fuses on the board. (OTPMK and SRK hash[3]) For more details regarding fuse blowing, CCS andBoot Hold Off, refer to Platform reference manual and Trust Architecture User Guide.
SRK hash in the fuse should be same as the hash of the key pair being used to sign the ESBC u-
boot. Step 2 of Signing the images using same key pair on page 194
For testing purpose, the SRK Hash can be written in the mirror registers.
gen_otpmk_drbg utility in cst can be used to generate otpmk key.
NOTE
3. Flash all the generated images on NAND Flash at locations as described in the address map (specified for differentplatforms under the topic 'Appendix <platform> Secure Boot Demo' ).
4. Switch to NAND Boot.
a. FLOW A
Change the Switch Settings to change the RCW_SRC to NAND and power on the board.
b. FLOW B
Power on the board to bring up Non-Secure U-Boot on NOR and from U-Boot promt issue the following command.
mw.b 0xffdf0020 0x48;mw.b 0xffdf0021 0x78;mw.b 0xffdf002c 0x90;mw.b 0xffdf002d 0xf0;mw.b 0xffdf0010 0; mw.b 0xffdf0010 1
• The PBL would configure CPC as SRAM, update the SCRATCH register and copy the Header and U-boot (ESBC)on CPC configured as SRAM.
• ISBC code would get control, validate the ESBC image.
• ESBC image would further copy the Boot Script Header and Boot Script from NAND to DDR, validate the boot scriptand execute it.
• The Boot Script has commands to copy the linux images and their respective headers from NAND to DDR, validatethe signed linux, rootfs and dtb images.
• Linux would be booted.
[3] Blowing of OTPMKis essential to run secure boot for both Production (Flow A) and Prototyping/Development (Flow B).
For SRK Hash,in Development Mode (Flow B), there is a workaround to avoid blowing fuses. For this use RCW withBOOT_HO = 1. This will put the core in Boot Hold off stage. Then a CCS can be connected via JTAG.
Write the SRK Hash value in SFP mirror registers and then release the core out of Boot Hold off by writing to CoreRelease Register in DCFG.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 203
9.2.8.5 NAND Secure Boot (Chain of Trust with Confidentiality)This section presents the steps and images needed for running Secure Boot Chain of Trust with Confidentiality fromNAND on P3/P5
The procedure for running Secure boot from NAND is same as Secure Boot from NAND. The only difference is that in caseof NOR, image is not required to be copied from NOR while in case of NAND, images have to be copied from NAND to SRAM/DDR before validation.
Images Required for Demo
1. PBL.bin
The PBL.bin is generated using QCVS Tool. It creates the RCW along with PBI commands. ESBC (U-boot) and CSFHeader for U-Boot are added using ACS_WRITE PBI commands. (For details/screenshots refer Using QCVS Tool (SecureBoot From NAND) on page 245)
2. uImage (Linux Image)
3. rootfs
4. dtb (Device Tree)
5. Encap Boot Script
6. CSF Header of the Encap Boot Script
7. Decap Boot Script
8. CSH Header for Decap Boot Script
Encap Boot Script
# uImagenand read <uImage DDR> <uImage NAND> <uImage size>esbc_blob_encap <uImage DDR> 0x10000000 <uImage size> 0x11223344556677889900aabbccddeeffnand erase <encapsulated uImage NAND> <encapsulated uImage size>nand write 0x10000000 <encapsulated uImage NAND> <encapsulated uImage size>
# rootfsnand read <rootfs DDR> <rootfs NAND> <rootfs size>esbc_blob_encap <rootfs DDR> 0x10000000 <rootfs size> 0x11223344556677889900aabbccddeeffnand erase <encapsulated rootfs NAND> <encapsulated rootfs size>nand write 0x10000000 <encapsulated rootfs NAND> <encapsulated rootfs size>
# dtbnand read <dtb DDR> <dtb NAND> <dtb size>esbc_blob_encap <dtb DDR> 0x10000000 <dtb size> 0x11223344556677889900aabbccddeeffnand erase <encapsulated dtb NAND> <encapsulated dtb size>nand write 0x10000000 <encapsulated dtb NAND> <encapsulated dtb size>
Decap Boot Script
nand read <encapsulated uImage DDR> <encapsulated uImage NAND> <encapsulated uImage size>esbc_blob_decap <encapsulated uImage DDR> 0x10000000 <uImage size> 0x11223344556677889900aabbccddeeff
nand read <encapsulated rootfs DDR> <encapsulated rootfs NAND> <encapsulated rootfs size>esbc_blob_decap <encapsulated rootfs DDR> 0x20000000 <rootfs size> 0x11223344556677889900aabbccddeeff
nand read <encapsulated dtb DDR> <encapsulated dtb NAND> <encapsulated dtb size>esbc_blob_decap <encapsulated dtb DDR> 0x1000000 <dtb size> 0x11223344556677889900aabbccddeeff
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016204 NXP Semiconductors
bootm 0x10000000 0x20000000 0x1000000
Image Signing
The image signing process will remain same as in case of NOR #unique_225
<platform> will be p3_p4_p5/nand
9.2.8.5.1 Running Secure Boot Chain of Trust with Confidentiality (fromNAND)
1. Setup the board for secure boot flow. You can choose any if the flows mentioned below.
a. Flow A
Program the ITS fuse. Use RCW with SB_EN=0
Or
b. Flow B
For protyping phase, don't blow the ITS fuse, but use rcw with SB_EN = 1.
Note: For P3/P5, if ITS fuse is blown, then ITF fuse must also be blown. (The value of ITS and ITF fuse mustbe identical.)
2. Blow other required fuses on the board. (OTPMK and SRK hash[4]) For more details regarding fuse blowing, CCS andBoot Hold Off, refer to Platform reference manual and Trust Architecture User Guide.
SRK hash in the fuse should be same as the hash of the key pair being used to sign the ESBC u-
boot. Step 2 of Signing the images using same key pair on page 194
For testing purpose, the SRK Hash can be written in the mirror registers.
gen_otpmk_drbg utility in cst can be used to generate otpmk key.
NOTE
3. Flash all the generated images on NAND Flash at locations as described in the address map (specified for differentplatforms under the topic 'Appendix <platform> Secure Boot Demo' )
a. PBL.bin
b. LINUX Images (uImage, dtb, rootfs)
c. CSF Header for bootscript_encap)
d. bootscript_encap
4. Switch to NAND Boot.
a. FLOW A
Change the Switch Settings to change the RCW_SRC to NAND and power on the board.
b. FLOW B
[4] Blowing of OTPMKis essential to run secure boot for both Production (Flow A) and Prototyping/Development (Flow B).
For SRK Hash,in Development Mode (Flow B), there is a workaround to avoid blowing fuses. For this use RCW withBOOT_HO = 1. This will put the core in Boot Hold off stage. Then a CCS can be connected via JTAG.
Write the SRK Hash value in SFP mirror registers and then release the core out of Boot Hold off by writing to CoreRelease Register in DCFG.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 205
Power on the board to bring up Non-Secure U-Boot on NOR and from U-Boot promt issue the following command.
mw.b 0xffdf0020 0x48;mw.b 0xffdf0021 0x78;mw.b 0xffdf002c 0x90;mw.b 0xffdf002d 0xf0;mw.b 0xffdf0010 0; mw.b 0xffdf0010 1
• The PBL would configure CPC as SRAM, update the SCRATCH register and copy the Header and U-boot (ESBC)on CPC configured as SRAM.
• ISBC code would get control, validate the ESBC image.
• ESBC image would further copy the Boot Script Header and Boot Script from NAND to DDR, validate the boot scriptand execute it.
• Bootscript would encapsulate the Linux, rootfs and device tree and store the blobs at the desired locations.
5. Revert the switch settings to earlier RCW_SRC and power on the board. Replace the encap bootscript and its CSFheader with decap bootscript and the CSF header of the decap bootscript respectively.
6. Switch to NAND Boot.
a. FLOW A
Change the Switch Settings to change the RCW_SRC to NAND and power on the board.
b. FLOW B
Power on the board to bring up Non-Secure U-Boot on NOR and from U-Boot promt issue the following command.
mw.b 0xffdf0020 0x48;mw.b 0xffdf0021 0x78;mw.b 0xffdf002c 0x90;mw.b 0xffdf002d 0xf0;mw.b 0xffdf0010 0; mw.b 0xffdf0010 1
• The PBL would configure CPC as SRAM, update the SCRATCH register and copy the Header and U-boot (ESBC)on CPC configured as SRAM.
• ISBC code would get control, validate the ESBC image.
• ESBC image would further copy the Boot Script Header and Boot Script from NAND to DDR, validate the boot scriptand execute it.
• Bootscript would copy the Linux, rootfs and device tree blobs on DDR and then decapsulate them on DDR.
• Bootm commnd in bootscript would execute on successful decapsulation.
• Linux prompt would come up.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016206 NXP Semiconductors
9.2.9 TroubleshootingTable 13. Troubleshooting
Symptoms Reasons and/or Recommended actions
1. No print on UART console. • Check the status register of sec mon block (location 0xfe314014).Refer to the details of the register from the Reference Manual. BitsOTPMK_ZERO, OTMPK_SYNDROME and PE should be 0 otherwisethere is some error in the OTPMK fuse blown by you.
• If OTMPK fuse is correct (see Step 1), check the SCRATCHRW2register for errors. Refer to Section for error codes.
• If Error code = 0 then check the Security Monitor state in HPSRregister of Sec Mon.
Sec Mon in Check State (0x9)
If ITS fuse = 1, then it means ISBC code has reset the board. This maybe due to the following reasons:
Hash of the public key used to sign the ESBC u-boot doesn't match withthe value in SRK Hash Fuse
Or
Signature verification of the image failed
Sec Mon in Trusted State (0xd) or Non Secure State (0xb)
Check the entry point field in the ESBC header. It should be 0xcffffffc forthe demo described in Section 4.
If entry point is correct, ensure that u-boot image has been compiled withthe required secure boot configuration.
2. Instead of linux prompt, you get a u-bootcommand prompt instead of linux prompt.
You have not booted in secure boot mode. You never get a u-boot promptin secure boot flow. Check Step 1 in Running secure boot (Chain of Trust)on page 197. You would reach this stage if ITS = 0 and you are using rcwwhere sben0 is present in its name.
3 u-boot hangs or board resets Some validation failure occurred in ESBC u-boot. Error code anddescription would be printed on u-boot console. Refer to for more detailson errors.
9.2.10 CSF Header Data StructureThe CSF Header provides the ISBC with most of the information needed to validate the image.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 207
P3/P4/P5 Platforms
Figure 16. CSF Header for P3/P4/P5 (ISBC and ESBC Phase)
Table 14. CSF Header Format (P3/P4/P5 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Barker code.
This location should contain the value: 0x68392781. The ISBC code searches for this Barker code. Ifthe value in this location does not match the Barker code, the ISBC stops execution and reports error.
0x04-0x07 Public key offset.
This location contains an offset in bytes of the public key from the start of CSF header. Using thisoffset and the public key length, the public key is read.
0x08-0x0b Public key length in bytes.
(Value populated here should be twice of Modulus size). Supported sizes are 256, 512 or 1024 bytes(2 * 1024, 2 * 2048 , 2 * 4096 bits).
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016208 NXP Semiconductors
Table 14. CSF Header Format (P3/P4/P5 Platforms) (continued)
Offset Data Bits [0:31]
0x0c-0x0f RSA Signature offset.
This location contains an offset(in bytes) of the RSA signature from the start of CSF header. Usingthis offset and the Signature length, the RSA signature is read. The RSA signature is calculated overCSF Header, Scatter Gather table and ESBC images.
0x10-0x13 RSA Signature length in bytes.
0x14-0x17 For ISBC Phase:
Based on the Scatter Gather flag in CSF header, this location can either be treated as Pointer toScatter Gather table or the address of ESBC image.
For ESBC Phase:
This location is treated as address of image(linux/bootscript/rootfs/dtb) to be validated.
0x18-0x1b For ISBC Phase:
Based on the Scatter gather flag in CSF Header, this location can either be treated as number ofentries in SG table or ESBC image size in bytes.
For ESBC Phase: Size of image to be validated
0x1c-0x1f For ISBC Phase:
ESBC entry point. ISBC transfers control to this location upon successful validation of ESBCimage(s).
For ESBC Phase: Reserved.
0x20-0x23 For ISBC Phase:
Scatter Gather flag.
0x0000 - 0x14-0x17 is a pointer to the ESBC image
0x0001 - 0x14-0x17 is a pointer to a scatter/gather table.
For ESBC Phase: Reserved
0x24-0x27 Unique ID Usage.
UIDs present in the CSF Header are compared to the corresponding UIDs in the SFP, and are includedin the ESBC validation.
0x0000 - No UIDs are present in CSF header
0x0001 - FSL_UID and OEM_UID are present in CSF header
0x0002 - Only OEM_UID present in CSF header
0x0004 - Only FSL_UID present in CSF header
0x28-0x2b Freescale unique ID.
A unique 32 bit value, which is specific to Freescale. This value is compared with the FSL ID in SecureFuse Processor 's FSL-ID registers
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 209
Table 14. CSF Header Format (P3/P4/P5 Platforms) (continued)
Offset Data Bits [0:31]
0x2c-0x2f OEM unique ID.
A unique 32 bit value, which is specific to OEM. This value is compared with the OEM ID in SecureFuse Processor 's OEM-ID registers
0x30-0x47 For ISBC Phase: Not Applicable
For ESBC Phase: Reserved
0x48-0x4b For ISBC Phase: Not Applicable
For ESBC Phase:
ISBC key Extension flag.
If this flag is set, key to be used for validation needs to be picked up from IE Key table.
0x4c-0x4f For ISBC Phase: Not Applicable
For ESBC Phase:
IE Key Select.
Key Number to be used from the IE Key Table if IE flag is set.
Table 15. Scatter Gather Table Format (P3/P4/P5 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Length in bytes of the first segment of the ESBC image.
0x04-0x07 Pointer to first segment of ESBC image.
0x08-0x0b Length in bytes of the second segment of the ESBC image.
0x0c-0x0f Pointer to second segment of ESBC image.
0xww-0xxx Length in bytes of the nth segment of the ESBC image.
0xyy-0xzz Pointer to nth segment of ESBC image
Table 16. Signature (P3/P4/P5 Platforms)
Offset Data Bits [0:31]
0x00-size The RSA signature calculated over CSF Header, Scatter Gather table and ESBC image(s).
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016210 NXP Semiconductors
Table 17. Public key (P3/P4/P5 Platforms)
Offset Data Bits [0:31]
0x00-size Public Key Value. The hash of this public key is compared with the hash stored in Secure FuseProcessor SRKH registers.
B4/T1/T2/T4 Platforms
Figure 17. CSF Header for B4/T1/T2/T4 (ISBC and ESBC Phase)
Table 18. CSF Header Format (B4/T1/T2/T4 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Barker code.
This location should contain the value: 0x68392781. The ISBC code searches for this Barker code. Ifthe value in this location does not match the Barker code, the ISBC stops execution and reports error.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 211
Table 18. CSF Header Format (B4/T1/T2/T4 Platforms) (continued)
Offset Data Bits [0:31]
0x04-0x07 If the srk_table_flag is not set :
• Public key offset: This location contains an address which is the offset of the public key from thestart of CSF header. Using this offset and the public key length, the public key is read.
If srk_table_flag is set:
• Srk table offset: This location contains an address which is the offset of the srk table from thestart of CSF header. Using this offset and the number of entries is SRK Table, the SRK table isread.
0x08 Srk table flag.
This flag indicates whether hash burnt in srk fuse is of a single key or of srk table.
0x09-0x0b If the srk_table_flag is not set :
• Public key length: This location contains the length of the public key in bytes.
If srk_table_flag is set:
• 0x09 – Key Number from srk table which is to be used for verification.
• 0x0a-0x0b – Number of entries in srk table. Minimum number of entries in table = 1, Maximum= 4.
0x0c-0x0f RSA Signature offset.
This location contains an offset(in bytes) of the RSA signature from the start of CSF header. Usingthis offset and the Signature length, the RSA signature is read. The RSA signature is calculated overCSF Header, Scatter Gather table and ESBC images.
0x10-0x13 RSA Signature length in bytes.
0x14-0x17 For ISBC Phase:
SG Table offset
This location contains an address which is the offset of the SG table from the start of CSF header.Using this offset and the number of entries is SG Table, the SG table is read.
For ESBC Phase:
Address of the image to be validated.
0x18-0x1b For ISBC Phase:
Number of entries in SG Table (Earlier ,Based on the Scatter gather flag in CSF Header, this locationcan either be treated as number of entries in SG table or ESBC image size in bytes.).
For ESBC Phase:
Size of Image to be validated
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016212 NXP Semiconductors
Table 18. CSF Header Format (B4/T1/T2/T4 Platforms) (continued)
Offset Data Bits [0:31]
0x1c-0x1f For ISBC Phase:
ESBC entry point. ISBC transfers control to this location upon successful validation of ESBCimage(s).
For ESBC Phase: Reserved
0x20-0x23 Reserved .(Earlier this field was SG Flag. SG flag is always assumed to be 1 in unifiedimplementation.)
0x24 For ISBC Phase: Reserved
For ESBC Phase: Reserved
0x25 For ISBC Phase:
Secondary Image flag
Indicates if user has a secondary image available in case of failures in validating primary iamge.Validin case of primary Images’s Header.
For ESBC Phase:Reserved
0x26-0x27 Unique ID Usage
This location contains a flag which specifies one of these possibilities
• 0x00 - No UID’s present
• 0x01 - FSL UID and OEM UID are present
• 0x02 - Only FSL UID is present
• 0x04 - Only OEM UID is present
0x28-0x2b Freescale unique ID.
A unique 32 bit value, which is specific to Freescale. This value is compared with the FSL ID in SecureFuse Processor 's FSL-ID registers
0x2c-0x2f OEM unique ID.
A unique 32 bit value, which is specific to OEM. This value is compared with the OEM ID in SecureFuse Processor 's OEM-ID registers
0x30-0x33 For ISBC Phase:
Housekeeping area address
This is address of start of a memory which can be accessed by devices on SOC bus. (DDR, L3 cacheconfigured as SRAM ). The area should have been pre-configured by user through PBL commandsor configuration header
For ESBC Phase: Reserved
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 213
Table 18. CSF Header Format (B4/T1/T2/T4 Platforms) (continued)
Offset Data Bits [0:31]
0x34-0x37 For ISBC Phase:
Size of the housekeeping area
Size of the pre-configured memory which can be used by Boot Rom Code.
For ESBC Phase: Reserved
0x38-0x3f Reserved
0x40-0x47 For ISBC Phase: Not Applicable
For ESBC Phase: Reserved
0x48-0x4b For ISBC Phase: Not Applicable
For ESBC Phase:
ISBC key Extension flag
If this flag is set, key to be used for validation needs to be picked up from IE Key table.
0x4c-0x4f For ISBC Phase: Not Applicable
For ESBC Phase:
IE Key Select
Key Number to be used from the IE Key Table if IE flag is set.
Table 19. Scatter Gather Table Format (B4/T1/T2/T4 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Length. This location specifies the length in bytes of the ESBC image 1.
0x04-0x07 Target where the ESBC Image 1 can be found. This field is ignored in case of PBL based SOC’s.
0x08-0x0b Source Address of ESBC Image 1
0x0c-0x0f Destination Address of ESBC Image 1
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
0x10-0x13 Length. This location specifies the length in bytes of the ESBC image 2.
0x14-0x17 Target where the ESBC Image 2 can be found. This field is ignored in case of PBL based SOC’s.
0x18-0x1b Source Address of ESBC Image 2
0x1c-0x1f Destination Address of ESBC Image 2
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016214 NXP Semiconductors
Table 20. Signature (B4/T1/T2/T4 Platforms)
Offset Data Bits [0:31]
0x00-size The RSA signature calculated over CSF Header, Scatter Gather table and ESBC image(s).
Table 21. Public key (B4/T1/T2/T4 Platforms)
Offset Data Bits [0:31]
0x00-size Public Key Value. The hash of this public key is compared with the hash stored in Secure FuseProcessor SRKH registers.
Table 22. SRK Table (B4/T1/T2/T4 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Key 1 length
0x04-0x403 Key 1 value. (Remaining bytes will be padded with zero)
0x404-0x407 Key 2 length
0x408-0x807 Key 2 value. (Remaining bytes will be padded with zero)
0x808-0x80b Key 3 length
0x80c-0xb0b Key 3 value. (Remaining bytes will be padded with zero)
0xb0c-0xb0f Key 4 length
0xb10-0xe10 Key 4 value. (Remaining bytes will be padded with zero)
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 215
LS1 Platform
Figure 18. CSF Header for LS1 (ISBC and ESBC Phase)
Table 23. CSF Header Format (LS1 Platform)
Offset Data Bits [0:31]
0x00-0x03 Barker code.
This location should contain the value: 0x68392781. The ISBC code searches for this Barker code. Ifthe value in this location does not match the Barker code, the ISBC stops execution and reports error.
0x07-0x04 If the srk_table_flag is not set :
• Public key offset: This location contains an address which is the offset of the public key from thestart of CSF header. Using this offset and the public key length, the public key is read.
If srk_table_flag is set:
• Srk table offset: This location contains an address which is the offset of the srk table from thestart of CSF header. Using this offset and the number of entries is SRK Table, the SRK table isread.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016216 NXP Semiconductors
Table 23. CSF Header Format (LS1 Platform) (continued)
Offset Data Bits [0:31]
0x08 Srk table flag.
This flag indicates whether hash burnt in srk fuse is of a single key or of srk table.
0x0b-0x09 If the srk_table_flag is not set :
• 0x0b-0x9 -- Public key length: This location contains the length of the public key in bytes.
If srk_table_flag is set:
• 0x09 – Key Number from srk table which is to be used for verification.
• 0x0b-0x0a – Number of entries in srk table. Minimum number of entries in table = 1, Maximum= 4.
0x0f-0x0c RSA Signature offset.
This location contains an offset(in bytes) of the RSA signature from the start of CSF header. Usingthis offset and the Signature length, the RSA signature is read. The RSA signature is calculated overCSF Header, Scatter Gather table and ESBC images.
0x13-0x10 RSA Signature length in bytes.
0x17-0x14 For ISBC Phase:
SG Table offset
This location contains an address which is the offset of the SG table from the start of CSF header.Using this offset and the number of entries is SG Table, the SG table is read.
For ESBC Phase:
Address of the image to be validated.
0x1b-0x18 For ISBC Phase:
Number of entries in SG Table (Earlier ,Based on the Scatter gather flag in CSF Header, this locationcan either be treated as number of entries in SG table or ESBC image size in bytes.).
For ESBC Phase
Size of image to be validated
0x1f-0x1c For ISBC Phase:
ESBC entry point.
ISBC transfers control to this location upon successful validation of ESBC image(s).
For ESBC Phase: Reserved
0x21-0x20 Manufacturing Protection Flag
Indicates if manufacturing protection has to be enabled or not in ISBC.
0x23-0x22 Reserved .(Earlier this field was SG Flag. SG flag is always assumed to be 1 in unifiedimplementation.)
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 217
Table 23. CSF Header Format (LS1 Platform) (continued)
Offset Data Bits [0:31]
0x24 For ISBC Phase: Reserved
For ESBC Phase: Reserved
0x25 For ISBC Phase
Secondary Image flag
Indicates if user has a secondary image available in case of failures in validating primary iamge.Validin case of primary Images’s Header.
For ESBC Phase:Reserved
0x27-0x26 Unique ID Usage
This location contains a flag which specifies one of these possibilities
• 0x00 - No UID’s present
• 0x01 - FSL UID and OEM UID are present
• 0x02 - Only FSL UID is present
• 0x04 - Only OEM UID is present
0x2b-0x28 Freescale unique ID 0
Upper 32 bits of a unique 64 bit value, which is specific to Freescale. This value is compared with theFSL ID 1 in Secure Fuse Processor 's FSL-ID registers
0x2f-0x2c OEM unique ID 0
Upper 32 bits of a unique 64 bit value, which is specific to OEM. This value is compared with the OEMID 0 in Secure Fuse Processor 's OEM-ID registers
0x37-0x30 Reserved
0x3b-0x38 Freescale unique ID 1
Lower 32 bits of a unique 64 bit value, which is specific to Freescale. This value is compared with theFSL ID 1 in Secure Fuse Processor 's FSL-ID registers
0x3f-0x3c OEM unique ID 1
Lower 32 bits of a unique 32 bit value, which is specific to OEM. This value is compared with theOEM ID 1 in Secure Fuse Processor 's OEM-ID registers
0x40-0x47 For ISBC Phase: Not Applicable
For ESBC Phase: Reserved
0x48-0x4b For ISBC Phase: Not Applicable
For ESBC Phase:
ISBC key Extension flag
If this flag is set, key to be used for validation needs to be picked up from IE Key table.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016218 NXP Semiconductors
Table 23. CSF Header Format (LS1 Platform) (continued)
Offset Data Bits [0:31]
0x4c-0x4f For ISBC Phase: Not Applicable
For ESBC Phase:
IE Key Select
Key Number to be used from the IE Key Table if IE flag is set.
Table 24. Scatter Gather Table Format (LS1 Platform)
Offset Data Bits [0:31]
0x00-0x03 Length. This location specifies the length in bytes of the ESBC image 1.
0x04-0x07 Target where the ESBC Image 1 can be found. This field is ignored in case of PBL based SOC’s.
0x08-0x0b Source Address of ESBC Image 1
0x0c-0x0f Destination Address of ESBC Image 1
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
0x10-0x13 Length. This location specifies the length in bytes of the ESBC image 2.
0x14-0x17 Target where the ESBC Image 2 can be found. This field is ignored in case of PBL based SOC’s.
0x18-0x1b Source Address of ESBC Image 2
0x1c-0x1f Destination Address of ESBC Image 2
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
Table 25. Signature (LS1 Platform)
Offset Data Bits [0:31]
0x00-size The RSA signature calculated over CSF Header, Scatter Gather table and ESBC image(s).
Table 26. Public key (LS1 Platform)
Offset Data Bits [0:31]
0x00-size Public Key Value. The hash of this public key is compared with the hash stored in Secure FuseProcessor SRKH registers.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 219
Table 27. SRK Table (LS1 Platform)
Offset Data Bits [0:31]
0x00-0x03 Key 1 length
0x04-0x403 Key 1 value. (Remaining bytes will be padded with zero)
0x404-0x407 Key 2 length
0x408-0x807 Key 2 value. (Remaining bytes will be padded with zero)
0x808-0x80b Key 3 length
0x80c-0xb0b Key 3 value. (Remaining bytes will be padded with zero)
0xb0c-0xb0f Key 4 length
0xb10-0xe10 Key 4 value. (Remaining bytes will be padded with zero)
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016220 NXP Semiconductors
LS1043/LS1012 Platforms
Figure 19. CSF Header for LS1043/LS1012 (ISBC and ESBC Phase)
Table 28. CSF Header Format (LS1043/LS1012 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Barker code.
This location should contain the value: 0x68392781. The ISBC code searches for this Barker code. Ifthe value in this location does not match the Barker code, the ISBC stops execution and reports error.
0x07-0x04 If the srk_table_flag is not set :
• Public key offset: This location contains an address which is the offset of the public key from thestart of CSF header. Using this offset and the public key length, the public key is read.
If srk_table_flag is set:
• Srk table offset: This location contains an address which is the offset of the srk table from thestart of CSF header. Using this offset and the number of entries is SRK Table, the SRK table isread.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 221
Table 28. CSF Header Format (LS1043/LS1012 Platforms) (continued)
Offset Data Bits [0:31]
0x08 Srk table flag.
This flag indicates whether hash burnt in srk fuse is of a single key or of srk table.
0x0b-0x09 If the srk_table_flag is not set :
• 0x0b-0x9 -- Public key length: This location contains the length of the public key in bytes.
If srk_table_flag is set:
• 0x09 – Key Number from srk table which is to be used for verification.
• 0x0b-0x0a – Number of entries in srk table. Minimum number of entries in table = 1, Maximum= 4.
0x0f-0x0c RSA Signature offset.
This location contains an offset(in bytes) of the RSA signature from the start of CSF header. Usingthis offset and the Signature length, the RSA signature is read. The RSA signature is calculated overCSF Header, Scatter Gather table and ESBC images.
0x13-0x10 RSA Signature length in bytes.
0x17-0x14 For ISBC Phase:
SG Table offset
This location contains an address which is the offset of the SG table from the start of CSF header.Using this offset and the number of entries is SG Table, the SG table is read.
For ESBC Phase:
Reserved
0x1b-0x18 For ISBC Phase:
Number of entries in SG Table (Earlier ,Based on the Scatter gather flag in CSF Header, this locationcan either be treated as number of entries in SG table or ESBC image size in bytes.).
For ESBC Phase
Size of image to be validated
0x1f-0x1c For ISBC Phase:
ESBC entry point.
ISBC transfers control to this location upon successful validation of ESBC image(s).
For ESBC Phase: Reserved
0x21-0x20 Manufacturing Protection Flag
Indicates if manufacturing protection has to be enabled or not in ISBC.
0x23-0x22 Reserved .(Earlier this field was SG Flag. SG flag is always assumed to be 1 in unifiedimplementation.)
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016222 NXP Semiconductors
Table 28. CSF Header Format (LS1043/LS1012 Platforms) (continued)
Offset Data Bits [0:31]
0x24 For ISBC Phase: Reserved
For ESBC Phase: Reserved
0x25 For ISBC Phase
Secondary Image flag
Indicates if user has a secondary image available in case of failures in validating primary iamge.Validin case of primary Images’s Header.
For ESBC Phase:Reserved
0x27-0x26 Unique ID Usage
This location contains a flag which specifies one of these possibilities
• 0x00 - No UID’s present
• 0x01 - FSL UID and OEM UID are present
• 0x02 - Only FSL UID is present
• 0x04 - Only OEM UID is present
0x2b-0x28 Freescale unique ID 0
Upper 32 bits of a unique 64 bit value, which is specific to Freescale. This value is compared with theFSL ID 1 in Secure Fuse Processor 's FSL-ID registers
0x2f-0x2c OEM unique ID 0
Upper 32 bits of a unique 64 bit value, which is specific to OEM. This value is compared with the OEMID 0 in Secure Fuse Processor 's OEM-ID registers
0x37-0x30 Reserved
0x3b-0x38 Freescale unique ID 1
Lower 32 bits of a unique 64 bit value, which is specific to Freescale. This value is compared with theFSL ID 1 in Secure Fuse Processor 's FSL-ID registers
0x3f-0x3c OEM unique ID 1
Lower 32 bits of a unique 32 bit value, which is specific to OEM. This value is compared with theOEM ID 1 in Secure Fuse Processor 's OEM-ID registers
0x40-0x47 For ISBC Phase: Not Applicable
For ESBC Phase: 64 bit pointer to ESBC image
0x48-0x4b For ISBC Phase: Not Applicable
For ESBC Phase:
ISBC key Extension flag
If this flag is set, key to be used for validation needs to be picked up from IE Key table.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 223
Table 28. CSF Header Format (LS1043/LS1012 Platforms) (continued)
Offset Data Bits [0:31]
0x4c-0x4f For ISBC Phase: Not Applicable
For ESBC Phase:
IE Key Select
Key Number to be used from the IE Key Table if IE flag is set.
Table 29. Scatter Gather Table Format (LS1043/LS1012 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Length. This location specifies the length in bytes of the ESBC image 1.
0x04-0x07 Target where the ESBC Image 1 can be found. This field is ignored in case of PBL based SOC’s.
0x08-0x0b Source Address of ESBC Image 1
0x0c-0x0f Destination Address of ESBC Image 1
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
0x10-0x13 Length. This location specifies the length in bytes of the ESBC image 2.
0x14-0x17 Target where the ESBC Image 2 can be found. This field is ignored in case of PBL based SOC’s.
0x18-0x1b Source Address of ESBC Image 2
0x1c-0x1f Destination Address of ESBC Image 2
If the target address is 0xffffffff, the image is not copied to the target. This field is ignored in case ofPBL based SOC’s.
Table 30. Signature (LS1043/LS1012 Platforms)
Offset Data Bits [0:31]
0x00-size The RSA signature calculated over CSF Header, Scatter Gather table and ESBC image(s).
Table 31. Public key (LS1043/LS1012 Platforms)
Offset Data Bits [0:31]
0x00-size Public Key Value. The hash of this public key is compared with the hash stored in Secure FuseProcessor SRKH registers.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016224 NXP Semiconductors
Table 32. SRK Table (LS1043/LS1012 Platforms)
Offset Data Bits [0:31]
0x00-0x03 Key 1 length
0x04-0x403 Key 1 value. (Remaining bytes will be padded with zero)
0x404-0x407 Key 2 length
0x408-0x807 Key 2 value. (Remaining bytes will be padded with zero)
0x808-0x80b Key 3 length
0x80c-0xb0b Key 3 value. (Remaining bytes will be padded with zero)
0xb0c-0xb0f Key 4 length
0xb10-0xe10 Key 4 value. (Remaining bytes will be padded with zero)
9.2.11 ISBC Validation Error CodesP3/P4/P5 platforms
Table 33. ISBC Validation Failures (P3/P4/P5 platforms)
Value Code Definition
0x1 CPUID_NO_MATCH ISBC is not running on CPU0
0x2 ESBC_HDR_LOC ESBC header location is not in 3.5G space
0x4 ESBC_HEADER_BARKER Barker code in the header is incorrect.
0x8 ESBC_HEADER_KEY_LEN Length of public key in header is not one of the supportedvalues.
0x10 ESBC_HEADER_SIGN_LEN Length of RSA signature in header is not one of the supportedvalues.
0x20 ESBC_HEADER_KEY_LEN_NOT_T
WICE_SIG_LEN
Public key is not twice the length of the RSA signature
0x40 ESBC_HEADER_SG_TABLE_ADDR_
NULL
SG table/ESBC image address (0x14-0x17 in CSF Header) isnull
0x80 ESBC_HEADER_SG_TABLE_ADDR_
NOT_IN_3_5G
SG table/ESBC image address (0x14-0x17 in CSF Header) isbeyond 3.5G
0x100 ESBC_HEADER_KEY_MOD_1 Most significant bit of modulus in header is zero.
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 225
Table 33. ISBC Validation Failures (P3/P4/P5 platforms) (continued)
Value Code Definition
0x200 ESBC_HEADER_KEY_MOD_2 Modulus in header is even number
0x400 ESBC_HEADER_SIG_KEY_MOD Signature value is greater than modulus in header
0x800 ESBC_HEADER_SG_ENTRIES_NUL SG Table contains zero entries
0x1000 ESBC_HEADER_SG_ENTRIES_NOT
_IN_3_5G
Address in SG entry in not in 3.5G
0x2000 ESBC_HEADER_SG_ESBC_EP ESBC entry point in header not within ESBC address range
0x4000 HASH_COMPARE_KEY Super Root Key Hash Comparison failure. Mismatch in thehash of the public key as present in the header with the valuein the SRK HASH fuse.
0x8000 HASH_COMPARE_EM RSA signature check failure. Signature provided by you in theheader doesn't match with the signature of the ESBC imagegenerated by ISBC. The ESBC image loaded by you may bedifferent than the image used while generating thesignature(using CST)
0x10000 SSM_CHECKSTS SEC_MON State Machine not in CHECK state at start of ISBC.Some Security violation could have occurred. Details can befound in P4080 Reference Manual.
0x20000 SSM_TRUSTSTS SEC_MON State Machine not in TRUSTED state at end ofISBC.
0x40000 FSL_UID FSL_UID in ESBC Header did not match the FSL_UID in SFP
0x80000 OEM_UID OEM_UID in ESBC Header did not match the OEM_UID inSFP
0x100000 BAD_ADDRESS A Data / Instruction TLB Exception occurred during ISBCexecution
0x200000 MISC E500mc exception other than TLB
0x400000 ESBC_HEADER_SG_ENTIRES_BAD SG Table too large (too many entries)
For error codes 0x2 - 0x2000 i,e errors in the ESBC Header, check the value of that particular field
by dumping the header.
NOTE
B4/T1/T2/T4/LS1/LS1043/LS1012 platforms
Errors in the system can be of following types:
1. Core Exceptions
2. System State Failures
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016226 NXP Semiconductors
3. Header Checking Failures
a. General Failures
b. Key/Signature/UID related errors
4. Verification Failures
5. SEC/PAMU errors
Table 34. Core Exceptions (LS1 platform)
Value Code Definition
0x1 ERROR_UNDEFINED_INSTRUCTION Occurs if neither the processor nor any attached co-processor recognizes the currently executing instruction.
0x2 ERROR_SWI Software Interrupt is a user-defined interrupt instruction. Itallows a program running in User mode, for example, torequest privileged operations that run in Supervisor mode.
0x3 ERROR_PREFETCH_ABORT Occurs when the processor attempts to execute aninstruction that has been prefetched from an illegal address.
0x4 ERROR_DATA_ABORT Occurs when a data transfer instruction attempts to load orstore data at an illegal address.
0x5 ERROR_IRQ Occurs when the processor external interrupt request pin isasserted (LOW) and IRQ interrupts are enabled.
0x6 ERROR_FIQ Occurs when the processor external fast interrupt request pinis asserted (LOW) and FIQ interrupts are enabled.
Table 35. Core Exceptions (LS1043/LS1012 platforms)
Error Code Value
Current EL with SP0
ERROR_EXCEPTION_SYNC_SP0 0x01
ERROR_EXCEPTION_IRQ_SP0 0x02
ERROR_EXCEPTION_FIQ_SP0 0x03
ERROR_EXCEPTION_SERROR_SP0 0x04
Current EL with SPx
ERROR_EXCEPTION_SYNC_SPX 0x05
ERROR_EXCEPTION_IRQ_SPX 0x06
ERROR_EXCEPTION_FIQ_SPX 0x07
ERROR_EXCEPTION_SERROR_SPX 0x08
Lower EL using AArch64
ERROR_EXCEPTION_SYNC_L64 0x11
ERROR_EXCEPTION_IRQ_L64 0x12
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 227
Table 35. Core Exceptions (LS1043/LS1012 platforms) (continued)
ERROR_EXCEPTION_FIQ_L64 0x13
ERROR_EXCEPTION_SERROR_L64 0x14
Lower EL using AArch32
ERROR_EXCEPTION_SYNC_L32 0x15
ERROR_EXCEPTION_IRQ_L32 0x16
ERROR_EXCEPTION_FIQ_L32 0x17
ERROR_EXCEPTION_SERROR_L32 0x18
Table 36. Core Exceptions (B4/T1/T2/T4 platforms)
Value Code Definition
0x1 ERROR_MACHINECHECK Machine check Exception
0x2 ERROR_DSI DSI Exception
0x3 ERROR_ISI ISI Exception
0x4 ERROR_CRITICAL Critical Exception
0x5 ERROR_ALIGN Alignment Exception
0x6 ERROR_PROG Program Exception
0x13 ERROR_DATA_TLB Data TLB Miss
0x14 ERROR_INST_TLB Instruction TLb Miss
0x20 ERROR_MISC Any other exception
Table 37. System State Failures (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)
Value Code Definition
0x100 ERROR_CORE_NON_ZERO ISBC is not running on CPU0
0x101 ERROR_STATE_NOT_CHECK SEC_MON State Machine not in CHECK state at start ofISBC. Some Security violation could have occurred.
0x102 ERROR2_STATE_NOT_CHECK SEC_MON State Machine not in CHECK state, when tryingto transition it to Trusted/Non Secure/Soft Fail state
0x103 ERROR_SSM_TRUSTSTS SEC_MON State Machine not in TRUSTED state at end ofISBC.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016228 NXP Semiconductors
Table 38. General Header Checking Failures (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)
Value Code Definition
0x301 ERROR_ESBC_HDR_LOC ESBC header location is not in 3.5G space
0x302 ERROR_ESBC_HEADER_BARKER Barker code in the header is incorrect.
0x303 ERROR_ESBC_HEADER_SG_ENTRIES_NOT_IN_3_5G
SG table/ESBC image address (header address + imageoffset in sg table) is beyond 3.5G
0x304 ERROR_ESBC_HEADER_SG_ESBC_EP ESBC entry point in header not within ESBC address range
0x305 ERROR_SGL_ENTIRES_NOT_SUPPORTED
Number of entries in SG table exceeds maximum limit i.e 8
0x306 ERROR_ESBC_HEADER_HKAREA_LEN_ZERO
Houskeeping area not provided in header
0x307 ERROR_ESBC_HEADER_HKAREA_NOT_IN_3_5G
House keeping area not in 3.5G boundary
0x308 ERROR_ESBC_HEADER_HKAREA_LEN_INSUFFICIENT
Housekeeping area length provided is not sufficient.
0x309 ERROR_SG_TABLE_NOT_IN_3_5 SG Table is not in 3.5G boundary
0x310 ERROR_ESBC_HEADER_HKAREA_NOT_4K_ALIGNED
House keeping area is not aligned to 4K boundary
0x311 ERROR_SGL_ENTRIES_SIZE_ZERO SG table has entry with size zero.
Table 39. Key/Signature/UID related errors (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)
Value Code Definition
0x320 ERROR_ESBC_HEADER_KEY_LEN Length of public key in header is not one of the supportedvalues.
0x321 ERROR_ESBC_HEADER_KEY_LEN_NOT_TWICE_SIG_LEN
Public key is not twice the length of the RSA signature
0x322 ERROR_ESBC_HEADER_KEY_MOD_1 Most significant bit of modulus in header is zero.
0x323 ERROR_ESBC_HEADER_KEY_MOD_2 Modulus in header is even number
0x324 ERROR_ESBC_HEADER_SIG_KEY_MOD
Signature value is greater than modulus in header
0x325 ERROR_FSL_UID FSL_UID in ESBC Header did not match the FSL_UID inSFP if fsl uid flag Is 1
0x326 ERROR_OEM_UID OEM_UID in ESBC Header did not match the OEM_UID inSFP if oem uid flag is 1.
0x327 ERROR_INVALID_SRK_NUM_ENTRY Number of entries field in CSF Header is > 4(This is whensrk_flag in header is 1)
0x328 ERROR_INVALID_KEY_NUM Key number to be used from srk table is not present in table.( This is when srk_flag in header is 1)
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 229
Table 39. Key/Signature/UID related errors (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms) (continued)
Value Code Definition
0x329 ERROR_KEY_REVOKED Key selected from srk table has been revoked(This is whensrk_flag in header is 1)
0x32a ERROR_INVALID_SRK_ENTRY_KEYLEN
Key length specified in one of the entries in srk table is notone of the supported values (This is when srk_flag in headeris 1)
0x32b ERROR_SRK_TBL_NOT_IN_3_5 SRK Table is not in 3.5G boundary (This is when srk_flag inheader is 1)
0x32c ERROR_KEY_NOT_IN_3_5G Key is not in 3.5G boundary
Table 40. Verification Failures (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)
Value Code Definition
0x340 ERROR_HASH_COMPARE_KEY Super Root Key Hash Comparison failure. Mismatch in thehash of the public key/srk table as present in the header withthe value in the SRK HASH fuse.
0x341 ERROR_HASH_COMPARE_EM RSA signature check failure. Signature provided by you in theheader doesn’t match with the signature of the ESBC imagegenerated by ISBC. The ESBC image loaded by you may bedifferent than the image used while generating thesignature(using CST)
Table 41. SEC/PAMU Failures (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)
Value Code Definition
0x700 ERROR_SEC_ENQ Error when enqueuing to SEC
0x701 ERROR_SEC_DEQ Sec Block returned some error when dequeuing from it.
0x702 ERROR_SEC_DEQ_TO Timeout when trying to deq from SEC
0x800 ERROR_PAMU Error while programming PAACT/SPAACT tables in PAMU(For PowerPC platforms only)
9.2.12 ESBC Validation Error CodesFor trust arch version 1.x and 2.x.
Table 42. ESBC Validation Failures
Value Code Definition
0x4 ERROR_ESBC_CLIENT_HEADER_BARKER
Wrong barker code in header
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016230 NXP Semiconductors
Table 42. ESBC Validation Failures (continued)
Value Code Definition
0x8 ERROR_ESBC_CLIENT_HEADER_KEY_LEN
Wrong public key length in header
0x10 ERROR_ESBC_CLIENT_HEADER_SIG_LEN
Wrong signature length in header
0x11 ERROR_ESBC_CLIENT_HEADER_KEY_REVOKED
Selected key is revoked.
0x12 ERROR_ESBC_CLIENT_HEADER_INVALID_SRK_NUM_ENTRY
Wrong key entry.
0x13 ERROR_ESBC_CLIENT_HEADER_INVALID_KEY_NUM
Wrong key is selected.
0x14 ERROR_ESBC_CLIENT_HEADER_INV_SRK_ENTRY_KEYLEN
Wrong srk public key len in header.
0x15 ERROR_ESBC_CLIENT_HEADER_IE_KEY_REVOKED
Selected IE key is revoked.
0x16 ERROR_ESBC_CLIENT_HEADER_INVALID_IE_NUM_ENTRY
Wrong key entry in IE Table.
0x17 ERROR_ESBC_CLIENT_HEADER_INVALID_IE_KEY_NUM
Wrong IE key is selected.
0x18 ERROR_ESBC_CLIENT_HEADER_INV_IE_ENTRY_KEYLEN
Wrong IE public key len in header.
0x19 ERROR_IE_TABLE_NOT_FOUND Information about IE Table missing.
0x20 ERROR_ESBC_CLIENT_HEADER_KEY_LEN_NOT_TWICE_SIG_LEN
Public key length not twice of signature length
0x21 ERROR_KEY_TABLE_NOT_FOUND No Key/ Key Table Found in header.
0x40 ERROR_ESBC_CLIENT_HEADER_KEY_MOD_1
Public key Modulus most significant bit not set
0x80 ERROR_ESBC_CLIENT_HEADER_KEY_MOD_2
Public key Modulus in header not odd
0x100 ERROR_ESBC_CLIENT_HEADER_SIG_KEY_MOD
Signature not less than modulus
0x400 ERROR_ESBC_CLIENT_HASH_COMPARE_KEY
Public key hash comparison failed
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 231
Table 42. ESBC Validation Failures (continued)
Value Code Definition
0x800 ERROR_ESBC_CLIENT_HASH_COMPARE_EM
RSA verification failed
0x2000 ERROR_ESBC_CLIENT_BAD_ADDRESS Bad address error.
0x4000 ERROR_ESBC_CLIENT_MISC Miscallaneous error.
0x20000 ERROR_ESBC_CLIENT_HEADER_IMG_SIZE
Invalid Image size.
0x40000 ERROR_ESBC_WRONG_CMD Unknown cmd/Wrong arguments. Core in infinite loop.
0x80000 ERROR_ESBC_MISSING_BOOTM Bootm command missing from bootscript.
9.2.13 Address map used for the demoThe addresses below are effective addresses as mapped by u-boot.
P3/P4/P5/T1/T2/T4 platforms
Table 43. Memory map for P3/P4/P5/T1_T2_T4 platforms
Address(NOR vBank0)
Address (NORAlternateBank)[5]
Definition
(Chain of Trust)
Definition
(Chain of Trust withConfidentiality)
SizeReserved(KB)
E8000000 EC000000 RCW RCW 128
E8020000 EC020000 uImage uImage 8064
E8800000 EC800000 DTB DTB 1024
E8900000 EC900000 1024
E8A00000 ECA00000 Bootscript Bootscript 1024
E8B00000 ECB00000 ESBC U-Boot HEADER ESBC U-Boot HEADER 1024
E8C00000 ECC00000 2048
E8E00000 ECE00000 Bootscript Header Bootscript Header 1024
E8F00000 ECF00000 1024
E9000000 ED000000 uImage Heaer 1024
Table continues on the next page...
[5] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016232 NXP Semiconductors
Table 43. Memory map for P3/P4/P5/T1_T2_T4 platforms (continued)
Address(NOR vBank0)
Address (NORAlternateBank)[5]
Definition
(Chain of Trust)
Definition
(Chain of Trust withConfidentiality)
SizeReserved(KB)
E9100000 ED100000 DTB Header 1024
E9200000 ED200000 Rootfs Header 1024
E9300000 ED300000 Rootfs Rootfs 29696
EC020000 E8020000 uImage
(ENCAPSULATED)
8064
EC800000 E8800000 DTB
(ENCAPSULATED)
1024
ED300000 E9300000 Rootfs
(ENCAPSULATED)
29696
EFF20000 EBF20000 u-boot env u-boot env
(current bank)
128
EFF40000 EBF40000 u-boot u-boot 768
Chain Of Trust Boot Script Used as per Address Map
esbc_validate 0xE9000000esbc_validate 0xE9100000esbc_validate 0xE9200000bootm 0xE8020000 0xE9300000 0xE8800000
B4 platforms
Table 44. Memory map for B4 platforms
Address(NOR vBank 0)
Address(NORAlternateBank)[6]
Definition
(Chain of Trust)
Definition
(Chain of Trust withConfidentiality)
SizeReserved(KB)
EC000000 EE000000 RCW RCW 128
Table continues on the next page...
[5] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
[6] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
[6] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 233
Table 44. Memory map for B4 platforms (continued)
Address(NOR vBank 0)
Address(NORAlternateBank)[6]
Definition
(Chain of Trust)
Definition
(Chain of Trust withConfidentiality)
SizeReserved(KB)
EC020000 EE020000 uImage uImage 7040
EC700000 EE700000 Bootscript Bootscript 1024
EC800000 EE800000 DTB DTB 1024
EC900000 EE900000 1024
ECA00000 EEA00000 1024
ECB00000 EEB00000 ESBC U-Boot HEADER ESBC U-Boot HEADER 1024
ECC00000 EEC00000 Bootscript Header Bootscript Header 1024
ECD00000 EED00000 uImage Heaer 1024
ECE00000 EEE00000 Rootfs Header 1024
ECF00000 EEF00000 DTB Header 1024
ED300000 EF300000 DTB
(Encapsulated)
1024
ED500000 EF500000 uImage
(Encapsulated )
10496
EE020000 EC020000 rootfs/
rootfs (ENCAPSULATED)
31232
EFF20000 EDF20000 u-boot env u-boot env 128
EFF40000 EDF40000 u-boot u-boot 768
To use 512KB u-boot, change u-boot address from xxx40000 to xxx80000.
NOTE
Chain Of Trust Boot Script Used as per Address Map
esbc_validate 0xECD00000esbc_validate 0xECE00000esbc_validate 0xECF00000bootm 0xEC020000 0xEE020000 0xEC800000
LS1020
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016234 NXP Semiconductors
Table 45. Memory map for LS1 platforms
Address NOR(vBank0)
Address (NORAlternate Bank)[7]
Definition
(Chain of Trust)
SizeReserved(KB)
60000000 64000000 RCW 128
60020000 64020000 DTB 256
60060000 64060000 Bootscript 128
60080000 64080000 ESBC U-Boot HEADER 128
600A0000 640A0000 Bootscript Header 128
60100000 64100000 ESBC U-Boot 1024
60200000 64200000 uImage 8192
60A00000 64A00000 Rootfs 54272
63F00000 67F00000 uImage Header 128
63F20000 67F20000 DTB Header 128
63F40000 67F40000 rootfs Header 128
Chain Of Trust Boot Script Used as per Address Map
esbc_validate 0x63F20000esbc_validate 0x63F00000esbc_validate 0x63F40000bootm 0x60200000 0x60A00000 0x60020000
LS1043
Table 46. Memory map for LS1043 platforms
AddressNOR(vBank 0)
Address (NORAlternate Bank)[8]
Definition
(Chain of Trust)
SizeReserved(KB)
60000000 64000000 RCW 128
60060000 64060000 Bootscript 128
60080000 64080000 ESBC U-Boot HEADER 128
Table continues on the next page...
[7] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
[8] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 235
Table 46. Memory map for LS1043 platforms (continued)
AddressNOR(vBank 0)
Address (NORAlternate Bank)[8]
Definition
(Chain of Trust)
SizeReserved(KB)
600A0000 640A0000 Bootscript Header 128
600C0000 640C0000 PPA Header 128
60100000 64100000 ESBC U-Boot 1024
60500000 64500000 PPA FIT Image 2048
60A00000* 64A00000* Kernel FIT Image 54272
63F40000 64F40000 kernel Header 128
* For LS1043 Bootscript, kernel image must be copied to DDR address 0x81000000 before issuing
esbc_validate command.
NOTE
Chain of Trust Boot Script Used as per Address Map
# Copy the Kernel Image from Flash to DDRcp.b 0x60A00000 0x81000000 0x3500000
# Validate the Kernel Image (The header has Image address as 0x81000000)esbc_validate 0x63F40000
# Boot the validated Kernel FIT Image.setenv bootargs "console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500";setenv fdt_high "0xffffffffffffffff";setenv initrd_high "0xffffffffffffffff";
bootm $img_addr
LS1012
* For QSPI flash banking support on LS1012, please refer to [QorIQ LS1012A SDK vX.X-->Software
Deployment Guides-->Boards--><board-name>-->Flash Bank Usage].
NOTE
[8] Address to be used for loading the images in case of working in Development mode with Non-Secure Boot images onBank 0.
[9] QSPI by default works in 64bit Big Endian as XIP memory. So the data has to be 64 bit byte swapped before loadingon QSPI.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016236 NXP Semiconductors
Table 47. Memory map for LS1012 platform
Address QSPI[9] Definition
(Chain of Trust)
Size Reserved (KB)
40000000 RCW 128
40060000 Bootscript 128
40080000 ESBC U-Boot HEADER 128
400C0000 Bootscript Header 128
40100000 ESBC U-Boot 1024
40480000 PPA Header 128
40500000 PPA FIT Image 2048
40A00000[10] Kernel FIT Image/ Kernel FIT Image(ENCAPSULATED)
40960
43200000 kernel Header 128
* For LS1012 Bootscript, kernel image must be copied to DDR address 0x81000000 before issuing
esbc_validate command.
NOTE
Chain of Trust Boot Script Used as per Address Map
# Copy the Kernel Image from Flash to DDRcp.b 0x40A00000 0x81000000 0x2800000
# Validate the Kernel Image (The header has Image address as 0x81000000)esbc_validate 0x43200000
# Boot the validated Kernel FIT Image.setenv bootargs "console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500";setenv fdt_high "0xffffffffffffffff";setenv initrd_high "0xffffffffffffffff";
bootm $img_addr
Chain of Trust Boot Script with kernel image and its header placed on SD card
# Copy the Kernel Image from Flash to DDRmmc read 0x80000000 0x0 0x4mmc read 0x81000000 0x8 0x14000
# Validate the Kernel Image (The header has Image address as 0x81000000)esbc_validate 0x80000000
# Boot the validated Kernel FIT Image.
[10] The Kernel Image and its CSF Header may be placed on any other memory as well. The same must be copied toDDR before validation and Booting.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 237
setenv bootargs "console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500";setenv fdt_high "0xffffffffffffffff";setenv initrd_high "0xffffffffffffffff";
bootm $img_addr
Chain of Trust with Confidentiality
Encap Boot Script
# Encap kernel.itb imageblob enc 0x40A00000 0x80000000 0x27c0000 0x40000000
# Write kernel.itb (Encapsulated) image on QSPI flashsf probe 0:0sf erase 0xA00000 +0x2800000sf write 0x80000000 0xA00000 0x2800000
# Reset to boot again using Decap Boot Scriptreset
Decap Boot Script
# Read kernel.itb (Encapsulated) image from QSPI flashsf probe 0:0sf read 0x80000000 0xA00000 0x2800000
# Decap kernel.itb (Encapsulated) Imageblob dec 0x80000000 0x81000000 0x27c0000 0x40000000
# Validate the Kernel Image (The header has Image address as 0x81000000)esbc_validate 0x43200000
# Boot the validated Kernel FIT Image.setenv bootargs "console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500";setenv fdt_high "0xffffffffffffffff";setenv initrd_high "0xffffffffffffffff";
bootm $img_addr
P3/P5 NAND SECURE BOOT
Table 48. Memory Map for P3/P5 NAND SECURE BOOT
Description
(Chain of Trust)
Description
(Chain of Trust withConfidentiality)
Address onNAND
Address on DDR
(Image copied tofrom NAND)
Size
PBL.bin (RCW, PBI, U-Boot,U-boot Header)
PBL.bin (RCW, PBI, U-Boot,U-boot Header)
0x00000000 -- 0xD0000
Boot Script Header Boot Script Header 0x00800000 0x00010000 0x2000
Boot Script Boot Script 0x00802000 0x00012000 0x2000
uImage Header 0x00804000 0x00014000 0x2000
dtb Header 0x00806000 0x00016000 0x2000
Table continues on the next page...
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016238 NXP Semiconductors
Table 48. Memory Map for P3/P5 NAND SECURE BOOT (continued)
Description
(Chain of Trust)
Description
(Chain of Trust withConfidentiality)
Address onNAND
Address on DDR
(Image copied tofrom NAND)
Size
rootfs Header 0x00808000 0x00018000 0x2000
uImage uImage 0x06500000 0x01000000 0x410000
dtb dtb 0x06b00000 0x00c00000 0x9000
rootfs rootfs 0x02000000 0x02000000 0x2000000
uImage (Encapsulated) 0x06500000 0x10000000 0x410000
dtb (Encapsulated) 0x06b00000 0x10000000 0x9000
rootfs (Encapsulated) 0x02000000 0x10000000 0x2000000
Chain Of Trust Boot Script Used as per Address Map
#UImage and Headernand read 0x01000000 0x06500000 0x410000nand read 0x00014000 0x00804000 0x2000#Rootfs and HEadernand read 0x02000000 0x02000000 0x2000000nand read 0x00016000 0x00806000 0x2000#DTB and Headernand read 0x00c00000 0x06b00000 0x9000nand read 0x00018000 0x00808000 0x2000esbc_validate 0x00014000esbc_validate 0x00016000esbc_validate 0x00018000bootm 0x01000000 0x02000000 0x00c00000
9.2.14 Useful U-Boot and CCS CommandsThis section contains some useful commands for loading images via U-Boot (As per memory map defined in this document)and CCS commands to load the SRK Hash in shadow registers and get the core out of boot hold off in Development mode.
The CCS commands to connect and configure config chain might change with Board/Silicon
Revision. Kindly refer the board manual/CCS Guide in case of issues with CCS commands.The
commands provided below are for reference only. These will assist users in writing to SFP
mirror registers and getting the core out of Boot Hold Off.
NOTE
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 239
For permanently blowing the values (OTPMK, SRK HASH etc.) in SFP, refer to the details in Trust
Arch. User Guide. A brief summary of the steps is described below:
1. Ensure that PROG_SFP/POVDD signal is correctly asserted. This is usually controlled via a
switch or a jumper. (Refer Board schematic/manual for the same)
2. Write the required fuse values to the SFP mirror registers.
3. To permamnetly blow the fuses, write to 'PROGFB' in SFP Instruction Register (SFP_INGR).
Make sure that the values written in SFP mirror registers are correct before blowing the
fuses as once blown, the fuse values cannot be changed.
• To check if OTPMK is blown or not on the Silicon, check the bit 'OTPMK_ZERO' in the
SECMON_HPSR register. If the bit is set, it means OTPMK is zero i.e. OTPMK needs to be
blown.
• The OTPMK value can be generated using 'gen_otpmk_drbg' tool provided in CST.
• After writing the values in SFP mirror registers, check the hamming error register. Ensure that
the value is 0x0 i.e. no error is reported.
• Hamming error is reported in SecMon_HP Status Register (HPSR) for P3/P4/P5.
• For other SoC's, it is reported in SFP Secret Value Hamming Error Status Register
(SFP_SVHESR).
NOTE
T1/T2/T4
protect off all;setenv dir <tftp_path>tftp 1000000 $dir/rcw.bin; erase EC000000 +$filesize; cp.b 1000000 EC000000 $filesize;tftp 1000000 $dir/hdr_uboot.out;erase ECB00000 +$filesize; cp.b 1000000 ECB00000 $filesize;tftp 1000000 $dir/u-boot.bin;erase EBF40000 +$filesize; cp.b 1000000 EBF40000 $filesize ;
tftp 1000000 $dir/hdr_bs.out;erase 0xECE00000 +$filesize;cp.b 1000000 0xECE00000 $filesize;tftp 1000000 $dir/hdr_linux.out;erase 0xED000000 +$filesize;cp.b 1000000 0xED000000 $filesize;tftp 1000000 $dir/hdr_rootfs.out;erase 0xED200000 +$filesize;cp.b 1000000 0xED200000 $filesize;tftp 1000000 $dir/hdr_dtb.out;erase 0xED100000 +$filesize;cp.b 1000000 0xED100000 $filesize;
tftp 1000000 $dir/rootfs;erase 0xED300000 +$filesize;cp.b 1000000 0xED300000 $filesize;tftp 1000000 $dir/bootscript;erase 0xECA00000 +$filesize;cp.b 1000000 0xECA00000 $filesize;tftp 1000000 $dir/uImage.bin;erase 0xEC020000 +$filesize;cp.b 1000000 0xEC020000 $filesize;tftp 1000000 $dir/uImage.dtb;erase 0xEC800000 +$filesize;cp.b 1000000 0xEC800000 $filesize;
# Connect to CCS and configure Config Chainccs::config_chain {t4240 j2i2cs}display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem 0 0xfe314014 4 0 1ccs::display_mem 0 0xfe0e0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem 0 0xfe0e823c 4 0 <SRKH1>ccs::write_mem 0 0xfe0e8240 4 0 <SRKH2>ccs::write_mem 0 0xfe0e8244 4 0 <SRKH3>ccs::write_mem 0 0xfe0e8248 4 0 <SRKH4>ccs::write_mem 0 0xfe0e824c 4 0 <SRKH5>ccs::write_mem 0 0xfe0e8250 4 0 <SRKH6>ccs::write_mem 0 0xfe0e8254 4 0 <SRKH7>ccs::write_mem 0 0xfe0e8258 4 0 <SRKH8>
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016240 NXP Semiconductors
#Get the Core Out of Boot Hold-Offccs::write_mem 0 0xfe0e00e4 4 0 0x00000001
B4
protect off all;setenv dir <tftp_path>tftp 1000000 $dir/rcw.bin; erase EE000000 +$filesize; cp.b 1000000 EE000000 $filesize;tftp 1000000 $dir/hdr_uboot.out;erase EEB00000 +$filesize; cp.b 1000000 EEB00000 $filesize;tftp 1000000 $dir/u-boot.bin;erase EDF40000 +$filesize; cp.b 1000000 EDF40000 $filesize ;
tftp 1000000 $dir/hdr_bs.out;erase 0xEEC00000 +$filesize;cp.b 1000000 0xEEC00000 $filesize;tftp 1000000 $dir/hdr_linux.out;erase 0xEED00000 +$filesize;cp.b 1000000 0xEED00000 $filesize;tftp 1000000 $dir/hdr_rootfs.out;erase 0xEEE00000 +$filesize;cp.b 1000000 0xEEE00000 $filesize;tftp 1000000 $dir/hdr_dtb.out;erase 0xEEF00000 +$filesize;cp.b 1000000 0xEEF00000 $filesize;
tftp 1000000 $dir/rootfs;erase 0xEC020000 +$filesize;cp.b 1000000 0xEC020000 $filesize;tftp 1000000 $dir/bootscript;erase 0xEE700000 +$filesize;cp.b 1000000 0xEE700000 $filesize;tftp 1000000 $dir/uImage.bin;erase 0xEE020000 +$filesize;cp.b 1000000 0xEE020000 $filesize;tftp 1000000 $dir/uImage.dtb;erase 0xEE800000 +$filesize;cp.b 1000000 0xEE800000 $filesize;
# Connect to CCS and configure Config Chainccs::config_chain {b4860 j2i2cs}display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem 0 0xfe314014 4 0 1ccs::display_mem 0 0xfe0e0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem 0 0xfe0e823c 4 0 <SRKH1>ccs::write_mem 0 0xfe0e8240 4 0 <SRKH2>ccs::write_mem 0 0xfe0e8244 4 0 <SRKH3>ccs::write_mem 0 0xfe0e8248 4 0 <SRKH4>ccs::write_mem 0 0xfe0e824c 4 0 <SRKH5>ccs::write_mem 0 0xfe0e8250 4 0 <SRKH6>ccs::write_mem 0 0xfe0e8254 4 0 <SRKH7>ccs::write_mem 0 0xfe0e8258 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Offccs::write_mem 0 0xfe0e00e4 4 0 0x00000001
P3/P4/P5
protect off all;setenv dir <tftp_path>tftp 1000000 $dir/rcw.bin; erase EC000000 +$filesize; cp.b 1000000 EC000000 $filesize;tftp 1000000 $dir/hdr_uboot.out;erase ECB00000 +$filesize; cp.b 1000000 ECB00000 $filesize;tftp 1000000 $dir/u-boot.bin;erase EBF40000 +$filesize; cp.b 1000000 EBF40000 $filesize ;
tftp 1000000 $dir/hdr_bs.out;erase 0xECE00000 +$filesize;cp.b 1000000 0xECE00000 $filesize;tftp 1000000 $dir/hdr_linux.out;erase 0xED000000 +$filesize;cp.b 1000000 0xED000000 $filesize;tftp 1000000 $dir/hdr_rootfs.out;erase 0xED200000 +$filesize;cp.b 1000000 0xED200000 $filesize;tftp 1000000 $dir/hdr_dtb.out;erase 0xED100000 +$filesize;cp.b 1000000 0xED100000 $filesize;
tftp 1000000 $dir/rootfs;erase 0xED300000 +$filesize;cp.b 1000000 0xED300000 $filesize;tftp 1000000 $dir/bootscript;erase 0xECA00000 +$filesize;cp.b 1000000 0xECA00000 $filesize;
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 241
tftp 1000000 $dir/uImage.bin;erase 0xEC020000 +$filesize;cp.b 1000000 0xEC020000 $filesize;tftp 1000000 $dir/uImage.dtb;erase 0xEC800000 +$filesize;cp.b 1000000 0xEC800000 $filesize;
# Connect to CCS and configure Config Chainccs::config_chain p3040display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem 0 0xfe314014 4 0 1ccs::display_mem 0 0xfe0e0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem 0 0xfe0e807c 4 0 <SRKH1>ccs::write_mem 0 0xfe0e8080 4 0 <SRKH2>ccs::write_mem 0 0xfe0e8084 4 0 <SRKH3>ccs::write_mem 0 0xfe0e8088 4 0 <SRKH4>ccs::write_mem 0 0xfe0e808c 4 0 <SRKH5>ccs::write_mem 0 0xfe0e8090 4 0 <SRKH6>ccs::write_mem 0 0xfe0e8094 4 0 <SRKH7>ccs::write_mem 0 0xfe0e8098 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Offccs::write_mem 0 0xfe0e00e4 4 0 0x00000001
LS1020
protect off all;setenv path <tftp_path>tftp 80000000 $path/rcw.bin;erase 64000000 +$filesize;cp.b 80000000 64000000 $filesize;tftp 80000000 $path/hdr_uboot.out;erase 64080000 +$filesize;cp.b 80000000 64080000 $filesize;tftp 80000000 $path/u-boot.bin;erase 64100000 +$filesize;cp.b 80000000 64100000 $filesize;
tftp 80000000 $path/hdr_bs.out;erase 640A0000 +$filesize;cp.b 80000000 640A0000 $filesize;tftp 80000000 $path/bootscript;erase 64060000 +$filesize;cp.b 80000000 64060000 $filesize;
tftp 80000000 $path/hdr_dtb.out;erase 67F20000 +$filesize;cp.b 80000000 67F20000 $filesize;tftp 80000000 $path/uImage.dtb;erase 64020000 +$filesize;cp.b 80000000 64020000 $filesize;
tftp 80000000 $path/hdr_linux.out;erase 67F00000 +$filesize;cp.b 80000000 67F00000 $filesize;tftp 80000000 $path/uImage.bin;erase 64200000 +$filesize;cp.b 80000000 64200000 $filesize;
tftp 80000000 $path/hdr_rootfs.out;erase 67F40000 +$filesize;cp.b 80000000 67F40000 $filesize;tftp 80000000 $path/rootfs;erase 64a00000 +$filesize;cp.b 80000000 64a00000 $filesize;
# Connect to CCS and configure Config Chainccs::config_server 0 10000ccs::config_chain {ls1020a dap sap2}display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem <dap chain pos> 0x1e90014 4 0 4ccs::display_mem <dap chain pos> 0x1ee0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem <dap chain pos> 0x1e80254 4 0 <SRKH1>ccs::write_mem <dap chain pos> 0x1e80258 4 0 <SRKH2>ccs::write_mem <dap chain pos> 0x1e8025c 4 0 <SRKH3>ccs::write_mem <dap chain pos> 0x1e80260 4 0 <SRKH4>ccs::write_mem <dap chain pos> 0x1e80264 4 0 <SRKH5>
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016242 NXP Semiconductors
ccs::write_mem <dap chain pos> 0x1e80268 4 0 <SRKH6>ccs::write_mem <dap chain pos> 0x1e8026c 4 0 <SRKH7>ccs::write_mem <dap chain pos> 0x1e80270 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Offccs::write_mem <dap chain pos> 0x1ee00e4 4 0 0x00000001
LS1043
protect off all;setenv path <tftp_path>tftp 80000000 $path/rcw.bin;erase 64000000 +$filesize;cp.b 80000000 64000000 $filesize;tftp 80000000 $path/hdr_uboot.out;erase 64080000 +$filesize;cp.b 80000000 64080000 $filesize;tftp 80000000 $path/u-boot.bin;erase 64100000 +$filesize;cp.b 80000000 64100000 $filesize;
tftp 80000000 $path/hdr_bs.out;erase 640A0000 +$filesize;cp.b 80000000 640A0000 $filesize;tftp 80000000 $path/bootscript;erase 64060000 +$filesize;cp.b 80000000 64060000 $filesize;
tftp 80000000 $path/hdr_kernel.out;erase 67F40000 +$filesize;cp.b 80000000 67F40000 $filesize;tftp 80000000 $path/kernel.itb;erase 64a00000 +$filesize;cp.b 80000000 64a00000 $filesize;
tftp 80000000 $path/hdr_ppa.out;erase 640C0000 +$filesize;cp.b 80000000 640C0000 $filesize;tftp 80000000 $path/ppa.itb;erase 64500000 +$filesize;cp.b 80000000 64500000 $filesize;
# Connect to CCS and configure Config Chainccs::config_server 0 10000ccs::config_chain {ls1043a dap sap2}display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem <dap chain pos> 0x1e90014 4 0 4ccs::display_mem <dap chain pos> 0x1ee0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem <dap chain pos> 0x1e80254 4 0 <SRKH1>ccs::write_mem <dap chain pos> 0x1e80258 4 0 <SRKH2>ccs::write_mem <dap chain pos> 0x1e8025c 4 0 <SRKH3>ccs::write_mem <dap chain pos> 0x1e80260 4 0 <SRKH4>ccs::write_mem <dap chain pos> 0x1e80264 4 0 <SRKH5>ccs::write_mem <dap chain pos> 0x1e80268 4 0 <SRKH6>ccs::write_mem <dap chain pos> 0x1e8026c 4 0 <SRKH7>ccs::write_mem <dap chain pos> 0x1e80270 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Offccs::write_mem <dap chain pos> 0x1ee00e4 4 0 0x00000001
LS1012
# Steps to sign images and swap images and corresponding headers before writing to QSPI memory.# Copy secure boot release binaries as:# RCW binary: PBL_0x35_0x08_800_250_1000_sben.bin# u-boot.bin-qspi-secure-boot -> u-boot.bin# ppa-unswap.itb -> ppa.itb# kernel-ls1012ardb.itb -> kernel.itb
./uni_sign input_files/uni_sign/ls1012/input_uboot_qspi_secure/bin/tclsh ./byte_swap.tcl u-boot.bin u-boot_swap.bin 8/bin/tclsh ./byte_swap.tcl hdr_uboot.out hdr_swap_uboot.out 8
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 243
./uni_sign input_files/uni_sign/ls1012/input_ppa_secure/bin/tclsh ./byte_swap.tcl ppa.itb ppa_swap.itb 8/bin/tclsh ./byte_swap.tcl hdr_ppa.out hdr_swap_ppa.out 8
./uni_sign input_files/uni_sign/ls1012/input_bootscript_secure/bin/tclsh ./byte_swap.tcl bootscript bootscript_swap 8/bin/tclsh ./byte_swap.tcl hdr_bs.out hdr_swap_bs.out 8
./uni_sign input_files/uni_sign/ls1012/input_kernel_secure/bin/tclsh ./byte_swap.tcl kernel.itb kernel_swap.itb 8/bin/tclsh ./byte_swap.tcl hdr_kernel.out hdr_swap_kernel.out 8
# U-boot Commands:
protect off all;setenv path <tftp_path>
# To select QSPI flash bank2i2c mw 0x24 0x7 0xfc; i2c mw 0x24 0x3 0xf5;
# Write all the images on QSPI flash bank2sf probe 0:0
tftp 0x80000000 $path/PBL_0x35_0x08_800_250_1000_sben.bin; sf erase 0x0 20000; sf write 0x80000000 0x0 20000tftp 0x80000000 $path/hdr_swap_uboot.out; sf erase 0x80000 20000; sf write 0x80000000 0x80000 20000tftp 0x80000000 $path/u-boot_swap.bin; sf erase 0x100000 100000; sf write 0x80000000 0x100000 100000
tftp 0x80000000 $path/hdr_swap_bs.out; sf erase 0xC0000 20000; sf write 0x80000000 0xC0000 20000tftp 0x80000000 $path/bootscript_swap; sf erase 0x60000 20000; sf write 0x80000000 0x60000 20000
tftp 0x80000000 $path/hdr_swap_kernel.out; sf erase 0x3200000 20000; sf write 0x80000000 0x3200000 20000tftp 0x80000000 $path/kernel_swap.itb; sf erase 0xA00000 0x2800000; sf write 0x80000000 0xA00000 0x2800000
tftp 0x80000000 $path/hdr_swap_ppa.out; sf erase 0x480000 20000; sf write 0x80000000 0x480000 20000tftp 0x80000000 $path/ppa_swap.itb; sf erase 0x500000 40000; sf write 0x80000000 0x500000 40000
# Reset board to run secure boot.reset
# CCS Commands:
# Connect to CCS and configure Config Chainccs::config_server 0 10000ccs::config_chain {ls1043a dap sap2}display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registersccs::display_mem <dap chain pos> 0x1e90014 4 0 4ccs::display_mem <dap chain pos> 0x1ee0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registersccs::write_mem <dap chain pos> 0x1e80254 4 0 <SRKH1>ccs::write_mem <dap chain pos> 0x1e80258 4 0 <SRKH2>ccs::write_mem <dap chain pos> 0x1e8025c 4 0 <SRKH3>ccs::write_mem <dap chain pos> 0x1e80260 4 0 <SRKH4>ccs::write_mem <dap chain pos> 0x1e80264 4 0 <SRKH5>
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016244 NXP Semiconductors
ccs::write_mem <dap chain pos> 0x1e80268 4 0 <SRKH6>ccs::write_mem <dap chain pos> 0x1e8026c 4 0 <SRKH7>ccs::write_mem <dap chain pos> 0x1e80270 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Offccs::write_mem <dap chain pos> 0x1ee00e4 4 0 0x00000001
9.2.15 Trust Architecture and SFP Information
SoC Trust Arch.Version
SFPVersion
POVDD DRVR OTPMK SNVS/SFPRegister tocheckHammingError
Algo (CST) Register tocheckHammingError
Algo (CST) Register tocheckHammingError
P4080 rev1 1 1 1.5 V A None/Simulation
1 SNVS SecMon_HPStatus(HPSR)
P4080 rev2 1 1.1 1.5 V B None/Simulation
1 SNVS
P4080 rev3 1 2.2 1.5 V B None/Simulation
1 SNVS
P3041 1.1 2 1.5 V B None/Simulation
1 SNVS
P5020 1.1 2 1.5 V B None/Simulation
1 SNVS
P5040 1.1 2.2 1.5 V B None/Simulation
1 SNVS
P5021 1.1 2.2 1.5 V B None/Simulation
1 SNVS
T4240 rev1 2 3.1 1.89 V A SFP 2 SFP SFP SecretValueHammingError StatusRegister(SFP_SVHESR)
T4240 rev2 2 3.2 1.89 V A SFP 2 SFP
B4860 rev1 2 3.1 1.89 V A SFP 2 SFP
B4860 rev2 2 3.2 1.89 V A SFP 2 SFP
T2080 2 3.2 1.89 V A SFP 2 SFP
T1040 2 3.2 1.89 V A SFP 2 SFP
T1023 2 3.2 1.89 V A SFP 2 SFP
LS1020A 2.1 3.3 1.89 V A SFP 2 SFP
LS1043A 2.1 3.3 1.89 V A SFP 2 SFP
LS1012A 2.1 3.3 1.89 V A SFP 2 SFP
9.2.16 Using QCVS Tool (Secure Boot From NAND)Use Freescale’s QCVS tool for adding the hdr_uboot.out and u-boot.bin in terms of ALT_CONFIG_WRITE PBI commandsat required addresses. The below screenshots describe the usage of QCVS Tool.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 245
1. Import rcw.bin from SDK in QCVS Tool.
2. Add ACS Data hdr_uboot.out @ 0xF00000.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016246 NXP Semiconductors
3. Add ACS Data u-boot.bin @0xF40000.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 247
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016248 NXP Semiconductors
4. Make Sure that the output format is Binary.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 249
5. Generate Processor Expert Code to get PBL.bin.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016250 NXP Semiconductors
.
Boot Loaders
Secure Boot: PBL Based Platforms
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 251
Chapter 10Virtualization
10.1 KVM/QEMU
10.1.1 KVM/QEMU Release NotesCopyright (C) 2013-2016 Freescale Semiconductor, Inc.
Freescale KVM/QEMU Release Notes
06/23/2016
Overview
--------
This document describes new features, current limitations, and
known issues in KVM and QEMU for NXP QorIQ LS1012A release.
New Features
------------
Linux and QEMU versions:
o KVM is based on the LS1012A release Linux kernel
o QEMU is based on QEMU 2.4.0
Only basic functionality is supported: basic guest boot without I/O.
Limitations
---------------------------------------
The following items describe known limitations with this release of KVM/QEMU:
o VFIO-PCI is not supported
o 64K page size in the host kernel is not supported.
Privacy Terms of Use Terms of Sale Feedback
©2006-2016 NXP Semiconductors. All rights reserved.
10.1.2 KVM for ARM Architecture Users Guide and Reference
10.1.2.1 Introduction to KVM and QEMU10.1.2.1.1 OverviewThis document is a guide and tutorial to building and using KVM (Kernel-based Virtual Machine) on NXP QorIQ SoCs.
Virtualization provides an environment that enables running multiple operating systems on a single computer system.Virtualization uses hardware and software technologies together to enable this by providing an abstraction layer betweensystem hardware and the OS. The isolated environment in which OSes run is known as a virtual machine (or VM). Theabstraction layer that manages all this is referred to as a hypervisor or virtual machine manager. The hypervisor layer
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016252 NXP Semiconductors
operates at a privilege level higher than that of the operating systems, thus enabling it to enforce system security, ensure thatvirtual machines cannot interfere with each other, and transparently provide other services such as I/O sharing to the VM.
Figure 20.
KVM is a Linux kernel driver that together with QEMU, an open source machine emulator, provides an open sourcevirtualization platfiorm based on Linux. KVM and QEMU together act as a virtual machine manager that can boot and runoperating systems in virtual machines. See Figure below.
In this document the term host kernel refers to the underlying instance of Linux with the KVM driver that acts as the hypervisor.The term guest refers to the operating system, such as Linux, that runs in a virtual machine. A virtual machine will be referredto as a "VM".
Figure 21.
NXP QorIQ SoCs based on ARM v7 and ARM v8 CPUs are supported.
10.1.2.1.2 Organization of this DocumentThis document is organized as follows:
• Introduction to KVM and QEMU on page 252 provides an introduction to KVM/QEMU, including overview informationand references.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 253
• Building QEMU and KVM on page 257 provides information on how to build QEMU and the Linux kernel with KVM.
• Using QEMU and KVM on page 262 describes how to use KVM/QEMU, including how to invoke QEMU to start virtualmachines and how to set up virtual I/O and passthrough I/O devices.
• Virtual machine reference on page 266 provides a reference for virtual machines-- details about initial VM state, virtualCPUs, and virtual I/O devices. This information is relevant when porting an OS or device driver to a KVM-based virtualmachine.
• Debugging virtual machines on page 269 describes facilities available for debugging software running in a virtualmachine.
• KVM/QEMU How-to's on page 271 provides a set of examples for common tasks.
10.1.2.1.3 Virtual Machine OverviewA guest OS running in a KVM/QEMU virtual machine "sees" a hardware environment similar to running on a physical board.The guest sees CPUs, memory, and a number of I/O devices. Some aspects of this environment are virtualized (emulatedin software by KVM/QEMU) but this virtualization is mostly transparent to the guest, and changes to the guest are typicallynot required to run in a virtual machine.
The number of virtual machines that can be run simultaneously is only limited by the amount of available resources (like anyother application on Linux).
KVM/QEMU implements a generic virt machine which is described completely by the device tree. The virtual machinecontains the following resources:
• one or more ARMv7/ARMv8 virtual CPUs
• memory
• virtual console based on an emulated PL011
• virtio over PCI (used for virtual devices such as block and network devices)
• ARM Virtual Generic Interrupt Controller
• ARM virtual timer and counter
10.1.2.1.4 Introduction to KVM and QEMUQEMU (pronounced KYOO-em-yoo) is a software-based machine emulator that emulates a variety of CPUs and hardwaresystems. KVM is a Linux kernel device driver that provides virtual CPU services to QEMU. The two software componentswork together as a virtual machine manager.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016254 NXP Semiconductors
Figure 22.
QEMU is a Linux user-space application that runs on the host Linux instance and is used to start and manage a virtualmachine. QEMU provides the following:
• A command line interface that provides extensive customization and configuration of a virtual machine when it isstarted-- e.g. type of VM, which images to load, and how virtual devices are configured
• Loading of all images needed by the guest-- e.g kernel images, root filesystem, guest device tree
• Setting the initial state of the VM and booting the guest
• Virtual I/O services, such as virtual network interfaces and virtual disks
• Debug services-which provide the capability to debug a guest OS using GDB (similar to a virtual JTAG)
KVM is a device driver in the Linux kernel whose key role in the VM architecture is to provide virtual CPU services. Theseservices involve two aspects:
1. First, KVM provides an API set that QEMU uses to set and get the state of virtual CPUs and run them. For example,QEMU sets the initial values of the CPU's registers before starting the VM.
2. Second, after KVM starts a guest OS, certain operations (such as privileged instructions) performed by the OS causean exception (or exit) into the host Linux kernel that must be handled and processed by KVM. This handling of traps isreferred to as "emulation". These traps are transparent to the guest.
The KVM API is documented in the Linux kernel-- Documentation/virtual/kvm/api.txt.
KVM/QEMU supports virtual I/O which allows sharing of physical I/O devices by multiple VMs. Virtual network and blockI/O are supported. See For More Information on page 257 for references that provide additional information on virtio.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 255
10.1.2.1.5 Device Tree OverviewA device tree is a data structure that describes hardware resources such as CPUs, memory, and I/O devices. An device treeaware OS is passed a device tree which it reads to determine what hardware resources are available.
The host Linux kernel is booted first, typically by u-boot (an open source bootloader). U-boot passes the kernel a hardwaredevice tree that lists and describes all system hardware resources available to the host kernel (CPUs/cores, memory, interruptcontroller and I/O).
Similarly, when a guest OS is booted in a KVM/QEMU virtual machine, QEMU passes it a guest device tree that describesall the hardware resources in the VM. See Figure below.
Figure 23.
The guest device tree is generated by QEMU and is used to define the resources a virtual machine will see. The guest devicetree defines CPUs, memory, and I/O devices. QEMU places the guest device tree in the virtual machine's memory prior tostarting the virtual machine.
10.1.2.1.6 References[1] QEMU Emulator User Documentation: http://qemu.weilnetz.de/qemu-doc.html
[2] The Linux usage model for device tree data: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt
[3] Specification for virtio devices: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.pdf
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016256 NXP Semiconductors
10.1.2.1.7 For More InformationKVM
• KVM website: http://www.linux-kvm.org
• ARM VM specification: http://lwn.net/Articles/589122/
• Supporting KVM on ARM architecture: http://lwn.net/Articles/557132/
QEMU
• QEMU website: http://www.qemu.org/
Device Trees
• devicetree.org website: http://devicetree.org
• DTC, the device tree compiler is available at: http://git.jdl.com . DTC also includes a library called libfdt which can beused by software to parse device trees.
Virtio-- a framework for doing virtual I/O using KVM/QEMU
• http://www.ibm.com/developerworks/linux/library/l-virtio/
• http://ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf
• http://www.linux-kvm.org/wiki/images/d/dd/KvmForum2007%24kvm_pv_drv.pdf
• http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.pdf
Virtual Networking with QEMU
• http://wiki.qemu.org/Documentation/Networking
• http://www.linux-kvm.org/page/Networking
10.1.2.2 Building QEMU and KVM10.1.2.2.1 OverviewLinux with KVM enabled and QEMU can be built as part of the standard build process used to build the NXP SDK usingYocto.
They can also be built in a standalone manner outside of Yocto.
The build instructions in the sections that follow assume a working understanding of how to use Yocto to build the NXP SDK.Please refer to the Yocto documentation in the SDK.
10.1.2.2.2 Building Linux with KVM10.1.2.2.2.1 OverviewKVM is a component in the Linux kernel. KVM is not enabled in the default kernel configuration in the NXP SDK and KVMfeatures must be enabled using the kernel's menuconfig configuration utility prior to building the kernel.
In the sections that follow configuration options are described for both the host and guest Linux kernel. The host and guestkernels can be built separately, but it is possible to build a single Linux kernel image that can be used for both the host andthe guest.
The kernel configuration options described below would be the same if building the kernel standalone (outside of Yocto).
The following sections provide high level build information:
• Running menuconfig with Yocto - describes how to configure the kernel under Yocto
• Quick Start - Recommended Configuration Options - in a single step shows all the recommended configuration optionsto enable to build a kernel with virtual I/O enabled with the same kernel image serving as both host and guest.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 257
The following sections provide more detailed information on each KVM-related configuration option for host and guest:
• Host Kernel: Enabling KVM - describes the configuration options to enable KVM in the host kernel.
• Host Kernel: Enabling Virtual Networking - describes how to enable bridging and tun/tap in the host kernel which enablesvirtual networking.
• Guest Kernel: Enabling Network and Block Virtual I/O - describes how to enable virtual I/O in the guest kernel.
• Guest kernel: Enabling console - describes how to enable the console for the guest kernel
10.1.2.2.2.2 Running menuconfig with YoctoThe prerequisite and starting point for building the Linux kernel with KVM enabled is performing a standard kernel build withYocto.
$ bitbake virtual/kernel
To change the kernel configuration options use the Linux standard menuconfig utility. To invoke menuconfig under Yocto dothe following from the Yocto build environment:
$ bitbake -c menuconfig virtual/kernel
Note: Depending on what build steps may have been done previously, it may be necessary to invoke the command 'bitbake-c clean virtual/kernel' prior to running the menuconfig command.
The result will be an xterm that appears that displays the menuconfig screen:
Figure 24.
10.1.2.2.2.3 Quick Start - Recommended Configuration OptionsThe steps below show all the recommended configuration options to enable to build a kernel with virtual I/O enabled with thesame kernel image serving as both host and guest. The sections that follow explain these options in further detail.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016258 NXP Semiconductors
Note: The configuration options are enabled by default in the kernel configuration. However, they are are listed here forreference.
1. From the main menuconfig window enable virtualization:
[*] Virtualization
2. In the virtualization menu enable the following options:
[*] Kernel-based Virtual Machine (KVM) support
3. Enable network bridging
Networking support ---> Networking options ---> <*> 802.1d Ethernet Bridging
4. Enable virtio PCI
Device Drivers ---> Virtio drivers ---> <*> PCI driver for virtio devices
5. Enable virtio for block devices
Device Drivers ---> [*] Block devices ---> <*> Virtio block driver
6. Enable virtio for network devices
[*] Network core driver support <*> Universal TUN/TAP device driver support <*> Virtio network driver
7. Enable vhost for virtio network devices
[*] Virtualization <*> Host kernel accelerator for virtio net
8. Enable Huge TLB file support
File Systems ---> Pseudo filesystems ---> [*] Huge TLB file system support
9. Enable guest serial support
Device Drivers ---> Character devices ---> Serial drivers ---> <*> ARM AMBA PL011 serial port support [*] Support for console on AMBA serial port
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 259
10.1.2.2.2.4 Host Kernel: Enabling KVMThis section describes the core, basic options needed to enable KVM in the host kernel. KVM is enabled in the host kernelunder the virtualization menu of the main kernel menuconfig window.
[*] Virtualization
Core KVM support is enabled as follows:
[*] Kernel-based Virtual Machine (KVM) support
10.1.2.2.2.5 Host Kernel: Enabling Virtual NetworkingVirtual network interfaces on page 265 describes how virtual networking can be used to give each VMs a virtual networkinterface which share physical network interfaces in Linux.
One common approach to configuring virtual networking is for QEMU to use a tun/tap interface bridged to a physical networkinterface. To do this Ethernet bridging and the kernel's tun/tap features must be enabled in the host kernel:
Networking support ---> Networking options ---> <*> 802.1d Ethernet BridgingDevice Drivers ---> [*] Network core driver support <*> Universal TUN/TAP device driver support
In order to enable vhost-net, the following config option should ne enabled:
[*] Virtualization <*> Host kernel accelerator for virtio net
10.1.2.2.2.6 Guest Kernel: Enabling Network and Block Virtual I/OVirtio is a framework for doing paravirtualized I/O using QEMU/KVM. In order to support communication between guest andhypervisor virtio uses a PCI transport protocol.
Below the kernel configuration options are shown to enable virtio-pci:
Device Drivers ---> Virtio drivers ---> <*> PCI driver for virtio devices
Below the kernel configuration options are shown to enable virtio drivers in the Linux kernel to support networking I/O andblock (disk) I/O.
Device Drivers ---> [*] Network device support ---> <*> Virtio network driverDevice Drivers ---> [*] Block devices ---> <*> Virtio block driver
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016260 NXP Semiconductors
10.1.2.2.2.7 Guest kernel: Enabling consoleQEMU emulates an AMBA/PL011 console.
Below the kernel configuration options are shown to enable console:
Device Drivers ---> Character devices ---> Serial drivers ---> <*> ARM AMBA PL011 serial port support [*] Support for console on AMBA serial port
10.1.2.2.3 Building QEMUQEMU is a standard package in the QorIQ SDK and will be built for the following Yocto build configurations:
• fsl-image-virt
• fsl-image-full
To add QEMU to another Yocto build configuration, edit the conf/local.conf file and add the IMAGE_INSTALL_append variable:
IMAGE_INSTALL_append = " qemu"
After a Yocto build is complete, the target root filesystem will contain the following QEMU components that are required forusing KVM/QEMU:
/usr/bin/qemu-system-arm # QEMU executable for ARMv7 platforms/usr/bin/qemu-system-aarch64 # QEMU executable for ARMv8 platforms
QEMU can be built as an individual component in the Yocto environment as well, it's package name is "qemu".
To clean and rebuild QEMU from the Yocto build environment:
$ bitbake -c clean qemu$ bitbake qemu
10.1.2.2.4 Creating a host Linux root filesystem10.1.2.2.4.1 OverviewCreating a Linux root filesystem is out of the scope of this document. Please reference the NXP QorIQ SDK for moreinformation on how to create root filesystems with Yocto. This section describes the software components needed on a rootfilesystem to use KVM/QEMU.
The host root filesystem is the filesystem booted by the host kernel. The host rootfs is distinct from a guest root filesystemwhich may be needed by certain guest such as Linux.
A host root filesystem capable of running Linux as a guest needs the following components:
• Guest Linux kernel image (Image or zImage). Note:Only zImage is supported for ARMv7 platforms.
• QEMU executable
• Guest root filesystem
• Dynamic libraries needed by QEMU (libfdt, libz, glib2.0). These libraries are standard components in a Yocto-createdrootfs.
Example host root filesystem layout with the required components to boot a Linux guest (excluding shared libraries):
/root/zImage # guest Linux kernel/root/rootfs.ext2.gz # guest rootfs
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 261
/usr/bin/qemu-system-arm # QEMU for ARMv7 platforms/usr/bin/qemu-system-aarch64 # QEMU for ARMv8 platforms
10.1.2.2.4.2 Adding Images to a Root Filesystem with YoctoIf using Yocto, as described in Building QEMU on page 261, the root filesystem produced by the build process will containQEMU and the example guest device trees provided by the SDK.
A feature is also available with Yocto and the SDK to add arbitrary additional images to the root filesystem. This is done usingthe merge-files component in Yocto.
Any files and directories copied to the "merge" directory (see path below) will be copied to the root filesystem created byYocto:
meta-freescale/recipes-extended/merge-files/merge-files/merge
After populating the merge directory with the desired files, clean and rebuild the rootfs. See example below for the fsl-image-core image type:
$ bitbake -c install -f merge-files$ bitbake merge-files$ bitbake fsl-image-core
See the how-to article Quick-start Steps to Build and Deploy KVM Using Yocto on page 271 for a more detailed example.
10.1.2.3 Using QEMU and KVM10.1.2.3.1 Overview of Using QEMUQEMU is used to start virtual machines and is built and included in the rootfs created by Yocto. The QEMU application isnamed qemu-system-arm (for 32 bit platforms) or qemu-system-aarch64 (for 64 bit platforms).
In addition to the QEMU executable itself, the following is a list of the minimum components that must be available on thetarget system to launch a virtual machine using QEMU:
• The host Linux kernel on the target must be built with virtualization support for KVM enabled as described in BuildingLinux with KVM on page 257.
• A guest OS kernel image (e.g. zImage or Image for Linux)
• A guest root filesystem (If needed by the guest OS. For example, a Linux guest requires a rootfs.)
• Recommended: A working network interface (to interface to the guest's console and the QEMU monitor)
See the article Quick-start Steps to Run KVM Using Hugetlbfs on page 273 for an example of how to boot a virtual machinewith a rootfs created by Yocto.
The QEMU Emulator User Documentation [1] (see References on page 256) contains complete documentation for all QEMUcommand line arguments. The Table below summarizes some of the flags and arguments for basic operation.
Table 49.
Argument Descriptions
-enable-kvm Specifies that the Linux KVM should be used for the virtual machine's CPUs
Table continues on the next page...
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016262 NXP Semiconductors
Table 49. (continued)
Argument Descriptions
-nographic Disables graphical output-console will be on emulated serial port.
-M machine Specifies the type of virtual machine. One value is supported:
• virt
-smp cpu_count Specifies the number of CPUs for the virtual machine.
The number of virtual CPUs allowed is the same as the value of the CONFIG_NR_CPUSconfig option in the host Linux kernel. To see this value issue the following command fromLinux on the target board:
zcat /proc/config.gz | grep NR_CPUS
-kernel file Specifies the guest OS image. The supported image types are in Image format (the genericLinux kernel binary image file) and zImage (a compressed version of the Linux kernelimage)
-initrd file Specifies a root filesystem image
-append cmdline Use cmdline as the guest OS kernel command line (passed in the bootargs property ofthe /chosen node in the guest device tree)
-serial dev Redirects the virtual serial port to the host device dev. QEMU supports many possible hostdevices. Please refer to the QEMU User Documentation [1] (see References on page256) for complete details.
Note: if using a tcp device with the server option QEMU will wait for a connection to thedevice before continuing unless the nowait option is used.
-m megs Specifies the size of the VM's RAM in megabytes. This option is ignored if using directmapped memory.
.
-mem-path path Specifies the path to a file from which to allocate memory for the virtual machine. Thisoption should be used to allocate memory from hugetlbfs.
-monitor dev Redirects the QEMU monitor to the host device dev. QEMU supports many possible hostdevices. Please refer to the QEMU User Documentation [1] (see References on page256) for complete details.
Note: if using a tcp device with the server option QEMU will wait for a connection to thedevice before continuing unless the nowait option is used.
-S Do not start CPU at startup (you must type 'c' in the monitor). This can be useful ifdebugging.
-gdb dev Wait for gdb connection on device dev
Table continues on the next page...
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 263
Table 49. (continued)
Argument Descriptions
-drive [args] Used to create a virtual disk in a virtual machine.
.
-netdev [args]
-device virtio-net-device[args]
The -netdev and -device virtio-net-device arguments specify the network backend andfront end for createing virtual network devices in virtual machines.
-cpu model Select CPU model. Only one model is supported:
• host
Below is an example command line a user would run from the host Linux to start virt virtual machine booting a Linux guest:
ARMv7:
qemu-system-arm -enable-kvm -m 512 -nographic -cpu host -machine type=virt -kernel /boot/zImage -serial tcp::4446,server,telnet -initrd /boot/guest.rootfs.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio
ARMv8:
qemu-system-aarch64 -enable-kvm -m 512 -nographic -cpu host -machine type=virt -kernel /boot/Image -serial tcp::4446,server,telnet -initrd /boot/guest.rootfs.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio
10.1.2.3.2 Virtual Machine MemoryQEMU allocates and loads images into a VM's memory prior to starting the VM. The amount of memory needed for a virtualmachine will be dependent on the workload to be run in the VM. There are two ways to allocate memory:
1. Allocation via hugetlbfs
Hugetlbfs is a Linux mechanism that allows applications to allocate memory backed large physically contiguous regionsof memory. QEMU can take advantage of hugetlbfs for allocation of memory for virtual machines, which can provide asignificant performance improvement over malloc allocated memory. Hugetlbfs allocated memory provides the flexibilityof memory that can be allocated and freed with performance comparable to direct mapped memory.
The 32 bit ARMv7 implementation in Linux supports 2MB sized huge pages. The 64 bit ARMv8 implementation in Linuxsupports 2MB and 1GB sized huge pages (for 4K granularity page size).
The -mem-path argument to QEMU specifies the path to the hugetlbfs mount point where the huge pages should beallocated from.
The -m argument to QEMU specifies the amount of memory to allocate to the virtual machine. There are no constraintson the size passed to this argument other than that the amount of memory must fit within the constraints of the systemand be enough for the workload in the VM.
See the how-to article Quick-start Steps to Run KVM Using Hugetlbfs on page 273 for an example of how to use hugetlbfs.
2. Allocation via malloc
The default for QEMU is to allocate guest memory by the standard malloc facility available to user space applications inLinux. The amount of memory is specified with the -m command line argument. Malloc'ed memory has the flexibility ofbeing allocated and freed by QEMU as needed. However, malloc'ed memory is backed by 4KB physical pages that arenot contiguous and emulation is required by KVM to present a contiguous guest physical memory region to the VM. Thisapproach is discouraged since the emulation can result in a substantial performance penalty for certain workloads.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016264 NXP Semiconductors
The guest device tree generated by QEMU will contain a memory node that specifies the total amount of memory.
A virtual machine's memory is part of the address space of the QEMU process. This means that
the amount of memory allocated to a VM is limited by the standard limits that exist for Linux
processes. A 32-bit host kernel has a 2GiB virtual address space used for stack, text, and other
data, and this limits the amount of memory that can be allocated to a VM.
NOTE
10.1.2.3.3 Virtual network interfacesQEMU provides a number of options for creating virtual network interfaces in virtual machines. Virtual network interfacesare specified using the QEMU command line and guest software sees them as memory mapped devices.
There are two aspects of virtual network interfaces with QEMU:
1. The network “front-end”, which is the network card as seen by the guest. This is specified with the -device QEMUargument. The argument to specify a virtio network front end would look like: -device virtio-net-pci
2. The network "backend", which connects the network card to some network. Network backend options include user modenetworking, a host TAP interface, sockets, or virtual distributed Ethernet. The network backend is specified using the -netdev command line argument of QEMU. Note: It is possible to connect two virtual machines using virtual networkinterfaces. Normally QEMU userspace process emulates I/O accesses from the guest. However, there is an in-kernelimplementation: vhost-net which puts the data plane emulation code into the kernel.
For example, to use a virtio NIC card with a TAP interface back-end the QEMU command line argument would look like:
-netdev tap,id=tap0,script=/root/qemu-ifup -device virtio-net-pci,netdev=tap0
The script “/root/qemu-ifup” is a script that QEMU invokes and passes the TAP interface name as an argument. For example,the script could add the TAP interface to an Ethernet bridge.
See the QEMU Users Manual [1] (see References on page 256) for detailed information about command line options andthe types of network interfaces and backends. For best performance, the virtio front-end is recommended.
For additional information about QEMU networking see the references in For More Information on page 257.
For a detailed example, see the how-to article How to Use Virtual Network Interfaces Using Virtio on page 275 .
10.1.2.3.4 VMs and the Linux Scheduler
Each virtual machine appears to the host Linux as a process with each virtual CPU in the VM implemented as a thread. AVM appears as an instance of QEMU when looking at Linux processes as can be seen in the example below:
$ ps -ef o o root 1333 1 0 Oct01 ttyS0 00:00:00 -sh root 1336 2 0 08:24 ? 00:00:00 [kworker/u4:2] root 1372 1333 18 08:27 ttyS0 00:00:17 qemu-system-arm -enable-kvm -m root 1361 1304 0 08:28 ? 00:00:00 sshd: root@pts/0 root 1363 1361 0 08:28 pts/0 00:00:00 -sh o o
CPUs appear as threads. To see thread IDs use the info cpus command in the QEMU monitor. Example of a VM with 8virtual CPUs:
(qemu) info cpus* CPU #0: thread_id=1984
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 265
CPU #1: (halted) thread_id=1985 CPU #2: (halted) thread_id=1986 CPU #3: (halted) thread_id=1987 CPU #4: (halted) thread_id=1988 CPU #5: (halted) thread_id=1989 CPU #6: (halted) thread_id=1990 CPU #7: (halted) thread_id=1991
To see the QEMU threads using the ps command:
root@ls2080ardb:~# ps -eL | grep qemu 1981 1981 ttyS1 00:00:00 qemu-system-aar 1981 1982 ttyS1 00:00:00 qemu-system-aar 1981 1983 ttyS1 00:00:00 qemu-system-aar 1981 1984 ttyS1 00:00:00 qemu-system-aar 1981 1985 ttyS1 00:00:00 qemu-system-aar 1981 1986 ttyS1 00:00:00 qemu-system-aar 1981 1987 ttyS1 00:00:00 qemu-system-aar 1981 1988 ttyS1 00:00:00 qemu-system-aar 1981 1989 ttyS1 00:00:00 qemu-system-aar 1981 1990 ttyS1 00:00:00 qemu-system-aar 1981 1991 ttyS1 00:00:00 qemu-system-aar
Being a Linux thread means that standard Linux mechanisms can be used to control aspects of how the threads are scheduledrelative to other threads/processes. These mechanisms include:
• process priority
• CPU affinity
• isolcpus
• cgroups
10.1.2.4 Virtual machine reference10.1.2.4.1 VM OverviewIn general the architecture of KVM/QEMU is such that few changes should be needed to guest software to run in a VM-- i.e.a full virtualization approach is used, which means that virtual CPUs and virtual I/O devices behave like the physical hardwarethey are emulating.
However, there are some differences between virtual machines and native hardware that should be considered when targetingan OS to a KVM virtual machine. These differences can be divided into 2 general categories that will be discussed in furtherdetail in this section:
1. Initial state and boot
2. CPUs
10.1.2.4.2 Memory Map of Virtual I/O DevicesThe virt virtual machine contains a small subset of the devices found on an SoC. The available devices will be representedin the device tree passed to the guest at boot. See the table below for a summary of the virtual I/O devices in the virt VM:
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016266 NXP Semiconductors
Table 50.
Virtual I/O Devices for virt machine
virt VM
Address, size
Descriptions
0,128MB space for a flash device (this allows running bootrom code)
0x08000000, 0x20000 Virtual CPU peripherals (including GIC distributor and CPU peripheral space)
0x08000000, 0x10000 Virtual GIC distributor
0x08010000, 0x10000 Virtual GIC CPU interface
0x08020000, 0x10000 Virtul GICv2m controller
0x09000000, 0x10000 Virtual UART
0x09010000, 0x10000 Virtual RTC
0x0a000000..0x0a0001ff Virtual MMIO
... Virtual MMIO
0x0c000000, 0x02000000 Virtual platform bus
0x10000000, 0x30000000 virtual PCIE
0x40000000, 30G guest RAM
10.1.2.4.3 Virtual machine state at initialization10.1.2.4.3.1 Initial State and BootWhen booting the Host, kernel is entered into the HYP mode for ARMv7 respectively EL2 privillege level for ARMv8. Afterthe boot the kernel uses a stub to install KVM and switches back to SVC, respectively EL1. The virtual machine has novirtualization extensions available, so the guest kernel will be entered in SVC mode (ARMv7) respectively EL1 (ARMv8).
In case of a real hardware the boot program will provide some services before giving control to the OS. The necessary stepsneeded to be done by the bootloader are described in the kernel documentation: Documentation/arm/Booting/ (ARMv7),Documentation/arm64/booting.txt (ARMv8). In case of virtualization, KVM/QEMU makes the necessary actions to puthardware into the initial state (as seen by the guest) and also will take the role of the bootloader and makes the necessarysettings. QEMU also installs a very simple bootloader which just set some registers and after that it jumps to the kernel.
It is recommended that a guest OS be minimally device tree aware. The libfdt library (available with the DTC tool) providesa full range of APIs to parse and manipulate device trees and will make the process of adding device tree awareness to anOS straightforward.
10.1.2.4.3.2 Initial State of Virtual CPUsIn a VM with multiple virtual CPUs, CPU #0 is the boot CPU and all other vcpus in the partition are considered secondary.The boot method for the secondary CPUs is PSCI.
The virtual CPU entry conditions comply with the entry conditions specified by linux/Documentation/arm/Booting (ARMv7)or Documentation/ arm64/booting.txt (ARMv8)
The virtual CPU state is summarized below:
ARMv7:
• R0 = 0
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 267
• R1 = machine type number
• R2 = physical address of device tree block (DTB) in system RAM
• MMU off
• data cache off
• CPSR: 0x000001d3 (SVC mode, asynchronous abort, IRQ and FIQ masked)
ARMv8:
• x0 = physical address of device tree blob (dtb) in system RAM.
• x1 = 0
• x2 = 0
• x3 = 0
• MMU off
10.1.2.4.4 Virtual CPUs10.1.2.4.4.1 Virtual CPU Specification
Software running in a virtual machine sees a virtual CPU that emulates an ARMv7/ARMv8 core without virtualizationextensions.
The virtual CPU type will match that of the host hardware platform.
10.1.2.4.4.2 Time in the Virtual CPUARM architecture has an optional extension, the generic timers, which provides:
• a counter (physical counter) that measures passing of time in real time
• a timer (physical timer) for each CPU. The timer is programmed to raise an interrupt to the CPU after a certain amount oftime has passed.
The generic timers include virtualization support by introducing:
• a new counter, the virtual counter
• a new timer, the virtual timer.
This allows the virtual machine to have direct access to reading (virtual) counters and programming (virtual) timers withouttrapping.
KVM uses the physical timers in the host, the virtual machine access to the physical timers being disabled.
The virtual machine accesses the virtual timer and can, in this way, directly access the timer hardware without trapping tothe hypervisor. However, the virtual timers do not raise virtual interrupts, but hardware interrupts which trap to the hypervisor.KVM injects a corresponding virtual interrupt into the VM when it detects that the virtual timer expired.
10.1.2.4.5 VGICThe ARM Generic Interrupt Controller (GIC) provides hardware support for virtualization. The guest is able to mask,acknowledge and EOI interrupts without trapping to the hypervisor. However, there is a central part of the GIC called distributorwhich is responsible for interrupt prioritization and distribution to each CPU which does not provide virtualization extensionsand for this part KVM provides an in-kernel emulation. Also, all the physical interrupts cannot be directly received by theguest. Instead, the KVM will program a virtual interrupt which will be raised in the guest. But, with the virtualization supportin the GIC controller, when the guest is ACK-ing and EOI-ing the virtual interrupt, there is no need to trap into KVM.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016268 NXP Semiconductors
10.1.2.5 Debugging virtual machines10.1.2.5.1 QEMU MonitorWhen starting QEMU, a monitor shell is available that can be used to control and see the state of VM. By default this monitoris started in the Linux shell where QEMU is invoked.
See example below of the output when starting QEMU. The user can interact with the monitor at the (qemu) prompt.
QEMU 2.4.0 monitor - type 'help' for more information(qemu) QEMU waiting for connection on: disconnected:telnet::4446,server
The monitor can also be exposed over a network port by using the -monitor dev command line option. See Overview ofUsing QEMU on page 262 and the QEMU user's manual [1] (see References on page 256).
Refer to the QEMU user's manual [1] for a complete listing of the monitor commands available. Below is a list of some usefulcommands supported in the NXP SDK implementation of QEMU:
• help - lists all the available commands with usage information
• info cpus - displays the state and thread ID of all virtual CPUs
• info registers - displays the contents of the default vcpu's registers
• cpu cpu_number - sets the default vcpu number
• system_reset - resets the VM
• x/fmt addr -- virtual memory dump starting at 'addr'
• xp/fmt addr -- physical memory dump starting at 'addr'
10.1.2.5.2 QEMU GDB StubQEMU supports debugging of a VM using gdb. QEMU contains a gdb stub that can be attached to from a host system andallows standard source level debugging capabilities to examine the state of the VM and do run control.
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 269
Figure 25.
To use the gdb stub, start QEMU with the -gdb dev option where dev specifies the type of connection to be used. See theQEMU user's manual [1] (see References on page 256) for details.
One useful option when debugging is the -S argument to QEMU which causes QEMU to wait to start the first instruction ofthe guest until told to start using the monitor (continue command).
In the example below the tcp device type is used. A gdb stub will be active on port 4445 of the host Linux kernel when startingQEMU:
$ qemu-system-arm -enable-kvm -m 512 -mem-path /var/lib/hugetlbfs/pagesize-2MB -nographic -cpu host -machine type=virt -kernel /boot/zImage -serial tcp::4446,server,telnet -initrd /boot/fsl-image-core-ls1021atwr.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio -gdb tcp::4445
QEMU 2.4.0 monitor - type 'help' for more information(qemu) QEMU waiting for connection on: telnet:0.0.0.0:4446,server
After the guest has been started normally, gdb can be used to connect to the VM (in this example the host kernel has an ipaddress of 192.168.3.30):
(gdb) target remote 192.168.3.30:4445Remote debugging using 192.168.3.30:44450x80024f44 in ?? ()
Debugging with gdb can then proceed normally:
(gdb) p/x $r15$2 = 0x80024f44(gdb)
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016270 NXP Semiconductors
10.1.2.6 KVM/QEMU How-to's
10.1.2.6.1 Quick-start Steps to Build and Deploy KVM Using YoctoThe following steps show how to build host and guest root filesystems, Linux kernel, and QEMU in the Yocto environment.
There are two possibilities to deploy KVM using Yocto:
• Using the preconfigured fsl-image-virt Yocto image as the base for host root filesystem. This image type will generate ahost root filesystem which contains: QEMU, guest root filesystem and guest kernel image.
• Using other Yocto images as the base for host rootfilesystem . If the user wants to use other Yocto images to enable KVMthere will be additional steps needed in order to add all the needed pieces into the host root filesystem: QEMU, guest rootfilesystem, guest kernel image.
10.1.2.6.1.1 Deploy KVM using fsl-image-virt Image
The host roofs is based on the fsl-image-virt image type and the guest rootfs is based on fsl-image-core.
The steps outlined below assume that the Yocto build environment is configured so that the bitbake command can be run.
1. Build the base host root filesystem using the fsl-image-virt image type.
$ bitbake fsl-image-virt
2. Build a kernel with KVM enabled. In this case the same kernel image will be used for both host and guest.
Configure the Linux kernel to enable KVM-related features (if not enabled by default in the kernel config)
$ bitbake -c menuconfig virtual/kernel
Follow the steps described in section Quick Start - Recommended Configuration Options on page 258 to enable KVM inthe Linux kernel.
Then rebuild the kernel based on the new configuration options:
$ bitbake virtual/kernel
3. Re-build the fsl-image-virt image (if nothing was done at step 2, this step may be skipped)
bitbake fsl-image-virt
4. Create the kernel.itb file (if necessary)
U-boot may use both uImage or FIT image format to load the kernel image. For ARMv7 platforms an uImage is used andfor these platforms this step is not needed. For ARMv8, a FIT image is used and the FIT image must be generated. Thefollowing steps need to be taken:
• Update the fsl-image-kernelitb to include the rootfs generated by the fsl-image-virt (by default the recipee would usethe rootfs generated by fsl-image-core). In order to change the rootfs type in the generated itb file there are two possiblesolutions:
• Redefine the ROOTFS_IMAGE variable in meta-freescale/recipes-fsl/images/fsl-image-kernelitb.bb directly:
-ROOTFS_IMAGE ?= "fsl-image-core" +ROOTFS_IMAGE ?= "fsl-image-virt"
• Add the following line to build_<machine_release>/conf/local.conf:
ROOTFS_IMAGE = "fsl-image-virt”
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 271
• Generate the kernel itb:
bitbake fsl-image-kernelitb
The resulting host rootfs will contain:
• Linux kernel image. Currently for ARMv7 paltforms the zImage file will be included and for ARMv8 platforms the Image file.The kernel image will be located in /boot
• Guest root filesystem: based on fsl-image-core. The guest root file system will be located in /boot
• QEMU
For steps to run QEMU see the article Quick-start Steps to Run KVM Using Hugetlbfs on page 273.
10.1.2.6.1.2 Deploy KVM using fsl-image-core Image
The host roofs is based on the fsl-image-core image type and the guest rootfs is based on fsl-image-minimal.
The steps outlined below assume that the Yocto build environment is configured so that the bitbake command can be run.
1. Build the base host root filesystem using the fsl-image-core image type.
$ bitbake fsl-image-core
2. Build a host kernel with KVM-enabled (if not enabled by default in the kernel config)
Configure the Linux kernel to enable KVM-related features.
$ bitbake -c menuconfig virtual/kernel
Follow the steps described in section Quick Start - Recommended Configuration Options on page 258 to enable KVM inthe Linux kernel.
Then rebuild the kernel based on the new configuration options:
$ bitbake virtual/kernel
3. Add QEMU to the packages built by fsl-image-core.
Edit the conf/local.conf file and append the following line which adds the QEMU package:
IMAGE_INSTALL_append = " qemu"
4. Build a guest root filesystem and add it to the host rootfs.
A. Build the guest roofs using the fsl-image-minimal image type. This creates a small rootfs sufficient for booting a Linuxguest:
$ bitbake fsl-image-minimal
This command results in the minimal rootfs being created in tmp/deploy/images. In this example the minimal rootfs builtis named: fsl-image-minimal.rootfs.ext2.gz
B. Use the merge-files feature of Yocto (see Adding Images to a Root Filesystem with Yocto on page 262) to copy theguest rootfs to the host rootfs.
$ mkdir -p meta-freescale/recipes-extended/merge-files/merge-files/merge/home/root
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016272 NXP Semiconductors
$ cp tmp/deploy/images/machine/fsl-image-minimal.rootfs.ext2.gz meta-freescale/recipes-extended/merge-files/merge-files/merge/home/root/guest.rootfs.ext2.gz
$ bitbake -c install -f merge-files
$ bitbake merge-files
5. Re-build the fsl-image-core image.
bitbake fsl-image-core
6. Create the kernel.itb file (if necessary)
U-boot may use both uImage or FIT image format to load the kernel image. For ARMv7 platforms an uImage is used andfor those platforms this step is not needed. For ARMv8, a FIT image is used and the FIT image must be generated.
bitbake fsl-image-kernelitb
The resulting host rootfs will contain:
• Linux kernel image
• Guest root filesystem
• QEMU, including the example guest device trees
For steps to run QEMU see the article Quick-start Steps to Run KVM Using Hugetlbfs on page 273.
10.1.2.6.2 Quick-start Steps to Run KVM Using HugetlbfsThe pre-requisite to this example is completing the steps in the article Quick-start Steps to Build and Deploy KVM UsingYocto on page 271.
This example assumes that the host Linux kernel is booted, has a working network interface, and the following images arepresent in the host root filesystem:
• Guest kernel image (/boot/zImage or /boot/Image)
• Guest root filesystem (/boot/guest.rootfs.ext2.gz)
• QEMU (/usr/bin/qemu-system-arm or /usr/bin/qemu-system-aarch64)
There are a number of mechanisms for allocating huge pages and making them accessible via a mount point. Refer to theSDK documentation for details. This example assume allocating pages using the hugeadm command. Create a 512MB poolof 2MB huge pages, which can be used by QEMU for allocating VM memory:
$ hugeadm --pool-pages-min 2M:256
hugeadm --pool-list Size Minimum Current Maximum Default 2097152 256 256 256 *
Create a mount point to access the huge pages:
$ hugeadm --create-mounts
$ ls -1 /var/lib/hugetlbfs/pagesize-2MB
Start QEMU specifying the 2MB huge page pool as the file from which to allocate memory. In this example 512MB of memoryis allocated to the VM:
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 273
32 bit ARMv7:
qemu-system-arm -enable-kvm -m 512 -mem-path /var/lib/hugetlbfs/pagesize-2MB -nographic -cpu host -machine type=virt -kernel /boot/zImage -serial tcp::4446,server,telnet -initrd /boot/guest.rootfs.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio
QEMU waiting for connection on: telnet::0.0.0.04446,server
64bit ARMv8:
qemu-system-aarch64 -enable-kvm -m 512 -mem-path /var/lib/hugetlbfs/pagesize-2MB -nographic -cpu host -machine type=virt -kernel /boot/Image -serial tcp::4446,server,telnet -initrd /boot/guest.rootfs.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio
QEMU waiting for connection on: telnet::0.0.0.04446,server
Explanation of the command line options:
• -enable-kvm : specifies that KVM should be used
• -m 512 : the amount of memory for the VM
• -mem-path /var/lib/hugetlbfs/pagesize-2MB : allocates from hugetlbfs based memory
• -nographic : don't instantiate a graphics card, this is the only option supported for the SDK
• -cpu host : the type of the CPU. In this case it is the same as the host CPU
• -machine type=virt : the type of virtual machine
• -kernel /boot/zImage : name of guest Linux kernel
• -initrd ./boot/guest.rootfs.ext2.gz : name of guest roofs
• -append "root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk" : guest Linux bootargs
• -serial tcp::4446,server,telne : provide an emulated serial port (telnet server) on port 4444 on the host Linux system.Default behavior will be for QEMU to wait until the user connects to this port before booting the VM.
• -monitor stdio : start QEMU monitor
At this point QEMU is waiting for a telnet connection to the virtual machine's console (port 4446 of the target board) prior tostarting the virtual machine.
Connect to QEMU via telnet to start the virtual machine booting. In this example the target board has IP address 192.168.3.30.
$ telnet 192.168.3.30 4446[ 0.000000] Booting Linux on physical CPU 0x0[ 0.000000] Initializing cgroup subsys cpu[ 0.000000] Linux version 4.1.8-rt8+gf42311c (gcc version 4.9.3 20150311 (prerelease) (Linaro GCC 4.9-2015.03) ) #1 SMP Tue Apr 26 15:40:46 EEST 2016[ 0.000000] CPU: AArch64 Processor [411fd071] revision 1[ 0.000000] Detected PIPT I-cache on CPU0[ 0.000000] alternatives: enabling workaround for ARM erratum 832075[ 0.000000] alternatives: enabling workaround for ARM erratum 834220[ 0.000000] efi: Getting EFI parameters from FDT:
.........Starting system log daemon...0Starting kernel log daemon...0Starting internet superserver: xinetd.
QorIQ SDK (FSL Reference Distro) 2.0 ls2080ardb /dev/ttyAMA0
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016274 NXP Semiconductors
ls2080ardb login:
10.1.2.6.3 How to Use Virtual Network Interfaces Using VirtioAs discussed in Virtual network interfaces on page 265, there are two aspects of virtual network interfaces-- 1) the "frontend" (the device as seen by the guest OS) and 2) the "backend" (the means by the virtual device is connected to the network).
This example uses a "virtio" model NIC card and a tap network backend. The virtual network interface is bridged via a TAPinterface to the physical network. The guest OS is Linux.
When starting QEMU we will add the following arguments to create the virtual network interface:
-netdev tap,id=tap0,script=/home/root/qemu-ifup,downscript=no,ifname="tap0" -device virtio-net-pci,netdev=tap0
Perform the following steps:
1. Enable virtio networking in the host and guest Linux kernels (see Host Kernel: Enabling Virtual Networking on page260 and Guest Kernel: Enabling Network and Block Virtual I/O on page 260).
2. On the host Linux create a bridge to the physical network interface to be used by the virtual network interface in thevirtual machine using the brctl command. In this example the physical interface being used is eth2:
brctl addbr br0ifconfig br0 192.168.3.30 netmask 255.255.248.0ifconfig eth2 0.0.0.0brctl addif br0 eth2
3. Create a qemu-ifup script on the host Linux system. For the TAP backend type, when QEMU creates the virtualnetwork interface it invokes a user-created script that allows customization of how the TAP interface is to be handled.The name of the TAP interface created by QEMU is passed as an argument. In this example we will bridge the the TAPinteface to the bridge created in step #2. See the example qemu-ifup script below:
#!/bin/sh# TAP interface will be passed in $1bridge=br0guest_device=$1ifconfig $guest_device 0.0.0.0 upbrctl addif $bridge $guest_device
4. When starting QEMU specify that the network device type is "virtio" and specify the path to the script created in step#3:
qemu-system-aarch64 -smp 8 -enable-kvm -m 4096 -nographic -cpu host -machine type=virt -kernel /boot/Image -serial tcp::4446,server,telnet -initrd /boot/fsl-image-core-ls2080ardb.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio -netdev tap,id=tap0,script=qemu-ifup,downscript=no,ifname="tap0" -device virtio-net-pci,netdev=tap0
5. In the guest OS the virtual network interface will appear and can be brought up and assigned an IP address in thenormal way. In the example below (the commands are run from the guest command shell) the virtio interface is eth0.
$ ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 275
inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default link/sit 0.0.0.0 brd 0.0.0.0
root@ls2080ardb:~# ethtool -i eth0driver: virtio_netversion: 1.0.0firmware-version: expansion-rom-version: bus-info: 0000:00:01.0supports-statistics: nosupports-test: nosupports-eeprom-access: nosupports-register-dump: nosupports-priv-flags: no
$ ifconfig eth0 192.168.3.31 netmask 255.255.248.0
10.1.2.6.4 How to use vhost-net with virtiovhost-net is a character device that can be used to reduce the number of system calls involved in virtio networking. vhost-net moves network packets between the guest and the host system using the Linux kernel, bypassing QEMU.
In order to use vhost-net perform the following steps:
1. Enable virtio networking and vhost-net in the host and guest Linux kernels (see Host Kernel: Enabling VirtualNetworking on page 260 and Guest Kernel: Enabling Network and Block Virtual I/O on page 260).
2. On the host Linux create a bridge to the physical network interface to be used by the virtual network interface in thevirtual machine using the brctl command. In this example the physical interface being used is eth2:
brctl addbr br0ifconfig br0 192.168.3.30 netmask 255.255.248.0ifconfig eth2 0.0.0.0brctl addif br0 eth2
3. Create a qemu-ifup script on the host Linux system. For the TAP backend type, when QEMU creates the virtualnetwork interface it invokes a user-created script that allows customization of how the TAP interface is to be handled.The name of the TAP interface created by QEMU is passed as an argument. In this example we will bridge the the TAPinteface to the bridge created in step #2. See the example qemu-ifup script below:
#!/bin/sh# TAP interface will be passed in $1bridge=br0guest_device=$1ifconfig $guest_device 0.0.0.0 upbrctl addif $bridge $guest_device
4. When starting QEMU specify that the network device type is "virtio" and that vhost-net (vhost=on parameter) is used:
qemu-system-aarch64 -smp 8 -enable-kvm -m 8192 -mem-path /var/lib/hugetlbfs/pagesize-1GB -nographic -cpu host -machine type=virt -kernel /boot/Image -serial tcp::4446,server,telnet -initrd /boot/fsl-image-core-ls2080ardb.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk ramdisk_size=307200' -monitor stdio -netdev tap,id=tap0,script=qemu-ifup,downscript=no,ifname="tap0",vhost=on -device virtio-net-pci,netdev=tap0
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016276 NXP Semiconductors
5. In the guest the virtual interface will come up as described in How to Use Virtual Network Interfaces Using Virtio onpage 275. In the Host kernel the vhost thread can be seen consuming CPU:
2078 root 20 0 0 0 0 R 93.7 0.0 0:07.09 vhost-2066 2066 root 20 0 9192660 511632 7532 S 82.0 3.3 0:12.70 qemu-system-aar 2091 root 20 0 159636 1092 960 S 68.0 0.0 0:05.50 iperf
10.1.2.6.5 Debugging: How to Examine Initial Virtual Machine State withQEMU
It can be helpful when debugging to examine the state of the virtual machine prior to executing the first instruction of theguest OS.
To do this, start QEMU with the -S option.
Example:
qemu-system-aarch64 -enable-kvm -m 512 -nographic -cpu host -machine type=virt -kernel /boot/Image -serial tcp::4446,server,telnet -initrd /boot/fsl-image-core-ls2080ardb.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0 rootwait earlyprintk' -monitor stdio -S
The console was started with the "-serial tcp::4446,server,telnet" option so QEMU waits for a connection prior to startinginitialization. Use telnet to connect to port 4446 of the target.
At this point QEMU initializes the VM, but does not execute the entry point to the guest OS. The monitor prompt can now beused to examine initial state:
QEMU 2.4.0 monitor - type 'help' for more information(qemu) QEMU waiting for connection on: telnet:0.0.0.0:4446,server(qemu)
To see where boot images are loaded and placed by QEMU use the info roms command:
(qemu) info romsaddr=0000000040000000 size=0x000028 mem=ram name="bootloader"addr=0000000040080000 size=0xb9a800 mem=ram name="/boot/Image"addr=0000000048000000 size=0x1517eef mem=ram name="/boot/fsl-image-core-ls2080ardb.ext2.gz"addr=0000000049600000 size=0x010000 mem=ram name="dtb"/rom@etc/acpi/tables size=0x200000 name="etc/acpi/tables"/rom@etc/table-loader size=0x000880 name="etc/table-loader"/rom@etc/acpi/rsdp size=0x000024 name="etc/acpi/rsdp"
A trivial bootloader is loaded at the start of guest memory at 0x40000000
The kernel image (zImage) is loaded at 0x40080000. The ramdisk is loaded at 0x48000000.
To examine the initial state of registers use the info registers command:
(qemu) info registersPC=0000000040000000 SP=0000000000000000X00=0000000000000000 X01=0000000000000000 X02=0000000000000000 X03=0000000000000000X04=0000000000000000 X05=0000000000000000 X06=0000000000000000 X07=0000000000000000X08=0000000000000000 X09=0000000000000000 X10=0000000000000000 X11=0000000000000000X12=0000000000000000 X13=0000000000000000 X14=0000000000000000 X15=0000000000000000X16=0000000000000000 X17=0000000000000000 X18=0000000000000000 X19=0000000000000000X20=0000000000000000 X21=0000000000000000 X22=0000000000000000 X23=0000000000000000
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 277
X24=0000000000000000 X25=0000000000000000 X26=0000000000000000 X27=0000000000000000X28=0000000000000000 X29=0000000000000000 X30=0000000000000000 PSTATE=400003c5 (flags -Z--)
q00=0000000000000000:0000000000000000 q01=0000000000000000:0000000000000000q02=0000000000000000:0000000000000000 q03=0000000000000000:0000000000000000q04=0000000000000000:0000000000000000 q05=0000000000000000:0000000000000000q06=0000000000000000:0000000000000000 q07=0000000000000000:0000000000000000q08=0000000000000000:0000000000000000 q09=0000000000000000:0000000000000000q10=0000000000000000:0000000000000000 q11=0000000000000000:0000000000000000q12=0000000000000000:0000000000000000 q13=0000000000000000:0000000000000000q14=0000000000000000:0000000000000000 q15=0000000000000000:0000000000000000q16=0000000000000000:0000000000000000 q17=0000000000000000:0000000000000000q18=0000000000000000:0000000000000000 q19=0000000000000000:0000000000000000q20=0000000000000000:0000000000000000 q21=0000000000000000:0000000000000000q22=0000000000000000:0000000000000000 q23=0000000000000000:0000000000000000q24=0000000000000000:0000000000000000 q25=0000000000000000:0000000000000000q26=0000000000000000:0000000000000000 q27=0000000000000000:0000000000000000q28=0000000000000000:0000000000000000 q29=0000000000000000:0000000000000000q30=0000000000000000:0000000000000000 q31=0000000000000000:0000000000000000FPCR: 00000000 FPSR: 00000000
The program counter is set to 0x40000000 which is the effective address of the entry point of the kernel.
10.1.2.6.6 Debugging: How to Profile Virtualization Overhead with KVM
Running software in a virtual machine can cause additional overhead that affects performance. The virtualization overheadis directly related to the number of times the hypervisor (KVM) is invoked to handle exception conditions that may occur inthe virtual machine. These exception handling events are referred to as 'exits', because guest context is exited.
Examples of exits include things such the guest executing a privileged instruction, access a privileged CPU register,accessing a virtual I/O device, or a hardware interrupt such as a decrementer interrupt.
The type and number of exits that occur is workload dependent.
KVM implements a mechanism in which different events are logged. These events are actually tracepoint events, and perfnicely integrates with them. You have to compile the host kernel with the following options:
Kernel hacking ---> [*] Tracers ---> [*] Trace process context switches and events
Counting Events
A count of a subset of KVM events that occur can be seen under debugfs. To see this first mount debugfs:
mount -t debugfs none /sys/kernel/debug
The statistics can be seen using perf tool:
# perf stat -e "kvm:*" -p 1395^C Performance counter stats for process id '1395':
5678 kvm:kvm_entry 5678 kvm:kvm_exit 3121 kvm:kvm_guest_fault 2278 kvm:kvm_irq_line 0 kvm:kvm_mmio_emulate
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016278 NXP Semiconductors
0 kvm:kvm_emulate_cp15_imp 2438 kvm:kvm_wfi 0 kvm:kvm_unmap_hva 2 kvm:kvm_unmap_hva_range 0 kvm:kvm_set_spte_hva 0 kvm:kvm_hvc 3119 kvm:kvm_userspace_exit 0 kvm:kvm_set_irq 0 kvm:kvm_ack_irq 4068 kvm:kvm_mmio 0 kvm:kvm_fpu 0 kvm:kvm_age_page
59.316709040 seconds time elapsed
Tracing events
Detailed traced can be generated using ftrace:
[enable ftrace in kernel: events and system calls]$echo 1 > /sys/kernel/debug/tracing/events/kvm/enable$cat /sys/kernel/debug/tracing/trace_pipe
qemu-system-arm-1366 [000] .... 716.115891: kvm_guest_fault: ipa 0x9000000, hsr 0x93430046, hxfar 0xa084c030, pc 0x80266a9cqemu-system-arm-1366 [000] .... 716.115892: kvm_mmio: mmio write len 2 gpa 0x9000030 val 0xf01qemu-system-arm-1366 [000] .... 716.115895: kvm_userspace_exit: reason KVM_EXIT_MMIO (6)qemu-system-arm-1366 [000] d... 716.115907: kvm_entry: PC: 0x80266aa0qemu-system-arm-1366 [000] d... 716.116234: kvm_exit: PC: 0x800cf508qemu-system-arm-1366 [000] d... 716.118274: kvm_entry: PC: 0x800cf508qemu-system-arm-1366 [000] d... 716.118704: kvm_exit: PC: 0x0000981cqemu-system-arm-1366 [000] d... 716.120737: kvm_entry: PC: 0x0000981cqemu-system-arm-1366 [000] d... 716.121159: kvm_exit: PC: 0x800bb104qemu-system-arm-1366 [000] d... 716.123197: kvm_entry: PC: 0x800bb104qemu-system-arm-1366 [000] d... 716.123620: kvm_exit: PC: 0x8009cae0qemu-system-arm-1366 [000] d... 716.125696: kvm_entry: PC: 0x8009cae0qemu-system-arm-1366 [000] d... 716.126091: kvm_exit: PC: 0x800c90f4qemu-system-arm-1366 [000] d... 716.128130: kvm_entry: PC: 0x800c90f4qemu-system-arm-1366 [000] d... 716.128561: kvm_exit: PC: 0x801f37f4qemu-system-arm-1366 [000] d... 716.130594: kvm_entry: PC: 0x801f37f4qemu-system-arm-1366 [000] d... 716.130623: kvm_exit: PC: 0x8020576cqemu-system-arm-1366 [000] d... 716.130635: kvm_entry: PC: 0x8020576cqemu-system-arm-1366 [000] d... 716.131018: kvm_exit: PC: 0x43014750qemu-system-arm-1366 [000] d... 716.133053: kvm_entry: PC: 0x43014750qemu-system-arm-1366 [000] d... 716.133478: kvm_exit: PC: 0x80205778qemu-system-arm-1366 [000] d... 716.135555: kvm_entry: PC: 0x80205778
Virtualization
KVM/QEMU
QorIQ LS1012A BSP v0.5, Rev. 0, December 2016NXP Semiconductors 279
How To Reach Us
Home Page:
nxp.com
Web Support:
nxp.com/support
Information in this document is provided solely to enable system and software implementers
to use Freescale products. There are no express or implied copyright licenses granted
hereunder to design or fabricate any integrated circuits based on the information in this
document. Freescale reserves the right to make changes without further notice to any
products herein.
Freescale makes no warranty, representation, or guarantee regarding the suitability of its
products for any particular purpose, nor does Freescale assume any liability arising out of the
application or use of any product or circuit, and specifically disclaims any and all liability,
including without limitation consequential or incidental damages. “Typical” parameters that
may be provided in Freescale data sheets and/or specifications can and do vary in different
applications, and actual performance may vary over time. All operating parameters, including
“typicals,” must be validated for each customer application by customer's technical experts.
Freescale does not convey any license under its patent rights nor the rights of others.
Freescale sells products pursuant to standard terms and conditions of sale, which can be
found at the following address: nxp.com/SalesTermsandConditions.
Freescale, the Freescale logo, and Kinetis are trademarks of Freescale Semiconductor, Inc.,
Reg. U.S. Pat. & Tm. Off. All other product or service names are the property of their respective
owners. ARM and Cortex are registered trademarks of ARM Limited.
Ⓒ 2016 Freescale Semiconductor, Inc.
QORIQLS1012ABSP05Rev. 0
28 Dec 2016