Skip to content

otpset: Fix reading OTP on BCM2712 - #219

Open
YORROY123 wants to merge 1 commit into
raspberrypi:masterfrom
YORROY123:otpset-bcm2712
Open

YORROY123 wants to merge 1 commit into
raspberrypi:masterfrom
YORROY123:otpset-bcm2712

Conversation

@YORROY123

Copy link
Copy Markdown
Contributor

On Pi 5 / CM5, vcgencmd otp_dump starts at row 00, skips rows 61-76 and 93-108, and uses three digit row numbers from 109 up. ReadOTP assumes the dump starts at row 08, is contiguous and that every row number has two digits (val[3:]), so on BCM2712:

  • otpset -c and otpset -p crash:
    File "/usr/bin/otpset", line 72, in ReadOTP
      result[i] = int(val[3:], base=16)
    ValueError: invalid literal for int() with base 16: b':19a519a6'
    
  • before the crash, otpset -c prints dump rows 28-35 as customer rows 0-7. On the CM5 below that shows the serial number as customer row 3 and the revision code as customer row 4, while the real customer OTP is all zero:
    $ sudo otpset -c
    ...
    3 0xea44e26e b'11101010010001001110001001101110
    4 0x00c04180 b'00000000110000000100000110000000
    ...
    $ sudo vcmailbox 0x00030021 40 40 0 8 0 0 0 0 0 0 0 0
    0x00000040 0x80000000 0x00030021 0x00000028 0x80000028 0x00000000 0x00000008 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
    

This PR:

  • parses the row number from each <row>:<value> line instead of using the line index
  • reads the customer rows with the documented mailbox call (0x00030021) instead of assuming where they sit in the dump
  • drops the BCM2711 row labels (Serial number, Revision code, ...) on BCM2712, where those rows hold other data

Tested on a CM5 (Compute Module 5 Rev 1.0, revision c04180, raspi-utils 20251120-1, Debian trixie):

Command Before After
otpset -c wrong rows, then ValueError 8 rows, all zero, matches the mailbox read
otpset -p ValueError all 83 rows (0-60, 77-92, 109-114), exit 0
otpset -f -c / otpset -f -p byte-identical to before
otpset -c / -p without sudo (user in video) works
otpset -v -r 0 0x1 (dry run) unchanged

I don't have a Pi 4 to hand, so the BCM2711 path is only covered by --fake; the mailbox read for -c is the one the OTP documentation gives for all models.

🤖 Generated with Claude Code

On Pi 5 / CM5, `vcgencmd otp_dump` starts at row 00, skips rows
61-76 and 93-108, and has three digit row numbers from 109 up.
ReadOTP assumed the dump starts at row 08, is contiguous and that
every row number has two digits, so:

- `otpset -c` and `otpset -p` crash with
  "ValueError: invalid literal for int() with base 16: b':19a519a6'"
- before crashing, `otpset -c` prints rows 28-35 as customer rows
  0-7, which on CM5 includes the serial number and revision code,
  while the real customer OTP is all zero

Parse the row number from each "<row>:<value>" line instead of the
line index, read the customer rows with the documented mailbox call
(0x00030021) rather than assuming where they are in the dump, and
drop the BCM2711 row labels on BCM2712 where they don't apply.

Output with --fake is unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Roy <rongh7426@gmail.com>
@YORROY123

Copy link
Copy Markdown
Contributor Author

Also checked on a Pi 5, which has a newer package than the CM5 above (Raspberry Pi 5 Model B Rev 1.1, revision e04171, raspi-utils-otp 20260626-1, Debian trixie). Read-only commands only.

Command /usr/bin/otpset (20260626-1) this PR (cbe8ccc)
sudo otpset -c rows 3/4/7 print 0x804afa61 / 0x00e04171 / 0xcec00454 (serial cec00454804afa61, revision e04171), then ValueError 8 rows, all zero, same as vcmailbox 0x00030021
sudo otpset -p ValueError after row 60 83 rows (0-60, 77-92, 109-114), exit 0
otpset -c without sudo (user in video) exit 0

So the crash is still there in the current package, and the same fix covers both BCM2712 boards I have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant