Introduction to Coreboot, an open source BIOS

http://lennartb.home.xs4all.nl/coreboot/coreboot.html

222 49 12 years ago

lennartb.home.xs4all.nl

penguindev2• 12 years ago

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."

Mind. Blown.

yuhong10• 12 years ago

In fact, I think all modern BIOSes uses CAR.

penguindev2• 12 years ago

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.

wfunction• 12 years ago

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?)

simcop2387• 12 years ago

Apparently it's done through controlling the MTRR registers on the CPU:

http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf

rbanffy2• 12 years ago

System RAM is not enabled yet

Is this something that happens to the children of the IBM PC or is this "feature" present in other machines?

I understand someone may want to tune memory controller parameters, but can't it initialize itself with sensible defaults?

kijiki• 12 years ago

The exact timings depend on the exact chips used, and a specific CPU could be connected to many different types.

You have to query something (often a eeprom) to determine what sort of timings you need, and then program the memory controller appropriately.

magila• 12 years ago

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.

aortega3• 12 years ago

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.

xobs• 12 years ago

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...

yuhong10• 12 years ago

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.

higherpurpose• 12 years ago

That kind of defeats the purpose of open source firmware, doesn't it?

yuhong10• 12 years ago

Remember that TianoCore itself is open source.

pgeorgi7• 12 years ago

Prototypes exist (eg https://github.com/pgeorgi/edk2 or http://notabs.org/coreboot/duet-payload/). But UEFI just isn't that great.

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.

yuhong10• 12 years ago

I remember reading a page that said it was because of ACPI. I will try to dig out a reference.

yuhong10• 12 years ago

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.

microcolonel2• 12 years ago

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.

guylhem3• 12 years ago

Some practical details on a Thinkpad X60 (http://www.coreboot.org/Board:lenovo/x60/Installation, check for yourself how it works on on https://www.youtube.com/watch?v=HKdLhbmjrDI)

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

I'm using grub2 as a payload, and that's what I call a fast boot for a debian Wheezy (details on http://www.coreboot.org/pipermail/coreboot/2014-July/078215....)

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.

yuhong10• 12 years ago

I don't think Computrace is that bad.

serf• 12 years ago

It's not bad, but it is a rootkit. Some people don't want that functionality to exist regardless of who is handed the keys.

aortega3• 12 years ago

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.

userbinator5• 12 years ago

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. ;)

guylhem3• 12 years ago

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)

throwawayaway• 12 years ago

does coreboot for the thinkpad x60 have the same SATA hack that the closed source midleton third party bios has?

listic2• 12 years ago

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?)

sounds2• 12 years ago

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.

The X60 is a good option, too.

userbinator5• 12 years ago

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.

Here is someone who could boot the very first version of DOS on a Ivy Bridge system: http://www.msfn.org/board/topic/153995-will-ms-dos-3x-run-on...

maaku• 12 years ago

Here is someone who could boot the very first version of DOS on a Ivy Bridge system

I would not be surprised if there is someone at Intel or Microsoft whose job it is to do just that for every release.

rbanffy2• 12 years ago

I wouldn't be surprised if someone at Microsoft had the job of making sure every new proposed standard breaks Linux somehow.

pgeorgi7• 12 years ago

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.

userbinator5• 12 years ago

The fastest entry into pmode I've seen is InsydeH2O BIOS which does it in <10 instructions.

gcb4• 12 years ago

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...

userbinator5• 12 years ago

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.

Introduction to Coreboot, an open source BIOS

Related Stories