ATSHA204A加密芯片Linux驱动源码：I2C挑战响应与产线落地

简介：面向 Linux 内核与嵌入式安全开发者的 ATSHA204A 加密芯片驱动源码，聚焦 I²C 接口下 SHA-256 认证芯片在内核中的接入与控制，适合需要为设备补上硬件身份认证、密钥存储与数据防篡改能力的中高级开发者参考。压缩包共 12 个文件，约 32KB，以 6 个 C 头文件与 4 个 C 源文件为主体，分别承担寄存器与命令定义、I²C 收发、API 封装及模块初始化，另附 Makefile 与 Kconfig，便于按内核模块方式编译裁剪。已有 486 人学习。源码按模块分层组织，将底层总线操作、芯片命令封装与对外接口拆开，可直接对照理解驱动注册、ioctl 访问、返回值处理与错误分支；配合配置项与构建脚本，能快速把驱动编入内核或独立模块，并在此基础上扩展认证流程与上层调用，节省从零搭建安全芯片驱动的时间。

1. 一颗 8 脚加密芯片的驱动源码：先别急着编译，先看它怎么被内核识别

拿到一份加密芯片 atsha204a linux 驱动源码，很多人第一反应是make一下插上板子；我一般先翻设备树和probe函数，因为这类芯片翻车点不在编译，而在上电时序、I2C 地址和配置区锁定。ATSHA204A 不是通用加密加速器，它更像一个带 SHA-256 挑战响应、少量 EEPROM 和一次性可编程区的认证从机，适合做设备身份、密钥槽位和随机数源。这类 linux 安全 软件/插件 的源码包，价值不在多一个设备节点，而在把密钥操作收进受控路径。下面按源码结构、编译加载、挑战响应、避坑和产线闭环拆开讲，新手能照着跑，熟手能直接看边界。

2. 驱动源码拆开看：I2C 命令包、CRC 与 hwrng 注册的三个边界

2.1 源码目录与模块边界

一份能落地的 ATSHA204A 驱动源码，常见做法是拆成 core 和 bus 两层：core 负责命令组包、CRC、槽位读写和 hwrng 注册，bus 层只处理 I2C 收发。这样换到别的总线上不用重写业务逻辑。拿到源码后先看文件职责，不要急着改probe。

驱动入口通常是一个i2c_driver，probe里做三件事：取设备树参数、初始化互斥锁、注册 hwrng 或 sysfs。下面这段是常见骨架，重点看of_match_table和devm_hwrng_register的位置。

static const struct of_device_id atsha204a_of_match[] = { { .compatible = "vendor,atsha204a" }, { } }; MODULE_DEVICE_TABLE(of, atsha204a_of_match); static int atsha204a_probe(struct i2c_client *client) { struct atsha204a *chip; int ret; chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) return -ENOMEM; chip->client = client; mutex_init(&chip->lock); i2c_set_clientdata(client, chip); ret = atsha204a_init_chip(chip); /* 读 DevRev、校验状态 */ if (ret) return ret; ret = devm_hwrng_register(&client->dev, &chip->rng); if (ret) dev_warn(&client->dev, "hwrng register failed: %d\n", ret); return 0; }

这段代码的逻辑是先把芯片私有数据挂到i2c_client上，再初始化硬件，最后注册 hwrng。参数上要注意：devm_hwrng_register失败不一定要让probe整体失败，因为有些产品只用挑战响应，不用随机数；但atsha204a_init_chip失败必须返回，否则后面读写都会落在未初始化的状态上。compatible字符串必须和板级设备树完全一致，大小写和厂商前缀都别抄错。

2.2 设备树与 I2C 地址匹配

ATSHA204A 的 I2C 从机地址常见是 7 位0x64。设备树里的reg写 7 位地址，不要写左移后的0xC8。有些平台在i2c_new_device的板级信息里用 8 位地址，那是旧式写法，和设备树混用最容易出现“probe成功但读不到”的玄学问题。

&i2c1 { status = "okay"; clock-frequency = <100000>; atsha204a: crypto@64 { compatible = "vendor,atsha204a"; reg = <0x64>; wake-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>; status = "okay"; }; };

