Hello Ahmad, On Mon, 2024-08-05 at 18:56 +0200, Ahmad Fatoum wrote: > > Do you have rngd enabled? You don't need this anymore with a recent > enough Linux (>= v6.1 or perhaps earlier). > > This doesn't fix the underlying issue of course, but it will save you > some CPU time. Your speculation that rngd is running comes from the error pops every 10seconds? I cannot see any systemd service related to rng running on my machine. How can I disable it? > > > And if I try to read from device the > > same error occurs: > > > > ~# dd if=/dev/hwrng of=/dev/null bs=1 count=1 > > caam_jr 2141000.jr: 2000005b: CCB: desc idx 0: RNG: Hardware > > error > > dd: /dev/hwrng: Invalid argument > > > > No errors are fired in barebox where the RNG self-test is run > > succesfully: > > > > rng_self_test: RNG software self-test passed > > caam 2140000.crypto@xxxxxxxxxx: Instantiated RNG4 SH0 > > caam 2140000.crypto@xxxxxxxxxx: Instantiated RNG4 SH1 > > caam 2140000.crypto@xxxxxxxxxx: registering rng-caam > > > > Here [1] I found that enlarging the entroy delay may help so I > > tried to > > do the same in barebox by changing RTSDCTL_ENT_DLY_MIN from 3200 to > > 4800 and it succeded, I no longer see those errors in linux and > > trying > > to read from the device works perfectly. > > That's the correct resolution, yes. > > > The strange thing is that on another board based on imx6sx I never > > see > > those errors. > > There can be quite some variance in the time needed to collect enough > entropy, even for SoCs cut from the same wafer, so this is not > unusual. > > > Is it something new to you? > > This issue has been there for a long time. Optimally, NXP would > store a suitable delay value into the OTP in the factory or at least > public suitable initial delay values for their SoCs, but > unfortunately > they don't. > > > May we change the delay? On linux-imx 6.6.3 3200 is still used. > > The driver starts at 3200 and increases the delay in steps of 40 > until > it reaches a suitable value. There's a maximum (12800), but it's not > used as that would slow down the RNG. Thus the search at probe time > for > the lowest possible delay value that still allows instantiating the > RNG. > > Unfortunately, a successful instantiated RNG doesn't necessarily mean > that > actual runtime usage of the CAAM won't trigger errors. > > Increasing RTSDCTL_ENT_DLY_MIN to a value appropriate for your board > is > thus the way to go. I think it would be appropriate to add a device > tree > property, so the minimum delay value can be set on a per-board basis. > Got it. Thank you
