去年6月带有 8GB RAM的树莓派4是与树莓派 OS 64 位的beta版一起推出的。在当时安装新版本的用户其实很少，很多人使用的还是 32 位版本的 Raspberry Pi OS（以前称之为 Raspbian），因为那个时候 64 位的版本还存在很多错误且缺少一些功能。但因为我想了解最新版本的进度，所以我就安装了raspios_arm64-2020- 05-28/2020-05-27-raspios-buster-arm64.zip，并且我在启动板子的时候也没有遇到什么问题。我们一起来看看当时的情况：
树莓派操作系统 64 位的系统信息
在桌面环境中我通过设置向导配置了语言、时间、网络等，并且为了确保操作系统是更新后的，我还查看了一些信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
pi@raspberrypi:~ $ cat /proc/cpuinfo processor : 0 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 ... Hardware : BCM2835 Revision : d03114 Serial : 10000000694c8ae2 Model : Raspberry Pi 4 Model B Rev 1.4 |
我确实有一个带有 8GB 内存的树莓派 4 Model B Rev 1.4版（修订版：d03114），该镜像带有 64 位的 Linux 内核：
|
1 2 |
pi@raspberrypi:~ $ uname -a Linux raspberrypi 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux |
我确实也得到了一个 64 位的根系统文件（rootfs）。
|
1 2 |
pi@raspberrypi:~ $ file /bin/busybox /bin/busybox: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=fdf7b3dd496e8fd678a0bda5540f9fae4d313d8f, stripped |
一切看起来也都很正常。
已知的问题
在开始评测之前，我们先了解一下已知问题：
1)在免费开源跨平台的多媒体播放器 VLC 上 或 Chromium 中是没有硬件视频加速的
2) libraspberrypi0、libraspberrypi-dev 和 libraspberrypi-doc 已从 /opt/vc/* 移到了 /usr/* 中（目的是使其更标准）。针对这些库构建的任何代码都需要更改以引用更标准的位置（/usr/lib/ 而不是 /opt/vc/lib）
3) 由于第（2）个问题，许多需要 libGLESv2.so libEGL 等的包都需要重新编译
4) raspberrypi-bootloader 和 raspberrypi-kernel 包含无用的非 64 位二进制文件，并且缺少为最小化文件删除和安装到 /boot 之间的延迟所做的工作
5) 没有为 AArch64 构建的 Wolfram Mathematica
6) Minecraft 填充层需要重建以应对问题（2）
7) VLC 需要重新编译（不可用）
8) VNC 服务器尚未为 64 位重新编译
树莓派操作系统 64 位基准测试
大多数基准测试对 RAM 容量的要求不高（非涉及交换情况除外），但我仍然安装了 sbc-bench，用来与使用 Raspbian Buster 32 位镜像的树莓派4（1GB RAM）获得的结果进行了比较：
|
1 2 |
wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh chmod +x sbc-bench.sh |
SBC Bench的结果：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
sudo ./sbc-bench.sh sbc-bench v0.7.2 Installing needed tools. This may take some time... Done. Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Done. Executing OpenSSL benchmark. This will take 3 minutes... Done. Executing 7-zip benchmark. This will take a long time... Done. Checking cpufreq OPP... Done. It seems neither throttling nor frequency capping has occured. Memory performance: memcpy: 2503.6 MB/s (0.2%) memset: 3359.5 MB/s (0.5%) 7-zip total scores (3 consecutive runs): 5083,5065,5099 OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 38070.54k 40669.85k 41716.22k 42029.40k 42131.46k 42177.88k aes-128-cbc 38065.38k 40746.26k 41775.96k 42064.21k 42229.76k 42292.57k aes-192-cbc 32294.31k 34105.22k 35048.28k 35303.42k 35351.21k 35351.21k aes-192-cbc 32254.74k 34136.98k 35043.33k 35301.38k 35367.59k 35367.59k aes-256-cbc 27986.06k 29351.96k 29962.33k 30127.79k 30173.87k 30179.33k aes-256-cbc 27986.74k 29372.25k 29969.24k 30119.25k 30160.21k 30157.48k Full results uploaded to http://ix.io/2paq. Please check the log for anomalies (e.g. swapping or throttling happened) and otherwise share this URL. |
请注意，我使用的是KKSB 铝制外壳，因此散热不是问题。我们可以在下表中看到测试结果的比较（所有的数据都是越高越好）。
| Raspberry Pi 4 @ 1.5 GHz Raspbian 32 位 – 1GB RAM | Raspberry Pi 4 @ 1.5 GHz RPI OS 64 位测试版 – 8GB RAM |
|
|---|---|---|
| memcpy (MB/s) | 2,662.5 | 2,503.6 |
| memset (MB/s) | 3,436.9 | 3,359.5 |
| OpenSSL AES-256-CBC 16K | 64,951.64k | 30,157.48k |
| 7-zip | 5,397* | 5,082.33 |
* 7-zip的测试结果主要是针对树莓派 4 +散热器（不是 KKSB）的早期测试，因为在 KKSB 评测中，7-zip 内存不足且未完成。
正如我们所看到的，64 位的操作系统在所有四个结果中都比较慢。memset/memcpy 的差异也很小，7-zip的数据大约落后了 6%，而 AES-256 hash的测试数据则落后了高达 50+%。其实，我对后者并不感到惊讶，因为从2019年1月以来，就有人将树莓派上的 Debian OS 32位与64位 sbc-bench 脚本中的 AES-256-SBC 16KB测试进行了比较，并且获得了类似的结果。但不知什么原因 SHA1SUM（SHA1 hash函数）在 64 位操作系统上要快很多。
在树莓派OS 64位上进行功能测试和多任务处理
现在让我们尝试运行常规程序来找出潜在的错误或限制，同时看看总内存使用量什么时侯会超过 4GB RAM，超过之后再切换到 8GB RAM，这样的切换会比较值得。
我使用 htop（已使用 + 缓冲区 + 缓存）来监控总内存的使用情况。首先是运行带有多个选项卡、YouTube 和 Facebook 游戏（Candy Crush Saga）的 Chromium 浏览器，加载 VLC、Thunderbird、带有 .odt 文件的 LibreOffice，以及带有照片的 GIMP。
我还运行了 glxgears -info 用来确认图形加速是正在工作的（从Candy Crush Saga来看这一点也已经很明显了）。
|
1 2 3 4 5 6 |
glxgears -info Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. GL_RENDERER = V3D 4.2 GL_VERSION = 2.1 Mesa 19.3.2 GL_VENDOR = Broadcom |
我还在 VLC 中试着播放了 720p 和 1080p 的视频（H.264/H.265）。你们也可以查看下面的视频了解所有的步骤。
相关视频链接，点击此处可查看。
总而言之，树莓派OS 64 位现在的运行已经相当稳定了。Chromium 的使用也没有什么大问题，除了 YouTube 的播放还有一些问题。因为现阶段还缺乏一些硬件视频解码，播放1080p 视频的时候CPU占用率会过高，而 Candy Crush Saga (HTML5) 确实需要很长时间才能加载完成，但是一旦加载完成之后游戏播放就会很流畅了。我可以使用 VLC 播放 720p 和 1080p H.264 视频，但由于缺乏硬件视频解码，720p 和 1080p H.265 视频确实也会出现播放时断断续续的情况。
那么，我什么时候使用过超过 4GB 的内存呢？就是我在 Chromium 中打开了 8 个标签页后，我使用 Gmail 帐户的 Thunderbird、使用 LibreOffice Write 的一个文本文件、带一张照片的 GIMP、Thunderbird、两个终端和 VLC（不播放视频）。结果它的分析比我最初想象的还要复杂一些，因为已用的内存 (1.92 GB) 对应程序和操作系统占用的实际内存，而缓冲区和缓存是指系统用来加快 I /O 性能的RAM。因此，在具有 4GB RAM 的 树莓派 4 上，我们可以拥有 1.92GB 的已用内存和小缓冲区，而无需涉及交换。最后，还有一点你们需要注意。如果你让系统运行了更长的时间，缓存就会趋于增长从而耗尽所有的内存，因为“未使用的内存就是浪费内存”。
我还尝试在 /usr/src/hello_pi/ 中编译示例，但即使在更正新路径（/opt到/usr/src）之后，编译也不会完成，并出现以下错误：
|
1 2 3 4 5 6 7 8 |
triangle.c: In function ‘init_ogl’: triangle.c:119:11: error: unknown type name ‘EGL_DISPMANX_WINDOW_T’ static EGL_DISPMANX_WINDOW_T nativewindow; ^~~~~~~~~~~~~~~~~~~~~ ... /usr/bin/ld: cannot find -lbrcmGLESv2 /usr/bin/ld: cannot find -lbrcmEGL /usr/bin/ld: cannot find -lopenmaxil |
使用aptitude命令行检查时，会提示libbrcm* 库目前不存在于树莓派 OS 64 位的任何包中。这些示例的文档现在已经被弃用了，因此我觉得这些示例在短期内应该是不可以使用了。
文章翻译者：Nicholas，技术支持工程师、瑞科慧联（RAK）高级工程师，深耕嵌入式开发技术、物联网行业多年，拥有丰富的行业经验和新颖独到的眼光！