Don't implement this at all. Even if it's better than the LRNG or FreeBSD kernel RNG, it's not worth pursuing. It's probably an interesting and important CS result. That doesn't mean it belongs in systems.

My first thought was to make a tiny cheap RNG chip using ~4 different really cheap TRNG sources (diodes, etc) with this as a mixer, for embedded systems (routers and similar).

It doesn't matter if a few turn out unreliable, predictable or if they malfunction, you just need those first few hundred bits to seed your system CSPRNG with.

There are two real-world problems hardware RNGs can solve, as far as I can tell:

1. They can give userland programs direct access to a permanently "seeded" source of entropy, so that you don't have to route requests through the kernel.

2. They solve the cold-start entropy problem for embedded systems that can't easily generate sufficient entropy within milliseconds of initialization.

The former problem is only solved if the HWRNG is part of the ISA for the platform. If you have to pull it from a device, you might as well just pull it from urandom or getrandom().

Other than that, we're not really dealing with problems real security software has. People don't break cryptosystems by attacking the quality of entropy extraction from interrupts and whatnot. I have the same reaction to proposals on LKML about improving the entropy inputs to the LRNG. I mean, great, knock yourself out. But that's not solving a problem systems programmers actually have.