Up to [cvs.NetBSD.org] / src / sys / arch / mips / cavium / dev
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
octeon_rnm.c: minor code formatting and grammar tweaks (NFC)
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
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
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
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.)
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.
sys: Use preempt_point and preempt_needed, not open-coded versions.
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.
Fix tyop in a comment. Thanks riastradh@.
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.
Rename all Cavium Octeon device driver functions, structs etc from "octeon_foo" to "octfoo", except "octeon_eth" becomes "cnmac".
Clean up Cavium Octeon device names. Rename devices from "octeon_foo" to "octfoo" - this follows the naming conventions used by many other MIPS CPUs.
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.
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.
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.
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.
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
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.
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.
Sync with HEAD
Synch with HEAD
no need to include <machine/param.h> if <sys/param.h> already included
update from HEAD
Sync with HEAD
file octeon_rnm.c was added on branch tls-maxphys on 2017-12-03 11:36:27 +0000
file octeon_rnm.c was added on branch nick-nhusb on 2015-06-06 14:40:01 +0000
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.