全志F133-A这板子我前前后后折腾了小半个月。刚拿到手那会儿以为搞个ADB能有多复杂结果从硬件接线到驱动识别从连不上到文件传不进去坑是一个接一个踩过来的。今天就把这段实战经历完整写出来包括硬件配置、环境搭建、常用命令、文件传输以及中间遇到的各种问题给后面要玩这块板子的人省点时间。先交代一下背景我手上这块F133-A开发板核心是全志F133-A芯片平头哥玄铁C906 RISC-V核单核1GHz板载64MB DDR3内存自带SPI Flash跑的是精简版Linux或者RTOS系统。这类低成本板子的调试方式通常比较受限串口只能看日志没法传文件、没法模拟触控、也没法批量操作。但接上ADB之后就完全不一样了既能把板子上的文件直接拉回电脑也能把资源包推上去还能抓log、截图、模拟点击调试效率提升一大截。这篇内容适合正在使用F133-A或者类似全志T113、V853系列开发板的开发者也适合刚入门嵌入式Linux、想搞明白ADB怎么在开发板上落地使用的朋友。1. F133-A开发板与ADB调试整体思路1.1 F133-A的硬件底子与调试核心矛盾全志F133-A这颗芯片准确说属于全志的“RISC-V DDR”方案片上集成H.264/H.265编解码器、显示控制器、音频Codec、USB控制器、SD/MMC控制器等外设。板子引出的调试相关接口主要有三个一个USB Host口、一个USB Type-C串口也有叫OTG口、调试口的、一组排针串口。大部分用户上手第一反应是插串口看内核日志这没错但串口只能解决“看得见”解决不了“传得进、拿得出”。这块板子内存只有64MBFlash分区又划分得细跑图形界面或者跑QT应用的时候资源文件、字体、图标、固件升级包这些怎么放上去一直是个麻烦。以前我都是通过串口一个命令一个命令敲用rz上传又慢又不稳定稍微大点的文件就废了。ADB的价值就在这个时候体现出来了它是一个基于USB的调试通道不仅能传输文件还能执行shell命令、转发端口、抓取屏幕图像、模拟输入本质上是一个比串口强大得多的“后门”。1.2 为什么选ADB而不是纯串口或网络调试有人可能会说板子不是有网口吗直接用scp不就行了。问题在于F133-A这类低端开发板默认固件里不一定把网络服务都带齐比如我拿到的这个固件版本SSH服务压根没编译进去想scp也没得scp。就算装了Dropbear往板子上移植、配置、自启动也要折腾半天而且TFTP、NFS这些网络方案对网络环境都有依赖路由器开了隔离或者网段不对就玩不转。ADB就不存在这个烦恼它是全志SDK默认支持的一个调试协议内核驱动配好了系统服务也起来了只要用USB线把板和电脑连起来线一插、服务一开就能直接通讯。虽然速度没有千兆网快但对付几十MB的固件包、资源文件绰绰有余而且它支持在device offline或者SDK重启的情况下快速重连特别适合调试期频繁改东西的场景。1.3 ADB调试链路全貌整套调试链路其实可以拆成四段第一段是物理链路F133-A开发板上的Type-C口通过USB数据线连接电脑USB口这里强调一下有些线只带充电不带数据传输换根线就识别不出来了别在线的上面省钱。第二段是设备侧F133-A内核里需要编译USB Gadget驱动支持ADB Function系统起来后init进程会拉起adbd守护进程。这套东西通常在SDK里已经配置好了我们不需要改但如果自定义内核忘了开相关配置就会出现电脑端永远提示找不到设备。第三段是电脑侧操作系统识别到ADB接口后需要正确的USB驱动才能让ADB工具跟设备握手。Windows系统尤其麻烦设备管理器里经常把设备识别成Unknown Device需要用板卡厂商提供的驱动或者用Zadig类工具手动指定驱动。第四段才是应用层电脑上安装platform-tools中的adb命令行工具执行adb devices就能看到设备随后就可以执行shell、push、pull、install等一系列操作。想清楚这四段之后后期排查问题就有了方向是线的问题、设备侧服务问题、电脑驱动问题还是工具版本问题逐个排除就行。2. 硬件配置与连接调试2.1 硬件清单与接口识别在正式开始之前先把需要用到的硬件理一理。除了F133-A开发板本体和一台电脑Windows/Linux均可之外还需要准备一条支持数据传输的USB Type-A转Type-C线注意确认线序完整能通数据而不是只能充电。F133-A开发板上一般有两个USB相关接口一个是标准USB Host口用来插U盘、USB摄像头这类外设的另一个是Type-C调试口这个既能当串口用也能当ADB口用。刚开始我不懂把数据线插到Host口上电脑一点反应都没有后来翻原理图才看到ADB调试走的是Type-C那一路经过芯片内部的USB DRD控制器通过OTG检测和ID引脚判断设备角色。还有一个关键点很多F133-A开发板的Type-C口同时复用了串口和USB信号板子上通常有跳线帽或者拨码开关来切换模式。我手头这块板子在调试口旁边有一个两针的跳线默认跳到UART模式要切到ADB模式必须把跳线帽拔掉换到USB侧否则不管怎么插线电脑只能看到一个串口设备看不到ADB设备。2.2 上电时序与内核启动状态确认很多新手把线接好、驱动装好、adb工具也装了结果执行adb devices就是空的其实问题出在板子还没正常启动。F133-A上电后需要大约几秒时间完成BootROM加载、SPL初始化内存和控制器、然后才轮到adbd进程起来。实操时我的习惯是先看串口日志确认内核起来、rootfs挂载完成、adbd进程已经监听USB。如果看不到adb服务相关的打印就用串口手动执行一下 ps -ef | grep adbd确认进程在不在。如果进程不在大概率是内核配置里没开USB Gadget这个后面会展开说。上电时最好先不插USB数据线等板子和串口日志都稳定了再插USB线到电脑这样电脑端枚举设备的节奏跟板子启动节奏是匹配的不容易出现设备枚举失败或者反复掉线的情况。2.3 电脑端USB驱动安装要点这部分对Windows用户尤其重要。F133-A通过USB连接电脑后设备管理器里默认会多出一个未知设备或者识别成“USB 串行设备”这时候ADB工具是发现不了它的必须先装ADB接口驱动。我用的方案是下载板卡厂商提供的全志USB驱动包其中包含WinUSB或者libusb驱动签名安装后在设备管理器里手动更新驱动程序指向驱动包目录确认设备名称变成类似“ADB Interface”或“Android Composite ADB Interface”才算成功。如果没有厂商驱动也可以用Zadig工具把对应的USB设备驱动替换成WinUSB或libusb-win32实测下来同样有效。但要注意如果板卡支持MTP、RNDIS等多个USB功能在设备管理器里会出现好几个子设备需要找到带ADB标识的那个设备来更新驱动别选错了。Linux下相对简单系统自带usbfs和libusb一般能直接识别但需要配置udev规则允许当前用户访问该USB设备。直接sudo adb会带来权限问题后面再细说。2.4 Linux下的USB权限与udev规则配置在Ubuntu等Linux发行版下插上F133-A后执行lsusb能看到一个USB设备厂商ID一般是全志的协议栈枚举出来的比如1f3aAllwinner Technology。如果不加任何处理普通用户执行adb devices会提示no permissions (user in plugdev group; are your udev rules missing?)这其实是USB设备节点权限不足。解决方法是创建一个udev规则文件比如/etc/udev/rules.d/51-allwinner-adb.rules内容大致如下SUBSYSTEMusb, ATTR{idVendor}1f3a, MODE0666, GROUPplugdev保存后执行sudo udevadm control --reload和sudo udevadm trigger重新插拔USB线再执行adb devices应该就能看到了。这块卡了我一个晚上当时老以为是驱动问题其实只是权限。3. ADB工具链环境配置与连接验证3.1 ADB工具包选择与环境变量配置电脑端使用的ADB工具推荐直接下载Google官方维护的platform-tools工具包它包含了adb和fastboot两个核心工具后续版本更新也会保持与Windows/Linux/macOS同步省得自己去编译源码。下载解压后我的习惯是把它放到一个稳定的目录比如Windows下放D:\platform-toolsLinux下放~/platform-tools然后把这个目录加入系统PATH环境变量。Windows下操作是先打开系统属性-环境变量在Path中添加D:\platform-toolsLinux下则在~/.bashrc或~/.zshrc中追加一行export PATH$PATH:~/platform-tools然后source一下。完成之后打开终端输入adb version能看到Android Debug Bridge version 1.0.41一类的输出版本号说明工具链已经就绪。拿到一个新的开发板第一件事我建议先执行adb devices -l看一下设备列表如果输出显示一串序列号并且带device状态说明整个链路已经打通。如果显示unauthorized就需要在板子上确认RSA授权弹窗但F133-A很多时候没有屏幕这个问题处理技巧见后面常见问题部分。3.2 有屏幕设备的屏幕解锁与ADB授权技巧F133-A开发板常见形态有两种一种是带屏幕的裸板跑的是精简LinuxLVGL之类的GUI另一种是带MiniHDMI输出、可以当成一个微主机来用的全家桶板子。不管哪种第一次连接ADB时设备端通常都需要确认是否允许USB调试。但对没有鼠标没有触摸的板子来说屏幕上如果弹了授权窗口根本没有手动点确认的入口这时推荐用串口终端帮忙。具体操作是用串口登录板子查看ADB的Key管理文件位置通常系统会把已经授权的电脑公钥存储在data/misc/adb/adb_keys里。可以手工把电脑本地的~/.android/adbkey.pub内容追加到这个文件然后重启adbd进程。这样做一次之后板子就记住了这台电脑的指纹后续插线直接就是device状态不用再管弹窗。如果你只是想临时用一下也可以简单执行adb shell锁屏解锁相关的命令但注意F133-A的Android系统很少见多数是Linux这个命令不一定适用。关键还是把授权问题解决在前面。3.3 Windows与Linux下adb server处理细节电脑上ADB工具的本质是一个adb client通过TCP协议连接本机的adb server进程再由adb server通过USB或网络与设备通讯。有时候板子明明没插线adb却提示offline多半是adb server进程卡住了。Windows环境下如果碰到这种情况先执行adb kill-server再执行adb start-server重新初始化一下服务。如果提示端口5037被占用一般是手机上类似手机助手之类的程序抢占了端口可以进任务管理器找到对应进程关掉或者换端口。这个坑在windows环境特别常见网上搜“windows10管理员找不到adb”基本就是这个原因。Linux环境下相对好一点但要留意同一个用户空间下adb server的启动权限不要在root下启动然后在普通用户下执行命令两边权限上下文不一样会导致设备列表为空。4. 常用ADB命令实战截图、日志、shell操作4.1 设备连接状态与基础信息获取ADB连接稳定之后我习惯先去拉一下设备的基本信息一个是确认连接状态另一个是了解系统和CPU的负载情况这对后续判断程序是否跑起来很有用。adb devices adb shell cat /proc/cpuinfo adb shell free -m adb shell df -hF133-A上执行cat /proc/cpuinfo能看到riscv架构相关的CPU型号和特性。free -m可以看到64MB内存的分配情况df -h则能看清各分区剩余空间。有时候板子内存占满应用启动失败不一定是代码问题而是Flash剩余空间不够日志写不进去这时候通过df -h排查很快。4.2 截图保存到电脑的三种方法截图是调试UI应用最常做的事。网上关于“adb截图保存电脑”的教程不少但多数是针对手机的开发板上有些命令不一定好用。我这里实测下来有三种方法第一种是标准screencapadb shell screencap -p /data/screen.png adb pull /data/screen.png D:/screen.png好处是稳定F133-A上能正常执行坏处是生成的文件在板载空间里对小内存板子来说多次截图可能把tmp分区占满。第二种是直接输出到电脑adb exec-out screencap -p screen.png这种方式不经过板载存储直接把PNG流重定向到电脑文件。实测F133-A上有效而且速度也不错推荐优先用这个。第三种是结合busybox工具adb shell busybox dd if/dev/fb0 of/data/fb.raw这种方法截取的是framebuffer原始数据适合对显示效果做像素级分析但恢复成可见PNG格式需要额外处理开发阶段用得少。4.3 input命令在无触屏设备上的应用F133-A开发板如果不带触摸屏通常默认的输入设备只有键盘和鼠标。调试QT或者LVGL这类图形界面时没法像手机上那样点来点去这时候ADB的input命令非常实用adb shell input keyevent 4 # BACK adb shell input keyevent 3 # HOME adb shell input keyevent 24 # 音量加 adb shell input tap 100 200 # 模拟触摸 adb shell input swipe 100 200 300 400 # 模拟滑动如果板子支持HID over I2C这类协议很多鸿蒙开发板这么干input命令的效果会更好。但有些精简Linux的input子系统没有编译进来执行input的时候会提示command not found这时候就得确认内核是否开启了CONFIG_INPUT_UINPUT和对应的UI设备节点。4.4 日志抓取与logcat实战F133-A如果跑的是Android系统默认有logcat日志系统如果跑的是Linux根文件系统日志一般在串口和syslog里。ADB方式抓log主要是针对Android或类似Android架构的。adb logcat -v threadtime logcat.txt adb logcat -s TAG_NAME:D *:S adb logcat -c把日志重定向到电脑文件然后配合grep过滤关键字是排查应用崩溃、底层报错最快的方式。我遇到过应用启动不久就闪退的问题在串口上反复打印段错误地址但不明显用logcat一拉直接看到是缺少某个so库秒定位。如果板子是精简Linuxadb shell后还可以直接执行dmesg、cat /var/log/messages来判断内核级错误。ADB shell本质上给你一个远程终端系统里有什么工具都能直接用关键是权限足够很多板子默认root所以调试效率天然比串口高一大截。4.5 变更系统设置的几个高频命令在F133-A这类Linux开发板上经常需要做一些修改默认设置的操作比如关闭密码保护、修改屏保超时、禁用某些服务等。虽然不像Android手机那么丰富但部分设置项是通用的。adb shell locksettings set-disabled true # 如果是Android系统且支持 adb shell settings put global stay_on_while_plugged_in 1 adb shell dumpsys battery set usb 0其中locksettings命令在有屏幕的Androiod开发板上很常用执行后可以关闭锁屏方便后续无人值守运行。虽然F133-A原厂固件很可能不带settings服务但是搞清楚这套ADB控制系统的思路换到其他全志平台也通用。5. 文件传输实战从pull/push到网络辅助5.1 adb pull与adb push的核心用法F133-A内存和Flash容量有限文件传输是最频繁的需求。文档、字体、图标、可执行程序、内核模块、数据库来回传递都是靠这两个命令。adb push D:/resource/sans.ttf /usr/share/fonts/ adb pull /etc/wpa_supplicant.conf D:/backup/push本地的资源文件到开发板指定路径pull拉取开发板上的文件到电脑就是这两个方向。实际操作要注意目录权限F133-A默认root用户一般不存在权限不够的问题如果遇到Permission denied优先确认目标文件系统是否只读挂载Flash分区经常被挂载为ro需要重新mount为rw。还有一个细节文件较大的时候建议先push到/tmp或/data分区再通过mv命令移动到最终位置因为某些根文件系统对直接写入大文件表现不太稳定容易写一半失败这种半路出错在Flash设备上非常常见。5.2 中文文件名和特殊字符处理从Windows操作ADB的时候中文路径和空格是最容易出现问题的因为Windows下的编码跟Linux默认的UTF-8不一致经常出现乱码、找不到文件的情况。我踩过的坑是这样在Windows终端中执行adb push D:\素材包\字体\常规.ttf /tmp/虽然路径加了引号adb仍显示找不到文件。后来测试发现Windows控制台默认编码是GBK而ADB工具按UTF-8解析中文路径就乱套了。保险的写法是先重命名成纯英文文件名再push或者先用adb push D:\1.ttf /tmp/test.ttf别带中文。board端目录名如果非要用中文建议通过串口先用shell创建设置好UTF-8语言环境后再操作。5.3 用scp作为ADB文件传输的补充方案ADB虽然好用但它的传输速率受USB枚举和adbd实现限制实测大文件在F133-A上push速度大概1~3MB/s不够快。如果你的板子固件里带了SSH服务那scp文件传输是很好的补充scp ./resource.tar.gz root192.168.1.100:/root/ scp -r ./folder root192.168.1.100:/root/scp基于SSH加密传输处理大目录的时候效率比ADB高不少而且支持断点续传配合rsync更佳。F133-A跑Linux如果固件里没带SSH服务可以通过ADB把dropbear静态编译版推上去然后再用scp传输后续内容多一步但是速度快很多。5.4 开发板挂载Ubuntu主机目录的方案文件传输还有一种更“魔法”的方式那就是让开发板直接挂载Ubuntu主机上的目录。这样开发板读写某个目录实际上是在读写Ubuntu主机的文件系统无论是调试代码还是替换资源都像在本地操作一样方便。最常用的是NFS挂载。需要先在Ubuntu上安装并配置NFS服务器把某个目录export出来开发板上执行mount命令挂载sudo apt install nfs-kernel-server # 修改/etc/exports添加 /home/ubuntu/shared *(rw,sync,no_root_squash,no_subtree_check) sudo exportfs -a开发板上adb shell mount -t nfs -o nolock 192.168.1.100:/home/ubuntu/shared /mnt这样开发板的/mnt目录就和Ubuntu主机的/home/ubuntu/shared目录实时同步了可以直接从/mnt运行可执行文件。注意F133-A的Linux内核默认会打开NFS客户端支持但如果自定义内核的时候忘了配置CONFIG_NFS_FSmount会报错。除了NFS还可以用sshfs方式开发板通过FUSE文件系统挂载远程目录不过低端板子通常没开FUSE支持实用性略差。6. 常见问题与排查技巧实录6.1 常见错误速查表这一节我把实际开发中F133-A ADB调试遇到的典型问题整理成了一张速查表方便大家按图索骥。现象可能原因解决办法adb devices没有任何输出USB线不支持数据传输或Type-C口接错了更换数据线检查是否插到调试口提示unauthorized板端未授权当前电脑公钥通过串口把电脑adbkey.pub写入/data/misc/adb/adb_keys重启adbddevice offlineadb server状态异常或USB枚举不稳adb kill-server adb start-server重新插拔USB线no permissionsLinux下USB设备节点权限不足配置udev规则将当前用户加入plugdev组device not found驱动未装或内核未开USB Gadget设备管理器更新驱动检查内核配置CONFIG_USB_CONFIGFSwait for device超时板子未完全启动或adbd未启动串口观察启动日志手动启动adbd服务push文件提示只读Flash分区挂载为roadb shell mount -o remount,rw / 后再pushinput命令不存在内核未开启uinput驱动配置CONFIG_INPUT_UINPUTy后重新编译内核截图输出文件损坏exec-out重定向在Windows下使用了错误模式使用cmd而非PowerShell编码差异或用adb pull方式无法连接无线ADB板子网络未配置或adbd未监听先配好IP和网关再adb connect IP:55556.2 无线ADB调试的补充方案虽然F133-A通常通过USB连接但有些场景不方便拖一根线比如设备已经装进外壳里或者放在不好够到的位置。这时候可以用无线ADB代替USB线。前提是板子已经通过有线以太网或WiFi连接到了局域网。先通过USB连一次设置好网络参数然后执行adb tcpip 5555 adb connect 192.168.1.100:5555正常的话adb devices里会多出一台IP:5555的设备这时拔掉USB线也可以继续调试。注意F133-A如果跑的是精简Linux而不是Androidadb tcpip这个命令不一定存在可以通过直接修改adbd启动参数比如adbd --port 5555来监听TCP端口。无线ADB传输速度受限于网络带宽但跟串口相比还是快得多。6.3 利用ADB Shell做自动化测试与批处理开发板调试到后期不断重复执行同样的命令会让人抓狂。我习惯把这些命令写成脚本在PC端跑一键完成整套操作。例如写一个脚本将本地目录下的所有apk安装到开发板上的Android系统for apk in $(ls *.apk); do echo Installing $apk ... adb install -r $apk done如果板子跑的是Linux应用也可以把编译好的可执行文件和依赖库通过adb push推到板子再通过adb shell一键启动adb push ./app /data/app/ adb shell chmod x /data/app /data/app --daemon这样每次编译完直接在电脑上跑一下脚本三秒内新版本就部署到板子上了比起SD卡拷文件循环效率高得多。6.4 内存不足场景下的传输优化F133-A板载64MB DDR3实际可用内存还要留一部分给显示缓冲和系统运行栈所以当传输大文件时经常出现内存吃紧push到一半进程被杀掉的状况。我的经验是大文件分片传输先在电脑端做好切分split -b 8M firmware.bin firmware_part_ adb push firmware_part_* /tmp/ adb shell cd /tmp cat firmware_part_* /data/firmware.bin先传到临时目录/tmptmpfs内存文件系统读写快再合并移动到最终位置避免直接在Flash上连续大块写入导致IO过慢也避免内存被一次性占用太大。这个方法传几十上百MB的文件都很稳。7. 一点个人经验总结把F133-A的ADB调试链路打通之后最大的感受就是调试效率完全不在一个量级上。串口时代传个文件可能花上十分钟现在用adb push几秒钟搞定以前只能看打印现在截图、日志、模拟输入、批量部署通通都变得简单了。个人最推荐的学习路径是从一条USB数据线和一张带ADB功能的固件开始先把ADB环境变量配好然后用adb pull和adb shell把系统文件翻一遍理解了整个工具链的运行机制后再尝试做无线ADB和自动化脚本每一步都能看得见摸得着。最后再分享一个小技巧如果遇到ADB死活连不上的问题先别急着重刷固件最简单的办法是用串口登录板子敲一下adbd进程有没有起来再执行一下lsusb确认USB控制器有没有枚举到设备。八成情况下问题出在这两个地方剩下的只需要耐心排查驱动和权限。