casaroli opened a new pull request, #19532:
URL: https://github.com/apache/nuttx/pull/19532
## Summary
The rp2350 holds 4096 rows of 24 bit one-time-programmable memory, which the
port did not expose at all, although `hardware/rp23xx_otp.h` and
`hardware/rp23xx_otp_data.h` have been in tree unused. This adds a driver on
the NuttX efuse interface, registered by the common board bringup as
`/dev/efuse`.
**Addressing.** The driver uses the ECC interpretation of a row, in which 16
bits carry data and the remaining 8 carry a Hamming code. The OTP therefore
appears as a flat space of 4096 * 16 bits for the efuse field descriptors to
index: a descriptor at bit offset N refers to bit `N % 16` of row `N / 16`.
That lines up with the row numbers already listed in `rp23xx_otp_data.h`, so
a
field can be described directly from the constants there.
**Reads** come from the chip's ECC-translated window and have no side
effects;
single bit errors are corrected in hardware. Rows are locked in pages of 64,
and reading a page that is locked against reads raises a bus fault, so the
driver checks the lock first and reports `EPERM` instead of faulting.
**Programming** requires the separate `RP23XX_OTP_WRITE` option, which
defaults
to off; with it off a write returns `EPERM` and no programming code is
compiled
in at all. When enabled, a row is programmed as a whole through the bootrom
`OTP_ACCESS` entry point, because the ECC bits cover the whole row. For the
same reason a row that already holds data cannot be modified, and the driver
rejects such a write rather than leaving it to corrupt the row's ECC.
## Impact
- New feature, opt-in via `CONFIG_RP23XX_OTP` (default n, selects `EFUSE`).
No
change to existing behavior when disabled.
- Arch: `arm` (rp23xx / RP2350). Boards: rp23xx common bringup registers
`/dev/efuse` when the option is enabled.
- No new external dependencies, no ABI/API changes beyond the new Kconfig
symbols and the new device node.
- Documentation: an OTP section and a peripheral-table row were added to
`Documentation/platforms/arm/rp23xx/index.rst`.
## Testing
**Hardware:** RP2350 board (Pimoroni Pico Plus 2), `raspberrypi-pico-2:nsh`
plus `RP23XX_OTP`. Programmed over SWD with a Raspberry Pi Debug Probe
(probe-rs); console on UART0.
### Read path, on hardware
Exercised with a small read-only application that issues
`EFUSEIOC_READ_FIELD`:
- `/dev/efuse` registers at boot.
- **Multi-row field:** the 64 bit chip identifier in rows 0-3 reads back as
`49a98f93d781c687`, which is exactly what the four individual row reads
compose to (`0xc687`, `0xd781`, `0x8f93`, `0x49a9`). The 64 bits of the
random identifier in rows 4-7 likewise agree with their individual rows.
- **Sub-row field:** bits 3:0 of row 0 read `0x7`, the low nibble of the
`0xc687` held in that row, confirming the bit offset and masking.
- **Range checking:** a descriptor past the end of the array is rejected
rather
than read.
- **Independent cross-check:** the same eight rows were read over SWD from
the
*raw* OTP window (`0x40134000`, which exposes all 24 bits). All eight match
the driver's ECC-decoded values, and the upper bytes hold the Hamming
codes,
confirming the ECC interpretation is the right one.
### Programming path, deliberately not exercised
The write path is **implemented but has not been run on hardware**, because
programming is irreversible and would permanently consume fuses on the test
board. Reviewers should weigh it accordingly. What was verified:
- It compiles: a build with `CONFIG_RP23XX_OTP_WRITE=y` links cleanly.
- With the option off (the default, and the configuration flashed for the
test
above) the programming code is genuinely absent, not merely unused: the OTP
object's only external references are `efuse_register` and `memset`, the
linked image contains no reference to the bootrom OTP entry point, and
`rp23xx_otp_write_field` compiles down to `mov r0, #-1; bx lr`.
- `EFUSEIOC_WRITE_FIELD` returns `EPERM` on the test board, and the row the
test aimed at was afterwards confirmed still blank by reading it over SWD.
`tools/checkpatch.sh -f` (nxstyle) and `-g` (patch + commit message) pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
