开头手里这块全志F133-A开发板到手之后我干的第一件事不是点灯不是跑裸机demo而是先把ADB调通。原因很简单全志F133-A这颗芯片虽然定位入门级RISC-V应用处理器但真正用起来之后你会发现串口终端看日志、敲命令是够用的可一旦涉及文件传输、截图、装包、批量调试串口的效率低到让人抓狂。ADBAndroid Debug Bridge这套工具链恰恰能把“终端控制、文件传输、日志抓取”三件事统一到一个命令行入口调试体验完全不一样。这篇内容我会从硬件配置讲起覆盖主机端工具准备、板端ADB服务确认、常用命令实战、文件传输对比最后把我在实际调试中踩过的一些坑整理成排查清单。目标只有一个你照着操作手里这块F133-A就能稳定连上ADB然后把文件和命令顺畅地跑起来。适合刚接触全志F133-A、T113这类RISC-V开发板或者想把Linux开发板调试效率提上来的朋友参考。1. 整体设计思路为什么F133-A调试首选ADB1.1 F133-A的开发调试痛点全志F133-A属于全志RISC-V产品线里比较有代表性的一款单核C906主频最高到1GHz内置64MB DDR3跑Tina Linux或者buildroot系统都很常见。刚拿到板子的人通常会先接串口因为串口是最基础的调试手段能看到内核日志、能进shell、能跑命令。但串口的瓶颈特别明显带宽撑死也就115200bps传一个几MB的文件要等半天想从板子上拉一张截图或者一份日志文件靠串口基本不现实。而如果用网络方式比如SSH或者scp又得先保证板子和电脑在同一网段配置IP、启用SSH服务、处理证书前期准备工作就够折腾一阵。ADB恰恰把这些问题一次性解决掉了。它走的是USB通道物理上就一根线不用额外接网线也不用配IP。传输速度快终端交互流畅而且所有操作都在主机端完成你想从板子拉文件、往板子推文件、执行高权限命令、抓logcat日志全部可以在同一条命令行工作流里完成。对开发调试这个场景来说ADB是配置成本最低、上手最快的综合方案。1.2 ADB在RISC-V Linux板卡上的工作方式有些朋友对ADB有误解觉得它是安卓专属工具Linux板卡上不一定能用。其实ADB由三部分组成主机端的adb客户端、主机端的adbserver以及板端的adbd守护进程。adbd本身就是一个Linux用户态程序只要板子系统能编译出对应架构的adbd并把它跑起来整个ADB链路就能工作。全志F133-A跑Linux系统时芯片原厂SDK里通常都已经预置了adbd的配置和启动脚本默认出厂固件很多甚至已经自动启用了ADB。从USB硬件层面来看F133-A的USB controller要运行在device/gadget模式下也就是让开发板模拟成一个USB设备主机把它识别成ADB Interface。这一过程涉及内核里的USB Gadget驱动常见的有ConfigFS或者老的g_android方案。只要内核配置正确系统启动时就会生成对应的USB功能节点adbd监听之后主机端才能看到设备。换句话说排查ADB能不能用本质上是排查三件事内核有没有把USB gadget功能打开adbd进程有没有跑起来主机端驱动和工具链正不正常。我后面的大多数排查步骤都是围绕这三件事展开的。1.3 适用场景和选型建议如果你手里是F133-A、T113、D1s这类的全志RISC-V开发板跑的是Tina Linux、buildroot或者Debian用户态那ADB调试特别适合以下几类使用场景内核驱动开发过程中需要频繁查看dmesg和内核日志应用开发时需要往板子推送可执行文件、动态库和配置文件UI调试时需要截图并保存到电脑跑QT或者LVGL应用时需要快速抓logcat其实是stdout输出来定位崩溃问题。反过来如果你的任务只是单纯读串口内核日志那就不需要费劲调ADB老老实实接串口更好。但如果涉及文件交互ADB是值得优先投入时间的工具。2. 硬件配置与板端环境准备2.1 开发板侧需要检查的硬件条件拿到F133-A开发板硬件上先确认几件事USB口是否支持device模式。这个特别关键很多开发板会同时引出USB Host和USB Device两个口样子长得很像但功能完全不一样。ADB必须接在USB Device口上有些板子标识为OTG口。接错口的表现是主机毫无反应或者识别成未知设备因为Host口本来就不是给ADB用的。供电是否稳定。F133-A开发板如果通过USB Device口同时供电和通信电源质量差会导致枚举不稳定经常出现设备一半就掉线的情况。建议用独立电源给板子上电USB线只负责数据通信。USB线是否支持数据传输。听起来很基础但我就遇到过好几次——手边随便抓了一根只能充电不能传数据的线插上去死活认不到设备换了根正常线立刻就好了。判断方法很简单拿这根线连接手机和电脑看电脑能不能识别到手机设备。跳线或拨码开关。部分F133-A开发板为了兼容不同启动模式和USB功能会有拨码开关或者跳线帽需要把USB模式设置到device/otg档位。硬件上就这些不需要额外买调试器一个五块钱的USB转Type-C或者Micro USB线就够了这点比JTAG调试要便宜得多。2.2 内核和系统侧确认ADB支持硬件线接好后先别急着插电脑先把开发板系统跑起来进串口终端确认板端环境。用串口登录后依次执行以下检查。检查adbd进程有没有跑ps -ef | grep adbd正常情况下能看到adbd进程。如果看不到尝试手动启动adbd 或者查看系统的init脚本全志Tina Linux通常会在/etc/init.d/下放一个adbd脚本ls /etc/init.d/ | grep adb /etc/init.d/adbd start如果手动启动报错大概率是功能目录没有生成检查内核的USB gadget是否正常ls /sys/kernel/config/usb_gadget/ ls /dev/usb-ffs/adb/如果这两个目录都不存在说明内核没有使能adbd所需的gadget功能需要检查内核配置项。F133-A对应的内核配置里重点关注CONFIG_USB_CONFIGFS、CONFIG_USB_F_FS、CONFIG_USB_CONFIGFS_F_ADB有的内核叫CONFIG_USB_CONFIGFS_F_ACM或F_FS编译内核时要把这些选项选上。顺带说一个判断技巧如果系统里能看到/dev/android0或者/dev/usb-ffs/adb/ep0基本说明gadget功能已经拉起来了问题多半出在adbd进程或者USB线连接上。2.3 Tina Linux中ADB的默认配置说明全志Tina Linux默认对ADB的支持做得比较完善。许多官方固件里面adbd已经是开机自启服务root权限也是默认开放的。也就是说你打开串口不输入账号密码就能直接拿到root shell这其实是allwinner系列开发板对比某些商业板卡的优势之一不用折腾提权的事情对调试来说省掉了很多麻烦。Tina Linux的ADB配置和相关脚本通常分散在几个位置/etc/init.d/adbd是启动脚本 /system/bin/adbd或/usr/bin/adbd是二进制路径取决于固件 /etc/adb或/build目录下可能有usb gadget的配置描述。如果你用的不是Tina而是自己buildroot构建的系统那需要确认rootfs里有没有包含adbd软件包没有的话编译时选上或者在buildroot的package菜单里使能adb相关选项。我的经验是用官方SDK默认配置来折腾ADB比完全手搓要省心得多。原厂已经把functionfs的挂载、adbd的启动参数、USB描述符这些都调好了你要做的只是确认它们在你当前的固件版本里没有被裁剪掉。3. 主机端工具链准备与连接验证3.1 Windows环境下的ADB工具安装与驱动配置主机端我主要用Windows和Ubuntu两个环境先说Windows。ADB工具官方提供platform-tools压缩包解压后就是一个文件夹包含adb.exe、AdbWinApi.dll、AdbWinUsbApi.dll等文件。不建议用乱七八糟的“一键安装版”直接下载官方platform-tools最干净。下载后把路径配置到系统PATH环境变量里这样以后在任何目录都能直接敲adb命令省去来回切换路径的麻烦。Windows下最容易出问题的是驱动。F133-A连接电脑后设备管理器里如果出现带黄色感叹号的“Android”或“ADB Interface”设备就要手动安装驱动。全志的板子在Windows下有时被识别成“USB 输入设备”或者“未知USB设备”这种情况可以尝试更新驱动在设备管理器里选择“从计算机的驱动程序列表中选择”然后选择“USB 设备”类里的ADB Interface或者使用通用WinUSB驱动。驱动装好之后设备管理器里会出现“Android Composite ADB Interface”之类的条目这时再敲adb devices就能看到设备了。注意Windows下如果始终提示“驱动未安装成功”先把USB线拔掉重插然后在设备管理器里“扫描检测硬件改动”。如果设备还是不明不白试试换一个USB口最好插主机背面的USB口前面板或者HUB容易供电不足。3.2 Ubuntu环境下的ADB工具安装与权限处理Ubuntu下装ADB就一条命令sudo apt install adb装完先启动serveradb start-server然后接上开发板运行adb devices如果输出列表是空的先排除USB线的问题再检查权限。Linux下访问USB设备需要权限常见表现是设备已经有ec50端口但adb devices里看不到。处理方式是把当前用户加入plugdev组然后写udev规则sudo usermod -aG plugdev $USER echo SUBSYSTEMusb, ATTR{idVendor}1f3a, MODE0666 | sudo tee /etc/udev/rules.d/51-adb.rules sudo udevadm control --reload-rules sudo udevadm trigger全志的USB Vendor ID通常是1f3a但不同板子可能不一样可以通过lsusb命令查看。重新插拔USB线之后adb devices就应该能看到设备了。需要说明的是Ubuntu下即使没有上述udev规则多数情况下root用户也能直接操作adb但开发调试一般不会用root登录桌面环境所以配置好用户权限规则是一劳永逸的事情。3.3 设备连接状态确认与常见状态解读连接成功后adb devices的输出是device正常连接可以操作。unauthorized设备弹出授权确认框你要在开发板的屏幕上点“允许USB调试”没有屏幕的板子可能需要通过串口执行adb keys确认或者板端root权限下直接关闭鉴权。offline状态异常通常是adbd版本与主机端不兼容或者USB连接不稳定。no permissionsUbuntu下典型权限问题按前面udev规则处理。device unauthorized之后又消失常见于连接了多个设备或者主机端adb server缓存了旧的设备密钥。F133-A这类开发板有一个便利点adbd默认以root权限运行而Tina Linux默认把鉴权也关掉了所以一般不出现unauthorized提示。如果遇到unauthorized且板子上没有屏幕可以尝试板端串口执行rm /data/misc/adb/adb_keys adb kill-server adb devices如果adbd支持root模式下不需要鉴权可以直接把ro.adb.secure属性设为0来绕过setprop ro.adb.secure 0 adb kill-server4. 核心实操ADB常用命令逐条跑通4.1 进入设备终端adb shell与常见参数ADB最核心的操作之一是adb shell它让你在电脑的命令行里直接操作开发板的Linux shell。使用方法adb shell直接回车会进入一个交互式shell可以敲任意Linux命令。退出时输入exit。也可以不进入交互式直接加一条命令在后面执行比如adb shell cat /proc/cpuinfo adb shell uname -a adb shell ls /etc/init.d/这种一次性执行在脚本化操作时非常方便。我经常写一批命令循环执行比如批量查看多个节点的状态for cmd in cat /proc/meminfo free -h cat /sys/power/state; do adb shell $cmd; done另外提一个实用的参数adb shell后面加su在一些非root系统里可以切换root用户全志Tina默认root不用带su。F133-A跑Tina Linux时板端shell也是busybox或者Toybox环境绝大多数Linux命令都能用。如果你发现自己常用的某个命令在板端不存在别慌先adb shell进去看看/bin和/usr/bin下都装了哪些工具很多精简版rootfs只裁剪了部分命令。4.2 文件传输adb push与adb pull文件传输是ADB调试里用得最多的功能之一这里单独展开讲一下。从电脑推文件到开发板adb push ./test_app /root/ adb push ./config.ini /etc/从开发板拉文件到电脑adb pull /root/log.txt ./ adb pull /data/dump.bin ./push和pull的本质是走USB的file transfer通道速度比串口快几个量级实际体验通常在几MB/s到几十MB/s之间具体取决于内核USB驱动实现和主机端USB控制器。实测下来F133-A的ADB文件传输速度大概在5MB/s到15MB/s这个范围传输几十MB的固件或者可执行文件毫无压力。有几点要提醒目标目录要有写权限。板端如果不是root用户push到/system等只读目录会失败先adb root或者chmod目标路径。pull时如果文件较大可以包成压缩包再拉效率更高adb shell tar czf /tmp/logs.tar.gz /var/log/ adb pull /tmp/logs.tar.gz ./文件路径里不要有中文和空格adbd处理特殊字符容易出幺蛾子。我自己的习惯是把需要反复传输的目录固定成一个约定路径比如/opt/target编译完直接adb push过去配合脚本完成“编译-推送-运行-拉日志”的闭环操作效率提升非常明显。4.3 截图与录屏保存到电脑ADB调试带屏幕的应用时截图是最直观的验证手段。有两种常用方法。方法一板端截图然后拉回电脑。adb shell screencap -p /tmp/screen.png adb pull /tmp/screen.png ./方法二直接用exec-out输出到主机重定向。adb exec-out screencap -p screen.png方法二更推荐少一次板端临时存储操作速度更快。F133-A这类跑Linux系统的板卡如果带framebuffer屏screencap工具通常从fb设备里抓当前画面。如果板子启动的是QT应用画面渲染在framebuffer上截图内容是能看到的。LVGL应用同理。录屏可以用screenrecord工具adb shell screenrecord /tmp/demo.mp4 adb pull /tmp/demo.mp4 ./注意screenrecord一般支持H.264编码码率和时长参数可以在命令里指定比如--bit-rate4M --time-limit10。4.4 日志抓取使用logcat和其他日志定位手段跑Linux系统的F133-A最常用的日志定位手段其实是板端的dmesg、syslog和应用的stdout输出。但如果你在板子上跑了一个类安卓的运行时或者系统里集成了logcat服务那adb logcat就是抓日志利器。用法adb logcat -v time adb logcat -c adb logcat *:E-v time会带上时间戳看时序问题特别有用-c清掉之前的缓冲*:E只显示错误级别以上的日志过滤噪音。对于纯Linux环境我的习惯是combined起来用adb shell dmesg dmesg.txt adb shell cat /var/log/messages messages.txt然后直接在电脑端搜索关键字比如grep -i error dmesg.txt grep -i usb messages.txt这个工作流比曾经在串口终端里翻屏找日志要舒服太多了。串口日志的缓冲有限跑一遍长时间压力测试后刷屏刷得根本看不清但ADB可以把日志原原本本落盘到电脑上方便后续分析。4.5 权限切换与系统属性操作F133-A跑Tina Linux默认adb登录用户就是root但也有些固件改成了普通用户。如果不是root需要先提权adb root执行后adbd会以root权限重启随后重新连接adb wait-for-device adb shell id输出uid0(root)就代表成功了。查看和设置系统属性adb shell getprop adb shell setprop debug.test 1getprop在Tina Linux里大多是开机时从环境变量或者配置脚本导入的对调试系统行为很有用。比如网络配置、串口波特率选择、显示分辨率这些都可能挂在系统属性上。如果是类安卓系统锁屏操作可以用adb shell locksettings set-disabled true这条命令在部分全志开发板预装安卓或类安卓系统时很实用能直接跳过锁屏验证方便做自动化测试。不过F133-A的内存只有64MB跑完整安卓比较吃力这类操作更常见于A系列或者H系列芯片平台上。4.6 无线ADB调试的补充用法USB线插着调试当然最稳但偶尔会遇到板子已经固定安装到设备内部、不方便再拉USB线出来的情况这时可以用无线ADB。前提是板子和电脑在同一个局域网先后台起一个ADB服务adb tcpip 5555然后通过IP连接adb connect 192.168.1.123:5555连上之后就和USB模式一样操作了push、pull、shell都正常。缺点是速度受网络环境影响另外板端如果重启了tcpip模式可能会失效需要重新配置。实际项目中我习惯把板端开机脚本里加上adbd tcpip的启动逻辑这样板子一上电就能通过网络调试也算是个小技巧。4.7 安装与卸载APK适配类安卓系统场景虽然F133-A裸机跑Linux居多但如果你拿到的是预装安卓精简系统或者Android容器方案的固件那安装APK就是家常便饭。ADB的install/uninstall命令通用adb install app.apk adb install -r app.apk adb uninstall com.example.app-r参数表示覆盖安装保留数据。批量安装时写个循环for apk in *.apk; do adb install $apk; done安装失败时先看具体报错INSTALL_FAILED_UPDATE_INCOMPATIBLE多半是签名不一致需要先卸载旧包INSTALL_FAILED_OLDER_SDK说明APK要求的系统版本过高INSTALL_FAILED_INSUFFICIENT_STORAGE则是存储空间不足F133-A内部存储不大出现这个报错很常见清理一下板端空间再试。5. 进阶实战从开发板到电脑的完整调试闭环5.1 一个典型调试场景的完整流程演示说得再好不如实际操作一遍这里用一个完整场景串起来写了一个小应用想在F133-A板子上跑起来验证功能然后抓到运行日志和截图。整体流程是这样的第一步把交叉编译好的可执行文件推到板子adb push my_app /root/ adb shell chmod x /root/my_app第二步运行应用并让日志输出到文件adb shell nohup /root/my_app /tmp/app.log 21 第三步等几秒后抓取运行状态和日志adb shell ps -ef | grep my_app adb pull /tmp/app.log ./第四步如果应用有图形输出截图拉回电脑adb exec-out screencap -p screen.png第五步检查完代码后改配置再推送一次adb push new_config.ini /etc/ adb shell killall my_app adb shell nohup /root/my_app /tmp/app.log 21 这个流程的体验非常顺滑全程不需要从座椅上站起来去接串口线也不需要反复拔插SD卡有ADB这个通道一切操作都在命令行里完成。5.2 与scp/串口/NFS方式的对比分析很多人会把ADB和scp放一块比较这里分享我的实际感受。scp文件传输命令的优点是通用性强几乎所有Linux板子都支持。但用它需要先解决网络问题要么板子插网线要么配WiFi要么用USB网卡每一步都可能遇到驱动或者网段问题。ADB只需要一根USB线即插即用。传输效率上USB 2.0的ADB和百兆网口的scp差距不算大但ADB的延迟更低交互响应更灵敏尤其频繁敲shell命令的场景体验差距明显。再对比串口串口胜在实现简单任何板子都能用早期调试离不开。但串口只有数据通道没有文件系统级别的交互能力拉文件要经过rz/sz这类协议慢且容易失败。我通常把串口当作“系统起不来的最后一道保底手段”系统能正常启动后就切换到ADB效率翻倍。NFS挂载在开发调试时很方便板子直接挂载主机目录当作本地文件系统运行代码不用拷贝。但它对网络环境要求高掉线的话整个系统工程都卡住适合调试过程中频繁改代码的场景ADB更适合调试目标明确、需要独立部署到板端运行的情况。综合来看ADB在“单机调试、直接交互、快速验证”这三件事上是综合体验最好的这也是为什么我强烈建议F133-A开发者把ADB用起来的原因。5.3 调试脚本封装与自动化思路使用多了以后命令越来越长每次都要敲好几条所以我自己写了一些脚本把常用操作封装起来这里分享一个简单模板。#!/bin/bash # 作用构建并推送应用到开发板 APP_NAMEmy_app HOST_DIR./build echo 编译 make if [ $? -ne 0 ]; then echo 编译失败 exit 1 fi echo 推送 adb push $HOST_DIR/$APP_NAME /root/ adb shell chmod x /root/$APP_NAME echo 运行 adb shell pkill -f $APP_NAME; /root/$APP_NAME echo 等待3秒后拉取日志 sleep 3 adb pull /tmp/app.log ./把这类脚本放在项目目录下以后每次调试一条命令搞定特别适合“编译后反复部署验证”的迭代循环。更偏向自动化的朋友还可以在此基础上加上incr、加入Rt-Thread烧录等流程不过那就超出ADB的范畴了。6. 常见问题与排查技巧实录6.1 adb devices识别不到设备的排查路径这应该是绝大多数人遇到的第一个拦路虎。按照我的经验按下面的顺序查通常几分钟就能定位问题换USB线。先排除“只能充电的线”这种低级但常见的坑。确认插的是USB Device/OTG口不是Host口。这个F133-A的板卡上常遇到因为两个口相邻很容易插错。看开发板端的adbd进程是否存活。串口里执行ps -ef | grep adbd如果进程不在手动启动或看启动脚本报错。看内核有没有usb gadget节点。查/sys/kernel/config/usb_gadget和/dev/usb-ffs/adb目录。主机端杀掉adb server重启adb kill-server adb start-server adb devicesWindows下检查设备管理器驱动状态Ubuntu下检查usb权限和lsusb能否看到设备。这一套下来95%的问题都能解决。剩下的5%多半是USB物理链路接触不良换根线换个口再试。6.2 unauthorized和offline状态的处理unauthorized的核心原因是主机端和板端的ADB密钥没有配对。开发板有屏幕时屏幕上弹窗点“允许调试”就完了没有屏幕的全志板卡可以尝试adb shell echo 0 /data/misc/adb/adb_enable adb shell setprop ro.adb.secure 0 adb kill-server adb devices如果固件的adbd完全忽略鉴权设置ro.adb.secure为0后重启adbd即可绕过授权。这个方法在多数全志原厂固件上都能奏效因为原厂SDK默认就不开启strict鉴权。offline状态就复杂一点。一般先看adbd是否频繁重启如果是可能是usb-ffs端点读写异常重新插拔USB线或重启板子。也可以检查主机端adb version和板端adbd版本差异过大老版本adbd连接新版adb工具偶发offline。6.3 push/pull失败与权限相关问题push文件时报“Permission denied”是最常见的原因基本是目标目录对当前用户不可写。解决方式adb root adb remount # 如果支持remount adb push file /system/板端如果是Tina Linux的只读rootfs先把目录挂载为可写adb shell mount -o remount,rw /大数据量pull时如果中途断掉建议在板端先压缩再拉取。有一个比较隐蔽的问题文件名包含特殊字符比如#、、空格adbd会解析错误最好的办法是改名之后再传输。6.4 开发板挂载Ubuntu目录与ADB的组合使用“开发板挂载ubuntu”这个词不少人在搜其实就是NFS或者sshfs挂载。调试大型工程时我常把Ubuntu主机的一个目录通过NFS挂到F133-A上这样板子能直接运行主机上的最新编译产物省去每次adb push的等待。NFS挂载和ADB搭配使用效果更好NFS负责“大文件、频繁更新的代码目录”ADB负责“快速命令、日志、截图等小交互”。挂载命令大概这样adb shell mkdir -p /mnt/nfs adb shell mount -t nfs -o nolock 192.168.1.100:/home/user/share /mnt/nfs前提是板子内核开启了NFS client支持F133-A的官方内核一般有。挂载后直接adb shell /mnt/nfs/my_app就能运行主机最新的编译产物非常适合做应用迭代调试。6.5 问题排查速查表现象可能原因处理方式adb devices空列表USB线不支持数据传输换线换口确认Device口设备显示offlineadbd版本不兼容或连接不稳定重启adbd重插USB检查供电设备显示unauthorized鉴权未通过屏幕点允许或设置ro.adb.secure 0no permissionsUbuntu下设备权限不足配置udev规则用户加入plugdev组push报Permission denied目标目录不可写adb root或者挂载可写adb shell卡住无响应adbd异常或USB枚举失败重启板子拔插USBkill-server重启Windows识别未知设备驱动未安装手动安装ADB Interface驱动传输速度很慢USB线质量差或Host口供电不足更换USB线连接主机后置USB口结尾最后分享一个我实际用下来的小技巧F133-A这套板子如果玩久了你会发现ADB不仅仅是调试工具它其实能充当开发板与电脑之间的“万能数据桥”。我经常用它来批量配置多块板子先推一个自动配置脚本上去然后adb shell执行也曾经在板子没有屏幕的情况下用screencap把显示内容回传到电脑上验证UI效果。遇到问题时不要一上来就怀疑开发板坏了先按备份思路把USB线、端口、驱动、权限这四个变量逐一固定住再排查应用层问题通常都能迎刃而解。我个人是在踩了无数次设备和驱动识别问题之后才把ADB调试变成日常开发的主流程。如果你刚拿到全志F133-A开发板强烈建议第一时间把ADB调通这会让你后续所有的内核调试、应用开发、文件传输工作都变得轻松许多。