qoriq ls1012a bsp v0 - my-boardclub.com · 8.1 openssl offload user's guide ... 9.1.4 how to...

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


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


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


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


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


http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/qoriq-arm-processors/qoriq-ls1012a-low-power-communication-processor:LS1012A?

• 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.


QLINUX-5875 Kernel call traceduringrt_fully_pistress_test run.


QUBOOT-1682 Checkpatch Errorsin PFE module.


QLINUX-5883 The ppfe port doesnot work afterpowermanagement isentered and exitedrepeatedly.


QLINUX-5841 Linux IPfwd forsmall frame sizehas moredegradationcompared withSDK v0.2 onLS1012ARDB.


Table continues on the next page...

SDK Overview

Known Issues


Table continued from the previous page...

QLINUX-6522 The kernel couldnot resume andcall trace whentesting PM onLS1012ARDB.


QLINUX-6529 Sec self for CE andNeon tested failedonls1012ardb-32bit.


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.


LS1012A BSP v0.5

QLINUX-5878 Kernel hang whentestingsec_tcrypto_deswith 32-bit kernel.


LS1012A BSP v0.5

QLINUX-6508 Kernel crashesduring boot with64K pagesize.


LS1012A BSP v0.5


SDK Overview

Known Issues



QUBOOT-1737 If code warrior isused to program u-boot or RCW, theflash gets intoinvalid state.


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.


LS1012A BSP v0.5

SDK Overview

Known Issues


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


https://www.yoctoproject.org/

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


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


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



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



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


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



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


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.


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



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



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




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:



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



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



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



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


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.


Target Board Set-up


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


Target Board Set-up


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


Optimizing Boot Flow (Fast Boot)


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


Supported Boards


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


Supported Boards


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:


Supported Boards


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:


Supported Boards


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.


Supported Boards


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.


Supported Boards


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


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


Supported Boards


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


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


Supported Boards


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.


Supported Boards


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


Supported Boards


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


Supported Boards


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


Supported Boards


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


Supported Boards


[ 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


Supported Boards


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.


Supported Boards


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


Supported Boards


• 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


Supported Boards


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


Supported Boards


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


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.


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


Supported Boards


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


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


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.


Supported Boards


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.


Supported Boards


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


Supported Boards


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


Supported Boards


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:


Supported Boards


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


Supported Boards


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



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.


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


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


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


http://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html

http://www.yoctoproject.org/docs/2.0/adt-manual/adt-manual.html

http://www.yoctoproject.org/docs/2.0/bsp-guide/bsp-guide.html

http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html

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


http://www.yoctoproject.org/docs/2.0/kernel-dev/kernel-dev.html

http://www.yoctoproject.org/docs/2.0/profile-manual/profile-manual.html

http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html

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



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


Audio


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


Device Drivers --->

[*] DMA Engine support ---> --->

<*> Freescale eDMA engine support

DMA engine subsystem driver and eDMA driver support


DMA Controller


Identifier



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


drivers/dma/fsl-edma.c The eDMA driver file


DMA Controller



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


DMA Controller


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 Tree View Options


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


CONFIG_MMC y/n n Enable SD/MMC bus protocol

CONFIG_MMC_BLOCK y/n y Enable SD/MMC block device driver support



Enhanced Secured Digital Host Controller (eSDHC)




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.


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




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


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




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




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




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.



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



PCI Express Interface Controller




Device Drivers --->

<*> Serial ATA and Parallel ATA drivers (libata) ---> <*> Silicon Image 3124/3132 SATA support

Enable support for SiliconImage 3124/3132 Serial ATA.



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



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,




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]#




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


• 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.







Device Drivers ---> <*> EDAC (Error Detection And Correction) reporting ---> <*> Main Memory EDAC (Error Detection And Correction) reporting <*> Freescale MPC83xx / MPC85xx

Enables EDAC supportfor 85xx platform



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


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






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]#




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.



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


CONFIG_PCIEAER y/n y Enable AER

CONFIG_PCIEAER_INJECT y/n n Enables AER INJECT

