Hardware and
host interfaces.

01 / R90-DIRECT

USB / CP2112

The CP2112 bridges USB HID transfers to I²C. The host implements the RNG90 command protocol; the board has no application MCU. USB-C provides bus power, and the onboard regulator supplies 3.3 V to the RNG90, I²C pull-ups, and Qwiic port.

Dimensions

57.15 × 38.1 mm

USB interface

Full-speed USB HID · CP2112

RNG90 address

0x40, 7-bit, fixed

Expansion

3.3 V Qwiic, on the same I²C bus

Mounting

Four 3.2 mm holes

Host enumeration

Linux’s hid-cp2112 creates an I²C adapter. FreeBSD’s cp2112 exposes an iicbus. Adapter numbering is host-dependent; identify the bridge before configuring an RNG90 instance at 0x40. No UART or serial-console device is involved.

Expansion bus

The Qwiic connector exposes the RNG90 bus at 3.3 V. Additional devices must use different addresses and compatible bus voltage and pull-ups. One RNG90 can occupy the bus because its address is fixed.

Activity indications and descriptors

The two LEDs are connected to CP2112 GPIO pins configured for transmit and receive toggling. The host must restore that volatile GPIO configuration after a reset or reconnect. USB descriptor fields are separate, one-time-programmable settings; changing LED behavior does not require burning descriptors.

The CP2112 host utility separates inspection, volatile GPIO configuration, and permanent descriptor programming. Plan descriptor fields before programming them; they are not ordinary rewritable configuration memory.

02 / R90-HAT

Raspberry Pi / RTC

The HAT connects the RNG90 and MAX31328 real-time clock to the Pi’s native I²C bus. The CR1220 cell backs up the RTC while host power is absent. The ID EEPROM is on the Pi’s separate identification bus.

Dimensions

65 × 56.5 mm

RNG90

0x40 · I²C1 on GPIO2 / GPIO3

RTC

MAX31328 · 0x68 · CR1220 backup

ID EEPROM

M24128 · 0x50 · ID_SD / ID_SC

Supply

3.3 V from the Pi header

Mounting

58 × 49 mm pattern · 2.7 mm holes

Pi 5 installation and troubleshooting ↗

Power and identity

The backup cell supplies the RTC only. RNG90 generation requires the Pi’s 3.3 V rail. The EEPROM stores board identity and an overlay name; the overlay and host driver are installed on the Pi separately.

EEPROM write protection uses a removable 0 Ω link, R10. After programming, removing the link lets the pull-up protect the array. Reprogramming requires temporarily pulling write protect low.

Mechanical installation

Align pin 1 with the Pi powered off and use suitable spacers. The left-edge notch provides flex-cable clearance. There is no camera slot; camera cabling runs below the HAT and exits at the right edge.

03 / Host software

OS integration

Linux: hwrng

The project’s RNG90 module registers with Linux’s hardware RNG framework and provides output through /dev/hwrng when selected. It uses raw I²C transfers through either the CP2112 adapter or a native I²C controller. The module is GPL-2.0-only.

Build the module against the running kernel’s development headers and configure the RNG90 at 0x40. Pi device-tree configuration is a separate installation step. The project module should not be assumed to ship in a distribution kernel.

Each driver read returns at most 32 bytes. Bytes unused by a short caller buffer are discarded. Transfers are serialized with suspend and cleanup; there is no asynchronous prefetch. A nonblocking request cannot initiate and wait for a new hardware result.

Linux entropy credit

The current project policy advertises quality = 1, nominally crediting one bit per 1024 returned bits. This deliberately conservative policy is not a physical entropy estimate. The RNG90’s stated 128-bit security strength for a 256-bit result does not, by itself, establish entropy per output bit.

Binding can allow the hwrng core to select the device and feed the kernel pool under that policy. Review device selection and credit settings as part of host integration, separately from reading raw device output.

FreeBSD: iicbus and the RNG90 source

The BSD-2-Clause module provides root-only /dev/rng90N reads and an opt-in kernel entropy feed. It uses native iicbus interfaces, including the CP2112 bridge. The feed is disabled on attachment unless a device hint enables it. Verified blocks are submitted through the dedicated RANDOM_PURE_RNG90 source in a matching kernel build.

Raw reads generate separate blocks that are not also submitted to the entropy feed. The production implementation submits four 8-byte harvest events per device block; the kernel applies its configured health policy. USB hardware, continuous collection, cold boot, module lifecycle and disconnect recovery have been tested on FreeBSD 15.1 with the accompanying CP2112 fix. These results concern R90-DIRECT; native Pi HAT operation on FreeBSD has not been established. This is project software, not an upstream release.

macOS bridge configuration

The CP2112 configuration utility can inspect the bridge and configure GPIO through HID. A bridge-configuration tool is separate from RNG90 generation software and from integration with the macOS random subsystem.

Throughput

Observed Linux throughput through CP2112 at 100 kHz I²C is approximately 850 bytes per second. The Pi 5 HAT path delivered approximately 1.07 kB/s over native 100 kHz I²C on Linux. These include command execution, transfers, polling and host scheduling; neither rate is guaranteed or an entropy measurement. See measured HAT validation.

04 / Device protocol

Command and response handling

The RNG90 uses a physical noise source to supply entropy to SHA-256 Hash_DRBG. Microchip describes entropy input at instantiation and at each generation request. The Random command returns 32 bytes of DRBG output, with 128-bit specified security strength.

Response framing

Count       Payload             CRC-16
1 byte      32 bytes            2 bytes
0x23        Random output       Response integrity

Total: 35 bytes

The host verifies transfer length, response count, CRC, and status before delivering the payload. Four-byte status responses and read padding cannot be treated as random data. The CRC detects transmission errors; it is not an authentication mechanism or an entropy test.

Timing

Table 5-6 of DS40002499A gives 20.2 ms typical and 25.3 ms maximum for subsequent Random executions under its stated conditions. First execution includes self-tests: 57 ms typical and 72 ms maximum. Polling and bus transfer time add to device execution time.

Failure and recovery

The Linux driver fails a read on a CRC-verified health-test or self-test failure. The next blocking read performs a sleep/wake recovery so the next Random command includes self-tests. Three such failures without an intervening verified Random result latch the driver until unbind/rebind. A verified result clears the failure count.

Malformed responses and adapter errors are handled separately from device health verdicts. Successful recovery requires a new, validated response; an earlier payload is not reused as substitute output.

Source health and validation

Source health tests, transport checks, and host statistical tests address different failure modes. Statistical properties of a stream do not establish its physical entropy or certify the board. Device output width, DRBG security strength, and OS entropy credit must be assessed separately.

05 / References

Device and standards

Microchip RNG90: data sheet DS40002499A, §2.2 for the generator, §5 for command and response handling, and Table 5-6 for timing. Its SP 800-90C discussion refers to the draft available when that data sheet was published.

NIST SP 800-90A Rev. 1 specifies DRBG mechanisms. SP 800-90B covers entropy sources and their validation. SP 800-90C specifies RBG constructions combining these elements.

These references describe device behavior and standards scope. They do not assert cryptographic-module validation for R90-DIRECT, R90-HAT, or a host system.