[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?

[David Hendricks]

On Wed, Jun 21, 2023 at 4:19 AM Nico Huber  wrote:
>
> On 21.06.23 04:58, David Hendricks wrote:
> > On Tue, Jun 20, 2023 at 4:41 PM Peter Stuge  wrote:
> >> ron minnich wrote:
> >>> And, yes, no question, this is an activity that likely occurs less than it
> >>> should. Such is our industry.
> >>
> >> Such is project policy. Maybe because it's the lowest common
> >> denominator in industry.
> >
> > The project's policy is to remove code that becomes difficult to
> > maintain, whether due to bitrot or technical barriers to refactoring.
>
> I don't see this "becomes difficult to maintain" much. Much of what
> we removed in the last years had either an unfortunate design (cf.
> FSP 1.0) and or was already merged in a difficult to maintain state
> (cf. AGESA). IMO, this is where we should consider to learn from,
> not just make it policy and go on.

I'd also add that we shouldn't stonewall new contributors because of
problems outside of their scope, going along with what Martin wrote
earlier.

> A bit OT, and sorry, if this is an odd question: Wasn't this the point
> of OCP, that they can talk to each other? If it's possible, we could try
> to talk earlier about the code, before it's written and pushed upstream
> later.

It's more about setting some general parameters to ensure the code can
be downloaded, modified, and redistributed. That alone is a huge hill
to climb in our industry. Perfection will be the next battle once
we've removed hurdles to initial development.

That said, there are some collaborative efforts with silicon vendors
using their reference platforms, for example Intel's Archer City and
AMD's Onyx, however OEM products are not usually developed this way.
To be clear, participation in open source projects does *NOT* require
companies to share upcoming product details with potential
competitors. I've heard FUD from certain parties claiming otherwise.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?

[David Hendricks]

On Tue, Jun 20, 2023 at 4:41 PM Peter Stuge  wrote:
>
> ron minnich wrote:
> > And, yes, no question, this is an activity that likely occurs less than it
> > should. Such is our industry.
>
> Such is project policy. Maybe because it's the lowest common
> denominator in industry.

The project's policy is to remove code that becomes difficult to
maintain, whether due to bitrot or technical barriers to refactoring.

> > It is not possible to know, a priori, what those common pieces will be.
>
> I think this is where we fundamentally disagree. I think common
> pieces and their interfaces can be recognized based on the hard
> IP blocks and their interfaces plus some creative thinking based
> on development experience.

I'm pretty sure the Intel engineers who wrote the Archer City CRB code
didn't have IBM's and ByteDance's server specs handy or know how they
would use the code.

OTOH Intel also has this thing called EDK2 where they implement all
kinds of interfaces for each IP block, however it requires a hugely
bloated framework and never quite works the way you want, requiring
ungodly hacks to the sources and build system to override the default
behaviors. I prefer to keep things simple and just refactor a few
lines of coreboot code when needed.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?

[David Hendricks]

Thanks everyone for this great discussion. I looked at making
Transformers a variant of Archer City CRB, but came to the conclusion
that others foresaw which is that a multi-vendor variant model is not
a good fit in this case.

In this case the SOC support is new to the tree and we have boards
developed in parallel by multiple entities, so it's unsurprising to
see some redundant bits. As Angel mentioned it will be easier to
refactor portions of the code with the large patches merged in a
buildable and (hopefully) usable/testable state.

On Tue, Jun 20, 2023 at 1:51 AM Lean Sheng Tan  wrote:
>
> Thanks again everyone for chipping in, this was a pleasant discussion (a bit 
> surprise to me TBH :D )
> I agree with Nico and Ron, and also with Angel's suggestion. For now, we can 
> let the MB code go in first, and if there is something in common we can 
> always restructure it, like we used to before.
> But if I understand correctly on how usually ODM/OEM boards evolves, the 
> first generation will usually be much closer to Intel CRB, but there will be 
> a few more variants of MB to be chucked out later on under same vendor, so it 
> makes perfect sense to let it host under individual vendor folder.
>
>
>
> On Tue, 20 Jun 2023 at 00:47, ron minnich  wrote:
>>
>> There have always been two approaches to new mainboards in coreboot.
>>
>> The first, "copy and convert", is to take the most similar board, copy the 
>> code, and then change it. I believe this is the strategy paul is unhappy 
>> with.
>>
>> The second, "embrace and extend", is to modify existing board in place to 
>> support a new board.
>>
>> The question of "copy and convert" vs "extend and embrace" has come up many 
>> times in the last 23 years. There are no ideal answers, we have found.
>>
>> When the boards are variants from a single vendor, it can work well. 
>> chromebook boards are a good example. One vendor will (we hope) make sure 
>> that, as new variants are added, they do not break old variants.
>>
>> We've had trouble over the years merging boards from different vendors. Even 
>> in the simple case, with similar boards from more than one vendor, a merged 
>> board will look like the union, with a greatly expanded set of build 
>> options. But in some early coreboot experience, e.g. with Opteron ca 2004, 
>> we found that some options were incompatible. CKE was a big pain.
>>
>> In the earliest days, we did make an effort to have common code for similar 
>> boards. Problems arose as boards from one vendor changed in ways 
>> incompatible with other vendors. We saw this from the beginning with boards 
>> that used SiS 630 chipsets, which led to a panic debug session for SC 2000 
>> as we dealt with a new board, allegedly compatible with an earlier board, 
>> which had some key differences that could not be accommodated in a single 
>> board source tree. We went with copy and convert.
>>
>> I think it's great to have as much common code as possible. But calling an 
>> inventec board and a bytedance board variants just because they happen to 
>> use SPR? I think that's a mistake.
>>
>>
>>
>> On Mon, Jun 19, 2023 at 2:02 PM Paul Menzel  wrote:
>>>
>>> Dear Martin,
>>>
>>>
>>> Thank you very much for taking the time to answer.
>>>
>>>
>>> Am 19.06.23 um 22:31 schrieb Martin Roth:
>>> > Duplicated code between mainboards isn't a big issue in my opinion.
>>> > It allows the boards to be customized without worrying about other
>>> > companies' mainboards. We've tried to make mainboards as small as we
>>> > can, and we can keep refactoring things out where it makes sense.
>>>
>>> Are you talking in general or in this specific SRP boards. As stated by
>>> others, a lot of code was copy-pasted.
>>>
>>> > If some common code fits under the SoC, that's great, and I'm all for
>>> > moving it there, but let's not force the burden of that refactoring
>>> > work onto inexperienced mainboard maintainers. Doing so just
>>> > encourages vendors to keep their mainboards in private repositories -
>>> > the opposite of what we should be working for. Even if this means
>>> > that it doesn't get refactored and gets a bit out-of-date, I find
>>> > that preferable to making contributors (more) frustrated about
>>> > getting their boards accepted.
>>>
>>> I haven’t seen any frustration. Do you know more? I agree, nobody should
>>> be frustrated. The question has to be answered though, who is going to
>>> do that general maintenance work – I think Kyösti raised a similar
>>> question a few weeks back. I welcome all new contributors, but it has to
>>> be clear, that coreboot – especially for commercial offerings – needs
>>> and expects some kind of maintenance commitment. I am pretty sure, the
>>> vendors are going to understand the benefits. It just has to be
>>> communicated transparently.
>>>
>>> > CRBs are (as the name says) reference boards and it should be
>>> > absolutely fine to duplicate their code when another mainboard vendor
>>> > uses the CRB as their 

[coreboot] Re: Coreboot chat room

[David Hendricks]

Hi Arne,
A couple of questions about this came up in a recent leadership meeting [1]:
- How does this improve upon the existing options? We already have
IRC, Slack, and Discord channels. Is there something about XMPP that
makes it more compelling than those other options?

- Who moderates the XMPP chatroom? At the very least there needs to be
admins who can deal with spam, abuse, and enforce community guidelines
[2] when needed.

[1] 
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#
[2] 
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/Documentation/community/code_of_conduct.md


On Tue, Mar 7, 2023 at 11:00 AM Arne via coreboot  wrote:
>
> Hi,
> I just created a XMPP chat room about coreboot on our public XMPP server and 
> I would be happy to make it to an official coreboot chatroom. The server is 
> running since 2,5 years and will stay online for at least the next years. 
> Maybe you like to join.
> So the main question is, can I write in the chatroom description "official 
> coreboot chatroom"?
>
> I would also offer the coreboot delevopers a free XMPP chat account on 
> https://ocean.monocles.de/apps/registration/
> or
> https://ocean.monocles.eu/apps/registration/
>
>
> Thanks for your project and best regards,
>
> Arne
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: RFC: Intention to join Open Source Firmware Foundation

[David Hendricks]

Hi Paul,

> 1.  What is OSFF modeled like – like the Linux Foundation?

The slideshow linked on the opensourcefirmware.foundation homepage
might answer some questions:
https://opensourcefirmware.foundation/slides/Open-Source-Firmware-Foundation_public.pdf

> 2.  What benefits does the coreboot project hope to get from being part
> of OSFF? Because the goals align with the coreboot project goals?


Overall yes, the goals align well with those of the coreboot project.
Personally I see value in creating a coherent organization
representing the interest of various projects and parties in this
ecosystem. For example, we've all seen many e-mail and chat threads
about vendors that go nowhere. If OSFF can help bridge that gap
between users/developers and vendors then it will be a huge help
(that's a big "if").

> 3.  As what kind of member do we want to join?

Associate, like other open-source projects.

> 4.  What entity(?) of coreboot is joining?

The same one as with the Software Freedom Conservancy.

> 5.  Who pays the membership fees, and how much are they?

$0 for associate members.

> 6.  I couldn’t find the goals of the OSFF stated in the documents. The
> bylaws say:
>
>  > The purposes of the Corporation shall be those set forth in the
>  > Articles of Incorporation of the Corporation, as may be amended
>  > from time to time (the "Articles of Incorporation").
>
>  I only found that members mostly have to “engage in or support the
> production, manufacture, use, sale, or standardization of open-source
> firmware technologies”.

The slide deck on the homepage should clear things up.

> 7.  Who is going to represent the coreboot project in the OSFF?

Same as with the SFC.

> 8.  Who is the OSFF president and secretary Christian Burghart [1]?

He's the lawyer who handled the incorporation process. That's why the
word "Initial" appears before those titles ;-)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] RFC: Intention to join Open Source Firmware Foundation

[David Hendricks]

Hi everyone,
As mentioned in this week's leadership meeting, membership in the Open
Source Firmware Foundation (OSFF) has been under consideration for
some time and we feel that we should move ahead. We plan to join by
the end of this month if possible.

This will be in addition to our membership with the Software Freedom
Conservancy who handles donations to coreboot.org and legal services
and will continue to do so. We've reviewed membership documents and so
far we do not see any conflict in this arrangement.

>From a community standpoint, we'd like to know if there are any
objections or good reasons *not* to move ahead with membership in
OSFF. Feel free to reply on the list or in private with your thoughts.

More info about OSFF can be found here: https://opensourcefirmware.foundation/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: POST codes and PCI Post card

[David Hendricks]

As Ron said, they are very useful. A lot of initialization happens
before PCI is enabled. Bear in mind that the POST codes traditionally
are written to IO port 0x80 (not PCI MMIO), so they can be output from
firmware immediately after the CPU is let out of reset.

The old coreboot wiki has some information about POST codes and cards
here: https://www.coreboot.org/POST_card


On Mon, Jul 11, 2022 at 9:58 AM ron minnich  wrote:
>
> They are incredibly useful, which is why they are still there. That
> first post-bist code has been there since the first code in 1999.
>
> If you have jtag, it still helps. But many BMC also have ways to see
> port 80 writes. You can see it before PCI is up.
>
> On Mon, Jul 11, 2022 at 8:00 AM Pedro Erencia  wrote:
> >
> > I've noticed that POST codes are sent very early. In x86 the first code is 
> > sent just after storing the bist.
> > Are codes sent so early useful? They are sent ages before any PCI 
> > configuration. Is there any guarantee of them reaching a PCI POST card?
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Removing Absolute BIOS (a commercial backdoor) from a Home Computer

[David Hendricks]

There's a good chance that your laptop will only boot Lenovo's signed
firmware. The best (perhaps only?) thing to do is get a refund and buy a
laptop that doesn't have this feature. The "Vendors" link from coreboot.org
lists a few examples of laptops which come with coreboot.

On Fri, Jun 24, 2022 at 2:22 AM keith.krohn--- via coreboot <
coreboot@coreboot.org> wrote:

> Hello,
>
>
> I would like to run coreboot on my home computer to disable Absolute BIOS.
> I didn't want it but had little choice when I got my new Lenovo PC.
>
>
> I see the download page on your site, but I am not really sure how to make
> coreboot work on my computer as the download doesn't appear to have an
> executable, but various components that are implemented according to
> specific steps which I don't want to screw up and brick my new computer. XD
>
>
> Please advise and thank you in advance!
>
>
> Best,
>
> Keith Krohn
>
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] #pragma once

[David Hendricks]

Thanks for digging up all that useful information, Martin! So `#pragma
once` is not the clear winner after all. Too bad since we could eliminate
some boilerplate code with that approach.

Is there another way to solve the problem Arthur raised in this thread? The
LMKL thread had a python script and people were also talking about adding
something to checkpatch.pl. Maybe these days it's sufficient to assume
clang will catch any real problems (CB:62173).



On Mon, May 16, 2022 at 1:03 PM ron minnich  wrote:

> we have, in the past, used Linux kernel style as our guideline on
> coreboot style.
>
> I'd say, based on Martin's note, that #pragma once is not such a good
> idea after all. If we decide NOT to use it, however, let's put a note
> about it in our style guide?
>
> This is not the first time this question has come up.
>
>
> On Mon, May 16, 2022 at 12:34 PM Martin Roth 
> wrote:
> >
> > After reading what I've included below, I'm going to have to vote to
> keep the guards.
> > Martin
> >
> > May 16, 2022, 10:59 by david.hendri...@gmail.com:
> >
> > > On Mon, May 16, 2022 at 8:59 AM ron minnich 
> wrote:
> > >
> > >>
> > >> btw, sometimes this has gone the other direction ..
> > >> https://github.com/lowRISC/opentitan/pull/5693
> > >>
> > >
> > > It looks like they did that solely to conform to Google's style guide
> > > which, dogmatic as it may appear, makes sense since OpenTitan is a
> > > Google-lead project.
> > >
> > The question then is 'why does Google require the use of guards?'.
> Whatever you think of google, they're not going to mandate something like
> this without a good reason.
> >
> > I went searching for where this rule came from, and found this:
> >
> > ```
> > If you trust our in-house C++ compiler gurus, here's the most salient
> part of the whole thread linked above.Matt Austern (4/11/2013): If you talk
> to the authors of [most C++] compilers, I think you'll find that most of
> them consider "#pragma once" (or the equivalent #import) to be a flaky
> feature -- something that works almost all of the time and that can cause
> seriously annoying bugs when it doesn't work.
> >
> > Chandler Carruth (4/12/2013): As one of the authors of one of those
> compilers, I couldn't agree more.
> > ```
> > any interested Googlers can find this here:
> >https://yaqs.corp.google.com/eng/q/5768278562045952
> >
> >
> > Further digging:
> > ```
> > To support #pragma once, the compiler tries to identify duplicate
> encounters with the same file, but the check gcc actually performs to
> establish the identity of the file is weak. Here's someone who made two
> copies of the same header with different names, each with a #pragma once,
> and it screwed up his build.
> >
> >  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566
> >
> > The two headers had the same size, same content, and same timestamps
> because he had run "touch *" on them, but they were intended to both be
> included. Only one was included, and the other was falsely identified as a
> re-inclusion and ignored.One might say he was asking for trouble by running
> "touch *", but timestamp collisions are EASY to come by. First of all,
> they're only 1sec resolution. You might patch all the relevant files and
> they'd have matching timestamps. You might be using a network filesystem
> that just doesn't bother with timestamps (common).
> > ```
> >
> > Now both of these are almost a decade old, so things might have changed
> quite a bit since then.
> >
> >
> > Linux kernel threads:
> > https://lkml.iu.edu/hypermail/linux/kernel/1401.0/02048.html
> >
> https://lore.kernel.org/lkml/CAHk-=wi54descexxpmro+q2nag_tup+y5ybhc_9_xglerfp...@mail.gmail.com/
> >
> > ```
> > On Sun, Feb 28, 2021 at 11:34 AM Alexey Dobriyan 
> wrote:>> >> > End result: #pragma is fundamentally less reliable than the>
> > traditional #ifdef guard. The #ifdef guard works fine even if you> >
> re-read the file for whatever reason, while #pragma relies on some> > kind
> of magical behavior.You continue to not even answer this very fundamental
> question."#pragma once" doesn't seem to have a _single_ actual real
> advantage.Everybody already does the optimization of not even opening -
> muchless reading and re-parsing - headers that have the traditional
> #ifdefguard.And even if you _don't_ do that optimization, the #ifdef
> guardfundmentally semantically guarantyees the right behavior.So the #ifdef
> guard is (a) standard (b) simple (c) reliable (d) traditionaland you have
> yet to explain a _single_ advantage of "#pragma once".Why add this
> incredible churn that has no upside?So no. We're not using #pragma once
> unless y9ou can come up with somevery strong argument for itAnd no, having
> to come up with a name for the #ifdef guard is not astrong argument. It's
> simply not that complicated.   Linus
> > ```
> >
> >
> >
> >
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to 

[coreboot] Re: [RFC] #pragma once

[David Hendricks]

On Mon, May 16, 2022 at 8:59 AM ron minnich  wrote:
>
> btw, sometimes this has gone the other direction ..
> https://github.com/lowRISC/opentitan/pull/5693

It looks like they did that solely to conform to Google's style guide
which, dogmatic as it may appear, makes sense since OpenTitan is a
Google-lead project.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] #pragma once

[David Hendricks]

On Sun, May 15, 2022 at 11:56 AM Arthur Heymans  wrote:
>
> Hi
>
> To make sure headers don't create conflicts, guards are added to all of them.
> But the guard needs to be correct: e.g. 
> https://review.coreboot.org/c/coreboot/+/64360/2

A few more that I noticed by grepping around:
https://review.coreboot.org/c/coreboot/+/64364

> Most compilers implement '#pragma once ' as an alternative.
> Should we use this instead across the tree, as it is less error prone and 
> less code?

Sounds good to me. It will also mitigate awkward guards with paths in
them, for example in src/mainboard/google/smaug/pmic.h which uses
`#ifndef __MAINBOARD_GOOGLE_FOSTER_PMIC_H__`. (This should probably be
factored out into a common header that smaug and foster include, but
that's another matter)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Support to Openpower platforms

[David Hendricks]

3mdeb has been working on this. Here is some documentation with resources
to get started: https://github.com/3mdeb/openpower-coreboot-docs. They've
also given several recent talks about this, and many of their patches have
been merged into upstream coreboot.

If you've got a Talos II or other POWER9 platform I'm sure they'd love some
help testing it :-)

On Thu, Mar 31, 2022 at 12:46 PM ratatouille gamer <
ratatouillemo...@gmail.com> wrote:

> the openpower have created this new firmware for boot openpower platforms
> is possible to coreboot use this base to write a new code for best support
> in openpower socs?
> https://github.com/open-power/hostboot
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Google Chrome OS Chromebook recovery util

[David Hendricks]

On Thu, Mar 10, 2022 at 9:33 PM Gregg Levine  wrote:

> And now for the third time around, it seems since this tool is for
> creating recovery images of existing systems, I noticed that Google
> has itself there, in this case Chromebook CR-48 for example. Isn't
> that one an internal reference system not designed for retail
> purposes? Oh and there are two others there as well.
>

I'm not familiar with the tool that you mentioned, but Cr-48 was the very
first Chromebook. You're correct that it wasn't available for retail,
however it was distributed publicly for evaluation purposes in anticipation
of the next round of Chromebooks a few months later. I guess one could call
it brutalist in its design - no frills and designed to put the "browser as
the OS" concept front-and-center without distractions. The full line-up can
be seen here:
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.

[David Hendricks]

> > I have to calmly tell it "laptop=this is not a laptop" and then it works as 
> > usual. I don't remember
> > ever having to do this before. Why? If I have a clue I can code up and 
> > submit a patch.

This happens if flashrom can't identify the chassis type via SMBIOS
(type 3 table IIRC). Basically, it assumes that if the user is on a
system that is likely to have an embedded controller (typically
laptops) then it is unsafe to proceed since ECs often share the
firmware ROM and may interfere with the update process.

So if you can fix SMBIOS to indicate that you are using a desktop
board then flashrom shouldn't bother you with that.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: "Private" changes on Gerrit are now disabled and removed

[David Hendricks]

Hi Sameer,

> hi Patrick,
> I will use this Private feature very badly in my daily job, for some
> critical code. I will create a private CL in gerrit and will build a
> Coreboot  by using jenkins based on other builds by cherry picking
> this private CL. I am not from a developer background, i just want to
> know, if there is anyother alternative to this?
> --sameer.

We ended up deciding to keep this feature enabled since others in the
community feel it's useful, and have documented it better. Patrick has
also reached out to the Gerrit team to see if the name can be changed
to not imply confidentiality.

See the Nov. 17 2021 leaderhsip meeting notes for details:
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/QOMQ3DQCDO4OKFK4WTV5H7TF2MRJXRFY/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to maintain AGESA-based ports long-term?

[David Hendricks]

On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov  wrote:
>
> Personally I don't see any reason for branching, if 99% of the rest of
> coreboot code (payloads etc.) is compatible. This will only get us
> outdated for these components on this branch, which otherwise could
> (and should) be kept simultaneously up-to-date to get the latest
> goodies. So, just make two folders: 1 - resource allocator v3, 2 -
> resource allocator v4, and access either v3 or v4 from outside
> depending on your board selection.

This can work, however it depends on how much other code is impacted.
A good example of this is the new SMM module loader introduced
recently to accommodate CPUs with >32 threads (CB:43684). It was
merged with "v2" in the filename so that work could continue on newer
server CPUs while the original loader was still in use everywhere
else. After some time spent testing it, the "v2" module loader became
the default and "v2" was dropped from the name (CB:51528).

In that case the code was isolated and the newer version was
essentially a drop-in replacement. But even then, there was at least
one known case where something broke (CB:52765). For something like
the resource allocator I would expect a lot more dependencies on other
parts of the tree. This can turn into a big and difficult-to-debug
mess if code beyond the resource allocator has different behaviors
depending on which version is being used.

tl;dr: What you suggest is possible, but cost and benefit need to be
considered and the cost can be very high if other parts of the
codebase are impacted.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

[David Hendricks]

1. These boards will be gone for the people who check the "mainboards
> supported by coreboot" and see only the "new Intel stuff". This
> hinders the coreboot community growth around the "gone boards", and
> also of the coreboot community in general: the fewer boards are
> supported by coreboot, the more difficult it is for a potential
> user/contributor to find the supported board and join us.
>

For the record, we have removed Intel boards from the master branch in the
past - See 4.11_branch. This was for boards that used FSP 1.0, including
popular Baytrail Atom and Broadwell-DE platforms which are still widely
used today. This ensures that those platforms continue existence on an
easy-to-find stable branch where one can reasonably expect to check out the
code and have it work. Checking out the master branch only to find out that
it doesn't work and then bisecting years worth of commits is a poor user
experience.

Perhaps we should follow the 4.11_branch example and do something similar
with old AGESA boards? Boards which are forward-ported and tested can stay
(or be re-introduced) in the master branch, of course.

Many of the AGESA platforms in the list Arthur provided are ~10 years old.
Some are clearly obsolete, like the Gizmosphere boards that have not been
in production for years and whose manufacturer is defunct. Others like the
PCEngines APUs should be more readily available to test and have developers
able to spend some time forward-porting the necessary bits.

Lastly, I'll mention that there is an active crowdfunding effort to
re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719.
There's clearly a lot of enthusiasm with that board, and 3mdeb is already
porting allocate v4 to it. Perhaps enthusiasts for other boards can
piggyback on this effort and leverage some of their work to bring other
boards up to date.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: DIP8 flash programming for development

[David Hendricks]

On Sat, Nov 27, 2021 at 10:39 AM Angel Pons  wrote:

> Before I
> had the EM100, I simply moved the flash chip back and forth by hand,
> from the mainboard to a breadboard wired to a CJMCU FT2232HL mini
> module (external programmer) and viceversa. I added another DIP8
> socket between the flash chip and the mainboard's socket, so that I
> could easily and quickly remove and replace the flash chip.
>

I've done this as well. A couple parts recommendations to make this easier:
- High quality DIP8 sockets with rounded legs such as
https://www.digikey.com/short/q0522m77. Those tend to be much easier to
insert and remove into a motherboard's socket than flash chips which have
flimsy legs and will help prevent damage to the mainboard socket when
removing and inserting the chip repeatedly. And if you need to solder
something, it's better to do it on one of these sockets than soldering to
the motherboard or the chip itself.

- If you have your programmer connected to a breadboard, keep a ZIF DIP
test socket like this mounted in place to make inserting and removing the
chip quick and easy: https://www.aliexpress.com/item/32708487337.html.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: "Private" changes on Gerrit are now disabled and removed

[David Hendricks]

Nice catch, Patrick. I used this feature long ago [1], but as the Gerrit
guidelines note we can now mark patches as WIP in the UI or just put
[DONOTSUBMIT] in the summary line if a patch isn't ready for review.
Furthermore, these days it's very easy to set up one's own git repo and
access controls using services such as Github, Gitlab, etc.

IMO it's best to keep the feature disabled so that people don't make
wrong assumptions.

[1]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/XT25LVQE73DSBV3WP46RQRV3KAXO2SWG/

On Thu, Nov 11, 2021 at 3:05 PM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> Hi everybody,
>
> it came to my attention that changes marked "private" on Gerrit are hidden
> in the UI but easily accessible through gitiles and with "git fetch".
>
> I don't think it matters for most cases, but since we advertised it as
> being accessible for the owner and individual reviewers, I didn't want to
> keep things exposed, especially not after there's an announcement that such
> access is possible (as through this email). Therefore I:
>
> - disabled the "private" CL feature in the Gerrit UI, so you can't mark
> changes as private
> - created per-account git bundles[1] of their private CLs. Since I don't
> want to spam a few hundred users with stuff they might not care about, this
> is a pull transaction: if you want them, reach out to me.
> - removed the private commits and references from the coreboot.git repo.
> You might still see the changes in the UI but that's due to its aggressive
> caching: The UI actually honors the private flag, so that's not a concern
> and all other means of accessing commits access the repo and will fail on
> these now-gone commits.
>
> https://review.coreboot.org/c/coreboot/+/59229 also proposes updating the
> docs to remove mentions of the "private change" feature.
>
> As an alternative we could also decide to re-enable the feature but with
> documentation pointing out that there are ways for motivated
> unauthenticated users to access these commits, which makes them more of a
> structuring feature (keep things out of sight until they're ready). In that
> case I could also reinstate the commits I deleted from the repo.
>
>
> Thoughts?
>
>
> Best regards,
> Patrick
>
> [1] https://git-scm.com/docs/git-bundle
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Providing an Interface to load PSE FW for Intel Elkhart Lake Platform

[David Hendricks]

Hi Nico,
One thing that's unclear to me is if there are lingering technical reasons
for holding the patch back, aside from a Kconfig variable that Michael
recently requested. Werner asked that question as well but the answer(s),
if any, seem to have been lost in the philosophical aspects.

If the patch still needs work then the author should continue to work on
it, but please keep the technical and non-technical arguments separate.

Sadly, I don't think Sheng will be able to solve the blob situation on
Intel platforms in this patch.

Other responses are in-line:

So please, coreboot leadership, take part in the project


You saw Werner's comments in the patch, right? I think you did since you
replied to them...


> At least when you decide something, just send an
> email. :)


Like this?
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/SCV363C5SAG32CB74XIYIASRFBACSCMR/


> The mailing list is the only place where everyone gets a
> chance to attend equally.
>

Does this link work for you?
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.j6ljr2742djc

If not, please let us know - permissions should be set so that anyone can
view it.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: First commercially available coreboot for Intel Xeon-SP

[David Hendricks]

This is awesome! Thanks for sharing, and keep up the great work!

On Fri, Nov 5, 2021 at 12:06 PM Jonathan Zhang 
wrote:

> Hi,
>
> We now have the first commercially available coreboot solution for
> servers based on Intel Xeon-SP processor (specifically CooperLake
> Scalable Processor).
>
> WW OCP DeltaLake server (with OSF being part of it) was OCP accepted;
> Also the server and its OSF solution are on market, backed by WW and
> 9E partnership.
>
> OCP blog:
> https://www.opencompute.org/blog/open-system-firmware-for-ocp-server-deltalake-is-published
>
> WW PR:
> https://www.prnewswire.com/news-releases/wiwynn-successfully-implemented-open-system-firmware-on-its-ocp-yosemite-v3-server-301417374.html?tc=eml_cleartime
>
> I look forward to a positive loop between coreboot engineering as open
> source firmware and its commercial success! Go coreboot for a fair
> server market share.
>
> Jonathan
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: There is a python in our toolchain?!?

[David Hendricks]

As a rule of thumb, any project involving a substantial amount of Python
always ends up needing a Docker container to build. So I'm in the "no" camp
for making Python a dependency, however I think it's fine to keep things
as-is where it can be used for helper scripts and utilities for specific
purposes such that they aren't critical to building the tree.

On Wed, Sep 29, 2021 at 2:58 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> That said, python makes its way back into the tree every now and then
> (typically as small snippets to compute and add hashes to binaries as
> needed by ARM SoCs). Uncanny, but typically not a big deal.
>
...
> To avoid these scenarios, could we possibly nail down the policy on python
> in coreboot?
>

The policy should be simple: The CI system (Jenkins) must be able to build
every target in its default configuration.

If we introduce Python as a dependency, then all Python in the tree must be
compatible with whatever version Jenkins uses. And if we're going to impose
the burden of fixing Python on everyone, then all developers must have the
ability to install a compatible version in their OS. Given the experiences
many of us in this thread have had and how widely distros vary in Python
support, I don't see this as tenable.

Another thing to keep in mind is that we have these sorts of helper scripts
from multiple vendors/parties over several years, and we'll likely see more
in the future. Pushing them all to use whatever version(s) of Python we
decide to build with does not seem realistic.

All that said, I'm fine with Python being used for helper scripts and such
as we've done in the past. It gives developers/vendors/etc. freedom to use
whatever works for their purposes without imposing a huge burden on
everyone else.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot BIOS question

[David Hendricks]

Hello Aaron,
That error message appears to be coming from Pfsense. After searching
around a bit, it appears that the boot loop issue has occurred in multiple
models of Pfsense firewall appliances and is due to filesystem corruption.
The most common suggestion I see is to reboot into single user mode and run
`/sbin/fsck -y /` until you don't see any errors appear.

As for the cause, some people mention abrupt shutdown due to a power
outage. If the problem occurs multiple times then you might consider
swapping out the SSD.

On Sat, Jan 30, 2021 at 6:07 AM SuperNova via coreboot <
coreboot@coreboot.org> wrote:

> Hello,
>
> I am a new user of Coreboot who recently purchased a Protectli firewall
> with Coreboot pre-installed. The firewall is running PfSense that I
> installed on it. Everything was going ok for a few days until I started
> having issues with PfSense and now I am having problems getting PfSense to
> launch at all. I believe this is related to a hardware issue with the
> firewall. During the coreboot launch I am getting an infinite loop which is
> triggered at the following line:
>
> cpu reset proxy stopped cpu 1
>
> Sounds like an issue with the hardware to me. I believe I saw this same
> issue referencing cpu 2 as well. I have tried over a period of several
> weeks to boot up and I always get this message and then a loop back to the
> the coreboot initialization. At this point I cannot tell if this is a
> coreboot, pfsense, or hardware issue, and I am getting ready to just buy
> another firewall with pfsense already installed and I am hoping someone has
> the time to give me a brief idea of what might be going on here. I am
> fairly PC savy but am having difficulty drilling down to what might be
> driving this specific issue on the web. I do like your product and plan to
> purchase a PC with coreboot in the near future.
>
> Thanks a lot for your time.
> -Aaron
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[David Hendricks]

>
> > You seem to imply that this may cause some kind of security or
> availability problem
>
> Can you guarantee that a silently installed submodule's repo won't get
> hacked and replaced with malicious code for example? We have seen that
> happening with other repos already (github, sourceforge and other
> webhosts too). The fewer dependency you have, the less are the chances
> for a vulnerability or sechole, simple as that.
>

We are not blindly taking code from github, sourceforge, etc. All
submodules are hosted on coreboot.org and the main repo points at the SHA
it's using, and have the same guarantees as code in the main coreboot repo.

This example might help illustrate it:
libgfxinit submodule: https://review.coreboot.org/plugins/gitiles/libgfxinit
When somebody wants to use point at a new version:
https://review.coreboot.org/c/coreboot/+/43559

But the main problem here I think is, following the tutorial
> https://doc.coreboot.org/tutorial/part1.html does not work, because it
> results in compilation errors (due to missing dependencies). This is
> clearly bad and must be resolved.


Can you be more specific? I ran thru the instructions and built for a qemu
target and did not run into any problems - it cloned the various submodule
repositories as expected and the build worked fine.


> About the solution: I think the best would be to use ifdef guards in
> the C code (both for coreboot and cbfstools), that's what the
> precompiler is for, after all. There's already a CONFIG_VBOOT_LIB
> config option, so why isn't it used? I see no reasonable excuse for
> that. I also think that "default n" should be added to
> https://github.com/coreboot/coreboot/blob/master/src/security/vboot/Kconfig
>
> However if Kconfig isn't wanted for any reason, it's pretty simple to
> add "ifneq ($(wildcard ../3rdparty/vboot/somefile*),)" to the
> Makefile. This way if the vboot submodule is cloned, then coreboot and
> cbfstool would be automatically compiled with support for it (without
> a Kconfig option). But for people who just clone the base repo, there
> would be no compilation errors. Everybody happy, problem solved.
>

Sort of, yes. As Julius mentioned this is possible but it's a fair bit of
work with little benefit. The common code which uses vboot has to do with
cbfs hashing. I personally think of it as a good feature, though I can see
arguments for not wanting it as well.

The submodule should be downloaded automatically and does not have a
restrictive license, unlike some other submodules that the user must opt-in
to. Is there a desire to remove hashing functionality in cbfs, or is the
problem here just the fact that the hashing library is part of a submodule?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[David Hendricks]

On Mon, Nov 9, 2020 at 4:51 PM Peter Stuge  wrote:

> Nico Huber wrote:
> > I don't think it's documented. As you already noticed, we depend on
> > a 3rdparty library (vboot), so we actually don't know the minimum.
>
> Whenever I want a build without vboot I get really annoyed about this
> hardcoded dependency, even when vboot is disabled in Kconfig.
>
> Would a patch to make the dependency conditional on Kconfig get accepted?


I should hope so, though I recommend starting a new thread to see if
experts on vboot can chime in and explain why this is or isn't a good idea.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot and Intel Flash Descriptor Erase Issue

[David Hendricks]

Hi Balaji,

On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar 
wrote:

>
> Hi David,
>
> Have verified and confirmed that coreboot process as well, it is
> disabling the BIOS write protect and Enable Prefetching and Caching as part
> of fast_spi_init().
>

Were you able to figure this one out? The snippet you showed is from
fast_spi_init() which should get called once early on. It is possible that
something later on calls fast_spi_enable_wp(), perhaps
smihandler_soc_check_illegal_access().
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot and Intel Flash Descriptor Erase Issue

