On 1/27/20, 10:56 AM, "Nico Huber" <[email protected]> wrote:
Hi Jonathan,
thanks for your email. It's become very rare that developers take part
in mailing-list discussions when they are asked to. So it's really
appreciated.
Jumping to conclusion without knowing context could cause distractions.
On 27.01.20 17:21, Jonathan Zhang (Infra) wrote:
> On 1/26/20, 11:32 AM, "Nico Huber" <[email protected]> wrote:
>>
>> Hi David,
>>
>>On 26.01.20 20:15, David Hendricks wrote:
>>> On Sat, Jan 25, 2020 at 4:44 PM Nico Huber <[email protected]> wrote:
>>>> There are currently two new platforms in development that seem to
>>>> have trouble with public binaries (which would be necessary to make
>>>> the code useful to the coreboot community). Namely, AMD/Picasso and
>>>> Intel/Skylake-SP. Support for the former is already partially rotting
>>>> on our master branch. Shouldn't we discuss their fate before more
>>>> resources are wasted?
>>>
>>> I happen to know that for the latter the whole point of uploading it
>>> in its current state was to get some feedback. The authors gave a live
>>> demo of it last fall at the OCP Summit in Europe and wanted to finally
>>> get some code published, which itself was quite a feat.
>>>
>>> As for their fate, I think we need to look forward and not just
>>> backward. The code was pushed upstream with the intent of being used
>>> in real products and not just for the fun of putting a bunch of
>>> unusable code on display and making peoples' lives difficult. It also
>>> serves as a starting point for future work.
>>>
>>> That said, it's fair to say that if nothing uses that code then
>>> perhaps it should be removed from the master branch. In Picasso's
>>> case, there is a mainboard in progress (CB:33772), and given the
>>> timeline I suspect there was a previous board that got cancelled
>>> (stuff doesn't always go as planned...). In Skylake-SP and Tioga Pass
>>> case, the hardware already exists and is in production but the blob
>>> situation might prevent it from being usable by the community, but the
>>> code is already being used as a starting point for the next generation
>>> platform.
>>
>> sounds like good progress. Though, you make it look like SKL-SP support
>> is just a code drop. If there is no intention to get it into shape and
>> working with upstream coreboot, together with the community, should we
>> merge it? Jonathan seems to work hard to clean the patches "formally
>> into shape" (i.e. fixing checkpatch issues), but that's not all that
>> matters, is it?
>
> It is NOT just a code drop.
Don't worry. Maybe that came out wrong. What I meant is that /if/ the
SKL-SP code will not be usable by anyone else, there'll probably be
little interest in the community to work on it. Hence, the code would
likely just stay as is. So what upstream it for? (that's not a retho-
rical question, I'm really asking for expectations)
At this moment, I cannot promise that SKL-SP code will be used in data center,
even though there is indeed a chance. That being said, our vision is not
limited
to SKL-SP, our target is all (especially future Xeon SP processors). Making
SKL-SP
(note that people normally short it to SKX-SP, instead of SKL-SP) supported in
Coreboot is an endeavor of starting enablement of coreboot to support Xeon-SP.
We had this before: Something that nobody really cared about was
upstreamed. And then later, it was copied for newer platforms and
people were confused by the feedback that they didn't get for the
original platform's code (they expected that what was acceptable for
the platform that nobody cared about would always be accepted). I'm
not saying that this is the wrong way. Just that from my point of
view, we had bad experience with it.
Most industry projects fail in the end. I hope this one does not. Let's work
together to make it happens. The difficulty is not just at technology side, it
is
more on the process side and business side. There is a chicken and egg problems
between coreboot support for Xeon-SP and FSP support for Xeon-SP. I hope the
community is sensitive to the engineers working in silicon vendor. Let's
encourage
them and support them, it is not easy to turn around a big ship.
al
> It is backed up by a huge commitment, multi-company
> collaboration and a long term roadmap.
Sounds nice. If it's really long term, i.e. covering more than a few
months, maybe it's even worth to add that roadmap to coreboot's
Documentation/ folder? Generally, in my experience, the more infor-
mation is available before a review, the better the review will be.
Good point, we are working on documentations, not aimed for this patch set
though,
both because of resource constraint and because more work is needed to
understand
the technology.
> For some context, please refer to [1] and
> [2]. The intention of this upstream is to get reviews from the
community, and
> in turn to enable the community to work on coreboot support for Xeon
Scalable
> Processors based servers, with this patch set as a start point.
Yeah, but what I don't understand so far: Where is one supposed to get
the required blob? And who produced it anyway? Does an NDA with Intel
suffice? or does it need a three-party NDA with Intel and Facebook? For
which (future?) platform can we expect a public binary if any?
This seems critical to me. With little documentation (if any at all)
about the silicon initialization, no documentation about the blob (I
assume?) and no binaries to at least test it, what do you expect from
the review?
Without coreboot able to support Xeon-SP, silicon vendor is rightly hesitate to
make Xeon-SP FSP as a product. Instead of wishing others to do something, let's
firm up coreboot support, and we have allies helping us.
> [1] https://www.youtube.com/watch?v=eVmx9n5FyDI
> [2] https://www.youtube.com/watch?v=lvAnj0k54Jw
Thanks. Um, do you have anything that is not on Youtube? One of the nice
things of the mailing list is that it's archived. But that applies only
to information inline in the e-mail, of course. Also, personally, I
would prefer something with less java-script, less commercials, and less
tracking.
Nico
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
