Summary
The ARK carriers' serial-number EEPROM (AT24CSW010, I2C1 = i2c-7, memory at 0x50, serial in the security register at 0x58) is not in the device tree. ARK-OS reads it from userspace with smbus2 (platform/jetson/scripts/jetson_serial_number.py: bus 7, address 0x58, dummy write 0x80, 16 bytes). Bringing it under the kernel is a cleanliness change, not a bug fix, and it has to land together with an ARK-OS change.
Why
- The L4T at24 driver already supports the part:
compatible = "atmel,24cs01" at reg = <0x58> handles the serial register, including the 0x80 word-address sequence, and exposes 16 read-only bytes at /sys/bus/i2c/devices/7-0058/eeprom and as an nvmem provider.
- The read becomes one file read in a single I2C transaction, with no root or Python dependency.
- The tree then describes the carrier's identity part, as the module's own EEPROM (
eeprom@50 on i2c-0) already is.
What has to change, in order
- ARK-OS:
jetson_serial_number.py reads the sysfs file (or the nvmem cell) and falls back to the current smbus2 path when the node is absent, so one script works on both images. Add a udev rule if the file must be readable without root.
- ark_jetson_kernel: add
eeprom@58 { compatible = "atmel,24cs01"; reg = <0x58>; label = "carrier-serial"; read-only; } under i2c@c250000 in the PAB, PAB_V3 and JAJ overrides.
In the same change, delete the inherited devkit node: /delete-node/ eeprom@57; under i2c@3160000. That is the p3768 carrier's board-ID EEPROM (label system); no ARK carrier has a part there, so today it is only an at24 probe failure in dmesg on every boot. The module's own eeprom@50 on i2c@3160000 stays.
- Ship the ARK-OS release before or with the image; ark-bench's carrier tests and the bundle flow call the ARK-OS script and record its output as the unit's internal serial.
Caution
Once the kernel binds 0x58, smbus2's plain I2C_SLAVE open on that address returns EBUSY. An image with the node and an ARK-OS without step 1 reports every carrier serial as unknown.
Summary
The ARK carriers' serial-number EEPROM (AT24CSW010, I2C1 =
i2c-7, memory at 0x50, serial in the security register at 0x58) is not in the device tree. ARK-OS reads it from userspace withsmbus2(platform/jetson/scripts/jetson_serial_number.py: bus 7, address 0x58, dummy write 0x80, 16 bytes). Bringing it under the kernel is a cleanliness change, not a bug fix, and it has to land together with an ARK-OS change.Why
compatible = "atmel,24cs01"atreg = <0x58>handles the serial register, including the 0x80 word-address sequence, and exposes 16 read-only bytes at/sys/bus/i2c/devices/7-0058/eepromand as an nvmem provider.eeprom@50oni2c-0) already is.What has to change, in order
jetson_serial_number.pyreads the sysfs file (or the nvmem cell) and falls back to the currentsmbus2path when the node is absent, so one script works on both images. Add a udev rule if the file must be readable without root.eeprom@58 { compatible = "atmel,24cs01"; reg = <0x58>; label = "carrier-serial"; read-only; }underi2c@c250000in the PAB, PAB_V3 and JAJ overrides.In the same change, delete the inherited devkit node:
/delete-node/ eeprom@57;underi2c@3160000. That is the p3768 carrier's board-ID EEPROM (labelsystem); no ARK carrier has a part there, so today it is only an at24 probe failure in dmesg on every boot. The module's owneeprom@50oni2c@3160000stays.Caution
Once the kernel binds 0x58,
smbus2's plainI2C_SLAVEopen on that address returnsEBUSY. An image with the node and an ARK-OS without step 1 reports every carrier serial asunknown.