[David Hendricks]

Hi Balaji,

I have tried to disable it using setcpi utility and it remains the same
> value. Also the flashrom utility also tries but it remains the same.
>
> Warning: BIOS region SMM protection is enabled!
> Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed.
>
> Also FLOCKDN=1 is set as 1 as well.
>
> I can clearly tell the BIOS region is read and writable but Protected
> registers are read only that's also the reason I am not able to write the
> BIOS region.
>
> What are the options/methods to unlock / disable the Bios Write
> enable(BIOS_CNTL) or to access the HSFS registers to set the FLOCKDN bit to
> 0.
>

Since BIOS_CNTL is 0xab, the SMM_BWP, BLE, and BIOSWE bits are set. This
means that you can only write to the BIOS region from within SMM. You
should not be able to change this from userspace.

The BLE and BIOSWE bits are not set by default. You mentioned that you're
using coreboot, can you check the source code to see if BIOS_CNTL is
getting set anywhere? You can also check if FLOCKDN is getting set,
possibly by FSP (look for the SpiFlashCfgLockDown FSP parameter getting
set).

>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot and Intel Flash Descriptor Erase Issue

[David Hendricks]

On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar 
wrote:

> Thank you Peter for the details. Yes it is identifying it as opaque flash
> chip. We are able to completely read it but erase fails.
>

There is some documentation in the tree to help explain the "opaque flash
chip":
https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_intel.txt#n8


> I understood from the logs of flashrom that SMM protection is enabled.
> Working on it to disable it.
>

You will also need to enable host CPU write access to other regions you
with to be writeable. From your earlier e-mail it appears that you've
already done this for the ME region, however you'll need to do it for IFD
and other regions you wish to update. Be advised, however, that *not*
locking certain regions may cause the ME to behave differently.

You can also target specific regions for updates using `--ifd -i 
-N`, for example `--ifd -i bios -N` will make flashrom only attempt to
write and verify the BIOS region (without -N flashrom will attempt to
verify the entire chip contents).
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Query related to GSoC 2020

[David Hendricks]

Hello Shridhara,
Thanks for reaching out. A good understanding of C programming is
definitely required, so if you are comfortable with C then that is a
good start. Beyond that, coreboot generally involves in-depth
knowledge about computer architecture and components. It can be a
steep learning curve since you'll need to do a lot of research about a
piece of hardware or some aspect of the codebase you wish to improve.

Is there anything about firmware or the boot process that you find
particularly intriguing? Do you have hardware that is supported by
coreboot (look thru src/mainboards and src/soc for examples), and can
you sacrifice it for the project? Have you tried running coreboot
under QEMU?

Here are some other resources you can check to see if this is the
right project for you:
https://doc.coreboot.org/contributing/project_ideas.html
https://www.coreboot.org/Previous_GSoC_Projects
https://summerofcode.withgoogle.com/archive/2019/organizations/6048278473342976/


On Fri, Mar 20, 2020 at 2:43 AM Shridhara Hegde  wrote:
>
>
>
> Hey,
>
> I am Shridhara Hegde, a 2nd year Computer Science & 
> Engineering student from Bangalore, India. I came across the coreboot GSoC 
> page and noticed C programming listed as a technology used in the projects. I 
> have a decent understanding of the basics of C such as pointers, dynamic 
> memory allocation and file handling. Kindly let me know if these skills are 
> even remotely sufficient to be of any good use at any coreboot projects and 
> what more do I need to learn in order get selected as a part of GSoC in the 
> future.
>
>
>
> Thank You
>
> Shridhara.
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel processors supported

[David Hendricks]

Hello,

> We're developing a security focused computer product and hoping to use 
> coreboot. Is it possible to use with modern Intel laptop processors and if so 
> which families or platforms?

Easiest way to find out is to look thru the src/soc/intel/ directory
in the codebase:
https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel

Upstream Intel reference boards are in
https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/intel.
There are many other mainboard targets (laptops and otherwise) that
use them under src/mainboard/.

This said, please be advised that support for Intel platforms is not
fully open source; only parts of it are open. You can certainly do
better than most using coreboot on Intel platforms, however if fully
open source code is important in your security model then you will not
find it in the Intel (or AMD) ecosystem right now.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Revoke of Gerrit privileges and asking to fork (was: Gerrit etiquette)

[David Hendricks via coreboot]

Hi Paul,

> [Your plain text email part of the mail is strangely indented.]

Thanks for pointing that out. I use my coreboot.org e-mail address sparingly 
and it seems there were some minor issues in how I was using the webmail 
client. Let's see if this message shows up better...

> 1. Who is the current coreboot leadership? How many of those voted, and
> what was the result?

It's currently Stefan, Werner, and myself. When things blew up in the patch you 
cited we started an e-mail thread to discuss what was to be done, and we agreed 
that rules/guidelines need to be enforced.

We tried to reach a consensus quickly, taking into account timezone 
differences, then discussed the issue in the leadership meeting on Jan. 29 and 
followed-up with an e-mail to the list (a poorly formatted one - sorry).

The project structure was put into place when coreboot joined the Software 
Freedom Conservancy, and is described in the following PDF (note: I stepped in 
when Marc Jones withdrew): 
https://www.coreboot.org/images/b/b4/Coreboot_and_the_Software_Freedom_Conservancy.pdf


> 2. Which comment violated the guidelines? I guess it’s about change-set
> [2]? Reading the comments, and considering, that English is not the
> mother tongue of some participants, and reading an apology, I’d really
> like to know what Gerrit guide lines were violated.
> 
> 3. Why did the coreboot leadership not step in earlier to avoid further
> escalation despite being added early on as reviewer so was made aware of
> the discussion?

Although the patch is what spurred action in this case, what happened was the 
result of tensions that had built up over several months. I think this is 
generally true of past incidents as well - Frustration builds and people 
eventually burn out or lose their temper.

coreboot is a highly active project and we have a large, global community. It 
is practically impossible for a small handful of people with day jobs to 
monitor every interaction and Gerrit comment.

That said, there is room for improvement in our guidelines and earlier 
intervention. We obviously don't like losing developers, so waiting for things 
to explode is not a viable path forward. I hope we can reach a better 
understanding of the underlying issues and develop guidelines to avoid the 
build-up of tensions we saw here. The "Workflows and Guidelines" thread is a 
good start.

> Hopefully, there will be an amicable outcome nevertheless.

For sure! If this were about some troll who just showed up then dealing with 
the problem and moving on would be easy. Dealing with the fallout in this case 
will take a lot more time and effort but I hope we can eventually be whole 
again.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[David Hendricks]

> Writing new code could considerably reduce its complexity
> and make things much easier. After a few years with FSP, I'm convinced
> that writing clean code would be cheaper than the FSP integration with
> all its avoidable complexity. Intel might not like it, but you could
> reach proper coreboot support much faster without FSP.

Assuming that's true from an engineering perspective and we're clear
to publish all code/info needed, we'd first need to invent a way to
send an electric shock thru the keyboard to users who complain to (or
about) Intel when something goes wrong with the code.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Do we have a rule that code should be build tested?

[David Hendricks]

> I'm not so sure what we argue about here. The hypothetical case that
> it's hard to hook things up for build testing early, right? I've haven't
> seen that yet.

Let's step back for a moment. The proposal as I understand is that all
code that lands in the tree must be hooked up so it's built by
Jenkins, correct?

That sounds good at first, but comes with a lot of ramifications. One
example, if I'm understanding your proposal, is that one can no longer
commit some initial SOC support followed up some time later by a
mainboard commit that uses it. Instead enough will need to be finished
in order to be buildable, but until then things linger on Gerrit.

Please correct me if I'm way off base with that example. The stubs
Patrick proposed in the other thread might help address the issue,
however it can also mean adding code which exists only to satisfy the
build requirement, churns as the real code changes, and may need to be
removed later on anyway.

> If you want to discuss trouble to get patches reviewed, please open
> another thread. This one is about build testing. To make it easier
> to work together on a big project while avoiding collisions.

You wanted some clarity on my "wild claims about consequences". The
recent drama shows us that when development on coreboot.org becomes a
PITA developers can just take their work elsewhere (or private). Which
development model works for a particular project (or sub-project
within coreboot) depends on a lot of variables and I don't think we
can expect many people to stick around if we make unfeasible demands
of their workflow.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[David Hendricks]

On Sun, Jan 26, 2020 at 12:38 PM Kevin Paul Herbert  wrote:
>
> I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very 
> disappointing to have to rely on binary blobs and I wish I could do better, 
> but I’d rather ship with coreboot than proprietary UEFI.
>
> I expected to upstream my code at some point but if FSP 1.0 support is being 
> deprecated I can live with the code as it is today.

It's still alive and well in 4.11_branch. Please feel free to send
patches if you've got 'em ready: `git push origin
HEAD:refs/for/4.11_branch`

The reason it was removed from master had to do with some
architectural changes that were impossible to reconcile with FSP 1.0.
More info is here https://review.coreboot.org/c/coreboot/+/37064

> I have 8-core systems working but there are bugs that keep us from shipping 
> the 12 and 16 core systems. I will probably be having a consultant with a FSP 
> source license help us when we want to ship those systems.

I happen to know one who has dealt with this issue. PM me if you'd
like to discuss further.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Do we have a rule that code should be build tested?

[David Hendricks]

> On 26.01.20 19:46, David Hendricks wrote:
> >>>> Of course, there'll always be a gap when a new platform is added. We
> >>>> could make it a rule, though, that no commit should be merged to the
> >>>> master branch, before the one that hooks the build test up is reviewed.
> >>>>
> >>> This means that such code isn't build tested for even longer, effectively
> >>> the whole development cycle until all the ducks are lined up.
> >>
> >> you mean it's less tested when it's sitting in the review queue, waiting
> >> for the hook-up? I don't see any difference in that aspect. As long as
> >> it's not hooked up for Jenkins, only the developers that work on the
> >> new platform will do build tests. And they can only spot conflicts when/
> >> after rebasing the patch train, no matter if parts of it are already
> >> merged. However, in case of conflicts, one could update patches that
> >> aren't merged yet. But for patches that are already merged, one would
> >> have to write fixups (more patches) and would have room to repeat the
> >> error (I feel like I've seen fixups for fixups before).
> >
> > For an individual developer this might make sense, but for large
> > projects I think that will make automation and coordination across
> > multiple companies unfeasible.
>
> We are still talking about adding new platform support to coreboot and
> build testing the code, right? I try to always keep the whole process
> in mind. And all I've said so far was to make it possible to work better
> together on such an endeavor even across multiple companies and the
> coreboot community. I have no idea how you got the impression that my
> view is too narrow.

I just don't think the model you propose is realistic. IMO the best
case is that it results in huge patch chains that churn a lot and are
frustrating to work with. And in the worst (and most likely) case it
will result in new silicon and platforms being developed out upstream
entirely.

>Is it like with
> the Underpants Gnomes?

Speaking of weird arguments...

> So what happens when somebody in one company rebases and has
> to fix a line somewhere; will they commit and push the patch imme-
> diately so everyone else working on the new platform can fetch it?
> I highly doubt that.

That's the current expectation - pull from master, rebase, and push
fixes when needed.

> However, if the queue stays on Gerrit, it would
> only cause build breakage when that queue is rebased and it would
> be much easier to share the resulting fixes.

I think this model will result in huge patch chains on gerrit, and in
my experience it's never easy to shuffle patches and fixes that way.

I simply disagree with you here, and based on the reaction of others
in the community it appears I'm not alone in thinking that your
proposed workflow is unfeasible.

>
> But what am I talking about. David, please share experience and
> explain your workflow and argue why build tests would break it.
>
> >
> > Then the community moans about not having a voice earlier in the
> > process and wonder why companies aren't doing development upstream. In
> > other words we go back to 2012 when Chromebooks started appearing
> > upstream (hundreds of patches at a time being pushed from an internal
> > repo to upstream) or 2020 when massive coreboot patches based on an
> > old commit get posted elsewhere (like
> > https://github.com/teslamotors/coreboot).
>
> Please explain your argumentation before making wild claims about
> consequences. This reads like propaganda.

Here's ya go:
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/6YV7EXNDJJNCQ45DLYA7EVPE2HDUGLOP/

To put it another way, coreboot needs upstream development under the
current model more than it needs your idealistic (and unrealistic)
development model. Not that things in the current model are perfect,
but I'd rather see the AMD code get merged in an imperfect state,
developed toward maturity, and eventually hooked into the build system
rather than have it developed out of tree.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[David Hendricks]

On Sat, Jan 25, 2020 at 4:44 PM Nico Huber  wrote:
>
> Hello coreboot fellows,
>
> 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.

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.

>
> 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.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Do we have a rule that code should be build tested?

[David Hendricks]

> >> Of course, there'll always be a gap when a new platform is added. We
> >> could make it a rule, though, that no commit should be merged to the
> >> master branch, before the one that hooks the build test up is reviewed.
> >>
> > This means that such code isn't build tested for even longer, effectively
> > the whole development cycle until all the ducks are lined up.
>
> you mean it's less tested when it's sitting in the review queue, waiting
> for the hook-up? I don't see any difference in that aspect. As long as
> it's not hooked up for Jenkins, only the developers that work on the
> new platform will do build tests. And they can only spot conflicts when/
> after rebasing the patch train, no matter if parts of it are already
> merged. However, in case of conflicts, one could update patches that
> aren't merged yet. But for patches that are already merged, one would
> have to write fixups (more patches) and would have room to repeat the
> error (I feel like I've seen fixups for fixups before).

For an individual developer this might make sense, but for large
projects I think that will make automation and coordination across
multiple companies unfeasible. The likely outcome is that large
projects are developed internally and eventually we see a huge code
drop after the product has been released (when the "ducks are lined
up" as Patrick says), and by then nobody involved with development
really cares about fixing up the code since their paycheck depends on
launching the next thing.

Then the community moans about not having a voice earlier in the
process and wonder why companies aren't doing development upstream. In
other words we go back to 2012 when Chromebooks started appearing
upstream (hundreds of patches at a time being pushed from an internal
repo to upstream) or 2020 when massive coreboot patches based on an
old commit get posted elsewhere (like
https://github.com/teslamotors/coreboot).

> > Maybe even in a designated area within src/mainboard? "Staging" perhaps?
>
> Probably overkill, how about simply having a warning instead of the
> board name in the Kconfig prompt?

Agreed, and moving code around also makes history more difficult to
follow so it's best to get the code structure in place early on if
possible.

>
> >
> > We have a number of conflicting goals (having usable code presented to
> > users, getting development into the main tree early to prevent code drops
> > after everything is said and done, incremental changes to ease review and
> > following what's going on) and that would provide a reasonable compromise:
> > the unfinished code is clearly identified as such but it's there for
> > (automated) testing and we can encourage incremental, incomplete changes
> > there.
> Ack.

+1. It's a difficult set of goals to balance, but we should certainly
strive to improve the process for everyone.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Comment on story about bootloader security?

[David Hendricks]

On Sun, Dec 8, 2019 at 12:00 AM Mike Banon  wrote:
>
> Yes, feel free to send more advanced questions to this list, would be
> an interesting discussion!

Looks like the article has already gone out:
https://the-parallax.com/2019/12/06/bootloader-security-pacsec/

In any case, if there are undisclosed vulnerabilities or any other
urgent security issue that requires an immediate fix then please
notify secur...@coreboot.org (also mentioned on the coreboot.org
homepage).

For general inquiries then this mailing list is fine.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)

[David Hendricks]

> I think most of this is changing and has changed already (like Patrick
> said it happened gradually) -- these days most chipset code for both
> x86 and Arm is in src/soc/vendor/common, and most new mainboards use
> the variant system. Whenever I see a patch of someone copy a
> lot of code I definitely ask them to find a way to factor it out and
> make it common instead. But if there is still uncertainty about what
> the general right approach for new code is, I think we should decide
> (and maybe write it down somewhere) that it should be code reuse and
> not copy

I think you hit on the key point here about writing down what you see
as a better development model. For mainboard ports, the documentation
that exists suggests finding a similar board, creating a new
directory, and copying files from it:
https://www.coreboot.org/Motherboard_Porting_Guide
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot and linuxboot

[David Hendricks]

Hi Jorge,

On Wed, Nov 6, 2019 at 5:09 AM Jorge Fernandez Monteagudo 
wrote:

> Hi all,
>
> I've built a coreboot with the LinuxBoot payload. The kernel is the stable
> 5.3.8 version and the intiramfs is the u-root master version.
> All with the default choices. I'm using coreboot 4.10.
>
> Once the system boots I get a framebuffer console without usb keyboard
> support and the u-root welcome message.
> How can I boot my debian system on a SATA or a USB disk? Maybe, first I've
> to add SATA and usb storage support?
> Is there someway to looks for the grub configuration automatically?
>

Yes, if you're using LinuxBoot then you need to include all the drivers you
wish to use in your LinuxBoot kernel, including SATA and USB.

`localboot -grub` will systematically mount partitions looking for a GRUB
config file, parse it, and kexec the kernel it finds. You can select a
particular entry using the `-config` command-line parameter.


> Sorry my noob questions, just arrived to LinuxBoot...
>

Welcome!
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

[David Hendricks]

Hi Naveen,
Yes, the first sentence. The DIMMs you are using appear to have geometry or
timings incompatible with Broadwell-DE, based on the SPD values that the
vendor programmed. Chapter 6 of the PDG (docid 543448) should help clarify
what kinds of DIMMs are supported and how they should be populated.

On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary <
naveenchaudhary2...@hotmail.com> wrote:

> Sorry I didn't get the point completely. Do you mean the settings are not
> compatible with FSP code? Or do you mean the settings might be conflicting
> themselves.
>
> Since the above settings were read from SPD and the chip vendor must have
> definitely set them correctly, I assume you meant first sentence.
>
> Please correct me.
>
> Regards,
> Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* Wim Vervoorn 
> *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> *To:* Naveen Chaudhary ; Nico Huber <
> nic...@gmx.de>; David Hendricks 
> *Cc:* coreboot@coreboot.org 
> *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
>
> Hello Naveen,
>
>
>
> This is the important part. This indicates the what you selected is not
> supported.
>
>
>
> Please review your settings carefully. This isn't a single check. The code
> validates the SPD settings against the other settings you made.
>
> So please make sure you are passing in a DDR4 SPD when you select DDR4
> mode. Also please make sure the SPD settings are in
>
> The list of supported configuration for the chip.
>
>
>
> Check POR Compatibility -- Started
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4:
> 4
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4:
> 4
>
> Unknown DIMM population *
>
> Check POR Compatibility - 17ms
>
> Initialize DDR Clocks -- Started
>
> Checkpoint Code: Socket 0, 0xB1, 0x00, 0x
>
> Configuration not in POR table!  *** (This basically indicates you are
> trying to do something that is not supported by the chipset).
>
>
>
> Best regards,
>
>
> Wim
>
>
>
> *From:* Naveen Chaudhary [mailto:naveenchaudhary2...@hotmail.com]
> *Sent:* Tuesday, October 29, 2019 10:44 AM
> *To:* Wim Vervoorn ; Nico Huber ;
> David Hendricks 
> *Cc:* coreboot@coreboot.org
> *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
>
>
> Thanks Wim.
>
> I will give a try and pass a 512 byte hex block corresponding to the SPD
> data and if it works, I can play with the hex values to find out the right
> configuration.
>
> BTW, any idea which field can impact the ddrfreq which was reported as
> error in the initial logs?
>
> Regards,
>
> Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> --
>
> *From:* Wim Vervoorn 
> *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> *To:* Nico Huber ; Naveen Chaudhary <
> naveenchaudhary2...@hotmail.com>; David Hendricks <
> david.hendri...@gmail.com>
> *Cc:* coreboot@coreboot.org 
> *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
>
>
> Hello Naveen,
>
> You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing
> the SPD data and set MemDownEnable" to 1.
>
> Best Regards,
> Wim Vervoorn
>
>
>
> -Original Message-
> From: Nico Huber [mailto:nic...@gmx.de ]
> Sent: Sunday, October 27, 2019 11:33 AM
> To: Naveen Chaudhary ; David Hendricks <
> david.hendri...@gmail.com>
> Cc: coreboot@coreboot.org
> Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hello Naveen,
>
> On 27.10.19 05:02, Naveen Chaudhary wrote:
> > Does this mean that there is a way in FSP to define custom
> settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (
> https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I
> don't see any relevant data member where we could define pointer to custom
> SPD settings or pass individual DIMMs configurations.
>
> there is the memory-down option. It seems undocumented if that does more
> than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
> If that doesn't work out, you can always overwrite the SPDs on your DIMM's
> EEPROMs. Always keep a backup, though.
>
> Hope that helps,
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an
> email to coreboot-le...@coreboot.org
>
>
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

[David Hendricks]

Hi Naveen,

What does "Configuration not in POR table mean? Does this mean that FSP can
> no longer initialize my DRAM automatically? If yes, what's the solution
> here? Or shall I try tweaking other settings such as MemEccSupport,
> MemDdrMemoryType, etc.
>

Intel validates several configurations of DRAM to go with their SoCs, and
AFAIK validated parts are considered "POR" (plan of record?). 'ddrfreq =
255' is a weird value for DRAM frequency, so I suspect that is really an
error code that indicates a problem with the frequency passed in via your
configuration or SPDs.

So you may need to adjust the value to match common DDR4 timings, such as
DDR4 2133 or DDR4 2400.

The following documents might help to figure out a valid configuration for
your SoC (you'll need to download them from Intel yourself, of course):
Document number 543448 - Grangeville Platform Design Guide
Document number 557970 - Xeon D-1500 Specification update
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to use crossgcc-i386 during make?

[David Hendricks]

Hi Naveen,
Do you have the ANY_TOOLCHAIN option enabled? It's under General setup -->
Allow building with any toolchain.

Make sure that option is not selected if you want to use coreboot's
crossgcc toolchain.

On Sat, Oct 19, 2019 at 12:08 PM Naveen Chaudhary <
naveenchaudhary2...@hotmail.com> wrote:

> As per the Wiki : https://www.coreboot.org/Build_HOWTO I did "make
> crossgcc-i386". Now when I do make, I get compilation errors because my
> host gcc verion is 4.3. In case I update the host gcc version is updated to
> some later version, says gcc-8 , the errors are gone.
>
> Looks like coreboot build system still uses the host gcc. How can I make
> with coreboot toolchain, instead of the host gcc toolchain.
>
> Regards,
> Naveen
> Build HOWTO - coreboot 
> This page describes how you can build a coreboot image for your specific
> mainboard.
> www.coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Web site revamp

[David Hendricks]

It would be nice if we can more prominently show libre-friendly systems
with coreboot. There have been some ideas proposed about how to do this,
for example this one by Carl-Daniel:
https://mail.coreboot.org/pipermail/coreboot/2010-October/060894.html

Now that our infrastructure is much better than it was nearly a decade ago,
maybe we can reconsider some ideas that would have previously involved a
lot of tedious manual labor. For example, perhaps a matrix of boards and
blob dependencies can be auto-generated using `make what-jenkins-does` (or
something similar) and looking at the resulting .config file for each
board. From there, boards with no blob dependencies (at least no
3rdparty/{blobs,fsp} dependencies) can be put on a list of "libre
platforms" linked from the homepage.

Just thinking out loud...
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Web site revamp

[David Hendricks]

> If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host
> of other proprietary components, they naturally take the statements above
> at face value and assume that installing coreboot on their machine (or
> paying for coreboot support for their system) allows them to replace the
> entire proprietary firmware with an auditable, fast, secure OpenSource
> firmware.
>

If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc.
then that is indeed a problem.


> One of the problems as I see it is that coreboot is really two different
> projects with two different goals right now, under the same label.  One is
> the native init project, which at the moment is only viable for RISC-V,
> POWER, and certain ARM SoCs.  The other is the open glue project for vendor
> binaries, which is not well understood at this time among much of the open
> source community, but seems to have significant support from vendors like
> Google, Intel, and AMD.
>

I don't see the latter as a project goal, it's just something that enables
coreboot to be used in non-libre platforms.


> Complicating matters, the trademark "coreboot" is currently known to some
> members of the public as a trusted (albeit limited in compatibility) fully
> open source replacement for their exiting board level firmware.  When the
> word "coreboot" is used, very few people think of the glue project.  Do we
> want to dilute / shift the coreboot trademark / branding to the glue part
> of the project, or do we want to somehow reserve "coreboot" for the native
> init part of the project?
>

Similar points have been made about Linux supporting binary modules. I'm
not convinced that conflating the project's openness with that of
third-party modules is helpful.

The heading could read something like "Flexible, open source frameworks for
> system firmware"
>
> and the detailed description could read "coreboot is an extensible
> firmware platform that aims to provide a minimal boot environment for
> modern computers and embedded systems.  As an Open Source project it
> provides a flexible framework for insertion of vendor specific firmware
> modules, and on open ISA platforms aims to provide a fully open, auditable
> boot process with maximum control over the technology."
>

Adding the word "framework" somewhere in there could be useful. I'm don't
think the rest needs to change, at least not much. The goal is always to
provide maximum openness, auditability, and control. The hard part is
conveying that one cannot achieve this goal 100% on many platforms
(especially in the x86 world).
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: MIPS architecture support is rotting away... should we consider dropping it?

[David Hendricks]

+1. Better to retire the code sooner than let it deteriorate into a less
and less useful state.

On Tue, Aug 13, 2019 at 7:53 AM Vadim Bendebury (вб) via coreboot <
coreboot@coreboot.org> wrote:

> I agree it could be dropped. If the need ever arises it could be
> resurrected and fixed.
>
> -vb
>
>
> On Mon, Aug 12, 2019 at 5:19 PM Julius Werner 
> wrote:
>
>> Hi,
>>
>> I've just been bitten by build problems with outdated MIPS code for
>> one of my CLs (not for the first time), and I've been wondering if
>> it's maybe time that we drop the architecture port completely. It was
>> added 5 years ago to support a Chrome OS project that never ended up
>> going anywhere and has been sitting in the tree unused and unsupported
>> ever since. The only SoC/board building it is that old abandoned
>> Chrome OS project for which there's probably not even any hardware
>> around anymore (or if there is, nobody wants to spend time with it).
>> There's no maintainer or even anybody who really reads MIPS assembly
>> or understands the architecture's intricacies paying attention to it,
>> and it keeps causing trouble when we try to pull it along with
>> overarching refactorings. I think at some point, if nobody wants to
>> use it and there's no future use case on the horizon, we should
>> consider pulling the plug.
>>
>> Some examples of stuff that causes problems:
>>
>> 1. There's no 64-bit division support (even soft-division) because we
>> have no code to implement the required libgcc function, and nobody
>> knows enough MIPS assembly to fix that. We need to keep several hacks
>> around in generic code (e.g. printf()) where code doesn't use 64-bit
>> division even though it probably should or has a special #if
>> CONFIG(ARCH_MIPS) case to deal with this.
>> 2. The read/write8/16/32() functions in libpayload take arguments in
>> (value, addr) order, whereas for all other architectures they have
>> long since been standardized to take (addr, value). This means you
>> can't submit any generic code that does direct MMIO without wrapping
>> it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers
>> left still using that old convention... I don't have time/interest
>> refactoring all of those and I don't think anybody else does either.
>>
>> We could either drop it right away, or (if we think that's too sudden)
>> schedule it for deletion after the next coreboot release (4.11 in
>> December(?)). What do people think?
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Related: General NERF Install Procedure?

[David Hendricks]

Hi Matt,
There actually has been quite a lot of progress made here, though
admittedly the state of documentation is somewhat confusing...

Here are some more resources to check out:
The LinuxBoot book has more up-to-date examples:
https://github.com/linuxboot/book/blob/master/7b.UEFI_Tool_Kit/README.md
Fiano is a set of tools for manipulating UEFI firmware:
https://github.com/linuxboot/fiano
Go Forth and Modify with Fiano (2019 OCP Summit):
https://www.youtube.com/watch?v=FrylZsqyi0c
Slack channel (join the linuxboot channel): http://slack.u-root.com/
Mailing list: https://groups.google.com/forum/#!forum/linuxboot

The naming has also gotten a bit confusing over the years. As I understand
it, NERF is more of a general concept of reduced UEFI. Fiano is a toolset
and LinuxBoot just implies replacing BDS and portions of DXE with Linux and
an initramfs to load and execute the target OS kernel.

HTH!

On Wed, Jul 10, 2019 at 7:36 PM Matt B  wrote:

> Hello,
>
> A couple of years ago I saw Ron's talk on NERF. An acquaintance who
> maintains a fleet of machines expressed some interest in NERF. He wants to
> boot linux instead of windows, which isn't supported by his (extremely
> recent) build of UEFI. (no legacy support whatsoever)
>
> The closest thing I could find to instructions for using it or otherwise
> replicating what's been done is the explanation for the Dell R630 here: [1]
> Many sections are still TODO and it overall seems fairly half-baked (with
> things like USB and networking not working).
>
> I surmise the basic steps are:
> -Dump the BIOS flash
> -Extract key boot blobs from flash
> -Configure and build NERF
> -Flash resulting image
>
> Has any progress been made (public) since 2017? Does a generalized install
> process exist (like that provided by me_cleaner, for example) or is this
> something that requires a large amount of rework for each platform?
>
> I imagine it is totally impossible to produce anything that would be
> accepted by stock UEFI as an update for internal flashing.
>
> Sincerely,
> -Matthew Bradley
>
> [1] https://trmm.net/NERF
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Does NSA contribute to Coreboot?

[David Hendricks]

On Sat, Jun 22, 2019 at 7:06 AM Anac  wrote:

> Any thoughts?


Seems fine to me. I'm a lot more concerned about contributions by state
actors to firmware that's NOT open.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Building ChromeOS from source

[David Hendricks]

On Sun, Jun 16, 2019 at 7:18 PM Gregg Levine  wrote:
>
> Hello!
> Thank you Matt. That does indeed confirm it is doable.

Bear in mind that you can build ChromiumOS, not ChromeOS, from source:
https://www.chromium.org/chromium-os/chromium-os-faq#TOC-What-s-the-difference-between-Chromium-OS-and-Google-Chrome-OS-

> But a
> referenced thread on the page also tells me that doing so locally
> might not be a good idea. It seems a builder needed to update his
> cloud system to practically very big sizes on memory just to build the
> image he had in mind.

It's generally assumed that the device running ChromeOS/ChromiumOS is
not very powerful, e.g. a low/mid-range laptop, and building a modern
OS and web browser from source is a pretty huge task even for powerful
desktop and workstation systems. The large memory recommendation is
just for the linking step when building the Chromium web browser. You
can do it on a machine with less RAM, it will just be very slow.

> At the moment I have not decided which way I'm going to go for this.
> Now that I know it can be done, I'll continue to think about it.

ChromiumOS is based on Gentoo which might be better suited for your
use case. ChromeOS/ChromiumOS is really slick for the use model it's
intended for, namely building and deploying a simple and secure Linux
distro to web-centric (and now Android-centric) devices.

> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
> On Sat, Jun 15, 2019 at 10:36 PM Matt DeVillier
>  wrote:
> >
> > https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md
> >
> > On Sat, Jun 15, 2019 at 4:54 PM Gregg Levine  wrote:
> >>
> >> Hello!
> >> An interesting thought came to me yesterday. And is still ringing a
> >> loud sound today.
> >>
> >> Is it possible to obtain and build ChromeOS from source?
> >>
> >> I freely admit that just once (or twice) I did look at building all of
> >> Linux from source, that was back during the same period that the list
> >> concerned itself with the LinuxBIOS project. By the time I'd finished
> >> studying what was involved, I found it was easier to customize the
> >> distribution I do use then to build the actual OS from source. And
> >> that was after being made aware of the amazing Linux From Scratch
> >> project series.
> >>
> >> If this is the wrong place to ask this Ron, Stefan, then please advise.
> >> -
> >> Gregg C Levine gregg.drw...@gmail.com
> >> "This signature fought the Time Wars, time and again."
> >> ___
> >> coreboot mailing list -- coreboot@coreboot.org
> >> To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Syntax highlighting screwed up (orange function parameters)?

[David Hendricks]

Has anything changed with the syntax highlighting on Gerrit recently?
I'm seeing many function parameters in orange (which is hard to read
on a green background), and signs that it misparsed the code somehow
(e.g. coloring opening braces different than closing ones). Example
attached.

Yeah, something seems broken with how it's parsing, and orange is not a great 
color to use on a green background anyway.

Here is an example where a function's return type is highlighted in orange 
rather than the usual purple: 
https://review.coreboot.org/c/coreboot/+/30414/22/src/mainboard/facebook/fbg1701/gpio.c#250

Here is an example where a variable is highlighted in orange while its type is 
purple (and the function return type is also purple, unlike in the previous 
example):
https://review.coreboot.org/c/coreboot/+/30414/22/src/mainboard/facebook/fbg1701/acpi_tables.c

Wanna file a bug at https://bugs.chromium.org/p/gerrit/issues/list ?

From: Julius Werner 
Sent: Monday, April 22, 2019 5:06:03 PM
To: Coreboot; Patrick Georgi
Subject: [coreboot] Syntax highlighting screwed up (orange function parameters)?

Has anything changed with the syntax highlighting on Gerrit recently?
I'm seeing many function parameters in orange (which is hard to read
on a green background), and signs that it misparsed the code somehow
(e.g. coloring opening braces different than closing ones). Example
attached.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question regarding 7th generation Intel CPUs

[David Hendricks]

On Wed, Apr 3, 2019 at 8:55 AM Coins  wrote:

> Currently I am using old hardware but I do miss having the latest
> performance capabilities at disposal.
> Any thoughts on this?
>

We see this a lot - People want performance of modern CPUs but don't trust
the platform. That's totally understandable but is sadly unavoidable in the
x86 world. Even though coreboot easily provides the most transparency
you'll get in x86 host firmware these days, it's still just one component
that you need to worry about. ME cleaner is great but has obvious
limitations to what it can remove.

If you're really serious then you need to divorce x86 and try an
alternative architecture such as POWER9. Raptor (https://www.raptorcs.com/)
sells reasonably affordable systems with Xeon-class performance, PCIe Gen
4.0, and 100% open source firmware for both host and BMC. Freedom isn't
free, though, and if that's too expensive you might find a cheap used
POWER8 system (not as open as POWER9, but still good compared to x86
systems in terms of openness):
https://www.phoronix.com/scan.php?page=article=tyan-power8-server=1
.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [x86] Support for SIS 651 (Northbridge) + SIS 962 (Southbridge) ?

[David Hendricks]

On Fri, Feb 15, 2019 at 10:19 AM Frederic Dumas 
wrote:

>
>
> Thank you, your answer makes the case to be simply closed.
>

Don't give up that quickly :-) It's an old chipset and I you may just need
to checkout coreboot-v1 (aka LinuxBIOS). SiS 635/735/950 were some of the
first chipsets with coreboot support, thanks to a SiS engineer named Li-Ta
"Ollie" Lo who eventually came to work for Ron at LANL.

Here's a good starting point:
https://review.coreboot.org/cgit/coreboot.git/log/?h=coreboot-v1=author=ollie%40lanl.gov
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Maintainer for FSP broadwell DE

[David Hendricks]

Hi Jay,

On Mon, Dec 17, 2018 at 3:05 PM Jay Talbott 
wrote:

> York Yang is no longer with Intel.
>
> We have a Camelback Mountain CRB with a D-1539 (8-core) Broadwell-DE SoC.
>
> We're not signing up to be maintainers of the platform, but we're willing
> to give it a go to test it for 4.9...
>
> What's the process once we have a log of it booting successfully?
>

The best way is to use the board_status.sh script located in
coreboot/util/board_status to collect and upload results to the
board-status repository (https://review.coreboot.org/cgit/board-status.git).

More info about how to use it is can be found on the wiki (soon be migrated
to coreboot/Documentation): https://www.coreboot.org/Board_Status

Thanks for doing this!
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboots Board Status have privacy issues for contributors

[David Hendricks]

On Sun, Nov 25, 2018 at 9:25 AM  wrote:

> I was thinking of contributing to the Board Status but i dont want to
> release any private data and wont contribute now. What is the usage of
> the world to know what mac address the people are using?
>

Thanks for pointing out these issues.

For what it's worth, the user must use the '-u' option to upload results.
And as Arthur points out you can edit logs and such yourself to scrub any
private data. The script just automates a few steps for convenience, though
obviously we'd like a reasonably uniform data set to compare with. You're
right that we don't need to know anyone's MAC address for coreboot
development; however as others have pointed out a full kernel log is useful
since firmware issues often manifest themselves there (memory map
incorrect, devices not enabled, etc) so it's good to have them for
comparison.

Still, a pause as Mike suggested and perhaps a scary warning or two could
be useful.

Then there can be for example a simple live linux iso that people can boot
> with LAN cable connected. No requirement of installation software, of
> setting things up or anything like that.


There is one - See util/board_status/set_up_live_image.sh .
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today

[David Hendricks]

On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot <
linuxb...@googlegroups.com> wrote:

> I"m leaning to yes, by which I mean if you do it, I'll show up.
>
> I can't believe I said that.
> On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
>  wrote:
> >
> > Hi!
> >
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
>

Same as what Ron said. I think someone from FB can be there to talk about
coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] current state of board/f2a85m

[David Hendricks]

There was a status report uploaded about a year ago (
https://coreboot.org/status/board-status.html).

Can you verify that the coreboot tree at that commit can boot your system?
>From there it will be much easier to find out where things broke.

On Sat, Oct 6, 2018 at 5:24 AM kinky_nekoboi 
wrote:

> I was not able to build any usable rom from the current master branch of
> coreboot
>
> for f2a85m.
>
> Compliation runs smooth but the resulting system does not pass POST(i
> dont know how to call it in coreboot terms, the system just powers up
> and dont loads the SeaBIOS payload) .. no useful debug information
> getable from der TTYS0 as there is no output.
>
> anyway to contact the current maintainer of this board?
>
> my setup:
>
> ASUS F2A85M with A8-6600K
>
> and 8GB DDR3 Ram.
>
> and early version of coreboot was fine expect the fact it was not able
> to initialize my Radeon HD7850.
>
> grettings
>
> the kinky nekoboi
>
>
>
> --
> 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] Is this fake news or not? Bloomberg says China is using a rice-sized chip to hack amazon servers.

[David Hendricks]

On Thu, Oct 4, 2018 at 9:22 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> But generally speaking: that discussion is rather off topic for this
> mailing list.
> Please look for some more suitable venue to discuss "people potentially
> tampering other people's devices (with no obvious connection to coreboot)".
>

Patrick is right that the Bloomberg article is not particularly well-suited
for the coreboot mailing list.

However, it's still worth pointing out that supply chain attacks are a
serious threat. This could be in the form of added hardware (like the
Bloomberg article suggests) or it could be in the form of firmware that
contains malicious code from any of the many parties involved in creating
it.

Traditionally, firmware contains modules from the silicon vendor, a
software vendor (IBV/ISV) who packages it with their SDK and value-add
software, and ODMs/OEMs who make further product-specific additions. Modern
firmware can easily contain over a million lines (or multiple millions of
lines) of code from several parties, and this code runs at the highest
privilege level before any OS-based security mechanism comes into play.
Anyone in that part of the supply chain can slip in malicious code, and the
customer usually doesn't have any way of viewing the code or tracing where
it came from due to its closed nature.

That is relevant to coreboot insofar as coreboot has been leading the
charge (with varying levels of success) for open and auditable firmware on
x86 platforms for nearly two decades.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SAR in Coreboot

[David Hendricks]

Hi Gallo,
coreboot does not do anything with SAR, as far as I know. There may be some
data (e.g. regulatory domain setting) that you need to provide to the
modem, though. You should check the driver and documentation for the modem
to get more details.

On Thu, Sep 20, 2018 at 1:21 AM galla rao  wrote:

> Hi All,
>
> This is my first email to coreboot open source team
>
> Does coreboot 4.8/4.9 support
> *Specific absorption rate* (*SAR*)
>
> How does Linux or Kernel driver uses the SAR Tx Power limits, Anyone
> working on this task, Kindly respond
>
> regards
> Galla
> --
> 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] Coreboot for Apollolake

[David Hendricks]

Hi Antony,
There are a few components which compose a complete firmware image for
Intel platforms: coreboot, FSP, microcode, management engine blob, and
flash descriptor are the most common ones.

For the flash descriptor, refer to the Apollo Lake SoC SPI and signed
Master Image Profile (SMIP) Programming Guide, docid 559702. Chapter 4
explains the flash descriptor for Apollo Lake in detail.

Once you have created a flash descriptor, you can add it to the firmware
image using coreboot's config system (under "Chipset").

On Tue, Sep 18, 2018 at 1:43 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrote:

> Hi,
>
>
>
> We would like to build coreboot image for Apollo lake platform. We are
> using
>
>- Coreboot-4.8.1
>- Apollo lake Intel FSP_2_0
>
>
>
> We have built the coreboot source and created coreboot.rom image with the
> below warning message:
>
> *** WARNING ***
>
> *coreboot will be built without an Intel Firmware Descriptor.*
>
> *Never write a complete coreboot.rom without an IFD to your*
>
> *board's flash chip! You can use flashrom's IFD or layout*
>
> *parameters to flash only to the BIOS region.*
>
>
>
> Is the coreboot.rom image is enough to flash ? Could you please provide
> feedback on this ?
>
>
>
> Thanks & Regards,
>
> Antony
>
>
>
> *L Technology Services Ltd*
>
> www.LntTechservices.com 
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> --
> 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] USB to Serial Converters

[David Hendricks]

Hi Zahra,
Yes, I used the 6-pin serial port header. Also, make sure the microcode
header(s) you include correspond to the CPUID of your processor. The E3825
and E3826 use different microcode headers, so M0130679901.h will not work
for you.

Please keep the coreboot mailing list CC'd. I haven't done anything with
Minnowboard in several months and others may be able to help.

On Thu, Aug 2, 2018 at 5:01 PM, zahra rahimkhani 
wrote:

> Hi David
>
> Thank you for your help.
> I extract your file and got M0130679901.h as Microcode but my board does
> not work it did not show anything.
> I use E3825.
> In previous notes, you told "My guess is that you don't have
> CONFIG_ENABLE_BUILTIN_COM1 selected
> (under "Chipset"), which is an option you have to set in addition to
> the stuff under "Console."
> but in your config, you had not enabled this option.
> Could you help me with this and Did you use   6 pins that are separated on
> board for console port?
> I do not know what is my problem .it did not show anything log.
>
>
>
> Thank you for your time.
> Zahra
>
>
>
> On Wed, Aug 1, 2018 at 2:04 AM David Hendricks 
> wrote:
>
>> Hi Zahra,
>> That header may be out of date
>> (https://mail.coreboot.org/pipermail/coreboot/2017-August/084800.html).
>>
>> I had to manually download the microcode file corresponding to my
>> processor SKU from Intel. Use the link I sent you earlier to download
>> Baytrail_FSP_Gold4.tgz and see if the microcode headers included in
>> that tarball match your processor. The Atom on my Minnowboard Turbot
>> has a CPUID of 30679, so I needed to use M0130679901.h.
>>
>> (note that the Minnowboard Max uses an Atom E3825, while the Turbot
>> uses an E3826 dual-core SoC or E3845 quad-core SoC)
>>
>> On Mon, Jul 30, 2018 at 2:36 AM, zahra rahimkhani
>>  wrote:
>> >
>> > Dear David
>> >
>> > for Microcode file I just it from coreboot source from this path
>> > coreboot/3rdparty/blobs/soc/intel/baytrail/microcode_blob.h
>> >
>> > Is that good ?
>> >
>> > Thanks ,
>> >
>> >
>> > On Sun, Jul 29, 2018 at 1:18 PM zahra rahimkhani <
>> zrahimkhani2...@gmail.com>
>> > wrote:
>> >>
>> >> Hi David,
>> >>
>> >> Thank you very much for your guide.
>> >>
>> >> I got this comments on my config and changes it based on your config.
>> >> But I can not see any thing on output.
>> >> Could you tell me  which Uart pins do you use on Minnowboard max
>> >>
>> >> I used it 6 pin that are separately on board .
>> >>
>> >> I would be grateful if you guide me .
>> >> I got my new config here .
>> >> https://paste.flashrom.org/view.php?id=3097
>> >>
>> >> Also , Could you tell me what is this parameter
>> >> CONFIG_UART_FOR_CONSOLE=0
>> >> and
>> >> CONFIG_DRIVERS_UART_8250IO
>> >>
>> >> Cheers!
>> >> Zahra
>> >>
>> >>
>> >>
>> >> On Fri, Jul 27, 2018 at 11:06 AM David Hendricks
>> >>  wrote:
>> >>>
>> >>> Hi Zahra,
>> >>>
>> >>>> I got my config file here
>> >>>> https://paste.flashrom.org/view.php?id=3096
>> >>>
>> >>>
>> >>> Thanks, that helps a lot!
>> >>>
>> >>> The last config that I tested is
>> >>> https://review.coreboot.org/cgit/board-status.git/plain/
>> intel/minnowmax/4.6-1358-g49d117c69f/2017-09-06T06_53_39Z/config.txt
>> >>>
>> >>> If you diff my config and yours, it seems you have several options
>> >>> disabled which I think you should try enabling:
>> >>> CONFIG_HAVE_IFD_BIN
>> >>> CONFIG_HAVE_ME_BIN
>> >>> CONFIG_TTYS0_LCS
>> >>> CONFIG_DRIVERS_UART_8250IO
>> >>> CONFIG_IFD_BIN_PATH
>> >>> CONFIG_ME_BIN_PATH
>> >>> CONFIG_LOCK_MANAGEMENT_ENGINE
>> >>> CONFIG_DRIVERS_UART
>> >>> CONFIG_CONSOLE_SERIAL
>> >>> CONFIG_CONSOLE_SERIAL_115200
>> >>>
>> >>> You can find these by using the search function in `make menuconfig`.
>> >>> Press '/' and type a Kconfig option.
>> >>>
>> >>>> I would be grateful if you check my config and tell me what is
>> ifdtool
>> >>>> in Coreboot and how
>> >>>> I  use it.
>> >>>> and How I find  Intel ME file for my board and GBE for a network on
>> my
>> >>>> board.
>> >>>
>> >>>
>> >>> ifdtool is a tool for viewing and manipulating an Intel Flash
>> Descriptor
>> >>> binary. The flash descriptor is a 4KB data structure at the start of
>> the
>> >>> ROM's address space (offset 0x00-0x000fff).
>> >>>
>> >>> To build it: `make -C util/ifdtool`
>> >>> To run it: `util/ifdtool/ifdtool`
>> >>>
>> >>> You'll probably want to use the '-x' option to extract the individual
>> >>> modules from an existing Minnowboard Max firmware image (e.g. the
>> UEFI image
>> >>> that comes with the board). That will give you the ME and GBE files.
>> >>>
>> >
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB to Serial Converters

[David Hendricks]

[re-adding the list while we're at it]

On Tue, Jul 31, 2018 at 2:34 PM, David Hendricks
 wrote:
> Hi Zahra,
> That header may be out of date
> (https://mail.coreboot.org/pipermail/coreboot/2017-August/084800.html).
>
> I had to manually download the microcode file corresponding to my
> processor SKU from Intel. Use the link I sent you earlier to download
> Baytrail_FSP_Gold4.tgz and see if the microcode headers included in
> that tarball match your processor. The Atom on my Minnowboard Turbot
> has a CPUID of 30679, so I needed to use M0130679901.h.
>
> (note that the Minnowboard Max uses an Atom E3825, while the Turbot
> uses an E3826 dual-core SoC or E3845 quad-core SoC)
>
> On Mon, Jul 30, 2018 at 2:36 AM, zahra rahimkhani
>  wrote:
>>
>> Dear David
>>
>> for Microcode file I just it from coreboot source from this path
>> coreboot/3rdparty/blobs/soc/intel/baytrail/microcode_blob.h
>>
>> Is that good ?
>>
>> Thanks ,
>>
>>
>> On Sun, Jul 29, 2018 at 1:18 PM zahra rahimkhani 
>> wrote:
>>>
>>> Hi David,
>>>
>>> Thank you very much for your guide.
>>>
>>> I got this comments on my config and changes it based on your config.
>>> But I can not see any thing on output.
>>> Could you tell me  which Uart pins do you use on Minnowboard max
>>>
>>> I used it 6 pin that are separately on board .
>>>
>>> I would be grateful if you guide me .
>>> I got my new config here .
>>> https://paste.flashrom.org/view.php?id=3097
>>>
>>> Also , Could you tell me what is this parameter
>>> CONFIG_UART_FOR_CONSOLE=0
>>> and
>>> CONFIG_DRIVERS_UART_8250IO
>>>
>>> Cheers!
>>> Zahra
>>>
>>>
>>>
>>> On Fri, Jul 27, 2018 at 11:06 AM David Hendricks
>>>  wrote:
>>>>
>>>> Hi Zahra,
>>>>
>>>>> I got my config file here
>>>>> https://paste.flashrom.org/view.php?id=3096
>>>>
>>>>
>>>> Thanks, that helps a lot!
>>>>
>>>> The last config that I tested is
>>>> https://review.coreboot.org/cgit/board-status.git/plain/intel/minnowmax/4.6-1358-g49d117c69f/2017-09-06T06_53_39Z/config.txt
>>>>
>>>> If you diff my config and yours, it seems you have several options
>>>> disabled which I think you should try enabling:
>>>> CONFIG_HAVE_IFD_BIN
>>>> CONFIG_HAVE_ME_BIN
>>>> CONFIG_TTYS0_LCS
>>>> CONFIG_DRIVERS_UART_8250IO
>>>> CONFIG_IFD_BIN_PATH
>>>> CONFIG_ME_BIN_PATH
>>>> CONFIG_LOCK_MANAGEMENT_ENGINE
>>>> CONFIG_DRIVERS_UART
>>>> CONFIG_CONSOLE_SERIAL
>>>> CONFIG_CONSOLE_SERIAL_115200
>>>>
>>>> You can find these by using the search function in `make menuconfig`.
>>>> Press '/' and type a Kconfig option.
>>>>
>>>>> I would be grateful if you check my config and tell me what is ifdtool
>>>>> in Coreboot and how
>>>>> I  use it.
>>>>> and How I find  Intel ME file for my board and GBE for a network on my
>>>>> board.
>>>>
>>>>
>>>> ifdtool is a tool for viewing and manipulating an Intel Flash Descriptor
>>>> binary. The flash descriptor is a 4KB data structure at the start of the
>>>> ROM's address space (offset 0x00-0x000fff).
>>>>
>>>> To build it: `make -C util/ifdtool`
>>>> To run it: `util/ifdtool/ifdtool`
>>>>
>>>> You'll probably want to use the '-x' option to extract the individual
>>>> modules from an existing Minnowboard Max firmware image (e.g. the UEFI 
>>>> image
>>>> that comes with the board). That will give you the ME and GBE files.
>>>>
>>

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

Re: [coreboot] fsp_broadwell_de: USB keyboard and mouse doesn't work.

[David Hendricks]

Hello Jose,

On Mon, Jul 23, 2018 at 5:23 AM, Jose Trujillo via coreboot
 wrote:
> Dear coreboot developers:
>
> I am trying to create CB firmware for Broadwell-D 1559 system using
> CamelBack Mountain CRB as mainboard selection, and the system boots Windows
> and Linux operating systems but USB keyboard and mouse doesn't work.
>
> I already enable/disabled EHCI/xHCI devices in devicetree without success.
> I tried Seabios and Tianocore without success.
>
> Anyone had experience this issue?

EHCI support may need to be enabled in FSP. What version of coreboot
are you using? I added a Kconfig option to enable the EHCI controllers
using UPD values: https://review.coreboot.org/c/coreboot/+/26042

> Any advise will be appreciated.
> Thank you,
> Jose Trujillo.
>
> --
> 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] USB to Serial Converters

[David Hendricks]

On Sun, Jul 22, 2018 at 11:50 PM, zahra rahimkhani
 wrote:
> Thank you very much.
> I compiled  coreboot  and seabios and got Microcode  and Fsp on it.
> But I did not have output on serial port.
> Could you tell me How set menuconfig that see outpot on serial port.
> Thanks,

It would be helpful if you can upload your .config somewhere such as
paste.flashrom.org.

My guess is that you don't have CONFIG_ENABLE_BUILTIN_COM1 selected
(under "Chipset"), which is an option you have to set in addition to
the stuff under "Console."

>
> On Mon, Jul 23, 2018 at 10:58 AM David Hendricks 
> wrote:
>>
>> Hi Zahra,
>>
>> On Mon, Jul 23, 2018 at 4:49 AM, zahra rahimkhani
>>  wrote:
>> > Dear friends
>> >
>> > I compile seaBios and coreboot for Minnowboard max .
>> > but I do not see output on Serial port .
>> >
>> > Does  coreboot support USB to Serial Converters ?
>> > or how do  I add this feature ?
>>
>> The Minnowboard Max serial port does not go thru a USB to serial
>> converter. However, you may need to enable some config options.
>> Compare a sample config.txt from the supported mainboards page
>> (https://coreboot.org/status/board-status.html) to your .config file
>> to see if there is anything obviously missing.
>>
>> Also, do you have the microcode files from Intel? If not, you can
>> download them from
>> https://downloadmirror.intel.com/25063/eng/Baytrail_FSP_Gold4.tgz.
>>
>>
>> >
>> > Thanks ,
>> >
>> >
>> > --
>> > 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] USB to Serial Converters

[David Hendricks]

Hi Zahra,

On Mon, Jul 23, 2018 at 4:49 AM, zahra rahimkhani
 wrote:
> Dear friends
>
> I compile seaBios and coreboot for Minnowboard max .
> but I do not see output on Serial port .
>
> Does  coreboot support USB to Serial Converters ?
> or how do  I add this feature ?

The Minnowboard Max serial port does not go thru a USB to serial
converter. However, you may need to enable some config options.
Compare a sample config.txt from the supported mainboards page
(https://coreboot.org/status/board-status.html) to your .config file
to see if there is anything obviously missing.

Also, do you have the microcode files from Intel? If not, you can
download them from
https://downloadmirror.intel.com/25063/eng/Baytrail_FSP_Gold4.tgz.


>
> Thanks ,
>
>
> --
> 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] Sun Ultra 40 M2 Board - Obscured coreboot status

[David Hendricks]

Hi Bostjan,


On Thu, Jul 19, 2018 at 12:47 PM, Bostjan Kravcar via coreboot
 wrote:
> Thanks Peter,
>
>
>
> It doesn't sound half as bad I feared it would, honestly. The way I see it,
> this is what I can and should do:
>
>
>
> - Acquire the Ultra 40 M2 machine (just bite the bullet, as there's no other
> way around…), to be able to run the tests in a first place;
>
> - Buy a couple of blank BIOS chips for that particular board, to use them
> for flashing various versions of coreboot BIOS images; if anything goes
> terribly wrong (workstation misbehaves, with any given coreboot image
> flashed), I can still use the computer with proprietary BIOS.
>
> - Try with the last stable release, where my board is listed as supported
> (4.8?), then stick to it if all works well;
>
> - Post the test results for functionalities (hmm, where … through mailing
> list ?), that were marked as »Untested«/ »Not working«/ »WIP«,  as listed in
> the last update of the table, with a status summary of the board
> functionalities, or … ?

You've got the right idea :-)

For testing we use a script (board_status) that you can run on your
test machine after successfully booting:
https://www.coreboot.org/Board_Status.

The script will obtain some basic information (configs and logs) and
upload it to a git repository. That info will be made publicly
viewable at https://coreboot.org/status/board-status.html. As Peter
mentioned, this is how we know that a board will work with a
particular version of coreboot. Boards that do not get tested are
eventually removed from the head of the master branch, though they are
still available in the history and release branches.

This gives users a better idea of what boards are known to work in a
given release, and helps developers to maintain and make progress on
boards that are actively being tested and developed.


>
> As you can see, I'm fumbling around and stumbling quite a bit,  being
> overwhelmed by the maze of available information on one hand, and the lack
> of encouraging up-to-date hints and proofs for the future on the other hand.
> I suppose this is where the proverbial line »welcome to the moment« comes
> into play.

Welcome!

Please feel free to point out where things get confusing - It's really
appreciated. Sometimes it's easy to overlook problems that newcomers
face.

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

Re: [coreboot] vboot

[David Hendricks]

On Fri, Jul 6, 2018 at 8:21 AM, Akendo  wrote:
> Awesome Thanks!
>
> Can you tell me what the state is with vboot for a x220 is (as an example)?
>
> I did ask in the IRC and someone told me, that there is some work done
> on this topic. Also that no code contribution are necessary, but rather
> review (and testing I guess).
>
> From what I have seen in the code only google based laptop are supported
> for vboot. More might be possible, but I wasn't able to quickly identify
> them all.
>
> From what I have seen on the review pages, most changes there for vboot
> should not affect the x220, or do I get it wrong?

Although vboot is agnostic to CPU/SoC, it has a few system
requirements. Off the top of my head:
- There must be a read-only copy of the firmware stored on the boot
ROM. This requires a write-protection mechanism (present in SPI flash
parts) and enough capacity to store both read-only and rewriteable
copies.
- There are some variables (inputs) which vboot needs to read at
runtime, such as write-protect enabled/disabled and which mode
(normal/dev) you're in. These can come reading GPIOs, from querying an
EC, etc.

I don't know off-hand if anybody has put serious effort into using
vboot on the x220 or similar laptops. Chromebooks are designed with
the necessary capabilities in mind, so you may need to get creative to
find substitutes on hardware that was not designed with vboot in mind.
It would be a really neat project to try if you have time :-)

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

Re: [coreboot] vboot

[David Hendricks]

On Fri, Jun 29, 2018 at 8:34 AM, Akendo  wrote:
>
> Hey everyone,
>
> I'm reading through the source code and found vboot. It should standing
> for verified boot. However I can't find any documentation(except the
> source code). Can anyone provide me with some explanation how to get it
> going or to make a little more sense of it?
>
> As far as I understand it needs to verify the signature against a
> Key/CA. This key should be located within the TPM. But how should the
> key/CA look like? Will be a classic x509 be enough?


Hi Akendo,
Here is some more background on vboot:
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery

In this schema usually the public key is stored in a write-protected
region of the firmware ROM. You can store it anywhere you want so long
as you can guarantee that it can't be tampered with in an undesirable
way.

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

Re: [coreboot] Equus "WHITEBOX OPEN" servers ship with Coreboot/LinuxBoot

[David Hendricks]

I'm calling shenanigans on this. Their server datasheets pretty clearly
specify an IBV-provided firmware solution, definitely NOT coreboot or
LinuxBoot and definitely NOT open. I did hear thru the grapevine that
they've been in contact with at least one OpenBMC developer, at least.

So basically this is a lot of misleading marketing BS AFAICT (though I'd
like to be proven wrong).

On Thu, Jun 21, 2018 at 4:56 AM, Alberto Bursi 
wrote:

> There was an announcement [1] about a new line of servers called
> WHITEBOX OPEN (yes, all caps)
>
> which appears to be about servers with Coreboot or Linuxboot and OpenBMC.
>
> Has anyone any experience with this company?
>
>
> -Alberto
>
> 1. https://www.prweb.com/releases/2018/06/prweb15571110.htm
>
> --
> 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] flashrom on osx ...

[David Hendricks]

Jean-Marie Verdun sent a patch which I've uploaded here:
https://review.coreboot.org/c/directhw/+/26655

I couldn't get the .dmg to install on High Sierra, though. Perhaps someone
with experience developing on Mac can take a look.

On Fri, May 11, 2018 at 11:45 AM, ron minnich  wrote:

> not late enough, sadly, and why the heck won't this build from github repo
> ... uses packagemanager which is no longer a thing.
>
> On Fri, May 11, 2018 at 11:07 AM Alberto Bursi 
> wrote:
>
>>
>> On 11/05/2018 19:42, ron minnich wrote:
>> > if I just want to use a dediprog sf100 what's the best way to build
>> > flashrom on osx?
>> >
>> > besides "throw the macbook in the trash and get a real computer" :-)
>> >
>> > ron
>> >
>> >
>>
>> There is "homebrew" package manager for OSX/MacOS, see here
>> https://brew.sh/
>>
>> They have latest flashrom https://formulae.brew.sh/formula/flashrom
>> among  a big list of other commandline stuff you might find useful.
>>
>> -Alberto
>>
>> --
>> 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
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [flashrom] MX66l51235f

[David Hendricks]

On Mon, May 14, 2018 at 9:48 AM, Nico Huber  wrote:

> Hi Ron,
>
> On 14.05.2018 18:01, ron minnich wrote:
> > anyone got the incantation to flash this with an sf100 ;-)
>
> TLDR; If it doesn't work with current master, you can try [1].
>
> 512M, huh? what's that for, UbuntuBoot? xD
>
> You need 4-byte addresses to access the full chip and that's rather
> delicate with Dediprog (because we don't control the SPI commands
> directly for read and write). The chip supports an extended address
> register for the most significant byte, though it's unclear to me
> if this register's state is maintained between Dediprog commands.
> So it might just work with flashrom master, or might wreak havoc ;)
>
> [1] https://review.coreboot.org/19858/


