这块正点原子的RK3588开发板，我拿到手之后踩了不少坑，也把整个从零到能正常远程开发的环境完整跑通了一遍。这篇文章就把整个流程记录下来，从镜像烧写、Ubuntu系统扩容，到xrdp远程桌面部署，一条线走完。不管你是刚拿到板子的小白，还是已经在RK3588上折腾过一阵子的开发者，这篇内容应该都能给你省下不少时间。
先说下我手上的硬件环境：正点原子RK3588开发板，官方标配的电源适配器，一张TF卡（实际没用上，纯eMMC启动），一台Windows电脑用作烧写，还有一台Ubuntu主机用来做后续的SSH和远程桌面测试。整个流程的核心就三件事：把官方Ubuntu镜像写进eMMC、把rootfs分区扩容到整个存储空间、装好xrdp让Windows可以直接远程桌面连上去。下面一个一个来。
1. 烧写之前，先把手上的板子和工具理清楚
很多人拿到RK3588开发板之后，第一反应是找资料、下镜像，然后直接开烧。这个顺序没错，但有几个前置工作不做，后面大概率会卡住。我这里先把准备工作列清楚，省得你后面来回折腾。
1.1 开发板启动方式与存储介质
正点原子RK3588的板载存储通常是eMMC，官方也提供SD卡启动的途径，但我个人建议优先用eMMC。原因很简单：eMMC的读写速度和稳定性都比SD卡好，系统跑起来之后做开发编译、跑模型推理，体感差距非常明显。而且后续扩容、分区管理也都是在eMMC上做的，思路更统一。
板子上一般会有启动拨码开关，用来切换启动介质，比如eMMC启动、SD卡启动、SPI Flash启动。烧写之前一定要确认拨码拨到了正确的位置，不然你辛辛苦苦烧完eMMC，上电一看从SD卡启动了，或者干脆起不来，那种挫败感我懂。正点原子的手册里面对拨码有详细说明，不同批次板子位置可能略有差异，务必先看自己手上这块板子的原理图和用户手册。
1.2 烧写工具全家桶：驱动、工具、固件
烧写RK3588必备的三样东西：DriverAssistant驱动、RKDevTool烧写工具、官方Ubuntu镜像。这三样在正点原子资料包里面都有，但版本要对上。驱动是Windows下的，用来让板子在Loader模式下被电脑识别成ADB设备；RKDevTool是烧写主工具，负责加载固件、擦除和写入；镜像的话，正点原子提供的Ubuntu镜像通常是基于Rockchip官方SDK定制的，直接用官方分支也可以，但板级适配文件不一定完整，建议优先用板厂提供的。
我第一次烧写时用的驱动版本比较老，结果电脑死活识别不到设备，换了资料包里最新版驱动瞬间解决。这个问题后面在常见问题里再展开，这里先记住一个原则：驱动和工具能新版就新版，不要用网上随意下载的旧版本。
1.3 进入Loader模式的操作细节
要把系统烧进eMMC，板子必须进入Loader模式。正点原子RK3588的操作方法一般是：先按住板子上的BOOT键不松手，然后接上USB线（Type-C那头插板子，另一头插电脑），再上电，等电脑出现设备提示后松开BOOT键。
注意，这里的顺序很重要。如果你先上电再按BOOT键，多半进不了Loader模式。而且USB线最好用带数据功能的高质量线，有些线只能充电不能传数据，插上去设备管理器里根本不会有反应。我第一次就栽在劣质USB线上，换了根线立马识别。
如果顺利，Windows的设备管理器里会出现一个Rockusb设备，这就是Loader模式下的状态。如果没有，优先检查驱动是否装上、USB线是否支持数据、BOOT键时序是否正确。
2. 镜像烧写完整流程：从擦除到写入一次跑通
前面准备工作做好之后，烧写本身其实是一个很机械的过程。但里面有几个细节决定了你是“一把过”还是“反复折腾”，我拆开细说。
2.1 RKDevTool的烧写配置与分区映射
打开RKDevTool，如果设备连接正常，软件界面里会显示发现一个LOADER设备。这块板子的烧写配置一般上市前就已经弄好，但你要看懂分区映射，不然就是盲烧。
RK3588的固件分区一般包括：uboot、misc、boot、recovery、rootfs等。boot分区存放内核和设备树，rootfs分区存放Ubuntu根文件系统。RKDevTool工具界面右侧会列出每个分区的起始扇区、分区名和对应的镜像文件路径。正点原子提供的Ubuntu镜像包里面一般是一个完整的镜像文件，也可以用单独的各个分区镜像来烧写。
我个人习惯是先用工具自带的“按分区烧写”模式，把uboot、boot、rootfs这几个关键分区单独指定好，擦除后逐个写入。这样万一某个分区烧坏了，我可以只重烧单个分区，不用每次都全量擦写。全量烧写虽然简单，但如果后续调试中频繁改内核，每次都整盘写入太浪费时间。
2.2 擦除与写入的执行过程和耗时预期
在RKDevTool里点击“擦除Flash”会把eMMC清空，然后再点击“执行”开始烧写。eMMC的容量是64GB，整盘全量写入大概要几分钟，具体时间取决于镜像大小和USB传输速度。第一次烧写等了快十分钟，期间界面会显示进度条，拔线断电是绝对禁止的，不然eMMC可能直接变砖头，只能重新进Loader模式再救。
烧写完成后，点“复位设备”或者直接断电重新上电，系统就会从eMMC启动。串口调试的话，用USB转串口线接开发板的调试串口，波特率一般是1500000，也就是1.5M。接好之后上电，可以在串口工具里看到完整的Uboot启动日志和内核日志，这对排查启动问题非常有用。
2.3 烧写后首次启动的验证清单
系统起来之后，别急着做扩容，先用一串命令确认基础状态：
uname -a cat /etc/os-release df -h lsblk ifconfig看内核版本确认是否烧写成功，看/etc/os-release确认是哪个Ubuntu版本，看df -h确认rootfs当前挂载大小，看lsblk确认eMMC分区结构。还要确认网络是否正常，如果是DHCP自动获取IP，用ip addr查看地址；如果板子直连路由器，其实这一步可以不做，我们后面用xrdp看IP连就行。
通常正点原子固件默认的rootfs分区只占用了eMMC的一部分空间，剩余的空间处于未分配状态，这就是我们下一步要扩容的原因。
3. Ubuntu系统扩容：把未分配空间变成可用分区
为什么官方镜像的rootfs分区不直接把整个eMMC都用上？这个问题我也纠结过。后来看了一些文档和SDK脚本，原因大概是固件打包时有默认分区表约束，镜像需要保持一个固定的最小体积，方便不同存储容量的板卡共用。比如同一套系统可以烧进64GB和128GB的eMMC，反正剩下的空间用户自己扩。
所以“扩容”的本质，是把根文件系统分区扩大到eMMC的全部剩余空间。
3.1 先用lsblk和df摸清分区现状
连上SSH或者在串口里操作，先看分区现状：
lsblk输出大致是：
mmcblk0 179:0 0 59.5G 0 disk ├─mmcblk0p1 179:1 0 100M 0 part /boot ├─mmcblk0p2 179:2 0 8.24G 0 part / └─mmcblk0p3 179:3 0 300M 0 part /var/log这里mmcblk0就是eMMC，p2是rootfs，只有8.24G，实际eMMC有59.5G，剩下的空间都在分区表里是空闲状态。df -h看到的根文件系统容量也跟这个一致。
3.2 用fdisk调整分区表
扩容步骤的核心是用fdisk删除rootfs分区再重建为一个包含所有剩余空间的分区，但分区起始扇区必须跟原来一模一样，否则文件系统直接损坏。操作前务必备份重要数据，这句话我说三遍都不嫌多。
具体操作：
sudo fdisk /dev/mmcblk0进入fdisk交互界面后，输入p打印分区表，记下/dev/mmcblk0p2的起始扇区号。然后输入d，再输入2，删除第二个分区。接着输入n新建分区，分区号仍选2，起始扇区必须填刚才记录的值，结束扇区直接回车用默认值（表示使用全部剩余空间）。最后输入w写入分区表。
写入之后重启板子，让内核重新读取分区表：
sudo reboot这里有个重点：如果你在系统运行时直接删分区再重建，内核可能还持有旧分区表，操作完最好立即重启，不要继续挂载。
3.3 resize2fs扩展文件系统到整个分区
重启之后，分区已经变大了，但文件系统还是原来的大小，这时要用resize2fs扩展它：
sudo resize2fs /dev/mmcblk0p2执行过程中会输出文件系统扩展的详细信息。完成后用df -h再看，根文件系统容量应该已经变成可用空间总量了：
/dev/mmcblk0p2 58.6G 5.1G 50.5G 10% /注意，有些教程会提到用growpart或者parted来扩容，这个也完全可以，但fdisk本身就能搞定，没必要额外装工具。另外有资料说用resize_rootfs.sh脚本，正点原子的镜像里可能预置了这个脚本，但如果你的镜像没有，就按我上面这个手动流程走。
3.4 扩容过程中踩过的两个坑
第一个坑是扩容之后系统卡在启动阶段。这个多半是分区表写入出了问题，起始扇区跟原分区不一致，导致内核挂载rootfs失败。解决办法是重新烧写镜像再来一次，所以我前面才强调先备份。
第二个坑是resize2fs报错说文件系统有错误。这种情况先用e2fsck -f /dev/mmcblk0p2检查修复文件系统，再执行resize。千万别跳过检查直接扩，不然数据丢了哭都来不及。
扩容之后还有个细节：/var/log如果也在独立分区，空间一般够用就不动它，如果太小可以参照同样的方法处理，但优先级不高。
4. xrdp远程桌面部署：让Windows直接连板子桌面
系统扩容做完之后，板子已经是一台配置不错的Linux主机了。但实际开发中，板子往往放在实验室角落，没有独立显示器，或者你人不在板子旁边，这时候就需要远程桌面。VNC是一个方案，但xrdp方案的好处在于Windows自带“远程桌面连接”工具就能直连，不需要再装VNC客户端。
4.1 为什么选xrdp而不是VNC
VNC的常见组合是vnc4server + vncviewer，配置相对繁琐，而且默认安全性一般，通信用的是RFB协议；xrdp实现的是RDP协议，与Windows远程桌面原生兼容。对RK3588这种开发板来说，xrdp还有一个优势：可以直接连接桌面环境，不需要额外起一个X Server实例，资源占用更小。在Linux桌面远程方案里，xrdp + Xorg是当前最主流的组合。
4.2 安装xrdp与xorgxrdp
正点原子Ubuntu镜像默认的软件源可能指向官方源，国内直连速度不一定快，建议先换成国内源。这里以Ubuntu 22.04为例：
sudo apt update sudo apt install xrdp装完xrdp之后最好再装一下xorgxrdp，这是xrdp与Xorg之间的桥梁，没有它，连接时可能只有灰色桌面或者黑屏：
sudo apt install xorgxrdp装完启动服务：
sudo systemctl enable xrdp sudo systemctl restart xrdp确认服务在跑：
sudo systemctl status xrdp看到active (running)就OK了。
4.3 配置Xorg会话与桌面环境
这里有个关键选择：连接进来之后启动哪个桌面环境。正点原子Ubuntu镜像默认可能带的是LXDE或者XFCE这类轻量桌面，但也有可能带的是GNOME。xrdp对GNOME的支持不算好，容易黑屏，XFCE是最稳的。
如果你不确定板子上装的是什么桌面，可以用这个命令查一下：
ls /usr/share/xsessions/如果里面只有一个ubuntu.desktop，那大概率是GNOME。为了少踩坑，建议直接装一个XFCE桌面，xrdp连接时就能选XFCE会话：
sudo apt install xfce4 xfce4-terminal然后在/etc/xrdp/startwm.sh里确认默认启动器是xfce4-session，如果是其他内容，改成这样：
#!/bin/sh if [ -r /etc/profile ]; then . /etc/profile fi export DESKTOP_SESSION=xfce export GDK_BACKEND=x11 startxfce4改完重启xrdp：
sudo systemctl restart xrdp4.4 Windows远程桌面连接实测
在Windows上按Win+R，输入mstsc，回车，在计算机栏填板子的IP地址，用户名填板子上的账号，比如ubuntu或者你自己创建的账号，密码对应登录密码，点击连接。第一次连接会提示证书不匹配，直接点是继续就行。
连接成功后，你会看到XFCE桌面出现在窗口里，操作流畅度取决于网络环境，总体使用是没问题的。这个环节我实测下来，局域网里延迟很低，基本接近本地操作体验。
需要注意几点：
- 板子IP要固定，建议在路由器上做DHCP静态绑定，或者在
/etc/netplan里配置静态IP，不然每次重启IP都变，远程连接体验很糟糕。 - 用非root用户连接。xrdp默认不允许直接用root登录，即使你改了
/etc/xrdp/xrdp.ini里的allow_root，也不建议这么做，安全风险太大。 polkit权限问题可能导致无法正常连接，如果连接时卡在登录界面，检查一下/etc/polkit-1/localauthority/50-local.d/下是否有对应的权限策略，后续会细说。
4.5 xrdp黑屏与登录失败排查
xrdp最让人烦躁的问题就是黑屏。这个问题我在好几台板子上都遇到过，原因五花八门。最常见的一个是用户家目录下的.Xauthority文件权限错乱，解决办法是删除它让系统重新生成：
rm ~/.Xauthority sudo systemctl restart xrdp还有一个是高版本Ubuntu里gdm和xrdp抢占会话的问题。解决办法是把显示管理器从gdm3切换为lightdm：
sudo apt install lightdm sudo dpkg-reconfigure lightdm或者手动设置默认管理器，然后重启。这个操作之后xrdp黑屏的概率会大大降低。
再有一个是连接后一直停留在蓝色或灰色界面，没有进入桌面。这种情况多半是startwm.sh里的会话启动方式不对，或者XFCE没装好。重新确认一下xfce4-session能不能在本地正常启动，如果本地都起不来，远程肯定不行。
如果遇到“连接被拒绝”，先检查xrdp服务状态和端口监听：
sudo netstat -tlnp | grep 3389没有监听的话先启动服务，再查防火墙。开发板场景下防火墙一般没开，但某些定制镜像里可能默认开了ufw，用sudo ufw disable或者放行3389端口。
4.6 关于xwayland与xrdp的几个补充
现在RK3588官方镜像跑Ubuntu时，默认会话越来越倾向于Wayland，xrdp兼容X11的Xorg会话反而更稳。如果你的板子上startwm.sh里启动的是Wayland相关的脚本，远程连接可能只看到一个光标或者完全黑屏。解决办法就是在startwm.sh里显式强制走X11/Xorg会话，也就是指定startxfce4。
另外一个点是xwayland xrdp这个组合，简单说一下：Wayland本身不直接支持RDP，Xwayland作为兼容层可以让X11程序跑在Wayland上，但xrdp目前对这套组合的支持仍然不够完善。所以对于RK3588开发板，我的建议是别折腾Wayland，老老实实用Xorg + XFCE + xrdp，稳定性会好很多。
5. 常见问题排查与使用体验补充
前面写了很多流水账式的操作，这里我把实操中遇到的问题集中整理成一份排查清单，方便你遇到问题的时候对照着处理。
5.1 镜像烧写相关问题速查
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 设备管理器看不到Rockusb设备 | 驱动未装好、USB线不支持数据、BOOT键时序不对 | 重装DriverAssistant驱动；换数据线；按BOOT键后上电再松手 |
| 烧写中途进度条卡死 | USB线接触不良、供电不足 | 换线、换USB口；确保电源适配器直接供电 |
| 烧写完上电黑屏无日志 | 启动介质拨码不对、uboot损坏 | 检查拨码；重新烧写uboot分区 |
| 擦除Flash报错 | eMMC被锁定或驱动异常 | 重装驱动、换接口重试；必要时用SD卡启动系统后重新烧写 |
5.2 扩容和文件系统相关问题速查
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| resize2fs报错要求先运行e2fsck | 文件系统存在错误 | 先执行sudo e2fsck -f /dev/mmcblk0p2再重试 |
| 扩容后无法启动 | 分区起始扇区不一致 | 重新烧写镜像，按正确起始扇区操作 |
| df显示容量没变大 | 分区改了但文件系统没扩展 | 确认resize2fs是否成功，必要时重启后再执行 |
| 只读文件系统错误 | 文件系统损坏或异常断电 | e2fsck修复，严重时重新烧写 |
5.3 xrdp问题速查
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 连接后黑屏 | Xauthority问题、gdm冲突、Wayland会话 | 删除.Xauthority；切换lightdm；强制Xorg会话 |
| 连接被拒绝 | 服务未启动、端口未监听 | 启动xrdp；放行3389端口 |
| 登录失败 | 密码错误、PAM配置异常 | 重置密码；查看/var/log/xrdp.log |
| 桌面极卡顿 | 网络延迟高、桌面环境太重 | 换轻量桌面；走千兆局域网 |
xrdp日志也是一个很重要的排查入口，/var/log/xrdp.log和/var/log/xrdp-sesman.log通常会给出更多细节。我每次排查xrdp问题都会先看这两个日志，比瞎猜高效得多。
5.4 正点原子资料包和社区资源的利用
买正点原子的板子，最大的好处是资料相对全。资料包里的用户手册、原理图、Linux开发指南、SDK源码，都是宝贵的一手资料。我建议这几个文件一定要过一遍：用户手册里关于启动模式和烧写的部分，Linux开发指南里关于Ubuntu系统定制和Rootfs制作的部分。看不懂没关系，先大概翻一遍，等自己遇到问题的时候就有印象哪里能查。
社区方面，rockchip-linux的GitHub仓库和eLinux wiki的RK3588页面也有不少补充资料。用搜索引擎搜具体问题时，加上“RK3588”和报错关键词通常能找到别人分享的解决方案。
5.5 一些额外的RK3588开发板使用心得
系统正常跑起来、远程桌面也能连上之后，你会发现RK3588这块板子的可玩性比想象中高很多。它自带NPU，很多人在上面部署YOLOv8模型做目标检测，正点原子也给了相关例程。我最近就在折腾这块，后面可能会单独写一篇NPU推理流程的文章。
调试过程中，adb也是一个很有用的工具，尤其当系统网络配置有问题、SSH连不上的时候，在电脑上用adb shell进去操作，能救不少急。具体来说，连接板子的Type-C调试口，电脑上执行adb devices如果能识别到设备，就可以直接用adb shell拿到一个Linux终端，这对排查网络和环境问题非常方便。
USB摄像头的使用也是一个热点方向，RK3588的ISP和V4L2框架对USB摄像头支持很友好，如果想做视频流推RTSP的话，Rockchip的MPP和RGA库也能帮忙做硬件编解码和图像处理。这些都属于装好系统之后的进阶玩法，我准备在后续的文章里慢慢展开。
如果下一步有系统备份的需求，比如把装好的环境克隆到另一块板子上，可以参考RK3588的整盘备份思路，用dd或者Rockchip提供的备份工具，把eMMC做一个镜像，以后随时恢复。这块内容如果再写又是一大篇，先在这里挖个坑。
6. 写在最后的几点实用建议
整个流程走完之后，我对这套RK3588开发环境有几个很直观的感受。
第一，xrdp远程桌面加上SSH，基本可以做到完全“无头”使用板子。把板子放在角落，插上网线和电源，所有日常操作我都在自己的电脑上完成，这个体验真的非常舒服。开发板不像服务器，大多数时候需要桌面来跑图形程序或者看可视化结果，xrdp把这块短板补齐了。
第二，扩容这件事不要拖。系统用久了，编译产生的临时文件、模型文件、日志，很容易把几个G的空间占满，早扩容早安心。而且扩容操作本身并不复杂，按照上面的步骤，十分钟之内就能搞定。
第三，资料包要好好利用，但也不要迷信资料包。正点原子的Ubuntu镜像有时候并不是最新的Ubuntu版本，如果你有特定的软件依赖版本要求，可能需要自己基于Rockchip SDK重新定制根文件系统，这个属于更进阶的方向，但思路其实跟我上面扩容的流程是相通的——理解了分区结构，你就能自由定制系统。
这套环境搭好之后，后面所有RK3588相关的开发工作都会顺畅很多。我规划里还有NPU推理、RTSP推流、ES8388音频调试这些主题等着一一实践，有机会再写出来和大家继续聊。
