Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I should probably step up here and just get this fixedlet me see
what I can do with it next week.

On 06/14/2018 08:28 PM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 8:28 PM, Merlin Büge  > wrote:
>>
>>
>> On Thu, 14 Jun 2018 09:45:49 +0300
>> Kyösti Mälkki  > wrote:
>>
>>>
>>> I hear you and weigh your opinion according to the number of commits I
>>> can recognize you have authored on the repo.
>>
>> I just want to mention:
>> Generally, helping out with documentation and (especially) code review
>> and even ordinary users who report bugs are also a value-add to the
>> coreboot project.
>>
> 
> Agreed and Talidan should not get offended by previous comment. I get
> way more rude and personal in some of my reviews towards commercial
> vendors. Apologies for that.
> 
> Just recently, cases of RELOCATABLE_RAMSTAGE=n started to fail to boot
> certain payload builds. The accumulated developers time it took to
> bisect, discuss and come up with a sub-standard solution for that;
> should I say 8 hours across 5 active developers. That time is better
> spent elsewhere, I consider the discussion of why we deprecate older
> boards from master just not productive at all.
> 
> Notice that even the little details Matthias provided earlier already
> moves us forwards.
> 
> The criteria I listed was my personal wishlist as flipping to
> RELOCATABLE_RAMSTAGE=y has proven to be quite easy and the remaining
> platforms are:
> 
>   northbridge/amd/amdfam10
>   northbridge/amd/lx  <- waiting for EARLY_CBMEM_INIT
>   northbridge/intel/i440bx<- already tested
>   northbridge/via/vx900   <- I know competent person to do this
>   soc/intel/fsp_baytrail  <- I have hardware and know person to
> double-check
>   soc/intel/fsp_broadwell_de  <- I know competent person to do this
> 
> 
> Kyösti
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbI050AAoJEK+E3vEXDOFbV9UH+wdDms4AhQq4GBrLbBmuFh+v
VxTMir4PTXlUh1Li/JhYWSV6ZMzOwrRo4JOQJp4BpnkvfAxZZ6vvnm1Bu2xR2sba
BRF01zk1ZJxoMaE1lUANkKlVOBTfog7nNElBHXRCZJ832Qsc3SpMGuWlap9mBd9L
J7e4yNAvBvW9/cRzh7jHUOzrWxB1ESuyOCEN03OPpxfG37nOHmtGQNKwwifm419d
YxoDwBnQ2vuJpj3ynQC1maX/t4RIqJacTfxfHIcQz7+S2U7Dem+n3lrq2gTl3OY/
e7NEmBevdAgaNiUIMC7pprWTsrthMw0oirmTXX8jVWFLAVIbZ0blSZVzjmfzkYU=
=amyM
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 8:28 PM, Merlin Büge  wrote:
>
>
> On Thu, 14 Jun 2018 09:45:49 +0300
> Kyösti Mälkki  wrote:
>
>>
>> I hear you and weigh your opinion according to the number of commits I
>> can recognize you have authored on the repo.
>
> I just want to mention:
> Generally, helping out with documentation and (especially) code review
> and even ordinary users who report bugs are also a value-add to the
> coreboot project.
>

Agreed and Talidan should not get offended by previous comment. I get way
more rude and personal in some of my reviews towards commercial vendors.
Apologies for that.

Just recently, cases of RELOCATABLE_RAMSTAGE=n started to fail to boot
certain payload builds. The accumulated developers time it took to bisect,
discuss and come up with a sub-standard solution for that; should I say 8
hours across 5 active developers. That time is better spent elsewhere, I
consider the discussion of why we deprecate older boards from master just
not productive at all.

Notice that even the little details Matthias provided earlier already moves
us forwards.

