[coreboot] Getting help to improve our documentation

[Patrick Georgi via coreboot]

Hi everybody,

in today's leadership meeting we discussed whether we should hire
technical writers to improve our documentation. While the situation
already got a lot better since we moved to the Documentation/ directory
instead of the wiki, it's still painfully obvious (at least to me)
that we're a hacker oriented project with not so much focus (and/or
skills) on documentation.

Philipp and Arthur stepped up to collect ideas about the scope of
such work, but we also decided to create an issue where ideas can
be proposed.

Therefore, if you've always thought that _this_ part of coreboot is
woefully underdocumented (or that our documentation sucks because of
_that_), please contribute to https://ticket.coreboot.org/issues/245.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to push to board_status repo?

[Patrick Georgi via coreboot]

We moved the other thread off-list, but the issue was that there's a https
proxy in the way that
terminates SSL connections.

I documented the approach to deal with that in
https://review.coreboot.org/c/coreboot/+/37599


Patrick

Am So., 8. Dez. 2019 um 09:39 Uhr schrieb Mike Banon :

> My guess is that maybe you've configured this repo incorrectly. After
> logging in to review coreboot org , go to
> https://review.coreboot.org/admin/repos/board-status and copy a HTTP
> command for cloning, like " git clone
> "https://mike...@review.coreboot.org/a/board-status; && (cd
> "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse
> --git-dir`/hooks/commit-msg
> https://mike...@review.coreboot.org/tools/hooks/commit-msg; chmod +x
> `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced
> by your username there (but better to copy it from HTTP tab to avoid
> accidental mistakes). Then copy the files you would like to commit to
> this repository, commit and push, and it should only ask your
> password, without a username.
>
> On Sun, Dec 8, 2019 at 11:37 AM Mike Banon  wrote:
> >
> > My guess is that maybe you've configured this repo incorrectly. After
> > logging in to review coreboot org , go to
> > https://review.coreboot.org/admin/repos/board-status and copy a HTTP
> > command for cloning, like " git clone
> > "https://mike...@review.coreboot.org/a/board-status; && (cd
> > "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse
> > --git-dir`/hooks/commit-msg
> > https://mike...@review.coreboot.org/tools/hooks/commit-msg; chmod +x
> > `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced
> > by your username there (but better to copy it from HTTP tab to avoid
> > accidental mistakes). Then copy the files you would like to commit to
> > this repository, commit and push, and it should only ask your
> > password, without a username.
> >
> > On Wed, Dec 4, 2019 at 5:17 PM Jorge Fernandez Monteagudo
> >  wrote:
> > >
> > > Hi all,
> > >
> > > I've generated a new entry in
> util/board_status/board-status/amd/bettong/4.10-6-g12ec481/2019-12-04T13_27_01Z/
> > > but I'm not able to push the changes.
> > >
> > > I'm able to entry in to https://review.coreboot.org/settings/ and I
> can see my HTTP credentials with my github user name
> > > and I've generated a new password pushing the button but then I try to
> do a push and always get:
> > >
> > > $ cd util/board_status/board-status
> > > $ git push
> > > Username for 'https://review.coreboot.org': jorgefm1900
> > > Password for 'https://jorgefm1...@review.coreboot.org':
> > > fatal: Authentication failed for '
> https://review.coreboot.org/board-status.git/'
> > >
> > > Any resource to configure a review.coreboot.org repo user? I've tried
> to change the password through Github creating a
> > > personal access token without luck...
> > >
> > > Thanks!
> > > ___
> > > 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
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to push to board_status repo?

[Patrick Georgi via coreboot]

Note that the setting is per-clone by default, so if you set up coreboot to
be without sslVerify, that doesn't apply to the board_status repo unless
you also used --global.

Am Mo., 9. Dez. 2019 um 11:11 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:

>
> >We moved the other thread off-list, but the issue was that there's a
> https proxy in the way that
> >terminates SSL connections.
> >
> > I documented the approach to deal with that in
> https://review.coreboot.org/c/coreboot/+/37599
>
> Hi,
> I'm still stuck with the same error trying to push anything. Disabled
> validating certs as pointed in
> your change doesn't solve my issue. But it's related to my workstation or
> company's proxy server
> because the same user works at home and I can login and send patches...
>
> Regards
> Jorge
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to push to board_status repo?

[Patrick Georgi via coreboot]

Am Mo., 9. Dez. 2019 um 11:51 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:

> >Note that the setting is per-clone by default, so if you set up coreboot
> to be without sslVerify, that doesn't apply to the board_status repo unless
> you also used --global.
>
> Yes, I have it configured globally using ~/.gitconfig file
>
In that case you have it really bad in that the proxy not only replaces the
SSL cert but also tampers with the data you send. There's little we can do
in such cases (given that https is usually the more accessible protocol in
such scenario and the SSH interface to Gerrit on port 29418 usually isn't
accessible at all).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Patrick Georgi via coreboot]

Am Mo., 9. Dez. 2019 um 19:02 Uhr schrieb Seth Rosenblatt <
s...@the-parallax.com>:

> I wasn't able to find the security@ alias, otherwise would've emailed
> y'all there. I didn't hear back before publication but happy to make any
> corrections if needed. I'm also willing to include a statement from
> Coreboot if you want to send one over.
>
Sadly there's little content in your article about what claims were made
and which parts of these claims applies to coreboot. The figure about the
ARM trusted boot flow is copied out of the old paper you linked that makes
no mention of coreboot.
It seems impossible to find the slides or even a recording of the talks
that you covered in the article. Apart from a few tweets and your article,
that entire thing might as well not exist, even though the conference was
apparently over a month ago.

All that makes it hard to give any clear statement on the subject matter.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD Agesa Bettong board support

[Patrick Georgi via coreboot]

Am Do., 5. Dez. 2019 um 15:22 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:

> One noob question. Can I push a change from a commit
> (f77f2c79c2bb898c123ffe89a0bd1acb5362afc5)
> not the master? From this commit I can make it boot but from the last
> there are
> a lot of changes to made...
>
You can, yes. If it can't be merged, that's only for review, but it would
be a start.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Tianocore: Long time to boot / Menu.

[Patrick Georgi via coreboot]

Am Fr., 6. Dez. 2019 um 17:23 Uhr schrieb Jose Trujillo via coreboot <
coreboot@coreboot.org>:

> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
>
> Several minutes later boots normal.
> If someone here knows how to fix it or suspect which could be the reason
> please let me know.
> I will ask for help in the EDK2 mail list too.
>
You probably have the edk2 side smmstore support added? And maybe not the
very latest coreboot side driver installed (Arthur pushed some important
fixes recently)?

I'm not sure if the edk2 mailing list is willing or able to help here,
given that this is a third-party addition from their point of view.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD Agesa Bettong board support

[Patrick Georgi via coreboot]

Hi Jorge,

Am Do., 5. Dez. 2019 um 12:53 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:

> and in setting I can see my GitHub user (jorgefm1900), the ID, etc... Then
> under 'HTTP Credentials' I've press
>
the 'GENERATE NEW PASSWORD' button and the string I get is what I use to
> login with the username.
>
yes, that looks reasonable.

I've tried creating the ~/.netrc file too with this info too but with no
> luck
>
Some installs (depends on libcurl, I think) require .netrc to be chmod 0600
to be considered trusted.

To see if your .netrc config works in general, you could try
$ curl -n https://review.coreboot.org/a/accounts/self/avatar.change.url

which should return something like:

)]}'
"https://doc.coreboot.org/community/services.html#gerrit-user-avatar;

If you get "Unauthorized", there's some issue with your configuration.

$ curl -vvvn https://review.coreboot.org/a/accounts/self/avatar.change.url
will give you more details (but beware when posting that output, it
contains the password with _very_ light scrambling: remove the base64 stuff
in the "authorization" line before showing anybody).

(And sorry: I've been meaning to make this a whole lot more user friendly
for a long time, but other issues keep popping up)

Since this is likely a configuration issue, I moved the list to bcc to keep
the noise down. If there's some resolution of this that warrants wider
publication, we can still do so later.

Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning coreboot 4.11

[Patrick Georgi via coreboot]

On Mon, Nov 04, 2019 at 09:30:34AM -0500, Patrick Georgi wrote:
> I'm planning to release coreboot 4.11 two weeks from today, Nov 18th.
This has been deferred to tomorrow, Nov 19th.

My basic functionality tests with current master are looking good,
but there are two issues for which I'm trying to get fixes in. While
we don't guarantee anything for our releases, experience shows that
people use them nonetheless as golden master, so let's get the tree
as stable as possible before tagging.

To reiterate, 4.11 will be master as of now + a few commits that are
yet to land. I'd appreciate if we could keep the tree stable for the
next 20-ish hours :-)

> - Fill in any notable developments since 4.10 in
>   Documentation/releases/coreboot-4.11-relnotes.md
This call to action worked really well. Thanks everybody for filling
in various blanks.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Announcing coreboot 4.11

[Patrick Georgi via coreboot]

It's my pleasure to announce that coreboot 4.11 was just released.

Release notes follow. Note that there are deprecations listed that will
be in effect immediately. The first two (Fam12 and MIPS) probably don't
affect anybody, but the third item has quite a lot of ripple effect.

I was considering giving affected platforms a chance until the end
of this year but that carries the risk that the deprecation will be
postponed even longer. While these platforms will be removed soon
(patches to that end are appearing on review.coreboot.org) we'll
be very happy to welcome them back as soon as they're brought up
to current standards. If this is done soon, the difference between
the trees won't be significant so the amount of extra work should
be reasonable.


Regards,
Patrick


--- release notes ---

This release cycle was a bit shorter to get closer to our regular
schedule of releasing in spring and autumn.

Since 4.10 there were 1630 new commits by over 130 developers.
Of these, about 30 contributed to coreboot for the first time.

Thank you to all contributors who made 4.11 what it is and welcome
to the project to all new contributors!

Clean Up


The past few months saw lots of cleanup across the source tree:

The included headers in source files were stripped down to avoid reading
unused headers, and unused code fragments, duplicate preprocessor symbols
and configuration options were eliminated. Even ACPI got its share
of attention, making our tables and bytecode more standards compliant
than ever.

The code across Intel's chipsets was unified some more into drivers for
common function blocks, an effort we're more confident will succeed now
that Intel itself is driving it.

Chipset work


Most activity in the last couple months was on Intel support,
specifically the Kaby Lake and Cannon Lake drivers were extended
for the generations following them.

On ARM, the Mediatek 8173 chipset support saw significant work while
the AMD side worked on getting Picasso support in.

But everything else also saw some action, the relatively old
(e.g. Intel GM45, Via VX900), the tiny (RISC-V) and the obscure
(Quark).

Verified Boot
-

The vboot feature that Chromebooks brought into coreboot was extended
to work on devices that weren't specially adapted for it: In addition
to its original device family it's now supported on various Lenovo
laptops, Open Compute Project systems and Siemens industrial machines.

Eltan's support for measured boot continues to be integrated with
vboot, sharing data structures and generally working together where
possible.

New devices
---

With 4.11 there's the beginning of support for Intel Tiger Lake and
Qualcomm's SC7180 SoCs, while we removed the unmaintained support
for Allwinner's A10 SoC.

There are also 25 new mainboards in our tree:

* AMD PADMELON
* ASUS P5QL-EM
* EMULATION QEMU-AARCH64
* GOOGLE AKEMI
* GOOGLE ARCADA CML
* GOOGLE DAMU
* GOOGLE DOOD
* GOOGLE DRALLION
* GOOGLE DRATINI
* GOOGLE JACUZZI
* GOOGLE JUNIPER
* GOOGLE KAKADU
* GOOGLE KAPPA
* GOOGLE PUFF
* GOOGLE SARIEN CML
* GOOGLE TREEYA
* GOOGLE TROGDOR
* LENOVO R60
* LENOVO T410
* LENOVO THINKPAD T440P
* LENOVO X301
* RAZER BLADE-STEALTH KBL
* SIEMENS MC-APL6
* SUPERMICRO X11SSH-TF
* SUPERMICRO X11SSM-F

In addition to the Cubieboard (which uses the A10 SoC), we also
removed Google Hatch WHL.

Deprecations


Because there was only a single developer board (AMD Torpedo)
using AGESA family 12h, and because there were multiple,
unique Coverity issues with it, the associated vendorcode will
be removed shortly after this release.

Support for the MIPS architecture will also be removed shortly after
this release as the only board in the tree was a discontinued development
board and no other work has picked up MIPS support, so it's very likely
broken already.

After more than a year of planning and following the announcement in
coreboot 4.10, platforms not using relocatable ramstage, a C bootblock
and, on systems using Cache as RAM, a postcar stage, won't be supported
going forward.

Significant changes
---

### `__PRE_RAM__` is deprecated

Preprocessor use of `defined(__PRE_RAM__)` have been mostly replaced with
`if (ENV_ROMSTAGE_OR_BEFORE)` or the inverse `if (ENV_RAMSTAGE)`.

The remaining cases and `-D__PRE_RAM__` are to be removed soon after release.

### `__BOOTBLOCK__` et.al. are converted

This applies to all `ENV_xxx` definitions found in ``.

Write code without preprocessor directives whenever possible, replacing
`#ifdef __BOOTBLOCK__` with  `if (ENV_BOOTBLOCK)`

In cases where preprocessor is needed use `#if ENV_BOOTBLOCK` instead.

### `CAR_GLOBAL` is removed where possible

For all platform code with `NO_CAR_GLOBAL_MIGRATION=y`, any `CAR_GLOBAL`
attributes have been removed. Remaining cases from common code are to be
removed soon after release.

### `TSEG` and  `cbmem_top()` mapping

Significant refactoring has bee done to achieve some consistency across 

[coreboot] Re: Coverity

[Patrick Georgi via coreboot]

On Sun, Nov 24, 2019 at 11:00:00AM +, awokd via coreboot wrote:
> Could a Coreboot Coverity admin please re-run the scan against master?
Done.

> Looks like the last analyzed version was from Sep 24, 2019. I would like
> to see what AGESA issues remain.
Thanks for the heads-up!

I'm not quite sure what happened there, we should get updated 3 times
a week but for some reason the service didn't accept the new data
jenkins pushed at https://qa.coreboot.org/job/coreboot-coverity/


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: AMD Agesa Bettong board support

[Patrick Georgi via coreboot]

Am Do., 5. Dez. 2019 um 12:16 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:

> > You can try setting up SSH key on the gerrit account and change the git
> remote to SSH instead of HTTPS.
> Sorry, we only have access to http/https ports... maybe I have a
> certificate's problem...
>
Have you set up an account on review.coreboot.org yet?

While we provide a read-only mirror on github for the code repos, board
status uploads have to happen on our infrastructure.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?

[Patrick Georgi via coreboot]

Nico Huber via coreboot  schrieb am So., 26. Jan.
2020, 02:07:

> Hello again,
>
> so, we have Jenkins that runs build tests on our master branch. That
> makes working together on a huge project much easier. However, do we
> have a rule that all the code should be build tested? and if not,
> should we establish one?
>
The general rule of thumb is to build test everything in the tree. We're
not doing that in a few cases, among them stuff behind default-off kconfig
flags, but I think we should strive for improvement.


> I've recently seen how much trouble it can cause when a whole new
> platform directory isn't hooked up for build tests. One has to double
> check every patch touching a file there. If in doubt, even run manual
> tests. That's a huge burden not only during development but also for
> reviewers. A burden that Jenkins would be happy to take if we let him.
> And even if people try to take care, they're just people, the untested
> code will break eventually.
>
> 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.

