简介

本文简单介绍如何使用QNX提供的树莓派BSP源码BSP for Raspberry Pi BCM2711 R-PI4编译出ifs-rpi4.bin文件，将其拷贝到SD卡中，在树莓派PI4上启动QNX800。

简介

本文通过了在ubuntu使用了多种方式创建和运行qnx800 vm(Virtual Machine, 虚拟机) ，并比较了这几种方式的差异点。
方式1：通过mkqnximage快速创建并使用qemu-system_x84_64运行该qnx800 vm
方式2：通过Generic x86_64 BSP编译出image，并使用qemu-system_x84_64运行该qnx800 vm
方式3：通过BSP_aarch64_qemu_virt BSP编译出image，并使用qemu-system-aarch64运行qnx800 vm

背景

本文将介绍NXP的AHAB和HAB机制以及差异，详细说明如何一步步使用CST工具对镜像进行签名以及验签的过程。

secure boot简介

secure boot是基于数字签名认证。在启动流程中，第一部分去认证第二部分，以此类推，从而建立信任链。每个组件都使用其数字签名和public key验证前面一部分的有效性。

以下使用i.MX平台进行说明。
public key可以存到One-Time-Programmable (OTP) fuses里面，或者也可以将public keyhash化后(srk fuse)使其size减小并存到OTP中。在boot启动的时候，ROM code将存在bootloader中未hash化(srk table)的public keyhash化，然后与OTP中hash化过的public key进行比较（因为hash不可逆），如果相等，使用bootloader中未hash化的public key对已签名的bootloader进行校验。以此类推。如下是i.MX6(i.MX8没有CSF)平台安全启动的流程：

在上图中：
1、在安全的环境中对SW Image内容hash化生成摘要A，然后使用private key对摘要A进行签名（采用RSA算法），得到SW Image和Signature；
2、将该SW Image和Signature烧录到flash中后去启动；
3、在启动的时候会将SW Image内容hash化生成摘要B（如果SW Image没有被修改过，摘要A和摘要B肯定相等），使用Fuse中的public key进行对Signature进行验签得到摘要C，如果摘要B和摘要C相等，表示认证成功，就去启动OS。

注意，这里i.MX处理器中芯片存储的是SRK，而不是hash化后的值，所以该SRK可以直接进行验签。

前言

新冠疫情期间在家里无事可做，奈何手上没有现成的开发板，又想调试学习linux内核，于是就有了这一系列的文章。本系列文章包含以下内容：

• 在家学习嵌入式1-搭建qemu环境
• 在家学习嵌入式2-在qemu环境下使用uboot启动linux
• 在家学习嵌入式3-使用Buildroot构建编译系统
• 在家学习嵌入式4-Versatile Express开发板
• 在家学习嵌入式5-buildroot的使用

使用buildroot进行开发的问题

buildroot的正常操作是下载一个tar包，解压缩，配置，编译和安装tar包里面的软件组件。源码文件展开到output/build/<package>-<version>路径下，这是一个临时的目录。当执行make clean的命令后，这个目录将整个被删掉。当下次执行make命令的时候，该目录又会被重新创建。即使将Git或Subversion存储库用作包源代码的输入，Buildroot也会从中创建一个tar包，然后像对待tar包一样正常工作。
以我们的uboot为例，当我们执行make的时候，会从 https://gitee.com/wowothink/u-boot.git 仓库上下载uboot到dl/目录中，然后将其打包到dl/uboot/uboot-v2017.01.tar.gz的tar包，之后再解压该tar包到output/build/uboot-v2017.01/目录，之后就编译该目录。
按照上述的行为，我们不能在dl/目录下修改源码，因为该源码会从远程仓库下载，我们也不能修改output/build/目录下的源码，因为当我们执行clean的时候，这个目录就没了。很明显，buildroot这样做使用起来很不方便。buildroot的初衷是用作集成工具来构建和集成嵌入式Linux系统的所有组件，也就是希望尽量的稳定和减少修改。

buildroot针对此情形提供了一种特定的机制：<pkg>_OVERRIDE_SRCDIR机制，Buildroot读取_override_文件，该文件允许用户告诉buildroot某些软件包的源位置。当buildroot发现给定软件包已经定义了<pkg>_OVERRIDE_SRCDIR时，它将不再尝试下载，提取和给软件包打patch。相反，它将直接使用指定目录中可用的源代码，并且make clean不会触及该目录。这允许将buildroot指向你自己的目录，该目录可以由Git，Subversion或任何其他版本控制系统进行管理。为此，buildroot将使用_rsync_将组件的源代码从指定的<pkg>_OVERRIDE_SRCDIR复制到output/build/<package>-custom/目录。接下来我们就使用该机制，来进行uboot、kernel源码位置的重新指定。

前言

新冠疫情期间在家里无事可做，奈何手上没有现成的开发板，又想调试学习linux内核，于是就有了这一系列的文章。本系列文章包含以下内容：

• 在家学习嵌入式1-搭建qemu环境
• 在家学习嵌入式2-在qemu环境下使用uboot启动linux
• 在家学习嵌入式3-使用Buildroot构建编译系统
• 在家学习嵌入式4-Versatile Express开发板
• 在家学习嵌入式5-buildroot的使用

简介

