On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks dhendrix@google.com wrote:
This all sounds fine from a developer's perspective, but what about AMD's customers? I honestly have no clue if the decision to use an AMD product with coreboot hinges on whether AMD's supplied AGESA code is used or not. But I can imagine ripping out the AMD-supplied code might make it difficult for AMD to support customers who use coreboot.
I'm sure there are people on this list who _have actually supported customers_ using AMD products and coreboot, so I'd like to hear their perspective.
/my $0.02.
The code lives on a branch. People are more than happy to work within that branch. That's exactly what branches are for.
I'll one up the recommendation and suggest all non-romcc code that #includes C files gets removed after the branch point. Or do such a thing in the next release. I'm sick of having to deal with and fighting against these development constructs.
On Tue, Oct 27, 2015 at 12:20 PM, ron minnich rminnich@gmail.com wrote:
The AGESA code was always an awkward fit into coreboot. It was more like a badly designed artificial limb than a real part of the code base. I understand the idea of encouraging vendors to commit source but, at this point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful in its time but I think I'm with tpearson on this point.
I believe we should drop AGESA on any boards that have native support, and the sooner the better.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot