Originally posted by pietrushnic
View Post
Announcement
Collapse
No announcement yet.
Open-Source Coreboot Port Working On A Retail Intel Alder Lake MSI Motherboard
Collapse
X
-
Originally posted by microcode View PostCool 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.
- Likes 3
Comment
-
Originally posted by Developer12 View Post
Features? no. manpower? yes. Every mainboard *must* be ported individually. It's a lot of work.
- Likes 2
Comment
-
Originally posted by mazumoto View PostWhew ... 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.
- Likes 6
Comment
-
Originally posted by Developer12 View PostIt 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.
- Likes 4
Comment
-
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).
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?
- Likes 6
Comment
-
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.
Originally posted by Developer12 View PostNobody 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).
Originally posted by Developer12 View PostCarefully 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?
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.
- Likes 4
Comment
-
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.
- Likes 4
Comment
-
Originally posted by pietrushnic View PostDear 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.
- Likes 3
Comment
-
Originally posted by pietrushnic View PostPardon, my ignorance but what features are most important for OC community?
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?) - really appreciate that effort!
- Likes 3
Comment
Comment