Announcement

Collapse
No announcement yet.

Open-Source Coreboot Port Working On A Retail Intel Alder Lake MSI Motherboard

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

  • #21
    Originally posted by pietrushnic View Post

    anarki2 what are the most important features that coreboot missing, that you would include if you would have requried resources?
    Features? no. manpower? yes. Every mainboard *must* be ported individually. It's a lot of work.

    Comment


    • #22
      Originally posted by microcode View Post
      Cool cool. I wonder how much it costs to hire them for a board, and how much help they need. Just waiting for the first big Taiwanese board manufacturer to bring this to their whole lineup.

      Edit: cool, they have a Get a Quote form on the Dasharo site.
      microcode feel free to reach us out. Price highly depends on features set and our workload. We already have all necessary agreements with major silicon vendors to deliver solution. Of course for retail mainboard manufacturers which don't want to cooperate by providing schematics we sometimes forced to implement adversarial interoperability, which may rise the cost, but for friendly manufacturers it may be not that expensive. Hiring us for small volume probably doesn't make sense, but if you can gather some crowd or by working with use establish relation with open-source firmware friendly sellers, then even most crazy idea may work.
      twitter | linkedin

      Comment


      • #23
        Originally posted by Developer12 View Post

        Features? no. manpower? yes. Every mainboard *must* be ported individually. It's a lot of work.
        Developer12 agree with manpower, but features that customer care about are also important. Feel free to tune in into our Dasharo OSF vPub Spring 2022 to talk about that. Explaining my position deserve blog post and would not fit here. In short open-source firmware need better economic environment and new business models to be sustainable.
        twitter | linkedin

        Comment


        • #24
          Originally posted by mazumoto View Post
          Whew ... unfortunately not AMD, but I'd probably still buy something like this when they continue this for the next generation of processors/mobos ... I'd love to give coreboot a try.
          mazumoto unfortunately AMD is not easy to play with, we're trying hard, but let's be honest for now Intel has better ecosystem for open-source firmware development. This may be because AMD is in rush, and they are terribly understaffed in all areas in comparison to success they achieved. We're doing AMD open-source firmware development for 6+ years, including our yearly reports of open-source firmware status at FOSDEM, but level of support for small volume firmware developing company is not yet at level of competition.
          twitter | linkedin

          Comment


          • #25
            Originally posted by Developer12 View Post
            It would be nice to support more recent boards with coreboot, but the while intel have continued releasing FSF packages they haven't really gotten any more coreboot-friendly. Quite the opposite.
            Developer12 FSP package was huge win of all open-source community, before that we had to do reverse engineering to get low level initialization and without documentation, which is mostly NDA'ed, there is no way to continue path in light of growing complexity. Simply nobody has enough resources to go that path. So FSP is not bad thing in short run. Of course in light of Intel promises about opening FSP it becomes bigger and bigger liability of whole community, which is bad. This horse was beaten many times - if open-source firmware community wants to win it has to do that by providing value not trying to break ecosystem which was carefully crafted through computer history. Revolution will not help to give better value will do. I had this discussion on coreboot IRC channel [1], [2], [3] (Matrix links).
            twitter | linkedin

            Comment


            • #26
              Originally posted by pietrushnic View Post

              Developer12 FSP package was huge win of all open-source community, before that we had to do reverse engineering to get low level initialization and without documentation, which is mostly NDA'ed, there is no way to continue path in light of growing complexity. Simply nobody has enough resources to go that path. So FSP is not bad thing in short run. Of course in light of Intel promises about opening FSP it becomes bigger and bigger liability of whole community, which is bad. This horse was beaten many times - if open-source firmware community wants to win it has to do that by providing value not trying to break ecosystem which was carefully crafted through computer history. Revolution will not help to give better value will do. I had this discussion on coreboot IRC channel [1], [2], [3] (Matrix links).
              Complexity is nothing. What we need is NDA-free documentation. Take OpenPOWER for example. No NDAs there. Documentation is more important than an FSP code dump, lest we repeat the awful experience with amd's AGESA.

              Nobody in open source is breaking anything. Intel on the other hand have published roadmaps that push coreboot later and later in the boot chain, until it does almost nothing. They want the diversity of final payload that coreboot brings, but don't want to give away any amount of control (or give up any amount of secrecy).

              Carefully crafted? This is a steaming pile of sh*t that was stacked up over 40 years, starting with 16-bit real mode. Do you have any idea how many people wish x86 started up in 64-bit mode like other architectures?

              Comment


              • #27
                Originally posted by Developer12 View Post

                Complexity is nothing. What we need is NDA-free documentation. Take OpenPOWER for example. No NDAs there. Documentation is more important than an FSP code dump, lest we repeat the awful experience with amd's AGESA.
                Developer12 AFAIK you are aware of our experience with porting hostboot to coreboot for Talos II. Please note this presentation where we explain how 800k SLOC of open-source code and claims of documentation availability fall apart when someone trying to check that. Interestingly nobody tried to verify if OpenPOWER really has all documentations available.

                Originally posted by Developer12 View Post
                Nobody in open source is breaking anything. Intel on the other hand have published roadmaps that push coreboot later and later in the boot chain, until it does almost nothing. They want the diversity of final payload that coreboot brings, but don't want to give away any amount of control (or give up any amount of secrecy).
                It is about control more than secrecy. Feel free to check my resume.

                Originally posted by Developer12 View Post
                Carefully crafted? This is a steaming pile of sh*t that was stacked up over 40 years, starting with 16-bit real mode. Do you have any idea how many people wish x86 started up in 64-bit mode like other architectures?
                Let's not mix things. Otherwise, discussion doesn't make sense.

                Of course, it was carefully crafted to deliver revenue to certain groups. There are thousands people working every day to maintain situation. All we're talking here is technology supply chain. Nobody who get money from existing ecosystem in which so much was invested will change way things work, and no technical argument make difference unless proven to earn enough money to justify change and potential risk associated with change.

                If you can prove on market that starting x86 in 64bit mode is beneficial to customers and will provide so big revenue, then I think you are good to go. Very quickly you will face pile of software not working, and huge investment needed to change that.

                Please note in UEFI spec at end of section "1.3 Goals" states: "Built on existing investment. Where possible, the specification avoids redefining interfaces and structures in areas where existing industry specifications provide adequate coverage. For example, the ACPI specification provides the OS with all the information necessary to discover and configure platform resources. Again, this philosophical choice for the design of the specification is intended to keep barriers to its adoption as low as possible." and who agrees with that statement? Almost every company that counts in computer industry - please check members at promoter or contributor level.
                twitter | linkedin

                Comment


                • #28
                  Originally posted by pietrushnic View Post

                  mazumoto unfortunately AMD is not easy to play with, we're trying hard, but let's be honest for now Intel has better ecosystem for open-source firmware development. This may be because AMD is in rush, and they are terribly understaffed in all areas in comparison to success they achieved.
                  AMD makes a great product right now, but Intel still has >80% market share. It makes a lot of sense to go with the market leader when the competition makes you jump through the same (or more) hoops. Maybe AMD will learn this and do better at helping enthusiastic small companies to ship products with their chips.

                  Comment


                  • #29
                    Originally posted by pietrushnic View Post
                    Dear Phoronix Community,
                    I'm Piotr Król CEO of 3mdeb. I just want to let you know that I would be glad to answer all questions and I'm definitely open to suggestions what we should include in the firmware to make it attractive for this expert community.
                    would it be possible to support ecc ram (with supported intel cpu's)?

                    Comment


                    • #30
                      Originally posted by pietrushnic View Post
                      Pardon, my ignorance but what features are most important for OC community?
                      I think things like the different voltages, multiplier and baseclocks, power limits are expected for the CPU. I don't know if tuning individual cores or things like that are really too broadly used outside of benchmark-hunters though.
                      What i would deem even more important nowadays are comprehensive options for RAM-OC as this can yield much more of a performance boost (as nowadays the binning is much more strict and most higher-end CPUs are already running close to their limit). I'm not too familiar with the intricacies of Alder Lake and DDR5 yet, but detailed settings for the different (sub-)timings, voltages (both for the ram and the cpu-side), synchronous or asynchronous operation (at least i think AL does have a similar setting for the ram-controller as AMDs infinity fabric clock?) are the things i would look out for. And of course - as already mentioned in other posts - ECC support would be nice as well ^^

                      To answer question about feature-complete we just started porting we're barely booting Ubuntu for now and not all devices work as expected (e.g. no sound), but we will improve in following weeks and months. We also have limited testing capabilities in comparison to main hardware vendors, so support in testing would be appreciated.

                      Also, if Phoronix Community can suggest what would be the best way to gather suggestions we are also open. For now, it seems for use best to report feature requests to https://github.com/Dasharo/dasharo-issues/issues. Would that work?
                      I think github is the right place for that. Currently i'm not in the market for a new system, but when the time comes i'll surely be looking out what boards got coreboot-support now that modern platform are starting to be an option and willing to play beta-tester (well, as long as all important devices like LAN, sound and SATA/NVMe work ) - really appreciate that effort!

                      Comment

                      Working...
                      X