Announcement

Collapse
No announcement yet.

The Current State Of Coreboot & Open-Source Firmware For AMD Hardware In 2023

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

  • #11
    Ahh, the MS certification make a lot of sense. Thanks!

    Comment


    • #12
      Originally posted by hauberg View Post
      Can anyone explain to me why coreboot is not more popular with CPU producers (Intel, AMD)? I understand that both developing a traditional bios and coreboot is too expensive but why not focus on coreboot exclusively? I'm sure there's an argument but I'd love to have it laid out so I could understand it.
      It would probably get more traction if MS supported coreboot. Then it could be used for more than just chromebooks and random embedded programs. It's a huge amount of work (basically maintaining two bioses, albeit with some shared components) and why would you want to to do it if no one is going to use it? Maybe something like UDK could get more traction. IIRC, that is compatible with MS and it is open source, but it's not coreboot so it doesn't work directly with current Chromebooks.

      Comment


      • #13
        Thanks, indeed the MS issue explains a lot. I wouldn't want to maintain two stacks either so it's (sadly) not unreasonable that coreboot isn't widespread.

        Comment


        • #14
          Doesn't Windows work with either the seabios or UEFI payload?

          Comment


          • #15
            Originally posted by agd5f View Post
            It would probably get more traction if MS supported coreboot. Then it could be used for more than just chromebooks and random embedded programs. It's a huge amount of work (basically maintaining two bioses, albeit with some shared components) and why would you want to to do it if no one is going to use it? Maybe something like UDK could get more traction. IIRC, that is compatible with MS and it is open source, but it's not coreboot so it doesn't work directly with current Chromebooks.
            Who says that Coreboot can't be used for Windows?




            Missing ReBAR (It works on Linux since amdgpu seems to force a full PCI MMIO reallocation), but it works.

            Comment


            • #16
              Originally posted by zir_blazer View Post
              Who says that Coreboot can't be used for Windows?




              Missing ReBAR (It works on Linux since amdgpu seems to force a full PCI MMIO reallocation), but it works.
              Is that official support from MS?

              Comment


              • #17
                Originally posted by agd5f View Post

                Is that official support from MS?
                No, nor I am expecting official support anytime soon. But some guys from Microsoft are involved in Project Mu which seems to be a modified EDK2 payload, which can be used as payload of coreboot, so you can say that Microsoft is toying with open source Firmware: https://www.reddit.com/r/coreboot/co...in_project_mu/
                Still, the point is that it works. A lot of people believes than Coreboot is Linux only and can't be used for Windows devices.

                Comment


                • #18
                  AMD Phoenix 2 APUs Spotted Within Coreboot, Features Cut-Down RDNA 3 GPU With Half The L2 Cache

                  Comment


                  • #19
                    Originally posted by binarybanana View Post
                    Most modern UEFI firmwares seem to be based on Intel's free reference implementation (also used on qemu, for example)
                    There is a misunderstanding what your UEFI actually is.
                    Your firmware consists of (at least) two parts, the part that inits the hardware, setups and trains ram etcs and something on top of that that handles the user facing and OS facing parts. Just like Coreboot and a payload like EDK2 on top. The underlying part of your usual x86 firmware has its roots in the BIOS days, EFI was mostly put on top of it.

                    QEMU only needs the top layer, which why it also isn't using coreboot, just the payload like SeaBIOS and EDK2.

                    Especially Ram Training is highly proprietary, something Firmware vendors like AMI protect with all their might.

                    Comment


                    • #20
                      Originally posted by Alexmitter View Post

                      There is a misunderstanding what your UEFI actually is.
                      Your firmware consists of (at least) two parts, the part that inits the hardware, setups and trains ram etcs and something on top of that that handles the user facing and OS facing parts. Just like Coreboot and a payload like EDK2 on top. The underlying part of your usual x86 firmware has its roots in the BIOS days, EFI was mostly put on top of it.

                      QEMU only needs the top layer, which why it also isn't using coreboot, just the payload like SeaBIOS and EDK2.

                      Especially Ram Training is highly proprietary, something Firmware vendors like AMI protect with all their might.
                      I mean the UEFI bits are based on that same EDK2 or some common ancestor at least. I don't think modern firmwares are based on legacy BIOS code in any meaningful way (other than maybe CSM/legacy boot, like EDK2 can be built with seabios), but you are right there are proprietary blobs for hardware initialization. Intel has a stand-alone version of this blob which is what coreboot is using. It's not really related to UEFI or BIOS. But you need that to boot anything. It's lower level firmware than even UEFI is.

                      EDIT: Apparently coreboot on qemu is a thing: https://www.coreboot.org/QEMU
                      Last edited by binarybanana; 07 February 2023, 09:46 AM.

                      Comment

                      Working...
                      X