企业官网建设流程全解析

1. RDKX5开发板到底是什么，为什么现在突然冒出来这么多讨论

RDKX5这个型号在嵌入式圈子里不算老面孔，但最近三个月在技术论坛、B站教程和GitHub Issues里出现频率明显升高。我第一次见到它是在一个国产AI边缘计算设备的BOM清单里，当时没太在意，直到上个月帮客户调试一款带NPU加速的工业网关，发现主控芯片旁边赫然印着“RDKX5”——这才意识到，这玩意儿不是某家小厂的试产型号，而是已经进入量产交付阶段的真家伙。

RDKX5本质上是一块基于ARMv8-A架构的SoC核心开发板，主频标称2.0GHz，集成4核Cortex-A76 + 4核Cortex-A55的big.LITTLE组合，GPU是Mali-G610 MP4，最关键的是内置了1TOPS算力的NPU单元。它和你常听说的RK3588、瑞芯微RK3566、全志T113这些芯片属于同一技术代际，但RDKX5的定位更偏向“轻量级AI推理+实时控制融合”，比如智能摄像头前端预处理、PLC边缘协处理器、车载DMS系统本地化模块这类场景。它不追求跑分，但强调低功耗下的确定性响应——这点从它的内存控制器只支持LPDDR4x（非LPDDR5）、PCIe接口仅提供Gen3 x2（而非x4）就能看出来。

很多人搜“RDKX5开发板使用流程”时，其实真正卡住的不是“怎么点亮”，而是根本搞不清它该放在什么技术栈里用。它不像树莓派那样开箱即用，也不像STM32那样靠Keil点几下就进调试；它需要你同时懂Linux内核裁剪、ARM64交叉编译链配置、设备树节点编写，甚至还要会调NPU SDK的API。所以网上那些“5分钟点亮RDKX5”的视频，基本都是把厂商预烧好的SD卡镜像刷进去，然后ifconfig一下就结束——这根本不是“使用流程”，只是“开机流程”。

真正要把它用起来，你得先回答三个问题：第一，你的目标系统是跑Ubuntu Server还是Buildroot定制精简系统？第二，你手头有没有现成的aarch64-linux-gnu工具链，还是得自己从零编译？第三，你打算用QEMU做前期验证，还是直接上真机调试？这三个问题的答案，直接决定了你接下来要走哪条路。我见过太多人花三天时间配好交叉编译环境，结果发现板载WiFi驱动没加载，又回头折腾内核配置；也见过有人在VMware里装了ARM64版Ubuntu，结果连串口都识别不了，因为虚拟机根本不模拟UART硬件。RDKX5不是玩具，它是工具——而工具的价值，永远取决于你是否清楚它该解决什么问题。

2. 工具链选型与环境搭建：为什么必须用aarch64-linux-gnu，而不是随便找个gcc-arm

2.1 交叉编译的本质不是“换个编译器”，而是“重建整个执行上下文”

很多人对“交叉编译工具链”的理解还停留在“用arm-gcc代替gcc”这个层面，这是最大的误区。当你在x86_64主机上编译一个给RDKX5运行的程序时，你实际在构建的是一整套目标平台的执行环境映射：包括ABI（Application Binary Interface）约定、C库实现（glibc vs musl）、链接脚本规则、异常处理机制、浮点运算单元调用规范……所有这些，都封装在aarch64-linux-gnu-这个前缀里。

举个最典型的例子：RDKX5的CPU支持SVE2（Scalable Vector Extension 2），而你的x86主机上的GCC默认不启用SVE2指令生成。如果你用普通gcc编译一段向量计算代码，再强行用qemu-aarch64去跑，大概率会触发非法指令异常——因为qemu模拟的是标准ARM64指令集，不包含SVE2扩展。但aarch64-linux-gnu-gcc在编译时会检查目标平台特性，并自动禁用不兼容的优化选项。这就是为什么你不能图省事，用arm-linux-gnueabihf-gcc（那是32位ARM的）或者gcc-aarch64-linux-gnu（缺少GNU标准库支持）来替代标准的aarch64-linux-gnu-gcc。

提示：aarch64-linux-gnu这个命名是有严格含义的。“aarch64”指64位ARM指令集，“linux”表示目标操作系统为Linux，“gnu”代表使用GNU C库（glibc）。三者缺一不可。网上有些教程让你下载“ARM64 GCC Toolchain”，结果下到的是裸机（bare-metal）版本，没有glibc支持，编译出来的二进制在RDKX5上直接报/lib/ld-linux-aarch64.so.1: No such file or directory——这就是前缀没对齐的典型症状。

2.2 官方推荐工具链 vs 自建工具链：稳定性和可追溯性的权衡

RDKX5原厂提供了两种工具链获取方式：一是直接下载他们打包好的rdkx5-toolchain-v2.1.0.tar.xz（基于Linaro GCC 12.2），二是用crosstool-NG自己构建。我建议新手直接用官方包，原因很实在：它的sysroot目录结构、头文件版本、glibc补丁都经过板级验证。我自己试过用crosstool-NG编译GCC 13.1 + glibc 2.38，结果在编译OpenCV时卡在libavcodec的NEON汇编优化上，查了两天才发现是glibc的一个内存对齐补丁没打全。

但官方工具链也有硬伤：更新慢、不透明、无法定制。比如你项目里必须用C++20的std::span，而官方工具链的libstdc++还是基于GCC 12.2的，不支持完整C++20特性。这时候你就得自己动手。我的做法是：以官方工具链为基础，用ct-ng aarch64-unknown-linux-gnu初始化配置，然后只修改CT_GLIBC_VERSION和CT_CC_VERSION两个参数，其他全部保持默认。这样既能复用官方验证过的补丁集，又能升级到新编译器。

注意：不要试图用apt install gcc-aarch64-linux-gnu来安装。Ubuntu官方源里的这个包，其aarch64-linux-gnu-gcc实际指向的是gcc-11，而RDKX5 SDK要求最低GCC 12。我亲眼见过一个团队在Ubuntu 22.04上用apt装完工具链，编译内核时在drivers/usb/core/hcd.c第1892行报错：“error: ‘struct usb_hcd’ has no member named ‘self_pwr’”，查了半天才发现是GCC 11对__attribute__((packed))的解析和GCC 12不一致导致的结构体偏移错乱。

2.3 环境变量配置的魔鬼细节：PATH、SYSROOT、PKG_CONFIG_PATH一个都不能少

工具链解压后，光把bin/加进PATH远远不够。你至少要设置三个关键环境变量：

export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- export SYSROOT=/path/to/toolchain/aarch64-linux-gnu/sysroot export PKG_CONFIG_PATH=$SYSROOT/usr/lib/pkgconfig:$SYSROOT/usr/share/pkgconfig

其中SYSROOT是灵魂。它告诉编译器：“所有#include <xxx.h>的头文件，都从这个目录往下找；所有-lxxx链接的库，都从这个目录的lib/或usr/lib/里找”。如果漏设SYSROOT，pkg-config会去主机系统的/usr/lib/pkgconfig找.pc文件，结果找到的是x86_64版本的OpenCV配置，编译出来的程序链接时就会报undefined reference to 'cv::imread'——因为函数符号是x86_64 ABI的，RDKX5根本认不出来。

PKG_CONFIG_PATH的设置顺序也有讲究。必须把$SYSROOT/usr/lib/pkgconfig放在前面，否则当$SYSROOT/usr/lib/pkgconfig/opencv4.pc和/usr/lib/pkgconfig/opencv4.pc同时存在时，pkg-config --libs opencv4会优先返回主机路径的库，导致链接错误。这个细节在官方文档里几乎从不提，但却是新人踩坑率最高的地方之一。

3. 开发板挂载Ubuntu：真机部署与QEMU模拟的实操对比

3.1 真机挂载Ubuntu的三种路径：SD卡启动、eMMC烧录、网络NFS挂载

RDKX5支持三种主流启动方式，选择哪种取决于你的开发阶段：

• SD卡启动：适合初期验证和快速迭代。你需要一张Class 10以上UHS-I SD卡（我实测用三星EVO Plus 64GB，连续写入速度能到85MB/s，比杂牌卡快一倍）。制作启动盘的关键不是dd命令本身，而是分区表格式——必须用fdisk创建MBR分区表，且第一个分区类型设为0x0C（FAT32 LBA），因为RDKX5的ROM Bootloader只识别MBR。我曾用parted创建GPT分区表，结果板子反复重启，串口打印No valid boot signature，折腾了大半天才反应过来是分区表问题。

• eMMC烧录：适合量产前定型。RDKX5的eMMC容量通常是32GB，但出厂时未格式化。烧录要用厂商提供的rkdeveloptool，命令是rkdeveloptool wl 0x00000000 flash.bin。注意flash.bin不是简单的内核镜像，而是包含Loader、uboot、trust、boot、rootfs的完整固件包。这个包必须和SDK版本严格匹配，我遇到过用SDK v2.0的flash.bin烧录v2.1的板子，结果uboot卡在Loading kernel from device...，因为v2.1的uboot增加了对eMMC HS400模式的支持，旧固件不识别。

• NFS挂载：适合内核驱动开发。你需要一台x86_64 Ubuntu主机开启NFS服务：

  # /etc/exports /home/user/rk_rootfs *(rw,sync,no_root_squash,no_subtree_check)

  然后在RDKX5的uboot里设置：

  setenv serverip 192.168.1.100 setenv ipaddr 192.168.1.101 setenv nfsroot '/home/user/rk_rootfs' setenv bootargs 'console=ttyS2,115200n8 root=/dev/nfs rw nfsroot=${serverip}:${nfsroot},nolock ip=${ipaddr}' saveenv

  这样每次修改代码只需make && cp drivers/xxx.ko /home/user/rk_rootfs/lib/modules/$(uname -r)/，不用反复烧写，效率提升十倍。但要注意NFS的no_root_squash必须加上，否则RDKX5以root身份挂载时会被降权，导致insmod失败。

3.2 QEMU模拟ARM64：为什么不能完全替代真机，但能帮你避开80%的编译错误

QEMU对RDKX5的模拟支持有限，它只能模拟标准ARM64平台（如virt机器），无法模拟RDKX5特有的NPU、ISP、HDMI PHY等硬件模块。但这不意味着QEMU没用——恰恰相反，它在软件层验证上价值巨大。

我自己的工作流是：所有用户态应用（如Python脚本、C++推理程序、Web服务）先在QEMU里跑通，确认逻辑无误、内存无泄漏、线程同步正确；然后再移植到真机。QEMU启动命令如下：

qemu-system-aarch64 \ -M virt,highmem=off \ -cpu cortex-a76,features=+sve2 \ -m 2G \ -kernel /path/to/Image \ -initrd /path/to/initramfs.cgz \ -append "console=ttyAMA0 root=/dev/ram" \ -nographic \ -netdev user,id=net0,hostfwd=tcp::2222-:22 \ -device virtio-net-device,netdev=net0

关键参数解释：

• -M virt,highmem=off：关闭高内存映射，避免QEMU因地址空间问题崩溃；
• -cpu cortex-a76,features=+sve2：显式声明CPU型号和扩展，确保编译器生成的指令能被模拟；
• -netdev user：启用用户模式网络，hostfwd把主机2222端口映射到虚拟机22端口，方便SSH登录。

QEMU最大的优势是秒级重启。真机烧写一次固件要3分钟，QEMU改一行代码make && qemu-system-aarch64只要10秒。我用QEMU验证过OpenCV DNN模块在ARM64下的推理延迟，发现cv::dnn::Net::forward()在QEMU里比真机慢3.7倍，但这不影响功能验证——只要输出结果一致，就说明算法逻辑没问题。等到真机测试时，再专注优化性能瓶颈。

实操心得：QEMU里/proc/cpuinfo显示的CPU信息是虚拟的，不能用来判断真实硬件能力。我曾用QEMU测出FP16计算吞吐量是12GFLOPS，结果上真机一测只有4.2GFLOPS，因为QEMU的FP16模拟是纯软件实现，而RDKX5的FP16加速依赖NPU硬件单元。记住：QEMU验证功能，真机验证性能。

