AMD To Support Coreboot On All Upcoming Processors

nukem996 writes "AMD has just announced that they will be supporting Coreboot (previously LinuxBIOS) on all upcoming processors." That means a flexible Free software BIOS replacement with a nice list of benefits.

Comments

And?

[ledow]

They "support" it now. So do Intel. The problem is not that the processor or even chipset supports it but that the bundled BIOS *IS* coreboot, which is unlikely.

And even then, every tweak made by a motherboard manufacturer has to be taken account of. It's like saying the AMD "supports" running Linux on it. Course it does, but it doesn't mean that the computer can actually run Linux usefully (Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking).

It's a step forward but hardly worth shouting about - when Foxconn, MSI, etc. get on board, then you have a deal. Until then, it's like saying that my computer support FireWire. It does. It just doesn't have any FireWire ports, and I haven't installed the drivers for them on any OS.

Re:And?

[dargaud]

Yes, that's what I was thinking too. I recently wrote my own bootloader for a project. It honestly took me less time to do it from scratch (copy kernel from flash to mem, jump to it, done) than to read, understand and customize Coreboot or U-Boot or one of the many everything but the kitchen sink boot projects.

Re:And?

[jxself]

And even then, every tweak made by a motherboard manufacturer has to be taken account of. It's like saying the AMD "supports" running Linux on it. Course it does, but it doesn't mean that the computer can actually run Linux usefully (Argh! Flashback to the days when a lot machines *couldn't* get basic support under Linux working without patching an tweaking).

It is much easier when you have support from the manufacturer. Previously, AMD would provide preriodic code drops and makes their engineers available. Now, one of their more recent contributions provided the same code that BIOS manufacturers get.

Re:And?

[oxygene2k2]

AMD made their platform code work for coreboot. That is, the same code they ship to board and BIOS makers, they release to coreboot, and even went the extra mile to integrate it.

Intel doesn't support coreboot. In fact, they hinder us and we'll have to get each bit of information out of the hardware or by massive coercion. Every support of Intel hardware in coreboot exists despite Intel's efforts.

Re:And?

[fuzzyfuzzyfungus]

I suspect that, given that Intel specifically designed EFI, and has AMT, their own proprietary PXE-on-Steroids setup; their incentive to support coreboot is relatively small. If somebody shoved a giant pile of cash in their face and said "100,000 Xeon cluster; but only with Coreboot", they might consider doing a custom job; but their roadmap is pretty clearly not in Coreboot's direction.

While that is an issue for people who want Coreboot and Intel, it is arguably an advantage in making AMD play nice. If intel has a variety of proprietary-secret-sauce-but-useful-and-tasty features, AMD will want something to compete. If they decided to support coreboot in order to add these sorts of advanced modern BIOS features, it's a win for both parties. AMD gets powerful preboot features, Coreboot doesn't have to painstakingly reverse-engineer support for every single board they want to run on...

Re:And?

[Barefoot Monkey]

Yes, that's what I was thinking too. I recently wrote my own bootloader for a project. It honestly took me less time to do it from scratch (copy kernel from flash to mem, jump to it, done) than to read, understand and customize Coreboot or U-Boot or one of the many everything but the kitchen sink boot projects.

What you made is a second-stage bootloader. All those really need to do is load some other program into memory and then transfer control to it. Coreboot is a primary bootloader - it handles starting up the computer, setting up the memory and CPU modes, testing harware, providing services such as the hard-drive access that your loader would need, and finally loading your secondary loader for you. Your job was easy because there wasn't much left to do.

Coreboot is more complicated than your loader because yours was piggybacking off something else, whereas Coreboot is that something else on which other people's loaders rely.

I'm not sure if I explained that well, but I hope it helped.

Re:And?

[Ant P.]

I'm pretty sure I've figured out why they do that. Every Intel CPU I've owned in the last 10 years has been crippled and locked down in the BIOS, while the AMD boards enable more or less everything the hardware supports. They don't want you supporting their hardware because it's harder to nickel-and-dime paying customers for basic features that way.

instant computing

[kubitus]

the solution for your quick access to the Internet. I have an ASUS P5Q DeLux with Splashtop.

No need to wait until your OS has booted to get the latest e-mails and/or news.

I wonder why there is no HW manufacturer coming up with Linux in the ROM - ROM chips are big enough for a basic functionality.

The rest may come from the disk.

And its damned hard to overcome a physical write protection and install permanent malware.

Re:instant computing

[The MAZZTer]

You can't patch ROM, and having an unpatched and unpatchable OS is a bad idea no matter which OS that is.

Re:instant computing

[limaxray]

Limited usually being 100,000+ times

I have prototype devices used for development that have had their EEPROMs erased and reprogrammed hundreds of times without any signs of a problem. A customer in the field would never come anywhere close to this.

In any case, this would be better served by flash memory than EEPROM.

Re:instant computing

[_0xd0ad]

i forgot about eeproms emulated using flash which i guess is what they all are now.

Emulated? Flash memory is a type of EEPROM (electronically erasable programmable read-only memory).

back in the day eeproms could only be flashed between 10 and 100 times.

Back in the day 640k of RAM was enough space for anyone, too. Technology has advanced since then...

Did I miss something?

[TheDarkMaster]

Did I miss something?

The problem is not the CPU support, is support for the motherboard... I went to see a list of motherboards "compatible" on Coreboot site and after seeing the definition of "compatible", I concluded that it would be madness to use Coreboot on any motherboard, especially if a newer type.

Do not get me wrong, but if that Coreboot want to replace the BIOS of a motherboard then it should necessarily be 100% compatible, nothing less. How can they say that for example the Coreboot is compatible with the Asus A8N-E, when only one SATA port works and PCI-E 16X do not work?

Re:Did I miss something?

[DrgnDancer]

It's gotten much, much better, but I can remember the days when "compatible" Linux hardware often meant that if you didn't mind missing half the functionality and everything being slow, it was completely compatible. Gods forbid something had "partial" or "experimental" support. I remember installing a scanner once that supposedly had "partial" support. It installed OK, and GIMP was able to use to it, so I was getting pretty excited. Then I tried to scan something. It would only scan approximately a 1 inch square around the very center of the glass. So assuming all you ever wanted to scan was the really small Post-It Notes you were fine.

Luckily the whole thing had been merely an exercise for me; the scanner worked fine on my Windows box, and I'd only tried to get it working on Linux for the experience. It was pretty shocking to see what constituted "partial support" though. Now, of course, nearly everything works with little or no effort. It's not *quite* as plug and play easy as Windows in some cases (though in many cases it is), but rarely do you find a piece of hardware that doesn't work at all or is severely degraded in Linux. Hopefully as time and development proceeds, this will improve as well (but I'm not using it till it does).