Source Files



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"]




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




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.


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



CONFIG_E1000E y/n y Intel PCI-e e1000e network card driver

Device Tree Binding

Use the default dtb file.


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.




# 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.


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




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




->[*] 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




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;


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




#> tftp c00000 uImage-<bsp>.dtb#> bootm 1000000 2000000 c00000


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)




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:


Packet Forward Engine (PFE) Network Driver


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.




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:




• 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.



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



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



Real Time Clock (off-chip)




CONFIG_RTC_INTF_DEV y/m/n y Enable RTC to use /dev interface

Source Files



drivers/rtc/ Linux RTC driver

Device Tree Binding

Preferred node name: rtc


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>; }; };


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


Real Time Clock (off-chip)


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.


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


SATA Controller




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.


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)


SATA Controller


/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


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


• CDROM is not supported due to the silicon limitation

6.8 Serial Peripheral Interface

6.8.1 DSPI Device Driver User Manual


Serial Peripheral Interface


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.


Device Drivers ---> [*] SPI support ---> <*> Freescale DSPI controller

Device Drivers ---> <*> Memory Technology Device (MTD) support ---> Self-contained MTD device drivers ---> <*> Support for AT45xxx DataFlash


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


Serial Peripheral Interface


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


Universal Serial Bus Interfaces


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


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



Device Drivers--->

USB support --->

[*] Support for Host-side USB

Enables USB hostcontroller support

Device Drivers--->

USB support --->

Enables EHCI HostController Driver andtransaction translator.






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



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



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




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




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




=> 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 ................=>





· 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




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)




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


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




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


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


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




Pwr. Mgmt. Kernel Configuration Option(s)


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


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




/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.




/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



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.





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


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 4. Kernel Configure Tree View Options (continued)


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




Source Files


Table 6. Source Files


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




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.




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


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




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.



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







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



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







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



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";




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.




Make filesystem and mount connected USB flash drive using below commands

root@freescale /$ fdisk -l


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


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




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




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




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]




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




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




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


• 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




Device Drivers --->

[*] Watchdog Timer Support --->

[*] Disable watchdog shutdown on close

[*] PowerPC Book-E Watchdog Timer

PowerPC Book-E Watchdog Timer


Watchdog Timers




CONFIG_BOOKE_WDT y/n y PowerPC Book-E Watchdog Timer

Source Files



drivers/char/watchdog/booke_wdt.c PowerPC Book-E Watchdog Timer


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


· 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.


Watchdog Timers


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


Watchdog Timers


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


· 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.


Watchdog Timers


Chapter 7Additional Linux Use Cases

7.1 Power Management

7.1.1 Power Management User Manual


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.


For ARM platforms


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


Additional Linux Use Cases

Power Management




[*] 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



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


Power Management


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.


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


• 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/


• QorIQ processor reference manuals

7.1.2 CPU Frequency Switching User Manual


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.


CPU Power Management -->

Enable the CPU frequencydriver


Power Management



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


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


Simply using command "cat" and "echo" can verify this feature.

Device Tree Binding


#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


clockgen: clocking@1ee1000 { compatible = "fsl,ls1012a-clockgen"; reg = <0x0 0x1ee1000 0x0 0x1000>; #clock-cells = <2>; clocks = <&sysclk>;};

Source Files




Power Management




drivers/cpufreq/qoriq_cpufreq.c CPU frequency scaling driver for qoriq chips


• 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.


Power Management



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



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


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


Power Management


ina220@40 { compatible = "ti,ina220"; reg = <0x40>; shunt-resistor = <1000>; };





ina220@47 { compatible = "ti,ina220"; reg = <0x47>; shunt-resistor = <1000>; }; }; };

Source Files



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


Power Management


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-44Adapter: i2c-0-mux (chan_id 2)in0: +0.00 Vin1: +1.51 V


Power Management


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.



Device Drivers --->[*] Misc devices ---> <*> Freescale Data Collection Manager (DCM) driver

Enables DCM driver



