8 ms·

Introduction to Coreboot, an open source BIOS

222 points by tbrock 12y ago

penguindev 12y 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.
- yuhong 12y ago
  In fact, I think all modern BIOSes uses CAR.
- penguindev 12y 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 12y 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 12y ago
    Apparently it's done through controlling the MTRR registers on the CPU: http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf
- rbanffy 12y 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 12y 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 12y 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.
  - aortega 12y 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 12y 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-novena/board/kosagi/novena/ddr3.c#L1005 https://github.com/xobs/u-boot-novena-spl/blob/u-boot-spl-no...
deleted 12y ago
[deleted]
yuhong 12y 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 12y ago
  That kind of defeats the purpose of open source firmware, doesn't it?
  - yuhong 12y ago
    Remember that TianoCore itself is open source.
    - pgeorgi 12y ago
      The open source part of Tiano doesn't make a firmware on x86. It's missing _all_ early hardware init because Intel considers that secret. Combining coreboot and Tianocore can build an open source x86 UEFI. But unless you need the network boot feature, UEFI is a waste of time and space.
      - yuhong 12y ago
        You can boot Windows with UEFI, and it is easier to implement than legacy BIOS (which requires a lot of reverse engineering).
        pgeorgi 12y ago
        legacy BIOS: see www.seabios.org, written in C. It's good enough for KVM (that Linux virtualization technology), which boots Windows all the time.
        deleted 12y ago
        [deleted]
guylhem 12y ago
Some practical details on a Thinkpad X60 (http://www.coreboot.org/Board:lenovo/x60/Installation http://www.coreboot.org/Board:lenovo/x60/Installation, check for yourself how it works on on https://www.youtube.com/watch?v=HKdLhbmjrDI 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.html 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 http://www.coreboot.org/SeaBIOS and http://www.coreboot.org/pipermail/coreboot/2014-February/077306.html 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-computrace-revisited/ 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.
- yuhong 12y ago
  I don't think Computrace is that bad.
  - serf 12y 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.
  - aortega 12y 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.
userbinator 12y 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-a-modern-pc/#entry1076011 http://www.msfn.org/board/topic/153995-will-ms-dos-3x-run-on...
- maaku 12y 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.
  - rbanffy 12y ago
    I wouldn't be surprised if someone at Microsoft had the job of making sure every new proposed standard breaks Linux somehow.
- pgeorgi 12y 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.
  - userbinator 12y ago
gcb4 12y 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...
- userbinator 12y 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.
deleted 12y ago
[deleted]

222 points by tbrock 12y 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.

yuhong 12y ago
In fact, I think all modern BIOSes uses CAR.
penguindev 12y 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 12y 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 12y ago
  Apparently it's done through controlling the MTRR registers on the CPU: http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf
rbanffy 12y 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 12y 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 12y 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.
- aortega 12y 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 12y 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-novena/board/kosagi/novena/ddr3.c#L1005 https://github.com/xobs/u-boot-novena-spl/blob/u-boot-spl-no...

deleted 12y ago

[deleted]

yuhong 12y 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 12y ago
That kind of defeats the purpose of open source firmware, doesn't it?
- yuhong 12y ago
  Remember that TianoCore itself is open source.
  - pgeorgi 12y ago
    The open source part of Tiano doesn't make a firmware on x86. It's missing _all_ early hardware init because Intel considers that secret. Combining coreboot and Tianocore can build an open source x86 UEFI. But unless you need the network boot feature, UEFI is a waste of time and space.
    - yuhong 12y ago
      You can boot Windows with UEFI, and it is easier to implement than legacy BIOS (which requires a lot of reverse engineering).
      - pgeorgi 12y ago
        legacy BIOS: see www.seabios.org, written in C. It's good enough for KVM (that Linux virtualization technology), which boots Windows all the time.
        deleted 12y ago
        [deleted]

guylhem 12y ago

Some practical details on a Thinkpad X60 (http://www.coreboot.org/Board:lenovo/x60/Installation http://www.coreboot.org/Board:lenovo/x60/Installation, check for yourself how it works on on https://www.youtube.com/watch?v=HKdLhbmjrDI 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.html 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 http://www.coreboot.org/SeaBIOS and http://www.coreboot.org/pipermail/coreboot/2014-February/077306.html 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-computrace-revisited/ 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.

yuhong 12y ago
I don't think Computrace is that bad.
- serf 12y 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.
- aortega 12y 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.

userbinator 12y 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-a-modern-pc/#entry1076011 http://www.msfn.org/board/topic/153995-will-ms-dos-3x-run-on...

maaku 12y 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.
- rbanffy 12y ago
  I wouldn't be surprised if someone at Microsoft had the job of making sure every new proposed standard breaks Linux somehow.
pgeorgi 12y 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.
- userbinator 12y ago

gcb4 12y 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...

userbinator 12y 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.

deleted 12y ago

[deleted]