Re:Did I miss something?

[ThePhilips]

The problem is not the CPU support, is support for the motherboard...

But the MB manufs won't move until chipset CPU/manufacturers also support the type BIOS.

Do not get me wrong, but if that Coreboot want to replace the BIOS of a motherboard then it should necessarily be 100% compatible, nothing less. How can they say that for example the Coreboot is compatible with the Asus A8N-E, when only one SATA port works and PCI-E 16X do not work?

Yes, you have missed something. Check the server motherboard compatibility list. It is much much more "up-to-date." Apparently people who are struggling most with the carp of proprietary BIOSs are the admins of data centers and server farms. Thus the developer's bias. Me, desktop user, is not on their roadmap.

Re:BIOS on a processor?

[vlm]

Isn't it a motherboard, and not a CPU, that needs to support a BIOS?

I ran into a problem a few years ago with an AMD CPU and an Asys (was it Asus?) MB where the MB bios was old enough that it would read the CPU type info, learn the CPU was newer than it was programmed to understand, and give up all hope. Had to install the oldest AMD CPU I could find, flash the BIOS, then install the brand new fast CPU.

I would assume this means they will give all CPU revision data to the coreboot guys so coreboot can support all (all future?) CPUs in a series without choking.

Re:BIOS on a processor?

[burnin1965]

Isn't it a motherboard, and not a CPU, that needs to support a BIOS?

Yes, read TFA.

AMD is providing coreboot development to support both AMD CPUs and chipsets. They specifically list three motherboards that will utilize coreboot and AMD chipsets and CPUs thus benefiting from AMDs development work on coreboot.

Not exactly

[DrYak]

It used to be the case before :
Most of the functionality (controlling memory, etc.) was done by the chipset on the motherboard. The CPU being almost only a dumb number-crunching unit.
So the BIOS was needed to help initialize this chipset and was mostly tailored to the mother board.

Nowadays, not only CPU cores have much more feature requiring some initialization (sleep states, speed stepping, etc.),
but even some of the functionnality of the chipset, mainly the north bridge, has moved into the CPU.
Low-latency memory controller, sometimes HyperTransport or Quickpath controller, sometimes PCIe controller : All these are now on the same silicon as the CPU (or at least inside the same package for some earlies Intel attempts). On the motherboard, only the south-bridge (lower speed controllers like : the rest of the PCIe, eSATA, old-school PCI, USB, LPC, I2C, etc.) is present and communicates through a standard protocol with the CPU (Hypertransport for AMD, either Quickpath or rebranded PCIe for Intel).

Thus to support a "chipset" (What you're thinking about), you need to both support the northbridge inside the CPU, and the southbridge on the motherboard (as well as a few extra chips which might be useful for booting such as : GPU or serial I/O to display messages, additional mass-storage controllers, ethernet interfaces for networked boot and/or remote diagnostic, etc.)
TFA mentions that AMD works to support both north and south of them, over the enitre product range, from lightweight low-power netbook CPU + Southbridges, all the way to server combination.