这段设备树的参数要逐个对：reg = <0x64>是 7 位地址；clock-frequency先按 100kHz 跑，别一上来就 400kHz，芯片能上更高频率不代表你的走线和上拉能跟上；wake-gpios是可选项，有些模块用 SDA 上的 wake token 唤醒，不占用 GPIO，源码里如果没实现 GPIO 唤醒，这个属性会被忽略。compatible必须和驱动of_match_table对上，后面避坑章节会专门讲这个。

2.3 命令包、CRC 与看门狗

ATSHA204A 的 I2C 传输不是“读寄存器”模型。主机先发一个 word address0x03，再发 count，再发命令字和参数，最后两个字节是 CRC。很多驱动把0x03当成寄存器地址写进i2c_master_send，结果芯片返回 NACK，看日志像是 I2C 不通，其实是包格式错了。

static int atsha204a_send_cmd(struct atsha204a *chip, u8 opcode, const u8 *param, size_t len) { u8 tx[ATSHA204A_CMD_MAX]; u8 rx[ATSHA204A_RSP_MAX]; int ret; if (len > ATSHA204A_PARAM_MAX) return -EINVAL; mutex_lock(&chip->lock); tx[0] = 0x03; /* I2C word address */ tx[1] = len + 1; /* count: opcode + param */ tx[2] = opcode; memcpy(&tx[3], param, len); /* 末尾两字节填 CRC，源码包里通常有 crc16 表 */ atsha204a_crc16(tx, len + 3, &tx[len + 3]); ret = i2c_master_send(chip->client, tx, len + 5); if (ret < 0) goto out; usleep_range(1000, 2000); /* 给芯片留执行时间 */ ret = i2c_master_recv(chip->client, rx, sizeof(rx)); out: mutex_unlock(&chip->lock); return ret; }

这段代码的关键参数：tx[0] = 0x03是 I2C 模式的 word address，不是芯片内部寄存器；count是命令字加参数字节数，别把 CRC 算进去；usleep_range(1000, 2000)是给命令执行留窗口，具体值看源码包里的时序宏。芯片内部有看门狗，命令后如果长时间不操作会复位，所以连续读写之间要么发休眠，要么在超时前发下一条命令。血泪经验是：不要在外面套一层“失败就立刻重试”的循环，重试前先发 wake token，否则越重试越 NACK。

3. 把驱动编译进内核：Kconfig、交叉编译与首个自检节点

3.1 内核配置与 Makefile

源码包如果带Kconfig，先把它挂到drivers/crypto/或drivers/char/hw_random/下，再在上一级Kconfig里source进去。常见配置项写成三态，依赖I2C，并select HW_RANDOM。不要默认select CRYPTO_SHA256，因为 ATSHA204A 的 SHA 只服务于挑战响应，不是通用哈希加速器，选多了只会让内核变大。

config ATSHA204A tristate "ATSHA204A crypto authentication chip" depends on I2C select HW_RANDOM help Driver for the ATSHA204A I2C crypto authentication chip. Provides device authentication and a hardware random source.

obj-$(CONFIG_ATSHA204A) += atsha204a.o atsha204a-objs := atsha204a_core.o atsha204a_i2c.o

这段Kconfig的逻辑是声明三态和依赖，select HW_RANDOM保证 hwrng 框架在。参数上注意：如果产品只用 sysfs 挑战响应，可以把select HW_RANDOM去掉，改成运行时可选的注册；obj-$(CONFIG_ATSHA204A)必须和配置项名字完全一致，大小写错了不会报错，只会静默不编译。atsha204a-objs的顺序会影响链接顺序，但一般不影响功能。

内核配置里还要确认几项：

3.2 交叉编译与加载

在 x86 上给 ARM 板子编译，最稳的是外部模块方式，先确认目标内核的构建目录可用。下面命令里的ARCH、CROSS_COMPILE和KDIR三个参数必须和板子内核一致，否则编出来的.ko会提示version magic不匹配。

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ -C /path/to/kernel M=$PWD modules scp atsha204a.ko root@target:/tmp/ ssh root@target insmod /tmp/atsha204a.ko dmesg | tail -n 30

这段命令的逻辑是先进入目标内核构建目录，用M=$PWD指向当前源码目录编译外部模块。参数说明：ARCH=arm64要和目标一致；CROSS_COMPILE是工具链前缀，末尾带-；KDIR必须是有.config和Module.symvers的构建目录。加载后先看dmesg有没有probe日志，不要只看lsmod，模块加载成功不代表probe成功。

3.3 读序列号与自检

自检顺序我一般分三步：先看 I2C 总线上有没有0x64，再看驱动有没有绑定，最后读序列号或 DevRev。i2cdetect可以用，但要知道它会对总线发探测包，某些时序敏感的板子上可能干扰芯片，生产环境别随手跑。

i2cdetect -y 1 ls -l /sys/bus/i2c/devices/1-0064/ cat /sys/bus/i2c/devices/1-0064/name dmesg | grep -i atsha

这段命令的逻辑是先确认地址存在，再确认 sysfs 设备节点，最后看驱动日志。参数上-y跳过交互确认，1是 I2C 总线号，实际以板子为准；1-0064里的1是总线号，0064是地址。如果i2cdetect能看到0x64但/sys/bus/i2c/devices/1-0064/不存在，多半是设备树没编进 DTB 或compatible不匹配；如果节点存在但没有driver链接，说明probe没成功，回去看dmesg的第一条错误。

提示：第一次上板先不要写配置区，只读 DevRev 和序列号。配置区一旦锁定不可逆，开发阶段用未锁定样品。

4. 挑战响应跑通：sysfs 二进制属性、密钥槽位与用户态封装

4.1 配置区与数据区的权限模型

ATSHA204A 的存储分成配置区、数据区、OTP 区和临时 SRAM。配置区决定每个槽位的读写权限、是否加密、是否可清除；数据区放密钥和用户数据；OTP 区一次性可编程；SRAM 放临时 nonce 和响应。驱动源码里如果只实现“读写 EEPROM”，没有处理权限位，用户态很容易写出“开发板能读、量产板读不了”的代码。

挑战响应的最小闭环是：主机发一个随机 challenge，芯片用指定槽位的密钥做 HMAC 或 SHA 运算，返回 response，主机用同样密钥验证。驱动不需要理解业务，只要把 challenge 写进去、把 response 读出来，并保证并发安全。

4.2 sysfs 二进制属性的读写

用DEVICE_ATTR_RW做文本属性很方便，但 challenge 和 response 是二进制，必须用bin_attribute。下面这段是常见写法，重点看count校验和锁的范围。

static ssize_t challenge_write(struct file *filp, struct kobject *kobj, struct bin_attribute *attr, char *buf, loff_t off, size_t count) { struct atsha204a *chip = dev_get_drvdata(kobj_to_dev(kobj)); if (off != 0 || count != ATSHA204A_CHALLENGE_SIZE) return -EINVAL; mutex_lock(&chip->lock); memcpy(chip->challenge, buf, count); chip->challenge_valid = true; mutex_unlock(&chip->lock); return count; } static struct bin_attribute challenge_attr = { .attr = { .name = "challenge", .mode = 0200 }, .write = challenge_write, .size = ATSHA204A_CHALLENGE_SIZE, };

这段代码的逻辑是把用户态写入的 32 字节 challenge 缓存到驱动私有数据里，等 response 读取时再触发芯片运算。参数上off != 0拒绝分段写，count != 32直接返回-EINVAL，避免用户态用echo写字符串把长度搞错；mode = 0200只允许写，response 属性另外用0400只读。锁只包住缓存更新，真正的 I2C 命令放到 response 读路径里，避免写属性时长时间占住总线。

注意：sysfs 属性名以你拿到的源码为准，常见是challenge、response、serial，不要硬编码到产线脚本里，先ls一遍。

4.3 用户态挑战响应脚本

用户态封装不要用 shell 的echo写二进制，换行符会多一个字节。下面脚本按challenge可写、response可读来写，实际路径按你的驱动节点改。