Indeed, in my experience the extended address enable got reset between
commands, so the follow-up patch forced that chip to use native 4BA access
mode. The patches were also based on the old 4BA access methods, so they
will need to be updated to work with the new way. At the very least I think
this means adding SPI_MASTER_4BA in spi_master_dediprog, but there's likely
some other stuff I'm overlooking.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Why do we have FSP-S

[David Hendricks]

Hi Kyösti,
That's a great post-mortem, thanks for writing it up!

I didn't mean to imply that binary PI is a great example of how to do
things, I just think Bruce's explanation is useful for answering
Ivan's question of why companies don't simply open their code. As you
point out binary blobs aren't a magic bullet and can end up a
bitrotting mess with no salvageable value for other potential
customers.

Intel's done a better job with FSP so far, hopefully we can convince
them that opening it up will add significant value for them by
enabling more customers and  more products. On that note, a shameless
plug: http://www.opencompute.org/projects/open-system-firmware/

On Thu, May 3, 2018 at 1:37 AM, Kyösti Mälkki <kyosti.mal...@gmail.com> wrote:
> Hi David,
>
> I tried to stay away from commenting, but now that you pulled this red
> binaryPI card from your pocket :)
>
> On Wed, May 2, 2018 at 9:49 PM, David Hendricks
> <david.hendri...@gmail.com> wrote:
>>
>> Bruce Griffith's e-mail about AMD's binary PI provides some great
>> insights into these issues:
>> https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html
>>
>
> I did not revisit that entire thread, judging by the date it was
> possibly prior to binaryPI code drops. From my perspective the only
> intention with binaryPI was for SAGE to gain a monopoly consulting
> position on AMD based coreboot board ports, leaving them the only ones
> capable of building and debugging with the blob.  I don't think any of
> the advertised benefits realized and the problems with time-to-market
> were not solved. I believe SAGE got the final nail on their coffin
> after AMD started to lock x86 JTAG debug (aka HDT) on their new SoC's
> and made SAGE EDK tool unusable.
>
> When referring to binaryPI below, I am ruling out ongoing development
> around StoneyRidge SoC. Somewhat different team, more strict quality
> goals as set by ChromeOS and much more resources and review talent put
> on the task now. Or so I have been told at least.
>
> The aftermath of binaryPI (say, version 0.1) :
>
> 1. Nobody *1 can reproduce the binaryPI blob builds that were pushed
> to coreboot 3rdparty repo. For most of these, I bet the source tree
> revision could not be traced back either. Source repositories are
> somewhere in the ruins of AMD AES and SAGE ex-personnel.
>
> 2. The needed binaryPI source is somewhat heavily patched version of a
> package, which a commercial partner is (or was) able to get through
> his AMD representative under an NDA and longish negotiations and
> promises of significant purchase volumes. In other words, your AMD
> reps cannot provide you with the source or the binary you need for use
> with coreboot.
>
> 3. After the binaryPI contractor SAGE shut down and AMD AES bailed out
> on coreboot (late 2015?), AMD has not granted permission to
> redistribute new builds of these binaryPI blobs even if we had the
> sources. And we do have the source for x86 AGESA parts, but not for
> PSP.
>
> 4. Commits of updated blob builds mostly just referenced AMD internal
> bugtracker ID numbers. For some cases, you cannot use the latest build
> of these blobs as they break elsewhere. In other words, for best user
> experience, you build the blob from the source you do not legally
> have.
>
> 5. Features partially or completely known broken in pre-built blobs
> (depending of SoC): ECC, HSA, IOMMU, S3 suspend, C6 boost, SPI
> dual/quad, fastboot (aka MRC cache).
>
> 6. AMD ignored or refused requests to provide debug builds of said
> blobs to create meaningful bootlogs on console, comparable to
> open-source AGESA. Also built-in error backlog feature in non-debug
> builds was initially broken, and once fixed, you still needed the
> source to decipher the error.
>
> 7. Some of the PSP (aka Security Processor) firmware in 3rdparty was
> modified for coreboot use. Commit message refers to which version was
> submitted, but file hash does not match with one you obtained from AMD
> reps. Someone with access to PSP's private key has approved the
> modifications, but none of this was mentioned with the commit.
>
> Needless to say, with all the issues above, it's hard to attract new
> industrial users on coreboot when product longevity is at risk due to
> uncertanities of having no firmware evaluation. After this first
> attempt of going closed-source with AGESA, there is one actively
> shipping product (5 board variants) from 2015. Not counting reference
> designs, there are less than five other commercially ported boards in
> this group from 2015-2017. AFAICS these board boot with coreboot only
> inside the companies R, some use custom builds of binaryPI blob
> while others link original (but modified) proprietary 

