[coreboot] Re: Makefile classes-y vs subdirs-y

[Patrick Georgi via coreboot]

libpayload uses both.

For example, line 52 defines a class "libcbfs", line 64 adds the subdir 
"libcbfs".And
https://elixir.bootlin.com/coreboot/latest/source/payloads/libpayload/libcbfs/Makefile.inc
 adds its sources to the libcbfs class.

Roughly speaking: subdirs-y just makes the build system scan the Makefile in 
those subdirs. classes-y creates a new type of build artifact (e.g. 
bootblock/romstage/ramstage in coreboot, or the various libraries in 
libpayload), and then $classname-y collects the sources related to that 
artifact.


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

[coreboot] Re: RFC: Behavior of make *config

[Patrick Georgi via coreboot]

29. November 2023 12:14, "Poeche, Uwe via coreboot"  
schrieb:
> Your above mentioned patch helps (I'm a reviewer of this). When I tried I 
> also noticed that this
> does not point out loudly if you have problems in your config. So the 
> approach without the patch
> (in result more strict) is from my opinion better if we have a workaround 
> beside edit config
> manually. In the parallel thread here Martin mentioned the same workaround as 
> you mentioned on IRC
> on Monday. But I get not work.

Right, because the code checks for the variables' presence, not for their 
value. I was mistaken on that, as was Martin apparently.

I modified the changeset so that it still doesn't fail on warnings during 
*config, but still prints them. That doesn't matter a whole lot with menuconfig 
and nconfig because they proceed to clear the screen immediately after, but 
oldconfig and olddefconfig are somewhat more helpful now:

$ make oldconfig
/home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB
*
* Restart config...
*
...

$ make olddefconfig
/home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB
#
# configuration written to /home/pgeorgi/coreboot/.config
#

Does that help?


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

[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs

[Patrick Georgi via coreboot]

On 29.11.23 00:20, Martin Roth via coreboot  wrote:

Hey Mike,
I think you should be able to just append change the kconfig values when you 
run make to override the current settings.

something like
`make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`

if we update where they're set in the makefile from := to ?=, you could even 
just have them set as environment variables so they don't need to be on the 
command line.


Kconfig doesn't check for the value in the variables, just for their presence. 
Therefore we'd need to unexport the variables, and that's not possible 
per-target (despite the gnu make docs claiming otherwise) or on the make 
command line.

I started a discussion in another thread on that, maybe we could discuss this 
over at 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs

[Patrick Georgi via coreboot]

On 28.11.23 19:04, Mike Banon  wrote:

Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that
outweigh these potential issues?

It ensures that we don't silently build with unknown symbols (typo in manual 
editing, changes to the config, ...), and wonder why CONFIG_UART_DEBUG=y 
doesn't actually enable serial output on select Intel chipsets (solution: it 
was renamed 5 years ago).

I put a subset of your question up for discussion[0] earlier today, including a 
patch that tweaks the behavior to make things pass the *config targets.
That should resolve your issue while keeping the safety benefit, no?


Patrick

[0] 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] RFC: Behavior of make *config

[Patrick Georgi via coreboot]

Hi everybody,

I updated Kconfig to track latest Linux last week and that brought some 
behavioral change with it. While these changes are appreciated in some respect, 
they also complicate work in others.

I now proposed https://review.coreboot.org/79298, a change that exempts _all_ 
*config targets from strict symbol checking under the assumption that any 
attempt to edit a config should work even if the old configuration is unclean. 
It will save a clean copy if it saves on exit.

A regular build will still fail with an error like this:

/home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB

ERROR: 1 warnings encountered, and warnings are errors.

make[1]: *** [build/util/kconfig/Makefile.real:76: olddefconfig] Error 1
make: *** [Makefile:219: build/config.h] Error 2

Running `make olddefconfig` manually (that is, explicitly stating that you want 
to run the command) would clean it up.

Now, given that this is a rather big semantic change, I wanted to make sure 
that the wider community can provide their input on how to approach this issue 
properly.

Before last week, only `make oldconfig` was exempt from checking, and the 
checks made by the other *config targets were much more lenient. With this 
approach, all *config targets clean up the config (and will do so silently, 
which might be a concern!) but when the config isn't right, the build will 
fail, and loudly.

Thoughts?

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

