RPis don't necessarily have RDRAND, they especially suffer from increasingly fast boot where waiting for the entropy pool is an actual concern.
Of course, not all applications need that kind of cryptographic entropy but during early boot it's pretty much the best randomness you can get (seeding from datetime isn't available on the RPi, so until you can bring up the network and contact the NTP server, you're stuck with whatever getrandom() returns)
Re:Fixing Getrandom()
by cryptonector on Wednesday October 02, 2019 @03:23PM
(#21139904)
RPI 2s have a BMC (binary-only) driver for entropy generation.
Still, if you're booting a system that will be doing one thing, and that one thing needs entropy, then you have a problem. And the only practical solution then is to accept using things like RDRAND and a previous shutdown's saved seed to seed the system's SRNG, then add better entropy slowly as you can get it.
EDIT: I agree with tytso: if you trust the CPU enough to run on it, then you should trust its RDRAND or equivalent (if it has it).