Results 1 to 10 of 10

Thread: Coreboot Now Has An Official GRUB2 Payload

  1. #1
    Join Date
    Jan 2007
    Posts
    14,553

    Default Coreboot Now Has An Official GRUB2 Payload

    Phoronix: Coreboot Now Is An Official GRUB2 Payload

    Coreboot's latest development code now features GRUB 2 as an alternative to SeaBIOS in its build system...

    http://www.phoronix.com/vr.php?view=MTUxODk

  2. #2
    Join Date
    Jul 2009
    Posts
    250

    Default

    as i understand it: coreboot does initialise system hardware on the mainboard and cpu. But what about bios features as CnQ, limitation of cpucores, hyper threading, setting frequencies, boot order, ACPI and stuff. is its still possible to set them? how does it work without classic bios?

  3. #3
    Join Date
    Dec 2011
    Posts
    2,021

    Default

    Quote Originally Posted by jakubo View Post
    as i understand it: coreboot does initialise system hardware on the mainboard and cpu. But what about bios features as CnQ, limitation of cpucores, hyper threading, setting frequencies, boot order, ACPI and stuff. is its still possible to set them? how does it work without classic bios?
    Those are technically not BIOS features. Those are firmware features.
    I guess that belongs to hardware initialization maybe?
    Some settings can be configured at compile time but coreboot (or SeaBIOS) have no CMOS setup utility to configure it at runtime.

  4. #4
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,537

    Default

    Quote Originally Posted by jakubo View Post
    as i understand it: coreboot does initialise system hardware on the mainboard and cpu. But what about bios features as CnQ, limitation of cpucores, hyper threading, setting frequencies, boot order, ACPI and stuff. is its still possible to set them? how does it work without classic bios?
    The whole idea of Coreboot is to put the hardware into a usable state, any usable state, as fast as possible, and pass control to the payload as soon as possible. All the features you describe are supposed to be configured down the boot chain, either from the payload itself or the operating system (which can by itself act as a payload). As for boot order (or rather boot location, Coreboot just boots the payload), I think it's determined at compile time.

  5. #5
    Join Date
    Sep 2011
    Location
    Rio de Janeiro
    Posts
    201

    Default

    Quote Originally Posted by GreatEmerald View Post
    The whole idea of Coreboot is to put the hardware into a usable state, any usable state, as fast as possible, and pass control to the payload as soon as possible. All the features you describe are supposed to be configured down the boot chain, either from the payload itself or the operating system (which can by itself act as a payload). As for boot order (or rather boot location, Coreboot just boots the payload), I think it's determined at compile time.
    Thank you for your explanation. So if I understand it correctly, in order to coreboot to become a full blown substitute to the good old bios, either the OSs will have to incorporate these ajustments, or a payload needs to be written to perform this function. Problem is these setings are almost all hardware extremelly hardware specific, so it may not be possible to have a single solution supporting a large pool of hardware.

  6. #6
    Join Date
    Dec 2011
    Posts
    2,021

    Default

    Quote Originally Posted by Figueiredo View Post
    Thank you for your explanation. So if I understand it correctly, in order to coreboot to become a full blown substitute to the good old bios, either the OSs will have to incorporate these ajustments, or a payload needs to be written to perform this function. Problem is these setings are almost all hardware extremelly hardware specific, so it may not be possible to have a single solution supporting a large pool of hardware.
    Coreboot supports a large of hardware.
    But when you compile it, you compile it for a specific hardware.

    Then Coreboot just does the hardware initialization.
    Then you can pass over the control to SeaBIOS (for legacy BIOS support), or to TianoCore (for UEFI support), or to other payloads such as GNU GRUB or the Linux kernel.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    Quote Originally Posted by Figueiredo View Post
    Thank you for your explanation. So if I understand it correctly, in order to coreboot to become a full blown substitute to the good old bios, either the OSs will have to incorporate these ajustments, or a payload needs to be written to perform this function. Problem is these setings are almost all hardware extremelly hardware specific, so it may not be possible to have a single solution supporting a large pool of hardware.
    Aye, but Linux already supports many of those, and adding the rest is just a question of someone bothering. I'd rather trust Linux to change hw settings than a BIOS - one of those you can fix

  8. #8
    Join Date
    Jul 2009
    Posts
    250

    Default

    so would it basically be possible to make some automatic hardware recognition via flashrom, make it choose the right devices/firmware/drivers from a trusted drivers' list (if available), compile the bin and finally flash it via flashrom?
    But you wont be able to change CPU (for instance) afterwards, right?

  9. #9
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by jakubo View Post
    so would it basically be possible to make some automatic hardware recognition via flashrom, make it choose the right devices/firmware/drivers from a trusted drivers' list (if available), compile the bin and finally flash it via flashrom?
    I think it's doable, but I ignore if it is already done. However, in that case you must be working on the machine you are about to flash, and I don't think that's the best approach, if something goes wrong it is preferable to have all of your configuration (to check it) in a working machine.
    But you wont be able to change CPU (for instance) afterwards, right?
    I think you would only be unable to change your CPU family, and AFAIR motherboards are usually for a given family anyway. My knowledge might be really obsolete in this subject, though.

  10. #10
    Join Date
    Mar 2011
    Posts
    375

    Default

    Quote Originally Posted by mrugiero View Post
    I think it's doable, but I ignore if it is already done. However, in that case you must be working on the machine you are about to flash, and I don't think that's the best approach, if something goes wrong it is preferable to have all of your configuration (to check it) in a working machine.
    Well, you could do everything except flashing, then transfer it to another machine so you have it backed up, then flash.
    I think you would only be unable to change your CPU family, and AFAIR motherboards are usually for a given family anyway. My knowledge might be really obsolete in this subject, though.
    There are two factors: First the socket (logically you can't put a CPU into a socket not made for it) and then the microcodes the BIOS includes. A good example for this are AM3+ CPUs, they are backwards compatible to older sockets but many motherboard vendors didn't ship a compatible BIOS, so you can't use them. But some do and there you can use AM3+ CPUs even if the mainboard wasn't made for them in the first place.
    I don't think this is different with coreboot, except that you're able to decide which microcodes to include, but I don't know.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •