| History log of /src/sys/arch/mips/cavium/dev/octeon_rnm.c |
| Revision | | Date | Author | Comments |
| 1.17 |
| 30-Jan-2025 |
gutteridge | octeon_rnm.c: minor code formatting and grammar tweaks (NFC)
|
| 1.16 |
| 21-Mar-2023 |
riastradh | 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
XXX pullup-10
XXX pullup-9
|
| 1.15 |
| 19-Mar-2022 |
riastradh | branches: 1.15.4;
rnd(9): Omit needless locks in various HWRNG drivers.
Now that the rnd(9) API guarantees serial callbacks, we can simplify
everything a bit more.
(Some drivers like hifn(4) and sun8icrypto(4) still use locks to
coordinate with other parts of the driver to submit requests to and
process responses from the device.)
|
| 1.14 |
| 19-Mar-2022 |
riastradh | rnd(9): Adjust IPL of locks used by rndsource callbacks.
These no longer ever run from hard interrupt context or with a spin
lock held, so there is no longer any need to have them at IPL_VM to
block hard interrupts. Instead, lower them to IPL_SOFTSERIAL.
|
| 1.13 |
| 28-Dec-2021 |
riastradh | sys: Use preempt_point and preempt_needed, not open-coded versions.
|
| 1.12 |
| 18-Jun-2020 |
simonb | General code cleanup:
- use generic macros for building IO and IOBDMA addresses instead
of many different variations of the same theme.
- use #define's for CVMSEG addresses instead of magic numbers.
- use __BIT/__BITS/__SHIFTIN/__SHIFTOUT in most places, instead of
foo_SHIFT defines or (worse) shifting by magic numbers.
No functional changes.
|
| 1.11 |
| 08-Jun-2020 |
simonb | Fix tyop in a comment. Thanks riastradh@.
|
| 1.10 |
| 05-Jun-2020 |
simonb | Rework CVMSEG LM usage a litte:
- remove unused LM slots
- use #defines for defining the size of CVMSEG LM users
XXX: Need to dynamically set CVMMEMCTL[LMEMSZ] during startup so we can
both adapt to any future increase in CVMSEG LM usage and not waste
any more L2 that we need to.
XXX: Still need to move general IOBDMA conf to a different (new?) header.
|
| 1.9 |
| 31-May-2020 |
simonb | Rename all Cavium Octeon device driver functions, structs etc from
"octeon_foo" to "octfoo", except "octeon_eth" becomes "cnmac".
|
| 1.8 |
| 31-May-2020 |
simonb | Clean up Cavium Octeon device names. Rename devices from "octeon_foo"
to "octfoo" - this follows the naming conventions used by many other
MIPS CPUs.
|
| 1.7 |
| 30-May-2020 |
simonb | CN70XX iobdma limit appears to be 128 words, so gather that many samples
as a time.
Gather the full 512 bytes of samples and process in a single call to
rnd_add_data_sync() - about 10% faster than 4 calls to rnd_add_data_sync().
Put sample buffer in the softc to save some stack usage.
|
| 1.6 |
| 18-May-2020 |
riastradh | Adjust entropy estimate for the Octeon.
We are hedging in serial and in parallel, and more conservative than
the Linux driver from Cavium seems to be, so although I don't know
exactly what the thermal jitter of the device is, this seems like a
reasonable compromise.
|
| 1.5 |
| 13-May-2020 |
riastradh | Rework octeon_rnm(4) random number generator driver.
- Do a little on-line self-test for fun.
- Draw raw samples from the ring oscillators.
- Draw substantially more samples:
=> early RO samples seem to have considerably lower entropy
=> consecutive RO samples are not independent
- Make sure to use rnd_add_data_sync in the callback.
=> not technically needed in HEAD, but would be needed for pullup
|
| 1.4 |
| 12-May-2020 |
simonb | Oceton RNG/RNM driver modernisation to fit new entropy world order by
riastradh@, with some tweaks to get working in RNG mode.
XXX TODO: work out how to get raw entropy mode working.
|
| 1.3 |
| 12-May-2020 |
simonb | If bus_space_map fails, just don't attach the driver instead of panicing.
Check RNG built in self test, don't attach if that fails too.
|
| 1.2 |
| 08-Jan-2019 |
jdolecek | branches: 1.2.4;
no need to include <machine/param.h> if <sys/param.h> already included
|
| 1.1 |
| 29-Apr-2015 |
hikaru | branches: 1.1.2; 1.1.18; 1.1.20; 1.1.22;
Initial import of Cavium Octeon and Octeon Plus SoC and
specifically Ubiquiti Networks EdgeRouter LITE support.
Currently the ethernet and uart are worked.
This support was contributed by Internet Initiative Japan Inc.
|
| 1.1.22.1 |
| 10-Jun-2019 |
christos | Sync with HEAD
|
| 1.1.20.1 |
| 18-Jan-2019 |
pgoyette | Synch with HEAD
|
| 1.1.18.2 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.1.18.1 |
| 29-Apr-2015 |
jdolecek | file octeon_rnm.c was added on branch tls-maxphys on 2017-12-03 11:36:27 +0000
|
| 1.1.2.2 |
| 06-Jun-2015 |
skrll | Sync with HEAD
|
| 1.1.2.1 |
| 29-Apr-2015 |
skrll | file octeon_rnm.c was added on branch nick-nhusb on 2015-06-06 14:40:01 +0000
|
| 1.2.4.3 |
| 30-Jul-2023 |
martin | Pull up following revision(s) (requested by gutteridge in ticket #256):
sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.16 (patch)
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
|
| 1.2.4.2 |
| 19-May-2020 |
martin | Apply patch, requested by simonb in ticket #918:
the updated octeon_rnm(4) driver fails a bogus randomness
test in the netbsd-9 rnd(9) driver for RND_TYPE_RNG type devices so
uses the RND_TYPE_UNKNOWN type. This approach is used by other drivers
on the netbsd-9 branch.
|
| 1.2.4.1 |
| 19-May-2020 |
martin | Pull up following revision(s) (requested by simonb in ticket #918):
sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.3
sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.4
sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.5
sys/arch/mips/cavium/dev/octeon_rnm.c: revision 1.6 (+ patch)
sys/arch/mips/cavium/dev/octeon_rnmreg.h: revision 1.2
sys/arch/mips/cavium/dev/octeon_rnmreg.h: revision 1.3
sys/arch/mips/cavium/octeonvar.h: revision 1.7
Add a few more bits.
XXX convert to __BITS.
--
If bus_space_map fails, just don't attach the driver instead of panicing.
Check RNG built in self test, don't attach if that fails too.
--
Oceton RNG/RNM driver modernisation to fit new entropy world order by
riastradh@, with some tweaks to get working in RNG mode.
XXX TODO: work out how to get raw entropy mode working.
--
Rework octeon_rnm(4) random number generator driver.
- Do a little on-line self-test for fun.
- Draw raw samples from the ring oscillators.
- Draw substantially more samples:
=3D> early RO samples seem to have considerably lower entropy
=3D> consecutive RO samples are not independent
- Make sure to use rnd_add_data_sync in the callback.
=3D> not technically needed in HEAD, but would be needed for pullup
--
Adjust entropy estimate for the Octeon.
We are hedging in serial and in parallel, and more conservative than
the Linux driver from Cavium seems to be, so although I don't know
exactly what the thermal jitter of the device is, this seems like a
reasonable compromise.
|
| 1.15.4.1 |
| 30-Jul-2023 |
martin | 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
|