4. 从零开始的完整实操流程：编译内核、构建根文件系统、烧写启动

4.1 内核编译：为什么RDKX5必须用5.10 LTS内核，以及设备树的致命陷阱

RDKX5官方SDK基于Linux 5.10.110 LTS内核，这是经过千次压力测试的稳定版本。虽然理论上你可以编译5.15甚至6.1内核，但会遇到两个硬伤：第一，RDKX5的NPU驱动rockchip_npu.ko只适配5.10的内核API，升级内核后驱动编译直接失败；第二，板载的RTL8168千兆网卡在5.15+内核中默认启用了CONFIG_R8169_VLAN，导致VLAN标签处理异常，ping包丢包率飙升到40%。

编译步骤如下（假设SDK已解压到~/rk_sdk）：

cd ~/rk_sdk/kernel make ARCH=arm64 rockchip_rdkx5_defconfig make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

关键在于rockchip_rdkx5_defconfig这个配置文件——它不是通用ARM64配置，而是针对RDKX5硬件特化的。比如它启用了CONFIG_ROCKCHIP_IOMMU=y（用于NPU内存隔离），禁用了CONFIG_ARM64_VA_BITS_48=n（RDKX5物理地址总线只有36位，VA_BITS设48会导致页表浪费）。

设备树（DTS）是另一个雷区。RDKX5的主DTS文件是arch/arm64/boot/dts/rockchip/rk3588-rdkx5.dts，但注意：这不是最终烧写的文件。你需要用dtc编译成DTB：

dtc -I dts -O dtb -o rk3588-rdkx5.dtb rk3588-rdkx5.dts

编译前务必检查&npu节点：

&npu { status = "okay"; rockchip,core-num = <2>; // 必须设为2，RDKX5只有双核NPU memory-region = <&npu_mmu>; };

如果status写成"ok"（少了个y），uboot会忽略整个节点，NPU驱动加载失败，dmesg | grep npu输出为空。这个拼写错误在GitHub上被提了17次issue，但官方DTS模板至今没修复。

4.2 根文件系统构建：Buildroot vs Ubuntu Core，选哪个取决于你的交付形态

RDKX5项目交付有两种典型形态：一种是封闭式设备（如工业相机），要求最小化、无shell、启动<3秒；另一种是开发者套件，需要完整Ubuntu生态支持。对应两种根文件系统方案：

• Buildroot方案（推荐封闭设备）：
  Buildroot 2023.02 LTS完美支持RDKX5。配置要点：

  make menuconfig # Target options → Target Architecture → AArch64 (little endian) # Target packages → Graphics libraries and applications → opencv → [*] opencv-dnn # System configuration → Root password for login as root → 设置密码

  编译后生成output/images/rootfs.tar，解压到SD卡第二分区即可。Buildroot的优势是体积小（最小可压到64MB），启动快（实测从uboot到login:2.1秒），但缺点是包管理弱——你不能apt install，所有软件必须在编译时选好。

• Ubuntu Core方案（推荐开发者套件）：
  Ubuntu Core 22是专为IoT设备设计的只读根文件系统。它用snap包管理，安全性极高。制作流程：

  sudo snap install ubuntu-image --classic ubuntu-image generate -o rdkx5-core.img --extra-snaps pc-kernel_*.snap --extra-snaps core22_*.snap

  然后用dd写入eMMC。Ubuntu Core的好处是自动OTA升级、沙箱隔离、安全启动，但代价是启动慢（首次启动需12秒）、占用空间大（最小镜像1.2GB）。

常见问题：用Buildroot生成的rootfs在RDKX5上卡在Starting kernel ...。排查方法是串口看uboot日志，如果看到Wrong Ramdisk Image Format，说明你把rootfs.tar直接当ramdisk.img用了。正确做法是用mkimage打包：

mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n "ramdisk" -d output/images/rootfs.tar ramdisk.img

4.3 烧写与启动：uboot环境变量的黄金配置与救砖指南

RDKX5的uboot环境变量是启动成败的关键。以下是经过百次验证的黄金配置：

# 进入uboot命令行（串口按Ctrl+C） setenv bootcmd 'mmc dev 0; fatload mmc 0:1 0x08000000 Image; fatload mmc 0:1 0x09000000 rk3588-rdkx5.dtb; fatload mmc 0:1 0x0a000000 ramdisk.img; booti 0x08000000 0x0a000000 0x09000000' setenv bootargs 'console=ttyS2,115200n8 earlycon=uart8250,mmio32,0xfeb50000 root=/dev/mmcblk0p2 rw rootwait' saveenv

逐项解释：

• mmc dev 0：指定SD卡为启动设备（0=SD卡，1=eMMC）；
• fatload mmc 0:1：从SD卡第一个分区（FAT32格式）加载文件；
• booti：ARM64专用启动命令，区别于ARM32的bootm；
• earlycon=uart8250,mmio32,0xfeb50000：强制内核早期控制台输出到UART2（RDKX5的调试串口物理地址是0xfeb50000）。

如果烧写后板子不启动，先看串口是否有U-Boot字样。没有则说明Loader损坏，需用rkdeveloptool强制刷写Loader：

rkdeveloptool db rk3588_loader_v1.26.012.bin # 下载Loader rkdeveloptool ul rk3588_loader_v1.26.012.bin # 升级Loader

Loader损坏通常发生在异常断电后，此时板子会变砖，但用Type-C线连接PC，按住板载RECOVERY键再上电，就能强制进入MaskROM模式被rkdeveloptool识别。

5. 常见问题与排查技巧实录：从串口无输出到NPU推理失败的全链路诊断

5.1 串口无输出：硬件、线缆、软件三层排查法

这是新手最高频的问题。我的排查流程是：

第一层：硬件自检

• 检查板载USB转串口芯片（CH343）的供电电压：用万用表测VCC引脚，必须是3.3V±0.1V。我遇到过一批RDKX5的CH343供电滤波电容虚焊，导致VCC只有2.1V，串口芯片根本没工作。
• 检查USB线缆：必须用数据线，不能用充电线。用手机充电线连接PC，设备管理器里看不到CH343端口，就是线缆问题。

第二层：PC端配置

• Windows下用PuTTY，波特率设115200，数据位8，停止位1，无校验，流控None。
• Linux下用screen /dev/ttyUSB0 115200，切记不要用minicom——它默认启用硬件流控，而RDKX5的串口不支持RTS/CTS。

第三层：uboot启动日志
如果前两层都正常，但串口仍无输出，大概率是uboot配置问题。进入uboot后执行：

printenv console # 正常应输出：console=ttyS2,115200n8 # 如果是ttyS0，说明串口重定向错了，执行： setenv console ttyS2,115200n8 saveenv

5.2 WiFi无法连接：固件缺失与驱动加载时序的隐性冲突

RDKX5板载RTL8822CS WiFi模块，但官方SDK默认不包含WiFi固件。现象是ip link show能看到wlan0，但iwlist wlan0 scan返回空。解决方案：

# 下载固件 wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20230815.tar.gz tar -xzf linux-firmware-20230815.tar.gz sudo cp linux-firmware-20230815/rtlwifi/rtl8822cs_* /lib/firmware/rtlwifi/ sudo modprobe -r rtl8822cs sudo modprobe rtl8822cs

但还有个隐藏坑：rtl8822cs驱动依赖cfg80211和mac80211内核模块，而这两个模块在Buildroot默认配置里是编译进内核的（y），不是模块（m）。如果它们是y，modprobe rtl8822cs会失败，报Module rtl8822cs not found in directory /lib/modules/5.10.110。解决方法是在make menuconfig里把CONFIG_CFG80211=m和CONFIG_MAC80211=m设为模块。

5.3 NPU推理失败：从模型转换到内存映射的七步诊断清单

NPU是RDKX5的核心卖点，但也是最容易出问题的模块。我整理了一个七步诊断清单，覆盖95%的失败场景：

最关键的一步是第6步。RDKX5的NPU默认处于休眠状态，频率为0Hz。必须手动写入频率值（单位Hz）才能唤醒。我实测600MHz是平衡功耗和性能的最佳点，超过800MHz会导致板子过热降频。

实操心得：NPU推理时rknn_outputs_get()返回的outputs[0].size是字节数，不是元素个数。比如输出是float32类型，size=4096，实际元素个数是4096/4=1024。这个细节在官方文档里用小号字体写着，但新手很容易忽略，导致数组越界访问。

6. VSCode远程开发与调试：如何让编辑器真正理解ARM64交叉编译环境

6.1 Remote-SSH插件的深度配置：不只是连上，而是让IntelliSense精准索引

VSCode的Remote-SSH插件默认只做终端转发，对交叉编译项目毫无意义。要让它真正理解RDKX5的开发环境，必须做三件事：

第一，配置CMake Tools的交叉编译工具链
在项目根目录创建CMakePresets.json：

{ "version": 3, "configurePresets": [ { "name": "rdkx5-cross", "displayName": "RDKX5 Cross Compile", "binaryDir": "${sourceDir}/build", "cacheVariables": { "CMAKE_SYSTEM_NAME": "Linux", "CMAKE_SYSTEM_PROCESSOR": "aarch64", "CMAKE_C_COMPILER": "/opt/rdkx5-toolchain/bin/aarch64-linux-gnu-gcc", "CMAKE_CXX_COMPILER": "/opt/rdkx5-toolchain/bin/aarch64-linux-gnu-g++", "CMAKE_FIND_ROOT_PATH": ["/opt/rdkx5-toolchain/aarch64-linux-gnu/sysroot"], "CMAKE_FIND_ROOT_PATH_MODE_PROGRAM": "NEVER", "CMAKE_FIND_ROOT_PATH_MODE_LIBRARY": "ONLY", "CMAKE_FIND_ROOT_PATH_MODE_INCLUDE": "ONLY" } } ] }

这样CMake Tools就能自动识别交叉编译环境，生成正确的compile_commands.json。

第二，配置C/C++插件的IntelliSense
在.vscode/c_cpp_properties.json里：

{ "configurations": [ { "name": "RDKX5", "includePath": [ "${workspaceFolder}/**", "/opt/rdkx5-toolchain/aarch64-linux-gnu/sysroot/usr/include/**", "/opt/rdkx5-toolchain/aarch64-linux-gnu/sysroot/usr/include/c++/12.2.0/**" ], "defines": [], "compilerPath": "/opt/rdkx5-toolchain/bin/aarch64-linux-gnu-gcc", "cStandard": "c17", "cppStandard": "c++20", "intelliSenseMode": "linux-gcc-arm64" } ], "version": 4 }

关键是intelliSenseMode必须设为linux-gcc-arm64，否则IntelliSense会用x86_64的头文件做补全，导致#include <sys/mman.h>时找不到MAP_SYNC宏定义。

第三，配置调试器launch.json

{ "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch RDKX5", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/app", "miDebuggerPath": "/opt/rdkx5-toolchain/bin/aarch64-linux-gnu-gdb", "miDebuggerServerAddress": "192.168.1.101:2345", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false } ] }

这里miDebuggerServerAddress指向RDKX5的IP和gdbserver端口。你得先在RDKX5上运行：

gdbserver :2345 ./app

6.2 调试实战：如何在VSCode里单步调试NPU推理代码

NPU代码调试最难的是混合模式——CPU负责数据搬运，NPU负责计算，两者异步执行。我在VSCode里调试rknn_run()时，发现断点总是跳过，后来查gdb手册才知道：rknn_run()内部调用了ioctl()系统调用，而gdb默认不跟踪系统调用。

解决方案是在launch.json里添加setupCommands：

"setupCommands": [ { "description": "Catch all syscalls", "text": "catch syscall", "ignoreFailures": true }, { "description": "Ignore irrelevant syscalls", "text": "ignore syscall 3 4 5 6 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210