CONFIG_FSL_DCM y/n y Enable DCM module

Device Tree Binding


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



drivers/misc/fsl_dcm.c DCM driver


Power Management


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.



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


Power Management




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



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


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


Power Management


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.


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"


Power Management


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


Power Management


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 options ---> Preemption Model (Fully Preemptible Kernel (RT)) ---> (X) Fully Preemptible Kernel (RT)

These options enable RT inLinux.

Identifier


Option Values Default Value to enable RT Description

CONFIG_SLAB y/n y Enable SLAB Support



Real Time Application Note


http://git.kernel.org/?p=linux/kernel/git/rt/linux-stable-rt.git;a=summary

https://rt.wiki.kernel.org


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


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



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


Real Time Application Note


http://git.kernel.org/?p=linux/kernel/git/clrkwllms/rt-tests.git


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


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



• 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



/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



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


Linux User Space



Table 7. OpenSSL CipherSuite Compatibility (continued)


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


Linux User Space





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


Linux User Space





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


Linux User Space





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


Linux User Space





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



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


[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



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



PPA

GPPBootrom


3

45



6

KernelEL3init

securemonitor

SMCLib

TBD PSCI

EL3 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



PPA

GPPBootrom


3

4



Kernel

EL3init

securemonitor

SMCLib

TBD PSCI

EL3 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



• 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



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.


Input Parameters:

Register Meaning

X0 Function ID

Return Values:


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



If successful, this function does not return.

9.1.5.4 CPU_SUSPENDPut the calling core/cluster/system into a low-power state.


Input Parameters (see [11]):

Register Meaning

X0 Function ID

X1 Power_State

X2 Start_Address (Physical)

X3 Context_Id

Return Values:


X0 SUCCESS


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.


Input Parameters (see [11]):

Register Meaning

X0 Function ID

X1 Target_Affinity

X2 Lowest_Affinity

Return Values:

Boot Loaders



Register Return Codes (see 5.8, 5.8.1)

X0 ON_PENDING

“ OFF

“ ON


“ NOT_PRESENT

“ DISABLED

9.1.5.6 SYSTEM_OFFPower down the entire system.


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.


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


Boot Loaders




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



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.


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.


Input Parameters:

Register Meaning

X0 Function ID

Return Values:

Register Value

X0 Bytes [3:0] of UUID




9.1.6.4 Get RevisionReturn the major and minor revision numbers of the SIP portion of this SMC implementation.



Boot Loaders



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



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


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



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



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



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



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



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



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



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



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:


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



Figure 13. Chain of Trust with Confidentiality (Encapsulation)

Boot Loaders



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



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:


• 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:


• 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



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



Boot Loaders



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


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



DRV 0 | 63 - 32 | f4bfc65f DRV 1 | 31 - 0 | 16294daf

$ ./gen_drv_drbg A2 1652afe595631dec


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


Input string not providedGenerating a random string-------------------------------------------* Hash_DRBG library invoked

Boot Loaders



* 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


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


Boot Loaders



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


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



# 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



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


Boot Loaders



Table 8. Description of fields. (continued)


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


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



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


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



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.


Boot Loaders



Table 9. IE Key Structure which is embedded in header and placed in memory. (continued)


- -

- 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



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


ESBC_HDRADDR ESBC Header address. It contains location of ESBC headerin the memory


Boot Loaders



Table 10. Description of new fields introduced. (continued)


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



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



# 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 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.


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



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



Usage Example:

./uni_sign --img_hash input_uboot_nor_secure


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



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


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



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



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.





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



CST uses openssl libraries, version 0.9.8.

In the Yocto environment, the user needs to use below commands to rebuild cst:


2. bitbake cst-native

3. Modify the CST source code if needed.


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



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



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



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



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.


Step 1: Creating blobs




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




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



$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



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


Or

b. Flow B


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.)





Boot Loaders




boot.



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.




• ESBC image would further validate the bootscript.

• Bootscript would encapsulate the Linux, rootfs and device tree and store the blobs at the desired locations.





