AMD has recently made a decision to supply AGESA as binary-only for future AGESA releases. This decision seems to have caused some grief and disharmony within the coreboot community. I would like to make a proposal that I hope satisfies everyone moving forward.
First some history:
The initial AMD releases to coreboot were not based on either AGESA or CIM-X. Sometime after AMD started contributing AMD 64-bit processor support, someone realized that core libraries were available elsewhere in AMD to initialize the processor and chipset in a standard way (AGESA and CIMX). Ultimately, that turned into the AGESA and CIM-X open-source postings in vendorcode. AMD still develops AGESA for other (proprietary) purposes and relicenses and forks AGESA for new processors for coreboot.
To get to an open-source AGESA, there were meetings and rules put in place within AMD with the intent that AMD would never lose proprietary license or ownership of the trunk AGESA or CIM-X codebases resulting from the contribution. The principal rules are that:
1. No modifications derived from open-source AGESA ever go back into AMD’s codebase.
2. Open-source AGESA always derives from a processor-specific fork of AGESA that is reviewed and edited to remove any proprietary code, identifiers, or concepts.
So AMD accepted that the process of releasing into open-source would be a very large and time-consuming task. No matter how good the process, any automated pruning effort will depend on authors to add tags to code to identify what is proprietary and what is not. Authors tend to make mistakes and therefore require review. So they elected to keep it a manual process.
Jumping ahead to 2013:
AMD realized that the open-sourcing process they developed was awkward and required lots of developer and legal involvement. The six month delay required to implement the “scrub” prevents AMD Embedded from capitalizing on the advertising and press excitement following the introduction of new parts. This delays commercial shipment of systems (and therefore chips) until well into the design cycle of the next processor. Anyone that received early code was required to modify their application when the scrubbed code was eventually released. And they were not allowed to release their product until after they incorporated the scrubbed code.
Please remember that AMD’s primary goal in open-source AGESA is to enable new platforms to sell more chips.
Binary PI was conceived with the sole intent of eliminating the delay caused by the scrub. By donating AGESA as a binary instead of scrubbed open-source, coreboot becomes available much sooner in the lifecycle of a processor. This is good for AMD and good for companies that want to use AMD’s chips.
There are downsides:
· The AGESA binary has to have a well-defined interface. Normal mechanisms to work around interface deficiencies don’t work, so you have to work within the API.
· Since the same BLOB is available to everyone, the API must be as flexible as possible to accommodate varying needs.
· Because there is no scrub, the source must remain proprietary.
· There is less flexibility because you can’t change AGESA to change when, where, or how initialization functions occur.
· There may be a performance or size impact. Binary PI currently runs exclusively from ROM and is not split between a ROM phase and a RAM phase.
The current binary PI implementation requires an Application Programming Interface (API) to insulate the interface from future changes. This is the same AGESA API that has been open-sourced for several processor generations. The API uses processor-specific structures as arguments and therefore must be compiled using header files that accompany the AGESA library releases. Note that this differs from an Application Binary Interface (ABI). I have maintained API compatibility between open-source AGESA and binary PI. This is for two purposes:
1. To allow early reference platform development using an integrated AGESA. The code is easier to debug when it is all contained within one binary.
2. In the hopes that there will be future open-source AGESA contributions from AMD late in the design cycle of a processor, well after binary PI is released.
Proposal:
There has been a request and changelist to split the AGESA wrappers:
1. Slowly migrating open-source AGESA away from the published AGESA API for Llano (F12), Ontario (F14), Trinity (F15tn), Orochi (F15), and Kabini (F16kb).
2. Creating new wrappers for binary PI-based processors, namely Bald Eagle (00630F01), and Steppe Eagle (00730F01).
The same wrappers, or at least wrapper structure, are shared by all of these platforms today. Note that the API is completely contained with the 3rdparty/pi and src/vendorcode/amd subtree. Code in src/mainboard, src/northbridge, src/southbridge, and src/cpu is “wrapper code” and fair game for modification within the coreboot community.
Instead of splitting the wrappers this way, I would propose forking open-source AGESA within the coreboot tree. Let’s COPY the existing vendorcode/amd/agesa into another subtree, maybe soc or devices, and rename it OSIFA (open software interface for AMD) or something similar. Move or clone experimenter boards over to OSIFA.
Let’s leave commercial production boards alone (AMD, ASRock IMB-A180, some tyan, some supermicro, some HP, maybe a few more) using the existing src/…/agesa directories. That leaves the interface stable for the boards AMD needs to demonstrate, allows AMD to continue donating AGESA with their existing interface, yet still allows the community to improve on and reorganize OSIFA.
What do you think … ?
On 11/05/2014 11:50 AM, Bruce Griffith wrote:
AMD has recently made a decision to supply AGESA as binary-only for future AGESA releases. This decision seems to have caused some grief and disharmony within the coreboot community. I would like to make a proposal that I hope satisfies everyone moving forward.
First some history:
The initial AMD releases to coreboot were not based on either AGESA or CIM-X. Sometime after AMD started contributing AMD 64-bit processor support, someone realized that core libraries were available elsewhere in AMD to initialize the processor and chipset in a standard way (AGESA and CIMX). Ultimately, that turned into the AGESA and CIM-X open-source postings in vendorcode. AMD still develops AGESA for other (proprietary) purposes and relicenses and forks AGESA for new processors for coreboot.
To get to an open-source AGESA, there were meetings and rules put in place within AMD with the intent that AMD would never lose proprietary license or ownership of the trunk AGESA or CIM-X codebases resulting from the contribution. The principal rules are that:
No modifications derived from open-source AGESA ever go back intoAMD’s codebase.
Open-source AGESA always derives from a processor-specific fork ofAGESA that is reviewed and edited to remove any proprietary code, identifiers, or concepts.
So AMD accepted that the process of releasing into open-source would be a very large and time-consuming task. No matter how good the process, any automated pruning effort will depend on authors to add tags to code to identify what is proprietary and what is not. Authors tend to make mistakes and therefore require review. So they elected to keep it a manual process.
Jumping ahead to 2013:
AMD realized that the open-sourcing process they developed was awkward and required lots of developer and legal involvement. The six month delay required to implement the “scrub” prevents AMD Embedded from capitalizing on the advertising and press excitement following the introduction of new parts. This delays commercial shipment of systems (and therefore chips) until well into the design cycle of the next processor. Anyone that received early code was required to modify their application when the scrubbed code was eventually released. And they were not allowed to release their product until after they incorporated the scrubbed code.
And the rule for the customer to _not_ release product until the scrubbed code is available remains to be a rule that is dictated by coreboot's GPL license.
Given that there is often a 3rdparty involved, say SAGE, who does coreboot / AGESA integration work under a contract for an end customer, it can be claimed the time of coreboot distribution happens already when said customer receives a copy of coreboot firmware image to test on their platform. And this may happen several months before the release of product to public.
The choice of GPL over LGPL implies a promise to both commercial and non-commercial contributors of coreboot codebase that hardware vendors will need to make necessary files available, so that the customer can rebuild and improve said coreboot firmware for the platform.
You have verified binaryPI uses (almost) exactly the same API as open-source AGESA so far. This complex API between AGESA component and coreboot does not fall under the mere aggregation terms of GPL, it is a form of runtime linking. In other words the distribution of binaryPI violates rights of every copyright holder in the coreboot sourcebase. I am not fond of Google's MRC binary or Intel's FSP either, but their implementation appears to be a single entry/exit with an array of platform configuration data.
Please remember that AMD’s primary goal in open-source AGESA is to enable new platforms to sell more chips.
Yes. And I understand AMD's and SAGE's urges and interest for the early distribution in binary form. The major trouble here is the question has turned from 'When to scrub AGESA' to 'If to scrub AGESA'.
The community needs to evaluate if infrastructure of said binaryPI brings any added value for coreboot, when there is no promise or a schedule for scrubbed AGESA sources. There has been empty promises in the past when it comes to updates for AGESA vendorcode. The community has to deal with what we see going on in the tree, as neither AMD AES or SAGE are not so willing to discuss any of their plans with community.
More importantly, we have an absurd situation here. A claimed compatibility with a source component we have not been promised to ever receive is currently delaying and restricting development of code we already have in the tree.
Personally, I would be willing to flex from the strict GPL terms here for the benefit of the industry, AMD AES, SAGE and the hardware vendor. That would require AMD AES to publish a schedule in which scrubbed AGESA sources under BSD -style license are released, and a regular schedule of bugfixes to previously released open-source AGESA.
My expectations on binaryPI are that it would be virtually impossible to do any community ports of AMD platforms with it. Also concepts of timestamping, USB debug and CBMEM console from romstage appear to be impossible to achieve.
Existing code in the tree suggests even AMD AES and SAGE were not able to implement ACPI S3 within the AGESA API for fam15tn and fam16kb, but chose to bypass the API and link directly with a couple functions in AGESA vendorcode proper.
Binary PI was conceived with the sole intent of eliminating the delay caused by the scrub. By donating AGESA as a binary instead of scrubbed open-source, coreboot becomes available much sooner in the lifecycle of a processor. This is good for AMD and good for companies that want to use AMD’s chips.
There are downsides:
· The AGESA binary has to have a well-defined interface. Normal mechanisms to work around interface deficiencies don’t work, so you have to work within the API.
· Since the same BLOB is available to everyone, the API must be as flexible as possible to accommodate varying needs.
· Because there is no scrub, the source must remain proprietary.
· There is less flexibility because you can’t change AGESA to change when, where, or how initialization functions occur.
· There may be a performance or size impact. Binary PI currently runs exclusively from ROM and is not split between a ROM phase and a RAM phase.
The current binary PI implementation requires an Application Programming Interface (API) to insulate the interface from future changes. This is the same AGESA API that has been open-sourced for several processor generations. The API uses processor-specific structures as arguments and therefore must be compiled using header files that accompany the AGESA library releases. Note that this differs from an Application Binary Interface (ABI). I have maintained API compatibility between open-source AGESA and binary PI. This is for two purposes:
To allow early reference platform development using an integratedAGESA. The code is easier to debug when it is all contained within one binary.
In the hopes that there will be future open-source AGESAcontributions from AMD late in the design cycle of a processor, well after binary PI is released.
1. Can You explain SAGE's role in all of this?
2. As You write you (SAGE) "maintain open-source AGESA and binaryPI compatibility", this must mean SAGE has early access to un-scrubbed AGESA and the changes proposed to it? Would an early release of AGESA sources affect negatively on SAGE's consultation revenue?
3. What is Your opinion on community ports for AMD platforms? How should we debug or develop those in future? Or is the answer that we need to consult with the commercial partner who have access to un-scrubbed AGESA to debug as much as they wish / how much they are contracted for? I assume here binaryPI is virtually impossible to debug for board bring-up. I assume binaryPI is built with all debugging output to console (aka IDS) disabled with no possibility to enable at runtime?
Regarding maintained API compatibility:
In my opinion maintaining an API involves a single set of header files and a source base where bugfixes are backported to previously released chipsets and CPU families. I can see that even within the two binaryPI releases pushed to coreboot blobs.git, the header files are not the same.
Proposal:
There has been a request and changelist to split the AGESA wrappers:
Slowly migrating open-source AGESA away from the published AGESAAPI for Llano (F12), Ontario (F14), Trinity (F15tn), Orochi (F15), and Kabini (F16kb).
Creating new wrappers for binary PI-based processors, namely BaldEagle (00630F01), and Steppe Eagle (00730F01).
The same wrappers, or at least wrapper structure, are shared by all of these platforms today. Note that the API is completely contained with the 3rdparty/pi and src/vendorcode/amd subtree. Code in src/mainboard, src/northbridge, src/southbridge, and src/cpu is “wrapper code” and fair game for modification within the coreboot community.
Well.. not exactly the same wrappers. Same wrapper structure? Not exactly that either, as fam15tn and fam16kb ACPI S3 support adds functions that do not exist for cimx/sb800 ACPI S3 implementation for fam14.
In the spirit of AGESA API, platform specifics would belong to BiosCallOuts and no board-specific agesawrapper.c file should have ever existed. But since board-specific agesawrapper.c files did exists, someone though it was okay to modify those nevertheless.
Instead of splitting the wrappers this way, I would propose forking open-source AGESA within the coreboot tree. Let’s COPY the existing vendorcode/amd/agesa into another subtree, maybe soc or devices, and rename it OSIFA (open software interface for AMD) or something similar. Move or clone experimenter boards over to OSIFA.
Let’s leave commercial production boards alone (AMD, ASRock IMB-A180, some tyan, some supermicro, some HP, maybe a few more) using the existing src/…/agesa directories. That leaves the interface stable for the boards AMD needs to demonstrate, allows AMD to continue donating AGESA with their existing interface, yet still allows the community to improve on and reorganize OSIFA.
You are effectively saying that you do not want any of the improvements that coreboot has gained from Chromebook development, to be available on AMD reference designs? Is this the opinion of You as an individual, the opinion of SAGE or that of the AMD Advanced Embedded Solutions division?
The approach I am suggesting brings improvements for all the AMD platforms where open-source AGESA is available, yet leaving a stable environment for those who are restricted to use of binaryPI.
Mind you, we are not even talking about modifying the AGESA API per se. Let's dig into this deeper:
A pre-requirement to improve the coreboot experience for any AMD platform is to get rid of the excessive copy-paste approach both AMD AES and SAGE seems to be fond of. Some of this work has already been merged (BiosCallOuts, GetBusConf). My work to have common (per family) agesawrapper.c files is under review, and it seemed to have positive feedback from You. All that work is currently on hold due this on-going dispute on the separation of open-source and binaryPI trees.
To think further, understand that a requirement to use a common agesawrapper.c file across fam12-fam16kb is for the vendorcode to actually expose a common API. A common API does not involve forking the header files for each family separately. The community has the possibility to unify the function prototypes within the different families of open-source AGESA API, should we find any.
The requirement to build binaryPI from a specific set of header files from blobs/ justifies the move of binaryPI to a sandbox. The matter around binaryPI is further complicated as the header files between different binaryPI releases are not the same. I do not want to see all the complications and #ifdefs this may introduce to affect the quality of the open-source AGESA -based implementations.
If I choose to bypass some of the lop layers of AGESA API for better performance on one platform, it does not mean I would need to remove unused layers of AGESA API from vendorcode/.
Once/if binaryPI gets scrubbed, it should not be a big deal to import the API header file changes from binaryPI release into the single set of open-source AGESA API header files under vendorcode/. After all, you claim a compatibility in binaryPI and open-source AGESA APIs.
What do you think … ?
Missing signature at end. Does this mail reflect the opinions of You as an individual developer, SAGE or the unanimous voice of SAGE and AMD Advanced Embedded Solutions division?
Kind Regards, Kyösti Mälkki
* Cleaning up AMD platforms sources in coreboot since 2012 *
What do you think … ?
I am happy Kyösti has written such a good analysis of the situation. Thank you! I only have one question and one business-level observation.
First, the observation: AMD can't abandon the open-source AGESA. It *does* affect business decisions to go with AMD over Intel: Intel's last binary holdout is FSP. AMD's binary blob is the GPU firmware. We might see an AMD Chromebook with open-source AGESA, but we can abandon all hope of that if AGESA is a binary blob and AMD GPUs are a binary blob too. More specifically, I'll probably be contributing to a community-maintained fork of AGESA in the event AMD finally really does abandon it.
Second, the question: AMD Graphics cards have announced a project to create a unified driver that links with both the open-source radeon and closed source "fglrx" currently available in linux. AMD claims this approach will save them effort as the valuable bits in fglrx are separated from all the API overhead. Why not try a similar approach here?
SAGE can have their chimera-coreboot (with binaryPI), getting to market faster. See Kyösti's question about the GPL license.
AMD can't abandon the open-source AGESA releases but now that AMD has at least announced a rationale for their actions, the community better understands where their priorities are. See Kyösti's question of when AMD will release scrubbed AGESA code.
Am 05.11.2014 um 17:04 schrieb Kyösti Mälkki:
You have verified binaryPI uses (almost) exactly the same API as open-source AGESA so far. This complex API between AGESA component and coreboot does not fall under the mere aggregation terms of GPL, it is a form of runtime linking. In other words the distribution of binaryPI violates rights of every copyright holder in the coreboot sourcebase. I am not fond of Google's MRC binary or Intel's FSP either, but their implementation appears to be a single entry/exit with an array of platform configuration data.
Please be careful with statements like that (that is: just don't. please.)
I talked with a number of lawyers over matters like that (some of them specialists in various jurisdictions' copyright laws), and they could make all kinds of compelling cases - for pretty much every outcome. All that "does situation X violate term Y in license Z" stuff is a matter of degrees. The result may even depend on the country in which you pose the question.
Patrick
This discussion has gone way off base, as such discussions can do when licensing comes into the picture.
Bruce asked a simple question: can we rename some directories/move some code around in response to a change in how a vendor is delivering their chipset support?
That's a pretty simple question.
All of a sudden we're talking about what AMD should have done, should do now, or will do. That's not the question.
Bruce, is it possible to rephrase your question in simple terms, one paragraph, and not bring in what 3rd parties such as Sage and AMD might do, and just pose the question absent any thought to what might happen at some future time?
thanks
ron
Bruce,
I have no beef with you, but you are the closest to a communications channel with AMD that the community is given access to, so I pass my comments to you.
Bruce Griffith wrote:
To get to an open-source AGESA, there were meetings and rules put in place within AMD with the intent that AMD would never lose proprietary license or ownership of the trunk AGESA or CIM-X codebases resulting from the contribution.
As these contributions started to flow into the community many years ago, you may remember that I guessed that such rules would exist and asked *literally* what those rules were. You may also remember that there was *NO* response whatsoever.
The principal rules are that:
Three (is it four? five?) years later it is nice to see these rules finally confirmed. Of course, by now, all of us fools have already been able to deduce them.
Unfortunately, by not communicating with the community, AMD has caused a significant amount of uncertanity and confusion within the project. Because community projects are supposed to be about collaboration and communication, this has placed AMD in a worse position than anyone wished for.
Although coreboot has received contributions from AMD over a long time already, it is also painfully obvious that AMD still has some ways to go until they can get proper returns on their investment in coreboot.
You may understand that I, as a volunteer, can only do *so* much to help AMD make the most of coreboot. I believe I have asked exactly the right questions but without dialogue there can not be progress.
AMD accepted that the process of releasing into open-source would be a very large and time-consuming task.
It is obviously backwards. I wonder, if someone in those meetings suggested "let's make the open-source code our HEAD so that we only have to scrub once and worst-case only incrementally thereafter".
Major corporations like AMD are perfectly capable of contributing to and even running open source projects. There are many sources of inspiration.
AMD realized that the open-sourcing process they developed was awkward and required lots of developer and legal involvement.
I think you understand that the community is quite frustrated since many attempts were made right at the start to explain that this would be the case. Community members with any meaningful open source experience immediately recognize how resource intensive the scrubbing process would be for AMD.
The six month delay required to implement the “scrub” prevents AMD Embedded from capitalizing
But ultimately this is AMD's problem and not coreboot's.
Please remember that AMD’s primary goal in open-source AGESA is to enable new platforms to sell more chips.
Please remember that the project's primary goal is to create an open source firmware.
Binary PI
..is not open source firmware, is it?
By donating AGESA as a binary instead of scrubbed open-source, coreboot becomes available
That's false. coreboot is an open source project. Binary PI is not open source, so can not be part of coreboot. If it were, coreboot's GPL would make a combination of the two difficult to use.
This is good for AMD and good for companies that want to use AMD’s chips.
It is however not good for coreboot, the open source firmware project.
I would propose forking open-source AGESA within the coreboot tree. What do you think … ?
Let's not be in such a hurry to make changes for once, let's try to think this thing through?
Industry contributors appear unable to see the forest for all the trees.
I notice a trend within governments to require more transparency from IT equipment suppliers. It will take a couple of years, but those requirements will eventually bubble up also to Intel and AMD, who will have to either open up or lose market share. Things will progressively get worse for anyone who insists on remaining opaque, as industry starts adopting the very same requirements as the government.
I predict that whoever opens up first has a great advantage in winning contracts over the next 5 years, but what do I know.
//Peter
Hi,
while this was addressed at AMD, I feel compelled to add my 2ct to some of this.
* Peter Stuge peter@stuge.se [141106 16:07]:
As these contributions started to flow into the community many years ago, you may remember that I guessed that such rules would exist and asked *literally* what those rules were. You may also remember that there was *NO* response whatsoever.
Please keep in mind, that, even or especially in large corporations, coreboot is until this day still driven by motivated individuals rather than through corporate commitment. If the motivation, or the people go away, the communication channel breaks down. I have seen this happen dozens of times for various reasons through out the last decade and a half.
Unfortunately, by not communicating with the community, AMD has caused a significant amount of uncertanity and confusion within the project. Because community projects are supposed to be about collaboration and communication, this has placed AMD in a worse position than anyone wished for.
Although coreboot has received contributions from AMD over a long time already, it is also painfully obvious that AMD still has some ways to go until they can get proper returns on their investment in coreboot.
The problem here, in my opinion, is that firmware is only one little, important but very limited part of the whole story. Even if an individual inside of the organization, or the firmware team as a whole, gets it, they will still have to argue with the same amount of energy to the other parts of the organization as they have to with the coreboot community.
You may understand that I, as a volunteer, can only do *so* much to help AMD make the most of coreboot. I believe I have asked exactly the right questions but without dialogue there can not be progress.
That pretty much applies to all members of the community. Being on the inside of a corporation gives you a lot more information, and somewhat more influence, but not ultimately the power to shift focus away from the corporate issues to the community issues. Especially not quickly.
I think we are having dialogue, and Sage is putting themselves out there to lead this dialogue. In my opinion, the fact that these mails do not originate from an AMD email address does not constitute that we shouldn't be open to finding a solition right now in this discussion. Sure, we can turn the discussion away, stating that it didn't happen on our terms. But will this help the coreboot community, or AMD?
AMD accepted that the process of releasing into open-source would be a very large and time-consuming task.
It is obviously backwards. I wonder, if someone in those meetings suggested "let's make the open-source code our HEAD so that we only have to scrub once and worst-case only incrementally thereafter".
I can tell you with a high degree of certainty that nobody outside of the core coreboot contributors considered the coreboot repository as a possible HEAD. None of the corporate entities in this field ever has. This is certainly something to be discussed, but there are also downsides to this. I remember when we (some of Google's coreboot community) decided to move ARM development to upstream first, there was a big concern in the community. Merging community outreach into a corporate development process is a bigger task than it seems at first, particularly because contributors are diverse and can't necessarily satisfy on all fronts. Like, porting coreboot to the ARM architecture did not allow us to open up the documentation we had access to, nor dedicate time to educating the community. In fact, most effort might have gone into making sure that coreboot was an option at all, rather than staying with the status quo. And after all, there was some code to write, too.
Major corporations like AMD are perfectly capable of contributing to and even running open source projects. There are many sources of inspiration.
I would like to know more about what you had in mind here. Maybe we, the community, and the corporations, can learn from some of these examples.
AMD realized that the open-sourcing process they developed was awkward and required lots of developer and legal involvement.
I think you understand that the community is quite frustrated since many attempts were made right at the start to explain that this would be the case. Community members with any meaningful open source experience immediately recognize how resource intensive the scrubbing process would be for AMD.
Unless coreboot is running on the majority of systems out there, that is not going to change though. If we're running on more systems than everybody else, we can dictate how that process is going to look like. Until then, we'll have to convince and win people over.
The six month delay required to implement the “scrub” prevents AMD Embedded from capitalizing
But ultimately this is AMD's problem and not coreboot's.
That's a very matter of your position. As long as they capitalize more on non coreboot systems, we will have to argue our point. Can coreboot prove that it provides the better ecosystem? The better environment to create innovation? Not all of that is about capitalizing, but blaming a corporation for being profit oriented is certainly not getting you closer to wide spread adoption.
Please remember that AMD’s primary goal in open-source AGESA is to enable new platforms to sell more chips.
Please remember that the project's primary goal is to create an open source firmware.
Mu personal take on this is that I would rather see coreboot run 75% free on a billion machines out there than 100% free on 1000 machines. Because that will ultimately leave the project in a better place of negociating future ports and leaves the whole ecosystem with a higher percentage of free software total.
By donating AGESA as a binary instead of scrubbed open-source, coreboot becomes available
That's false. coreboot is an open source project. Binary PI is not open source, so can not be part of coreboot. If it were, coreboot's GPL would make a combination of the two difficult to use.
So maybe we need to find a common ground on this. In the past we have always accepted VGA option roms. Now we move forward to open graphics. Are we willing to sacrifice open memory initialization in order to be able to deploy open graphics initialization? In order to deploy an open source resource allocator? In order to create an ecosystem in which we can move to an open source memory initialization in the long term? Or is this a dark alley that will only lead to giving away freedom? We, as a community, need to find a way here. If we decide we prefer to run on older hardware that is 100% open on the firmware side, that's something we can run with. Maybe that's where the libreboot effort comes in and makes sure that we can make this goal a reality, while still having another part of the community open to enabling the latest and greatest hardware?
This is good for AMD and good for companies that want to use AMD’s chips.
It is however not good for coreboot, the open source firmware project.
I would propose forking open-source AGESA within the coreboot tree. What do you think … ?
Let's not be in such a hurry to make changes for once, let's try to think this thing through?
Yes, I am absolutely in favor of that.
Industry contributors appear unable to see the forest for all the trees.
I notice a trend within governments to require more transparency from IT equipment suppliers. It will take a couple of years, but those requirements will eventually bubble up also to Intel and AMD, who will have to either open up or lose market share. Things will progressively get worse for anyone who insists on remaining opaque, as industry starts adopting the very same requirements as the government.
Let's work on opening up the industry before governments get the hang of it. While it is a great opportunity, the one thing that, in my opinion, moves slower than corporations, is governments. No offense to any governments listening in on this ;)
I predict that whoever opens up first has a great advantage in winning contracts over the next 5 years, but what do I know.
My prediction is quite similar. But there's also the part of me that knows that if coreboot only runs on a 6+ month old piece of silicon, it will not be adopted, and hence not be in the position to discuss the needs of the community.
Stefan
-
Bruce Griffith -
David Hubbard -
Kyösti Mälkki -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer