Maybe the driver is broken.
Maybe it fails to initialize it. Maybe in other cases, the BIOS initializes it.
So maybe on this machine, it is broken, but on other machines it is not broken.
Pushing 0's to the random subsystem doesn't make the random state worse.
It just fails to make it better.
But on another machine, it might not be pushing 0's, and it might be making the
random state better.
Christian Weisgerber <na...@mips.inka.de> wrote:
> Christian Weisgerber:
>
> > ccp(4) attaches, so presumably it is used as a source of entropy.
> > Whether the hardware actually provides random output, I don't know.
>
> I built a kernel with an instrumented driver. Unfortunately, no
> entropy is provided:
>
> ccp: rng 00000000
> ccp: rng 00000000
> ccp: rng 00000000
> ccp: rng 00000000
> ccp: rng 00000000
>
> This is with the lastest firmware:
> bios0: vendor coreboot version "v4.19.0.1" date 01/31/2023
>
>
> Index: dev/ic/ccp.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/ccp.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 ccp.c
> --- dev/ic/ccp.c 29 May 2020 04:42:25 -0000 1.3
> +++ dev/ic/ccp.c 19 Apr 2023 15:12:17 -0000
> @@ -56,6 +56,7 @@ ccp_rng(void *arg)
> trng = bus_space_read_4(sc->sc_iot, sc->sc_ioh, CCP_REG_TRNG);
> if (trng != 0)
> enqueue_randomness(trng);
> + printf("ccp: rng %08x\n", trng);
>
> - timeout_add_msec(&sc->sc_tick, 100);
> + timeout_add_msec(&sc->sc_tick, 5000);
> }
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
