This article is written on an open-source operating system, but not an open-source machine — the BIOS isn’t open-source, and even if it were supported by the coreboot project (formerly LinuxBIOS), there would still be a whole host of binary blobs required to get it to boot. On one vintage architecture, there’s one less blob, as coreboot can now initialize DRAM on Intel Bay Trail SOCs, as [Mate Kukri] presented in a talk at the recent Open Source Firmware Conference.
Bay Trail isn’t exactly cutting-edge hardware, to be sure — the SoCs are over a decade old at this point, and were only used in low-performance mobile applications like Chromebooks. On the other hand, coreboot has been on Chromebooks for at least as long. Getting DRAM set up is difficult because, well, you don’t have any memory to work with until you do. Traditionally, the way you did that was to call on one of the many proprietary ‘binary blobs’ provided with next to no documentation by the manufacturer. Reverse engineering that requires some serious bus-sluthing, which was done in software with the SerialICE debugger and the Unicorn Engine CPU emulator. The talk focused on that technique and how it might be applied more widely, rather than getting into the weeds of how to do DRAM init on one obsolete SOC. At some point the whole thing should be archived on the OFSC website so those of us not lucky enough to attend in person can hear what [Mate] — and all the other speakers — had to say.
Because coreboot is open, you can do a lot more with it than a proprietary UEFI firmware — for example, you can choose not to initialize RAM at all, and run entirely in the CPU’s cache. You can also — of course — run DOOM. If you want to be binary-blob-free, you’ll need to find hardware supported by the more hardcore Libreboot distribution of coreboot, which admits no binary blobs at all. When it comes to Libreboot, it might actually be easier to install than to find compatible hardware these days.
“Bay Trail is exactly cutting-edge hardware” -> isn’t
No,you see, that’s where the edge stopped: Bay Trail. That was it. The edge was cut, and we’re just far beyond the cutting edge now.
Or maybe it was a typo.
Maybe it’s even been fixed.
I guess that bay trail fell off when that edge was cut.
People were tired of the constant cuts, so now we’re at the extorting edge.
Certainly was bleeding edge hardware, though – it was the generation of chips where Intel had forgooten about the laws of physics as they interacted with silicon circuits for a while, with the result that pretty much every interface on the chip except video would degrade with use: the USB ports have a maximum 50TB transfer life, for example.
In others words it now runs on hardware which even at its prime was considered ewaste. Woohoo!
It always ran on that e-waste hardware, now it just does it with one fewer binary blob. That may sound even less exciting to you, but the key here is the techniques used to reverse engineer that blob– they seem like they’d be applicable elsewhere, which should hopefully lead to more open computing. If you don’t care about that, well, the whole thing is a waste of time. If you do care about open source firmware, though, it’s pretty neat to hear.
Wake me up when they replace IME. That’s the ultimate cancer which makes every x86 system perma-backdoored and compromised no matter if it runs Windows, Linux or even MS DOS.
Of course there are Russian Elbrus or Chinese Loongson x86-compatible CPUs without US backdoors. However due to abysmal performance they’re useless for modern gaming unless you’re into playing titles from roughly GeForce FX era.
Or let’s just use sane resolutions/color depths instead.
Super VGA in 800×600 pixel in 15-Bit or 16-Bit color depth (displays pixel perfect on 1600×1200 monitors).
Normal Standard VGA in 640×480 pixel is fine for CRT TVs.
But we can try 512×384 pixel for improved performance, too.
Tomb Raider supported it, for ecample.
I know, at first it doesn’t seem to be the yellow from the egg!
But gameplay will be butter smooth!
These configs were good enough when we had our Pentium MMX PCs with Voodoo cards and DOS/Windows 98SE, after all.
– What used to be right can’t be wrong now, after all!?
Good enough? https://github.com/corna/me_cleaner
In a past civilised era processor manufacturers published things like a guide to writing a BIOS. What they have to gain from not doing so and forcing people into having to spend endless time figuring out how things work is something I would like to see others’ views on.
probably gotten so complicated and has so many quirks and work arounds that the only realistic guide to how it works is the code
Maybe hidden config that they gate behind paywall(like unlock multiplier, support new gen cpu).
strange that no one leaked the sources of these fw. seems like it is easier to protect kb of code than our credit cards.
What are you implying here, that there is some sort of double standard? One for the important people and another for everybody else?
Those kb of code probably have probably never left an Intel facility, except as a compiled blob. Your credit card information gets used, and therefore shared, pretty much every day.
libreboot doesnt work like that anymore. they do allow blobs, when there is no other way to make hardware work. its a “blob minimization policy”
” If you don’t care about that, well,”
He is one who “kisses the M$ ring”
No loss :)