★ FEATURED ARTICLE 最近在调一块基于RK3588的板子BSP这边的活儿主要是把内核、设备树、外设驱动一整套从原厂SDK里梳理清楚跑通基本功能。系列文章的第一篇我准备从RTC下手。为什么选RTC开头因为RTC这个外设在BSP调试里非常典型它横跨硬件电路、设备树配置、内核驱动、用户态工具几个层面还牵扯到掉电保持、时钟校准这些实际工程问题。麻雀虽小五脏俱全把RTC调明白了整套BSP调试的方法论也就立起来了。这篇就把我在RK3588平台上调试RTC的完整过程、踩过的坑、以及沉淀下来的验证方法写清楚给同样在做BSP的兄弟们一个参考。1. RTC调试的全局视角为什么它是BSP入门的必修课1.1 RTC在嵌入式系统中的真实定位很多人觉得RTC不就是读个时间嘛驱动自带了设备树配一下就能用。实际上RTC在嵌入式系统里的角色要复杂得多。系统关机后主供电断开SoC内部的绝大多数域都断电了唯独RTC部分靠一颗纽扣电池或者超级电容维持供电继续跑32.768kHz的晶振保住时间和闹钟寄存器不丢。这意味着BSP工程师需要同时操心电源域、晶振电路、寄存器读写、系统集成四个方面。RK3588这颗芯片内置了RTC控制器同时也支持通过I2C外接独立的RTC芯片。两种方案各有利弊内部RTC集成度高但和SoC绑定一旦芯片进Sleep模式或者掉电路径设计不合理备用电流控制不好就容易出问题外部RTC芯片独立性强但多一颗物料、多一路I2C、多一个中断硬件设计上要额外小心。我这次调的是内部RTC但调试思路对两种方案都适用。1.2 BSP调试的基本方法论做BSP调试和纯粹做应用开发完全不同。应用开发可以靠日志、断点、调试器BSP调试则是硬件、软件、系统三线并行。我的习惯是遵循先硬件后软件、先最小系统后完整功能的原则第一步先用示波器确认晶振波形正不正常第二步确认SoC的RTC模块电源域有没有供电第三步看设备树节点和内核配置第四步用用户态工具验证功能第五步做掉电和压力测试。这套流程听起来简单但每一步都有坑。比如晶振波形看起来是有了但振幅不够内部振荡器起振不稳时间走着走着就跳变比如设备树里RTC节点地址写对了但对应的pinctrl被别的外设占用了驱动加载直接崩。这些都是我在调试过程中真实遇到的后文会一个一个拆开讲。在动手之前建议把调试环境准备好RK3588的串口调试线、逻辑分析仪、示波器、可以随时切换的内核编译环境还有一块充满电的备用电池我用的是CR1220纽扣电池座。工具不齐会非常被动。2. 内核配置与设备树让RTC先被系统看到2.1 内核配置项的梳理RK3588原厂SDK一般默认打开了RTC驱动但最好还是亲自过一遍menuconfig确认。与RTC直接相关的配置项有这么几个CONFIG_RTC_DRV_ROCKCHIP芯片内部RTC驱动必须开启CONFIG_RTC_HCTOSYS系统启动时把RTC时间回填给系统时间一般默认开CONFIG_RTC_SYSTOHC系统关机或同步时把系统时间写回RTC默认也开CONFIG_RTC_DRV_XXXX如果外接I2C RTC芯片需要对应打开具体驱动要特别关注CONFIG_RTC_HCTOSYS。这个配置决定了内核启动阶段是否用RTC的时间初始化系统时间。如果RTC时间本身是无效的内核就会从默认的2000年1月1日开始计时表现为date命令读出来一个远古时间。所以如果你的系统需要开机就有正确时间必须确保RTC里存的值是有效的否则就会出现时间回退。检查内核配置时我习惯用这样的方式# 在当前内核源码目录下 cd kernel make menuconfig # 进入 Device Drivers - Real Time Clock # 确认 Rockchip RTC 勾选为 * 或 M # 确认 Set system time from RTC on startup 开启另一个容易被忽略的点是驱动编译进内核还是编成模块。建议BSP阶段直接编进内核不要用模块。RTC驱动的加载时机非常靠前如果编成模块模块加载顺序依赖udev或者initramfs断点太多出了问题很难排查。我在量产方案里也统一用内建方式。2.2 设备树节点的完整解析设备树是BSP调试的核心战场。RK3588的内部RTC在dtsi基础文件里已经有节点板级dts要做的就是确认节点使能和去冲突。一个典型的内部RTC节点长得像下面这样我在注释里标了每个字段的作用rtc: rtc3ad0000 { compatible rockchip,rk3588-rtc; reg 0x0 0x3ad0000 0x0 0x100; interrupts GIC_SPI 295 IRQ_TYPE_LEVEL_HIGH; clocks cru RTC_32K; clock-names rtc; pinctrl-names default; pinctrl-0 rtc_32k; status okay; };几个关键字段的解读compatible驱动匹配的关键字符串。驱动侧通过of_device_id数组来匹配这个字符串如果写错或者驱动里没加对应的ID驱动根本不会加载。regRTC寄存器的基地址和映射大小。这个地址必须和芯片手册里的寄存器地址完全一致写错了驱动去读寄存器时就会访问到错误的内存甚至触发IO错误。interrupts闹钟中断。RTC不只是记时间更重要的是秒中断和闹钟中断。GIC_SPI 295表示这是SPI类型的中断号路由到GIC通用中断控制器。clocks和pinctrl-0这两个最容易出问题。RTC需要32.768kHz的参考时钟这个时钟既可以是外部晶振也可以是SoC内部的时钟源。pinctrl配置的rtc_32k引脚如果和其他外设复用冲突就会导致晶振电路不工作。实配过程中我见过好几个板子是因为pinctrl冲突导致RTC不跑。排查方法很简单拿到板子后先看/sys/kernel/debug/pinctrl/下的pinmux状态确认RTC对应的引脚没有被其他外设抢占。如果你用的是外接RTC芯片设备树节点则是挂在某个I2C总线下面的子节点i2c6 { status okay; rtc51 { compatible pcf8563; reg 0x51; interrupts gpio4 RK_PB7 IRQ_TYPE_LEVEL_LOW; pinctrl-0 rtc_int_l; }; };外接芯片要特别关注I2C地址。0x51是PCF8563默认的7位地址但有的芯片允许通过引脚配置换地址一旦和总线上其他芯片地址撞了I2C通信就会混乱表现是读出来的时间一直不对甚至读写失败。2.3 晶振电路与电源域设计RTC要正常工作硬件上必须保证两个东西晶振和备用电源。RK3588内部RTC一般使用32.768kHz的晶振晶振两脚通常接两个负载电容到地。这个负载电容的取值直接影响晶振的频偏。电容选大了振荡频率偏低一天能差出几十秒选小了频率偏高还会导致振荡不稳定。精确的做法是查晶振规格书确认CL值然后按下式估算匹配电容C1 C2 2 * CL - Cstray其中CL是晶振要求的负载电容Cstray是PCB上的寄生电容一般取1~3pF。举个例子一款常用晶振CL6pFCstray约1.5pF算出来C1C2大约9pF。很多公版设计直接用10pF~12pF实测误差往往就在这个环节引入。备用电源这一块要确认VBAT引脚确实连到了电池或超级电容并且充电电路如果有正确配置。有的板子RTC电池是可充电的锂亚电池有专门的充电回路BSP工程师要在驱动里设置充电电流上限避免过充。这里还要注意一个电源域的问题。RK3588的RTC模块属于PMUIO电源域如果这一个域没有被正确供电即使驱动加载成功读写寄存器也会失败。排查时看内核启动log里有没有rockchip-rtc ... fail to get regmap类的报错有的话大概率是电源域或regmap配置问题。3. 驱动框架与关键实现RTC驱动是怎么工作的3.1 Linux RTC子系统架构Linux把各类RTC芯片抽象成了一个统一的框架源码在drivers/rtc/目录下。框架分两层上层是通用的rtc-core向用户态提供字符设备、sysfs属性和proc接口下层是具体的rtc-xxx驱动只需要实现一组回调函数。驱动需要实现的核心回调包括read_time从硬件寄存器读出时间填充到struct rtc_timeset_time把时间写入硬件寄存器read_alarm读取闹钟设置set_alarm设置闹钟alarm_irq_enable使能闹钟中断驱动注册时调用devm_rtc_allocate_device和devm_rtc_register_device框架就会自动创建设备节点。内核中/dev/rtc0对应第一颗RTC设备外接芯片一般会注册成rtc1或者更多个。日常使用中可以用ls -l /dev/rtc*看一共有几个RTC设备再用hwclock -r分别测试它们谁能正确读回时间。有的板子上既有内部RTC又外接了独立RTC芯片系统里就会出现/dev/rtc0和/dev/rtc1两个设备。用户判断要搞清楚/dev/rtc0映射到哪一个硬件不然可能出现你写的是内部RTC断电后读的却是外部芯片两个时间源不一致直接造成系统时间跳变。3.2 内部寄存器操作的核心细节RK3588内部RTC驱动的工作流程大致是这样的通过regmap接口映射寄存器地址然后执行读写序列。这里有一个非常容易忽略的细节——很多RTC芯片的时间寄存器是BCD编码的直接read出来的值不是二进制数必须做BCD转换。处理BCD格式的代码一般长这样static int rockchip_rtc_read_time(struct device *dev, struct rtc_time *tm) { struct rtc_data *data dev_get_drvdata(dev); // 读取年、月、日、时、分、秒寄存器 tm-tm_year bcd2bin(data-regmap_read(data, YEAR_REG)) 100; tm-tm_mon bcd2bin(data-regmap_read(data, MONTH_REG)) - 1; tm-tm_mday bcd2bin(data-regmap_read(data, DAY_REG)); tm-tm_hour bcd2bin(data-regmap_read(data, HOUR_REG)); tm-tm_min bcd2bin(data-regmap_read(data, MIN_REG)); tm-tm_sec bcd2bin(data-regmap_read(data, SEC_REG)); return 0; }bcd2bin宏把BCD码转换为二进制。写时间时反向操作bin2bcd把二进制转回BCD。如果不做转换程序里的小时值可能变成十六进制意义上才对得上的数时间会乱得一塌糊涂。另一个细节是写入时序。有的RTC芯片在寄存器写入期间会锁存数据如果没等总线空闲就去做别的操作可能丢失一次写入。驱动里一般会先写“可写使能”寄存器再写时间寄存器最后清理使能位。RK3588内部RTC没有这么复杂的保护逻辑但外接芯片比如某些I2C RTC就有写驱动时务必仔细读芯片手册的操作流程图。3.3 用户态接口详解RTC驱动注册好之后用户态能看到这么几类接口第一类是字符设备/dev/rtc0。这是传统接口应用层通过openioctl来操作。常用的ioctl命令包括RTC_RD_TIME读时间、RTC_SET_TIME写时间、RTC_WKALM_SET设置闹钟、RTC_WKALM_RD读取闹钟、RTC_IRQP_SET设置中断频率。第二类是sysfs属性通常在/sys/class/rtc/rtc0/目录下。这个目录里有date以YYYY-MM-DD格式读日期time以HH:MM:SS格式读时间since_epoch从1970年1月1日起的秒数wakealarm读或写闹钟时间offsetRTC相对标准时间的偏移校准值第三类是proc接口/proc/driver/rtc。这个文件把RTC状态汇总成人类可读的文本包括时间、闹钟、中断计数等。调试时我经常cat这个文件快速确认驱动是否正常工作。日常最常用的用户态工具是date和hwclock。date管理的是系统时间内核维护的时间hwclock管理的是硬件RTC时间。两者要配合着用系统时间从RTC同步过来改完系统时间再写回RTC。关于时区问题有必要多说一句。硬件RTC内部存储的时间业界约定有两种习惯一种是存UTC时间系统启动时根据/etc/localtime或TZ环境变量换算成当地时区另一种直接存本地时间。Windows和嵌入式Linux的习惯不同经常打架。判断当前系统是哪种方式在Linux下执行timedatectl看RTC in local TZ: no/yes即可。如果是no说明RTC存的是UTChwclock读写时默认加8个小时的偏移。这个坑特别隐蔽很多人发现“我明明设置了正确时间重启后又差了8小时”就是在时区上栽了跟头。4. 从零到一RK3588上RTC的完整调试验证流程4.1 基本功能验证步骤拿到一块RK3588开发板第一步先确认硬件和系统能不能看得到RTC。完整流程分六步走第一步确认设备树加载正常。板子启动后先检查内核有没有打印RTC驱动的注册信息dmesg | grep -i rtc正常的输出里应该包含设备树匹配成功的日志比如rtc rtc0: registered as rtc0。如果这条日志都没有说明驱动没加载抓紧查kernel config和compatible字符串。第二步确认系统时间源。执行cat /sys/class/rtc/rtc0/time cat /proc/driver/rtc如果RTC时间可以正常读取说明驱动正常工作。如果读出来全0或者一个荒谬的时间说明寄存器访问有问题或者晶振没起振。第三步设置系统时间并写入RTC。在板上执行# 设置系统时间比如2025年5月20日 14:30:00 date -s 2025-05-20 14:30:00 # 同步到RTC hwclock -w # 读回RTC时间验证 hwclock -r这里注意date -s改的是系统时间hwclock -w把系统时间写到硬件RTC。两者要分开执行缺一不可。有人直接执行hwclock --systohc然后发现时间不对是因为系统时间本身就没设置对。第四步重启验证掉电保存。先记录当前时间然后执行reboot系统重启后重新读取时间date hwclock -r如果重启后时间还在说明掉电保持基本没问题。如果时间回退到了初始值先查电池端电压再查RTC的备用电源域配置。第五步验证闹钟功能。设置一个30秒后的闹钟# 先关闭已有的闹钟 echo 0 /sys/class/rtc/rtc0/wakealarm # 设置30秒后的闹钟 echo date -d 30 seconds %s /sys/class/rtc/rtc0/wakealarm # 查看结果 cat /sys/class/rtc/rtc0/wakealarm如果驱动有中断支持系统会在闹钟触发时打印一条内核日志。对于支持RTC唤醒的系统还可以配合echo standby /sys/power/state让系统睡眠后再唤醒测试RTC作为唤醒源的能力。第六步做基本的精度观察。先对时再放置一段时间至少24小时回来对比RTC和标准时间的偏差。用NTP服务器对时后写一次RTC记录初始值24小时后再读一次误差一般在几秒到十几秒量级取决于晶振质量。如果误差超过一分钟基本可以断定晶振匹配电容问题或者晶振本身质量不行。4.2 自动化验证脚本手动验证太多写个脚本提升效率。我日常用一个自动化测试脚本覆盖基本读写、掉电后校验、闹钟功能三条主线脚本关键逻辑如下#!/bin/bash # RTC功能验证脚本 # 用法: ./rtc_test.sh PASS0 FAIL0 check() { if [ $? -eq 0 ]; then echo [PASS] $1 PASS$((PASS1)) else echo [FAIL] $1 FAIL$((FAIL1)) fi } echo RTC 基础读写测试 # 设置固定的系统时间 date -s 2025-05-20 14:30:00 check 设置系统时间 # 写入RTC hwclock -w check 系统时间写入RTC # 读回RTC时间 hwclock -r check RTC时间读回 # 比较读回的时间和预期是否一致 RTC_TIME$(hwclock -r | awk {print $1}) if [ $RTC_TIME 2025-05-20 ]; then echo [PASS] 时间日期一致性 PASS$((PASS1)) else echo [FAIL] 时间日期一致性, 读出: $RTC_TIME FAIL$((FAIL1)) fi echo 闹钟功能测试 # 清除闹钟 echo 0 /sys/class/rtc/rtc0/wakealarm # 设置10秒后的闹钟 echo date -d 10 seconds %s /sys/class/rtc/rtc0/wakealarm check 设置闹钟 # 读取闹钟确认设置成功 ALARM$(cat /sys/class/rtc/rtc0/wakealarm) echo 当前闹钟时间戳: $ALARM echo 测试结果 echo 通过: $PASS 失败: $FAIL if [ $FAIL -gt 0 ]; then exit 1 else exit 0 fi这个脚本只是一个基础版实际量产测试建议扩展成完整的自动化测试用例集覆盖异常输入比如写入非法日期、连续读1000次稳定性、设置和读回一致性比对等场景。脚本写完后记得用chmod x赋执行权限再配合交叉编译好的busybox环境挂载到目标板上运行。4.3 调试工具链的使用经验BSP调试过程中除了板子上的命令行工具主机侧的工具链同样重要。我一般习惯把Linux内核的tools/testing/selftests里RTC相关测试程序交叉编译到板子上跑这些测试代码是内核维护者写的对各种边界条件的覆盖比手写的脚本好得多。交叉编译RTC测试工具的命令大致如下# 假设交叉编译工具链为aarch64-linux-gnu-gcc cd kernel/tools/testing/selftests make TARGETSrtc CROSS_COMPILEaarch64-linux-gnu-生成的可执行文件拷到板子的/usr/bin下直接用rtc_selftests批量跑。我在RK3588上实测过一套能把读时间、设置时间、闹钟、IRQ频率这些路径全部打到比较适合做回归测试。如果怀疑I2C外接RTC有通信问题I2C工具也要备好# 查看I2C总线上挂载的设备 i2cdetect -y 6 # 直接读取RTC芯片的寄存器原始值 i2cget -y 6 0x51 0x02i2cget返回的是纯寄存器值可以对照芯片手册人工核对BCD码是否正确。比如读到秒寄存器0x30那实际就是BCD编码的30秒。这一步能帮你快速定位是驱动读数错误还是硬件时序问题。5. 常见问题与排查技巧实录5.1 典型问题速查表把我在RK3588调试过程中和同行交流中最常遇到的问题整理成一个速查表遇到类似情况可以先对照排查。故障现象可能原因排查顺序date读出来是2000年或1900年RTC寄存器无效、电池没电、HCTOSYS配置关闭1. 查电池电压 2. 查CONFIG_RTC_HCTOSYS 3. 重新hwclock -whwclock -r读失败报ioctl错误驱动没加载、设备树地址错误、电源域没供电1. dmesg看驱动日志 2. 查dts节点 3. 查regmap系统时间每次重启跳变内外部RTC设备同时存在、/dev/rtc0指向错误1. ls /dev/rtc* 2. 分别hwclock -r 3. 确定正确设备节点时间偏差越来越大晶振频率不准、负载电容不匹配1. 示波器测32.768kHz波形 2. 计算匹配电容 3. 更换晶振闹钟不触发中断配置错误、wakealarm被清零1. 查设备树中断 2. cat wakealarm确认 3. 查中断响应设置时间后马上读回错误BCD转换错误、写寄存器未生效1. i2cget读原始寄存器 2. 核对BCD码 3. 查驱动写时序5.2 我踩过的三个隐蔽坑第一个坑是内外部RTC共存导致的/dev/rtc0指错。某板子硬件上既有RK3588内部RTC又外挂了独立RTC芯片系统启动后注册顺序不确定/dev/rtc0可能是内部RTC也可能是外部芯片。当时应用层用固定路径写RTC导致了几个小时的排障。后来统一在系统启动脚本里根据设备树的aliases配置固定RTC设备名才根治这个问题。第二个坑是时区导致的时间偏移8小时。RK3588板子默认时区设置成Asia/Shanghai但hwclock默认认为RTC存的是UTC写入和读取之间就会差出8小时。一开始我以为是驱动问题折腾了半天最后发现是时区语义没对齐。现在我在设备启动脚本里显式写入/etc/adjtime内容为0 0 0.0 0\nLOCAL\n让系统明确知道RTC存的是本地时间配合timedatectl set-local-rtc 1设置问题就消失了。第三个坑是pinctrl冲突导致RTC时钟源被关闭。RK3588的32.768kHz引脚除了给RTC用还可能被其他外设复用比如以太网PHY的参考时钟或者I2S的MCLK。当时设备树里某个外设节点使能后把RTC的32K引脚抢走了RTC模块虽然还活着但时钟源没有了时间直接停止走动。排查方法是看pinctrl debugfs把冲突的外设节点禁掉问题立刻解决。5.3 排查流程的经验总结排查RTC问题时我建议按照“硬件方向确认-驱动状态确认-寄存器级确认-用户态行为确认”的层级逐层推进不要一上来就在应用层瞎猜。第一步永远是看晶振和电池。把示波器探针点到32.768kHz晶振引脚上如果有正常的正弦波或方波输出注意探头电容会影响频率最好用低电容探头说明晶振起振没问题。电池电压用万用表量一下低于2.0V的纽扣电池就该换了很多“掉电后时间丢失”的问题其实就是电池用完了不是驱动问题。第二步看内核日志。RTC驱动加载和报错都会打印在dmesg里。像rtc-rockchip驱动在probe失败时会打印具体的错误码比如-EPROBE_DEFER表示依赖的时钟或电源还没准备好-EIO表示寄存器读写失败。第三步是寄存器级排查。这一步需要芯片手册和i2c工具直接读原始寄存器数据确认驱动读到的值是否和硬件实际值一致。如果寄存器值正确但sysfs接口读出来不对问题定位在驱动如果寄存器值本身就不对问题定位在硬件或I2C通信时序。最后一步才轮到用户态工具排查。应用层用hwclock、date、rtc_selftests反复交叉验证排除工具本身使用方法错误。6. 从功能可用到稳定量产RTC的可靠性设计6.1 备用电池与低功耗设计RTC进入量产阶段后功耗和可靠性比单纯“能动”重要得多。RK3588内部RTC在备用电池供电状态下的电流消耗虽然寄存器只有几十微安级别的损耗但外围电路的漏电才是大头。我实测过有些板子的RTC备用电流高达几十微安一颗100mAh的纽扣电池几个月就耗尽了原因就是VBAT引脚到SoC之间的滤波电容漏电或者PCB表面受潮引起的漏电路径。低功耗设计要从硬件选型开始。VBAT引脚串一个0欧姆电阻作为调试断点方便量产时测电流电池正极到RTC的VBAT之间加防倒灌二极管或者使用带有电源切换功能的芯片避免系统主电源存在时给电池反向充电。BSP这一侧能做的事是确保驱动不主动唤醒RTC外设不把不必要的时钟域打开。我习惯在量产前的硬件测试阶段测量三组电流整机待机电流、RTC电池单独供电电流、主电源与电池同时存在时的电池端电流。第一组反映整机功耗第二组反映RTC电路本身第三组反映有没有倒灌。这三个数据都正常才敢说RTC低功耗设计过关。6.2 时间校准与批量生产注意批量产线上的RTC校准是另一个经常遇到的话题。晶振的初始频偏一致性并不好同一批次晶振的频偏分布可能从-20ppm到20ppm对应每天1.7秒的误差跨度。如果产品对时间精度有硬性要求比如某些计时付费场景就必须在产线上做校准。一种常见做法是产线上先用高精度时间源对时放置一定时间后读取偏差计算出ppm值写入RTC的偏移寄存器。Linux内核从4.x开始支持/sys/class/rtc/rtc0/offset接口可以写入以ppb为单位的校准值驱动会把这个值应用到每秒的计时上。写入正数表示RTC走慢了需要加速负数表示RTC走快了需要减慢。举例来说实测RTC偏差为每天快3秒希望校准到每天误差1秒以内。每天快3秒对应频率偏差约为3 / 86400 * 1e9 34722 ppb因为是走快了要减慢所以写入-34722echo -34722 /sys/class/rtc/rtc0/offset不过需要注意这个补偿的粒度取决于驱动支持有的芯片寄存器只有有限的补偿位数写进去之后实际生效的是一个量化值不能完全消除误差。量产工艺允许的情况下更稳妥的方案是直接选频偏小的晶振或者加TCXO省去批量校准的麻烦事。6.3 系统集成层面的最后收尾RTC调试到最后别忘了把用户态策略理顺。常见的问题场景是板子每次开机都从RTC恢复时间但RTC时间本身依赖上次关机时系统时间是否正确。如果系统时间被用户改错了又关机RTC就会存一个错误时间下次开机继续错。通用的解决思路是引入时间优先级策略。首次开机时如果没有外部时间源允许使用RTC的默认时间启动系统系统联网后通过NTP获取标准时间再刷写RTC。这个逻辑在系统脚本里实现大致流程是# 启动时判断RTC时间是否合理 RTC_YEAR$(date %Y) if [ $RTC_YEAR -lt 2024 ]; then echo RTC时间无效等待NTP同步 fi # 等待网络时间同步 timedatectl set-ntp true # 定期把系统时间写回RTC timedatectl set-local-rtc 1 hwclock -w这一套逻辑落地后用户不会再遇到时间越用越离谱的问题。我自己在项目里还会加一个后台监控任务每隔一小时做一次hwclock -w保证即使系统异常关机RTC里保存的时间也是最新的。最后再分享一点个人经验。RTC调试看起来简单但“简单功能不简单落地”才是BSP工作的常态。我见过不少人在RTC上翻车要么是看不懂时区要么是忽略了备用电池电路。如果你也在调RK3588或者类似的Linux平台建议一定按照这篇的思路把掉电测试、精度测试、闹钟测试完整走一遍特别是pinctrl和时区这两个点绝大多数RTC“灵异现象”都是从这里冒出来的。BSP调试系列后续我会继续写其他外设RTC这个起点踩扎实了后面的路会顺很多。
阅读完成 · 觉得有帮助？
