coreboot October 2021

coreboot@coreboot.org

40 participants
27 discussions

TigerLake RVP TCSS init failure
by Michal Zygowski 27 Oct '21

27 Oct '21

Dear coreboot community, I have encountered problem with silicon init on Tiger Lake RVP platform. I managed to resolve previous issues with memory initialization and now hitting an error with TCSS init. The FSP asserts on IOM ready check, which is 0. The configuration has selected CONFIG_USE_INTEL_FSP_MP_INIT (without MP PPI service). When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is selected, then the FSP-S returns smoothly (at least from one of the phases I guess) and resets after clearing MCEs in coreboot's CPU init: CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Setting up local APIC... apic_id: 0x00 done. Turbo is available but hidden Turbo is available and visible CPU #0 initialized Initializing CPU #2 Initializing CPU #6 Initializing CPU #7 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Cl (tutaj następuje reset) Any ideas what may cause these issues? When I clean this up, I will upstream the DDR4 variant of TGL UP3 RVP. -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

6 16

7010 Motherboard Variants
by Matt B 25 Oct '21

25 Oct '21

A question about Optiplex 7010 motherboards: It appears (at least to me) that the DT and MT variants of the 7010 use the same motherboard, different from the SFF. The docs specify the SFF version. Has any testing been done on the DT/MT motherboard? The only mention in the documentation: > There are no schematics for SFF, but if one looks for MT/DT schematics, > they can be found publicly. Most of the schematics should match the SFF (although MT/DT has additional > PCIe and PCI slot). -M

2 2

GPU clock throttling on Intel Atom family
by Rao G 22 Oct '21

22 Oct '21

Hi All, Trying to enable GPU clock throttling on Intel Gen 7 UHD The SoC is E3815 Atom BayTrail On Ubuntu *command* *i*ntel_gpu_frequency *output* cur:200MHz min:200MHz RP1:400MHz max:400 MHz Can GPU Frequency be throttled? Any specific registers to enable throttling for GPU/GFX Thanks Ranga

1 1

[arm64] queries on current support and future direction
by Sukanto Ghosh 20 Oct '21

20 Oct '21

Hi Everyone, 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) ? * If no, would coreboot community be willing to support such a flow (via a build-time flag) ? * 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) ? Best Regards, Sukanto

4 4

20 October 2021 coreboot Leadership meeting minutes
by Martin Roth 20 Oct '21

20 Oct '21

# 20 October 2021 - coreboot Leadership ##Attendees: Felix Singer, David Hendricks, Arthur, Werner, Piotr, Lean Sheng Tan, Marshall, Jason Glenesk, Jay Talbott, Matt DeVillier, Patrick Georgi, Tim Crawford, Martin, Stefan, Felix Held ## Agenda: * [patrick g] “Verified+1” permissions on gerrit repos that aren’t build tested (e.g. homepage.git): open up? For which groups? * For which repos? * Blobs - Only people appointed by Stefan for legal reasons. * Homepage: All submitters? Owner’s +2 or verified doesn’t count. * [martin] Clean up the coreboot root folder? * /spd, /gnat.adc, /Makefile.inc, /toolchain.inc -> src * Move spd directory to src/lib (or src/device?) * Look at moving gnat.adc to /src. Might be difficult to move * Move toolchain.inc to /src - only included by top level makefile * (keep Makefile.inc in place, otherwise it has to refer to ../util which is ugly) * /configs -> util/abuild * Having this here may help with visibility of platforms * Leave this here, remove subdirectory * /MAINTAINERS, /AUTHORS -> Documentation * Leave both of these at the top level * MAINTAINERS is machine readable and not really “Documentation”, AUTHORS is a “standard file” * Remove COPYING - it’s a copy of the GPL V2 license, which we have under /LICENSES * Leave this here: standard location so license checking and compliance tools are happier to find it there. * Update README.MD to point into /Documentation and each .md in other directories. * Marshall will do this. Thanks! * Add a .mailmap file [to correctly map authors to an email address](https://git-scm.com/docs/gitmailmap). * Yes * Should we lock it to the result after moving anything so that additional objects can’t be created without deliberation? * Add a lint test to keep other files from being added without discussion. * [Martin] When do we need another coreboot EFI working group meeting? * Next tuesday - send out invites after this meeting. * Lots of issues joining last time. * [Werner] Discuss patch [CB:55367](https://review.coreboot.org/c/coreboot/+/55367) regarding Intel PSE (Programmable Service Engine) * Must be loaded at boot time by a piece of firmware. * Discussed osfc2020 - zephyr based, but not open yet. * Patch just adds the loading from cbfs so that FSP can load it. * Yet another blob without notifications. * Blob is unfortunately mandatory for the platform. * Initializes the ARM processor then stops running? * It may be possible to write an open version? * The process of open sourcing the code for this takes a long time, so this is (in theory) a temporary solution. * The processor is EC-like, handles realtime interface, has I2C interface. * PCIe devices can be assigned to either the device or X86. * Sheng and Werner will verify that this is more similar to an EC than the ME. * If this is EC-like, this shouldn’t be an issue. * [Arthur] Logging: (optional) printing the error level in front of the message? * Would need to have a little logic to allow a line to continue without printing again. * Loglevel in brackets. * Sure, let's try this - so long as it's optional, there's not much of a downside. * [Martin] Adding requirements for blobs in coreboot’s repos * Nico [suggested requesting/requiring some additional items for blobs](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thre…. * We already have[ a list of requirements](https://review.coreboot.org/plugins/gitiles/blobs/+/refs/head…, so updating that doesn’t seem unreasonable. * How do we want to handle non-coreboot-owned blob repos - fsp/intel_microcode/amd_blobs/qc_blobs/ * Let’s review the blobs directory and see what’s still needed. * Revisit next meeting ## Mailing list discussions of interest: * Mailing list question about [arm64 ports of coreboot](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/t… * Mailing list: [firmware and bootloader log spec](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/threa… * (LPC 2021 System Boot and Security MC discussion about that)[https://youtu.be/JwU1_hyOzMI?t=4329] ## Ongoing items: * [New videoconferencing system?](#bookmark=id.ehzxgz9a1ta0) * Big Blue Button (maintained install: senfcall.de, [coreboot room](https://lecture.senfcall.de/pat-yut-ayj-bc6) set up by pgeorgi) * At the end of the meeting, please try to join the coreboot room here, so we can see if it’s working for people. * What happens if the host doesn’t join - seems fine. * This was tested by a number of people after the meeting, and it seems better than bluejeans. There weren't any reports of people not being able to get in, though some people had a little difficulty getting their audio set up. It seems like they were able to resolve this * Bluejeans. coreboot.org has an account here already, but lots of folks had issues joining the coreboot EFI working group meeting on Oct 12, so probably not? * Kind of weird - different versions per subscription level? * Definite NO. * Documentation updates * Hiring a tech writer? * Not right now. * coreboot 4.15 release ~Nov 1 * First notice went out to mailing list. * Contribute to the same patch or check it in and add to it? * Martin to review. * [Updating the builder](https://docs.google.com/document/d/10jQc1N67Pck2pE3pkyke7g-YFDIBqu… * Felix testing NixOS. * Need to determine builder differences - decide what builder can build what at runtime based on configuration. * Packaged coreboot toolchain for NixOS. * 4.14 package - making a stable release. * Set up build test with flashrom * Test both with linux & bsd

1 0

Where to post PC BIOS related job ads?
by Jonathan Hartley 19 Oct '21

19 Oct '21

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

2 1

Intent to release coreboot 4.15 on November 1st
by Jason Glenesk 18 Oct '21

18 Oct '21

Hi Everyone, This email starts the release process for coreboot 4.15, so we're now at the "~2 weeks prior to release" step in our https://doc.coreboot.org/releases/checklist.html Our releases do not mark any feature or stability milestones, they only serve as a point in time that downstream coreboot users can use to work against. Please 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 at https://review.coreboot.org/c/coreboot/+/58422 to see if any notable work of the last 6 months is missing there. Please feel free to extend the release notes as needed. Thank you all for contributing and improving coreboot over the last 6 months! Regards, Jason

1 0

spkmodem-recv
by Keith Emery 17 Oct '21

17 Oct '21

Can somebody please verify that the attached file can be interpreted by spkmodem-recv? Or point out where I might be going wrong?

2 2

There is a python in our toolchain?!?
by Patrick Georgi 16 Oct '21

16 Oct '21

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

11 28

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 15 Oct '21

15 Oct '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1464650: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1464650: Memory - corruptions (OVERRUN) /tests/lib/lzma-test.c: 147 in test_ulzman_zero_buffer() 141 uint8_t in_buf[LZMA_PROPERTIES_SIZE + 1 * KiB]; 142 uint8_t out_buf[2 * KiB]; 143 144 memset(in_buf, 0, sizeof(in_buf)); 145 memset(out_buf, 0, sizeof(out_buf)); 146 >>> CID 1464650: Memory - corruptions (OVERRUN) >>> Overrunning array "in_buf" of 1029 bytes by passing it to a function which accesses it at byte offset 2047 using argument "2048UL". 147 assert_int_equal(0, ulzman(in_buf, sizeof(in_buf), out_buf, sizeof(out_buf))); 148 } 149 150 #define ULZMAN_CORRECT_FILE_TEST(_file_prefix) \ 151 { \ 152 .name = "test_ulzman_correct_file(" _file_prefix ")", \ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2021