Coreboot, what's the deal?

[dan_g]

This Coreboot thingy, does anyone have some hands-on experiences with it? I have looked at their webpages, but no wiser it seems.

It looks very promising. One could perhaps configure it to do things which aren't supported by the original BIOS? Like boot from USB or use a serial text console, or maybe even bolt on some kind of RAID support for the built in ATA ports? There sure are many possibilities...

To be quite honest, the procedures for making a Coreboot image they describe are way over my head. How come there's no BIOS image depository anywhere?

And that rabbit logo, isn't that exactly the same logo Volkswagen used for some of their Golfs?

[cp]

To be quite honest, the procedures for making a Coreboot image they describe are way over my head.

then you shouldn't use CoreBoot. it's still under development and way from production use. there are still many things going on under the hood like software design, basic hardware support, etc.
it's kind of hard to get decent hardware datasheets even for ancient or older components not to mention to problems to get information for any recent hardware. this makes the progress quite slow.
however there are some embedded systems that are quite well supported.

How come there's no BIOS image depository anywhere?

you have to compile them yourself. there's the source for various components and there are targets. the source e.g. for a northbridge can be used for many targets (=mainboards). the target files just include which source should be compiled and some mainboard specific stuff (IRQ routing, cpu socket)

[dan_g]

Thanks for your reply.
However, it is a bit amazing that there are no ready made images out there at all. I happen to have access to lots of different computers and I really hoped that someone had made an image for a MB I'd have in reach.

OK, seems I'll have to install Linux and try this out myself.

Must one compile the Coreboot image on the MB for which the BIOS is intended? Meaning, does it suck something out of the existing BIOS chip?

[cp]

However, it is a bit amazing that there are no ready made images out there at all.

There are no ready made images because there are options to be set BEFORE compiling the image (like cpu type, etc.)

OK, seems I'll have to install Linux and try this out myself.

yes :) a simple debian basic install will be sufficient.

Must one compile the Coreboot image on the MB for which the BIOS is intended? Meaning, does it suck something out of the existing BIOS chip?

both yes. make sure you have a board that's already supported if you want a quick success. if you want to support the team there are tools that read out things like irq routing and pci device ids. those are needed to create a new target (= support a new mainboard).

[dan_g]

CP, thank you for being so patient with a beginner like me...
Just two more questions.
The first being perhaps wishful thinking.

Is there some utility that overrides the normal BIOS and instead reads in an image from the MBR or floppy? I seem to remember that Compaq had such a BIOS system very long time ago. In those ugly all-in-one machines that were a kind of proto-iMacs. The BIOS, or greater part of it resided somewhere on the HDD. The idea is of course that it would be less risk in trying out various BIOS stuff that way. I guess the possibility of such a utility would depend on where the BIOS code is executed from, the actual ROM chip or a mirrored image of it somewhere in RAM.

Secondly, if I manage to make a nice little Coreboot image, would it be a bad thing to post it somewhere here you think?

[dan_g]

The old computer I was referring to was the Compaq Presario 524 Desktop PC and it apparently had a hidden hard disk partition for its BIOS. A friend of mine had bought one of those and unknowlingly formatted its HDD. It was a bit like cutting off your head. After next reboot the computer was dead. It took a while before we understood all the oddities about the BIOS residing in a hidden partition and needing a special floppy to recreate it. Ah, those were the days!

Well, couldn't this hidden partition BIOS thing be tried on a modern system in order to facilitate a more 'plastic' testing environment?

[cp]

Is there some utility that overrides the normal BIOS and instead reads in an image from the MBR or floppy?

i'm not aware of such a utility. and i don't really like the idea because the mainboard would be kind of useless if you separate HDD and mainboard.

Secondly, if I manage to make a nice little Coreboot image, would it be a bad thing to post it somewhere here you think?

first you should post it to the coreboot mailing list. they'll answer a lot of your questions for sure.
you can always post anything useful on bios stuff here. that includes coreboot :)

back to the BIOS from HDD thing: the job of a BIOS is the initial setup of hardware like writing registers, testing stuff and detecting various add-ons. the problem with external (=on any other medium than the bios chip) is that the external medium has to be attached to the mainboard permanently and the hardware has to be initialized so that it can read the external medium.

coreboot shows that the size of a BIOS chip is more than enough to hold DECENT coded stuff. the problem is to get information on hardware registers and addresses so that an OS could take over afterwards without crashing.

right now the situation is some kind of weird. the BIOS initializes the hardware. once the OS takes over drivers are loaded. some drivers reconfigure the hardware to gain some performance or to avoid some flaws/hardware bugs. the OS shouldn't be botherd with hardware reconfiguration, it should just USE the hardware and accept it's capabilities. but i guess that's still a very long road to go.

[dan_g]

An update here.
While looking for something entirely else for my motherboard at work, I stumbled onto a Coreboot BIOS image for exactly that motherboard. What are the chances for that?

The image has everything I'd choose myself, like support for booting Windows, since we're an XP only company.

The native Asus flasher didn't want to flash it and neither did Uniflash, but there's some Linux utility as well. Got to try that out. Will get back to you guys when there's some more progress.

[sharky]

While looking for something entirely else for my motherboard at work, I stumbled onto a Coreboot BIOS image for exactly that motherboard. What are the chances for that?

Ready-made coreboot images are rare because everyone wants different features. Where did you find that image and what's the exact name of your board? Not every board is supported perfectly.

The native Asus flasher didn't want to flash it and neither did Uniflash, but there's some Linux utility as well.

Usually you can flash almost every BIOS/firmware image (yes, coreboot as well) with the Linux/BSD/OSX utility flashrom. Make sure you get the latest version (0.9.1) because it has builtin paranoid checks and will warn you if anything goes wrong (and thus you can recover easily).

back to the BIOS from HDD thing: the job of a BIOS is the initial setup of hardware like writing registers, testing stuff and detecting various add-ons. the problem with external (=on any other medium than the bios chip) is that the external medium has to be attached to the mainboard permanently and the hardware has to be initialized so that it can read the external medium.

Agreed. And even if the external hardware was initialized automatically (which it isnt) and if all buses between CPU and that external hardware were initialized automatically (no way), the CPU still wouldn't be able to fetch its first instructions from said external hardware (how should it know where to look?). Even if somebody solved all the problems above (thousands line of C firmware code would have to be transformed into silicon, waaaaaay expensive), it still would not work because RAM is disabled during early initialization, so it is not possible to load anything from HDD/floppy/USB/serial/whatever because there's no RAM to store it in.

The first instructions executed on every x86/x86_64 CPU are in a very restricted 16-bit environment (no RAM, no cache, only the registers and instructions you know from the 8086) and you only have 16 bytes room for instructions at the inital execution location. That's why the first instruction usually is a jump out of that space (did I mention that most useful jump instructions are defined to crash the CPU at that point?). If you touch certain registers, the CPU will crash. If you use the wrong jump instructions, the CPU will crash. Since you have no RAM (and no cache), you can't use the stack either. 32-bit (or 64-bit) instructions are no-go. Interrupts are no-go. DMA needs memory -> no-go.

Now let me explain what some vendors mean by "BIOS on disk". Basically, they have a full BIOS in flash/ROM and because they wanted to save a few cents on the flash chip, those parts of the BIOS which are executed late after HDD init (BIOS menu etc.) can be loaded from disk. Which also means stuff like netbooting will fail if you remove the HDD (stupid). EFI has this designed in as "feature".

[dan_g]

Impressive knowledge! Hats off.
As you may have already deduced, I'm not quite up to your levels in this field guys. The motherboard at work is an:

Asus M2V-MX SE

and I found the image somewhere at Coreboot's site.

I haven't yet attempted flashing the BIOS with the Linux utility.
I guess I'm a bit chicken here. The BIOS is directly soldered onto the mainboard. We have som 30 of these machines in the house.

