Coreboot Sandy/Ivy Bridge Gains Native RAM Initialization
Phoronix: Coreboot Sandy/Ivy Bridge Gains Native RAM Initialization
The latest addition to Coreboot is native RAM initialization support for Intel's Sandy Bridge and Ivy Bridge families...
why is the comment page sometimes off
Originally Posted by phoronix
and what is actally native RAM init? How does it differ from AMD systems?
But the real question is
Which hardware is actually supported by coreboot?
I wish I could boot my netbooks, notebooks and a couple of servers by HP off coreboot.
But so far, there is almost nothing currently in the market I can install it to.
So why all this interest in coreboot?
The interest in coreboot stems from the dream of a fully FOSS system. It's a FOSS replacement for what is usually a proprietary component in computers. Even if it doesn't have widespread hardware support, it's an interesting project, especially for FOSS enthusiasts.
Originally Posted by Uqbar
... Just like a project about coding a new OS for the PDP-11.
Originally Posted by Plombo
It'd be as interesting as useless but for those who own actual working hardware.
I wouldn't ad such a project on Phoronix!
This is just my opinion, of course.
I sure would, we can thank Michael for that.
Originally Posted by Uqbar
Before intel or google provided a binary program that was jumped into to initialize RAM.
Originally Posted by jakubo
AMD pedged support for AM3 chipsets and later, so all of them should already be native, AFIAK.
What I hate about x86? BIOS/UEFI in first place.
Here we can see how sucking proprietary software could be. Just one example: my computer's BIOS would hang if you press someything on USB keyboard between BIOS logo disappearance and boot loader start. The issue is that boot loaders (GRUB included) are often invoked by holding some key or combo. In GRUB you have to hit shift before it starts and it would show you extended menu rather than booting quickly. The prob? BIOS would lock up in 50% of cases or so. Hit shift half-second too early? Now press reset, dude and try again. Needless to say, this annoying bug will never get fixed. And everyone else can't try to fix that bug because its blob-only. So proprietary BIOS is really worst part of my x86 system. If it sounds not too scary, there is brand new UEFI and of course it is binary-only as well and also often offers you some "protection" known as secure boot. It "protects" you from installing systems not signed by M$, making it far from trivial and granting MS exclusive control over x86 platform. Really crappy state of things, to say the least. Hopefully it explains why some people started to prefer opensource solutions :-).
I hope to live long enough to see my primary computer booting fully opensourced stack, beginning with early boot loaders. Its already here on ARM boards with things like u-boot, but x86 is really bad at this regard to the date.
Not exactly true. UEFI BIOS is great beacuse it lets your system fast boot, provides additional security against boot sector viruses for casual users.
Originally Posted by 0xBADCODE
UEFI BIOS was also needed because all modern hard drives require GPT partitioning instead of MBR. Without UEFI you can't boot from a GPT disk and you'd need some old MBR disk for booting.
Additionally computer hardware has got very complex. It's not possible to have 64 kB BIOSes anymore, modern UEFI BIOS is tens of megabytes.
UEFI BIOS can also support wider variety of hardware. Such as GPU accelerated fullhd video, bluetooth devices out of the box. For example all Mac owners know how great it is that you can install OS from scratch and have only bluetooth devices. Same thing on PC. Plug your bluetooth dongle in and start setting up Windows installer on UEFI BIOS. Bluetooth HID is a standard so it just works. Old legacy x86 BIOS didn't necessarily even support usb keyboard, only ps/2.
Originally Posted by caligula
Secure boot on x86 need to have an off switch to qualify for microsft windows 8 ready or OEM certification. Then you can use the UEFI loader program to jump right into a linux kernel, or windows, or Grub ... Most of the issues in jumping into something other than windows are caused by improper implementation of the UEFI loader by the BIOS vendor (bad vendor code is nothing new and is probably the best argument for the need for OSS firmware)
UEFI drivers are nice, but should we really trust a newtorking stack in a proprietary BLOB that we can't modify.
UEFI is huge, and not yet fully tested. It does thing BIOS couldn't do, but perhaps that's too much..
TianoCore is the BSD licensed reference implementation of UEFI, but lacks the drivers needed to actually boot any system.
GPT/MBR is just a formatting choice, if the disk has nothing you need to save, conversion is trivial, and most people don't hit the limitations of MBR format anyways. There are also hydrid formats that look like MBR to the bootloader and GPT to the OS.
BIOS sucks and needs replaced, but I think UEFI was the wrong way to go. It tries to be everything for everyone, rather then the simple conduit between power off and hardware ready that it should be. Coreboot-Grub is fast, and if you dare try it Coreboot->Kernel is on the fastest boots you can have. UEFI->Kernel is pretty dang fast as well, but should I really trust it?
Last edited by WorBlux; 07-29-2014 at 11:15 PM.