[prev in list] [next in list] [prev in thread] [next in thread]
List: linuxbios
Subject: [coreboot] Re: Discussing Controversial Upstreaming
From: Marshall Dawson <marshalldawson3rd () gmail ! com>
Date: 2020-01-30 15:39:08
Message-ID: CAB_1Bs1QD+qDn1yUZ=S2Dvfn6-2Q2Q3SzvYMALwUmOJRi2RQ_w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Nico,
> For our FSP implementation, I intend to rely on the FSP 2.0 EAS published
> > by Intel then document the important differences, which I hope is
> extremely
> > minimal. Then there will also be a Picasso-specific Integration Guide,
> > again similar to Intel's docs. This leaves us subject to many of the
> > complaints in CB:36328, however I'm trying to do my best to avoid as much
> > of that as possible -- I forwarded your RFC to my team, asked them to
> read
> > it carefully to understand FSP customers' concerns, and told them I fully
> > expect us to outshine Intel.
>
> sounds great. But before you can outrun them you have to catch up. And
> I fear you might try to take shortcuts. I don't want to tell you how to
> do your job, but here is what I'd try to do (I guess an extreme): Do
> whatever needs to be done for the priority customers when writing code,
> but only start writing code for upstream coreboot when there is also
> public documentation about the chips. If you start earlier, you exclude
> too many people from collaboration. Just in case you don't know, there
> is not even a public datasheet to be found that would acknowledge that
> Ryzen, Picasso etc. are SoCs with FCH like components.
>
Nico, I completely agree that we're not there yet. The Picasso FSP is
still a work in progress. Anyone with access to the v9 AGESA and
historical knowledge of AGESA in coreboot would likely identify similar
complaints in the design. Given what my team has learned from the FSP
conversion, the intention to minimize FSP efforts for future designs (and
potentially better flexibility in deploying AGESA in other ways), we're
driving changes back into the AGESA trunk right now. This type of action
had been requested of AMD for 6-8 (?) years and we're getting it done now.
Hopefully we'll exceed your expectations. If you suspect the solution will
target only priority customers, then it shouldn't be very difficult. I've
also personally dealt with shortcomings in the Intel FSP offerings, so I'm
sensitive to the consumer's experience. I'll skip further descriptions of
our sausage factory, but my team knows I'm adamant we're enabling coreboot
and FSP for everyone and not some customer. I'm confident we'll encounter
unforeseen gotchas along the way. For example, I recall years ago, our
Embedded System customers tried to utilize a particular GPIO and we were
all surprised it didn't work properly -- it turned out AGESA had co-opted
it, but it was never documented anywhere. All non-Embedded designs were
simply instructed not to use the GPIO. About a week ago, we discovered a
CMOS location baked into the design. ...still a work in progress. However
I recall similar experiences with the earlier Intel FSPs too. BTW I'll
infer "here is what I'd try to do..." as "what I would be tempted to do".
Granted Google made modifications to their version of the Stoney Ridge
binaryPI and corresponding changes in coreboot to support them. I really
hope to get that code back and upstream the binaries so that we're all on
the same page. I haven't asked for permission from the right people, or
with adequate urgency, yet. BTW behind the scenes I'm also working to
solve the problem we've discussed of single-sourced contractors owning the
source and creation of AGESA blobs.
Regarding upstream code and documentation, as I mentioned on another
thread, AMD's PPR for Picasso (i.e. the equivalent of BKDG on previous
generations) was nearly nonexistent when we started. IIRC it was primarily
architectural registers you could get from anywhere; hardly anything unique
to Picasso except perhaps CPUID indicators. Google and I demanded from AMD
that registers we would use had to be openly available. The best we could
negotiate was that anything unique would be requested on a case-by-case
basis and they would either be opened or denied (precluding their usage).
Also, anything that was mostly identical to previous generations, e.g. in
the FCH, I had an implied permission to push. The resulting public spec is
as holey as you'd expect. I predict this will continue to be a challenge
for a while. The PSP specs have always been NDA only, and not likely to
change.
but only start writing code for upstream coreboot...
>
No, Picasso was always "upstream first". Until you mentioned it, I'd
forgotten that Stoney Ridge had been developed "internal first", although
it was eventually completely revamped. Two things come to mind for
Picasso. (1) When AMD first put out the Picasso RFP, they wanted
everything to be internal-only. I inferred this was partly because of NDA
info and partly hopes of hiding any intentions. This is part of what I now
call the "old thinking", and we helped them to see why that would be a huge
mistake (for exactly the reasons everyone here would suggest). (2) The
"fork" we've talked about was from August-ish; a snapshot of the WIP at
coreboot.org. This was done only so that other scheduled effort could
continue without waiting for the WIP to land -- that other work doesn't
depend on the underlying x86 init sequence.
Thanks,
Marshall
On Wed, Jan 29, 2020 at 3:58 AM Nico Huber <nico.h@gmx.de> wrote:
> On 26.01.20 20:15, David Hendricks wrote:
> > On Sat, Jan 25, 2020 at 4:44 PM Nico Huber <nico.h@gmx.de> wrote:
> >> we've recently seen the deprecation of Intel/Broadwell-DE support
> >> because it turned out to be too proprietary to be maintained in the
> >> long run.
> >
> > To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley)
> > had a pretty long run in master. It was only when certain important
> > coreboot features were introduced and plenty of warning that FSP 1.0
> > needed to be deprecated that those SoCs were deemed unmaintainable in
> > master and moved to 4.11_branch.
>
> Let me briefly explain why I think it wasn't deemed maintainable. There
> were fundamental problems with the FSP blob. Though, we could have main-
> tained it by either:
>
> a) Fixing it in the source code (and releasing a new binary).
> b) Fixing it in the binary.
> c) Working around the issues in coreboot.
>
> Due to the proprietary nature, a) could only have been done by Intel.
> b) is forbidden by Intel in the FSP license. c) didn't happen, I guess
> because people didn't try hard enough as they were promised a).
>
> >
> > Heck, even after that platforms are still being released using that
> > code such as the Librem Server. It's still used and maintained, just
> > not in the master branch.
>
> That's actually a good point, "not in the master branch". With the
> two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/
> Picasso), we (potentially, in the Picasso case) have even worse blob
> situations. By allowing that on the master branch, we're creating
> demons that guard parts of the source tree from collaboration.
>
> IMO, we have just seen one of these creating a bottleneck that was
> way too frustrating for three important contributors. I think we
> should try to prevent such friction in the future, not by trying to
> work around, but by avoiding the cause.
>
> Nico
> _______________________________________________
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-leave@coreboot.org
>
[Attachment #5 (text/html)]
<div dir="ltr">
<div><span>Nico,</span></div><div><span><br></span></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><span>> For our FSP implementation, I \
intend to rely on the FSP 2.0 EAS \
published</span></div><div><span></span></div><span> > by Intel then document the \
important differences, which I hope is extremely</span><br><span> > minimal. \
Then there will also be a Picasso-specific Integration Guide,</span><br><span> > \
again similar to Intel's docs. This leaves us subject to many of \
the</span><br><span> > complaints in CB:36328, however I'm trying to do my \
best to avoid as much</span><br><span> > of that as possible -- I forwarded your \
RFC to my team, asked them to read</span><br><span> > it carefully to understand \
FSP customers' concerns, and told them I fully</span><br><span> > expect us to \
outshine Intel.</span><br><span> </span><br><span></span>
sounds great. But before you can outrun them you have to catch up. And<br>
I fear you might try to take shortcuts. I don't want to tell you how to<br>
do your job, but here is what I'd try to do (I guess an extreme): Do<br>
whatever needs to be done for the priority customers when writing code,<br>
but only start writing code for upstream coreboot when there is also<br>
public documentation about the chips. If you start earlier, you exclude<br>
too many people from collaboration. Just in case you don't know, there<br>
is not even a public datasheet to be found that would acknowledge that<br><div>
Ryzen, Picasso etc. are SoCs with FCH like \
components.<span><br></span></div></blockquote><div><br></div><div>Nico, I completely \
agree that we're not there yet. The Picasso FSP is still a work in progress. \
Anyone with access to the v9 AGESA and historical knowledge of AGESA in coreboot \
would likely identify similar complaints in the design. Given what my team has \
learned from the FSP conversion, the intention to minimize FSP efforts for future \
designs (and potentially better flexibility in deploying AGESA in other ways), \
we're driving changes back into the AGESA trunk right now. This type of action \
had been requested of AMD for 6-8 (?) years and we're getting it done \
now.<br></div><div><br></div><div>Hopefully we'll exceed your expectations. If \
you suspect the solution will target only priority customers, then it shouldn't \
be very difficult. I've also personally
dealt with shortcomings in the Intel FSP offerings, so I'm sensitive to the \
consumer's experience. I'll skip further descriptions of our sausage \
factory, but my team knows I'm adamant we're enabling coreboot and FSP for \
everyone and not some customer.
I'm confident we'll encounter unforeseen gotchas along the way. For \
example, I recall years ago, our Embedded System customers tried to utilize a \
particular GPIO and we were all surprised it didn't work properly -- it turned \
out AGESA had co-opted it, but it was never documented anywhere. All non-Embedded \
designs were simply instructed not to use the GPIO. About a week ago, we discovered \
a CMOS location baked into the design. ...still a work in progress. However I \
recall similar experiences with the earlier Intel FSPs too. BTW I'll infer \
"here is what I'd try to do..." as "what I would be tempted to \
do".<br></div><div><br></div><div>Granted Google made modifications to their \
version of the Stoney Ridge binaryPI and corresponding changes in coreboot to support \
them. I really hope to get that code back and upstream the binaries so that \
we're all on the same page. I haven't asked for permission from the right \
people, or with adequate urgency, yet. BTW behind the scenes I'm also working \
to solve the problem we've discussed of single-sourced contractors owning the \
source and creation of AGESA blobs.<br></div><div><br></div><div>Regarding upstream \
code and documentation, as I mentioned on another thread, AMD's PPR for Picasso \
(i.e. the equivalent of BKDG on previous generations) was nearly nonexistent when we \
started. IIRC it was primarily architectural registers you could get from anywhere; \
hardly anything unique to Picasso except perhaps CPUID indicators. Google and I \
demanded from AMD that registers we would use had to be openly available. The best \
we could negotiate was that anything unique would be requested on a case-by-case \
basis and they would either be opened or denied (precluding their usage). Also, \
anything that was mostly identical to previous generations, e.g. in the FCH, I had an \
implied permission to push. The resulting public spec is as holey as you'd \
expect. I predict this will continue to be a challenge for a while. The PSP specs \
have always been NDA only, and not likely to change.</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div> but only start writing code for upstream \
coreboot...</div></blockquote><div><br></div><div>No, Picasso was always \
"upstream first". Until you mentioned it, I'd forgotten that Stoney \
Ridge had been developed "internal first", although it was eventually \
completely revamped. Two things come to mind for Picasso. (1) When AMD first put \
out the Picasso RFP, they wanted everything to be internal-only. I inferred this \
was partly because of NDA info and partly hopes of hiding any intentions. This is \
part of what I now call the "old thinking", and we helped them to see why \
that would be a huge mistake (for exactly the reasons everyone here would suggest). \
(2) The "fork" we've talked about was from August-ish; a snapshot of \
the WIP at <a href="http://coreboot.org">coreboot.org</a>. This was done only so \
that other scheduled effort could continue without waiting for the WIP to land -- \
that other work doesn't depend on the underlying x86 init \
sequence.</div><div><br></div><div>Thanks,<br></div><div>Marshall<br></div><div><span></span></div><div><span></span></div>
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, \
2020 at 3:58 AM Nico Huber <<a href="mailto:nico.h@gmx.de" \
target="_blank">nico.h@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On 26.01.20 20:15, David Hendricks wrote:<br> > \
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber <<a href="mailto:nico.h@gmx.de" \
target="_blank">nico.h@gmx.de</a>> wrote:<br> >> we've recently seen the \
deprecation of Intel/Broadwell-DE support<br> >> because it turned out to be \
too proprietary to be maintained in the<br> >> long run.<br>
><br>
> To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley)<br>
> had a pretty long run in master. It was only when certain important<br>
> coreboot features were introduced and plenty of warning that FSP 1.0<br>
> needed to be deprecated that those SoCs were deemed unmaintainable in<br>
> master and moved to 4.11_branch.<br>
<br>
Let me briefly explain why I think it wasn't deemed maintainable. There<br>
were fundamental problems with the FSP blob. Though, we could have main-<br>
tained it by either:<br>
<br>
a) Fixing it in the source code (and releasing a new binary).<br>
b) Fixing it in the binary.<br>
c) Working around the issues in coreboot.<br>
<br>
Due to the proprietary nature, a) could only have been done by Intel.<br>
b) is forbidden by Intel in the FSP license. c) didn't happen, I guess<br>
because people didn't try hard enough as they were promised a).<br>
<br>
><br>
> Heck, even after that platforms are still being released using that<br>
> code such as the Librem Server. It's still used and maintained, just<br>
> not in the master branch.<br>
<br>
That's actually a good point, "not in the master branch". With the<br>
two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/<br>
Picasso), we (potentially, in the Picasso case) have even worse blob<br>
situations. By allowing that on the master branch, we're creating<br>
demons that guard parts of the source tree from collaboration.<br>
<br>
IMO, we have just seen one of these creating a bottleneck that was<br>
way too frustrating for three important contributors. I think we<br>
should try to prevent such friction in the future, not by trying to<br>
work around, but by avoiding the cause.<br>
<br>
Nico<br>
_______________________________________________<br>
coreboot mailing list -- <a href="mailto:coreboot@coreboot.org" \
target="_blank">coreboot@coreboot.org</a><br> To unsubscribe send an email to <a \
href="mailto:coreboot-leave@coreboot.org" \
target="_blank">coreboot-leave@coreboot.org</a><br> </blockquote></div>
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic