训练营

转眼到了卯兔新年，祝大家四时吉祥，万事顺意。在这里给大家准备了一些“灯谜”，欢迎大家来阅码场的春节灯谜会逛逛。留言你的答案，张健老师将从中选出一个赠送训练营名额。

环境一小步，兔年一大步（灯谜4）

题目

茂图公司的项目继续推进中，目前项目组CPU IP选型基本确定是Cortex-A715，但是商务谈判还在进行，公司暂时拿不到实际的Cortex-A715 IP。软件的预研还需要继续。项目组希望你在前面的基础上，帮忙分析Cortex-A715的基础开发环境如何搭建。具体包括qemu，build system和版本管理的选择建议。

对于qemu，需要列出用qemu可能验证的软件能力有哪些，哪些不能验证。对于build system和版本管理工具，希望你至少各找到两个，并进行对比。

注：请文章末尾留言你的答案，赢免费训练营名额。

“兔”选一（灯谜3）

前面的项目评估有了新的进展。项目组在考虑使用ARM Cortex-A76或Cortex-A715作为系统的CPU。目前已经确定该SOC应用在边缘计算领域，预计支持AI。项目组正在收集具体需求。希望你作为ARM架构领域的操作系统架构师，可以给出

•使用A76或A715在软件生态上的优缺点。

•CPU相关IP的选型还有哪些建议。

生态的调查可以分为固件/bootloader，内核，编译器，底层库，中间件等方面。可能会需要查看ARM架构相关的文档，可以参考如下思维导图：

留言可长可短，可以写问题1或问题2具体的分析或涉及到哪些软件组件，硬件模块。

题目解析

芯片研发过程中，往往需要软件团队从软件团队给出一些参考建议，例如不同IP对于业务的影响，对于开发工作量的影响等等。本题目从从这个角度从选择了其中一个环节的工作：CPU选型。软件帮忙评估相应CPU IP在社区的支持情况。

从之前只有模糊的ARM64到现在两个具体的CPU IP，能看出项目有推进。宏观上看，评估的纬度仍然是前面说的架构到业务的不同视角，具体可能会涉及到架构，CPU IP，SOC和业务等视角。按照ARM架构扩展的设计，每个CPU都会有个基线的架构版本，例如8.X，9.Y，该版本和更早版本的必备特性必须都支持，还可以支持后续版本的部分特性。

具体来说，Cortex-A76和Cortex-A715的架构基线分别是ARM8.2-A和ARM9.0-A。其余的特性需要阅读TRM(Technical Reference Manual)。TRM在昨天的题目中有涉及到。也可以参考这篇文章的介绍：ARM文档系列之一：系统软件工程师看ARM（https://mp.weixin.qq.com/s/IElSwXK5bpXpdVans0-cUw）。简单说ARM CPU TRM是针对某个CPU的介绍，重点是架构手册上Implementation Defined（允许每个CPU自行决定并实现的）部分以及架构中可选的部分。

所以这个题目，有几个部分的工作

•列出Cortex-A76和Cortex-A715的主要特性以及软件的支持情况；

•基于前面调查，根据每个软件的开发流程和维护方式，给出软件选型建议；

ARMv8-A和ARMv9-A特性对比

由于二者都是ARMv8.0之后的CPU，并且v8.0的软件生态已经很完善，所以下表仅仅从v8.1扩展开始。Cortex-A76和Cortex-A715主要特性的差异如下表（ARMv9的可选特性还包括CCA，不过A715不支持，暂时忽略）

（表格作者张健：来源：https://fvot4kwt4n.feishu.cn/base/bascnOqJV6oroLoaD65JjqiqI6l?table=tblj0XWsjtdVUgwP&view=vewpV1LnoO）

为了更好的支持CPU IP的选型，需要了解下具体每个特性的作用，以及整体ARM架构和操作系统的关系。举几个例子

PAC（指针认证）是一个安全特性，具体是为了防止ROP攻击。ROP是Return-Oriented Programming，攻击者通过修改堆栈上的返回地址操纵函数返回到不同的位置，通过一系列执行（称为代码片段）和跳转的组合，达到执行自己所需代码的目的。  ROP的预防方式有软件，软硬件协同等方式。

PAC是软硬件协同的方式。把指针，上下文（一般是栈指针）和key三者通过QARMA算法运算，把运算结果写到（64位）指针中系统不需要使用的bits。具体可以参考LWN的文章：https://lwn.net/Articles/718888/。PAC上下文的选择，涉及到APCS（辞旧迎新（答案）中有涉及），key的选择和进程管理相关，这分别涉及到了ARM架构和操作系统的能力。如果后续需要分配任务到具体的工程师，可以根据这些信息和工程师的背景/意愿进行分配。

