Hello Daniel,
On 2024-07-30 01:18, Daniel Golle wrote:
On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
Thanks a lot for the testing. Though, such wildly different test
results
can, regrettably, lead to only one conclusion: the HWRNG found in
RK3566
is unusable. :/
The results on RK3568 look much better and the series right now also
only enabled the RNG on RK3568 systems. However, we have only seen few
boards with RK3568 up to now, and I only got a couple of NanoPi R5C
here to test, all with good hwrng results.
Do you think it would be agreeable to only enable the HWRNG for RK3568
as suggested in this series? Or are we expecting quality to also vary
as much as it (sadly) does for RK3566?
I'm a bit late to the party, sorry for that. The test results so far
show that the HWRNG in RK3566 simply cannot be relied upon, but the test
results also show that the RK3568's HWRNG seems fine. I'm wondering
why,
but until we bump into a sample of RK3568 whose HWRNG performs badly,
I'd say that enabling the HWRNG on RK3568 only is safe.
Of course, as other people already noted, the HWRNG should be defined in
rk356x.dtsi, because it does exist in both SoC variants, but should be
enabled in rk3568.dtsi only. As already noted, describing it as broken
on RK3566 in rk356x.dtsi should also be good.