import os import binascii base = "/sys/class/atsha204a/atsha204a0" challenge = os.urandom(32) with open(f"{base}/challenge", "wb", buffering=0) as f: f.write(challenge) with open(f"{base}/response", "rb", buffering=0) as f: response = f.read() print("challenge:", binascii.hexlify(challenge).decode()) print("response :", binascii.hexlify(response).decode())

这段脚本的逻辑是生成 32 字节随机 challenge，写入 sysfs，再读回 response。参数上buffering=0避免 Python 缓冲把一次写拆成多次；os.urandom(32)只用于测试，生产环境应该由主控的 TRNG 或 ATSHA204A 自己的随机数命令产生 challenge。并发场景下要在应用层加文件锁或串行队列，驱动里的 mutex 只能保证单次命令不交错，不能保证“写 challenge 和读 response 之间”不被另一个进程插入。

5. 避坑与排查：五个“能加载但不工作”的细节

5.1 现象：probe 成功但第一次 read 超时

现象是insmod成功，dmesg里也有probe日志，但用户态第一次读 response 就超时，i2c_master_recv返回-ETIMEDOUT。原因通常不是驱动没绑定，而是命令包格式或上电时序不对：ATSHA204A 在 I2C 模式下要先发 word address0x03，再发 count 和命令字，末尾带 CRC；有些源码把0x03当寄存器地址，芯片收到的包长度不对，直接不响应。另一个常见原因是唤醒：芯片处于 sleep 状态时，第一次访问要先发 wake token 或拉wake-gpios，驱动probe里没做唤醒，读命令就落在睡眠窗口里。

解决方法是先用逻辑分析仪或i2c-tools抓一帧，确认tx[0]是0x03、tx[1]是 count、最后两字节是 CRC；再确认probe后有没有发唤醒。没有逻辑分析仪时，临时在atsha204a_send_cmd里打印tx的前几个字节，和源码包头文件里的命令宏对一遍。超时重试不要立刻重发同一条命令，先发 wake，再延时，再重试；否则芯片看门狗复位，日志会变成一串 NACK。

5.2 现象：配置区锁定后开发板变砖

现象是开发阶段读写都正常，执行一次 LockConfig 后，同一块板子再也读不出密钥，换驱动也不行。原因是配置区锁定不可逆，锁定后槽位权限、I2C 地址和 OTP 模式都固定，原来“先写后锁”的测试流程如果顺序错了，密钥槽位可能被设成不可读或需要加密读。更隐蔽的是，有些源码包的测试脚本默认“写完就锁”，在开发板上跑一次就把样品废了。

解决方法是开发阶段只用未锁定样品，锁定前先读回配置区做模板比对；量产前把“写配置、读回校验、锁配置、再读回校验”做成四步，任何一步失败都停在当前步，不要继续。配置模板要版本化，别在产线现场手改权限位。如果已经锁错，只能换芯片，没有后悔药；所以我在probe里加一条日志，把配置区锁定状态打出来，至少知道当前样品处于哪一步。

5.3 现象：hwrng 注册失败或质量低

现象是devm_hwrng_register返回-ENODEV或-EEXIST，或者注册成功但/dev/hwrng读出来的随机数被上层判为质量低。原因是内核没开CONFIG_HW_RANDOM，或者 hwrng 名字和已有设备冲突；质量低通常是驱动把 ATSHA204A 的随机数命令返回值直接透传，没有处理状态字节和 CRC，偶尔把错误码当随机数喂给框架。

解决方法是先看dmesg里 hwrng 注册的返回码，再确认CONFIG_HW_RANDOM=y或模块已加载；名字冲突就改rng.name，不要硬抢。质量问题上，读随机数命令后先校验 response 的状态字节和 CRC，失败就返回-EIO，不要返回半截缓冲区。hwrng 的quality值别拍脑袋写 1000，ATSHA204A 的随机源适合做种子和挑战 nonce，不适合当高吞吐熵源，写 500 到 700 更稳妥。

5.4 现象：多进程并发返回 NACK

