The writing is amazing. I had a turbo-XT back in the day, so parts 1 and 2 really bring you back if you were of that age.
Part 3:
"Running C code is a bit more difficult. The problem is that the code generated by any standard C compiler for the x86 CPU will heavily depend on RAM. System RAM is not enabled yet and the code to enable it is so complex that you really want to do it in C. Two solutions have been devised and both of these are in use (one or the other depending on the hardware).
Use a special C compiler (romcc) that does not make use of RAM, but keeps all data in registers. As the register set of the x86 is quite small (only 8 general purpose 32-bit registers), this severely limits the things that your C program can do. As the CALL and RET instructions cannot be used (they always use the stack in RAM), all C functions have to be inlined.
Use the CPU cache as a data RAM. This requires some special tricks to pretend that all cache lines contain valid data and to prevent them from being evicted. Which tricks are exactly required, depends on the exact model of CPU, but it can be done. The Cache As RAM trick (CAR) yields at least 16kB of usable RAM, sufficient as stack space for a simple C program. All recent hardware ports use this trick."
We run into the same problem on ARM systems, but they tend to be much more forgiving when using cache as RAM. Generally there is a bit you can flip (either in memory-mapped IO or as a coprocessor instruction) to turn cache into RAM, which is how most ARM boot roms work.
Furthermore, most embedded platforms simply hardcode the timing values for the variety of RAM that they put down on the board. Since you know that the RAM, CPU, and board won't change, you can calibrate once and be done with it.
For Novena, we support swapping DDR3 modules, so we need to recalibrate on every boot. We're not so restricted, since we have a good 128k (or 256k) of on-chip cache-as-RAM, so we just do it all in C. Of course it starts out with reading the RAM configuration out of the SPD chip on the module, but timing calibration must be completed regardless. If you're curious, the code we use to do this is available at https://github.com/xobs/u-boot-novena-spl/blob/u-boot-spl-no...
I also like how bringing the RAM up works: it starts with getting the south bridge running, then querying the RAM SPD for timings (via the south bridge smbus), and then programs the northbridge with the right timing information. Wow.
Modern high-speed DRAM interfaces are very complex. Their initialization is dependent on the particular memory module in use, and some parameters are even determined at power-on via training. So there actually are no "sensible defaults" which can be expected to work reliably with all memory modules. The initialization and training routines are far too complex to justify implementing them entirely in hardware, thus the need for software hacks to get things up and running.
If you think about it, many modern CPUs have as much cache as XTs had RAM.
It's no surprise that a I7 can work perfectly with no DIMMs attached to it and actually for a brief period of time, the BIOS does exactly that until it starts the DDR memory.
Another interesting thing, no matter how many cores the CPU have, it always starts in single-core mode and you have to switch the other cores on.
Mind blown indeed. But don't these need special CPU instructions? Which x86 instructions do this? (Or is this done through a special hardware pin on the CPU?)
coreboot time (as per cbtime) : 1.5s, followed by kernel and system boot in (as per systemd-analyze) :
Startup finished in 2.244s (kernel) + 611ms (userspace) = 2.856s
But you can use other payloads too - even chainloading them from grub!
"stealing the VGA bios" in column 4 is not mandatory if your hardware supports native video init, and today I just succeeded in replicating the video support using SeaBIOS (cf http://www.coreboot.org/SeaBIOS and http://www.coreboot.org/pipermail/coreboot/2014-February/077...), which means that I can now load a standard grub and maybe other operating systems should I want to use them on the X60, without any blackbox blob - who knows what may be hidden in these blobs.
Why is that interesting? Because in the default bios (cracked open with bios-extract, Phoenix BIOS "Phoenix FirstBIOS(tm) Notebook Pro Version 2.0 for ThinkPad") there is Computrace backdoor as option rom 2E (cf http://securelist.com/analysis/publications/58278/absolute-c...).
If I ever need to do things on a windows machine, I don't want bios rootkits - and coreboot makes that possible, thank you :-)
If you like playing with operating systems, boot, etc. coreboot is very cool.
Is coreboot ready for practical usage for someone paranoid about security, but needing to use real-world operating system with production-grade stability and performance on more-or-less modern hardware (something like X60 is kinda ok; maybe just a little bit newer?)
It's all the caveats you mention. So in a word, yes, but to get a decent system with coreboot your first stop should be a look at Google Chromebooks, not because they _should_ be the first stop but because they're above the curve in terms of being pretty modern, reasonably priced, and coreboot-supported.
I'm actually interested whether X200s is supported, as that's what I use now and what I'm ok with. I can see myself using this or X220. I had X60s, but it would feel limiting already: among other things, it only supports 3GB RAM. I looked into hardware support list http://www.coreboot.org/Supported_Motherboards#Laptops and only see X201 and X230 mentioned, but X230 board is not supported by flashrom. Does that mean that flash chip has to be replaced (a new one soldered in the place of old one) to use this board? Should X200(s) and X220 be supported?
Looks like the hardware support situation haven't improve a single bit since the last time I looked into coreboot. That's a pity.
How well does the computer work, when it is supported? Are there stability issues? Is performance the same? Do all of the same devices work, as with proprietary BIOS?
Getting everything on a laptop supported is definitely hard, so any help you can give is appreciated.
When it is supported, there are different outcomes. The individual board pages on the wiki can offer more details. The X60 is especially well supported because of a combination of factors:
1. Lenovo was actually pretty helpful
2. Lots of coreboot hackers have worked on the machine for years
3. Lots of other linux hackers have also worked on various parts (which improves the support for all the devices)
So without doing any research, my understanding is that the X200s and to a lesser degree the X230 cannot achieve that level of support, mostly because it would take the coincidence of all that work coming together. But it's not all bad: the Chromebooks are getting that work done by a group of paid engineers, and there is a recent addition to the supported laptops (not fully open, but close; not amazing hardware, but decent) - the HP m6-1035dx.
I got an HP m6-1035dx on ebay, and my experience is that everything works fine. I suggest throwing away the mini PCIe wireless card it comes with and putting in a better one, but I haven't brought it up on the coreboot mailing lists because it's not really coreboot's fault. HP just built a cheap laptop and so it has a junk wifi card.
The X60 doesn't have Computrace in its original BIOS; that appeared starting with the X61. If it's there it got in through an update or someone deliberately installed it...
Either way it's not so hard to remove that option ROM and reflash the BIOS. ;)
I beg to disagree. On all of the motherboards I have, it was present in every single one of them - but on some it "didn't show", ie there was no warning message when entering the bios, so it I believe it was not activated or something. But the option rom was present on the X60 tablet. You may want to check yours.
Also, which tool would you use to remove this option rom? CBMROM does not works on phoenix firstbios, and the phoenix editor tools don't work on the 2 Mb image.
I'd be delighted to know, just because I have that it's still there on my "reference" motherboard (used to test whether issues are due to coreboot or not)
I just checked the first version of BIOS update for the X60 available from Lenovo's site and... damnit, it has the option ROM! My X60 is not with me at the moment but I know I never updated the BIOS since I bought it so it should have the very first version that was released, and it's possible that Lenovo silently modified their previous versions to incorporate Computrace. No signs of it being activated (yet).
phdecomp + phnxdeco worked to unpack the BIOS into its modules; it shouldn't be difficult to reassemble it without the Computrace module and fix up the checksum, then reflash. But on the other hand, since the C&C server can be modified, maybe it might be more fun to activate it after pointing it to a server I own, and then I get a free backdoor that I can use...
told you so :-/ If you run bios-extract on a dump of your x60t, you'll see Computrace is in 2E_0.rom.
I have no idea on how to reassemble the pieces into a working bios. It's not just a checksum, that's for people doing SLIC ie replacing or adding stuff at the bottom. A missing table in the middle might cause problems. Isn't there an index too?
Anyway, the alternative hack you suggest would be quite a cool one :-) I didn't know it was possible to change the address of the c&c in the option rom (IIRC, it's like packed in an EFI header, then again - I just don't know which tools to use), but if it's, I'd be quite interested - even more if the computrace protocol has ben reverse engineered ;-)
It's not bad per se. But it's badly designed (no digital signatures whatsoever in binary or protocol), and it has complete control of your machine.
A very dangerous piece of propietary software preinstalled in all corporate laptops that you cannot deactivate, uninstall or even patch. It may not be a rootkit, but surely can be used as one.
I love the idea of freedom that Coreboot gives, but feel like they should really be using more Asm. I remember doing a comparison a few years ago and CB had far less functionality, while being quite a bit larger, than the standard commercial BIOS for a given machine.
Also, almost all BIOSes go into flat real mode ("unreal mode") not far from the reset entry point, as otherwise they would be unable to access most of the memory and devices in the system.
If you're interested in BIOS stuff one of the things I'd recommend is to get a copy of the PC/AT technical reference - the full BIOS listings are in there, and make for great studying of historical significance since much of the hardware has remained essentially software-compatible since then, only physically changed form. For example, the latest 8-series chipsets for i5/i7 still contain a pair of 8237s, 8259s, and an 8254 in the same configuration as the original AT.
coreboot moves into 32bit protected mode (without paging) within ~30 instructions after power-on. Contemporary PC firmware now does as well, or even moves to 64bit long mode.
For BIOS services, there's SeaBIOS (www.seabios.org) which we can run as a payload. DOS works fine with it.
I'd be more interested in how many cycles it takes. I mean at 2 billion instructions per second, do you really notice a difference between 30 and 10 instructions? However, if any/all/many of the stall on data or something, then yes, it matters.
this passage hit android right in the face for me. hopefully we can get rid of it now in less than 30yrs...
"
In the 1980s the functionality of a microcomputer was determined at least as much by its firmware in ROM as by its hardware. The Apple MacIntosh might have had a similar hardware architecture to the Atari ST, but each had its own different operating system in ROM.
Of course there were those brave people who would replace the ROM chips inside their computers by ROMs they had programmed themselves, so they could regain complete control over their machines, which was lost when the front panel had disappeared. Coreboot is just such an endeavor.
"
it's nice that everyone can compile an android rom, but with closed drivers and proprietary boot managers we are in that precarious state...
The situation is particularly bad for ARM SoCs since the majority of them are notoriously proprietary - at least with an x86/PC backwards compatibility means a lot has stayed the same even though there have been many differences, and that gives a basic point to start exploring and reverse-engineering (basically you can assume the BIOS is at the top of the address space and the first instruction after reset is at FFFF:FFF0), but with ARM about the only thing that stays the same is the CPU core; the boot sequence, where the peripherals are (and what exactly is available), etc. are all vastly different between makes and models. I'm not saying it can't be done, but it'll need a lot more effort if you don't have the official documentation.
I think Coreboot is useful for some things, but I did not like it when Chromebooks used it because using different firmware for different OSes defeats the purpose of firmware standards. I think it is possible to run UEFI as a payload in coreboot.
And when it comes to open firmware standards, why didn't Intel go with IEEE1275 but invent its own? firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard.
firmware standards really exist aplenty, defusing any claim that any single one of them "should" be implemented because it's a standard.
New Win8.x machines are required to boot using UEFI, and OF on x86 was never popular anyway. To show some of the harms this situation have caused BTW, LKML has a lot of posts about various UEFI firmware bugs, and remember that Chrome OS is based on the Linux kernel.
These UEFI firmware bugs are completely avoided by choosing an interface with a smaller footprint. As in: not much of an interface at all. This is what makes ChromeOS work while UEFI still fails at times.
No moving parts means no worries - that's a lesson the UEFI architects never understood.
So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design).
And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so.
Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design.
Yes, I know UEFI is not perfect, but the problem with PC OEMs only caring about Windows existed long before UEFI, and my point is that Chromebooks using different firmware only make the problem worse. ARM SBSA uses UEFI and ACPI BTW even though there is no Windows Server RT.
Many coreboot installs(including those on x86 chromebooks) have SeaBIOS included. you just press C-l at boot and it drops you into the standard PC BIOS. If you've gone through and removed the warranty-voiding screw(which is not warranty-voiding in europe) you can enable it by default(and also just load your kernel directly as a payload, which I think is a better idea).
There is also talk, and perhaps actual implementation, of TianoCore running on top of coreboot.
SeaBIOS is also used by VirtualBox, and probably Xen as well.
Most x86 chromebooks have SeaBIOS included in their coreboot payload, you can just press C-l and it'll drop you to a standard BIOS, I use this to run a PC GNU/Linux distro on my C720P.
Part 3:
"Running C code is a bit more difficult. The problem is that the code generated by any standard C compiler for the x86 CPU will heavily depend on RAM. System RAM is not enabled yet and the code to enable it is so complex that you really want to do it in C. Two solutions have been devised and both of these are in use (one or the other depending on the hardware).
Use a special C compiler (romcc) that does not make use of RAM, but keeps all data in registers. As the register set of the x86 is quite small (only 8 general purpose 32-bit registers), this severely limits the things that your C program can do. As the CALL and RET instructions cannot be used (they always use the stack in RAM), all C functions have to be inlined. Use the CPU cache as a data RAM. This requires some special tricks to pretend that all cache lines contain valid data and to prevent them from being evicted. Which tricks are exactly required, depends on the exact model of CPU, but it can be done. The Cache As RAM trick (CAR) yields at least 16kB of usable RAM, sufficient as stack space for a simple C program. All recent hardware ports use this trick."
Mind. Blown.