The criteria I listed was my personal wishlist as flipping to
RELOCATABLE_RAMSTAGE=y has proven to be quite easy and the remaining
platforms are:

  northbridge/amd/amdfam10
  northbridge/amd/lx  <- waiting for EARLY_CBMEM_INIT
  northbridge/intel/i440bx<- already tested
  northbridge/via/vx900   <- I know competent person to do this
  soc/intel/fsp_baytrail  <- I have hardware and know person to
double-check
  soc/intel/fsp_broadwell_de  <- I know competent person to do this


Kyösti
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> On 13/06/18 22:12, Kyösti Mälkki wrote:
> Hi,
>
> S3 is __not__ working on my KCMA-D8. The last time I tried, I had to
> remove the power cord for a couple of seconds to be able to boot again.
>
> Interestingly, this issue looks similar to another one I had with a
> flash chip which seems not to be supported by coreboot. Here the
> relevant part of the logs regarding the bad chip:
> Manufacturer: ef
> SF: Unsupported Winbond ID 4014
> SF: Unsupported manufacturer!
>

Thanks, [1] should take care of this.

> Coreboot did work well, but froze sometimes when booting during the
> assigning resources step (more or less exactly after assigning the PCI
> 14.3 or PNP 002e.2 device, which happen to be close to each other inside
> the devicetree). I had to remove the power cord in order to be able to
> boot again (or to get the next random freeze...). Rarely, after such an
> recovery, I have got flooded by IOMMU warnings in Linux which would only
> disappear after another reboot.

Ah, that resume reboot-loop issue. The bit that tells to do S3 resume
is a sticky register backed up by Vstb rail. With [2] you should not
need to do full power-cycling at least. We should extend this work to
other platforms.

> Replacing the chip seems to have solved this random boot freeze problem.
> But maybe the S3 issue and the issue I had with the wrong chip are
> related as they both lock down the machine until I remove the power cord.

Yes, it's connected. Having a non-supported SPI part ID there would
prevent ACPI S3 resume, and likely enter the loop.

If someone takes the task of testing and/or bisecting please note:

Regression present between: 714709f .. a26377b

Regression present between: 9e94dbf .. c2a921b (for kcma-d8) 8a8386e
(for kgpe-d16)

Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
within the latter period, I do not quite see how S3 support could have
worked with that commit on kgpe-d16.  Or maybe this feature was never
retested once it was rebased and upstreamed. Nor can I see how it
could have worked for any commit in 4.6, so I must be missing
something here. So I will need some logs.


[1] https://review.coreboot.org/#/c/coreboot/+/27107
[2] https://review.coreboot.org/#/c/coreboot/+/27108

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[Martin Roth]

On Thu, Jun 14, 2018 at 12:35 PM Leah Rowe  wrote:
> On 14/06/18 19:01, Martin Roth wrote:

> > * The wiki requires a separate login from everything else, which
> > has to be created manually.
> Not only that, but it wasn't clear how to get an account in the first
> place.

I guess I didn't realize that it was a problem.  If you clicked 'log
in' in the top of the wiki, it told you who to email along with their
addresses.
"If you don't have an account and wish to contribute contact Stefan
Reinauer or Patrick Georgi and tell them what exactly you want to
contribute."
https://web.archive.org/web/2015103952/http://www.coreboot.org:80/index.php?title=Special:UserLogin=Welcome+to+coreboot

> By the way, what do you think of the idea I floated in a previous
> message? My idea is to have some kind of web interface where a
> non-technical user who doesn't know how to use git can browse the
> documentation on the website and click "edit", which will take them to
> the appropriate markdown file in the repository. When they're done,
> they give their edit a title and description, which becomes the commit
> message, and their contribution gets sent to code review (Gerrit).
>
> How feasible do you think this would be?
> It would give some of the ease of use of MediaWiki as before, while
> still having all of the advantages that you listed.

I have no issue with that if someone wanted to work on it.  It might
still cause some difficulties because those people probably wouldn't
be able to respond to requests for updates in gerrit, and they
wouldn't necessarily follow the rest of the rules we have for
submitting to coreboot, but maybe those issues could be worked out.
Maybe a documentation administrator could shepherd the patches the
rest of the way through the process.

