On Wed, Oct 28, 2015 at 7:59 AM, Vladimir <quickcracktime(a)gmail.com> wrote:
> On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>>
>> How will moving [AGESA] code [to a separate branch] affect supported [AMD]
>> boards?
>>
>
> The biggest problem here is:
>
> Various improvements and important bug fixes, that will be introduced to a
> master branch and affect all the coreboot boards, will not be automatically
> applied to that separate AMD branch. Those coreboot developers which have
> AMD boards and want to constantly use and test latest and greatest coreboot
> builds, they will have to constantly check the coreboot commit log and
> backport all these improvements and fixes to their separate (and soon to be
> abandoned) AMD branch. That will be adding lots of unnecessary manual work
> and draining lots of workhours, which otherwise could have been spent on
> writing the bug reports or improving a coreboot code which is common for all
> the coreboot-supported boards.
Those developers should then take a more active role in improving the
code that is applicable to them. As it stands now, I don't see any
work going in improving those code bases.
>
> As result, moving AGESA code will affect - and not only AMD boards: all the
> coreboot supported boards will be indirectly negatively affected by that
> change...
>
> Luckily Timothy Pearson has advised a perfect solution for this issue:
>
> On 28 October 2015 at 02:23, Timothy Pearson wrote:
>>
>> Perhaps in the short term we can port the remaining AGESA Fam15h boards
>> to native init, and look into moving Fam14h to as much native as
>> possible while still keeping the PSP happy with its blobs?
>>
>
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch
There's more to it than just moving to native init. That doesn't
remove the maintenance burden.
>
> Best regards,
> Vladimir Shipovalov
>
> On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi(a)google.com> wrote:
>>
>> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>:
>> > Here's a list of things I think should be moved to branches, right after
>> > the 4.2 release:
>> So far the idea was to drop things in master after a release, and
>> create branches for releases (as I did for 4.1 yesterday, in addition
>> to the tag).
>> So, when dropping stuff after the 4.2 release, to go back to these
>> things, you start from the 4.2 branch.
>>
>> > Now remember, this assumes branches are as first class
>> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> > That shows it can work.
>> There's a significant difference (and a problem that we'd inherit by
>> adopting the chromium gerrit model):
>>
>> The difference is that Chromium firmware branches are made per-board
>> for devices where not many changes are expected.
>> The items you point out are most interesting for adding new boards
>> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
>> predicted a year before it happened either, 945 was "dead" then).
>> If we go for branches for that, developing FSP1.0 coreboot will look
>> quite different from master-coreboot.
>>
>> The problem we have with firmware branches over at Chromium is that,
>> as far non-ChromeOS development is concerned, branches are where
>> commits are pushed to die. They're not folded back into mainline
>> Chromium nor coreboot.org. We don't really have a good solution for
>> that.
>>
>> If we spawn tons of branches every time something becomes a bit
>> inconvenient to deal with, we're quickly devolving into u-boot:
>> vendors will just start maintaining their own branches, and porting
>> high level features between those requires an immense amount of effort
>> because there are many years of divergence between them.
>> If you want a taste of that, try building something on Chromium's
>> chromeos-2013.04 branch and then port it to upstream master. And that
>> was just 2.5 years.
>>
>> tl;dr: hiding problems in branches won't serve us long-term.
>>
>>
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Oct 28, 2015 at 3:32 AM, Patrick Georgi <pgeorgi(a)google.com> wrote:
> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>:
>> Here's a list of things I think should be moved to branches, right after
>> the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
>> Now remember, this assumes branches are as first class
>> citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient. From
the few years that I have been involved in this project I have seen
the airplanes pile up in the graveyard. So basically, it seems like
status quo rules. Or the time horizon for change is so long (10 years)
that the result is accumulation of more cruft? To add insult to injury
there's no tenable way of making changes in these areas because the
physical resources are not readily available to test against. As such
there is no progress in fixing those inconveniences which in turn
means an ever increasing burden for making non-periphery changes.
Ignoring the #include "file.c" constructs, a large majority of the
mainboards drive romstage flow entirely within those directories. i.e.
main() starts in mainboard. There is no common/consistent flow for
romstage on x86. That requires chipset as well as mainboard changes to
rectify. How do you propose one goes about doing that? Build test it?
Then have someone come 6 months later and say "hey, this doesn't
work."
> tl;dr: hiding problems in branches won't serve us long-term.
What does serve us long-term? And what are those goals? Is it
quantifiable by the number of mainboards checked into the coreboot.org
repo that build regardless of the maintenance burden?
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
2015-10-28 13:59 GMT+01:00 Vladimir <quickcracktime(a)gmail.com>:
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch
I agree. Patches accepted.
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>
> How will moving [AGESA] code [to a separate branch] affect supported
[AMD] boards?
>
The biggest problem here is:
Various improvements and important bug fixes, that will be introduced to a
master branch and affect all the coreboot boards, will not be automatically
applied to that separate AMD branch. Those coreboot developers which have
AMD boards and want to constantly use and test latest and greatest coreboot
builds, they will have to constantly check the coreboot commit log and
backport all these improvements and fixes to their separate (and soon to be
abandoned) AMD branch. That will be adding lots of unnecessary manual work
and draining lots of workhours, which otherwise could have been spent on
writing the bug reports or improving a coreboot code which is common for
all the coreboot-supported boards.
As result, moving AGESA code will affect - and not only AMD boards: all the
coreboot supported boards will be indirectly negatively affected by that
change...
Luckily Timothy Pearson has advised a perfect solution for this issue:
On 28 October 2015 at 02:23, Timothy Pearson wrote:
>
> Perhaps in the short term we can port the remaining AGESA Fam15h boards
> to native init, and look into moving Fam14h to as much native as
> possible while still keeping the PSP happy with its blobs?
>
If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch
Best regards,
Vladimir Shipovalov
On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi(a)google.com> wrote:
> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>:
> > Here's a list of things I think should be moved to branches, right after
> > the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
> > Now remember, this assumes branches are as first class
> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
> > That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>
> tl;dr: hiding problems in branches won't serve us long-term.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
On 10/27/2015 01:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you would
> check a "Binary situation" page at coreboot's wiki, you would see that
> Intel is in three times more evil
Probably "evil" is a bad term. I doubt that there's an ill intent. There
are customer (read OEMs) who want such "features". Remember the Lenovo
laptops that only allowed you to connect white-listed wifi cards before
they would boot? [1]
The real issue is that some of those "features" cannot be disabled, but
that's a technical argument, and has nothing to do with evil vs good.
> (still could not understand why some
> incredibly talented coreboot developers are spending so much time
> fighting Intel's ME issues,
I can't speak for others, but that allows me to continue to work on
coreboot, while also paying the bills. In fact, there is a significant
number of developers who pay their bills by working on coreboot. That's
progress that coreboot wouldn't otherwise see.
> In any case, it would be very sad to see the AMD code gone from the
> master branch. Even the code for some unpopular boards like Intel
> Atom-based EOL "Mohron Peak" was allowed to stay!
There are two reasons for that, one technical, and another one
political. On the technical side, there are users, and people stepped up
to maintain that code. That's usually sufficient to allow code back in.
On the non-technical side, one or two of the developers who originally
committed that code got very offended, angry, and blindsighted by the
fact that it was removed. I won't go into the details.
> Why AMD boards are considered worse? The sole idea of AMD code going away,
Who said AMD is worse? And who said AMD is going away? The whole idea is
to move it to a separate branch. This has two advantages:
* it's only concerned with agesa boards, so it's not constrained by the
needs of other hardware
* the master branch is no longer held back by the integration issues of
agesa
Positive side-effects:
* No longer need to build-verify AGESA for unrelated changes (AGESA
boards take up more than half the server time)
> which will affect many alive-and-kicking coreboot-supported AMD boards,
How will moving code around affect supported boards?
> is beyond my comprehension
BRANCH NOT EQUALS REMOVAL
Does that help?
Someone in this thread (was it you Stefan?) was also suggesting we wait
until 4.3 release before we "remove" AGESA code. I know this whole
discussion started as "removing" stuff, but nobody wants to remove
anything anymore. We've gotten smarter. We just make the effort more
distributed and less centralized. I think moving to branches should be
done sooner rather than later.
Here's a list of things I think should be moved to branches, right after
the 4.2 release:
* AGESA
reason: integration issues
* binaryPI
reason: integration issues
* FSP 1.0
reason: integration issues
* MRC boards
reason: sandy/ivy already has native init path. Some chromebooks have
already been converted.
See the pattern? Now remember, this assumes branches are as first class
citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
That shows it can work.
If people apply that pattern, there are a few other things that could be
branched, but I intentionally excluded:
* ROMCC-only boards:
why not: x86 bootblock still uses ROMCC, so there's no immediate value
in removing boards that also need ROMCC for romstage. Maybe we should
think of it for some future release, once we get more hardware to use
CAR setup in the bootlock.
* google FSP boards (informally, FSP 1.1)
why not: the FSP spec that's used on those boards is subject to change
(and become 1.2, 1.3, etc), and there's no indication that we'll see
significant integration issues if that happens/after it goes live.
Hope this clears things up,
Alex
[1] http://www.coreboot.org/images/6/68/Network_card_bios.jpg
>
> On 27 October 2015 at 23:15, Timothy Pearson
> <tpearson(a)raptorengineeringinc.com
> <mailto:tpearson@raptorengineeringinc.com>> wrote:
>
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are
>> AMD-based products which are still very alive and actively sold (at the
>> developing markets) Moving the support for these products to a separate
>> coreboot branch, could create many inconveniences for those AMD product
>> owners who would like to test & use the latest and greatest coreboot
>> build: they will have to backport all the commits of code that's used by
>> all the boards, to that separate abandoned branch - which would cause a
>> lot of hassle and would basically cut them off from the development
>
>> I agree that removing could be done to some 2009 VIA-based EOL boards
>> that nobody cares about, but it would be a mistake to do that to all the
>> AMD products, some of which are still produced to this date and used
>> together with coreboot by lots of people from this mailing list
>
>> Also, that action will send a bad signal to AMD. AMD is actively
>> supporting the coreboot project and is much more friendly to open source
>> community than Intel with it's ME and creepy lock-it-all desires.
>> Removing AGESA code would be an equivalent of telling "we don't need
>> your code" to AMD, one of the largest coreboot supporters, and that
>> could lead to a terrible consequences
>
> AMD is hardly innocent on that front; they require a large binary blob
> to execute on the auxiliary CPU at bootup, with unknown security
> consequences. Also, as far as I understand there has been no new AGESA
> source release for some time, only binary blobs.
>
>
>
>
>
Hi,
yep try this patch. Then it should work again.
http://review.coreboot.org/#/c/12112/
Regards Zaolin
> I'm testing the Lenovo T420 port[1]. After I saw some commits on
> Sandy/Ivy RAM init and native graphics init code, I asked Nicolas
> Reinecke to rebase and update the code. After I flashed the new
> firmware, coreboot runs fine and boot to GRUB payload. However, Linux
> kernel hanged and could not boot. I think there must be something
> wrong with some of the upstream commits.
>
> [1] http://review.coreboot.org/#/c/11765/
>
> Iru Cai
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Thank you for this enlightening message about blobgesa... Luckily AMD was
10 years slow at following Intel's ME example, 10 years since ME first
version, and it was not until 2015 that built-in Platform Secure Processors
completely took over the AMD's Mobility family ( Kaveri from 2014 still
didnt have PSP ) . Desktop family has 2015 Godavari without the PSP. It
seems that PSP-blobgesa plague is going from low end to high end direction,
and - while it took over the mobility family - desktop high end is still
OK, and server family is far from it (so far only low end "seattle" servers
are affected)
Hopefully this blobgesa will be open sourced eventually - its not that far
from reality because AMD open sourced a lot of stuff during the past
months... Also it will be very interesting to see how AMD Zen platforms
will behave
Best regards,
Vladimir Shipovalov
On 28 October 2015 at 00:35, Felix Held <felix-coreboot(a)felixheld.de> wrote:
>
> if you would check a "Binary situation" page at coreboot's wiki, you would
>> see that Intel is in three times more evil
>>
> That page is outdated. Newer AMD systems have the platform security
> processor, which is quite similiar to the ME.
>
> http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Secur...
> has some information on the PSP.
> Chips with PSP are btw. only supported by blobgesa.
>
> Also the AGESA source is quite a mess (I started to do some cleanups
> there, but finally dropped the project, because it wasn't worth the time
> for me) and having native initialization will be much better.
>
> Regards
> Felix
>
I think we can make it clear to AMD that we are grateful for AGESA and
their support, and the way they have helped us to get to a good place in
terms of code; and, further, we can now offer a better option, with code
that really fits well into coreboot.
I don't see demoting AGESA as a bad thing; it's a good thing. AGESA got us
to where we are, and now we take the next step: code that is well
integrated. In fact I think we're all giving AMD a huge vote of confidence
by making the effort to make their chips fit really well into coreboot,
instead of being half-in/half-out. This is going to be a big improvement.
We're not tossing AMD out; we're inviting them into the living room, with a
warm fire and a nice place to sit down and relax :-)
ron
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/27/2015 03:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you would
> check a "Binary situation" page at coreboot's wiki, you would see that
> Intel is in three times more evil (still could not understand why some
> incredibly talented coreboot developers are spending so much time
> fighting Intel's ME issues, while AMD boards don't have that "dragon you
> have to tame" on board)
>
> In any case, it would be very sad to see the AMD code gone from the
> master branch. Even the code for some unpopular boards like Intel
> Atom-based EOL "Mohron Peak" was allowed to stay! Why AMD boards are
> considered worse? The sole idea of AMD code going away, which will
> affect many alive-and-kicking coreboot-supported AMD boards, is beyond
> my comprehension
This is why I was advocating a gentle demotion to second class status.
You can still use the AGESA code where needed, but native intialization
would be preferred for new ports.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv
S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl
aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ
W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt
Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT
+f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA=
=nXMZ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/27/2015 03:10 PM, Vladimir wrote:
> It would be really wrong to remove the whole AGESA code: there are
> AMD-based products which are still very alive and actively sold (at the
> developing markets) Moving the support for these products to a separate
> coreboot branch, could create many inconveniences for those AMD product
> owners who would like to test & use the latest and greatest coreboot
> build: they will have to backport all the commits of code that's used by
> all the boards, to that separate abandoned branch - which would cause a
> lot of hassle and would basically cut them off from the development
>
> I agree that removing could be done to some 2009 VIA-based EOL boards
> that nobody cares about, but it would be a mistake to do that to all the
> AMD products, some of which are still produced to this date and used
> together with coreboot by lots of people from this mailing list
>
> Also, that action will send a bad signal to AMD. AMD is actively
> supporting the coreboot project and is much more friendly to open source
> community than Intel with it's ME and creepy lock-it-all desires.
> Removing AGESA code would be an equivalent of telling "we don't need
> your code" to AMD, one of the largest coreboot supporters, and that
> could lead to a terrible consequences
AMD is hardly innocent on that front; they require a large binary blob
to execute on the auxiliary CPU at bootup, with unknown security
consequences. Also, as far as I understand there has been no new AGESA
source release for some time, only binary blobs.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
+iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
=G6dr
-----END PGP SIGNATURE-----