I will keep you posted on the development when it happens.

[sharky]

Impressive knowledge! Hats off.

Thanks! I have been doing x86 firmware development for the last few years and it's my goal to help others understand the environment firmware runs in and what firmware can do.

Asus M2V-MX SE and I found the image somewhere at Coreboot's site.

Probably here: http:// www. coreboot. org /ASUS_M2V-MX_SE
Please note the image linked from there is marked as "Warning: Windows won't boot with the hacked VGA image. You will need to exchange the image for original VGA ROM".

AFAIK the M2V-MX SE is pretty well supported in coreboot (at least according to the coreboot wiki) and the chipset docs are available, so any bugs can be fixed rather easily.

I haven't yet attempted flashing the BIOS with the Linux utility.
I guess I'm a bit chicken here. The BIOS is directly soldered onto the mainboard. We have som 30 of these machines in the house.

You could ask on the coreboot mailing list about the current status (and maybe an updated image). Anyway, if you have ~30 machines, it may be possible to sacrifice one or two for testing. Even if they end up as bricks, you don't have to desolder the whole flash chip. Often it is enough to use the "top hat flash" method of sticking a second chip on top with some additional circuitry which disables the soldered chip until you have booted successfully. No guarantees about that method working on that board, though (I don't own it, so I'm hesitant to guarantee anything).


P.S. I am not allowed to post links yet, but I think you can do cut-n-paste and remove the spaces if you need it ;-)

[dan_g]

I couldn't sacrifice one machine to become a brick. Even though the hardware isn't mine, I have resposibility for it. And my conscience stops me too. The top hat flash method sound interesting though. Is there some detailed description as to how this is done?

One of my main principles is reversibility. I want to be able to roll back what I've done and cut my losses.

In the end I guess the only good way is to heed CP's good advice and roll my own. The Coreboot features are apparently mostly interesting for machines that run Linux or Unix. We do have a couple of servers running FreeNAS, SuSE and Debian. Some of them are really old stuff, like PIII 700MHz. They also feature nice DIL chips one can pry out easily.

This thread has really proven educational. BIOS is a bit of voodoo for many of us.

[sharky]

I couldn't sacrifice one machine to become a brick.

Ah. With "brick" I meant you have to resort to either desoldering or top hat flash to recover. I've yet to see a machine which was permanently bricked from such experimentation.

The top hat flash method sound interesting though. Is there some detailed description as to how this is done?

http://www.pcstats.com/articleview.cfm? ... 835&page=3 and http://www.coreboot.org/pipermail/linux ... 20384.html may have some useful info for you. Basically, the idea is to temporarily deactivate the soldered chip and boot from another chip piggybacked on top of it. Depending on the wiring of your board (pullup/pulldown strength for some lines etc) it may be possible to use non-invasive top hat flash, but you'd have to check with a multimeter.

One of my main principles is reversibility. I want to be able to roll back what I've done and cut my losses.

It all depends on how many traces you're allowed to leave... if the RMA department ever looks at the board with a microscope, you want a completely non-invasive top hat flash variant.

In the end I guess the only good way is to heed CP's good advice and roll my own. The Coreboot features are apparently mostly interesting for machines that run Linux or Unix. We do have a couple of servers running FreeNAS, SuSE and Debian. Some of them are really old stuff, like PIII 700MHz. They also feature nice DIL chips one can pry out easily.

If your board has a decent ACPI implementation in coreboot (and I think your board does have that) you can boot Windows XP/Vista/7 without problems.
About the PIII boards you mention: If those are i440bx based boards, there is a good chance they already are supported or can be supported with a few hours of hacking.

it's kind of hard to get decent hardware datasheets even for ancient or older components not to mention to problems to get information for any recent hardware.

Actually, AMD and VIA have been pretty open with their documentation for recent chipsets. http://www.coreboot.org/Datasheets has an overview (and links) for quite a few chipsets and processors. There are more datasheets out there, but not every datasheet is linked from that page.