6. Replace the encap bootscript and its CSF header with decap bootscript and the CSF header of the decap bootscriptrespectively.




• 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. .




Boot Loaders



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



a. Flow A


Or

b. Flow B


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.)






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.




Boot Loaders



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



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


Or

b. Flow B


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.)






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


a. FLOW A


b. FLOW B




Boot Loaders








• 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.


a. FLOW A


b. FLOW B






• 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



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



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)


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).


Boot Loaders



Table 14. CSF Header Format (P3/P4/P5 Platforms) (continued)


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.


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


Boot Loaders



Table 14. CSF Header Format (P3/P4/P5 Platforms) (continued)


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


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)


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)


0x00-size The RSA signature calculated over CSF Header, Scatter Gather table and ESBC image(s).

Boot Loaders



Table 17. Public key (P3/P4/P5 Platforms)


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)





Boot Loaders



Table 18. CSF Header Format (B4/T1/T2/T4 Platforms) (continued)


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.


• 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.




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


Boot Loaders





0x1c-0x1f For ISBC Phase:

ESBC entry point. ISBC transfers control to this location upon successful validation of ESBCimage(s).


0x20-0x23 Reserved .(Earlier this field was SG Flag. SG flag is always assumed to be 1 in unifiedimplementation.)

0x24 For ISBC 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


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



Boot Loaders






Size of the housekeeping area

Size of the pre-configured memory which can be used by Boot Rom Code.


0x38-0x3f Reserved




For ESBC Phase:

ISBC key Extension flag



For ESBC Phase:

IE Key Select


Table 19. Scatter Gather Table Format (B4/T1/T2/T4 Platforms)


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.






Boot Loaders



Table 20. Signature (B4/T1/T2/T4 Platforms)



Table 21. Public key (B4/T1/T2/T4 Platforms)



Table 22. SRK Table (B4/T1/T2/T4 Platforms)


0x00-0x03 Key 1 length

0x04-0x403 Key 1 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



LS1 Platform

Figure 18. CSF Header for LS1 (ISBC and ESBC Phase)

Table 23. CSF Header Format (LS1 Platform)









Boot Loaders



Table 23. CSF Header Format (LS1 Platform) (continued)




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.



• 0x0b-0x0a – Number of entries in srk table. Minimum number of entries in table = 1, Maximum= 4.

0x0f-0x0c RSA Signature offset.




SG Table offset


For ESBC Phase:

Address of the image to be validated.

0x1b-0x18 For ISBC Phase:


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).


0x21-0x20 Manufacturing Protection Flag

Indicates if manufacturing protection has to be enabled or not in ISBC.



Boot Loaders







0x25 For ISBC Phase










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


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


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




For ESBC Phase:




Boot Loaders






For ESBC Phase:

IE Key Select


Table 24. Scatter Gather Table Format (LS1 Platform)












Table 25. Signature (LS1 Platform)



Table 26. Public key (LS1 Platform)



Boot Loaders



Table 27. SRK Table (LS1 Platform)










Boot Loaders



LS1043/LS1012 Platforms

Figure 19. CSF Header for LS1043/LS1012 (ISBC and ESBC Phase)

Table 28. CSF Header Format (LS1043/LS1012 Platforms)









Boot Loaders



Table 28. CSF Header Format (LS1043/LS1012 Platforms) (continued)




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.



• 0x0b-0x0a – Number of entries in srk table. Minimum number of entries in table = 1, Maximum= 4.

0x0f-0x0c RSA Signature offset.




SG Table offset


For ESBC Phase:

Reserved

0x1b-0x18 For ISBC Phase:


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).


0x21-0x20 Manufacturing Protection Flag

Indicates if manufacturing protection has to be enabled or not in ISBC.



Boot Loaders







0x25 For ISBC Phase











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


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


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


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


For ESBC Phase: 64 bit pointer to ESBC image


For ESBC Phase:




Boot Loaders






For ESBC Phase:

IE Key Select


