1. 从一次产线SN写不进去说起去年帮一家做智能硬件的客户处理产线问题他们的板子用的是MTK平台系统是Android 9.0产线工人用工具往Nvram里写SN号前几百台都正常突然有一批板子怎么都写不进去工具报错也含糊就一句write fail。换工具、换USB线、换电脑都试过问题依旧。后来抓了底层log才发现是Nvram的写保护机制在起作用——这批板子的Nvram分区被置了写保护标志普通写入接口直接被拦掉了。这个事让我意识到MTK平台的Nvram写保护机制虽然不是什么新东西但真正踩过坑的人不多网上能查到的资料要么太老要么语焉不详。所以我把整个排查过程和解决方案整理出来包括写保护的工作原理、怎么判断当前是否处于写保护状态、怎么安全地解除保护写入SN号、以及写完之后怎么恢复保护状态。内容会涉及MTK的Nvram分区结构、写保护标志位的存储位置、Android 9.0下的权限变化以及实际操作用的工具和命令。不管你是刚接触MTK平台的驱动工程师还是产线负责写号的测试人员或者只是好奇Nvram到底怎么回事的Android开发者这篇内容应该都能给你一些可以直接用的东西。我会尽量把原理讲透同时给出可复现的操作步骤让你看完就能上手。2. MTK Nvram分区到底存了什么2.1 Nvram在MTK平台中的角色定位MTK平台的NvramNon-Volatile Random Access Memory本质上是一块独立的存储分区用来保存那些掉电不能丢、但又不能随便让上层应用改的数据。你可以把它理解成PC主板上的CMOS只不过MTK把它做得更复杂里面分了很多个LIDLogical ID每个LID对应一类数据。具体来说Nvram里存的东西包括但不限于WiFi的MAC地址、蓝牙地址、IMEI号、SN号、校准参数比如RF校准数据、音频参数、摄像头模组的OTP信息等。这些东西有一个共同特点——每台设备都不一样而且必须在出厂前写入出厂后不应该被随意修改。SN号就是其中最典型的一个它是设备的唯一标识产线写号是必经环节。Android 9.0在MTK平台上对Nvram的访问做了更严格的限制。Android 8.0之前很多Nvram操作可以通过/dev/nvram设备节点直接读写但到了9.0SELinux策略收紧普通进程根本没有权限碰这个节点。产线工具通常是以native可执行文件的形式运行需要配合特定的权限配置才能正常工作。2.2 Nvram分区的物理布局与LID机制MTK的Nvram分区在eMMC里的位置是固定的通常紧跟在boot分区之后。分区内部不是一整块裸数据而是有一套自己的组织结构。简单来说它分为头部区域和数据区域两部分。头部区域记录了整个Nvram分区的元信息包括版本号、校验和、以及每个LID的偏移和长度。数据区域则是按LID划分的一个个独立块。每个LID有自己独立的读写接口MTK提供了一套nvram相关的库函数比如nvram_read、nvram_write上层工具通过这些接口来操作具体的数据。SN号通常存放在某个特定的LID里具体是哪个LID取决于项目配置。不同项目可能不一样有的放在LID_WIFI里有的单独开一个LID_SN。这个信息一般记录在项目的nvram配置文件里编译时确定。如果你不确定SN号存在哪个LID可以查项目的custom_nvram_extra_files或者nvram_agent相关配置。写保护机制就作用在这些LID上。MTK给每个LID或者整个Nvram分区提供了一个写保护开关一旦打开所有写入操作都会被拒绝返回一个特定的错误码。这个开关的状态存在Nvram头部的某个保留字段里或者存在一个单独的efuse区域。2.3 写保护标志位的存储位置与判断方法写保护标志位具体存在哪里MTK的文档里没有完全公开但根据实际调试经验它通常有两个可能的位置一个是Nvram头部的保留字段另一个是SoC内部的efuse。前者可以通过读取Nvram分区的前几个字节来判断后者需要用MTK的底层工具读取efuse寄存器。判断当前是否处于写保护状态最直接的方法是尝试写入一个测试数据看返回值。MTK的Nvram库函数在写保护开启时会返回NVRAM_WRITE_PROTECT之类的错误码。但这个方法有风险——万一写保护没开你就真的把数据写进去了。所以更稳妥的方式是先读后写先读一个已知LID的数据然后尝试写回同样的数据如果返回写保护错误说明保护是开的。另一个方法是直接读Nvram头部的标志位。用dd命令把Nvram分区的前512字节dump出来然后看特定偏移的值。具体偏移因平台而异MT6765、MT6768、MT6785这些常见平台写保护标志通常在偏移0x10附近。你可以对比一台已知写保护开启的设备和一台已知关闭的设备找出差异字节。注意直接dump Nvram分区需要root权限而且在Android 9.0上SELinux会阻止dd访问/dev/block/mmcblk0pXX。你需要先setenforce 0临时关闭SELinux或者用MTK的SP Flash Tool在BROM模式下读取。3. 写保护机制的工作原理与触发条件3.1 写保护不是简单的开关而是分层拦截很多人以为写保护就是一个布尔开关打开就全禁关闭就全放。实际在MTK平台上写保护是分层的。第一层是硬件层efuse里的保护位一旦烧录就不可逆这是最狠的通常只在量产最后阶段才烧。第二层是Nvram分区头部的软件保护位可以反复擦写产线常用这一层。第三层是SELinux和文件权限这是Android系统层的限制跟Nvram本身的写保护是两码事。产线写SN号时遇到的写不进去大概率是第二层在起作用。因为第一层一旦烧了整块Nvram就彻底锁死连MTK自己的工具都写不了那产线根本没法用。所以MTK默认出厂时第一层是关闭的只开第二层等所有写号、校准都完成后再决定是否烧第一层。第二层的写保护标志位在Nvram头部具体是一个字节的某个bit。MTK的Nvram库在初始化时会读取这个标志如果发现保护开启就把所有写操作的函数指针替换成空操作或者直接返回错误。这个替换是在库内部完成的上层工具感知不到只能看到写入失败。3.2 什么操作会触发写保护写保护不会无缘无故开启。根据我的经验以下几种情况会导致写保护被置位第一种是产线工具主动设置。有些产线流程里写号完成后会调用一个nvram_protect接口把写保护打开防止后续误操作。这个接口通常是MTK提供的nvram_write_protect_enable之类的函数。第二种是系统升级或恢复出厂设置。某些MTK平台的OTA升级包里会包含Nvram分区的镜像如果这个镜像里的写保护标志是开的升级后就会继承这个状态。恢复出厂设置一般不会动Nvram但如果恢复脚本里有重置Nvram的操作也可能触发。第三种是efuse烧录。如果产线在写号之前先烧了efuse那Nvram写保护就直接被硬件锁死了。这种情况比较少见但一旦发生基本只能换主板。第四种是异常掉电或写入中断。Nvram写入过程中如果突然断电可能导致头部标志位处于不确定状态有时候会误置为保护开启。这种情况下的保护状态可能不稳定重新上电后可能又变了。3.3 写保护开启后的错误表现写保护开启后不同的工具表现不一样。MTK官方的SP Flash Tool在写Nvram分区时会直接报错提示write protection enabled之类的信息。产线常用的SN_Writer工具可能只报一个通用的write fail不会告诉你具体原因。如果你用nvram命令行工具会看到返回码是-5或者0xFFFFFFFB对应NVRAM_WRITE_PROTECT。在kernel log里你会看到类似这样的信息[ 12.345678] (0)[1234:nvram_writer] nvram_write: LID 0x1A is write protected [ 12.345679] (0)[1234:nvram_writer] nvram_write: return -5如果你看到这种log基本可以确定是写保护在拦截。但要注意有些平台的log级别默认不打印这些你需要先把nvram相关的debug level调高。可以在/proc/nvram或者/sys/kernel/debug/nvram里找找有没有调试开关。4. 解除写保护并写入SN号的完整操作链路4.1 操作前的环境准备与风险确认在动手解除写保护之前有几件事必须先确认清楚。第一确认写保护是哪一层。如果是efuse层那没得解只能换板。判断方法用MTK的efuse工具读一下SECURE_BOOT或者NVRAM_PROTECT相关的efuse位如果已经烧了就别折腾了。第二确认SN号应该写到哪个LID。这个信息在项目的nvram配置里通常是LID_SN或者LID_WIFI不同项目不一样。第三备份当前Nvram分区。不管你要做什么先把整个Nvram分区dump出来存好万一操作失误还能恢复。环境方面你需要一台装了MTK USB驱动的Windows电脑或者一台配置好adb和fastboot的Linux电脑。工具方面MTK的SP Flash Tool是必须的用来在BROM模式下读写Nvram分区。另外SN_Writer工具或者MTK的nvram命令行工具用来实际写入SN号。如果你要在Android系统里直接操作还需要root权限和关闭SELinux。提示Android 9.0上关闭SELinux用setenforce 0但重启后会恢复。如果要持久关闭需要改boot.img里的cmdline加上androidboot.selinuxpermissive。这个操作有风险建议只在产线环境做。4.2 用SP Flash Tool读取并修改Nvram头部标志SP Flash Tool是MTK平台最底层的工具它可以在BROM模式下直接读写eMMC的任意分区不受Android系统和SELinux的限制。用它来解除写保护是最彻底的方式。具体步骤先把板子断电按住BROM模式进入键通常是音量上或者某个测试点然后插USB。SP Flash Tool识别到设备后选择Read Back功能添加一个读取任务起始地址填Nvram分区的起始地址长度填整个分区大小。Nvram分区的起始地址和大小在项目的scatter文件里有一般是nvram那一项。读出来之后用十六进制编辑器打开这个bin文件找到写保护标志位。前面说过通常在偏移0x10附近。你可以对比一台正常设备的Nvram dump找出差异。找到之后把那个字节改成0x00保存。然后回到SP Flash Tool选择Write Memory功能把修改后的bin文件写回Nvram分区。写完之后重新上电写保护应该就解除了。这个方法的好处是彻底、不依赖系统权限。坏处是操作繁琐而且每次都要拆机进BROM模式产线效率低。所以产线通常用另一种方法。4.3 在Android系统内通过nvram接口解除保护如果板子已经能正常开机而且你有root权限那可以在系统内直接操作。MTK在/system/bin或者/vendor/bin下提供了一个nvram命令行工具支持读写和设置保护状态。先看看工具支持哪些命令nvram --help通常会有read、write、protect、unprotect这些子命令。解除保护nvram unprotect如果这个命令不存在可以试试直接写Nvram头部的标志位。用dd命令# 先备份 dd if/dev/block/by-name/nvram of/sdcard/nvram_backup.bin # 读取头部 dd if/dev/block/by-name/nvram of/sdcard/nvram_head.bin bs512 count1 # 用hexedit或者busybox的hexdump查看 hexdump -C /sdcard/nvram_head.bin | head -20找到标志位后用dd写回# 假设标志位在偏移0x10要改成0x00 printf \x00 | dd of/dev/block/by-name/nvram bs1 seek16 convnotrunc写完之后重新加载Nvram驱动或者直接重启# 重新加载驱动 rmmod nvram insmod /vendor/lib/modules/nvram.ko或者直接reboot。重启后写保护应该就关了。注意/dev/block/by-name/nvram这个路径在不同平台上可能不一样有的是/dev/block/mmcblk0pXX。用ls -l /dev/block/by-name/看一下就知道。4.4 写入SN号并验证写保护解除后就可以写SN号了。用MTK的SN_Writer工具或者直接用nvram命令nvram write LID_SN SN1234567890如果LID_SN不对换成项目实际使用的LID。写完之后读回来验证nvram read LID_SN应该能看到刚才写入的SN号。如果读出来是空的或者不对说明写入没成功检查一下LID是否正确、写保护是否真的解除了。在Android系统里还可以通过getprop或者/proc节点验证。有些项目会把SN号映射到ro.serialno属性写完后getprop ro.serialno应该能看到新值。但注意这个属性是开机时从Nvram读的写完Nvram后需要重启才会更新。4.5 写完后恢复写保护状态SN号写完后建议把写保护重新打开防止后续误操作。用nvram protect命令或者把之前改的标志位改回去。如果你是用dd改的就再改回来printf \x01 | dd of/dev/block/by-name/nvram bs1 seek16 convnotrunc然后重启。重启后确认写保护已经生效尝试写一个测试数据应该返回写保护错误。产线环境通常会在所有写号、校准完成后统一烧efuse把硬件写保护也打开。这一步是不可逆的所以一定要确认所有数据都写完了再烧。5. 产线批量写号时容易踩的坑5.1 写保护状态不一致导致的批量失败产线最怕的就是一批板子里有几台写保护状态跟别的不一样。比如100台板子99台写保护是关的1台是开的那台就写不进去。如果产线工人没有逐台检查就会卡在那里。避免这个问题的方法是在写号之前统一检查写保护状态。可以写一个脚本用nvram命令读保护状态如果发现开启的就自动解除。MTK的SN_Writer工具通常支持批量模式可以在配置文件里加上unprotect_before_write1之类的选项让工具自动处理。另一个方法是产线流程标准化所有板子在写号之前先统一过一次unprotect操作不管当前状态如何都强制解除。这样虽然多了一步但能保证状态一致。5.2 Android 9.0 SELinux策略变化带来的权限问题Android 9.0比8.0在SELinux上严格了很多。以前nvram工具可以直接访问/dev/nvram9.0上默认策略是拒绝的。你需要给工具加上正确的sepolicy或者临时setenforce 0。如果产线工具是native可执行文件可以在file_contexts里给它打上nvram_exec之类的标签然后在nvram.te里允许它访问nvram_device。具体策略因平台而异MTK的BSP里通常有示例可以参考device/mediatek/sepolicy目录下的文件。临时方案就是setenforce 0但这不是长久之计。而且有些平台在setenforce 0之后nvram节点还是访问不了因为还有capability的限制。这种情况下需要给工具加上CAP_SYS_ADMIN之类的capability或者直接用root运行。5.3 Nvram写入过程中的掉电保护Nvram写入不是原子操作如果写到一半掉电可能导致数据损坏或者标志位异常。MTK的Nvram库在写入时会先擦除再写这个过程中掉电风险最大。产线环境通常有UPS但也不能完全避免。建议在写号之前先确认电量充足或者用带电池的板子。另外MTK的Nvram库支持write_with_verify模式写完会读回来校验如果校验失败会重试。可以在工具里开启这个选项增加可靠性。如果真的遇到掉电导致Nvram损坏可以用SP Flash Tool把之前备份的Nvram分区写回去。所以再次强调操作前备份Nvram分区是必须的。5.4 不同MTK平台的差异MT6765、MT6768、MT6785、MT6833这些平台Nvram的写保护机制大同小异但细节有差异。比如标志位的偏移可能不同nvram工具的路径可能不同SELinux策略也可能不同。我遇到过MT6768上nvram unprotect命令不存在的情况只能用dd直接改。也遇到过MT6833上Nvram分区名不是nvram而是nvdata的情况。所以操作之前先确认平台型号和分区名。平台Nvram分区名写保护标志偏移常用工具MT6765nvram0x10nvram, SN_WriterMT6768nvram0x10dd, SP Flash ToolMT6785nvram0x14nvram, SN_WriterMT6833nvdata0x10dd, SP Flash Tool这个表是根据我实际接触过的项目整理的不一定覆盖所有情况但可以作为参考。如果你不确定最稳妥的方法还是dump出来对比。6. 几个实际案例的排查过程6.1 案例一写号工具报错但log无异常有个客户反馈产线写号工具报write fail但抓kernel log没有任何Nvram相关的错误。这种情况通常是工具层的问题不是Nvram写保护。排查过程先确认工具是否有权限访问Nvram节点。用strace跟踪工具的系统调用看它到底卡在哪一步。结果发现工具在open(/dev/nvram)时就失败了返回EACCES。这是SELinux在拦截不是写保护。解决方案给工具加上正确的SELinux标签或者临时setenforce 0。改完之后工具就能正常打开节点写号成功。这个案例说明写号失败不一定是写保护也可能是权限问题。排查时要先看loglog里没有写保护错误就不要往写保护方向想。6.2 案例二写保护解除后重启又恢复另一个客户遇到的问题是用nvram unprotect解除保护后写号成功但重启后写保护又自动恢复了。这是怎么回事排查过程检查Nvram头部的标志位发现重启后被改回了保护状态。进一步查发现是init.rc里有一个服务开机时会调用nvram protect。这个服务是MTK默认加的目的是防止Nvram被意外修改。解决方案要么把这个服务禁掉要么在写号流程里每次开机后先unprotect再写。产线通常选择后者因为改init.rc需要重新编译boot.img比较麻烦。这个案例说明写保护状态可能被开机流程重置操作前要确认有没有这种自动保护的服务。6.3 案例三efuse已烧导致无法写入最坏的情况是efuse已经烧了。有个客户的板子是返修品之前产线已经烧了efuse现在要改SN号怎么都写不进去。排查过程用MTK的efuse工具读NVRAM_PROTECT位发现已经是0x1。这是硬件级的写保护软件无法解除。解决方案只能换主板。或者如果只是要改SN号可以尝试改上层显示的SN不动Nvram里的。比如改ro.serialno属性或者改/proc节点的映射。但这种方法不彻底有些应用会直接读Nvram改属性没用。这个案例说明操作前一定要确认efuse状态否则白忙活。7. 写保护机制背后的设计逻辑与个人体会MTK搞这么一套写保护机制不是为了给开发者添麻烦而是有实际考虑的。Nvram里存的是设备的身份信息和校准数据这些东西一旦被篡改轻则设备功能异常重则整个网络出问题。比如IMEI号如果被随意修改会影响运营商网络RF校准数据如果被改可能导致射频指标超标干扰其他设备。所以MTK在Nvram的读写上做了多层防护硬件efuse是最底层一旦烧录不可逆软件写保护是中间层可以灵活开关SELinux是系统层防止上层应用乱来。这三层配合既保证了产线能正常写号又防止了出厂后被乱改。从实际使用角度我的体会是产线写号一定要标准化流程。不要指望工人手动判断写保护状态而是用脚本或者工具自动处理。每次操作前备份Nvram操作后验证写入结果最后恢复保护状态。这套流程看起来繁琐但能避免99%的问题。另外不同平台的差异一定要提前确认。不要拿MT6765的经验直接套到MT6833上分区名、偏移、工具路径都可能不一样。最稳妥的方法是先dump一台正常设备的Nvram对比着看。最后分享一个小技巧如果你不确定写保护标志位在哪可以拿两台设备对比——一台写保护开启一台关闭分别dump Nvram头部用cmp或者diff找出差异字节。这个差异字节大概率就是标志位。这个方法虽然笨但很有效我在好几个平台上都用过。