现象是单进程测试全过，一上多进程就偶发 NACK 或 response 错位。原因是 ATSHA204A 的命令之间有时序窗口，驱动里如果只在send_cmd内部加锁，用户态“写 challenge”和“读 response”是两次独立系统调用，中间可能被另一个进程插入一条命令，芯片状态机就乱了。另一种情况是命令后延时不够，前一条命令还没执行完，下一条就来了。

解决方法是在驱动里把“一次挑战响应”做成一个原子操作，比如提供challenge_response属性，一次写入 challenge 并返回 response，而不是拆成两个属性；如果必须拆，就在应用层用文件锁把两次调用包住。驱动内部的重试逻辑要加退避，失败后先 wake 再延时，不要忙等。并发测试至少跑 1000 次，观察 NACK 是否随并发数上升；如果单进程也偶发，优先查时序和 CRC，不要先怀疑芯片坏。

5.5 现象：设备树 compatible 不匹配

现象是 I2C 地址能看到，/sys/bus/i2c/devices/1-0064/也存在，但没有driver链接，dmesg里没有probe日志。原因是设备树compatible和驱动of_match_table不一致，常见是厂商前缀写错、大小写不一致，或者源码包里示例用的是vendor,atsha204a，板级 DTS 写成了atmel,atsha204a。这种问题不会报编译错误，只会静默不绑定。

解决方法是grep -r "compatible"把驱动和设备树两边对一遍，再用cat /sys/bus/i2c/devices/1-0064/of_node/compatible看实际值；如果内核开了CONFIG_OF_OVERLAY，确认 overlay 真的应用了。绑定成功后/sys/bus/i2c/devices/1-0064/driver会指向驱动目录，这是最快的自检点。别靠猜，字符串匹配是硬规则。

6. 进阶：把 ATSHA204A 做成产线可信根的最小闭环

6.1 密钥槽位最小化配置

产线闭环的第一步不是写脚本，而是把槽位权限压到最小：只开一个认证密钥槽，读权限设成需要加密读或不可读，写权限在烧录后关闭；OTP 区只放生产批次和序列号，不放密钥。配置模板先在未锁定样品上跑通，读回配置区做二进制比对，再进量产。这样做的好处是即使主机侧 linux 安全 软件/插件 被替换，密钥也不会以明文形式从芯片里读出来。

6.2 量产烧录与自检脚本

烧录脚本不要直接调i2cset，ATSHA204A 不是寄存器模型。用驱动暴露的 sysfs 属性或源码包自带的用户态工具，先读 DevRev 和序列号，再写配置，再读回校验，最后锁配置。下面是一个最小的自检骨架，具体属性名按你的源码改。

#!/bin/sh set -e BASE=/sys/class/atsha204a/atsha204a0 # 1. 读序列号，确认芯片在位 [ -r "$BASE/serial" ] || { echo "no serial node"; exit 1; } od -An -tx1 "$BASE/serial" # 2. 写配置前先备份当前配置区 [ -r "$BASE/config" ] && od -An -tx1 "$BASE/config" > /tmp/config.bak # 3. 写配置模板并读回比对 cat /tmp/config.bin > "$BASE/config" cmp /tmp/config.bin "$BASE/config" # 4. 锁定配置区，锁定后不可逆 echo 1 > "$BASE/lock_config"

这段脚本的逻辑是“先确认在位，再备份，再写，再比对，最后锁定”。参数上set -e保证任何一步失败就停，避免半锁状态；cmp比的是二进制，不要用diff看文本；lock_config的写入值以源码为准，有的驱动用1，有的用lock字符串。量产时把脚本做成幂等，重复执行先判断锁定状态，已锁定就跳过写配置。

6.3 验证方法与边界

验证分三层：总线上能看到0x64，驱动能绑定并读出序列号，挑战响应的 response 能被主机侧同样密钥验证通过。三层都过，再把板子断电重启跑一遍，确认配置区没有因为看门狗或上电时序丢状态。边界也要清楚：ATSHA204A 的 SHA 吞吐不适合做大数据哈希，hwrng 适合做种子而不是高吞吐熵源，挑战响应适合设备身份而不是通用加密通道。从那以后我每次改配置区之前都强制走一遍“未锁定样品 + 读回比对 + 断电重启”，希望帮到你。

本文还有配套的精品资源，点击获取