Announcement

Collapse
No announcement yet.

The Mission Of Coreboot - Is It About Open-Source Or Appeasing Hardware Vendors?

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

  • #21
    Maybe just rename it from coreboot to crustboot, and change their logo from a rabbit running away as fast as it can in to a MIB catching it and fking it.

    That would be more honest and factually accurate.

    Comment


    • #22
      Originally posted by woife View Post

      I fully agree.

      And just because some blobs are still required doesn't mean that there is no progress.
      Intel's FSP is often mentioned as an example, but FSP actually consists of three different parts:
      • FSP-T: Initialize "Cache as RAM"
      • FSP-M: Initialize RAM
      • FSP-S: Silicon init
      From those you only need the last two, because the first one is already implement in Coreboot.
      (Details may vary depending on FSP version and platform, and I have only used Coreboot a few times, so don't take that information as fully reliable)
      This is an area where, respectfully, the vendor pulled the wool over your eyes quite nicely. CAR setup is not hard, or rather it used to be fairly easy. Nowadays the "CAR setup" runs in an already partly initialized system, preconfigured by the ME/PSP -- there's nothing to be gained by keeping the tiny "turn CAR on in this partly configured environment" code secret. The ME/PSP has started doing the actual heavy lifting, but you are treating this migration from closed BIOS code to signed/locked ME/PSP code as a good thing.

      Look at all the setup required by the SBE on a fully powered down POWER system. You can read all the source at https://git.raptorcs.com/git/talos-sbe/ That's what real CAR setup looks like on a modern platform. Still think you got a net win over the vendor here with FSP-T?

      Comment


      • #23
        Originally posted by schmidtbag View Post
        This is an absurd argument. Having something open-source in your firmware is better than nothing.
        Cool! Lets say I've got a set top box here that uses 10 lines of coreboot to load a DRM enforcing OS. The megabytes of vendor firmware before it, and the gigabyte of vendor binaries after it, are signed, locked, and encrypted. I can look at those 10 lines of code, but not touch.

        Would you choose this set top box over a cheaper, fully proprietary model just because of those 10 lines of open source?

        Have you actually looked at the ratio of open code to vendor binaries in coreboot for modern platforms, including the ME/PSP and microcode?

        Comment


        • #24
          Originally posted by bachchain View Post
          Who cares? Any user that goes out of their way to replace their motherboard firmware is going to understand the limitations regardless.
          Then what's the harm of being transparent on the home page? This type of thing is fundamentally why the nutrition facts ended up being mandated, precisely because the vendors advertised tasty but unhealthy food (great analogy, BTW!)

          Comment


          • #25
            Originally posted by c117152 View Post
            ... what's preferable is me_cleaner. Letting Intel and the vendors maintain their hold on our hardware by allowing them to put firmwares in the kernel and coreboot is not something that we should support on the PC.
            This is non-sequitor as written. Did you mean to say something else, or do you not understand that me_cleaner leaves the (mandatory) ME as part of the boot flow? *

            * unless you're referring to a Core 2 era system, but those are a decade old now.

            Comment


            • #26
              Originally posted by bachchain View Post
              Who cares? Any user that goes out of their way to replace their motherboard firmware is going to understand the limitations regardless.
              If this was just about that small group that flashes their firmware, you would be right. But I think this has more to do with educating the less technically advanced who may never alter their existing firmware but may make decisions about what to manufacture, what to stock, and what to buy. Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.

              Comment


              • #27
                I agree that being an open source project and shipping the FSP blob is mutually exclusive. Coreboot should either stop shipping the FSP or stop calling themselves open source and auditable.

                The wording could be changed to the following to make it honest: It aims to bring more Open Source to the boot process, it providing better auditability and increased control over technology.

                Originally posted by phoronix View Post
                The situation around the openness of Coreboot becomes clouded with some vendors like Purism prominently advertising their "open-source" Coreboot support but without mentioning that FSP binaries for example are still being used
                That however is not a Coreboot problem. That is a Purism problem, this company routinely overstates their capabilities in this regard.

                Comment


                • #28
                  Originally posted by marsbase View Post
                  Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.
                  This whole discussion though is about coreboot not really standing for open source per se; right now it's mainly a shim loader / open framework around ME/PSP/FSP/AGESA/BinaryPI/etc. Libreboot is probably a more tangible indicator of open source support, plus there are a couple of other projects that also basically mean fully open now (the IBM POWER stack, oreboot, etc.)

                  Comment


                  • #29
                    Originally posted by marsbase View Post

                    If this was just about that small group that flashes their firmware, you would be right. But I think this has more to do with educating the less technically advanced who may never alter their existing firmware but may make decisions about what to manufacture, what to stock, and what to buy. Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.
                    we're talking about a two sentence product summary. I fear for the future of any company or person that bases any decision solely on that.

                    Comment


                    • #30
                      I really hate these purist arguments that throw shade on companies that pragmatically offer partial support. It helps gain traction and provides suitable entrypoints for contributions. And the people who crusade on this nonsense waste massive amounts of community time, as well as damaging community efforts from their inability to recognize any subtlety at all.

                      No x86 vendors submit full code to booting on modern systems. And open-source shouldn't mandate using decade-old hardware. It reduces marketshare and provides an artificial barrier to entry for people that has no need to exist. Nearly everyone who went FOSS had partially-closed hardware at some point in time, so they need to get off their purist high horses and recognize that ease of entry brings visibility and contributions that the project sorely needs.

                      If you're upset about vendors claiming coreboot functionality when it's *all* blobs, update the ugly-as-hell compatibility matrix to show it and design level qualities/endorsements that illustrate it. For example, bronze only boots with blobs. Silver only has blobs for non-essential pieces. Gold has no blobs. Platinum has no ME/PSP, or allows for it to be disabled.

                      What's the benefit to having a coreboot image that's all blobs? Anyone who hasn't lived under a rock for the past two decades has seen motherboards with the same chipsets offering different functionality and having different bugs. Having 5 bronze-level coreboot images based on the same chipset would allow people to grab different blobs from other vendors in case one vendor drops support early. It would also allow for multiple vendors and users to collaborate on replacing the same binary blob without having the exact same revision of the board from the same vendor.

                      Yes, vendors might take advantage when we allow binary blobs, but lots of issues arise in firmware that lie outside the binary blobs. Like hardware block lists, bad timings, incorrect ACPI tables, incorrect RDRAND settings, sloppy secure boot implementations, etc. Having a partial base to build and collaborate upon is much better than not recognizing community efforts *at all*. And it lets us add additional value in optional packages beyond the basics to multiple boards.

                      And honestly, having LibreBoot as a separate project was always stupid. Compatibility matrices should have been adjusted to show functionality with/without binary blobs, and build scripts should have made blob inclusion optional. Having it be a separate project designed to collect FOSS brownie points for adding patches to remove functionality was a colossal waste of effort and prevented people from working on the same team to maximize availability. Not to mention the massive shitshow of mental instability we get from FOSS purists running the show. Remember when the head of Libreboot decided to attack GNU and drop out entirely on her own? That was a massive waste of time and energy.

                      Now that I've pointed out how having partial support actually helps the community and the consumers, take a moment to consider if you're willing to collaborate with people who can compromise. If not, please kindly fuck off with your attempts to force everyone else to do things your way or face a shame tax. Go bother the people in Libreboot. We've already made community space for one weird purist asshole (RMS) to remind us of the goals. We don't really need more. But you're welcome to challenge him for his position with a trial by combat. Go steal his conch if you need to be heard that much.

                      Comment

                      Working...
                      X