I'll pass on most of this rant, just want to correct this misunderstanding:
> That one? https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-....
> It's one of the first links I found, I hope it is obsolete: they say the internal state of Jitterentropy is puny 64 bits number
You skimmed too quickly and came to a judgement based on a misreading or misunderstanding of the concept. Obviously 64 bits is not sufficient.
The idea of the jitter entropy mechanism is that most modern CPUs have super high resolution clock or cycle counters available (even embedded boards), and instruction execution speed has mild variance.
You run a series of trials, each of which produces one or more bits of output (classically: 1). You run as many as you want, producing an infinite stream of weak entropy, until you have collected a satisfactory number of output bits. Trials can be run relatively quickly (many nanoseconds or a handful of milliseconds per trial).
For each trial, you perform some minimal workload intended to exacerbate CPU runtime variance (this might be where you saw "64 bits"), and extract some number of output bits (maybe 1) from one or more of: the low bits of the cyclecounter, nanosecond clock, or something similar of that nature.
Caveat: jitter is an even weaker entropy source than most non-HWRNG sources typically consumed by entropy gatherers. Your motto of "just 256 bits" assumes total independence and 8 bits per byte of entropy. It isn't met by most real-world entropy sources on server systems (expect 4-5 bits/byte) and especially not by jitter entropy. Empirically, jitter seems to come closer to 1 bit per byte minimum in SP800-90B evaluations on the raw output — it's a pretty weak entropy source.
Anyway: feel free to read more about the concept at any of the sources. The Fuschia writeup you linked is a good one if you read it more closely; there's also:
* From the original (2013) proponent, Stephan Mueller: description: http://www.chronox.de/jent.html and sources: https://github.com/smuellerDD/jitterentropy-library
* LWN's 2015 writeup of the concept as a Linux entropy source: https://lwn.net/Articles/642166/
* And this is all suddenly topical due to the latest nonsense from Linus (TFA, 2019), who still does not understand CSPRNGs. Anyway, Linus wrote and merged a version of jitter entropy quite recently: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... This is a relatively happy outcome in that Linus didn't just break the ABI to be completely insecure by default.