Announcement

Collapse
No announcement yet.

Coreboot Now Has An Official GRUB2 Payload

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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?

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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

              Comment


              • #8
                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?

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X