Re: [coreboot] Why do we have FSP-S

[David Hendricks]

On Wed, May 2, 2018 at 1:00 AM, Ivan Ivanov  wrote:
> I think, by "The Right Direction" he meant having the open source code
> instead of FSP-S blobs.
> 'Why do we have FSP-S' - I have the same question. Why this code must
> be kept closed, Intel?
> Open source is always better than closed, and your major competitor -
> AMD - would not be able
> to use your source code - not just because of the licenses, but
> because your CPUs are so different

Bruce Griffith's e-mail about AMD's binary PI provides some great
insights into these issues:
https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html

IMO the lesson is that processes for open sourcing firmware are very
costly and time-consuming. If we want open source firmware to be
considered from the start of a product development cycle, we need to
demonstrate that coreboot will add value and that the development
processes will not be too costly or burdensome.

It took Linux many years to become such a valuable part of the
ecosystem that vendors hire kernel developers to write open source
drivers. Coreboot is slowly getting to that point, and Chromebooks are
setting a good example for how to do it. Ranting and making unfeasible
demands does not help. Working with vendors to toward a more open
future and proving our worth by shipping real products does.

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

Re: [coreboot] Thread derailment

[David Hendricks]

On Wed, May 2, 2018 at 1:07 AM, Ivan Ivanov <qmaster...@gmail.com> wrote:
>
> Regarding the FSP-S thread - sorry, but I did not see any derailment.
> The whole thread - 'Why do we have FSP-S' - is about "why we should
> have more blobs when we already have enough?" And its understandable
> that some people got upset while seeing how coreboot is slowly turning
> from being almost completely open source to the big collection of blobs
> launching each other. Hopefully this reply would not get me removed...

The problem is the animosity some members brought to the other thread,
complete with conspiracy theories about "corporate control", insults
directed Intel, and negative comments about coreboot.

Just because someone doesn't like a particular vendor or blobs doesn't
mean they should interject with rude comments and prevent others from
having a civil discussion. The FSP-S thread illustrates exactly why
companies don't "consult the community" before doing things. If the
mailing list can't be used to discuss things with major hardware
vendors then these discussions will simply happen elsewhere without
any community input.

We need open dialogue with vendors more than we need obnoxious
commentary from certain individuals.

>
> Best regards,
> Ivan Ivanov
>
> 2018-05-01 19:07 GMT+03:00 ron minnich <rminn...@gmail.com>:
> > We've had to remove people from the list before, and I suppose at some point
> > it might have to happen again. Nobody likes this option. Sometimes there is
> > no choice.
> >
> > I agree that on a technical discussion list there's no place for abusive
> > language. We're all trying to do the best we can in a non-ideal world.
> >
> > ron
> >
> > On Tue, May 1, 2018 at 9:03 AM David Hendricks <david.hendri...@gmail.com>
> > wrote:
> >>
> >> Hello all,
> >> Recently I've noticed an uptick in threads going off-topic. While some
> >> noise should be expected on an open source mailing list, I think it's 
> >> become
> >> very counterproductive in many recent cases. A good example is the FSP-S
> >> thread going on where we see clear examples of people interjecting with
> >> non-technical diatribes and disrespecting developers, corporate
> >> contributors, and coreboot itself in violation of the existing community
> >> standards (https://coreboot.org/Code_of_Conduct).
> >>
> >> Most of this is perpetrated by a very small handful of individuals who
> >> have not contributed anything to the codebase, so I think the current
> >> problem could be dealt with easily. It might also be worth adding something
> >> about keeping threads on-topic and focused on technology in the Code of
> >> Conduct.
> >>
> >> Another option would be to have a developer-only mailing list, but I think
> >> it's best to try and keep things open to the community at large even if 
> >> that
> >> means ejecting the most disruptive members.
> >>
> >> Thoughts?
> >> --
> >> 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
>
> --
> 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

[coreboot] Thread derailment

[David Hendricks]

Hello all,
Recently I've noticed an uptick in threads going off-topic. While some
noise should be expected on an open source mailing list, I think it's
become very counterproductive in many recent cases. A good example is the
FSP-S thread going on where we see clear examples of people interjecting
with non-technical diatribes and disrespecting developers, corporate
contributors, and coreboot itself in violation of the existing community
standards (https://coreboot.org/Code_of_Conduct).

Most of this is perpetrated by a very small handful of individuals who have
not contributed anything to the codebase, so I think the current problem
could be dealt with easily. It might also be worth adding something about
keeping threads on-topic and focused on technology in the Code of Conduct.

Another option would be to have a developer-only mailing list, but I think
it's best to try and keep things open to the community at large even if
that means ejecting the most disruptive members.

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

Re: [coreboot] Why do we have FSP-S

[David Hendricks]

You are just, with this desperate chit-chat, fueling INTEL's big EGO.
Please, continue to do so! INTEL, at the end of the day, will thank
you for that! :-))

Please keep things civil. Whatever you think of Intel and FSP, this is a good 
opportunity to improve support for coreboot and others reading this thread 
would like to see progress.


From: coreboot  on behalf of Zoran Stojsavljevic 