As far as feasibility, I'm sure it could be done, it would just take
someone committed to making it happen.

Martin

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 14/06/18 19:01, Martin Roth wrote:
> * When the wiki was started, we didn't really think about
> licensing, so most of what's been written needs to be scrapped as
> we're not going to go back and contact all of the original authors,
> many of whom are no longer part of the project, to see if it's OK
> to update the license on their contribution.  As we've joined the
> SFC and committed to having all of our documentation correctly
> licensed with an appropriate license, this means that we'd be
> starting over, regardless of whether we stuck with a wiki or
> changed to something else.

This is also by virtue of the way MediaWiki is designed.

> * The wiki requires a separate login from everything else, which
> has to be created manually.  We've gotten criticism for only
> allowing wiki access to "a few coreboot elites".  People can sign
> up for a gerrit account and contribute to the coreboot
> documentation with pretty minimal restrictions.

Not only that, but it wasn't clear how to get an account in the first
place.



By the way, what do you think of the idea I floated in a previous
message? My idea is to have some kind of web interface where a
non-technical user who doesn't know how to use git can browse the
documentation on the website and click "edit", which will take them to
the appropriate markdown file in the repository. When they're done,
they give their edit a title and description, which becomes the commit
message, and their contribution gets sent to code review (Gerrit).

How feasible do you think this would be?
It would give some of the ease of use of MediaWiki as before, while
still having all of the advantages that you listed.
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsitYoACgkQ/0W3TPnR
z5T9tgf/bI99R/vZct45z5PiUjwsfLGAPWRVyI5Eni+rUTV9bjGRSLueCyu0o55n
cJjk7Oy6NNlzsKxe5qZOQGXgVvO3XNFfmgIptw6NYL8IIYpcwff0GLxwn4K6BQFL
uo0lLb8hNM7H28rOc2hf4p198LeqWGpsgg9CKGKOckZMpmf/AZ+ONltGPRtUYLCD
qTuSkA29rPtr3CfIqpLUHGThrpRJBcAYCeOSpDuXwnOewSj3i4WB4jbEjEvXNoIg
aHgBcAPx+Ce+xy5MQ7A6PXiRNDWRfRQN6SpOgh+7kMVsbOM+2kOVerJtBKb4G32/
XB+O7NSFaRX1CU8g0NzURtofgMvjXg==
=AQkC
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[Martin Roth]

I feel like we've discussed this a number of times, but maybe it
hasn't happened completely in open forums where everyone involved can
see it.  If that's the case, I apologize.

This isn't really a decision that can just be voted upon and if enough
people want to keep the wiki, the direction would change.  This isn't
an arbitrary decision on the part of the coreboot leadership, but
something that's been a very long time coming, with a number of
reasons.

* When the wiki was started, we didn't really think about licensing,
so most of what's been written needs to be scrapped as we're not going
to go back and contact all of the original authors, many of whom are
no longer part of the project, to see if it's OK to update the license
on their contribution.  As we've joined the SFC and committed to
having all of our documentation correctly licensed with an appropriate
license, this means that we'd be starting over, regardless of whether
we stuck with a wiki or changed to something else.

* The wiki requires a separate login from everything else, which has
to be created manually.  We've gotten criticism for only allowing wiki
access to "a few coreboot elites".  People can sign up for a gerrit
account and contribute to the coreboot documentation with pretty
minimal restrictions.

* The wiki has no integrated method of getting feedback or reviews
from people, so documentation written can be, and has been, wrong for
a long time before anyone noticed.  Moving to gerrit at least
guarantees that two people will look at what's added before it's
integrated.

* Moving the wiki into git puts the documentation where the source
code is, so it's more likely to get updated as the source code
changes.