针对PAC这个特性，Cortex-A76和Cortex-A715的比较就变成，A76上使用纯软件的ROP预防方式和A715上使用软件方式和或PAC的ROP预防方式的比较。也就是软件和PAC两个方式的比较，具体可以再调查性能开销，向后兼容性等等。

特性比较的时候，还需要考虑特性和特性之间的影响，例如PAC和MTE都使用了指针中系统不需要使用的bits，如果二者同时使用，各自可用的bit变少，对安全性会有影响。再比如，SPE和AMU都属于调测特性，这些调测特性与公司已有的调测工具是什么关系，与业务的场景是什么关系，如何能最大程度的用起来。调测这块内容比较多，请大家关注后续的文章。

软件版本备选

有了前面的特性分析和软件支持情况，可以再根据各自软件成份自身的开发和维护方式，列出可能的版本选型。

内核

内核的版本是X.YY的形式，X是主版本号，但是主版本号没有特殊含义。大约10周左右会有一个新的YY版本，20个YY版本左右会有一个主版本的变化。因为内核版本更新比较快，而实际业务周期以年计算，所以业务厂商需要一个内核版本可以长期维护，具体来说有内核社区维护的版本，发行版厂商维护的版本，其它组织（例如前面提到的Linaro）维护的版本和芯片厂商自己维护的版本。

芯片厂商为了降低自己的维护压力，会基于前面的维护版本添加自己内容。为了描述简单，这里直接基于内核社区维护的版本进行分析。内核社区维护的版本有两种，一种是stable，一种是longterm。stable是对最近发布的版本，维护周期很短。longterm是长期维护版本，社区至少会维护两年。（发行版维护的内核可以维护十年以上，有机会具体介绍）。

从kernel.org可以看到长期维护版本包括4.9，4.14，4.19，5.4，5.10和5.15。不考虑回合补丁的情况下，如果选择A76，5.4，5.10和5.15是可以选择的。如果选择A715，5.10和5.15可以选择。

（图片来源：kernel.org）

libc

libc是Linux系统在用户空间最基础的库，根据Linux系统的设计，libc和内核共同维护了内核ABI的稳定。通常在业务维护周期内，libc版本是不会升级的。以glibc为例，glibc社区使用的ABI检查工具（ABI compliance checker）和使用方法在这里有说明：https://sourceware.org/glibc/wiki/Testing/ABI_checker

对于题目中的CPU IP来说，前面表格中可以看到，A715的PAC和BTI特性和glibc相关，这至少需要glibc 2.32。

编译器

无论GCC还是LLVM对ARMv9-A的支持都不错，参见下图

（图片来源：http://aijishu.com/a/1060000000368030）

qemu

CA715的BTI，MTE，PAC，在qemu max中都可以支持。

其它软件的移植

A76仅仅在EL0支持aarch32，A715不支持aarch32。所以前一题说的Nucleus需要移植到64位平台（aarch64）。

总结

我们从CPU IP的特性分析开始，具体分析到主要软件成份可选的版本。在实际项目中，还会考虑版本归一，维护团队能力等需要综合考虑。

“兔”故纳新（灯谜2）

项目组看到你的评估，很认可你对Cortex-A8与ARM64生态的对比。这次新的平台对公司很重要，可以支持公司未来两代的产品。项目组希望评估更多的典型业务，更好的把旧业务迁移到新平台上。

公司之前有部分业务基于ARM926EJ-S，操作系统是Nuclues（一种RTOS），目前仍然是符合业务需要的。但是在新的多核ARM64平台上。一个平台上单独跑一个Nuclues会浪费大量硬件资源，能不能找到合适的软件方案——即不需要修改业务又可以使业务充分利用ARM64平台的能力——对于新项目的推进很重要。

项目组希望你做两项评估工作

•把Nucleus从仅支持ARM926EJ-S升级到支持ARM64平台的工作量；

•评估在新ARM64平台上运行Nucleus的方式。

回答可长可短，可以写某个具体的分析，例如移植工作量有几方面，需要几个人月等等。也可以思考下大致的方向，简单列写一下ARM64平台上运行Nucleus有哪些方式。

题目解析

ARM926EJ-S是ARM公司于2001年推出的基于ARMv5TE的CPU核。处理器对于操作系统的支持的最基本三方面内容是汇编语言，异常管理和内存管理。

Nucleus是一个实时操作系统。操作系统的移植可以分为架构移植，SOC移植和板级移植。对于题目涉及的硬件平台来说，这三方面都有涉及到。同时，题目没有给出具体的CPU IP名称。说明项目还处于非常早期。这种情况下，距离SOC和板级还有距离。可以先聚焦在架构移植。

除了移植的方式，希望旧系统运行在新平台上还可以通过模拟的方式。题目没有提到这个选项，如果是实际项目，还建议了解公司为什么不考虑模拟的方式，而直接希望移植到新平台。一个可能的原因是，之前运行在Nucleus的业务对实时性有要求，模拟方式不能满足实时性要求。作为参与到项目预研的软件架构师，了解整个项目的来龙去脉是很必要的。

从”辞旧迎新“和"‘兔'故纳新"两个题目可以看到，新的ARM64平台至少需要运行Linux和Nucleus。这是个异构系统，需要调查异构系统的管理方式。

Nucleus移植分析

如前所述，移植主要从架构角度入手，具体涉及到启动代码，异常管理， 内存映射，cache管理等。

首先，ARM64包括aarch32和aarch64，也就是32位和64位两个运行环境（Execution Environment，以下简称EE）。aarch64是全新的设计；aarch32和ARMv7-A几乎一致，与ARMv5TE差异相对于aarch64来说小很多。所以移植的分析，实际上包含了需要继续使用32位的环境还是迁移到64位这个选择。

二者各有利弊，如果继续用32位运行环境，假设新平台也支持，升级工作相对小一些，缺点是寻址能力受限，只能是32位。与其它操作系统或硬件模块通信时，寻址能力可能会影响软件或硬件的方案。如果使用64位系统，移植工作量相对大一些，但是可以更好的利用ARM64平台的新特性。因为移植到aarch64的工作量更大，先以此方向继续分析，等有更多输入时，再做决定。

启动代码主要是汇编语言，具体包括算术运算，跳转，访存指令，系统控制指令等。因为和ARMv5TE和ARMv8-A一样同属于RISC架构，所以算术运算，跳转，访存指令等指令是类似的，大部分可以用类似指令替换。差异比较大的是ARMv5TE通过协处理器（coprocessor）处理做cache一致性，MMU开关等系统控制操作。二者架构上间隔时间比较长，即使像ARMv5TE的control register和ARM64 aarch64的system control register功能很类似，由于间隔时间长，不能简单把名称一样的位阈看成完全对等的。

继续分析异常部分，ARMv5TE和ARMv8-A一样也有分层的异常级别，在非安全世界可以对应Linux的用户态和内核态，ARM64里面没有处理器模式的概念，同时增加了比Linux内核级别更高的EL2，用于支持虚拟化；在安全世界没有使用ARM64的EL3这个概念，而是用了secure monitor mode作为进入安全世界的大门。

在内存管理方面，ARMv5TE在页表使用C和B分别控制Cacheable和Bufferable。这和aarch32和aarch64两个EE都有很大差异。页表方面还需要注意到aarch32和aarch64两个EE的页表差异很大。

Nucleus的管理方式

目前开源的异构系统管理有Linux的remoteproc/rpmsg和OpenAMP两个框架。Linux下的remoteproc负责远端处理器管理，rpmsg负责消息收发，这个机制只能是Linux控制RTOS的启动和停止，不能反过来。

而OpenAMP包括了openAMP和libmetal两部分，其中libmetal负责硬件和操作系统的抽象，OpenAMP负责远端处理器管理和通信。OpenAMP既允许Linux控制RTOS，也允许RTOS控制Linux。

参考答案

•把Nucleus从仅支持ARM926EJ-S升级到支持ARM64平台，最小系统支持大约需要1个人月。

•在新ARM64平台上运行Nucleus的方式可以选择OpenAMP，分层更清晰，且Linux和RTOS都可以管理远端处理器。

辞旧迎新（灯谜1）

新年伴随着辞旧迎新，正如公司的业务也需要逐步迭代。茂图公司的“祖传”业务，最早运行在Cortex-A8平台上，最近因套片（主控芯片+相关芯片，例如主控+电源管理芯片，主控+接口转换芯片）后续没有支持，同时为了业务归一，需要迁移到新的64位ARM平台。

经过前期信息收集，已知业务主要用c语言编写，编译器是gcc 4.2.1。系统软件团队正在对之前BSP的工作做梳理，目前已知有如下两点修改

•时钟和中断控制器是自研的；

•使用了/dev/mem把特定设备的寄存器暴露给用户空间。

Cortex-A8是ARM公司2005年推出的CPU IP。当时的ARM系统定制化很多，缺乏完整的软件生态。这都对业务的迁移造成了不小的影响。作为系统软件部门的架构师，项目组希望你尽早参与到项目中。

项目组需要你做一些预研工作，请结合上述改动，列出哪些组件的哪些模块（例如内核里面包括驱动，内存管理，调度等若干大模块）需要修改，以及可能的方式（例如代码微调，重构，替换，升级等）。作为项目进一步推进的输入。

留言可长可短，可以写某个具体的分析，例如中断控制器驱动该如何思考，还需要哪些输入，如何行动等等。也可以思考下大致的方向，简单列一下修改，例如

组件

行动

时钟驱动

微调/重构/升级/替换四选一

中断控制器驱动

微调/重构/升级/替换四选一

用户空间驱动

微调/重构/升级/替换/四选一

...

...

题目解析

项目迭代中，经常会遇到把业务从旧平台迁移到新平台的需求。迁移过程中，新旧架构的对比，是很好的理解系统的架构的机会。题目描述的是从32位ARM CPU到64位ARM CPU（即ARM64）的迁移，其中涉及到大量硬件和软件的工作，具体来说可以从是生态和业务两个角度分析。生态方面，需要透彻了解当时CPU的生态以及当前的CPU的生态。从生态入手，结合业务需求，做好迁移工作。

题目是基于Linux的SOC平台的迁移。题目中的第一点修改关于定时器和中断。二者加上UART和其它的系统基本的初始化，称为最小系统。最小系统和业务关系不大，重点是从生态角度更好的支持迁移。第二点暴露特定硬件的寄存器到用户空间，这说明之前的BSP包括用户态驱动。用户态驱动可以很好的和内核解耦。这部分分析的重点是/dev/mem使用上的利弊，Linux上有没有其它的用户态驱动机制更适合业务需要。

Cortex-A8与ARM64生态的对比

Cortex-A8是ARM公司2005年推出的CPU IP，这背后的Cortex系列是ARM 公司构建生态的一个重要步骤，ARM公司联合各类厂商，从硬件IP，软件组件和驱动，社区和规范等方面建设生态。

Cortex-A8的内部编号是0xc08，其中的c透露了Cortex-A8相当于ARM12（Cortex-A的前任是ARM11）。8表示A8。这很像当初Intel公司推出的奔腾。没有用586，而直接用了奔腾。

参见下面Cortex和Pentium的简单对比：

ARM

INTEL

编号

Cortex

Pentium

流水线

超标量

超标量

多媒体指令

NEON

MMX

数据宽度

64bit

64bit

指令压缩技术

Thumb-2

硬件 IP方面，ARM 公司从Cortex系列开始更重视IP和生态的建设，把定时器，中断控制器等 IP 逐渐标准化为arch timer, Generic Interrupt Controller（简称GIC）。同时迭代相应的驱动。从Cortex-A9 SOC开始，arch timer和GIC逐渐成为主流。

随着Cortex-A系列的推出，TI，苹果，国内的中星微，Amlogic，Rockchip也纷纷基于这些CPU，推出自己的SOC。例如苹果公司分别于2010年和2011年推出A4和A5处理器。也是在2010年，ARM，Freescale，IBM，三星，意法-爱立信和TI等公司成立了ARM生态组织Linaro。华为海思也成为Linaro的核心成员。为了减少SOC的专有代码，以Linaro为首的ARM社区逐渐加入了device tree，gpio， pinctrl，regmap，cma等软件组件。

在规范方面，除了已有的 APCS（过程调用标准）与 c/c++语言对接，elf spec 与 elf 规范对接，从 2013 年开始，借助 Linaro 这个 ARM 生态组织，在ACPI 等标准上发力，使 ARM 在数据中心有了基础。除了对接已有的事实标准，结合 ARM 在数据中心的需要，把软硬件模块与服务器场景对应，推出了SBSA等标准。

在ARM生态发展的过程中，Cortex-A8处于一个非常早期的阶段，标准化的组件还非常少。所以题目的需要是把不够标准的组件迭代为更标准的组件，提高与ARM生态对接的能力，如果在不损失业务特点/优势的情况下，能减少所需维护的总代码量，还能降低长期的维护成本。

用户态驱动

/dev/mem允许访问所有的物理内存，站在ARM架构统一寻址的角度，这包括了所有的物理内存和寄存器空间。在没有合适的用户态驱动框架情况下，使用/dev/mem映射设备的寄存器空间，从而实现用户态驱动是非常方便的。但是这样有两个问题，安全性和隔离性。

安全性方面，/dev/mem可以访问内核空间，这可能对系统运行造成很大的影响。隔离性方面，使用/dev/mem可能造成寄存器访问的冲突，引发硬件错误。

如果驱动满足下面三个条件，可以尝试UIO（Userspace I/O）

•寄存器可以映射；

•基本的操作是寄存器读写和中断处理；

•没有现成的内核驱动可以使用。

参考答案

组件

行动

时钟驱动

替换为arch timer

中断控制器驱动

替换为GIC

用户空间驱动

替换为UIO或专有驱动