coreboot November 2021

coreboot@coreboot.org

44 participants
35 discussions

Does the mrc.bin extracted from BayTrail-M chromebox work with BayTrail-D celeron J1900
by Zhiwen Zheng 06 Nov '21

06 Nov '21

Hi, I am trying to add a mainboard using celeron J1900 to coreboot-4.14, the serial console output stops after entering the MRC. The mrc.bin I used is extracted from Mrchromebox's roms for baytrail based chromebooks.

3 4

03 November 2021 - coreboot Leadership meeting minutes
by Martin Roth 05 Nov '21

05 Nov '21

# 03 November 2021 - coreboot Leadership meeting minutes Edited for clarity and formatting. * Attendees: Christian Walter, David Hendricks, Felix Held, Felix Singer, Jason Glenesk, Jay Talbott, Martin Roth, Matt DeVillier, Patrick Georgi, Piotr Król, Ron Minnich, Sean Rhodes, Stefan Reinauer, Tim Crawford, Werner Zeh ## Ongoing Items * New videoconferencing system? The desire for a new way of having meeting is because the current Google Meet platform requires a Google Employee to allow access. It would also be nice to use an open platform instead of a proprietary one, but we need something stable that we can all access. * BigBlueButton was used for the last coreboot EFI working group meeting and worked relatively well for most people, though some still seemed to have issues. * Matt - BBB did a poor job of filtering background noise. Not as good from an audio perspective. * Felix - same. Audio is much better in meet. * We probably do not want to use BBB at this time. * Should we try Jitsi? Limits: 100 ppl is free limit * [https://meet.jit.si/](https://meet.jit.si/) * Does this work with firefox? It used to have issues with some browsers. * We'll test this for the next EFI working group meeting * So far Google Meet seems to offer the best quality. * Can we use the Public version of google Meet? * 1 hour limit? * Number of people? * Can coreboot make an Google workspace account and host the meetings with Google Meet? * Yes, it has a free tier for non-profits. We'd need to work this out with SFC as they're the actual non-profit. ## Agenda: ### [martin] Trademark issues with starlabs. * StarLabs used the coreboot name in a way that creates confusion. * What would a reasonable release name be? * Starboot * Add "Star Labs" prefix before "coreboot" to make clear that it's a distro * coreboot version 4.15-company-7 (recommended naming scheme when not doing their own distro like libreboot, pureboot, ...) * We should document acceptable use and naming of the coreboot trademark. * Should coreboot go back to quarterly releases? * [Sean (Star Labs)] Yes, this would help. ### [Martin] 2022 coreboot (only) conference/hackathon/summit It’s been several years since we had a coreboot summit, and the thought is that this would be mostly focused on hacking and discussing improvements to the project instead of having a significant number of talks. * [Chris] Do we need another in person event? OSFF is willing to plan/take over costs * [Martin]Yes, after looking at the agenda for the latest OSFC, it was felt that a coreboot-only conference might be useful. If OSFF wants to pay for it, that’d be great, but I don’t think that OSFF should replace coreboot. * [Werner] Sounds like a good plan * [David] Choose a place with fewer restrictions (needs to be predictable). * In April after OCP regional summit - OSFF Meetup with hackathon ~40 ppl * [Ron] 4-day thing in Prague already planned for the week after OCP. April 21-24. Do this in parallel with the OSFF meeting. * Martin, Ron, and Chris will meet soon to discuss expanding this meeting. * [Chris] OSFC 2022 will be (hopefully) in south korea ### [Martin] Use of pseudonyms at coreboot. We currently require the use of real names at coreboot for legal reasons. This bothers some people. Could we introduce a method to allow reasonable pseudonyms by having a verified name held privately to associate with the name used in gerrit? I’d rather not have everyone switch and end up with code checked in as booty-mcbootface, but it seems reasonable to protect people’s privacy if desired. * [Werner] Is there a trust for source code? Basically a broker who submits the patches for people. * This is suggesting “Code laundering”. * Things like this are just being established now, but maybe shouldn't be allowed. * The entity submitting code would be responsible for this (this is supported by the [Developer’s Certificate of Origin](https://coreboot.org/Development_Guidelines#Sign-off_Procedure), part (b) or (c)) * [Martin] Can we have a company audit the code? Then it wouldn't matter as much if someone anonymously submitted code because troublesome code could be caught. * The coreboot server is in Germany, so the codebase is following their laws. * It might be best not to have a policy because then if there are issues, lawyers could actually come after us for the policy not being sufficient. * What does Linux do? * They have the linux foundation and with ~70% (estimate drawn from thin air) of big IT corporations being members, they play by different rules. * What do other projects do? * Let’s ask the SFC. * The important thing is to make sure that we’re making an effort to keep questionable content out. ### U&EFI - Usable & Effective Firmware Initiative. Created to create standards that coreboot can use. This originated because of the rumor that linux will soon require EFI interfaces to boot, a few patches that tried to change core coreboot concepts into something different (e.g. [https://review.coreboot.org/c/coreboot/+/51770](https://review.coreboot.org…), and more pushes in a similar direction (such as the “universal” “scalable” firmware “standard” driven by Intel). This seems like it’s boxing coreboot into a corner. Additionally there have been efforts to push EFI blocks further into coreboot. * [David] I think this has more to do with distros and OEMs expecting them for their manufacturing and testing purposes, for example [https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.… * Recently there have been a number of initiatives defining “industry standards” that affect coreboot, we’re then told that we need to support these “standards” * This will allow coreboot to define our own de-facto standards of similar legitimacy. These will then allow coreboot to continue with what we’re doing. * UPF - [Usable-Payload-Format](https://github.com/Usable-Effective-Firmware-Initiat…: Recommendations for providing means to pass information on to the OS and payloads. * Join #uefi in libre.chat, also visit its home (for now) at GitHub: [https://github.com/Usable-Effective-Firmware-Initiative](https://github.com… * Note that this name is tongue-in-cheek though the project itself isn't.