* Most of the wiki is developer oriented, not user oriented, so again,
having that documentation alongside the source tree makes sense.

Currently the coreboot admins are mostly focused on development, and
while that may be an issue, it's the way that the coreboot project has
evolved.  We've talked at conferences in the past about having a more
user-oriented site, but the decision has generally been that it's
something better handled externally.  If someone wants to invest the
time to start and run a coreboot or open-source firmware related site,
we can certainly evaluate adding a link to it from the coreboot.org
page.  We've got links to various sites already on the "End Users"
page (https://coreboot.org/users.html).  The website itself is also in
git, so feel free to submit appropriate changes.

Martin



On Thu, Jun 14, 2018 at 12:37 AM taii...@gmx.com  wrote:
>
> I do not like this...
>
> I update the wiki on a regular basis for the boards I use and I can't
> understand why another critical choice was made without input from the
> community?
>
> The new system has less features, doesn't look as good and does not
> feature the current articles.
>
> Policies like this make it very unfriendly to a new user and help ensure
> that either only expert firmware developers will be able to install
> coreboot themselves the average person will simply be forced to buy from
> a company that sells coreboot systems (of course none of them sell
> systems with real "free firmware")
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Patrick Georgi via coreboot]

Merlin Büge  schrieb am Do., 14. Juni 2018, 19:30:

> I just want to mention:
> Generally, helping out with documentation and (especially) code review
> and even ordinary users who report bugs are also a value-add to the
> coreboot project.
>
Indeed. Not necessarily when it comes deciding about the maintenance of
code that they never touched, ran, documented or tested though.


Regards,
Patrick
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Merlin Büge]

On Thu, 14 Jun 2018 09:45:49 +0300
Kyösti Mälkki  wrote:

> On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com 
> wrote:
> > On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
> >> Hi
> >>
> >> Now that we wiped out K8, I'd like to put my eyes on fam10-15
> >> boards.
> > What exactly do you mean by wiped out?
> >
> >>
> >> Couple questions for board owners:
> >>
> >> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working
> >> S3 support? I remember rumours they originally worked at some
> >> point, but regressed during the rebase / upstream process. Anyone
> >> willing to bisect/fix it if necessary?
> >>
> >
> > I have a D16 with v4.6 that I regularly use suspend with and it
> > works absolutely fine - I can also suspend a host featuring a guest
> > with IOMMU graphics and then resume that host later on and continue
> > playing video games on the guest.
> 
> So you are committed to bisect this and make it work on current
> master, thank you.
> 
> >
> > I again state my for-some-reason controversial opinion that at this
> > rate there will soon be no non-development boards in coreboot due
> > to the choices of the current leadership in determining standards.
> 
> I hear you and weigh your opinion according to the number of commits I
> can recognize you have authored on the repo.

I just want to mention:
Generally, helping out with documentation and (especially) code review
and even ordinary users who report bugs are also a value-add to the
coreboot project.

> 
> Kyösti
> 



-- 
Merlin Büge

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 14/06/18 05:28, taii...@gmx.com wrote:
> I do not like this...
> 
> I update the wiki on a regular basis for the boards I use and I
> can't understand why another critical choice was made without input
> from the community?
> 
> The new system has less features, doesn't look as good and does
> not feature the current articles.
> 
> Policies like this make it very unfriendly to a new user and help
> ensure that either only expert firmware developers will be able to
> install coreboot themselves the average person will simply be
> forced to buy from a company that sells coreboot systems (of course
> none of them sell systems with real "free firmware")
> 

Git is more portable than MediaWiki. It allows more people to be able
to easily submit documentation changes. The documentation is in the
repo under Documentation/ as Markdown files.

Markdown is much simpler than the markup language used by MediaWiki.

Plus you can make easy frontends for editing files in a git
repository. E.g. GitHub does it. I wouldn't recommend use of GitHub
since it's proprietary, but that's just an example. Where a user
doesn't even need to understand git, they just log in and click
"edit", edit whatever they like in a web interface and then that goes
to a pull request for code review. I'm not sure if coreboot does that.
We tried in Libreboot but it's currently not possible due to a
limitation in Gogs, the software that we use for Git-based code review.

So it's possible to have something wiki-like while being hosted in Git.
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlsiUukACgkQ/0W3TPnR
z5S6Zwf/fByVDDUvgQHjro6vJcrpzWSvRmyryhPf/y/Evn96rP4lCBaB9cRUVsRd
+/1lggRNujj/SEaJrlTzbh+qlwXpObaGBaKDDsDOjuAREn3oXSkZ6hYzkRXbDMS/
OakFjkMjDiltZlX2e6eou7Yn2L1+J66pH5kNtXxFbINlE6LdJppRopRfgOtSVie5
3ManiKcHdMRRts2ZE/gUN5RU49jGs/pEAOFHUjb8dt/zyN6SsxGWnLS5fdOJ5s79
Xhv/C5MDXSlZrmv8rGvV8qw90QVDmx9wkaw4r+w9FCPIRBB7J5cxbEUSJ6T8eWIy
38oCoaIURTOEgG6Q6QwiXbHrPAaHfw==
=CByM
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[Kyösti Mälkki]

On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com  wrote:
> On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
>> Hi
>>
>> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
> What exactly do you mean by wiped out?
>
>>
>> Couple questions for board owners:
>>
>> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
>> support? I remember rumours they originally worked at some point, but
>> regressed during the rebase / upstream process. Anyone willing to
>> bisect/fix it if necessary?
>>
>
> I have a D16 with v4.6 that I regularly use suspend with and it works
> absolutely fine - I can also suspend a host featuring a guest with IOMMU
> graphics and then resume that host later on and continue playing video
> games on the guest.

So you are committed to bisect this and make it work on current
master, thank you.

>
> I again state my for-some-reason controversial opinion that at this rate
> there will soon be no non-development boards in coreboot due to the
> choices of the current leadership in determining standards.

I hear you and weigh your opinion according to the number of commits I
can recognize you have authored on the repo.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[taii...@gmx.com]

I do not like this...

I update the wiki on a regular basis for the boards I use and I can't
understand why another critical choice was made without input from the
community?

The new system has less features, doesn't look as good and does not
feature the current articles.

Policies like this make it very unfriendly to a new user and help ensure
that either only expert firmware developers will be able to install
coreboot themselves the average person will simply be forced to buy from
a company that sells coreboot systems (of course none of them sell
systems with real "free firmware")

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
> Hi
> 
> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
What exactly do you mean by wiped out?

> 
> Couple questions for board owners:
> 
> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
> support? I remember rumours they originally worked at some point, but
> regressed during the rebase / upstream process. Anyone willing to
> bisect/fix it if necessary?
> 

I have a D16 with v4.6 that I regularly use suspend with and it works
absolutely fine - I can also suspend a host featuring a guest with IOMMU
graphics and then resume that host later on and continue playing video
games on the guest.

> I am asking, because these are the last two remaining boards with
> combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we
> have to drag along some back-and-forth memory copy code to keep OS
> memory intact for these two.
> 
> Second, I would like to move forwards with AMD fam10 to have
> RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and
> open up doors for some new features.
> 
> If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one
> criteria to survive the next (October 2018?) release. POSTCAR_STAGE
> for May 2019. I am probably too late to make such wishes, but I hope
> these will happen in the next two years nevertheless.

I again state my for-some-reason controversial opinion that at this rate
there will soon be no non-development boards in coreboot due to the
choices of the current leadership in determining standards.

Removing something from master is in fact removal from coreboot - one of
the reasons is as over time the older versions of software required to
compile older versions of coreboot will become un-obtainable already to
compile master critical old GPL code is only obtainable from one obscure
non-US site.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot