CVS commit: [netbsd-10] src/sys/arch/mips/cavium/dev

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Sun Jul 30 11:39:33 UTC 2023

Modified Files:
        src/sys/arch/mips/cavium/dev [netbsd-10]: octeon_rnm.c

Log Message:
Pull up following revision(s) (requested by gutteridge in ticket #256):

        sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.16

octrnm(4): Raise delay on startup.

According to CN50XX-HRM-V0.99E and CN78XX-HM-0.99E:
    The entropy is provided by the jitter of 125 of 128 free-running
    oscillators XORed into a 128-bit LFSR.  The LFSR accumulates entropy
    over 81 cycles, after which it is fed into a SHA-1 engine.
    [...]
    The SHA-1 engine runs once every 81 cycles.
    [...]
    The hardware produces new 64-bit random number every 81 cycles.

The last sentence means that we only need to wait 81 cycles _between_
consecutive SHA-1 outputs (which isn't relevant anyway because we
reconfigure it into raw mode later), but the first two quotes might
mean that we need to wait 81+81 cycles for the _first_ output to be
produced on boot when running the self-test.

Now, in this case, the self-test is run with the LFSR unhooked, by
clearing the RNM_CTL_STATUS[ENT_EN] bit, so that SHA-1 is computed
from a known input -- this is really just paranoia to make sure that
_some_ functions of the device (which is conjured out of thin air at
a fixed virtual address, with no firmware bindings to guide us)
behave as we expect.

And it's not clear if it really does take 81+81 cycles for the first
SHA-1 output to appear when the LFSR isn't feeding into it anyway.

But experimentally, delay of 81+81 cycles seems to work whereas a
delay of only 81 cycles crashes.
PR kern/57280


To generate a diff of this commit:
cvs rdiff -u -r1.15 -r1.15.4.1 src/sys/arch/mips/cavium/dev/octeon_rnm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.