---
- branch: netbsd-9
  date: Sun Jul 30 11:41:48 UTC 2023
  files:
  - new: 1.2.4.3
    old: 1.2.4.2
    path: src/sys/arch/mips/cavium/dev/octeon_rnm.c
    pathrev: src/sys/arch/mips/cavium/dev/octeon_rnm.c@1.2.4.3
    type: modified
  id: 20230730T114148Z.a40b6354aa4b428bc1962aa066cdba6d19228e68
  log: "Pull up following revision(s) (requested by gutteridge in ticket #256):\n\n\tsys/arch/mips/cavium/dev/octeon_rnm.c:
    revision 1.16 (patch)\n\noctrnm(4): Raise delay on startup.\n\nAccording to CN50XX-HRM-V0.99E
    and CN78XX-HM-0.99E:\n    The entropy is provided by the jitter of 125 of 128
    free-running\n    oscillators XORed into a 128-bit LFSR.  The LFSR accumulates
    entropy\n    over 81 cycles, after which it is fed into a SHA-1 engine.\n    [...]\n
    \   The SHA-1 engine runs once every 81 cycles.\n    [...]\n    The hardware produces
    new 64-bit random number every 81 cycles.\n\nThe last sentence means that we only
    need to wait 81 cycles _between_\nconsecutive SHA-1 outputs (which isn't relevant
    anyway because we\nreconfigure it into raw mode later), but the first two quotes
    might\nmean that we need to wait 81+81 cycles for the _first_ output to be\nproduced
    on boot when running the self-test.\n\nNow, in this case, the self-test is run
    with the LFSR unhooked, by\nclearing the RNM_CTL_STATUS[ENT_EN] bit, so that SHA-1
    is computed\nfrom a known input -- this is really just paranoia to make sure that\n_some_
    functions of the device (which is conjured out of thin air at\na fixed virtual
    address, with no firmware bindings to guide us)\nbehave as we expect.\n\nAnd it's
    not clear if it really does take 81+81 cycles for the first\nSHA-1 output to appear
    when the LFSR isn't feeding into it anyway.\n\nBut experimentally, delay of 81+81
    cycles seems to work whereas a\ndelay of only 81 cycles crashes.\nPR kern/57280\n"
  module: src
  subject: 'CVS commit: [netbsd-9] src/sys/arch/mips/cavium/dev'
  unixtime: '1690717308'
  user: martin