为啥要用QEMU模拟Versatile Express开发板呢？主要是由于网上使用QEMU模拟Versatile Express开发板的资料比较多，于是乎就用这个开发板了。既然使用这块开发板，那么就要了解相关的信息：比如说SOC、板级硬件、原理图、memorymap等。本文就是详细介绍该开发板的一些资料，对于后续使用这块开发板大概有个认识，本文不是重点。

前言

新冠疫情期间在家里无事可做，奈何手上没有现成的开发板，又想调试学习linux内核，于是就有了这一系列的文章。本系列文章包含以下内容：

• 在家学习嵌入式1-搭建qemu环境
• 在家学习嵌入式2-在qemu环境下使用uboot启动linux
• 在家学习嵌入式3-使用Buildroot构建编译系统
• 在家学习嵌入式4-Versatile Express开发板
• 在家学习嵌入式5-buildroot的使用

编译系统

在前面的文章中，我们分别下载编译uboot、下载编译kernel、下载busybox制作ramdisk、下载toolchain、制作SD卡等。这些步骤比较繁琐，有没有一种方法一键生成所需的镜像并且打包到一起呢？我们先看一下嵌入式系统编译的输入和输出，输入源码，输出二进制镜像。其中就需要Embedded Linux build system来整合这些步骤，一键就需要依赖这里的build system（编译系统）来实现。目前的编译系统有Yocto/OpenEmbedded, PTXdist, Buildroot, OpenWRT。回想一下，SOC厂商发布BSP的时候，不可能一个个给你发布uboot、kernel的，而是将整个编译系统发布出来，据我所知NXP/MTK是通过Yocto发布，Pana通过Buildroot发布。

本文将使用buildroot作为编译系统，将我们之前使用qemu搭建的虚拟开发环境统一起来，实现一键编译打包。在这之前，我们先介绍一下buildroot。

前言

新冠疫情期间在家里无事可做，奈何手上没有现成的开发板，又想调试学习linux内核，于是就有了这一系列的文章。本系列文章包含以下内容：

• 在家学习嵌入式1-搭建qemu环境
• 在家学习嵌入式2-在qemu环境下使用uboot启动linux
• 在家学习嵌入式3-使用Buildroot构建编译系统
• 在家学习嵌入式4-Versatile Express开发板
• 在家学习嵌入式5-buildroot的使用

在前面的文章中，我们简单的编译一个kernel，然后使用qemu-system-arm -kernel指定启动一个特定的linux kernel，在虚拟开发板上可以这么做。但是在实际的开发板中，启动是一个很复杂的东西。在启动kernel之前，通常有个小的引导程序（本文使用u-boot），引导程序需要事先存储在某些存储介质上，比如SD、eMMC、Flash、USB。当启动的时候，会有RomCode去初始化某些关键外设并且拷贝引导程序到DDR上。现在某些SOC支持ATF和TEE的功能，启动会变得更加的复杂。本文不讨论启动流程，本文只介绍在qemu环境下使用uboot通过sd卡去启动linux。

前言

新冠疫情期间在家里无事可做，奈何手上没有现成的开发板，又想调试学习linux内核，于是就有了这一系列的文章。本系列文章包含以下内容：

• 在家学习嵌入式1-搭建qemu环境
• 在家学习嵌入式2-在qemu环境下使用uboot启动linux
• 在家学习嵌入式3-使用Buildroot构建编译系统
• 在家学习嵌入式4-Versatile Express开发板
• 在家学习嵌入式5-buildroot的使用

注意：这只是一个入门的文章，介绍自己如何一步步搭建qemu环境以及启动虚拟开发板。如果想要用现成的环境，可以去查看吴章金大牛发起的Linux lab 项目，那个项目做得非常的棒。

需求

作为嵌入式软件工程师，经常需要板子才能开发然后验证某些内容，这些东西在公司很容易实现。但是一回到家里，就没有这样的开发环境。因此，有没有这样一种仿真环境，支持某个虚拟的开发板，可以在上面跑uboot、linux kernel，从而进行uboot或kernel的调试而不必关心具体的外设器件。

为啥要介绍usb gadget configfs

在之前的2篇文章来介绍并验证usb gadget configfs，为啥呢？因为现在主流配置usb gadget都是采用configfs通过用户空间进行配置，而不是像之前使用hardcode方式专门有个内核模块来配置，来看一下Linux usb gadget的发展历程：

• David Brownell 在2003年之前引入gadget framework，只支持单一的gadget设备；
• composite framework 在2008年的时候加入进来，用来支持多个function的gadget设备；
• FunctionFS在2010年加入，允许用户空间创建function，并与内核寄存的function组成一个支持多个function的gadget设备；

但是上述还存在一个问题，就是还在自定义的内核模块中，将各个功能各个用例绑定在一起不够便利。因此，在Linux 3.11版本引入usb gadget configfs，支持一系列API，用户层可以通过该API定义任意功能和配置，从用户空间定义特定于应用程序的usb复合设备。
在Androidadb驱动实现原理这篇文章中，我们使用传统的hardcode方式来创建一个android adb的usb复合设备。在usb gadget configfs 验证文章中，我们使用usb gadget configfs方式创建一个mass storage的usb复合设备。无论是使用哪种方式，都是为了创建一个usb复合设备。本文将详细介绍通过usb gadget configfs创建usb复合设备的原理。