Sent: Monday, April 30, 2018 9:58:33 AM
To: Nico Huber
Cc: Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin; 
coreboot@coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron minnich; 
Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris Ching; Duncan 
Laurie; Subrata Banik
Subject: Re: [coreboot] Why do we have FSP-S

Nico, Aaron,

You are just, with this desperate chit-chat, fueling INTEL's big EGO.
Please, continue to do so! INTEL, at the end of the day, will thank
you for that! :-))

Zoran
___

On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber  wrote:
> Hello Aaron,
>
> thanks for your reply.
>
> On 30.04.2018 05:22, Aaron Durbin wrote:
>> On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber  wrote:
>>> Hello coreboot folks, hello Intel and Google coreboot developers,
>>>
>>> back on Tuesday, some of us discovered a commit on gerrit [1] that
>>> implements (another) foreign interface inside coreboot. Discussing
>>
>> It's more of a bridge into coreboot's infrastructure, imo.
>
> It is. Anyway, maybe discuss that in another thread or on gerrit.
>
>>
>>> it didn't go well and I kind of bursted. I feel sorry about that now
>>> (especially because I got too personal).
>>>
>>> One of the causes for this clash definitely was that things apparently
>>> were discussed before but not with coreboot (i.e. this coreboot mailing
>>> list). So I'll try to take the general discussion here, but I've to
>>> start some years back, where you lost me.
>>>
>>> Some questions (that I believe have to be answered) right away. I'll
>>> argue about why later, so these won't get lost (in an already too long
>>> email):
>>>
>>>
>>> TLDR;
>>> For Google:
>>> You kind of introduced blobs in coreboot (with Sandy Bridge) which was
>>> a simple jump-in-jump-out thing and kind of accepted. The argument was
>>> that the things it does aren't documented by Intel anymore, AFAIR. But
>>> with Broadwell suddenly another blob emerged (in ramstage) some
>>> `refcode.elf` AIUI. It turned out, later, that this blob (also) does
>>> things that were open source for Haswell (and would work verbatim on
>>> Broadwell). It seems to play a role comparable to FSP-S.
>>>   o What's the story behind this blob?
>>>   o Why was it introduced?
>>>   o Was there more than IP concerns? Time to market pressure maybe?
>>
>> Saying it's comparable to FSP-S is apt. The story is, like most
>> things, that it has specific things that are not architectural that
>> Intel thinks they need to be secret. Typical settings are related to
>> power management. When needing to be competitive in the laptop space
>> power is a big concern. Time to market may have been a thing too, but
>> I don't recall all the specifics. I'll get to it later in the
>> response, but there are temporal components to decisions and/or how
>> things change over time that are not within Google's control when
>> working on a particular platform.
>>
>>>
>>> For Intel:
>>> It's hard for me to understand what parts of your silicon init you can
>>> open-source and what parts you can't. I know your BIOS Writer's Guides
>>> (BWG) / BIOS Spec, and many things therein are often published by you
>>> or Google. Please tell us.
>>>   o Are the things that you can *not* open-source documented at all?
>>>   o if so, in these BWG documents?
>>>   o Or is everything in these documents generally publishable (with
>>> some NDA clearance, ofc)?
>>>   o For a configuration of FSP-S that just runs the bare minimum to
>>> boot (e.g. skips questionable add-ons like TXT, SGX), is there
>>> anything not publishable?
>>>   o Can anything be done to get more documentation published? e.g.
>>> for things that are done in open source (or were done in the past)
>>> but are not publicly documented.
>>
>> Based on my working history a lot of BWGs and/or specs are usually
>> wrong. They don't always contain the right information, but generally
>> contain quite a few things that are wrong where you second guess
>> everything in the docs. This should sound familiar: the 'reference
>> code' is the documentation. Most docs are not in sync with reality or
>> necessarily with how the silicon was actually designed. It's my belief
>> when there wasn't as much change from version to version, the
>> copy-pasting in docs just kinda worked. But as things have been
>> getting more complicated and incorporating more 'features' the
>> documentation has not been keeping up.
>
> Still these documents exist. 

Re: [coreboot] [URGENT] - The KCMA-D8 is going to be removed from coreboot unless people cough up a board status update

[David Hendricks]

On Thu, Apr 26, 2018 at 12:06 PM, awokd via coreboot 
wrote:

> On Thu, April 26, 2018 5:09 pm, Pierre P wrote:
> > Hi,
> >
> >
> > I have a KCMA-D8 and am willing to provide a status update but have no
> > idea what is the formal way to do it.
> >
> > I guess it begins with testing a specific version (4.7 or latest source
> > ?). Please could you point me to a procedure.
>
> Looks like there was a board status uploaded a few days ago so it should
> be OK for a while-
> https://www.coreboot.org/Supported_Motherboards#asus.2Fkcma-d8.
>
> However, to upload your own, check out
> https://www.coreboot.org/Board_Status. (I had a hard time finding this
> page and had to end up searching for it, is it linked somewhere on
> coreboot.org?)


Yeah, it's not very obvious :-/ Maybe this will help people find it a
little easier (at least those who visit the supported mainboards wiki):
https://review.coreboot.org/#/c/coreboot/+/21568/
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How is our SPI API supposed to work?

[David Hendricks]

On Thu, Apr 19, 2018 at 3:54 PM, Aaron Durbin  wrote:
> >> OK. It's just moving code around.
> >
> > Yeah, I just want to shuffle code around. Nothing is broken right now, it's
> > just working in a confusing and inconsistent way. We should have an API
> > where the callbacks share the same semantics across all implementations
> > (and also document those semantics more clearly).
>
> I can send some CLs out.

While you guys are at it, it might be worth folding spi_claim_bus()
and spi_release_bus() into these changes so that CS is managed
automatically for things like SPI flash transactions. Right now they
return 0 for controllers that don't define ctrlr->claim_bus and
ctrlr->release_bus, meaning those which do fused ops and might not
even allow the user to manually drive CS. In those cases the behavior
feels like silent failure since they don't even attempt to do the
thing the user asked, yet they are required to be in the common
codepaths for generic SPI controllers.

The result would be that functions such as do_spi_flash_cmd() no
longer need to explicitly manage CS by claiming/releasing the SPI bus.
On the other hand, one might want to transfer one or more vectors
without toggling CS, so we may need to expose a way to leave CS alone
e.g. thru struct spi_op or another function parameter.

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

Re: [coreboot] BIOS/CoreBoot/UBOOT

[David Hendricks]

On Thu, Apr 12, 2018 at 2:18 PM,  wrote:

>
> - Mail d'origine -
> De: Peter Stuge 
> À: coreboot@coreboot.org
> Envoyé: Thu, 12 Apr 2018 17:43:48 +0200 (CEST)
> Objet: Re: [coreboot] BIOS/CoreBoot/UBOOT
>
> ...
> > Most people who buy computers are happy, because controlling the computer
> > isn't as important as using the desktop, which I think IS FINE.
> (emphasis mine)
> ...
>
> It depends .. many people use their computer to access their online bank
> accounts or to do operations with their bitcoin wallets. Would you be happy
> knowing that someone from MS (could be a very decent person btw..) have
> STEALTH access to your banking operations at every moment?...
>

What does this have to do secure boot, which is what Peter was talking
about?

I think we're all on the same page with regards to obscure privileged code
and microcontrollers running in the system. But that's not what was being
discussed.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[David Hendricks]

On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung  wrote:

> I currently have a board that uses Intel Xeon D (previously codenamed
> Broadwell DE).  It boots up with BIOS/UEFI. I 'm exploring other oot-up
> options here.
>
>
> I'm not familiar with this early stage of system initialization.  It seems
> BIOS/UEFI to Linux needs to use PXE, with the need to configure DHCP (and
> possibly Proxy DHCP), TFTP server PXELINUX, Linux initial RAM disk
> (initrd) configuration file, and then Linux.  Previously, I'd been using
> Coreboot/UBOOT environment (as a user, not developer).  Prerequisite seemed
> much simpler.
>
>
> A few questions -
>
>
>
>1. Is there even a coreboot support for this CPU already available and
>stable that I could download and reflash?  Or are we talking about some
>serious re-development?
>
>
Yes - See src/mainboard/intel/camelbackmountain_fsp/ for the reference
platform.

You'll need the Intel FSP blob from
https://github.com/IntelFsp/FSP/tree/Broadwell-DE. You'll also need
microcode which you can download from developer.intel.com.


>
>1. Is it possible to go from BIOS/UEFI to UBOOT (on-board)?  How?
>
>
I haven't tried uboot as a payload, but yes, it is possible. There are
other options available to consider depending on your use case.


>
>1. Support for Secure Boot - would one approach be simpler than
>another?
>
>
It depends on what you want/need. Philipp Deppenwiese is working on "vboot"
(Google's verified boot implementation) integration with upstream:
https://review.coreboot.org/#/c/coreboot/+/24993/

More about that approach here:
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot


>
>1. Am I even on the right track thinking this way?
>
>
You seem to be off to a good start :-)
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[David Hendricks]

>
> There's obviously a few people on this list using the Asus boards mentioned
> which is great. The issue we need to solve is getting more people to submit
> test results so that this isn't a problem in the future.
>
> Even if I didn't use mine for something important I am unable to submit
> results because I refuse to provide my "real" name and am too honest to use
> a fake name.
>

As I understand the DCO is only required for code submissions, while
board_status results are auto-generated and don't require a sign-off. Not
sure how Patrick and others feel about allowing aliases to be used for
gerrit accounts though.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[David Hendricks]

On Fri, Apr 6, 2018 at 5:43 PM, Daniel Gröber  wrote:

> I'd be happy to upload a board-status report if someone can give me
> (or tell me how to get) commit rights for the appropriate repo. I
> cannot for the life of me figure out what the proper procedure for
> that is just from the wiki.
>
> I just recently started playing around with my KCMA-D8 and coreboot,
> so I still got it right here on my desk :)
>

Hi Daniel,
Thanks for volunteering!

Which wiki? For commit rights, have you tried
https://www.coreboot.org/Git#Register_with_gerrit ? I just updated the
board status wiki to hopefully make that step easier to follow.

Please let us know where you get stuck. Many of us set up our accounts
years ago and the documentation may be stale or non-obvious to newcomers,
so a fresh perspective is welcome.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[David Hendricks]

On Fri, Apr 6, 2018 at 3:40 PM, taii...@gmx.com  wrote:

> Like I have said before these types of policies are eventually going to
> result in coreboot only having unobtainable development boards in the
> tree (that are of course not owner controlled)
>
> It simply isn't right.
>

Indeed, this isn't right (as in correct) so don't spread this FUD. The
boards are still in the tree, you just need to check out whatever coreboot
version is known to actually work with the board. For example if a board
was last reported working in coreboot-4.6, then `git checkout 4.6` or
checkout a specific hash reported on the board_status repo.

It does no good for users to have hundreds of boards in master that fail to
boot, and no good for developers who need to maintain and refactor code for
boards that nobody tests and have been abandoned.

There's obviously a few people on this list using the Asus boards mentioned
which is great. The issue we need to solve is getting more people to submit
test results so that this isn't a problem in the future.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[David Hendricks]

On Sat, Mar 17, 2018 at 10:46 PM, Alex G. <mr.nuke...@gmail.com> wrote:

> On 03/14/2018 11:39 PM, David Hendricks wrote:
>
>>
>>
>> On Mon, Mar 12, 2018 at 12:26 PM, taii...@gmx.com <mailto:taii...@gmx.com>
>> <taii...@gmx.com <mailto:taii...@gmx.com>> wrote:
>>
>> On 03/11/2018 09:42 PM, Tom Li via coreboot wrote:
>>
>> 2. Even if all developers are registered with their IDs
>>
>> And you actually have to meet them in person for this due to
>> photoshop existing.
>>
>> I have always thought it hilarious when a company asks for a scan of
>> a passport or identification card.
>>
>>
>> There still seems to be some confusion. As Alberto alluded to this isn't
>> about verifying your identity. What matters is protecting coreboot along
>> with its adopters and contributors (including companies who sell
>> coreboot-based products) from legal threats. That is far more valuable than
>> any bug fixes you might have to offer.
>>
>
> Oh come on. Pseudonyms are perfectly acceptable ways of identifying
> oneself for copyright reasons. See what the copyright office has to say:
>

This isn't really relevant and just muddies the waters in this
discussion. Licensing and copyright are separate things, the DCO (
https://developercertificate.org/) addresses the former.


> Unless I'm reading this policy wrong and "legal name" allows pseudonyms.


...in copyright, but even then you need to register the fictitious name
(e.g. a business name) to be sure the pseudonym is used appropriately.
Otherwise how would a court know that a troll who claims ownership of a
work isn't the real copyright holder?

For licensing the person who contributes a patch to an open source project
must have legal authority to do so in the first place and the DCO is an
affirmation of their "due diligence" (some legal term) to do so. Pretty
much the whole SCO thing was about IBM's license to distribute derivative
works of Unix under the GPL - Check out T.mike's slides (12-14 are
particularly relevant) for a nice summary.

Long story short is that in order to protect coreboot there needs to be
some credible way for courts to trace origins of code should a dispute over
copyright or licensing ever come up.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[David Hendricks]

On Mon, Mar 12, 2018 at 12:26 PM, taii...@gmx.com  wrote:

> On 03/11/2018 09:42 PM, Tom Li via coreboot wrote:
>
> 2. Even if all developers are registered with their IDs
>>
> And you actually have to meet them in person for this due to photoshop
> existing.
>
> I have always thought it hilarious when a company asks for a scan of a
> passport or identification card.


There still seems to be some confusion. As Alberto alluded to this isn't
about verifying your identity. What matters is protecting coreboot along
with its adopters and contributors (including companies who sell
coreboot-based products) from legal threats. That is far more valuable than
any bug fixes you might have to offer.

Perhaps you can fork the repository elsewhere and post your patches, but
please keep them out of upstream unless you're willing to do what has been
deemed necessary to protect the project from the SCOs of the world. This
means abiding by the DCO (https://developercertificate.org/) including its
use of the pronoun "I".
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[David Hendricks]

On Tue, Mar 6, 2018 at 9:04 AM, <mtur...@codeaurora.org> wrote:

> On 2018-03-05 17:50, David Hendricks wrote:
>
>> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com <taii...@gmx.com>
>> wrote:
>>
>> I can't understand as to why doing a git commit requires your "real"
>>> name
>>>
>>
>> SCO.
>>
>> Ref: https://lkml.org/lkml/2004/5/23/10
>>
>
> Wow, SCO, really?
>

Well, any (likely failing) company who would rather litigate and "play the
US legal system as a lottery" (as Torvalds put it) instead of investing in
engineering to build/improve their own product.


> If anybody on list is interested, I gave a presentation on the SCO
> litigation to a local LUG in April.2005.
>
> http://recipes4linux.com/os-presentations/2005apr.pdf


Nice! BTW, did you know the case is still ongoing? Check out
https://www.ca10.uscourts.gov/opinions/16/16-4040.pdf . Section G begins
with "We are now almost fifteen years into this litigation."

As silly as SCO's claims were, last I heard (years ago) IBM had spent over
a hundred million dollars on the case.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[David Hendricks]

On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com  wrote:

> I can't understand as to why doing a git commit requires your "real" name


SCO.

Ref: https://lkml.org/lkml/2004/5/23/10
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARMv8 MMU changes

[David Hendricks]

On Thu, Mar 1, 2018 at 11:30 PM, Patrick Rudolph <
patrick.rudo...@9elements.com> wrote:

> Am Donnerstag, den 01.03.2018, 14:11 -0800 schrieb Julius Werner:
> > Hi Patrick et. al.,
> >
> > Continuing from what you said on IRC, let's please discuss this
> > before you spend time to work on any major changes to the ARMv8 MMU
> > code. I don't think that should be necessary (especially changing the
> > GRANULE_SIZE which is a complication I'd really like to avoid
> > having), and I'd like to understand what you're trying to do first.
> > Can you explain what memory ranges you need to map on your SoC and
> > why they need to be so large?
> >
> Hi Julius,
> the Cavium SoC expose the MMIO space at 1 << 47 with a size of 1 << 47.
> As coreboot does use PA=VA mapping, I have to extend the VA space to 48
> bit and that seems to work fine with 64KB granule.
>
> The change in coreboot is minimal, I'm not sure if all armv8 CPUs
> support's that granule, but a Kconfig should do for now.
>

Yes, the architecture reference manual for ARMv8 mentions that 4KB, 16KB,
and 64KB are supported for VMSAv8-64.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Custom Layer or Overlay

[David Hendricks]

Hi Naveed,
3rdparty/ is probably what you want. That directory is managed using git
submodules: https://review.coreboot.org/cgit/coreboot.git/tree/
Documentation/submodules.txt
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does the coreboot build system support external patches?

[David Hendricks]

In addition to what Martin suggested they might also consider storing their
code in a separate repository and pulling it in as a git submodule into the
coreboot/3rdparty/ directory. What's best for them depends on their use
case, like if they're mostly adding new files with an API or modifying
existing files.

On Thu, Feb 1, 2018 at 12:26 PM, Martin Roth  wrote:

> coreboot uses the site-local directory to allow users to extend the
> coreboot build outside of the regular coreboot coreboot files.
> Create the coreboot/site-local directory, and add Makefile.inc and Kconfig
> files.  Both of these files will get picked up by coreboot.
>
> To run steps at the start of the build, you can create a target that does
> whatever is needed, then calls the 'all:' target to do the build.
> At the end of the build, you can hook into the 'build_complete::' target
> to run whatever finalization steps are needed.
>
> Martin
>
> On Thu, Feb 1, 2018 at 10:53 AM, Jay Talbott  com> wrote:
>
>> I got this question from a client yesterday that I didn’t know how to
>> answer because I focus primarily on the porting effort (getting coreboot to
>> build and boot for their hardware) and let the client figure out how they
>> want to manage the resulting code base once the porting effort is complete.
>> So I offered to inquire of the coreboot community to see if anybody can
>> provide an answer for my client.
>>
>>
>>
>> Below is the inquiry that I received:
>>
>>
>>
>> I’m looking at how best to structure our coreboot repositories.  Does the
>> coreboot build system support the concept of external patches? With
>> buildroot you can keep your changes is a directory tree separate from the
>> FOSS tree. Then during the build step your patches get applied and compiled
>> using another separate build tree.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> - Jay
>>
>>
>>
>> Jay Talbott
>> Principal Consulting Engineer
>> SysPro Consulting, LLC
>> 3057 E. Muirfield St.
>> Gilbert, AZ 85298
>> (480) 704-8045
>> (480) 445-9895 (FAX)
>> jaytalb...@sysproconsulting.com
>>
>> http://www.sysproconsulting.com
>>
>>
>>
>> --
>> 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
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Power off in Coreboot?

[David Hendricks]

On Mon, Jan 29, 2018 at 1:59 PM, Julius Werner  wrote:

> In grepping the sources I see the API is provided and only used in a
>> handful of cases, mainly x86.
>>
>> On an ARMv8 target is there a power-off use-case for Coreboot?
>> This is strictly from Coreboot perspective, not Depthcharge.
>>
>
> You're right, there is no globally standardized power off API in coreboot,
> it's only implemented internally by select chipsets. There is no ARM target
> that implements something like this at the moment, because they don't
> really need to.
>

Indeed, hlt() is just an infinite loop as currently implemented on aarch64
and that's only used if CONFIG_FATAL_ASSERTS is set as a debug option.

I think the prevailing wisdom is that coreboot always has to try to load
the payload. An error path that shuts down the machine isn't very helpful
to a user, though perhaps that is not always true if we can log an error
(e.g. to RW_ELOG on boot ROM) and the user can retrieve it out-of-band
(systems with a BMC, etc).
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

On Fri, Jan 26, 2018 at 12:23 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> wrote:

> Hi guys,
>
>
>
> Sorry for the late. I spent some time try to use U-Boot as payload but
> still get infinite reboot…maybe wrong TSC clock frequency in my dts file.
>
> About using the Grub2 as payload, it is now working after I modify
> “–unit=1” to “—unit=0” :P That’s why it hangs…
>
> Thanks for all your help.
>

I'm happy to hear of your success! It will be great if you figure out the
issue with the u-boot payload as well.

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

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

Hi Hilbert,

On Mon, Jan 15, 2018 at 12:51 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> wrote:

> Hi Zoran,
>
> That information was dumped when I use SeaBIOS as coreboot's payload. I
> don't know why it is related to GRUB_legacy. If I use GRUB2 as payload, it
> just hangs there. I am still struggling on this :(
>

If you are using serial console, did you remember to enable serial output
in grub.cfg? There is a GRUB2 wiki page on coreboot.org which you might
find helpful (if you haven't already read it):
https://www.coreboot.org/GRUB2


By the way, I saw following message in the log. Should I choose NodeManager
> Mode? Do you know what's different?


> >>[SPS] SiliconEnabling Mode
>
>
> Thanks.
> -Hilbert
>
> -Original Message-
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: Thursday, January 11, 2018 7:27 PM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: Zeh, Werner; coreboot@coreboot.org; David Hendricks
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
> > Booting from Hard Disk...
> > Booting from :7c00
>
> It is booting from the thirty second Kbyte of HDD (sector 62, sector 0
> is MBR), where the beginning of GRUB Legacy is placed/implanted,
> called core.img or similar name.
>
> https://wiki.archlinux.org/index.php/GRUB_Legacy
>
> Well, you have succeed, by all means. Problem solved! ;-)
>
> Zoran
> ___
>
> On Thu, Jan 11, 2018 at 12:06 PM, Hilbert Tu(杜睿哲_Pegatron)
> <hilbert...@pegatroncorp.com> wrote:
> > Hi Werner,
> >
> > Thanks for your information. It works but still has same result. The
> result is like following. My usb stick is ext4fs formatted and has kernel
> and rootfs files. I wish SeaBIOS can give me a shell like Grub so that I
> can specify how to boot next. Or should I create a bootable usb stick?
> >
> >
> > = PEIM FSP is Completed =
> >
> > Returned from FspNotify(EnumInitPhaseReadyToBoot)
> > Jumping to boot code at 000ff06e(7eff6000)
> > CPU0: stack: 00128000 - 00129000, lowest used address 00128b00, stack
> used: 1280 bytes
> > entry= 0x000ff06e
> > lb_start = 0x0010
> > lb_size  = 0x0012d6d0
> > buffer   = 0x7ed66000
> > SeaBIOS (version rel-1.10.2-0-g5f4c7b1)
> > BUILD: gcc: (coreboot toolchain v1.44 March 3rd, 2017) 6.3.0 binutils:
> (GNU Binutils) 2.28
> > Found mainboard Intel Camelback Mountain CRB
> > Relocating init from 0x000e3860 to 0x7ef74cc0 (size 49824)
> > Found CBFS header at 0xffe00138
> > multiboot: eax=0, ebx=0
> > Found 25 PCI devices (max PCI bus is 05)
> > Copying SMBIOS entry point from 0x7efc1000 to 0x000f7140
> > Copying ACPI RSDP from 0x7efd2000 to 0x000f7110
> > Using pmtimer, ioport 0x408
> > WARNING - Timeout at tis_wait_sts:160!
> > WARNING - Timeout at tis_wait_sts:160!
> > Scan for VGA option rom
> > XHCI init on dev 00:14.0: regs @ 0xfea0, 21 ports, 32 slots, 32 byte
> contexts
> > XHCIprotocol USB  2.00, 8 ports (offset 1), def 3001
> > XHCIprotocol USB  3.00, 6 ports (offset 16), def 1000
> > XHCIextcap 0xc1 @ 0xfea08040
> > XHCIextcap 0xc0 @ 0xfea08070
> > XHCIextcap 0x1 @ 0xfea0846c
> > EHCI init on dev 00:1a.0 (regs=0xfea18020)
> > EHCI init on dev 00:1d.0 (regs=0xfea19020)
> > WARNING - Timeout at i8042_flush:71!
> > ebda moved from 9f000 to 9e800
> > AHCI controller at 00:1f.2, iobase 0xfea17000, irq 5
> > Found 0 lpt ports
> > Found 2 serial ports
> > XHCI no devices found
> > Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0
> > Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1
> > USB MSC vendor='Generic-' product='Multiple Reader' rev='1.11' type=0
> removable=1
> > ehci_wait_td error - status=80e42
> > Initialized USB HUB (0 ports used)
> > USB MSC blksize=512 sectors=30777344
> > Initialized USB HUB (1 ports used)
> > All threads complete.
> > Scan for option roms
> > Running option rom at c000:0003
> > Running option rom at c100:0003
> > Searching bootorder for: /pci@i0cf8/pci-bridge@2,2/*@0
> > Searching bootorder for: /pci@i0cf8/pci-bridge@2,2/*@0,1
> >
> > Press ESC for boot menu.
> >
> > WARNING - Timeout at tis_wait_sts:160!
> > Searching bootorder for: HALT
> > drive 0x000f70c0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=30777344
> > Space available for UMB: c2000-efb00, f6960-f70c0
> > Returned 184320 bytes of ZoneHigh
> > e820 map has 9 items:
> >   0:  - 0009e800 = 1 RAM
> >   1: 0009e800 - 000a = 2 RESERVED
> >

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

Hi Hilbert,
For what it's worth, I was able to boot Linux as the payload without any
obvious problems. It might be good to try other payloads, or see if you can
enable serial console earlier in u-boot to find exactly where it reboots.

Here is my CPUID and microcode info printed by coreboot during ramstage:
microcode: sig=0x50664 pf=0x10 revision=0xf0c
CPUID: 00050664
Cores: 32
Stepping: Y0
Revision ID: 05

So it appears I am using the production CPU and microcode that Zoran
suggested. To obtain this, I downloaded SRV_P_203.exe from Intel's website
and converted M1050664_0F0C.TXT into a C-style header that can be
included by coreboot's build system.


On Thu, Jan 4, 2018 at 3:19 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> wrote:

> Hi Zoran,
>
> About this issue, I decide to follow David's suggestion to comment out the
> SMBus clock gating and then it can continue booting until load my U-Boot
> payload. But then it enters infinite reboot as previous attached log
> "smbus_init_fail_max_dump2.txt". I am not sure if is a side effect or
> just a new issue. Do you have any recommendation about the reboot? By the
> way, we have our own BDX-DE board, not Camelback CRB. But just use similar
> configuration. Thanks.
>
> -Hilbert
> This e-mail and its attachment may contain information that is
> confidential or privileged, and are solely for the use of the individual to
> whom this e-mail is addressed. If you are not the intended recipient or
> have received it accidentally, please immediately notify the sender by
> reply e-mail and destroy all copies of this email and its attachment.
> Please be advised that any unauthorized use, disclosure, distribution or
> copying of this email or its attachment is strictly prohibited.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，
> 請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

Hi Hilbert,

On Wed, Jan 3, 2018 at 12:56 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> wrote:

> Hi Zoran,
>
> I have changed to maximal log level and found SMBus init was failed when
> enabling clock gating. Do you have any comments about this? Thanks.
>

Yes, looking back at my notes from earlier that is also how I got past the
issue - by commenting out the following lines in
src/soc/intel/fsp_broadwell_de/smbus.c:
/* Enable clock gating */
   reg32 =read32(rcba + 0x341c);
   reg32 |= (1 << 5);
   write32(rcba + 0x341c, reg32);

I suspected that reading the register is where it hung, however I did not
have a chance to root cause the issue or try to enable clock gating
elsewhere. The system worked without clock gating enabled, though.

I also tested another Broadwell-DE device that did not require the same
hack, but it used different memory and a different processor stepping
(stepping 3 instead of stepping 4) which may have made a difference.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[David Hendricks]

On Sat, Dec 30, 2017 at 10:05 PM, Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

> With a few minutes spent looking, it is not at all clear to me how Siemens
> handles their GPL responsibility and whether they attempt to provide
> compliance for their customers or not.
>

For their part, Siemens releases the code upstream:
https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/siemens

As with your case the firmware for their products is basically invisible to
the customer. Nevertheless if the customer wants to examine the code or
make changes they can easily do so. Relevant license information is found
in the header of each source code file as well as the COPYING file at the
root of the coreboot directory.

Werner (cc'd) might be able to share some more details about how they
handle compliance matters.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[David Hendricks]

Hi Ian,
Did you actually need to change coreboot or SeaBIOS? If so, how extensive
were the changes? I am guessing that the boot firmware isn't considered to
be part of the high-value IP of the product - that is presumably in your OS.

If you can publish the coreboot and SeaBIOS code on your website (it could
be a zip file or something) then things should be reasonably simple. Even
better would be to add the mainboard support to upstream coreboot or fork
upstream coreboot on github and then add your patches on top. Then
downstream customers can then easily download the code and, if needed,
modify and commit their patches to the same codebase as to be in compliance
in the same manner as you.

Your idea about using the "About" tab to inform the user about the licenses
and where to find the code is good. It should cover your company even if
the customer never reads it. You shouldn't need a clickthrough license or
anything (gnu.org has a FAQ that covers that topic:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html). Also, the
"conspicuous" requirement should already be met with the license
information that exists in the header of each source code file and/or a
LICENSE or COPYING file. As Peter mentioned that is exactly how the
requirement is met for large companies who work with open source software.

Like you say, the goal here should be to make it so that downstream
customers don't need to think about this stuff. The nice thing is that if
you act consistently with the spirit of the open-source licenses then this
should all be simple for them and for your company as well, and you get to
spend more time engineering and collaborating and less time worrying.

Just my $0.02. Please make sure to consult your company's legal department
before acting on anything you read in this thread (or elsewhere) :-)


On Fri, Dec 29, 2017 at 6:21 PM, Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

> ron minnich wrote
> > how are you different in this case from Motorola, who had to put their
> linux source on a web site? companies resold motorola phones. Or the many
> switch vendors who sell network switches that run coreboot/linuxbios? or
> irobot, who use it still on the packbot?
> > Or how are you different from just about every vendor that sells
> embedded ARM boards that run u-boot?
> We are, because of the nature of our customers, very different from all of
> your example use cases, except perhaps the people who sell embedded ARM
> boards.
>
> Motorola phone: They sell their product to people (well, companies) who
> set out to make GPL licensed products, typically for a large market. The
> customer of Motorola makes no modifications to the Motorola phone, or at
> least no significant modifications. There is no difficulty for such a
> prospective reseller of such a product to comply with GPL. There are lots
> of sales to cover the initial costs. But, most importantly, the Motorola
> reseller is typically not making a new product. They are reselling the
> Motorola product, perhaps as a private label, to an end user who will
> receive Motorola's packaging and notifications (at first boot, perhaps - I
> do not actually know how).
>
> As far as I can see (well, guess), network switch purchasers are almost
> always end users (corporate or personal). And, it is my guess - after
> spending the past week and a half trying to understand GPL's implications -
> that there are many, many small resellers of network switches in complete
> systems that are out of compliance with GPL because they do not even think
> about the issue. As a side note, our customers are a bit like this kind of
> reseller of a complete system that happens to contain a network switch,
> though the analogy is not great because the network switch is in some sense
> a complete system, while what we make is not. Still, if I sell a network
> installation to a small shop, and I fail to give the recipient of my system
> that includes that switch the GPL license and a place to get the source
> code, I am in violation of GPL. I do not want this to happen to my
> customers.
>
> iRobot is making an end use product, not a product that someone else is
> going to take and build into something very different from the iRobot
> product. Again, a lot like Motorola and their phone. If NewEgg sells an
> iRobot product, they just pass through the iRobot package - with everything
> in it - so (I think, though I am not quite sure) they are in compliance as
> long as iRobot was. I suspect that NewEgg just assumes that iRobot got
> their licensing right. My reading of GPL is that NewEgg actually has their
> own obligation under GPL separate from iRobot's, but I would guess they do
> not worry about it much. They are not making anything. They are just
> reselling.
>
> ARM boards that run u-boot: The target customer base is aiming to take
> advantage of the ARM board to make a product at a low cost (typically), and
> most of them are well aware of GPL and 

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

Hi Hilbert,
Have you had any luck? I have a board with a similar problem. Commenting
out the entry for device 1f.3 in devicetree.cb seemed to help (I copied
src/mainboard/intel/camelbackmountain_fsp for my project).

On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@pegatroncorp.com> wrote:

> Hi,
>
>
>
> I am porting coreboot on Intel BDX-DE platform and it gets stuck when init
> PCI 00:1f.3. This device should be SMBus, serial management bus. But I
> don’t know why this happened. Does anyone can give me some hint? Attached
> is my boot up log. Thanks in advance.
>
>
>
> -Hilbert
> This e-mail and its attachment may contain information that is
> confidential or privileged, and are solely for the use of the individual to
> whom this e-mail is addressed. If you are not the intended recipient or
> have received it accidentally, please immediately notify the sender by
> reply e-mail and destroy all copies of this email and its attachment.
> Please be advised that any unauthorized use, disclosure, distribution or
> copying of this email or its attachment is strictly prohibited.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子
> 郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
>
> --
> 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] Depthcharge License

[David Hendricks]

To be fair, it appears that many source files refer to a non-existent
LICENSE file. Someone on the CrOS team should probably just add the LICENSE
file for depthcharge and/or contact mal@ to see how the license info is
being collected these days (e.g. for chrome://os-credits
).

On Tue, Dec 19, 2017 at 9:19 AM, ron minnich  wrote:

> Is there even a question? Looks like aaron just answered the original
> question, which boils down to Read The Source?
>
> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot <
> coreboot@coreboot.org> wrote:
>
>> On Tue, Dec 19, 2017 at 8:03 AM,  wrote:
>>
>>> On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
>>>
 Preparing to mirror the coreboot.org requires us to vet the various
 licenses, etc.

 There doesn't appear to be a LICENSE or COPYING file in the Depthcharge
 tree.

 My understanding is that Depthcharge is licensed GPLv2 (or later).

 How would I confirm this with an online source?

 Cheers,
 T.mike

>>>
>>> Should this query be posted on Chromium list rather than Coreboot list?
>>>
>>>
>> Probably. The files in the depthcharge repository  have licenses at the
>> top of each file. They are GPLv2.
>>
>> Cheers,
>>> T.mike
>>>
>>> --
>>> 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
>
>
> --
> 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] BIOS log in coreboot

[David Hendricks]

On Wed, Nov 22, 2017 at 10:09 AM, ingegneriafore...@alice.it <
ingegneriafore...@alice.it> wrote:

> Hello Guys !
>
> I apologize with you if my question seems silly:
>
> can you tell me if Coreboot stores a log of the POST phase in its EPROM
> memory ?
>
> If so, is it possible to retrive the log by the Operative System  and read
> it ?
>
> Thanks in advance.
>
> Vincenzo.
>

There are a few ways you can log stuff in coreboot. Console output can be
stored in DRAM which can later be retrieved from the OS using the `cbmem`
tool, or written to SPI flash (warning: this is for debugging may cause
premature wear). POST codes can be saved to CMOS or sent to an external
device (such as an EC or other microcontroller) that can store them.
There's also an event log which uses a SMBIOS-like record format that is
written to flash.

Run `make menuconfig` and look under "Console" for more details.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ast2400 / ast2500

[David Hendricks]

On Fri, Oct 20, 2017 at 7:46 AM, Tirumalesh 
wrote:

> Hi,
>
> Could some one please let me know, if corebott supports either
> AST2400/AST2500 (ASpeed BMC)
> If yes, how to test it with QEMU?
>

What kind of support are you looking for? There is some support for
interfacing with it in coreboot running on the host:
https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed

I believe this was added as part of the Asus KGPE-D16 OpenBMC porting
effort: https://www.raptorengineering.com/coreboot/kgpe-d16-
bmc-port-status.php
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot