站点图标 CNX中文站

Polarfire SoC FPGA Icicle套件的Yocto Linux BSP入门

Nicholas Dong 董巷
本文共计4900字，预计阅读13分钟

上个月我收到了微芯（Microchip）的PolarFire SoC FPGA Icicle 开发套件，该套件的一大特点是 PolarFire SoC FPGA 具有 5 核 64 位 RISC-V CPU 子系统和一个 254K LE 的 FPGA，并被加载到了基于 OpenEmbedded 的预装 Linux 操作系统中。

本文我将展示如何快速使用 Yocto BSP 并运行 EEMBC CoreMark 基准测试，并且我还会在几周内评测这块带有Libero SoC 设计套件的FPGA。

PolarFire SoC FPGA支持的操作系统

我最初的想法是将这部分评测集中在 Linux 的 RISC-V 状态、检查一些系统信息、运行一些基准测试（例如 SBC-Bench）、编译 Linux 内核以及安装诸如 LEMP 堆栈（如：Linux、Nginx（发音为 Engine-X）、MySQL、PHP）之类可以用于WordPress 托管的服务。随后我又查看了 Microchip PolarFire SoC FPGA 支持的操作系统。

Polarfire SoC FPGA操作系统

查看之后，我了解到Microchip 支持 Yocto Linux BSP 和 Buidlroot Linux BSP，以及 Siemens Embedded 和 WindRiver 等第三方嵌入式的 Linux 发行版。据说 FreeBSD 即将推出，并且可能会有几个实时操作系统用于 SoC 的小型 64 位 RISC-V 内核。

这意味着除了我计划使用的一些工具之外，没有包管理器和基于 Debian 的根文件系统了。因此，虽然从理论上讲，仍有可能实现我打算做的事情，但我实在没有那么多时间来实现这一目标了，所以我缩小了我的评测范围。我根据从镜像构建 Yocto 镜像的经验，交叉编译了 hello world，同时进行本地编译和运行 EEMBC 基准测试。这其实不是我第一次上手Yocto 项目了，但我仍然学到了一些东西，希望你们也能从中有所收获。

网络服务器演示和电压/电流分析

在开发 Yocto BSP 之前，根据 Microchip 的入门指南我将开发板连接到了以太网，并运行网络服务器。


运行后，我们可以访问一个网页，该网页将显示 VDDA（XCVR Tx/Rx 通道电源）、VDD25（PLL 和 PNVM 电源）、VDDA25（XCVR PLL 电源）和 VDD（内核电源）的电压和电流，方法是访问 http:/ /<board_ip_address>。

Icicle Kit电压电流分析

我想一旦我们运行了 EEMBC CoreMark 基准测试，重新访问此页面应该会很有趣。

Yocto Linux BSP

接着我们按照Github上的说明使用 Yocto BSP 构建 Linux 。作为参考，我使用的是运行 Ubuntu 20.04 的笔记本电脑。在此我需要更改一些命令。

首先，我们安装 repo 函数：


然后安装一些依赖项：


初始化 repo 的时间：


现在我们可以修改设置文件：


在开始构建前，要运行以下命令：


我记得大约 10 年前，Yocto 构建系统可能需要花大量的时间，在低端笔记本电脑上构建镜像甚至要超过 24 小时。而且在默认设置下，我由 8 核 AMD Ryzen 7 2700U 处理器驱动并配备了 16 GB RAM的笔记本电脑，在 50 多的 CPU 负载下运行都由很快变得极其慢甚至无法使用：

Polarfire Icicle构建Yocto系统

我构建之后就去吃饭然后上床睡觉了。但我没有检查存储需求，大约两个小时后，由于硬盘空间不足，构建就停止了。正如我们看到的，要构建完成，大约需要100 GB的可用存储空间。

Libero SoC的存储需求

接着我们来讨论系统要求，Libero SoC 设计套件需要大约 35 GB 的额外空间，而 PolarFire SoC 开发至少需要 16 GB RAM。因此，你们需要一个功能强大的工作站来在 PolarFire SoC FPGA Icicle 开发套件上开发应用程序，并具需要有足够的 RAM 和足够的存储空间。

回到我们的 Yocto 构建。理想的情况是拥有一个专用的构建服务器，但如果你打算在构建的同时使用计算机，你可能就需要编辑 [your_yocto_build_dir]/conf/local.conf


然后，按照如下操作


另一种方法是使用 Ctrl-Z 暂停构建，其工作方式与 Ctrl-C 类似，但使用SIGTSTP而不是 SIGINT 来暂停进程，记住是暂停而不是终止它。


由于 bitbake 产生了许多其他进程，我们必须等待它们完成，大约需要 10 分钟才能恢复使用普通计算机。

我将构建进程暂停了大约 3 个小时，然后可以使用命令“fg”恢复它。这就像终端程序的休眠模式，它一直存在。然而要么是我忘记了它，要么自己从未使用过。，所以几经折腾之后，在我的机器上完成构建大约花了 7 到 8 小时。

这是 Yocto BSP 使用的空间：


我们可以在tmp-glibc/deploy/images/icicle-kit-es/文件夹中找到镜像：


未压缩的镜像有 5.5GB，因此 8GB SD 卡是够使用的。但我建议使用 16GB 或 32GB 卡。下面是 Microchip 提供的将其闪存到 SD 卡的命令：


如果你想要验证镜像，像USBImager这样的实用程序将是首选。这就是我用来将镜像烧写到 32GB SD 卡的方法，然后我将其插入开发板的 SD 卡插槽中进行试用。

我们中断启动来检查一下是否能检测到 SD 卡：


一切正常了，我们继续，但它无法切换到内核。最终我使用了未压缩的二进制文件重新刷新镜像，然后我就可以登录到终端：


rootfs 没有自动调整大小，似乎是因为 GPT 表有问题。我不太确定这一步发生了什么。但是由于我们的自建镜像正在运行，而且我们有一个 eMMC 闪存，我就闪存到了内部存储。

将板子断电，取出SD卡，用Bootterm连接ttyUSB0，访问HSS终端：


在重新启动开发板之前，中断启动，然后输入“usbdmsc”将 eMMC 闪存作为 USB 大容量存储开放给我们的 Ubuntu 笔记本电脑。


注意，在这里我们需要另一根连接到 J16 Micro USB 端口的 Micro USB 电缆才能在 Ubuntu 中查看烧录过程。

PolarFire SoC FPGA Icicle Kit
PolarFire Icicle的eMMC、USB、闪存和驱动

我们可以像对 SD 卡那样在烧录镜像之前卸载 Boot 和 root 分区。我先尝试使用 gz 镜像，但我遇到了与 SD 卡相同的问题，即使在 PC 上也无法安装root分区，因此我就使用未压缩的镜像了，之后一切顺利。

Flash eMMC PolarFire FPGA SoC Icicle

完成后，我们就可以拔掉连接到 J16 的 micro USB 电缆，并访问我们的 Linux 镜像。

小标题：Hello World 交叉编译

接下来，我们尝试交叉编译的 Hello World 程序。


对于使用 Yocto 工具链的 RISC-V，我们要首先将其添加到我们的路径中：


并使用 RISCV GCC 工具来构建它：


糟糕，它并没有按预期工作。看起来是因为工具链没有正确安装，或者是因为我使用了错误的工具链。我尝试过使用 CFLAGS，但还是没有成功。也许它只能在 Yocto/Bitbake 框架中工作。根据我以往对 buildroot 的经验，交叉编译工具链是可以开箱即用的。

EEMBC CoreMark 基准

所以我将在本地构建 EEMBC CoreMark，即直接在板上构建。我们构建的镜像带有 git 和 GNU GCC 工具链，所以它应该很简单。


这一操作可以构建和运行 CoreMark 并生成两个文件


由于 RISC-V 内核以 600 MHz 运行，该板获得了 1339.136257 的分数，大约 2.23 CoreMark/MHz。但是Microchip 报告板上显示有3.25 CoreMark/MHz。让我们与Microchip公司使用相同的配置再试一次：


这是 run1.log 的内容：


不知何故，CoreMark 的分数找不到了，但我们仍然可以看到其迭代次数/秒从 1341.651573 达到了 1666。由此看来新配置确实有所提高了。很容易看出为什么分数没有显示了，我们也可以看看代码：


我们用 -DHAS_FLOAT=1 重复这个过程。


这次看起来是正确的：


但这只有 2.59 CoreMark/Mhz，还没有达到 3.125 CoreMark/MHz。实际上，它是使用无符号索引的，而且符合Microchip的结果。有人也尝试做了同样的事情，并被很多人建议更改posix/core_portme.h 中的代码以使用签名索引：


再次运行基准测试后，得分更高：


1789.159376 CoreMark 对应的大约是 2.98 CoreMark/MHz。接下来通过在 make 命令行中定义 HAS_FLOAT=0 来做最后的破解。结果：


看看我们使用 Iterations/Sec 的结果：1875 作为 CoreMark 1.0 的数值。在这种情况下，我们确实可以达到 3.125 CoreMark/MHz，就像 Microchip 使用带符号索引所做的那样。但是为什么有符号比无符号快得多，我不太确定。我们需要查看一下程序集，并检查每条指令的周期数才能找出答案。

这次测试过程真实地展示了如何调整/操纵基准以获得更好的结果，以及编译标志对优化代码的重要性。电压/电流分析网页在测试期间没有显示任何显著变化。

这就是本文评测的全部内容，之后，我可能会发布一些 FPGA 部分的内容。有人让我通过 PCI-e 总线评估 virt-io，但由于时间限制，我就没有这样做。因为有人说Microchip应该可以工作，我还咨询了他们，但他们到目前为止并没有测试过。

如果你们对该板感兴趣，可以从各种分销商处购买，价格应该不到 500 美元。

分享这篇文章
退出移动版