1 0

Build error/warning on 32bit host?
by Branden Waldner 01 Nov '21

01 Nov '21

I've been working on testing current coreboot on my asus/p2b and asus/p2-99 for the upcoming release, but ran in to problems trying to build it on my p2b with Gentoo with gcc 11.2.0. It (ironically) did build and work on the p2-99 with Debian Buster (oldstable) with gcc 8.3.0. It also built on my main system with Debian sid 64bit and gcc 11.2.0. CC host/lib/extract_vmlinuz.o In file included from /usr/include/string.h:519, from host/lib/extract_vmlinuz.c:9: In function 'memcpy', inlined from 'ExtractVmlinuz' at host/lib/extract_vmlinuz.c:67:2: /usr/include/bits/string_fortified.h:29:10: error: '__builtin_memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=] 29 | return __builtin___memcpy_chk (__dest, __src, __len, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30 | __glibc_objsize0 (__dest)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ host/lib/extract_vmlinuz.c: At top level: cc1: note: unrecognized command-line option '-Wno-unknown-warning' may have been intended to silence earlier diagnostics cc1: all warnings being treated as errors It looks like I might have to do a better job of regular testing of self hosting the build on these old 32-bit systems. Branden

1 1

coreboot release 4.15 reminder
by Jason Glenesk 01 Nov '21

01 Nov '21

Hi All, We are still going to do a release this week (Friday 11/5). If you have hardware and the ability to test, please test with the current code and report back any issues that come up. Also if you want a feature or change to be called out in the release notes that was checked in since 4.14, please add the change to Documentation/releases/ coreboot-4.15-relnotes.md. Side Note: I forgot to introduce myself when sending the last notice. I am relatively new to the coreboot community. AMD has been building up a coreboot team, and I started working with them a little over a year ago. I've worked in and around the firmware realm for almost 10 years. I'm excited about the chance to contribute to the project. Thanks everyone for being so welcoming. -Jason

1 0

Re: Installing OpenBIOS/coreboot
by bernd1-1＠web.de 01 Nov '21

01 Nov '21

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2021