Table 29. Scatter Gather Table Format (LS1043/LS1012 Platforms)












Table 30. Signature (LS1043/LS1012 Platforms)



Table 31. Public key (LS1043/LS1012 Platforms)



Boot Loaders



Table 32. SRK Table (LS1043/LS1012 Platforms)










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.


Boot Loaders



Table 33. ISBC Validation Failures (P3/P4/P5 platforms) (continued)


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



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)


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


Boot Loaders



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)


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)


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



Table 38. General Header Checking Failures (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms)


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)


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)


Boot Loaders



Table 39. Key/Signature/UID related errors (B4/T1/T2/T4/LS1/LS1043/LS1012 platforms) (continued)


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)


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)


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


0x4 ERROR_ESBC_CLIENT_HEADER_BARKER

Wrong barker code in header


Boot Loaders



Table 42. ESBC Validation Failures (continued)


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


Boot Loaders



Table 42. ESBC Validation Failures (continued)


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


[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



Table 43. Memory map for P3/P4/P5/T1_T2_T4 platforms (continued)

Address(NOR vBank0)

Address (NORAlternateBank)[5]

Definition

(Chain of Trust)

Definition


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


SizeReserved(KB)

EC000000 EE000000 RCW RCW 128





Boot Loaders



Table 44. Memory map for B4 platforms (continued)

Address(NOR vBank 0)

Address(NORAlternateBank)[6]

Definition

(Chain of Trust)

Definition


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


esbc_validate 0xECD00000esbc_validate 0xECE00000esbc_validate 0xECF00000bootm 0xEC020000 0xEE020000 0xEC800000

LS1020

Boot Loaders



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


esbc_validate 0x63F20000esbc_validate 0x63F00000esbc_validate 0x63F40000bootm 0x60200000 0x60A00000 0x60020000

LS1043

Table 46. Memory map for LS1043 platforms

AddressNOR(vBank 0)


Definition

(Chain of Trust)

SizeReserved(KB)

60000000 64000000 RCW 128

60060000 64060000 Bootscript 128

60080000 64080000 ESBC U-Boot HEADER 128




Boot Loaders



Table 46. Memory map for LS1043 platforms (continued)

AddressNOR(vBank 0)


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


[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



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


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


# 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



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



bootm $img_addr

P3/P5 NAND SECURE BOOT

Table 48. Memory Map for P3/P5 NAND SECURE BOOT

Description

(Chain of Trust)

Description


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


Boot Loaders



Table 48. Memory Map for P3/P5 NAND SECURE BOOT (continued)

Description

(Chain of Trust)

Description


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


#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



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



#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




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



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




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



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;



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


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



./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:



#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



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>


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



1. Import rcw.bin from SDK in QCVS Tool.

2. Add ACS Data hdr_uboot.out @ 0xF00000.

Boot Loaders



3. Add ACS Data u-boot.bin @0xF40000.

Boot Loaders



Boot Loaders



4. Make Sure that the output format is Binary.

Boot Loaders



5. Generate Processor Expert Code to get PBL.bin.

Boot Loaders



.

Boot Loaders



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


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


• 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


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


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


http://qemu.weilnetz.de/qemu-doc.html

https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.pdf

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


http://www.linux-kvm.org

http://lwn.net/Articles/589122/

http://lwn.net/Articles/557132/

http://www.qemu.org

http://devicetree.org

http://git.jdl.com

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

http://wiki.qemu.org/Documentation/Networking

http://www.linux-kvm.org/page/Networking

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


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


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


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


/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


Virtualization

KVM/QEMU


Table 49. (continued)


-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


Virtualization

KVM/QEMU


Table 49. (continued)


-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


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


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


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


• 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


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


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


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)


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:


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


• 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.


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:


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


$ 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


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


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


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


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


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


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


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

http://www.nxp.com

http://www.nxp.com/support

http://www.nxp.com/SalesTermsandConditions

qoriq ls1012a bsp v0 - my-boardclub.com · 8.1 openssl offload user's guide ... 9.1.4 how to...

Documents