Then, if anything goes wrong, and it's still not hooked up after 24h,
> revert it.
>
> How about that?
>
How about this: we allow utterly incomplete mainboards in, if they're
hidden behind some flag. Abuild and Jenkins build these, regular users
don't even see them.

Maybe even in a designated area within src/mainboard? "Staging" perhaps?

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.


Regards,
Patrick

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

[coreboot] Re: Discussing Controversial Upstreaming

[Patrick Georgi via coreboot]

Hi Marshall,

thanks for that cohesive report and insight into your development process
and the trade-offs involved.

Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson <
marshalldawson...@gmail.com>:

> Instead, please give me the opportunity to review any of your changes that
> touch the picasso directory. If I have any concerns of building, I can test
> and run it locally, recommend solutions, etc.  We can expect a few problems
> to slip through that process, which I will immediately discover prior to
> repushing my subsequent work. I will fix it, and allow you to review that
> work. I am also committed to converting anything resembling a fork to
> amd/common where it makes sense, and when the development priorities
> allow.  The instant that mb/amd/mandolin lands, it will no longer be
> work-in-progress and it will undoubtedly build successfully.
>
Should we add stub mainboards for new chipsets that build the code as a way
to make sure nobody else inadvertently breaks things (at least not too bad)?
While it's reassuring to know that you intend to keep track of these things
and sort them out, that would help other developers do changes with more
confidence that they won't leave a huge mess in a hard-to-test area of the
tree.

Ironically, I could have commonized the SMBus feature several times over
> within the time we’ve had this discussion.  I feel this is an important
> topic, however, so thank you for indulging me. Although I still won’t
> reprioritize this work ahead of what I promised to my stakeholders, I
> believe the time discussing this was valuable.
>
I'm quite sure that you won't forget all the little places that you intend
to clean-up down the road. Would it help to document these somewhere, e.g.
as issues on ticket.coreboot.org? Both for helping you keep track of things
and to state publicly what you've postponed (so you don't have to argue
every time somebody else gets the same idea that there's something that
could be deduplicated).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[Patrick Georgi via coreboot]

On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
> having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
> especially if it were to select less common/non-default options that other
> in-tree boards don't select by default, to ensure full coverage of all SoC
> options.
I think for non-default options, having more specimen of real world examples
in configs/ is better simply because that means that we're optimizing for
real-world configurations.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Workflows and Guidelines

[Patrick Georgi via coreboot]

Hi everybody,

one thing that became clear to me in the recent (and not-so-recent)
discussions broadly related to coding style, code duplication, code
submission strategies, documentation requirements and similar things
is that there have to be many different styles of approaching coreboot
development out there.

As David said:
> 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.

We can only avoid making unfeasible demands on other people's workflows
if we know these workflows. Developers might also benefit from guidelines
telling them how to approach certain projects.

On the other end, there's not really a standard on how we review things:
For example some people (I belong to that crowd) tend to accept stuff
that is part of active development (and for example have a long set of
commits on top), even if there are minor issues left (that look like
they create tons of patch handling work if fixed in the base commit of
the patch train), on the understanding that people follow up on comments
with later commits. Others seem, at times, to be rather close to give such
a change a -2 review until it's perfect and all comments are addressed
in that very commit.

Which approach is right? I don't know. (And therein lies the problem)

There are other points of disagreement in review style, and having
unspoken assumptions be in force with some reviewer but not with others is
a doubly confusing experience: we shouldn't expect things without stating
them (but for the reviewer they probably appear to be natural) and the
varying style means that every review can be a whole new experience full
of surprises.

So here's something I'd really love to do, but lack the time for:

 - Interview developers in all kinds of contexts (hobbyists, corporate,
   and so on) about how they work and what their constraints are
 - Interview reviewers on what they consider important, how they work
   and what they look for
 - Document all that, coalescing common pieces
 - Draft guidelines that bring the workflows (or variations thereof
   that the developers agree can be implemented on their part) in line
   with the review requirements and vice-versa.
 - Iterate on the guidelines until there's rough consensus

The idea isn't to create some legal text to wield as a weapon during
review ("§3 says that I can do it this way!" "but §7.a.5 says that you
mustn't in this particular case!"), but to establish a baseline for common
understanding when working on the code we all care for in this project.

Such an effort probably takes half a year or longer (not full time,
but catching up with folks, and rewriting draft after draft accumulates)
and that's sadly nothing I can offer right now or in the near future.

But, if there's somebody in the community wondering how they could
participate, thinking that this is a useful endeavour and that it's just
their cup of tea, that project is for the taking.

(Or maybe this is just a stupid idea of mine)

Beware though: the "Iterate" step looks short and simple in this text
but it won't be since you'll have to reconcile all the forces pulling
at the text.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
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?

[Patrick Georgi via coreboot]

Am Di., 28. Jan. 2020 um 08:03 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:

> 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.
>

Right, but it means that there's less of a risk of API changes across the
tree (that happen all the time) throwing bring-up projects off-track.
I mean, these stubs don't have to _do_ anything useful, they merely have to
present themselves as just good enough to the build system to put all
source code through the grinder^Wcompiler.

I'd expect all developers to have _some_ kind of board set up for their SoC
because otherwise how do they test the SoC code in the first place? (I
assume it is tested, at least to some degree)
Maybe it's good enough to push these early, potentially anonymized plus
some signifier that they're stubs? Not sure if that's practical in all
existing workflows, but I'll leave that to a separate thread.

I suppose we could look into having jenkins throw out a warning if a source
file (*.c or *.h) wasn't touched during the build. That might be a good
exercise in any case to see what the situation looks like right now.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discussing Controversial Upstreaming

[Patrick Georgi via coreboot]

David Hendricks  schrieb am Mi., 29. Jan. 2020,
00:51:

> 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.
>
That may have been necessary in the era of the fdiv bug but I'm not sure
this trope is still applicable to today:

The concern is that something outside Intel's control reflected badly onto
Intel, but our industry seems fully exempt of consequences (except for
revenue being in the up and up) even when participants are fully
responsible that I don't know how this can be true:

Take Intel, their chips make news every few weeks because another side
channel attack was discovered and besides some (probably uncomfortable)
news cycle the only results seem to be that they still sell chips faster
than they can produce them and that they provide workarounds that reduce
performance by, I think, 25% (and counting) less than what people paid for?
Meanwhile Intel's quarterly reports look fabulous.

And this issue is by no means Intel specific, the entire industry managed
to somehow replace responsibility with a short uncomfortable news cycle
that is forgotten 24 hours later.
No matter if hardware, software (what other paid product requires monthly
maintenance cycles?) or even users (who opt to not even do that maintenance
and instead pretend that any malware they suffer from is a force of nature
instead of pain old neglect), there just are no consequences.

And now we need to prevent users from whining at the wrong folks with
something as drastic as remote shocks? Something doesn't seem to add up.


Patrick

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

[coreboot] Re: "Delete change" Gerrit feature does more harm than good

[Patrick Georgi via coreboot]

Am Do., 9. Jan. 2020 um 06:46 Uhr schrieb Mike Banon :

> It would be nice if the deleted commits get moved to some archive
> outside of Gerrit instead of being simply removed, to ensure that if
> anyone else is interested in these commits, they could be restored.

That's not easily done and I guess there are higher priority issues we need
to deal with in our infrastructure.

That said, there's
https://mail.coreboot.org/hyperkitty/list/coreboot-ger...@coreboot.org/ which
contains a full set of changes that you can download as an mbox mail
archive containing the patches, and you can subscribe to get future changes
sent to your mail server.

In example, if your Gerrit gets hacked, or simply forgot to log out on
> another PC and someone malicious removed a few changes, there should
> be a guaranteed way to restore them.
>
If Gerrit gets hacked, the hacker could just as well do the removal for
good. To deal with such a threat, we need to rely on separate
infrastructure. To deal with critical events, we have nightly backups of
the server's data stored on multiple separate machines (in a different
location), keeping the latest few weeks around. Therefore as long as issues
are discovered reasonably quickly, we can recover things that were kept on
our infrastructure for more than 24 hours.

As for the threat of somebody abusing an open session, we restrict the
lifetime of a gerrit session to guard against that, but we can't make it so
short that it annoys active developers.

Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Initial mainboard commit - minimal requirements and completion criteria

[Patrick Georgi via coreboot]

Am Fr., 6. März 2020 um 12:15 Uhr schrieb Piotr Król :

> If the community keeps our reviews not merged, we
> cannot use that as proof of our engagement and quality.

 [...]

>  This doesn't contribute to project health.
>
Indeed. Looking into Gerrit, we have >1000 commits open for coreboot.

Some of our patches got no attention for over 1.5 years.
>
Most Gerrit views are sorted by last change date, so often it already
helps to rebase to master to bring it in front of reviewers again.


> What we are asking is a decision about those patches - if anything is
> wrong we will fix that.
>
That's fair. As said, we have a rather big backlog, and to me that
indicates that we should look into ways to reduce that, and keep things
actionable (and with clear responsibility who's next: author, reviewer, ...)
There's development going on with Gerrit that should assist that, and there
are a few more ideas floating around in a different context that could also
help here, but whatever we can improve in infrastructure, we still need to
use it.

We believe this is a little bit bigger problem that should be addressed
> by coreboot leaders since it reflects the healthiness of the community
> and agenda of participating entities.
>
I put the topic on the agenda for tomorrow's leadership meeting (
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit

)


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Seeking mentors for Google Summer of Code 2020

[Patrick Georgi via coreboot]

Hi everybody,

since we're invited to participate in this year's GSoC and since students
can send their project proposals starting next week, I guess now is the
time to register potential mentors with the system, so we can triage and
assign proposals efficiently.

If helping a student get up to speed with coreboot development and open
source development in general sounds like a great way to spend your time
to you, please consider mentoring!

Note to potential student participants: There's a conflict of interest
in being both a student and a mentor and so GSoC doesn't allow that. If
you consider joining GSoC as a student (for any participating open source
project) this year, don't ask to become a mentor.

Our expectations of a mentor are:
- Being around for most of mid of March (when the applications rush in) to
  mid of August (when everything wraps up)
- Work with the student to build a realistic project plan
- Being the point of contact for a specific student working on a
  specific project from mid of May to mid of August
- Following up on their student's progress and helping them along.
  This usually means:
  - One or more sync meetings with the student every week (schedule is
up to you and your student to sort out)
  - Being available for helping them when they get stuck
  - Encourage them to participate in the community. Students with no
prior OSS experience are often a bit shy, and a big part of GSoC
is to help them get into it. This depends on the student, but can
involve being their wingman on IRC, encouraging them to push code
for review early and go through the feedback they get together
(it often looks scary for new-comers)
- 3 evaluations of the student's progress (in mid-June, -July, -August)

If that time frame covers a week or two of down time (vacation etc), we
can likely handle that (but it helps to know about scheduled off-time
in advance!) If it's more, maybe there should be more than one mentor
to your student. If you're dropping out due to some unforeseen event,
that's on David Hendricks and I (in our function as org admins) to sort
out, finding a replacement or jumping in ourselves.

If you're interested, feel free to send me a private email and we'll
take it from there.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Google Season of Docs

[Patrick Georgi via coreboot]

Hi everybody,

we just had our project leadership meeting and I brought up the Google
Season of Docs[0] programme which is similar to Summer of Code but
for documentation.

(Note to meeting attendants: I mentioned that the application deadline
for projects has already passed, but I was wrong about that. According
to the timeline[1] we have until May 4 to decide.)

The programme's goal is to connect Open Source projects (like coreboot)
with technical writers and if there's one thing coreboot can benefit
from, I'd say it's having somebody who knows what they're doing write
documentation for the project.

There was some interest in having coreboot take part there, but it
requires at least two project admins (people willing to coordinate)
and also mentors for the tech writers (if there's interest on their
side to work with coreboot), which may or may not overlap with the
project admins.

I'm not sure I can do a good job managing both Summer of Code and
Season of Docs (which overlap timewise), but there was nobody else
able to step up.

So: What's the interest for this in the wider community and do we
have people who could imagine organizing our participation there?

The first step would be to dig into their application procedure,
and I guess I could help a bit there (if it's at all similar to
Summer of Code's). If they don't take us, we'd drop out early May,
otherwise admin work seems to require some attention until December.


Regards,
Patrick

[0] https://developers.google.com/season-of-docs
[1] https://developers.google.com/season-of-docs/docs/timeline
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Adding unit testing to the tree

[Patrick Georgi via coreboot]

Hi everybody,

There's some fine work by Jan on Gerrit on the issue of adding unit testing
infrastructure to our tree and I'd like to see it merged soon.

So far, most feedback was by Google folks so this is a heads up for
everybody (and especially those not at Google) to take a look and offer
your input.

The design doc, build infra and demonstration test cases can be found at
https://review.coreboot.org/39893 and the commits that are based on it.

I aim for inclusion near the end of the week unless there's feedback
showing weaknesses in the plan or implementation.


Thanks,
Patrick
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Planning the next coreboot release

[Patrick Georgi via coreboot]

Hi everybody,

it's that time of year again: we should look into cutting a
release. Not because there's anything noteworthy that we should bring
out (although there certainly is), but because we have a 6-monthly
cadence of giving our tree a new number and pushing out tarballs and
press releases.

I plan to do the release on or shortly after May 11, and
this announcement is in accordance to the process detailed on
https://doc.coreboot.org/releases/checklist.html, so we're at the
"~2 weeks prior to release" point right now.

As such, there are a number of things I ask of you (all of you
subscribed to the list, but since you're reading this mail, yes,
I mean you, personally!):

1. If you have anything big that you want to get in before the release,
it's on you to maintain the changes responsibly and responsively so
that it all works out in time. I'll gladly help coordinate things
but I'm not interested in last-minute heroics, so get in touch with
me ASAP.

2. Please try to postpone riskier refactorings and the like until after
the release (unless they're ready to land in the next few days), so
that people have a solid foundation to test their hardware on. Which
gets us to the next point:

3. Please test your coreboot-supported gear if you can, report and/or
fix issues, and upload fresh reports to the board-status repo. While
we have no quality requirement for releases - they're _really_ only
about giving the tree a new number, a release is a good opportunity
to verify that what we have in the tree is still functional, with
only limited work required to pin-point new issues (bisections since
4.11 should take 12 steps or less at this time).

4. Please check the preliminary release notes in
Documentation/releases/coreboot-4.12-relnotes.md and add whatever
happened since 4.11 that you think is noteworthy. If in doubt, push
a change to gerrit and see what your fellow developers think about it.


Thanks,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus P5Q experience

[Patrick Georgi via coreboot]

Hi Eduardo,

Am Mo., 11. Mai 2020 um 03:24 Uhr schrieb edbatalha--- via coreboot <
coreboot@coreboot.org>:

> About 2 months ago I discovered that it is supported by coreboot so I
> thought it would be fun to experiment with it.
>
Well, welcome!


> 2)
> I then decided to try out Windows XP but the Installation would stop with
> STOP: 0xA5 (0x11, 0x8, ... .. .,  ).
> I could not figure it out...
> Then I used a usb pen with "Active Boot Disk 9.4" in it, based on
> WindowsPE / Windows7.
> For that I got STOP: 0xA5 (0x1000, 0x0, 0xFFF0, 0x40) and that
> actually provided a clue.
>
Stop 0xa5 codes are under documented by Microsoft, but we collected
whatever we could find about them at https://coreboot.org/ACPI#STOP_0xa5 (it
helped to attach windbg to a crashing Windows install that came with debug
symbols).

Your error is listed in our collection: "Parameter1 == 0x1000 means
that some memory resource is claimed by ACPI that, according to memory
tables, belongs to the OS. Parameter3 is the start address, Parameter4 is
the length of the range".
Now, "0xFFF0, 0x40" looks _very_ odd. 0xFFF0 is the 16bit cpu
entry vector, and the size given doesn't really fit that, and there isn't
really any other purpose to those 16 bytes, while it's also odd to reserve
4MB-16bytes above 4GB to anything.

I searched in the ACPI tables and found this in the x4x.asl file
> ...
> OperationRegion (GFRG, SystemMemory, And (BAR0, 0xfff0),
> 0x40)
>
Note the And(), so this would give you these values only if BAR0 is
0x.

The best approach may be to boot into Linux (which doesn't fail that hard,
right?) and dump ACPI tables there so we can see what's going on (as some
parts are generated at runtime, so it's not enough to look at the source
code only).
If you put that stuff up somewhere, I'm sure that there will be folks
interested to look into the issue (I am for sure).

5) None of the secondary payloads coreinfo, nvramcui and Memtest86+ worked
> for me.
> I managed to get Memtest86+ working by selecting the "Master" version but
> did not investigate any further.
>
There's a known issue between memtest's stable version and our toolchain.
Since master works for you, that seems good enough.

As for the others, how do they fail for you?

6) I tried to follow the "coreboot Overview" in
> https://www.coreboot.org/Developer_Manual but found it difficult, the
> crt0_romcc_epilogue.inc for example does net exist in the source tree. Is
> there any other updated overview somewhere else?

The current documentation is at doc.coreboot.org, which is generated from
the Documentation/ folder.
https://doc.coreboot.org/getting_started/architecture.html has a few words
about the codeflow, but not at file granularity.

I hope it's ok to report issues to the mailing list like this, apologies
> for the long email.
>
Sure! Another option would be to create issues for them on
ticket.coreboot.org.


Thank you for the detailed report!
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Resource allocator: multiple boards regression

[Patrick Georgi via coreboot]

Peter Stuge  schrieb am Sa., 16. Mai 2020, 15:39:

> Holy moly..
>
Indeed...

All I could find was "prepare for 64 bit resources". That is beyond weak.
>
To people dealing both with somewhat modern hardware and coreboot, it is
well known that the resource allocator has a few crucial weaknesses in that
area. See, for example, review.coreboot.org/12575 which tried to merely
work around the issue in 2015.

Even worse, I also could not find any explanation of how the new algorithm
> is different from the old, neither in commit messages nor in comments.
>
That may belong in the commit message but certainly not in any comments in
the tree.

I am so relieved that I don't invest heavily in coreboot anymore because
> I would be furious if I did, not to mention how I would feel if I had been
> contributing significantly to the existing, working algorithm.
>
Have you looked at the type of contributions to the resource allocator in
the last 2 years? Some fixes for sure but "significant contributions", not
so much.

If anything this was because the allocator is a pretty hairy beast that
nobody dared to come closer than strictly necessary. That seems to be the
one unifying property of resource allocators by the way, given that the
last rewrite had a similar genesis.

This is obviously the classic conflict between one strong contributor
> working toward their special interest (enable particular future work)

Like allowing dGPUs that announce several gigs of on board RAM, or
thunderbolt or USB4, yes. Highly special interests, indeed. (A few of them
that Furquan's project doesn't even care about).

(do not break a working core algorithm).
>
I guess, if anything, you can complain to me about that: after all, I was
the person who submitted that to master and who also held off on reverting
it because I see value in getting that thing in.

We should not take for granted that our own stuff is the most important,
> but rather the other way around.
>
I'd treat grandiose organizational psychoanalysis on public forums the same
way but I guess everybody has their vice:

suggests to me that something isn't right
> in Google's coreboot team. The classic problem would be that there are
> some impossible (time) constraints, which just ends up being really toxic.
> :\
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [GSoC] Self Introduction

[Patrick Georgi via coreboot]

Hi Sindhoor,

Welcome to coreboot!

Would you mind spending a few words on what you'll be working on? It's
something about POST codes but there's little more than that available
about your project, and there has been some interest in your work already.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Planning the next coreboot release

[Patrick Georgi via coreboot]

Hi again,

A while I ago I announced my intent to do a new coreboot
release. This is slated to happen next Monday, so we're now at
the "~1 week prior to release" point of our release checklist (at
https://doc.coreboot.org/releases/checklist.html).

So as a reminder: Please test the devices you have with master, fix
(or at least report) regressions you encounter, propose additions
to the release notes and generally try to make sure that the release
looks like you want it to look.

Again, consider postponing risky changes to avoid shaking up things
for your fellow co-developers and users.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Documenting changes and so on

[Patrick Georgi via coreboot]

Hi everybody,

during last week's issue with the resource allocator there have been some
remarks about how the change seemed practically invisible despite being on
Gerrit for 2 months and some people suggested that it would be useful to
have better documentation with such changes on why they're done and what
the former situation has been.

I created https://review.coreboot.org/c/coreboot/+/41493 to add this aspect
to the reviewing guidelines, to remind contributors to document and to
invite feedback on the mailing list; to provide suggestions to contributors
where such documentation could end up; and also to make sure that reviewers
feel empowered to ask for more docs and/or discussion (by pointing at the
guidelines if necessary).

I hope this allows improving our review culture so that things don't fall
through the cracks in the future (or at least, less often) without becoming
too rigid (please do not use this section to demand typo fixes discussions
on the list, please ;-) )

Please take a look, comment, disagree, and so on.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Announcing coreboot 4.12

[Patrick Georgi via coreboot]

Hi everybody,

I just release coreboot 4.12, with release notes as follows:

Since 4.11 there were 2692 new commits by over 190 developers and of
these, 59 contributed for the first time, which is quite an amazing
increase.

Thank you to all developers who again helped made coreboot better
than ever, and a big welcome to our new contributors!

Maintainers
---

This release saw some activity on the MAINTAINERS file, showing more
persons, teams and companies declare publicly that they intend to
take care of mainboards and subsystems.

To all new maintainers, thanks a lot!

Documentation
-

Our documentation efforts in the code tree are picking up steam, with
some 70 commits in that general area. Everything from typo fixes to
documenting mainboard support or coreboot APIs.

There's still room to improve, but the contributions are getting more
and better.

Hardware support


The removals due to the announced deprecations as well as the
deduplication of boards into variants skew the stats a bit, so at
a top level view this is a rare coreboot release in that it removes
more boards (51) than it adds (49).

After accounting for the variant moves the numbers in favor of more
hardware supported than the previous version. Besides a whole lot
of Chrome OS devices (again), this release features a whole bunch
of retrofits for devices originally shipping with non-coreboot OEM
firmware, but also support for devices that come with coreboot right
out of the box.

For that, a shout out to System76, Protectli, Libretrend and the
Open Compute Project!

Cleanup


We simplified the header that comes at the top of every file:
Instead of a lengthy reference to the license any given file
is under, or even the license text itself, we opted for simple
[SPDX](https://www.spdx.org) identifiers.

Since people also handled copyright lines differently, we now opt for
collecting authors in AUTHORS and let git history tell the whole story.

While at it, the content-free "This file is part of this-and-that
project" header was also dropped.

Besides that, there has also been more work to sort out the headers
we include across the tree to minimize the code impacting every
compilation unit.

Now that our board-variant mechanism matured, many boards that were
individual models so far were converted into variants, making it
easier to maintain families of devices.

Deprecations


For the 4.12 release a few features on x86 became mandatory. These are
relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK.

### Relocatable ramstage

Relocatable stages are a feature implemented only on x86, where stages
can be relocated at runtime. This is used to place ramstage in a better
location that does not collide with memory the OS or the payload tends
to use. The rationale behind making this mandatory is that you always
want cbmem to be cached so it's a good location to run ramstage from.
It avoids using lower memory altogether so the OS can make use of it
and no backing up needs to happen on S3 resume.

### Postcar stage

With Postcar stage tearing down Cache-as-Ram is done in a separate
stage. This means that romstage has a clean program boundary and
that all variables in romstage can be accessed via their linked
addresses without runtime resolution. There is no need to link
global and static variables via the CAR_GLOBAL macro and no need
to access them with car_set/get_var/ptr functions.

### C_ENVIRONMENT_BOOTBLOCK

Historically the bootblock on x86 platforms has been compiled with
romcc. This means that the generated code only uses CPU registers
and therefore no stack. This 20K+ LOC compiler is limited and hard
to maintain and so is the code that one has to write in that
environment. A different solution is to set up Cache-as-Ram in the
bootblock and run GCC compiled code in the bootblock. The advantages
are increased flexibility and consistency with other architectures as
well as other stages: e.g. printing to console is possible and
VBOOT can run before romstage, making romstage updatable via RW FMAP
regions.

### Platforms dropped from master

The following platforms did not implement those feature are dropped
from master to allow the master branch to move on:
- AMDFAM10
- all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY
- VIA VX900

In particular on FSP1.0 it is impossible to implement POSTCAR stage.
The reason is that FSP1.0 relocates the CAR region to the HOB before
returning to coreboot. This means that after FSP returns to coreboot
accessing variables via their original address is not possible. One
way of obtaining that behavior would be to set up Cache-as-Ram again
(but with open source code) and copy the relocated data from the HOB
there. This solution is deemed too hacky. Maybe a lesson can be
learned from this: blobs should not interfere with the execution
environment, as this makes proper integration much harder.

### 4.11_branch

Given that some platforms supported 

[coreboot] Re: [GSOC] Query regarding proposals

[Patrick Georgi via coreboot]

Hi Sindhoor,

Am Di., 24. März 2020 um 08:19 Uhr schrieb Sindhoor Tilak <
sindh...@sin9yt.net>:

>This is my first time here applying for GSoC.
>
> I'm interested in couple of ideas posted. I wanted to know if multiple
> proposals are accepted?
>
If you have multiple proposals, feel free to offer them. That helps us
distribute proposals across students in case students propose doing the
same project and it's nothing we could split in two (GSoC doesn't want
students to work on identical topics because that just doesn't make sense).
However, we expect students to provide some amount of detail on their plans
(e.g. a schedule that they'll try to follow if the project is accepted), so
don't stretch yourself too thin: your chances will be better with 1 or 2
great proposals rather than 5 mediocre ones.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] Proposal to move all FSP 1.x binaries to "legacy" branch

[Patrick Georgi via coreboot]

Am Fr., 4. Sept. 2020 um 10:56 Uhr schrieb Nico Huber :

> I would expect the opposite. At least for all coreboot revisions that
>
use a Git submodule. Those point to commits, not branches, and hence
> should always work as long as the branch history is kept in tact
> upstream.
>
Indeed: As long as there's no git history rewriting involved, the branches
will just continue to work because they point to commit ids.

Nate, if there's strong interest in retiring binaries (although that will
only reduce download size for shallow clones, so I'm not too sure what's
the point), could you keep FSP 1.1 around and just retire FSP 1.0?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Should coreboot.org provide a vendor-agnostic hub for open hardware projects?

[Patrick Georgi via coreboot]

Hi everybody,

I heard about a project interested int creating coreboot compatible
open hardware. While that effort isn't ready to make any announcement,
questions came up about where to host such a project.

There's lots of open hardware out there already, but it's often
based on not-quite open base boards so there seems to be a hole in
the ecosystem approximately the shape of open hardware designs that
could serve as base for hardware of all sizes (SBC alikes to put
"shields" on, laptop/desktop designs that can be customized, maybe
even servers, ...)

That's where coreboot.org might come in: When I brought up the question in
today's leadership meeting, people were generally interested in having
coreboot.org host projects like that.

The idea isn't to create "coreboot branded" hardware, because that
makes as much sense as "UEFI branded" hardware (that is, none), but to
provide a place where people can cooperate on and publish open hardware
designs that are complex enough to require coreboot-style firmware.


Thoughts?
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Should coreboot.org provide a vendor-agnostic hub for open hardware projects?

[Patrick Georgi via coreboot]

On Thu, Sep 24, 2020 at 01:06:13PM +0200, Christian Walter wrote:
> what does "coreboot compatible open hardware" means here? Do we have
> some kind of specification for this or does that "just" means no blobs
> at all?
No specification as yet, I wrote that email with the intent to start
a discussion that may lead to a spec :-)

As for what "coreboot compatible" means: I think hardware designs
hosted on coreboot.org should be able to run an upstream coreboot
build. Depending on how you look at it, the terminology might not be
entirely right: It may be more correct to say that coreboot has to
be compatible with open hardware designs that we host (and that we
expect the open hardware maintainer to ensure that.)

The only exception might be firmware development related tooling, if
we were to create a subproject with a wide mandate that also covers
such "related tools" like a SPI mux board. If we should do that is
another open question, by the way - but more of a follow-up.

> I would think that we can definitely host such a projects, give it a
> gerrit, docs and stuff - but I would be aware of leveraging resources
> for this. I don't think that we should promote this in any way or brand
> it as coreboot compatible open hardware.
If we were to host projects that are open hardware implementations
of parts that are traditionally (with only a few notable exceptions)
closed (such as SBCs, laptop/desktop/server mainboards), why shouldn't
we promote them?

And if they run coreboot, why shouldn't we say that? (I'm not saying
that open hardware designs should come with our Hare logo on the
silk screen)


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Unit tests are now live on our build infrastructure

[Patrick Georgi via coreboot]

Hi everybody,

Just a quick heads up: the unit tests in tests/ are now built and run on
every commit pushed to review.coreboot.org.

Consider this a good opportunity to improve our stability by contributing
tests! Jan is writing a tutorial on writing tests that you can find for now
at review.coreboot.org/41727.

If anything is unclear with the tutorial, don't hesitate to comment on the
change.


Regards,
Patrick
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Self-describing CBFS features - prefixed config and revision files

[Patrick Georgi via coreboot]

Am Di., 2. Juni 2020 um 17:50 Uhr schrieb Jeremy Jackson :

> Below is a patch that does what I want for one of the points I
> mentioned.  Comments?  Does this interfere with a different use case?
>
I'd say that change is reasonable. Care to push it to review.coreboot.org
or should somebody else (e.g. I) take over?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Issue-Tracker: Unable to reply

[Patrick Georgi via coreboot]

On Wed, Jul 08, 2020 at 06:51:41PM +0200, Daniel Kulesz via coreboot wrote:
> I wanted to reply in the Redmine issue tracker to a comment posted
> by Patrick Georgi [1], however, it seems like I can only open new
> issues and edit my own issue as well but not comment or reply to
> comments. At least I don't see any button for that. Is this a general
> permission issue (regarding roles) or is this specific to my account
> (kuleszdl) there?

I just checked and I found nothing special in the redmine user database
that would preclude you from creating comments to existing issues.

The comment/reply functionality is considered an "edit". You _should_ see the
edit link on that change, and that should get you the comment box.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: I just tried to download from the repo a completely new tree it gave an error

[Patrick Georgi via coreboot]

Am Mo., 15. Juni 2020 um 22:27 Uhr schrieb Gregg Levine <
gregg.drw...@gmail.com>:

> Initialized empty Git repository in /usr/src/lobos/work4/coreboot/.git/
> fatal: https://review.coreboot.org/coreboot.git/info/refs download
> error - The requested URL returned error: 406
> root@pike7:/usr/src/lobos/work4# clear
> root@pike7:/usr/src/lobos/work4# git --version
> git version 1.6.1.3
> root@pike7:/usr/src/lobos/work4#
>
> And that's my Git version. Last time I had Slackware-12.2 up it did work.
>
That git version is from 2009. The world didn't stop turning.
It's surprising enough that your system has support for sufficiently new
SSL that it could receive that HTTP error instead of already failing at the
SSL handshake.

tl;dr: update your system.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Supporting blobs with licenses that you agree to on download

[Patrick Georgi via coreboot]

Am Mi., 17. Juni 2020 um 02:47 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> Patrick, any further concerns from your side? If not, would you mind
> creating a new repository for this? I can write the patches to move
> blobs and adjust the Makefiles afterwards.
>
I will create a repo for the qc stuff (let's discuss the details offline),
but also started writing up some clarifications for the blobs repo at
https://review.coreboot.org/c/blobs/+/42476

I think in the long term we might do best by having two licenses on blob
contributions: their regular license agreement and a
download+redistribution license as outlined in the CL. That way the only
requirement on their license would be that coreboot users can use it in
some way (because otherwise, why ship it?)

It may be good to get the various blob owners on board with such a license
so that we can have a single one that allows mere (re)distribution with
little effort on their and our part. Could you ask the QC folks if there's
interest in sorting this out?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Supporting blobs with licenses that you agree to on download

[Patrick Georgi via coreboot]

Am Mi., 10. Juni 2020 um 03:43 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> > Clearly, the rules should be the same for all blobs, so if
> > some blobs with language like this are already in the repository, it
> > shouldn't be grounds to reject new blobs from landing.

It's not unheard of to adapt rules to new realities or to tighten them up
to implement what was meant originally and grand-father in violations.
But that only works if we can find an interpretation that doesn't put us
all in violation _right now_. In that case, we'll have to remove these
binaries (and respin the blobs tarballs of the last few releases).

> If we can come
> > up with an alternative that people would feel more comfortable with,
> > we should also apply it to those existing cases.
>
It might be possible to procure statements from the licensors to that end,
perhaps something akin to "$licensor grants a license to everyone to
download and redistribute the following files in the exact form uploaded to
coreboot.org by the licensor: [list of files with hashes]" that we can
simply append to the license text.


> > Would it be enough to just create a second repository
> > (3rdparty/restrictive_blobs or something like that) which is not
> > automatically checked out by CONFIG_USE_BLOBS so people can make a
> > separate conscious decision if they want to check it out?

If it doesn't allow redistribution, we'd have to check if coreboot.org can
host such repos (because we redistribute all the time) or if there's some
implied license by the licensor (they pushed it for redistribution after
all), and if we can mirror it to github.com and other places (or if that's
not implied anymore). As coreboot.org maintainers we won't accept a special
"redistribution by coreboot.org allowed" type of license: if those bits are
_that_ precious, we don't want them.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Language matters

[Patrick Georgi via coreboot]

Hi everybody,

in last Wednesdays' leadership meeting we've been discussing how to
deal with language in our code and community. I offered to report on
our results and to start the wider discussion and so that's the aim
of this email.

You might have heard about calls to avoid certain terminology in
tech. For those who haven't heard, here's a short re-cap: tech uses
terminology like "slave" (in conjunction with "master") with little
thought about the impact the non-tech interpretations of such terms
can have for some people.

The issue isn't exactly new, some open source projects retired the
use of certain words years ago, but in light of recent developments
(Black Lives Matter and all that) the topic has been brought up again.

Since it's usually possible to find other terms to describe the same
fact that come with no (or less) historical baggage, and often even
_better_ terms, the proposal is to move away from troublesome words
in favor of more neutral ones.

In some cases such proposals don't come across as proposals (but rather
as pretty forceful demands) and some of these debates ended badly,
both things that we'd like to avoid. We discussed an approach at the
leadership meeting and hope that it's nuanced enough to achieve a code
base and community where people of all stripes can contribute and not
run into stumbling blocks that make them feel not welcome, while also
not making people feel like they're having to watch their words.


So first and foremost, this isn't about playing some blame game. Words
have been used and will be used while not taking into account the
impact they may have on others, and as long as there's no bad intent,
let's try to be gracious about it, point out where things go wrong,
and on the receiving end, strive to improve. Overall I think this
community did pretty well on that, and so I don't see a big issue
with us continuing to do that.

Second: This exercise isn't about achieving world peace by eliminating
bad language or anything similar grandiose, obtuse or nonsensical. It's
about ensuring that coreboot is one of those open source projects
about which people, no matter their background, say that it's a
pleasure to work with.
From what I've heard people say after coming in to coreboot with
experience from other firmware projects, we probably achieved that
on the technical side (although there's always room to improve)
but there's more than just technical merit.

With that out of the way, here's what we came up with:

There's a set of words that we'd try to avoid, and that set can
grow over time as we identify terminology that is picked up badly
by some. Not all such terms are equally bad, and that can certainly
inform our approach with them.

For now, we've identified "slave", "master", "black list", and
"white list".

"slave": There has been no contest in the meeting that this term
carries _lots_ of baggage, and that we should look for alternatives.

"master": This is troublesome due to its connection to "slave", but
there are also different meanings of the term, some decidely positive
(what's bad about being a "master of your trade"?), so it's probably
the poster child of "not equally bad".

"black list": These lists typically aren't "black", neither are the
objects on these lists. I'd dare to say that they come in no color or
at most in whatever color your text editor uses. I'd like to think that
there's a better adjective for any given list to describe its purpose.

"white list": The opposite to the "black list", with the same
rationale. We even have an example for a descriptive rename for that
in the tree: Duncan renamed some white list into "allow list", which
is more descriptive for that particular use case while avoiding the
blanket term.
That doesn't mean that all white lists should become allow lists:
Be descriptive and consider what best describes the object you're
(re)naming.


The way we want to proceed with such terms depends on the context:

1. Some internal representation within coreboot that's called "master"
and "slave" could be renamed without confusing anybody and that's what
we should do there. Luckily, we don't typically deal with multiple
coordinating entities, so these specific terms aren't very widely
used to describe actors within coreboot. A counter example is the
Gerrit project that's developing our code review platform, and they
have a much harder time with these specific words.

For things in this category we'd propose that you think twice before
using them (and if you're comfortable doing so, that you start
a discussion when you see them during code review.) Again, such a
discussion is not about assigning blame or creating any bad outcomes
for your fellow developers, but to ensure a consistent style in our
code. If something slips through, we can clean up later - it's the
same approach we take with technical problems in our code.
There needn't be a huge "stop the world, we'll purge the tree" event
to get the code base into a certain form, but 

[coreboot] Re: Supporting a new board

[Patrick Georgi via coreboot]

Am Di., 12. Jan. 2021 um 09:47 Uhr schrieb Alif Ilhan :

> Well, should I share the code? But I am trying with Pineview raminit
> codes, both the MRC.bin and native one. The bios session document mentioned
> "Cedar View uses the same MRC build environment as Pineview"
>
We welcome contributions that you have written yourself and that you are
legally allowed to license under GPLv2 terms.

Don't share other people's code that came under licenses that aren't
compatible with the GPLv2, or under no license at all (such as leaked
code). Deriving knowledge from such code to write your own can lead to
legal problems (the boundary of what constitutes a derivative work isn't
very clear and can differ from country to country), for you and for the
project, so please be careful!

There's been an example on how that can hamper open source projects:
https://en.wikipedia.org/wiki/ReactOS#Internal_audit
That issue led to a significant slowdown in their development for several
years until the mess was sorted out.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Idiots guide to devicetree.cb

[Patrick Georgi via coreboot]

Am Mi., 25. Nov. 2020 um 15:57 Uhr schrieb :

> On 2020-11-24 03:05, Andy Pont wrote:
> > Is there an idiots guide to the definitions in devicetree.cb?  Trying
> > to make sense of the USB and PCIe configuration stuff.
>
https://doc.coreboot.org/acpi/devicetree.html describes some aspects but
it's relatively specific about listing devices for the purpose of having
them appear in ACPI, so that's just a subset.
https://doc.coreboot.org/acpi/devicetree.html#diving-into-the-above-example
is probably the most interesting part in terms of generic information.
https://link.springer.com/chapter/10.1007/978-1-4842-0070-4_4 also has some
bits on the devicetree (page 28+).

Roughly speaking:
- The device tree is mostly modeled after PCI (because that's where it was
first used), although it was extended over time to be able to describe
other topologies.
- "device" entries enumerate addressable devices at a certain point in the
physical hardware tree
- "chip" entries describe the drivers that are used for the sub-tree they
cover
- "register" entries fill in values into the struct referred to by the
next-outer "chip"
- io, irq point to device registers.

The naming of the keywords doesn't make all too much sense, since it
remained unchanged (except for compatible additions) since ~2003 when that
structure was devised, while both hardware and our use of the device tree
evolved.

I'd love to see somebody pick up the bits of information they gather on the
device tree and write a doc on that in Documentation/ (which gets rendered
to doc.coreboot.org). Andy, willing to take that on? :-)


> Device Tree Reference: https://elinux.org/Device_Tree_Reference
> Device Tree Usage: https://elinux.org/Device_Tree_Usage
> Device Tree Mysteries: https://elinux.org/Device_Tree_Mysteries

Those are u-boot/Linux-style device trees, loosely based on the
OpenFirmware device tree.
devicetree.cb is something else, coming from LinuxBIOS v2
LinuxBIOS v3 used Linux-style device trees but it didn't stick (as in:
people didn't port that back to v2, which later became v4), so our device
tree is still based on the old LBv2 thing.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Feature request: add payload "Tianocore with SeaBIOS CSM"

[Patrick Georgi via coreboot]

Am So., 15. Nov. 2020 um 19:43 Uhr schrieb Matt DeVillier <
matt.devill...@gmail.com>:

> if it were as simple as building Tianocore with SeaBIOS as the CSM, that
> would be the default option offered, but unfortunately it's not. The
> neither Tianocore package (the default CorebootPayloadPkg, nor
> UefiPayloadPkg) has support for a CSM, like the emulator package (OmvhPkg).
> I maintain the default CorebootPayloadPkg, and have tried unsuccessfully to
> integrate SeaBIOS as a CSM, but I've also not put a ton of effort into it.
> If someone else manages to get it working, I'll gladly take a pull request
> on github
>
corebootPkg used to support CSM a long time ago. The remains are archived
at
https://code.georgi.software/patrick/corebootPkg/src/branch/coreboot-pkg/corebootPkg
(see
https://code.georgi.software/patrick/corebootPkg#user-content-csm-support
for some minimal documentation.) While I won't spend time reviving or
integrating it with the modern coreboot/edk2 bridges, it might serve as a
starting point for whoever is interested. Good luck.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[Patrick Georgi via coreboot]

Am Do., 19. Nov. 2020 um 18:32 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > > My argument is solely on complexity, but please don't trust that hash
> too
> > > much.
> >
> > If I shouldn't trust
> > "16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot" too much,
> > why should I trust
> > "04 tree 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot"
> > (where the repo referred to through the "commit" entry comes from the
> > very same server)?
>
> Let's say that you've audited the files some time in the past, found
> them to be good, and have noted down the hash to catch obvious repo
> tampering or changes in the submodule commit, saying to audit anew.
>
Then you rely on a hash (which one, commit? That's SHA1 of a collection of
SHA1s for files, directories and submodules) for your certification.
That's true no matter what kind of object those SHA1s represent.

If you create your own hash for the tree, you can as well create a hash of
everything (minus .git which has an unstable representation) which
conveniently includes any checked out submodules.

If you later need to re-fetch the submodule contents (maybe in a
> local clone into a new directory) then merely the hash is not very
> reliable. SHA-2 would be a lot better than SHA-1, which is in turn
> a lot better than MD5, but just a hash is a lot weaker than the
> original audit.
>
Which is exactly why git is moving to SHA2 now, but that critique is more
one of git, so if you don't trust SHA1, don't use git?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[Patrick Georgi via coreboot]

Am Mi., 18. Nov. 2020 um 09:14 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:

> or is the problem here just the fact that the hashing library is part of a
> submodule?
>
If it's the submodule that is in question here, we _could_ import vboot as
a subtree (and compatibly, too!), although that will create a real mess of
our repo history because we'll have two git histories merged in one. I
would not recommend going down that route.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Undepend on vboot [was: System gcc requirements]

[Patrick Georgi via coreboot]

Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > coreboot doesn't, cbfstool does.
>
> If that were the case things would already be a lot better!
>
> Alas, coreboot unconditionally requires vboot in these files:
>
Oops, I forgot about those, you're right!

So: we discussed that in today's meeting and had two take-aways:

1. people have issues with older host toolchains failing to build vboot.
We'll work on improving those scenarios.

2. We generally prefer to build our utilities fully featured to prevent
partial feature sets from popping up in installed binaries.
That said, if there were a patch that cleanly cuts out cbfs hashing support
from coreboot (and cbfstool used for building coreboot) based on a Kconfig
flag, we would consider it.

"Cleanly" meaning:
 - It needs to be optional
 - The result needs to be maintainable. Things shouldn't break apart when
looking at the flag funny
 - cbfstool should behave properly and reasonably when built without
hashing but the relevant options are used (that is: say that it's a
stripped down build, not just "command line error")
 - cbfstool and cbfs in coreboot without those flags still need to be able
to deal with hash attributes sanely, that is, skip them safely. I don't
expect that to be an issue (the data structures are robust enough), but
something to keep in mind.

Maybe we view Kconfig differently. I expect it to control not only the
> final build artefact but also the build process, meaning what gets built
> and what is needed for successful build.
>
I'm not entirely happy about the way we use Kconfig to enable ccache (to
pick an example) because IMHO changes to config.h should lead to a
different coreboot build (outside config.h).
I guess with this "feature", the build would be different, so this
satisfies my personal criterion.


> Right, but maybe we at least agree that requiring some submodule(s)
> for nothing is at a minimum unneccessary?
>
As I mentioned elsewhere, we could import vboot as a git subtree (even
though I wouldn't recommend it). That changes next-to-nothing for users
(but makes life hell for developers), but satisfies that criterion.
So, why the hate on submodules?

I don't want any submodules, so I go over the source and remove the
> requirement.
>
I lined out how that could look like above. (Good) Patches accepted.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Termin mit Notiz abgesagt: coreboot Leadership Meeting - Mi 2. Dez. 2020 19:00 - 20:00 (MEZ) (coreboot@coreboot.org)

[Patrick Georgi via coreboot]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Denver:20201202T11
DTEND;TZID=America/Denver:20201202T12
DTSTAMP:20201118T185952Z
ORGANIZER;CN=Patrick Georgi:mailto:pgeo...@google.com
UID:gg46f4n5p6f9gl466ara69o1us_r20200909t170...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=WI
 M;X-NUM-GUESTS=0:mailto:wvervo...@eltan.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=su
 brata.ba...@intel.com;X-NUM-GUESTS=0:mailto:subrata.ba...@intel.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Patric
 k Georgi;X-NUM-GUESTS=0:mailto:pgeo...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Do
 ssym Nurmukhanov;X-NUM-GUESTS=0:mailto:dos...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ch
 ristian.wal...@9elements.com;X-NUM-GUESTS=0:mailto:christian.walter@9elemen
 ts.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ma
 rshalldawson...@gmail.com;X-NUM-GUESTS=0:mailto:marshalldawson...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=pa
 trick.rudo...@9elements.com;X-NUM-GUESTS=0:mailto:patrick.rudolph@9elements
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=St
 efan Reinauer;X-NUM-GUESTS=0:mailto:reina...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ma
 tt.devill...@gmail.com;X-NUM-GUESTS=0:mailto:matt.devill...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=je
 r...@system76.com;X-NUM-GUESTS=0:mailto:jer...@system76.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ro
 n Minnich;X-NUM-GUESTS=0:mailto:rminn...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ma
 rc Jones;X-NUM-GUESTS=0:mailto:marcj...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ma
 rtin Roth;X-NUM-GUESTS=0:mailto:martinr...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=We
 rner Zeh;X-NUM-GUESTS=0:mailto:wero...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=de
 b...@sfconservancy.org;X-NUM-GUESTS=0:mailto:d...@sfconservancy.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ja
 ytalb...@sysproconsulting.com;X-NUM-GUESTS=0:mailto:jaytalbott@sysproconsul
 ting.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=jo
 nzh...@fb.com;X-NUM-GUESTS=0:mailto:jonzh...@fb.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Fu
 rquan Shaikh;X-NUM-GUESTS=0:mailto:furq...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Da
 vid Hendricks;X-NUM-GUESTS=0:mailto:david.hendri...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ke
 rry.br...@silverbackltd.com;X-NUM-GUESTS=0:mailto:kerry.brown@silverbackltd
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=za
 olin.dais...@gmail.com;X-NUM-GUESTS=0:mailto:zaolin.dais...@googlemail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ju
 lius Werner;X-NUM-GUESTS=0:mailto:jwer...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=qu
 asi...@google.com;X-NUM-GUESTS=0:mailto:quasi...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ep
 e...@google.com;X-NUM-GUESTS=0:mailto:epe...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fe
 lix.h...@amd.corp-partner.google.com;X-NUM-GUESTS=0:mailto:felix.held@amd.c
 orp-partner.google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fe
 lix-coreb...@felixheld.de;X-NUM-GUESTS=0:mailto:felix-coreb...@felixheld.de
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ni
 c...@gmx.de;X-NUM-GUESTS=0:mailto:nic...@gmx.de
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fe
 l...@felixheld.de;X-NUM-GUESTS=0:mailto:fe...@felixheld.de
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ed
 .benyuk...@amd.com;X-NUM-GUESTS=0:mailto:ed.benyuk...@amd.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ar
 t...@aheymans.xyz;X-NUM-GUESTS=0:mailto:art...@aheymans.xyz
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gd
 

[coreboot] Re: Undepend on vboot [was: System gcc requirements]

[Patrick Georgi via coreboot]

Am Mi., 18. Nov. 2020 um 22:15 Uhr schrieb bzt :

> I believe you are both unnecessarily overcomplicate this. The way I
> see it the only issue here is a few missing ifdef guards for
> CONFIG_VBOOT in cbfs, that's all. Quite straightforward to solve.
>
CONFIG_VBOOT enables vboot, the verified boot scheme. The issue here is the
submodule, which is drawn in through CONFIG_VBOOT_LIB. Besides vboot, other
users of it are: the TPM drivers, Eltan's mboot, AMD PSP verstage, Intel
CSE lite, and CBFS hashing (which has nothing to do with verified boot
right now, although that could change).

And even if "just ifdef stuff in CBFS with CONFIG_VBOOT_LIB" creates a
working image, that doesn't solve the problem that cbfstool has its own
CBFS implementation (so it also needs to be ifguarded that way, which is a
bit annoying because util/* doesn't use Kconfig at this time), and with
just "ifguarding things", there's some work left to do to handle "cbfstool
coreboot.rom add -A sha256 ..." properly: should it error out generically
(as if -A is unknown)? provide a useful error message? just ignore the flag?

It's not quite that straightforward.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Undepend on vboot [was: System gcc requirements]

[Patrick Georgi via coreboot]

Am Mi., 18. Nov. 2020 um 22:03 Uhr schrieb Nico Huber :

> The vboot dependency has been a PITA for a while. I'll happily accept
> patches that make it less of a pain even if that means a little more
> maintenance effort. I'd even accept a local hash implementation.

That's an option. That isn't what was proposed though. The proposal was "I
don't need this, it annoys me, let's drop it".

But I wonder, if that were a policy, would vboot have
> such implementations? I'm sure they weren't the first. Maybe there
> were even concerns about external code?
>
Suitable license (rules out everything GNU for GPL3+, OpenSSL + offspring
for their advertising clause or tomcrypt for not having a license),
somewhat recently maintained (rules out libtomcrypt and SPARK crypto),
suitable for embedded purposes (rules out Java implementations). Exactly
the issues coreboot would face when selecting an implementation to copy.
Just that by the time coreboot had to consider hashing data, vboot existed,
it ticked the right boxes, and some people with overlap to coreboot were
familiar with it.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[Patrick Georgi via coreboot]

Am Mi., 18. Nov. 2020 um 23:54 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> because unlike everything
> else you need to build coreboot there seems to be no way to get an ADA
> toolchain from crossgcc.

gnat (gcc's Ada implementation) needs an Ada implementation to bootstrap
(just like gcc needs a C++ compiler). If you have gnat[0] installed on the
host, you also get a gnat for the targets.
(side note: The chromium-os coreboot-sdk package uses a binary toolchain
from AdaCore for the bootstrap, so within cros_sdk the cross compilers are
all Ada-aware.)

But yes, it's not exactly obvious.


Patrick
[0] conditions apply: it needs to be the same build as gcc so that they can
interact (some distros mess this up) and it must be sufficiently new
(although we integrated a bunch of hacks to support older compilers than
usual)
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[Patrick Georgi via coreboot]

Am Do., 19. Nov. 2020 um 01:26 Uhr schrieb Peter Stuge :

> > the Git SHA of the submodule HEAD is stored in the main coreboot repo.
>
> My argument is solely on complexity, but please don't trust that hash too
> much.
>
If I shouldn't trust
"16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot" too much,
why should I trust
"04 tree 4c523ed10f25de872ac0513ebd6ca53d3970b9de vboot"
(where the repo referred to through the "commit" entry comes from the very
same server)?

And this isn't a rhetorical question, I _really_ don't get that point.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System gcc requirements

[Patrick Georgi via coreboot]

Am Di., 17. Nov. 2020 um 05:06 Uhr schrieb Peter Stuge :

> It's absurd to me that coreboot would require any routines out of any
> submodule for a build which will not use those routines.

coreboot doesn't, cbfstool does.

One purpose of Kconfig is to ensure that only what's neccessary gets built.

But cbfstool isn't hooked up to Kconfig. Given that it's not part of the
final coreboot build, having extra stuff in cbfstool doesn't affect
coreboot in the slightest, so it's not clear to me that we should change
that.


> It's wrong to pull in anything during build. I too am guilty of this
>
by pushing for buildgcc, it would be good to improve that case too.
>
Given your reference to buildgcc, I guess you mean "download"? In that
case: git clone --recurse-submodules and there's not a single extra
download going on at build time.
I know because I frequently deal with two systems that forbid downloads at
build time: qa.coreboot.org and Chromium OS' build infrastructure.

It is because that's what consistently causes me extra work and
> frustration every time I want to build a minimal coreboot.
>
git clone --recurse-submodules is extra work, really?

What some people always want isn't OK to require when other people do
> not want it. I think that's just lazy, and not the smart kind. :\
>
Some people do not want ramstage. Some people do not want blobs. Some
people do not want x86 support. They still carry the baggage when
downloading coreboot.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Tooling of choice for coordinating and running the coreboot leadership meeting

[Patrick Georgi via coreboot]

Hi everybody,

when announcing today's leadership meeting on IRC I got some replies to the
tune of "oh no, Google!" as the meeting minutes are recorded on Google Docs
and the meeting itself is held using Google Meet.

Note that both are set up to be usable without a Google account, so the
impact on users should be limited.

That said, if that's a real concern that prevents people from participating
who otherwise would like to chime in, we need a solution. To avoid spending
too much time on something that may not actually be a problem, I'm asking
you:

1. To consider if you care about the leadership meeting (otherwise, please
don't create extra work to prove a point about "big tech", software
licenses or whatever)
2. If using these two tools for this specific purpose is a problem for you
3. What your ideal alternative solution would look like
4. How your solution would be implemented
5. Present the result of 4 to the list :-)

Note that this project, its developers, contributors and maintainers aren't
in the business of managing servers or communication suites (although we
spend a fair amount of time and money on running coreboot.org to ensure
people can contribute with little restrictions: apart from that meeting,
everything we do is self-hosted!) so a proposal should be low maintenance
for us.

This means: running the meeting must not be a hassle (we tried a fair
amount of open tools for running the calls: jitsi, mumble and several
others, and they fell flat, for example because they sent video streams
from everybody to everybody. n^2 traffic growth isn't great), available for
the long term (if you offer to run the necessary services for us that's
nice, but we'd prefer not to have to change routines again 3 months down
the road because your priorities shifted, so any such offer should give us
the impression that it's available for the foreseeable future) and not just
exchanging one "troublesome" vendor for another (I guess we'll see what
"troublesome" means to people in the community.)

As for capacity: The meetings take one hour every 14 days. Today's meeting
had 17 participants and I think some meetings had a few more folks joining.
Those are discussions not presentations, so high-latency streaming options
(such as PeerTube's new live stream feature) won't work.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] RFC: On testing and reporting how well coreboot does on real hardware

[Patrick Georgi via coreboot]

Hi everybody,

There has been some talk recently in a smaller group where coreboot needs
to improve the most in public perception, and how to get there.

Consensus has been that we're doing a pretty bad job at promoting all the
hardware that we support in each coreboot version.

There's board-status which I started _years_ ago in the hope that somebody
picks up the slack, but everybody has been busy, myself included. By now
the collected information of the last 7.5 years is compiled into a 12MB
HTML file that takes ages to render on moderate hardware (beware:
https://www.coreboot.org/status/board-status.html), and the process to
collect that data is mostly manual using pretty poor tooling. (Most of the
links on that page don't even work anymore (which I'll fix) due to
gitweb/cgit/gitiles changes on review.coreboot.org (and I only noticed by
chance now).)

Meanwhile, there are several parties that boot test the hardware they care
about regularly, with (often internal) information about how well coreboot
does there.

We can't expect all those existing systems to converge into a single
testing framework, but we could make it a single test result reporting
framework.

To this end, I invite people interested in that topic to chime in on this
email thread so that we can discuss what we could do to provide a common
place with information about which coreboot versions are bootable on which
boards in a way that makes sense for everybody: users who are interested in
such data as well as testers that already collect it but have no way to
publish it.


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Releasing coreboot 4.14 (on Monday)

[Patrick Georgi via coreboot]

Hi everybody,

I still plan to do the coreboot release on Monday (or, if things are really
bad, on Tuesday), even though I'm somewhat behind on our checklist.
This means we are at the
https://doc.coreboot.org/releases/checklist.html#week-prior-to-release
stage.

Therefore, if you have hardware and the ability to flash and recover,
please test our current code on it, and report back if there are problems.
If you think a feature you worked on since 4.13 was released deserves a
shout-out in our release notes and it isn't already there, create a change
that adds it to Documentation/releases/coreboot-4.14-relnotes.md


Thanks,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Do., 6. Mai 2021 um 14:03 Uhr schrieb Piotr Król :

> If 3mdeb maintains some boards, we already testing those and would be
> glad to hook, in secure way, to patch testing system, but I would like
> to know where is interface documentation so I can evaluate cost of
> integration and convince customers to go that path. This was expressed
> many times in various communication channels (conferences, slack).
>
We're at the ~5th or so public test infrastructure project by now and it's
still not nailed down.
Part of it is that it's simply a hard problem.

Another problem is that whoever pulls this off needs to be in the very
narrow intersection of having time (i.e. not a product driven coreboot
developer) and having money and a few other resources (i.e. not a
hobbyist), so they can run enough of the infrastructure by themselves that
others who could hook into the infrastructure see the benefit.

I think it can be expensive to go all-in in that direction, but if we
> could go in that direction it would be great.
>
If you want to maintain any particular release as a long term branch,
announce your intent and we'll set up a branch!


> Question is why coreboot change so dramatically in all mentioned areas?
> Does projects with similar lifetime also change in so significant way?
>
One reason is that we're dealing with the guts of an industry that is
changing around us _very_ quickly.
But I disagree that we're changing dramatically: on the contrary, we're
pretty careful about remaining compatible in various important ways for
long stretches of time to help everybody move at their own pace.

Some examples off the top of my head:
- We used to compile out strings for log levels we didn't print for space
reasons. Space is now no concern and there's the cbmem console, so we leave
everything in for better debugging. The remnants of the "compile out"
approach, gone for ~10 years, have only been removed within the last two
months.
- We used to have CBFS with a master header that defined "off limit"
regions at the start and end of flash. That's fine as long as you don't
regularly write to flash (where you risk blasting away parts of the CBFS
structure), but these days we do write to flash, sadly, so there's now a
partitioning scheme (fmap), making the master header obsolete. The header
is still around, SeaBIOS still can't read FMAP.
- We added per-file metadata to CBFS in a compatible way even though the
structure is a bit more complicated than it could have been if we hadn't
cared about compatibility.
- The "read/write registers" code had to change because C compilers like to
tighten up their rules around aliasing and volatile types and stuff like
that. So we rewrite our macros into functions, with proper types, just so
that a newer compiler doesn't break our entire code base.
- All that vboot/mboot/bootguard security stuff just was not a thing when
coreboot started. It brought in tons of complexity: more flash
partitioning, more boot stages, just "tons more code", more memory
management (for example, we now have some funky "free last two malloced
objects" free() implementation. We got by without free() for 15 years)
- Thunderbolt (and USB4) have some pretty arcane requirements on
configuration buses. Originally LinuxBoot was supposed to set up only the
bare minimum to jump into a kernel. With TBT/USB4 you can forget about that.
- More and more external complexity brought in: IOMMUs seem to add a new
data structure with every chip generation, ACPI is getting ever more
complex (and we can't opt out of that madness or OSes won't boot), ...

So everything changes around us, sometimes in unexpected ways: compilers,
interfaces, hardware. It would be a miracle if we didn't have to change to
go along with that.

The main reason why you notice that with coreboot but not other firmware is
that ancient-UEFI never gets uprevved (and while other firmware, like
u-boot, collects firmware build support in their main repo, in products
they're still used mostly in a copy model). I just turned down a
couple of older (non-coreboot) firmware build processes because they rely
on python 2. They're dead, while coreboot isn't.

The main reason why it's slightly less painful with Linux (but ask any
out-of-tree module maintainer!) is that chip vendors provide open source
code for Linux and maintain it whenever they raise the complexity bar a
notch or two, and compiler vendors (gcc, clang) are coordinating against
Linux (while they usually don't really care about coreboot).

tl;dr: All things considered, we're a pretty small project punching _way_
above our weight, working sometimes against the interests of other parties
in the ecosystem who'd prefer to keep things closed that we open. Since (at
this time) we can't offload the pain to those who inflict it on us the way
Linux is doing, we'll have to bear it.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:

[coreboot] Re: arm-trusted-firmware mirror seems to have stopped syncing

[Patrick Georgi via coreboot]

Hi Julius,

the syncer's configuration for that repo was wrong in a couple of places, I
fixed it this morning.


Regards,
Patrick

Am Do., 13. Mai 2021 um 01:55 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> Hi Patrick, Martin,
>
> The coreboot.org mirror of the arm-trusted-firmware repo
> (https://review.coreboot.org/admin/repos/arm-trusted-firmware) seems
> to be half a year out of date. According to the description (although
> that may be out of date) it's still syncing from the old GitHub
> location (https://github.com/ARM-software/arm-trusted-firmware.git).
> The Trusted Firmware project switched a while ago to their own hosting
> solution and I probably forgot to let you know. The new upstream
> repository this should sync from is at:
> https://review.trustedfirmware.org/TF-A/trusted-firmware-a
>
> Then again, it looks like the GitHub location is still kept up to date
> as a read-only mirror
> (https://github.com/ARM-software/arm-trusted-firmware/commits/master),
> so maybe this isn't the real source of the problem? Anyway, can you
> please take a look and figure out how to fix the syncing? (Or is this
> supposed to be done manually somehow?)
>
> Thanks,
> Julius
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Sa., 8. Mai 2021 um 03:08 Uhr schrieb Julius Werner :

> I understand that you might like to have both [features and stability] but
> I think that's just fundamentally impossible -- big new features just tend
> to require deep, invasive changes.

+1


> I think we could encourage that, I don't think it's really something
> you can make a hard requirement. spatches just don't work well for all
> kinds of API changes. Starting this as a sort of "experiment" like you
> suggested to see how it goes sounds like a good idea.
>
This is why my proposed documentation change (
https://review.coreboot.org/c/coreboot/+/52576/1/Documentation/getting_started/gerrit_guidelines.md#335)
states:
"Providing a script or a [coccinelle](
https://coccinelle.gitlabpages.inria.fr/website/) semantic patch to
automate this step is extra helpful, so consider doing that if possible."

The only "shall do" request is that there's _some_ documentation about what
has been going on, and that can be as short as "commit abc replaced
foo(a,b) with bar(b,a)."

Do I need to emphasize the "if possible" part some more?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] What should we do about freenode IRC services?

[Patrick Georgi via coreboot]

Hi everybody,

you might have heard that freenode.org recently changed management under 
weird circumstances. Given that we use their services for our project 
chat, this concerns us as well.


In last week's leadership meeting we had a wide variety of opinions: To 
go for libera.chat (a network created by former freenode staff), some 
other IRC network, to leave IRC behind and go for something newer and 
Matrix and Mattermost have been brought up as examples of where this 
might lead. Of course, we could also decide to stay on freenode, 
although from what transpires that option seems less and less attractive 
every day.


So, what should we do?


Regards,
Patrick
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What should we do about freenode IRC services?

[Patrick Georgi via coreboot]

27. Mai 2021 11:44, "Angel Pons"  schrieb:
>> On Tue, May 25, 2021 at 6:01 AM Patrick Georgi via coreboot 
>>  wrote:
>>> So, what should we do?
> 
> I'd suggest moving to Libera. I think the Matrix bridge to Libera is
> running now.
It is: #coreboot:libera.chat is accessible (although you'll need to go through 
the nickserv dance and ideally !storepass your nickserv password in the 
'liberachat IRC Bridge status' room to make things reasonably automatic)

So far I haven't seen strong objection to IRC, but no stated desire to stay on 
freenode, while its admins behave more erratically every day.

For that reason I created https://review.coreboot.org/c/coreboot/+/55010 and 
https://review.coreboot.org/c/coreboot/+/55011 that retarget IRC links to 
libera.chat, promote the Matrix bridge and the Discord presence.


Regards,
Patrick
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What should we do about freenode IRC services?

[Patrick Georgi via coreboot]

Am 28.05.2021 um 07:54 schrieb Shawn C:

Nice, I wouldn't use libera.chat since they banned all tor traffic by default. 
OFTC respect more of user privacy but seems nobody are willing to use. Then 
Matrix is a good option. Thanks.


They seem to have a dedicated tor service now, described at 
https://libera.chat/guides/connect#accessing-liberachat-via-tor


So much as I understand tor that seems to be preferable over using tor's 
exit node network.



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

[coreboot] Re: cgit on review.coreboot.org

[Patrick Georgi via coreboot]

gitiles#106 points to https://github.com/google/gitiles/issues/7 which
outlines the concern of delivering arbitrary data from an authenticated
domain.

I believe GitHub moved its "raw" output to a separate domain for the same
reason, e.g.
https://raw.githubusercontent.com/coreboot/coreboot/master/Makefile
We could consider setting up a separate domain for that purpose and provide
raw files there, but as an immediate workaround, all our repos are mirrored
~hourly to github.com/coreboot, too (and therefore are available through
raw.githubusercontent.com)


Regards,
Patrick

Am Fr., 28. Mai 2021 um 00:43 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> > Hi Julius,
> > Appending "?format=TEXT" to the file link in Gitiles (the "txt" link at
> the bottom of the page) will give a base64-encoded copy of the file.
>
> Yeah, I wish they just had a ?format=raw instead, I don't get why they
> don't implement the most obvious option. Seems like they're not really
> interested in doing that though
> (https://github.com/google/gitiles/issues/106).
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Intent to release coreboot 4.14 on May 10

[Patrick Georgi via coreboot]

Hi everybody,

This email starts the release process for coreboot 4.14, so we're now at
the "~2 weeks prior to release" step in our
https://doc.coreboot.org/releases/checklist.html

As usual, our releases don't denote any particular feature or stability
milestone, they only serve two purposes:
1. Avoid the impression that coreboot is dead - an idea that actually came
up before we started doing time-based releases
2. Provide anchor points that downstream coreboot users can use to base
their work against if they wish to do so

What everybody can do: Consider testing the devices you have against our
current master branch, send in board-status reports so boards are
known-good in https://coreboot.org/status/board-status.html, report or,
even better, fix issues you encounter.

As a developer, please consider if your large scale tree change can wait
for after the release so that the tree can settle down a bit. But also, if
you have large changes that are waiting (such as toolchain updates), you
could already start to bring them in shape to merge after the release!

Also, please check out the release notes in Documentation/releases/
coreboot-4.14-relnotes.md to see if any notable work of the last 6 months
is missing there. Addition and deletion of mainboards and SoCs will be
added shortly before the release with script assistance, but everything
else won't be. Patches to extend our release notes are appreciated!

Thanks y'all for making coreboot what it is now. As a release manager I'll
merely put another label on it :-)


Best regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Dropping the "cbfs master header" file

[Patrick Georgi via coreboot]

Hi Arthur,

The master header is a legacy thing and I'm in favor of removing it. That
said, as you and Michal mentioned, there's some work to do first. I started
https://ticket.coreboot.org/issues/306 to help track what's missing.


Patrick


Am Mi., 28. Apr. 2021 um 08:42 Uhr schrieb Arthur Heymans <
art...@aheymans.xyz>:

> Hi
>
> Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs master
> header" at the bottom of this fmap region and the X86 bootblock has a
> pointer at 0xFFFC to it. Other ARCH have a "header pointer" file at the
> top of that FMAP region pointing to it.
>
> Currently this file is only used as an anchor point to use cbfs with
> walkcbfs_asm on X86 to access cbfs in assembly (before any C code). There
> are 2 uses for this at the moment:
> 1) updating microcode on Intel systems that don't feature FIT before
> setting up CAR
> 2) finding FSP-T (if FSP_CAR is used) before jumping to it
> Both the cbfstool and the C coreboot code don't rely on it anymore, so it
> is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a VBOOT
> setup don't feature it.
>
> Accessing cbfs with walkcbfs_asm breaks hardware based root of trust
> security mechanisms like Intel bootguard/TXT/CBnT, because no verification
> or measurement whatsoever happens on either " cbfs master header" of
> "fsp-t" files. So for instance even if TXT/Bootguard measured or verified
> FSP-T as an IBB so that it is trusted, an attacker could insert a new cbfs
> file with the same name, "fsp-t" at a lower address and coreboot will run
> it anyway.  So a static pointer to fsp-t is required. Sidenote/Rant: FSP-T
> continuously causes such integration problems... Blobs that set up the
> execution environment are just a very bad idea.
>
> So I propose to drop the legacy "cbfs master header" file and adapt the 2
> current use cases in the following way:
> - Reuse the Intel FIT table and implement FIT microcode updates in
> assembly/software. (I had this working on some point, before I decided to
> use walkcbfs_asm)
> - Either fix the location of FSP-T via for instance a Kconfig option or
> add a pointer to "fsp-t" at a fixed location in the bootblock and have the
> tooling update the pointer during the build process. I think the Kconfig
> option is the least amount of work and cbfstool is already overloaded with
> options and flags, so my preference goes to this.
>
> Let me know what you think.
>
> Kind regards
>
> Arthur Heymans
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Am Do., 22. Apr. 2021 um 22:58 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > tree-wide changes
> ..
> > there may be other approaches on how to make development easier
>
> I'm a big fan of semantic patching as provided by coccinelle and used
> heavily in Linux kernel development.
>
> Perhaps one way to make lives easier is to require tree-wide changes
> to be the result of an spatch, which can then be applied downstream too?
>
I proposed that in https://review.coreboot.org/c/coreboot/+/52576 already
because I'm also a fan of this idea.

That said, both in the meeting and in Nico's sibling comment there have
been concerns on putting additional burden on developers (although,
personally, I'd rather review a CL that is created by a tool + a simple
rule set than a tree-wide refactoring made by hand...)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Patrick Georgi via coreboot]

Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans <
arthur.heym...@9elements.com>:

> So TL;DR:
> - Is (temporarily) adding a tool to the blobs repo ok?
>
If it matches the requirements of the blobs repo wrt. license terms and
documentation, I don't see why not from a formal perspective.
It's telling though (in the sense of a Freudian slip) that you put the
"temporarily" in parentheses already: interim solutions like these tend to
survive their best due date ;-)


> - Is integrating an (optional) not yet open tool into the build system ok?
>
This one is IMHO the bigger issue: that tool will only run on
Linux/x86(-64?), and probably only with a select set of libc
implementations. While we have portability issues every now and then,
they're always accidentally introduced because our testing isn't good
enough while adding this to the build flow deliberately makes all other
platforms second tier build hosts.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coding style discussions, again.

[Patrick Georgi via coreboot]

Hello everybody,

https://review.coreboot.org/c/coreboot/+/51825 proposes getting rid of the
rule to make if-statement blocks (and the like) as short as possible.
The rationale is to encourage a style that avoids subtle bugs which then
need to be found by tooling such as Coverity Scan and fixed by commits like
https://review.coreboot.org/51786.

Julius disagrees and requests wider discussion, specifically on the mailing
list.
So here we are: Arguments? Opinions?

Julius, maybe you want to make your case, I didn't want to risk
representing a distorted position.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: On handling vendorcode

[Patrick Georgi via coreboot]

Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge :

> Patrick Georgi via coreboot wrote:
> > Any objections to moving the code out there that has no other upstream
> > (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> > while moving in code from elsewhere in the tree that fits the "it has a
> > foreign upstream" description (e.g. the lzma library)?
>
> I think that can make sense, but where would the chromeos, eltan and
> other directories go instead? Someplace existing, or someplace new?
>
I first wanted to make sure that there are no major issues with the overall
idea, but to further the discussion:

- src/vendorcode/eltan/security -> src/security/mboot
- src/vendorcode/google/chromeos is a mixed bag: some src/drivers/tpm/cr50,
some src/lib (e.g. elog, vpd), some src/acpi/chromeos (acpi*)

I'm not sure about Siemens' hwilib: if that's imported, it remains there,
if this version is written for coreboot, src/drivers/siemens perhaps?

The other things look to be "real" vendorcode, even if we're probably the
last codebase by now that still ships (our versions of) amd/agesa.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: On handling vendorcode

[Patrick Georgi via coreboot]

Am Mi., 7. Apr. 2021 um 01:12 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> I think we still need to have a difference between hacky vendor stuff
> and normal coreboot code. For example, the Eltan mboot stuff is
> something we didn't really want to have in coreboot in that form, and
> so they kinda put it in vendorcode as a compromise. We should make
> sure it remains clear that that code isn't "proper" coreboot code and
> didn't go through the same level of review.
>
It might have started that way, but I don't think that's an accurate
portrayal of eltan's work at this point:
The eltan code uses vboot for the cryptographic primitives these days and
as far as I can see, extends it for measured boot - which vboot itself
doesn't do, ever.

Also, regarding your point on gerrit (collecting arguments in this thread)
that we don't have duplicate things, look no further than graphics init:
- src/device/oprom/realmode
- src/device/oprom/yabel
- src/drivers/intel/gma
- FSP can do the graphics init, too (and report it in cbtables)

(I didn't count the native ARM graphics init routines because we don't ship
alternatives for those)


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] On handling vendorcode

[Patrick Georgi via coreboot]

Hi everybody,

We recently landed a change (https://review.coreboot.org/51827) to be more
selective which parts of src/vendorcode are checked for coding style
because some areas are really coreboot code "by vendors".

The original purpose of that subhierarchy was to isolate code we draw in
from the outside to make every dev aware that the file they're touching has
some upstream other than coreboot and that this code shouldn't be modified
except to track that upstream.

Any objections to moving the code out there that has no other upstream
(e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
while moving in code from elsewhere in the tree that fits the "it has a
foreign upstream" description (e.g. the lzma library)?


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Posting via web interface doesn't work (was: Kann keinen Thread eröffnen)

[Patrick Georgi via coreboot]

Am Do., 18. März 2021 um 04:04 Uhr schrieb Tobias Wiese <
tob...@tobiaswiese.com>:

> Actually since HyperKitty Version 1.3.4 the HYPERKITTY_ALLOW_WEB_POSTING
> setting should do that.
> This might prevent further confusion for others.
>
The last time I looked that didn't exist yet, but I disabled the web editor
"properly" now.


Thanks for the heads up!
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Kann keinen Thread eröffnen

[Patrick Georgi via coreboot]

Dear Mr. Kunze,

Am Di., 16. März 2021 um 17:43 Uhr schrieb web25322986p1 <
gottfried.ku...@fanfara.de>:

> Trotz Anmeldung bei der Mailiglist (bin eingeloggt) kann ich jedoch keinen 
> Thread beginnen. Ich erhalte stets:
>  *Error 404 not found.
> *
>
> We disabled the mail editor in hyperkitty due to spammers abusing that
interface (ruining it for everybody). Since hyperkitty has no "official"
way of doing that, we routed the editor into a 404 error.

(by the way, the mailing list language is English)


Best regards,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Running QEMU targets in Jenkins

[Patrick Georgi via coreboot]

Hi Julius,

https://qa.coreboot.org/job/coreboot-boot-test/ sends off ToT builds to
9esec's Lava system where they are run on some virtual and real devices.
See for example the comments to
https://review.coreboot.org/c/coreboot/+/51189 where Lava reports passing
on 5 qemu configs and 3 real devices.


Regards,
Patrick

Am Do., 4. März 2021 um 02:42 Uhr schrieb Julius Werner <
jwer...@chromium.org>:

> I'm just curious... have we ever considered booting some of our QEMU
> targets as part of the Jenkins CI? I know they don't do a lot but they
> do cover some stuff (e.g. CBFS). I randomly happened to boot one of my
> in-flight patch trains on qemu-i440fx recently and discovered that I
> accidentally broke rmodule loading. Would be nice if Jenkins could
> just do that for you automatically.
>
> Just wanted to know whether this had been discussed before and people
> have come up with good reasons not to do it, or if it's just a matter
> of nobody had time to implement it yet. (And if someone wanted to
> implement it, what would be the best hook point? Put it into abuild?)
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding GSoC 2020

[Patrick Georgi via coreboot]

Hi Vedant,

coreboot has applied to this year's GSoC but GSoC still has to decide on
the projects they want to host: That will be announced on March 9.


Patrick

Am Sa., 20. Feb. 2021 um 07:40 Uhr schrieb :

> Hi, I am interested to apply to gsoc2020, is coreboot going to apply in
> gsoc 2021?
>
> Regards,
> Vedant Paranjape
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: GSoC query

[Patrick Georgi via coreboot]

Hi Hritik Vijay,

we applied to GSoC but they will only announce the projects that will
participate this year on March 9.


Regards,
Patrick

Am Fr., 19. Feb. 2021 um 09:52 Uhr schrieb Hritik Vijay via coreboot <
coreboot@coreboot.org>:

> Hi
> Coreboot appeared last year in the GSoC initiative, I wanted to know if
> there are plans to appear again?
>
>
> From the terminal
> Hritik Vijay
>
> Sent with ProtonMail  Secure Email.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Patrick Georgi via coreboot]

Hi Enrico,

(list to bcc)

not speaking about the technical difficulties you face with golang or the
general topic of blob use here, just one thing:

Don't post conspiracy theories here. Well, two things: We also do not
punching here (except for cards, maybe, if we're in the mood for some retro
computing.)

It took me some deliberation whether or not to moderate you, but I also
didn't want to deal with the (very realistic risk of you) whining that
you're being censored. You're not: Later messages with such content will
drop out of the moderation queue without further comment, but you still
have an entire Internet (minus coreboot.org) at your disposal to try to
disseminate your world view.

Am Di., 23. Feb. 2021 um 20:38 Uhr schrieb Enrico Weigelt, metux IT consult
:

> that already devastated several major

cities in the US last year and also stormed into the US capitol ?

I really don't like to have anything to do with those people. ]
>

If you're really worried about being associated (even several times remote)
with organizations that are (or may be) responsible for devastation of
cities, I have really bad news for you:

coreboot, originally LinuxBIOS, was initially funded by the US DoE through
LANL (https://www.coreboot.org/FAQ#Who_is_funding_coreboot.3F) of which
Wikipedia (https://en.wikipedia.org/wiki/Los_Alamos_National_Laboratory)
has this to say: "initially organized during World War II for the design of
nuclear weapons as part of the Manhattan Project". There are few
organizations that can lay claim to "devastation of major cities" to the
degree that they can.

It was later kept alive through projects indirectly (and maybe directly)
paid for by the German government, with purposes - among others - like
controlling Patriot ground-to-air missiles (the laptop seen at
https://youtu.be/0RfPSXL6yLw?t=67 looks like a Roda RK8 series device and
probably runs coreboot). I'm trying to put it mildly, but Patriot isn't
typically used for home improvement.

Nowadays the support of companies like Google, Facebook and Amazon is
elemental in keeping coreboot usable on current platforms (even if there
are caveats with those platforms). Some people claim that these companies
devastate societies and economies: Under the loose-association philosophy
that you seem to live by, some brick & mortar store owners (the backbone of
inner city living infrastructure) might have a word or two to say about you
being affiliated with a project that is used by Amazon. Some people in San
Francisco (a major US city) are rather unhappy about Google and Facebook as
well, due to a perception that there's some negative impact of their
headquarter on cost of living in the area. (And if this section contains a
larger amount of weasel words than usual note that I'm not trying to take a
position here, just present a point of view)

Therefore if you don't like to have anything to do with people who
devastate cities, you better look elsewhere (and given that Free Software
and Open Source licensing in general forbids "field of endeavour" clauses
you'll have a hard time living that philosophy anywhere in the FLOSS
ecosystem)


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Announcing our new job board

[Patrick Georgi via coreboot]

Hi everybody,

In our leadership meetings we repeatedly had companies using coreboot look
for qualified staff. In response this created a job site at coreboot.org,
linked prominently from our landing page, accessible at
https://coreboot.org/jobs.html

So if you're looking for a coreboot related job, check out these job
postings and if you're with a company that is looking for new folks, feel
free to push a change to our homepage.git repository to add your company
there!


Best regards,
Patrick Georgi
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Mailing list moderation

[Patrick Georgi via coreboot]

Hi everybody,

As we're encountering a spam campaign right now by a sufficiently motivated
actor to get through our filters I put the mailing list on moderation until
this silliness subsides.

For this reason delivery of mails sent to this list may be delayed.

Thanks for your patience,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Mailing list issues, update

[Patrick Georgi via coreboot]

Hi everybody,

There have been some issues with the mailing lists hosted at coreboot.org
(spanning multiple projects: coreboot, flashrom, seabios and openbios)
related to configuration changes in response to our precious little
spammer. As a result some people have seen mailing list delivery to them
disabled due to bounces. I reversed that change for the affected users so
everybody's back in.

To avoid this type of issue going forward, the server manual has been
revised to point out some pitfalls in the mail server configuration and how
to avoid them.


Again thank you for your patience,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Regarding GSoC 2020

[Patrick Georgi via coreboot]

Am Mo., 22. Feb. 2021 um 12:31 Uhr schrieb Vedant Paranjape <
vedantparanjape160...@gmail.com>:

> Thanks for the update. I joined coreboot IRC, it doesn't seem active. Any
> other communication channel to lookout for?
>
The channel is reasonably active for a medium size project like coreboot,
but activity differs _a lot_ depending on weekday and time.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [RFC] How should we manage tree-wide changes?

[Patrick Georgi via coreboot]

Hi everybody,

In our leadership meeting[1] we discussed how we should deal with tree-wide
changes (ranging from "new file header" to "some API is gone now"). The
concern was that right now, anything can change at any time, making local
development harder.

There have been a few ideas but nothing definite yet:

One idea was to declare some interfaces (e.g. those used by
src/mainboards/**), with varying stability horizons (e.g. "only change
right after a release"), or backward compatibility guarantees (although the
details still seemed hazy on how that could work in practice.)

Another idea brought up was to require that such changes come with
documentation and, ideally, migration support in the form of scripts and
the like. We had something like this in the past[2] and I created a
proposal[3] to establish it as a rule and build a culture around
documenting sweeping changes.

One doesn't exclude the other, and there may be other approaches on how to
make development easier without calcifying our codebase. Or maybe people
don't see a problem that needs fixing?

In any case, I wanted to bring it up in a larger forum to make sure that we
find rough consensus across the community before a decision is made on how
to proceed here.


Regards,
Patrick

[1] minutes at
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.9hutkekd50uf
[2]
http://web.archive.org/web/20130315025026/http://www.coreboot.org/Flag_Days
[3] https://review.coreboot.org/c/coreboot/+/52576
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question on loading SELF payload

[Patrick Georgi via coreboot]

Hi Ray,

Am Fr., 17. Sept. 2021 um 18:43 Uhr schrieb Ni, Ray :

> If yes, is there a recommended memory map (where is stack, where is
> coreboot ramstage, where is payload)?
>

ramstage is relocatable these days: romstage/postcar loads it near the top
of memory. ramstage's stack is kept in the ramstage's .bss section so close
to the top of memory, too.

Payloads aren't relocatable (some relocate themselves, but that happens
after coreboot finished, so no conflict there) so they're loaded to a fixed
address. This is usually a relatively low address (16MB, for example) as
there can be little assumption about the available amount of memory.

So as long as RAM is a bit larger than payload size + ramstage size + 16MB
(and that's normally the case these days) there's no risk of overlap.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Mailing list archive not updating

[Patrick Georgi via coreboot]

Hi Branden,

the issue should be resolved. Thanks for bringing it up!


Patrick

Am Di., 21. Sept. 2021 um 19:22 Uhr schrieb Branden Waldner <
scruff...@gmail.com>:

> I was just checking the mailing list archive and noticed that it isn't
> showing any new messages since September 9.
>
> I wasn't able to determine if there was a mailing list admin address
> to send this to, so I hope just sending it to the list is okay. (I did
> see this "mail...@coreboot.org alias for mailman admins" while
> searching, but wasn't sure about it, since it doesn't actually show up
> on the available lists page.)
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Hi Ricardo,

sorry for the late response, and that your project fell a bit by the
wayside. I guess discussion configuration frameworks is more attractive to
this community than testing frameworks (which also explains why we have ~3
config frameworks and only ~1 testing frameworks ;-) )

So yes, testing is something we really need to improve on. I'm not sure if
"contest" is the right solution to your particular problem though. The
first thing I see when opening up its page is something about mysql, and
scrolling down, something about submitting jobs to a server. That seems
more like a potential replacement to our Jenkins install (qa.coreboot.org)
rather than something to easily write end-to-end tests for our userland
tools.

Looking for options, my first instinct was to go for expect(1), but that's
really best for interactive uses - might be interesting if we ever grow
interactive tools, but so far we manage to stick to clean and tidy CLI.
Then I ran into https://github.com/bats-core/bats-core. That seems
maintained, reasonably minimal in its dependencies, it emits TAP which is
as good as JUnit in terms of Jenkins-integration (so we can have
qa.coreboot.org parse the results and give meaningful feedback on
review.coreboot.org), and it seems to be fairly widely used for similar
things to what you're doing, see
https://github.com/bats-core/bats-core/wiki/Projects-Using-Bats - it points
to many, many code examples, e.g.
https://github.com/docker/machine/blob/master/test/integration/core/core-commands.bats
which should cover the basic "call some command, see what it did" scenario
quite nicely.

Of course in the end it's all a matter of taste, and that's why I opened
the can of worms again that is Python-use in coreboot land. As python
hasn't seen a warmer reception than last time, I'd look for alternatives.
Maybe Bats could do? Of course, I haven't _actually_ used it yet and if
writing tests with that makes you want to scream and run away, we'd have to
look for other options (please, don't run away!)


Regards,
Patrick

Am Mo., 4. Okt. 2021 um 18:59 Uhr schrieb Ricardo Quesada <
ricar...@google.com>:

> Hi all,
>
> Regarding Patrick's 2nd point (end-to-end testing), what's the recommend
> way to go forward?
> I just need to run one of the Coreboot's utils (in this case "elogtool"),
> and make sure the output is the expected one.
>
> Should I use Contest, as suggested by Ron Minnich?
>
> Thanks!
>
>
>
> On Thu, Sep 30, 2021 at 10:18 AM ron minnich  wrote:
>
>> Speaking as the person who wrote the first few config tools in python,
>> and was happy to see the python dependency gone, I think bringing
>> python back in would be a mistake.
>>
>> Every single python test framework I've worked with works until there
>> is a problem, and I then find myself having to walk back a python call
>> trace, because what inevitably breaks is the test framework tooling.
>> It's why so many projects are removing python test frameworks.
>>
>> If you want a good test framework, get the linuxboot fork of
>> facebook's contest github.com/linuxboot/contest, written in Go, in use
>> at scale near you.
>>
>> It's easy to let the joy of building a build system overwhelm the
>> actual goals of a project. coreboot is not about being a build system.
>> It's easy to fall into the trap of creating an ever more complex
>> system that is more than is needed.
>>
>> On Thu, Sep 30, 2021 at 9:11 AM Patrick Georgi via coreboot
>>  wrote:
>> >
>> > Am Do., 30. Sept. 2021 um 17:29 Uhr schrieb Jack Rosenthal <
>> jrose...@google.com>:
>> >>
>> >> With respect to Kconfig, we (at Google) encountered a lovely build
>> flake after the Kconfig uprev last month in the coreboot tree that took a
>> couple of weeks to sort out and resolve. Some sort of automated validation
>> that the code is working could have possibly helped. Of course, the C
>> implementation of Kconfig has no tests at all. Some tests is better than
>> nothing.
>> >
>> >
>> > Let me put the record straight:
>> >
>> > - The last kconfig "uprev" hasn't been a simple update the way
>> https://review.coreboot.org/c/coreboot/+/57880 is, but rebuilt the
>> entire build system integration to ease maintenance
>> > - That issue sprang up because before the kconfig update, we were
>> shipping prebuilt parser files (C code) while now we made bison and flex
>> hard dependencies for our build
>> > - Tests covering the C code wouldn't have helped, because the issue
>> wasn't in the C code
>> > - The issue we were facing has been an external dependency (namely: the
>> Chromium OS development environment s

[coreboot] The coreboot.org edk2 repo is live! (But don't get a heart attack)

[Patrick Georgi via coreboot]

Hi everybody,

To facilitate cooperation on UEFI-as-a-payload work, we established a
mirror of tianocore's edk2 repo at https://review.coreboot.org/edk2. Unlike
other mirrors on review.coreboot.org, it's open for development.

It's updated regularly, but the default branch that we set up,
coreboot-stable202108, is based on edk2-stable202108, so there won't be
changes flowing in automatically to the branch we will focus on.

We will set up builders on qa.coreboot.org to cover that repo, so we get
the same "at the very least, it builds" guarantees that we have for any
coreboot contributions. Maybe we'll even get boot tests in the future, who
knows?

If you want to make coreboot+edk2 a viable option for starting hardware
(with the bonus compared to "regular" edk2 flows that hardware init happens
on the coreboot side, so if you want the same hardware to boot differently,
it can easily be made to be coreboot+SomethingElse!), there's plenty of
opportunities for developers.

Matt DeVillier (Mr. Chromebox) offered to push his patch train there which
(as I understand it) is an amalgamation of changes made in various edk2
forks in the coreboot ecosystem.

Something people have talked about is adding Microsoft's Project Mu (
https://microsoft.github.io/mu/) UI improvements to tianocore-as-a-payload,
which could find a good home there, as well.

Finally, SMMSTORE: it exists, it helps where it is supported to persist
UEFI variables, but as I understand it, actual support for devices is
rather limited.

Making coreboot+edk2 the premier option for booting UEFI platforms would
give the rest of us something to work with that is more pleasant than
trying to NERF vendor firmware until it stops doing all the things we don't
need it to do.

And if you don't care about UEFI (or if that's putting it mildly, even),
don't worry: this is only a payload. Just like we have FILO on our server
or SeaBIOS or depthcharge, this is just another option. But given the
market penetration of UEFI interfaces, it's an important one to get right.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Where to post PC BIOS related job ads?

[Patrick Georgi via coreboot]

For coreboot related jobs there's https://www.coreboot.org/jobs.html
More generally there's a channel called "firmware-jobs" in the OSFW slack:
https://osfw.slack.com/archives/C029KQWBWJZ which has an invite-bot at
https://slack.osfw.dev/

Am Di., 19. Okt. 2021 um 20:04 Uhr schrieb Jonathan Hartley <
tart...@tartley.com>:

> Hey,
>
> An old friend is now CEO at https://www.ctc.com/, and is looking for
> venues to advertise jobs for people with PC BIOS expertise. I said I'd ask
> around. I don't know much about the positions yet. They are hiring in the
> US or UK, are probably not directly coreboot related, but I believe there
> will be substantial overlap, so thought it worth asking for suggested
> places we ought to advertise.
>
> I already suggested posting on stackoverflow jobs, but wondered if there's
> anywhere more specialized he ought to try.
>
> I'll assume you do not want me to post the positions here once they are
> advertised (unless I get significant requests to do so.) I couldn't find a
> policy about job postings here, but saw a couple of old job posts, so
> figured a one-off would be ok.
>
> Thank you,
>
>Jonathan
>
> --
> Jonathan Hartley  USA, Central(UTC-5)
> @tartley  https://tartley.com 
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [arm64] queries on current support and future direction

[Patrick Georgi via coreboot]

Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot <
coreboot@coreboot.org>:

> Does the current coreboot/arm64 port allow executing only the ramstage of
> coreboot (say as a means of reducing the coreboot binary footprint) ?
>

I think that's really the gist of your inquiry, so let me stick to this
part:
The coreboot project obviously has little interest in "coreboot looking"
firmware being made up of other (usually less Free-with-a-capital-F)
components.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [arm64] queries on current support and future direction

[Patrick Georgi via coreboot]

Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot <
coreboot@coreboot.org>:

> We have couple of queries regarding the current support and future
> direction of arm64 port of coreboot:
>
>
>1. Does the current coreboot/arm64 execute post BL31 stage (assuming a
>separate BL2 stage loads BL31 and coreboot) ?
>   1. If no, would coreboot community be willing to support such a
>   flow (via a build-time flag) ?
>   2. Beyond the direct access of EL3 registers, what are the other
>   assumptions that the current coreboot/arm64 port has that need to be
>   addressed to allow such a NS-EL2 port ?
>2. Does the current coreboot/arm64 port allow executing only the
>ramstage of coreboot (say as a means of reducing the coreboot binary
>footprint) ?
>
> After some more community discussion about what's going on here, a
proposal:

TF-A is 3-clause BSD licensed which is compatible with the GPLv2 used by
coreboot. We already integrate that source tree in coreboot via git
submodules (3rdparty/arm-trusted-firmware).

What we could do to reduce your maintenance burden is to extend the
coreboot build system so that it can include sources from TF-A as part of
its romstage build. There'd be some work required to paper over the API
differences, and the end result (the coreboot-style romstage containing
TF-A code) would be a combined work under GPLv2.
This requires that everything becoming part of this amalgamation needs to
be GPLv2-compatible (coreboot code: GPLv2, TF-A code: typically 3-clause
BSD given their licensing regime).

Is that workable for you?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Am Sa., 16. Okt. 2021 um 02:40 Uhr schrieb ron minnich :

> Contest is easy to set up, easy to run, it's
> getting contributors. I understand it's a commitment of a day or so to
> figure out, but it's worth it in our experience. It's just not that
> hard.
>
> I believe starting down the python path is a bad start, and I'd rather
> not make it.

It is, but that's the code proposed on the repo.
I asked you about using Contest in a setting that comes without
client/server architecture, SQL database and a dedicated system under test.
Any news on that end?

I realize "it's only 160 lines", now; but that's how these things
> always start. They don't end well.
>
It's not a license for adding more of the same.

I consider it:
1. A signal that we care for testing our tools (as in: we like
contributions that improve our test coverage).
2. A signal of encouragement towards Ricardo who haplessly ran into the
trap of coreboot discouraging (ahem) python (we should document that!)
while trying to improve the project's general posture.

As soon as you bring up an alternative path that's acceptable to the
project at large, Ricardo offered to rewrite this specific test in whatever
we'll use officially (I suppose there's a caveat of it being "within
reason": don't get out your brainf*ck-based e2e testing framework!), and I
hereby offer to be the rewriter-of-last-resort in case Ricardo is gone by
then.

As is, Content looks like a solution for a _different_ problem. As soon as
we can clear up that confusion, I'm all for using it, and the faster we get
that done, the faster this python code is removed again.

Therefore I guess one could say that I also consider this change (and my
proposal of merging it):

3. A rather blunt tool to get you to resolve the open questions regarding
Contest ;-)


Patrick
___
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?!?

[Patrick Georgi via coreboot]

Am Fr., 15. Okt. 2021 um 19:50 Uhr schrieb Ricardo Quesada <
ricar...@google.com>:

> In the meantime, would it make sense, as Jack mentioned, to land my change
> [1] as it is? It is small/simple and it only has  ~160 LoC Python.
> For comparison, other util are using Python: util/qualcomm has ~3500 LoC
> Python [2]
> I'll happily migrate + integrate my test once a end-to-end test has been
> chosen.
>
I'm fine getting it in for now, but it won't see testing every build.

Will wait for other people to chime in, though. If I don't see pushback
against getting this in as-is (with the understanding that it might be out
quickly again once we decide on a plan of action) by next Thursday at noon
in Germany (UTC+0200), I'll see that I submit it.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot EFI working group meeting minutes - 12 October 2021

[Patrick Georgi via coreboot]

Am Mi., 13. Okt. 2021 um 20:51 Uhr schrieb Peter Stuge :

> > Linux is expecting more and more to use EFI supplied interfaces (UEFI
> > Boot Services in particular, even if many are stubbed out) so like it or
> > not, we’re going to need to support these interfaces.
>
> LOL!
>
The fun part about this segment was that all we could go by was hear-say
and unfounded rumors that went around.
I attended that meeting but from what I've heard there, no such expectation
might actually exist, and it might just have been a weird game of telephone.

This is super embarrassing for Linux and Linux Foundation, but of
> course also 100% to be expected. Linux plods along towards absolute
> uselessness.
>
Remember that LF is a trade organization (501(c)(6)), not a charitable
organization (501(c)(3)).
This difference in target audience compared to most open source
organizations informs their strategic decisions, and keeping that in mind
minimizes surprises and heartburn.

> * The coreboot repo will host an EDK2 fork for use as a coreboot payload.
> I think the planned tighter integration is a significant first step
> towards coreboot becoming UEFI.
>
This isn't about a "tighter" integration: we already have that payload, and
we had Tianocore-as-a-payload integration since 2013 (commit
cc5b3446624cf85e13a8130a524e81360c5f4239)

It minimizes the time each individual, who for one reason or another works
on edk2, needs to spend on edk2.
OTOH I haven't found a better way to make developers fervent edk2 opponents
than simply showing them the source, so there's that.

> * Definitely no one-size fits all solution here
>
> The challenge is great. The coreboot community must be strong and
> vigilant to not allow coreboot to get locked into EDK2/UEFI like has
> already happened with vboot. The vboot case arguably hurts coreboot a
> lot less, but unfortunately all incentives are wrong for quality!
>
I'm not sure why vboot makes this sudden appearance here.

I don't expect this to go at all well for coreboot, but fingers crossed!
>
Want peanuts?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Build failure due to gcc update to 11.2

[Patrick Georgi via coreboot]

Hi Selma,

It might help to know what kind of build failures these are. Could you post
them somewhere (e.g. ticket.coreboot.org) for discussion?


Regards,
Patrick

Am Sa., 25. Sept. 2021 um 02:22 Uhr schrieb Bensaid, Selma <
selma.bens...@intel.com>:

> Hi,
>
> We are facing build failure due to the
> https://review.coreboot.org/c/coreboot/+/54050 # util/crossgcc: Update
> gcc to 11.2
>
> Does anyone else face the same issue?
>
> Thanks,
>
> Selma.
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Patrick Georgi via coreboot]

Hi everybody,

Historically, coreboot avoided depending on python too much (we got rid of
an entire python based configuration and build system, for example), with
few minor exceptions.

The main reason has been that while python code is quick to slap together,
it has demonstrated a penchant for breaking in all kinds of mysterious ways
(python 2->3 really was just a slightly bigger instance of what's going on
in python all the time), and its users demonstrate a disregard for their
fellow developers as demonstrated by endless stack traces on trivial errors
(or is the language too complicated to properly catch them all?)

While probably nice for one-off prototypes, long term maintenance is a
concern: this project has over 20 years of history under its belt, with
more to come.

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.

There are two bigger initiatives proposed that would significantly increase
our python footprint:
1. Replacing Linux's kconfig with kconfiglib (
https://review.coreboot.org/c/coreboot/+/48679)
2. Using pytest for end-to-end testing utilities (
https://review.coreboot.org/c/coreboot/+/57869)

Compared to the "inject a hash value at a fixed location" scripts, these
would probably be here to stay, and sufficiently integrated that everybody
will have to deal with them.

People spending time working on python code when it has no chance to land
isn't a good use of their time and we should avoid that in the project.

People spending time arguing that python shouldn't be used (to avoid
the other outcome) even though the project's culture shifted and is now
accepting Python isn't creating a great community for anybody.

To avoid these scenarios, could we possibly nail down the policy on python
in coreboot?


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Am Mi., 29. Sept. 2021 um 19:47 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:

> At a minimum, I think we should consider introducing Python on an optional
>>> basis (i.e., the C Kconfig implementation only gets used if a Python
>>> interpreter is unavailable), but making it required would be even better.
>>>
>> That idea is... horrible. Instead of only bringing in the python
>> dependency we'd also create an environmental dependency that can silently
>> introduce behavioral differences.
>>
> Fair, require python then. Most people have it on their systems anyways.
>
Well, the question I put up on the mailing list, for the community to
decide, is if we should lift our quasi-ban on python in the project. I
added you and the other contributors proposing python changes in Cc to this
email as a courtesy because you're not all registered on the project's
discussion venue.

The default alternative to "let's do something horrible" isn't "let's do
this other thing instead", it's "don't change anything at all". Don't look
further than the requirement for proposed changes to make it through
review: Without "don't change anything" as default, we could just open up
write access to the main repo and branch for everybody and everything - we
don't.

Only if we decide that extensive python use in the coreboot tree is now
okay, kconfiglib is even eligible for discussion.

So far the only argument in favor of python in _any_ way has been "it's
installed everywhere". That was true 20 years ago as well, and yet still we
had a fair amount of trouble with python. Look no further than the recent
uptick in support requests on IRC by people trying to build coreboot +
"stable" Tianocore: It fails because python moved on while the tagged
Tianocore version did not and its build tooling relies on python. So I
agree that "installed everywhere" is a necessary condition, but given how
badly python's maintainers historically treated their user base, I don't
think it's a sufficient condition, by far.

tl;dr: people of coreboot, opinions?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Am Do., 30. Sept. 2021 um 15:22 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:

> IMO, any codebase is significantly easier and safer to maintain if there
> are tests.
>
Since we kinda-sorta support SPARK in our toolchain (not for the host
though at this time), maybe we should evaluate doing a rewrite in SPARK
then: Formal verification beats spot tests which may or may not cover the
troublesome situations. ;-)
(What I mean is that it's always possible to up the ante, not that we
should actually do that. I'd rather get rid of the kconfig language, and
even that idea has dubious value in this context.)

As for the idea of a Python 4 you seem to have here (or if it does come,
> repeating the massive language differences we had between 2 and 3), it's
> unlikely to happen. Guido says that a "Python 4" at the scale Python 3 was
> is unlikely to happen
> 
> .
>
If Python 3->4 is only half as painful as 2->3, this would still be true -
and still mean misery for 5+ years. No thanks.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Am Do., 30. Sept. 2021 um 17:29 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:

> With respect to Kconfig, we (at Google) encountered a lovely build flake
> after the Kconfig uprev last month in the coreboot tree that took a couple
> of weeks to sort out and resolve. Some sort of automated validation that
> the code is working could have possibly helped. Of course, the C
> implementation of Kconfig has no tests at all. Some tests is better than
> nothing.
>

Let me put the record straight:

- The last kconfig "uprev" hasn't been a simple update the way
https://review.coreboot.org/c/coreboot/+/57880 is, but rebuilt the entire
build system integration to ease maintenance
- That issue sprang up because before the kconfig update, we were shipping
prebuilt parser files (C code) while now we made bison and flex hard
dependencies for our build
- Tests covering the C code wouldn't have helped, because the issue wasn't
in the C code
- The issue we were facing has been an external dependency (namely: the
Chromium OS development environment shipping a broken version of bison(1))
- Fixing bison in CrOS wouldn't have helped any because we have to assume
that other users come with the same kind of broken bison tool
- The fix has been to ship pre-built files again to remove an external
dependency

The alternative that we did actually consider was to add support for
building bison and flex to util/crossgcc/buildgcc. For three files that's
sheer madness, so we went back to precompiled files instead.

In relation to your proposal to adopt kconfiglib: We can run into any kind
of external tool demonstrating weird behavior. That's true for bison (as
seen here) just as it can be true for arbitrary python versions (even when
specified to be "python 3.6+" or whatever): Linux distributions do strange
things to their packages, and we're not a Linux-only project, so even
official, unchanged, straight-from-the-server python might behave
unexpectedly on less well exercised platforms.

The best way to reduce issues on that end is to avoid external dependencies
- like bison, like flex... like python.
I'd _love_ to avoid the dependency on the host compiler as well, but that's
one of those "sheer madness" moments when you support a multitude of
operating systems on as many architectures.

Introducing kconfiglib (and through it, a deep reliance on python) just
doesn't seem to provide comparable benefits.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Git reports an interesting error message

[Patrick Georgi via coreboot]

Hi Gregg,

Am Do., 30. Sept. 2021 um 21:16 Uhr schrieb Gregg Levine <
gregg.drw...@gmail.com>:

> fatal: unable to access 'https://review.coreboot.org/coreboot.git/':
> SSL certificate problem: certificate has expired
>

Given the timing, I wonder if
https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/ might be the
cause: We serve a pretty complete certificate chain but if your client
doesn't support the root certificate that we now rely on exclusively
(because the other path using the more popular root has expired), your
client won't like any of our certs.

You could try changing the environment to carry GIT_CURL_VERBOSE=true to
see what's going on, or maybe just look at updating the ca-certificate
store of your system.

Alternatively you could set up the SSH based access method to access the
server, as outlined in
https://doc.coreboot.org/tutorial/part2.html#step-2a-set-up-rsa-private-public-key
but you might run into more issues with certs going forward on other
servers if the cert store is old.


All the best,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
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?!?

[Patrick Georgi via coreboot]

Am Mi., 29. Sept. 2021 um 16:43 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:

> Overall I think introducing Python to the build would provide net benefit,
> mainly from Kconfiglib, but could also find other good uses in e2e tests
> like Ricardo was working on. Most people's Linux distros ship with a Python
> interpreter too, so most developers would be unlikely to notice the extra
> dependency introduction.
>
This is assuming that all python environments are alike. Experience
disagrees.


> In terms of Kconfiglib, we have a lot to gain by switching away from the
> Linux C implementation of Kconfig, mainly the ~30kloc of C code that we've
> forked from the Linux tree and hacked in our own customizations
> (KCONFIG_NEGATIVES). With Kconfiglib, these customizations get turned into
> a miniature Python script
> 
> that we use to handle our custom header format, and a stable API to work
> off of so that we can uprev Kconfiglib without needing to change our
> scripts.
>
The customizations are a set of patches with simple maintenance (as
documented in https://review.coreboot.org/c/coreboot/+/57879).

In terms of Kconfiglib's stability and track record: I think it has it
> covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already
> without any issues at all.
>
This project deals in 20 year timelines. Zephyr is at 5.5 years, while
depthcharge is used exclusively in a tightly controlled environment (and
even there we had - and have - our share of pythonic problems).

At a minimum, I think we should consider introducing Python on an optional
> basis (i.e., the C Kconfig implementation only gets used if a Python
> interpreter is unavailable), but making it required would be even better.
>
That idea is... horrible. Instead of only bringing in the python dependency
we'd also create an environmental dependency that can silently introduce
behavioral differences.

This project has the ability of building bit-identical firmware images on
hosts spanning all kinds of CPU register sizes, endianness and operating
system families. If you ever heard of "hermetic builds" being a good idea:
the trustworthiness of our build is stronger - and part of making that
possible is being (relatively) careful with picking our dependencies.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Build failure due to gcc update to 11.2

[Patrick Georgi via coreboot]

Hi Selma,

Am Mo., 27. Sept. 2021 um 17:54 Uhr schrieb Bensaid, Selma <
selma.bens...@intel.com>:

> Here the build error, I checked that the error does not occurs with gcc 12
> revert. We are using Ubuntu 18.04 for our build nodes.
>
>

> src/drivers/bus/i2c/designware.c: In function 'i2c_set_bus_speed':
>
> src/drivers/bus/i2c/designware.c:322:53: error: taking address of packed
> member of 'struct ' may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>
>   322 |MIN_HS_SCL_HIGHTIME,
> >hs_scl_hcnt,
>
>   |
> ^~
>

That issue seems to occur in depthcharge (we don't have that path in
coreboot itself), for which we have fixes: this one in particular is fixed
by the commit at
https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/3181723
but a few more (including a change to disable that type of warning because
vboot runs in a few more instance) in the patch train.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org