[coreboot] Re: make menuconfig - is broken after commit 7eab8ef (Linux 6.2's kconfig) and follow-ups

[Patrick Georgi via coreboot]

Am 26.11.2023 um 18:15 schrieb Mike Banon:

/usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation
against `acs_map' in read-only section `.text'
/usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help':
mconf.c:(.text+0x1770): undefined reference to `stdscr'
/usr/bin/ld: mconf.c:(.text+0x177c): undefined reference to `stdscr'
/usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_item':
checklist.c:(.text+0x82): undefined reference to `wattrset'
/usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove'
/usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch'
/usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove'
/usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset'



Curious, if anyone else has the same error? Please take a look at this


Oops! https://review.coreboot.org/c/coreboot/+/79264 fixes it for me.


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

[coreboot] Re: coreboot has switched the default git branch from "master" to "main"

[Patrick Georgi via coreboot]

12. September 2023 17:59, "Felix Singer"  schrieb:

> it seems people are still able to use refs/for/master. Some patches
> were just pushed for master today, but they are already rebased to the
> main branch now. Can we prevent that or can we only prevent submissions
> to the master branch?

I extended the ACLs to catch more cases. Other than that, we'll monitor the 
situation and move things around if patches end up in the wrong place.


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

[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

[Patrick Georgi via coreboot]

Am 06.09.2023 um 18:57 schrieb Williams, Hannah:

Here are the reasons why we cannot open source Meteor Lake uGOP:
- It has licensed code for HDMI and other industry specifications (i915 also 
cannot open source HDMI 2.1)
- VBT spec is not open sourced
There will have to be a re-design of the uGOP component so that we can work 
around above issues and still open source. This is being considered for future 
SOCs.


At the risk of repeating myself: That seems like a you-problem to me.

By now the question (and request by Intel customers) of having GOP (or 
its predecessor vgabios) available under open source terms is older than 
some of the contributors to coreboot.


Given that https://www.phoronix.com/news/Intel-MTL-Graphics-Linux-Stable 
claims that the Meteor Lake GPU bring-up in Linux is now ready, maybe 
those folks, who know both your GPU design _and_ how to work in an open 
source environment could help out the GOP folks?


(And don't complain about any choices made in libgfxinit: Intel had tons 
of time to come up with an adequate solution, thereby shaping the 
standard solution in that problem space - and decided not to. Eventually 
people put in _their_ effort to support _your_ hardware.)



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

[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP

[Patrick Georgi via coreboot]

Am 27.08.2023 um 19:18 schrieb Tim Wawrzynczak:
Also, to be perfectly honest, I don't understand why this "sign-of-life" 
feature is so critical that it must be available during development.
When I (and a few others) came up with the idea at Google, the entire 
point of the feature is so that end-users who must undergo some
kind of firmware update before memory is available or require a new DRAM 
training session can know that their device which usually
boots in a few seconds will take longer during this specific boot. It is 
not particularly useful during development, as developers should know why

their device is taking longer to boot.


This is an important point: The "Sign of Life" stuff is only needed when 
the cache is busted. The only situation where we expect (and, as far as 
I can tell, see) that coming up is when the memory init code changes 
incompatibly.


By definition the earliest point in time where this can happen is with 
the first firmware update (if that already breaks the cache, which isn't 
a given).


Because of this and what I said up above about porting to libgfxinit as 
soon as i915 patches are available, there ought to be enough time
in the product lifecycle to do that port before the product is released, 
hence making this uGOP unnecessary.


Given the above, SOL is only required after the device is on the market, 
an even more comfortable position: By that point the entire "welp, muh 
secrets!!!1" charade is already over.


(And yes, that requires somebody to keep track of additional development 
effort/costs after release / before the first cache-breaking update)


More options to consider: extend the update procedure so that it can 
convert an older cache format into a newer cache format as required. 
That sidesteps that entire "we need to tell the user that their device 
is busy with no interaction for the next 60 seconds doing stuff they 
can't appreciate because it's too opaque."



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

[coreboot] [coreboot - Feature #213] Have the bug tracker report activity to the mailing list

[Patrick Georgi]

Issue #213 has been updated by Patrick Georgi.

Related links updated

Removed IRC as a target given the chaos we have around chat channels right now 
with libera.chat and matrix decoupling.
Meanwhile, mailing list receives ticket updates


Feature #213: Have the bug tracker report activity to the mailing list
https://ticket.coreboot.org/issues/213#change-1639

* Author: Patrick Georgi
* Status: Resolved
* Priority: Normal
* Assignee: Patrick Georgi
* Category: infrastructure
* Start date: 2019-06-05

This helps make the tracker more visible and therefore useful



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Feature #213] (Resolved) Have the bug tracker report activity to the mailing list

[Patrick Georgi]

Issue #213 has been updated by Patrick Georgi.

Subject changed from Have the bug tracker report activity to IRC and the 
mailing list to Have the bug tracker report activity to the mailing list
Status changed from New to Resolved
Related links updated


Feature #213: Have the bug tracker report activity to the mailing list
https://ticket.coreboot.org/issues/213#change-1638

* Author: Patrick Georgi
* Status: Resolved
* Priority: Normal
* Assignee: Patrick Georgi
* Category: infrastructure
* Start date: 2019-06-05
* Related links: Removed IRC as a target given the chaos we have around chat 
channels right now with libera.chat and matrix decoupling.

This helps make the tracker more visible and therefore useful



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #309] crossgcc: Handle missing tarballs in download step

[Patrick Georgi]

Issue #309 has been updated by Patrick Georgi.

Assignee set to Felix Singer


Bug #309: crossgcc: Handle missing tarballs in download step
https://ticket.coreboot.org/issues/309#change-1634

* Author: Patrick Georgi
* Status: New
* Priority: Normal
* Assignee: Felix Singer
* Start date: 2021-05-29

We keep a copy of the tarballs used by crossgcc in coreboot releases in 
https://coreboot.org/releases/crossgcc-sources/, so we should fall back if a 
download failed.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Termin mit Hinweis abgesagt: coreboot Leadership Meeting - Mi 9. Aug. 2023 19:00 - 20:00 (MESZ) (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:20230809T11
DTEND;TZID=America/Denver:20230809T12
DTSTAMP:20230809T143943Z
ORGANIZER;CN=Patrick Georgi:mailto:pgeo...@google.com
UID:gg46f4n5p6f9gl466ara69o1us_r20230726t170...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=WI
 M;X-NUM-GUESTS=0:mailto:wvervo...@eltan.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=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Do
 ssym Nurmukhanov;X-NUM-GUESTS=0:mailto:dos...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ch
 ristian.wal...@9elements.com;X-NUM-GUESTS=0:mailto:christian.walter@9elemen
 ts.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ma
 rshalldawson...@gmail.com;X-NUM-GUESTS=0:mailto:marshalldawson...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ga
 uml...@gmail.com;X-NUM-GUESTS=0:mailto:gauml...@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=OPT-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=We
 rner Zeh;X-NUM-GUESTS=0:mailto:wero...@gmail.com
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=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=za
 olin.dais...@gmail.com;X-NUM-GUESTS=0:mailto:zaolin.dais...@googlemail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=rm
 inn...@gmail.com;X-NUM-GUESTS=0:mailto:rminn...@gmail.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=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ep
 e...@google.com;X-NUM-GUESTS=0:mailto:epe...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-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=tc
 rawf...@system76.com;X-NUM-GUESTS=0:mailto:tcrawf...@system76.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ro
 cky Phagura;X-NUM-GUESTS=0:mailto:rphag...@fb.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN="D
 esimone, Nathaniel L";X-NUM-GUESTS=0:mailto:nathaniel.l.desim...@intel.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=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fe
 lix.singe...@gmail.com;X-NUM-GUESTS=0:mailto:felix.singe...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=st
 efank.reina...@gmail.com;X-NUM-GUESTS=0:mailto:stefank.reina...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Sh
 elley Chen;X-NUM-GUESTS=0:mailto:shc...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=no
 gasm...@google.com;X-NUM-GUESTS=0:mailto:nogasm...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=kr
 ama...@google.com;X-NUM-GUESTS=0:mailto:krama...@google.com
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=ja
 

[coreboot] Re: New Defects reported by Coverity Scan for coreboot

[Patrick Georgi via coreboot]

"Angel Pons"  schrieb:

> We made the patches that made Coverity angry about this `format_pn()`
> function. However, this is not an actual bug: the
> `eeprom_read_serial()` function returns a buffer that is at most 32
> (`HERMES_SN_PN_LENGTH`) characters long, and the length of the
> `prefix` string is known at build-time (it's a string literal in both
> call sites) to be less than 32 characters long.

There's no guarantee that the string returned by eeprom_read_serial() is 
0-terminated (not even in its implementation) and strcpy proceeds until the 
first 0 it sees, even if that's only 2GB later. Use strncpy instead to prevent 
out of bound copies.


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

[coreboot] Re: Can we make unit test failures more obvious in Gerrit?

[Patrick Georgi via coreboot]

Am 02.09.2022 um 03:38 schrieb Julius Werner:

Right now, when you have a CL that builds fine but fails unit tests,
Jenkins with Verified -1 it with a failure page like this
https://qa.coreboot.org/job/coreboot-gerrit/215770/ , which just says
"Test Result (no failures)". If you know your way around Jenkins you
can click on the "Console Output" link on the left and scroll down to
see the actual unit test errors, but most people who see this for the
first time will probably be very confused and have a hard chance
finding that on their own.


This isn't "the unit test fails", it's "the unit test failed to compile".


Is there any way we could make that more obvious and display the unit
tests as a real element among the test results (or at least put some
sort of "click Console Output to see errors" message on there)?
Unfortunately I have no idea how anything on that page is configured
or generated -- Patrick or Martin, I hope one of you guys would know
more?


We'd have to wrap the build process for the unit tests to report into 
junit on error.


tests/Makefile.inc already looks for JUNIT_OUTPUT. The target in 
tests/Makefile.common for $($(1)-bin) would have to be extended to 
create a report on build failure.


The junit.xml target in payloads/libpayload/Makefile.inc might serve as 
inspiration.



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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Patrick Georgi via coreboot]

Hi everybody,


22. Juli 2022 16:56, "Patrick Georgi via coreboot"  
schrieb:

> On August 1, I'll change the coreboot repo to use that submission strategy 
> and then we'll have a
> month to see how it works for us. Late August we can make a decision whether 
> to stay with Rebase
> Always or to go back to Cherry-Pick.

This is now live, let's see how it goes.

(And if it's too horrible, it's trivial to change back at a moment's notice)


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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Patrick Georgi via coreboot]

Hi again,

On 2022-07-13 I wrote:

> David proposed that we could try out "rebase always" for a while (maybe a 
> month) to see how it
> feels.

This idea has been positively received on the list and nobody voiced objection 
to such a change.

As a server admin I declare that August will be "'Rebase Always' test month".

On August 1, I'll change the coreboot repo to use that submission strategy and 
then we'll have a month to see how it works for us. Late August we can make a 
decision whether to stay with Rebase Always or to go back to Cherry-Pick.


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

[coreboot] [coreboot - Feature #404] (New) Support board variants in board-status

[Patrick Georgi]

Issue #404 has been reported by Patrick Georgi.


Feature #404: Support board variants in board-status
https://ticket.coreboot.org/issues/404

* Author: Patrick Georgi
* Status: New
* Priority: Normal
* Category: infrastructure
* Target version: none
* Start date: 2022-07-17

The board-status tool predates our concept of board variants, which we now use 
extensively.
This means that the board list on https://coreboot.org/status/board-status.html 
is always incomplete, so add support for parsing out board variants, showing 
them in the board list and properly attributing board-status data to variants.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Reconsidering the Gerrit submission strategy

[Patrick Georgi via coreboot]

Hi everybody,

I was recently made aware that Gerrit now supports adding metadata to
commit messages in the "rebase" strategy. The "cherry-pick" strategy that
we're using has been chosen over everything else primarily due to this
capability.

Some details:
Gerrit supports different ways of committing changes into branches when
developers submit them, with different effects on which changes are
considered ready and how they show up in the commit history.

The two main contenders are "cherry-pick" and "rebase always".

Both create a linear history (unlike some "merge" strategies that can
create merge commits.
Both add metadata to the commits, all that "Reviewed-on", "Reviewed-by" etc
in the commit message.

Cherry-pick considers every change on Gerrit on its own. Even if you push a
patch train of 50 commits, it allows submitting commit #49 individually.
That gives some flexibility (if these commits are truly independent) but
also creates risk: if changes are merged out of order, we might break the
tree with otherwise perfectly good commits, for example when a new API is
used that is only added by a previous commit.

Rebase always considers patch trains: To submit commit #49, the commit
itself and all its 48 ancestors need to be ready for submission. It becomes
a one-click operation in the UI and ordering is honored. On the other hand,
picking an individual commit is a manual operation now (cherry-pick to
become its own patch train, push, re-review).

Speaking of UI, depending on the strategy the "readiness" marker in the UI
changes behavior, too: With "cherry-pick", each commit is compared against
the branch individually, with a "merge conflict" notification if the commit
on its own would fail to merge. With "rebase always" the entire patch train
up to that point is considered.

It's a matter of trade-offs, but given that "rebase always" can now add the
metadata that was the deal breaker for anything but cherry-pick back in the
day, I wanted to know how y'all feel about changing or keeping the
submission strategy.

David proposed that we could try out "rebase always" for a while (maybe a
month) to see how it feels.


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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Patrick Georgi via coreboot]

Am 12.04.2022 um 23:54 schrieb Karl Semich:
Obviously a way to sidestep all this would be to simply test the board 
in question, which is a small investment of money and time.
I appreciate that you volunteer to do that for Quark. Can't be too bad, 
it's a small investment of money and time, after all.



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

[coreboot] Fwd: [Lvfs-announce] LVFS Community Meeting: Alternate Branches

[Patrick Georgi via coreboot]

Might be interesting for a few folks here?

-- Forwarded message -
Von: Richard Hughes 
Date: Di., 25. Jan. 2022 um 12:20 Uhr
Subject: [Lvfs-announce] LVFS Community Meeting: Alternate Branches
To: 


Hi all,

We normally only allow the silicon vendor, the ODM or the OEM to
upload firmware for hardware, and only if that entity has legal
permission to upload the file to the LVFS. The security model for
fwupd relies on standardised registries like USB and PCI, along with
immutable DMI information to ensure that only the correct vendors can
ship firmware for their own hardware, and nothing else.

This strict rule breaks down where the OEM responsible for the
hardware considers the device end-of-life and so will no longer
receive updates (even for critical security issues). There may also be
a situation where there exists an alternate (not provided by the
vendor) free software re-implementation of the proprietary firmware,
which may be desired for licensing reasons.

In these situations we can now allow another legal entity to also
upload firmware for the hardware, but with a few restrictions:

* The end user must manually and explicitly opt-in to the new firmware
stream, perhaps using fwupdmgr switch-branch, with a suitable warning
that there is no vendor support available and that the hardware
warranty is now invalid. This means that the alternate firmware must
set the device branch appropriately without any additional
configuration.

* The alternate firmware must not ship with any code, binaries or
generated assets from the original hardware vendor (perhaps also
including trademarks) unless written permission is provided in writing
by the original hardware vendor.

Some real world examples might be providing a Open Source BCM57xx GPL
firmware for Broadcom network hardware, or providing a coreboot system
firmware for a long-EOLed Lenovo X220 ThinkPad. In this instance, the
LVFS may be the legal entity distributing the firmware, which is
actually provided by a trusted contributor who has permissions to
upload and hardware to test the update. In other cases another legal
entity (like coreboot itself) or an individual trusted contributor may
be considered the distributor.

In all cases the specifics should be discussed with the LVFS
maintainers, as should any concerns by licensors or existing
distributors.

I've decided to make this functionality the topic of the first LVFS
Community Meeting which is happening this Friday at 1700 GMT. See
https://github.com/fwupd/fwupd/wiki/LVFS-Community-Meeting-2022-01-28
for instructions. If you would like me to add you to the Google
calendar invite please let me know. If you're not comfortable joining
the Community Meeting I'm happy to get private feedback via email too.

Richard
___
LVFS-announce mailing list
lvfs-annou...@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lvfs-announce


-- 
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 Jay,

from your description I'm not clear what you added to your root certificate
store.
Let's Encrypt provides their root certs in various formats at
https://letsencrypt.org/certificates/
Things should work after you add those (right now, review.coreboot.org is
certified through the X1 root)

If that doesn't help, the issue might be incompatible cipher suite
requirements (your clients only supporting cryptographic algorithms that
the server doesn't support) but I don't think we changed anything in that
regard on the servers in the last few years.


Patrick

Am Di., 18. Jan. 2022 um 02:26 Uhr schrieb Jay Talbott <
jaytalb...@sysproconsulting.com>:

> Ok, I'm running into the same issue on an Ubuntu 16.04 system.
>
> $ git clone https://review.coreboot.org/coreboot.git
> Cloning into 'coreboot'...
> fatal: unable to access 'https://review.coreboot.org/coreboot.git/':
> server certificate verification failed. CAfile:
> /etc/ssl/certs/ca-certificates.crt CRLfile: none
>
> In the past I've had no problems with cloning coreboot on this system, but
> now it's broken with the same error message as Gregg encountered.
>
> I've updated the ca-certificates, but it said I already had the latest
> certs and that didn't fix it.
>
> I found an article online about pulling the cert from coreboot into a .pem
> file, and then appending that into the ca-certificdates.crt file, but that
> didn’t work either.
>
> I imagine there are others that have run into this... what's the solution?
>
> Thanks,
>
> - Jay
>
> > -Original Message-
> > From: Gregg Levine 
> > Sent: Thursday, September 30, 2021 6:16 PM
> > To: Patrick Georgi 
> > Cc: coreboot 
> > Subject: [coreboot] Re: Git reports an interesting error message
> >
> > Hello!
> > Okay update. This is WSL remember, I grabbed an Ubuntu image that I'd
> > previously claimed and allowed the automation to install it.  I should
> > mention that I also followed normal Debian based Linux methods to
> > upgrade it.
> > And I then pulled over a tar compressed with Bzip2 tree of my entire
> > work, and extracted it. Inside it I went into the original coreboot
> > directory from a while ago. Inside it I ran the git command steps to
> > update it. I did not see the error message.
> >
> > I did note that it found problems with updating an earlier source
> > tree, but had no problems pulling down a new one. The problems were
> > related to the contents. I renamed the tree to call it a backup. It is
> > still working to retrieve things. So I believe the problems were
> > related to the SuSe image I was using, it was not put together in a
> > form that could be properly updated. Yes I agree with you regarding
> > the pending certificates but will the problem such as it is impact us?
> > And when?
> > -
> > Gregg C Levine gregg.drw...@gmail.com
> > "This signature fought the Time Wars, time and again."
> >
> > On Thu, Sep 30, 2021 at 6:19 PM Gregg Levine 
> > wrote:
> > >
> > > Hello!
> > > Okay, I tried setting that variable, and it did not show me anything.
> > > I also looked at the page you suggested. Interesting, I suspect I'd
> > > need to do that should I go ahead and want to contribute.
> > >
> > > As for updating certificates, the big problem is that is a WSL
> > > prebuilt image, and someone else built it, and deliberately broke the
> > > methods SuSe uses to update things.
> > > -
> > > Gregg C Levine gregg.drw...@gmail.com
> > > "This signature fought the Time Wars, time and again."
> > >
> > > On Thu, Sep 30, 2021 at 3:37 PM Patrick Georgi 
> > wrote:
> > > >
> > > > Hi Gregg,
> > > >
> > > > Am Do., 30. Sept. 2021 um 21:16 Uhr schrieb Gregg Levine
> > :
> > > >>
> > > >> 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-cer

[coreboot] Re: Does PCI driver code belong in coreboot (ARM)?

[Patrick Georgi via coreboot]

1. Dezember 2021 12:06, "Paul Menzel"  schrieb:
> If I remember correctly, coreboot’s goal to only do minimal hardware 
> initialization originally meant, that the payload/OS does PCI 
> initialization.
The original idea was to boot into Linux (hence LinuxBIOS, back in the day). 
coreboot is very different from this scheme, see the presence of payloads that 
aren't Linux.

> Should PCI support be added to coreboot for ARM, so it’s aligned with 
> x86? Should coreboot stay minimal on ARM, for example PCI code adds 100 
> ms delay [4]? PCI drivers then have to be added to the payloads, which 
> could be a minimal Linux kernel, so that booting from drives connected 
> over PCI is possible?
The only option I see for getting rid of PCI support on ARM is to remodel the 
relationships between coreboot, the payload and the OS. Reminds me that I 
wanted to build a proof-of-concept for chainloaded payloads, a concept that 
might help with such a redesign because we could move things out of coreboot to 
"elsewhere" (wherever that might be) piece by piece.

But as is, if there are PCI(e) devices that need early init, coreboot is the 
place to put these drivers.


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

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

[Patrick Georgi via coreboot]

Am 28.11.2021 um 02:44 schrieb Peter Stuge:

Patrick Georgi via coreboot wrote:

With all due respect, dropping support for the majority of AMD boards


Dropping support for hardware has never been the primary purpose of
deprecation plans,


I think the difference is unimportantly subtle; deprecation is formal
intent to (eventually) drop.
I'll try to make it clearer: Dropping support FOR HARDWARE has never 
been the primary purpose of deprecation plans


The primary goal, as seen in the title, is to remove LEGACY_SMP_INIT and 
RESOURCE_ALLOCATOR_V3.


One purpose of announcements like the one by Arthur is to start a 
discussion how to get there while ideally NOT dropping the devices that 
would be affected (as listed in the original email).


I'll leave the rest of the email uncommented because it's only derailing 
matters even more.



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

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

[Patrick Georgi via coreboot]

24. November 2021 21:16, "Mike Banon"  schrieb:

> With all due respect, dropping support for the majority of AMD boards

Dropping support for hardware has never been the primary purpose of
deprecation plans, but since deprecations have been interpreted like that too
often, I propose using clearer language going forward. I'd appreciate
comments on https://review.coreboot.org/c/coreboot/+/59677 to ensure that it
brings the point across.


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

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

[Patrick Georgi via coreboot]

Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot:

In my opinion coreboot is more developer friendly than user friendly.

Kinda obvious: We don't even ship binaries...

Given the trouble these deprecation announcements always are, I can tell 
you an even more developer friendly strategy:


We could simply make all boards compile _somehow_ with the new 
infrastructure and retire the old one because it fell out of use. 
Without telling anybody.


If such a change lands in, say 4.16, and you only think of updating your 
firmware in, say 4.20, there has been one year of development going on 
after the removal (assuming the newly-proposed quarterly release schedule).


The result: fixing the issue becomes much harder, by then, rolling back 
is impossible, and nobody can quite remember what the issue was.


That strategy is more developer friendly because we don't have to deal 
with crap on the mailing list. Is it more user friendly?



And board depreciation is not a good idea. I understand that they can be 
brought back at some point. But lets be realistic that this need some developer 
time and testing. And in capitalistic world that means money to support old 
boards.
It also costs developer time to keep maintaining several alternate code 
paths, some of which are only used for boards no developer still uses 
(or they would have patched them to use the new code already).


As it stands, the proposed timeline allows for:

- ~2 more months to intervene before that list of boards even makes it 
into some official release notes. Adapt a board to the new 
infrastructure before then and it can disappear from that list before it 
even becomes official.


- 6 additional months in which the announcement is out in the open but 
the code is still in ToT. Adapt a board to the new infrastructure before 
then and while the old infrastructure will be dropped, the board won't 
be affected.


Even after that, all the existing coreboot versions are still there.


There are already some patches out there, so it appears that the 
strategy how to adapt a board to the new infrastructure is well 
understood - we're lacking the ability to test these boards.


Even if you can't adapt a board yourself, I'd suspect that announcing 
that you have some piece of hardware, can provide logs and offer to run 
tests will spark interest in developers creating a patch for the board.


We just don't do that speculatively because while it's usually simple to 
make a board compile it's far from clear that the result will still boot.


So: what board(s) are you offering to test?


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

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

[Patrick Georgi via coreboot]

On 25.11.21 17:04, Mike Banon  wrote:

2. It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch

These users didn't contribute fixes to their boards (or even just feedback that 
things needs to be done and testing when others provide patches) - are they 
even contributors?

It's easy to argue in favor of "lots of users" (or contributors if you want), 
but if they're all but invisible, do they even exist?


Of course, the people may finally fork a coreboot to i.e.

Do it. I'm getting tired of people making this particular empty promise.


"coreboot_extended" or "coreboot_notcorporate" (need a good name) and

Given this:


--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/


Maybe coreboot_3mdeb_corporate might be a proper name?


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

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

[Patrick Georgi via coreboot]

12. November 2021 20:35, "Felix Singer"  schrieb:
> Is it possible to rename the label to something else, so that it
> doesn't sound so strong anymore? Like "hidden", for example. Or does
> this need changes in its code?
I was thinking about renaming the feature "hide from UI" or something like 
that, too.
While it likely requires changes to the code, I think it could be argued that 
this is a candidate for upstream to pick up so that Gerrit doesn't mislead 
users, no matter the instance.


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

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

[Patrick Georgi via coreboot]

Since this appears to be blowing up (because we didn't have enough crap this 
week already, right?), let me respond a bit longer to the list for completeness 
sake:

12. November 2021 11:05, "Keith Emery"  schrieb:
> But would anyone else like to explain why this isn't a GPL violation? Because 
> it really seems like
> it is.

The GPL is no magic fairy that does whatever you feel it should do. It has 
sufficiently precise meaning to _not_ require a few things, too.

The only "you _must_ distribute source code" requirement in the GPL is for the 
GPL'd source code that made up a binary you shipped 
(https://review.coreboot.org/plugins/gitiles/coreboot.git/+/refs/heads/master/COPYING#134
 [1]) and even that isn't unlimited:
 - You ship the sources with the binary -> no further responsibility (and 
especially not towards third parties outside that transaction)
 - You offer some means to obtain the sources -> must be valid for 3 years 
after shipping the binary.

coreboot.org doesn't ship binaries of GPL code, so whenever we decide to 
distribute source code it's because we want to, not because we're obliged to do 
it. And when we decide not to distribute source code anymore, that's our right.


Patrick

[1] As you see, there wasn't a need to send a copy of the GPLv2 to everybody on 
the list, we had it already
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Patrick Georgi via coreboot]

Hi everybody,

it came to my attention that changes marked "private" on Gerrit are hidden in 
the UI but easily accessible through gitiles and with "git fetch".

I don't think it matters for most cases, but since we advertised it as being 
accessible for the owner and individual reviewers, I didn't want to keep things 
exposed, especially not after there's an announcement that such access is 
possible (as through this email). Therefore I:

- disabled the "private" CL feature in the Gerrit UI, so you can't mark changes 
as private
- created per-account git bundles[1] of their private CLs. Since I don't want 
to spam a few hundred users with stuff they might not care about, this is a 
pull transaction: if you want them, reach out to me.
- removed the private commits and references from the coreboot.git repo. You 
might still see the changes in the UI but that's due to its aggressive caching: 
The UI actually honors the private flag, so that's not a concern and all other 
means of accessing commits access the repo and will fail on these now-gone 
commits.

https://review.coreboot.org/c/coreboot/+/59229 also proposes updating the docs 
to remove mentions of the "private change" feature.

As an alternative we could also decide to re-enable the feature but with 
documentation pointing out that there are ways for motivated unauthenticated 
users to access these commits, which makes them more of a structuring feature 
(keep things out of sight until they're ready). In that case I could also 
reinstate the commits I deleted from the repo.


Thoughts?


Best regards,
Patrick

[1] https://git-scm.com/docs/git-bundle
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Weird thoughts about blobs (was Re: Re: Another year, another blob?)

[Patrick Georgi via coreboot]

Dear coreboot project,

this discussion heated up and escalated considerably, to the point where things 
got personal.
I have since put Nico and Martin into temporary moderation for this mailing 
list, in an attempt to get the temperature down at least within the project.

The timing of me doing so led to statements about Nico going through without a 
chance for Nico to react. To avoid further escalation, I offered to voice 
Nico's disagreement so that the public record doesn't end with uncontested 
assertions about him.


Specifically, Martin wrote that Nico "agreed that [he is] actually talking 
about blocking platforms because of blobs", and also that Nico wants "to block 
things until [he is] satisfied."

Nico objects to both assertions.


I hope that that these two valued long-time contributors find a way to set 
aside their differences and reconcile, but I'm not sure that the public is the 
right venue to work on that.


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

[coreboot] Re: Placing coreboot in system memory

[Patrick Georgi via coreboot]

Hi Julian,

November 9, 2021 6:27 PM, "Julian Stecklina" 
 wrote:

> This works, but I wonder whether this is the intended way to use Coreboot or
> whether there is some more elaborate way to do it. Does all of Coreboot have 
> to
> be mapped at the end of 4G? Or is there any documentation on this?

The normal layout for coreboot on x86 is indeed that it's mapped in its 
entirety at "below 4GB" because that's how x86 generally works.

The exceptions to that rule are:
 - emulation/qemu* because, like in your case, hardware is virtual with 
no/little need for initialization
 - AMD Zen family, where their coprocessor initializes RAM before x86 even 
enters the picture

They still map everything to 4GB there because that's the most convenient 
approach given how everything else on coreboot for x86 works (and on Zen, 
coreboot is still on that single flash part so why go through the trouble of 
splitting things up?), but you might be able to take some ideas from those for 
your own platform.

Is there any particular concern with having coreboot in that memory region on 
your platform that makes you ask this or is this just some general curiosity?


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

[coreboot] Re: Another year, another blob?

[Patrick Georgi via coreboot]

Am So., 7. Nov. 2021 um 12:29 Uhr schrieb Nico Huber :

> There's also a general reluctance to expect to support a project with
> free software that has shown that it doesn't take the GPL seriously.
>

General reluctance by whom? I just don't see that, instead I see tons of
activity by a very diverse crowd of people (contributing individually or
for companies of all sizes).
On the other hand, where's the coreboot fork/branch/variant/you-name-it
that improves in "taking the GPL seriously"? Where are its contributors?

(There's Libreboot, but it specifically is not a platform bringup project:
They strip coreboot of the things they dislike and then make the rest work
as well as possible. More power to them, and if there are means to make
these steps easier for them, I'd like to hear about it so we can work on
that - we did that in the past. This also means that their relative lack of
contributors is not to be held against them as independent development is
not their mission.)


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: Another year, another blob?

[Patrick Georgi via coreboot]

Am Fr., 5. Nov. 2021 um 19:11 Uhr schrieb ron minnich :

> e.g., the KGPE-D16 would get a 100%
>
except for the VGABIOS.


> Marketing types are sensitive to numbers like this: we could
> prominently display these numbers on coreboot.org
>
They're also pretty sensitive about any kind of mistake (or as they'd put
it: false statement) you make.


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: Another year, another blob?

[Patrick Georgi via coreboot]

Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot <
coreboot@coreboot.org>:

> The current reality is that binary blobs are needed for almost every
> platform in coreboot.  I believe the coreboot leadership is united behind
> the unfortunate reality that allowing these blobs is a requirement for the
> platform.  I don't think we're going to refuse a platform right now simply
> because it has blobs.  I'm not sure what coreboot would look like right now
> if we'd started refusing blobs when the required blobs started appearing,
> but it definitely wouldn't have many modern platforms.
>
It would be dead: while there are still a few folks carefully maintaining
i945 and GM45 in this reality, I'm not sure they would have done so in that
other reality where there was no help maintaining the payloads (and so
coreboot-compatible seabios, tianocore, grub, filo, ... would all be on
their plate as well)

We all agree that we don't like adding more proprietary binaries, but there
> are times when a binary needs to be closed for a time until the platform is
> released such as with the PSE.

There's a UPD called PchPseEnable - I wonder what it does if you set to it
0? ;-)

  Maybe the coreboot organization & SFC can enter into a contract that
> specified a rough timeframe that the firmware would be open sourced.
> Hopefully that would be enough of a guarantee.
>
That would be the SFC (coreboot org is not a separate legal entity). We
could ask and I suppose it would further the SFC's missions (more Software
Freedom!), but it's not something they already do routinely, and last I
heard they're pretty swamped with work already. That said: If we ask, the
worst they can do is say "no", right?

Simply refusing to accept the binaries *only hurts us*, most companies will
> be probably happy using Slimboot or TianoCore. Making things difficult to
> work with coreboot only makes it easier to show why something shouldn't be
> open and why the chip vendors shouldn't work with coreboot.  I cant tell
> you how many times I've heard that the reason coreboot wasn't used or
> wasn't upstreamed was that it takes too long to get changes into coreboot.
>
Compared to pretty much every other project (including high profile stuff
like Linux, and don't get me started on the mess that is u-boot forks),
coreboot is doing a relatively good job at coalescing developments upstream.

These things said, I think we can come up with solutions to make things
> easier. Ron suggested several years ago that we could enable Kconfig to
> only show the platforms with the amount of binaries that people are
> comfortable with.  Maybe we need to look into that more.

It's work - and lots of it - to get this to the granularity needed to
satisfy everyone. And then it needs a dedicated "librarian" role to keep
all new development categorized properly.
Much as I like the idea, we're already spread thin so I just don't see
that. (I guess that's a complicated way of saying: contributions desired!)

(And then it also differs by desired feature set: while I don't know who in
their right mind would use TXT, SGX or any of the other toys pretending to
improve security, apparently there are such folks, and on some platforms
enabling these means "optional blobs". So the set of platforms differs by
"blob level" _and_ feature set.)

We can require that the soc/cpu/chipset Kconfig screens display what blobs
> are required.

Few people see those screens.

We can push to get anything we can moved from the blobs into coreboot.  We
> can, and we are, pushing the vendors to be more open-source friendly, and
> we're finally starting to see some more and more people at these companies
> buying into this.
>
This is something I can only emphasize: there is movement in the right
direction - and there's also a struggle to not let things slip back, but
lots of these things happen behind closed doors. "Trust us" is  always a
hard sell, but if you don't trust us, look elsewhere and see how much
better it gets?


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: [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: 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: 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] 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: 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] 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 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: 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 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 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] 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: 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

[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] 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] 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] 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] 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: 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] 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: 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] 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: 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] 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] [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: Can we get rid of SMMSTORE_IN_CBFS?

[Patrick Georgi]

Am Mi., 14. Apr. 2021 um 04:06 Uhr schrieb Julius Werner :

> Does anyone still need this? As far as I know it was just a hack
> invented to backport SMMSTORE onto a Chromebook that couldn't make
> FMAP changes anymore, and we never ended up using it after all. Anyone
> still using SMMSTORE today should be putting it in a separate FMAP
> section. Would anyone mind if I just remove the CBFS option?
>
>From a technical standpoint, yes, we should remove this: Messing with files
inside CBFS is frowned upon.
>From a practical perspective, I'm not sure those Chromebooks ended up being
the only user of this option, so please wait a week for people to chime in.
If there hasn't been any report that it's in fact needed, I'll gladly give
you a CR+2 (well, I'd give +1000) to get rid of that option.

Looping in Matt DeVillier because he's probably the most active developer
dealing with SMMSTORE these days through his Tianocore payload efforts.


Patrick
___
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] 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] 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] 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: 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] 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] 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] 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] 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: 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] 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] 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] 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] 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] 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: 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 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 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: 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: 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] 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 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] 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: 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] 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: 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] 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: [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] 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] 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