coreboot

coreboot@coreboot.org

6 participants
39687 discussions

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

coreboot EFI working group meeting minutes - 12 October 2021
by Martin Roth 13 Oct '21

13 Oct '21

# 12 October 2021 - coreboot EFI working group ## Objective: 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. How do we approach this without turning coreboot into UEFI. ## Decisions: * The coreboot repo will host an EDK2 fork for use as a coreboot payload. Commits to this repo will go through gerrit for review. * Any code needed to support booting should go into a payload instead of coreboot itself. * We will look at adding chain-loading payload support to coreboot. Among other things, this will allow a payload to support turning cbmem tables into UEFI HOBs as needed before calling into a UEFI support payload. ## Minutes: * Can you access the VC ? [Chris] * 9 people in. Apparently Chrome + Web or using the apps work for some people, but not for others. * Native [Bluejeans] apps * We’ll try a different method for our next meeting - The method will be announced after we decide when to hold our next meeting. * FelixH: this isn’t a job for coreboot. * This should definitely be in a payload. * If FSP settings need to be configured, this would be a problem. * How would we support boot variables? Or would we? * Werner: Agree with keeping this in a payload. * [pgeorgi] What’s the scope of this project? * Just booting? * Jay: Syspro is typically asked to create solutions that are NOT UEFI. They want simplicity and boot code to do the minimal amount. * 9elements: customers are mostly desiring UEFI boot solutions * coreboot need additional tables in cbmem to support a better UEFI implementation. * What’s the timeline? * When will we NEED to support the EFI interfaces? * Do we know what these interfaces will be? * Initially just boot services. * Is there any advantage to pulling EFI into coreboot. * No? Having chainloading payloads could handle any translation necessary without tying that to a specific payload. (ie. coreboot loads the cbmem2hob payload, which does its thing, then cbmem2hob loads the actual payload) * Look into chain-loading payloads: pgeorgi will look into this. Proof of concept: move splashscreen support out of ramstage. * Add an edk2 fork to the coreboot git server * Where do we start from? * Current EDK2 stable from August 2021. * https://review.coreboot.org/edk2.git is now mirrored from https://github.com/tianocore/edk2 * Updated hourly * Our own stable tag is default: coreboot-stable202108, based off edk2-stable202108 * How do we pull changes from EDK2 * Create upstream branch to pull in changes? The vast majority of changes will come into this branch, and someone would need to sort them out at some point. * What’s the volume of patches that come into the EDK2? That has a big impact to how we address this: * About 5 patches a day. * checked again: there are ~6000 commits between 2020-09-20 and 2021-09-20 on edk2/master, so more like 20 commits a day * Can we just create a fork and add things on top, or is there a better way to start? * Matt currently just creates his fork for the chromebook firmwares that he maintains. * How do we push changes back to EDK2? * This is a big issue - this is why many of the forks were created. * What’s the volume of our changes that would go into this tree? * How do we want to handle commits? * Are there enough people to do real code reviews? * Let’s just start by pushing through gerrit. * What other more minimal projects are we interested in pulling in as payloads? * Yabits, Voodoo, U-Boot’s codebase? * Yabits did not work the last time it was (minimally tested) * Tianocore is currently not very well featured. * There are definitely situations currently where a uefi-payload is needed, so if there were something that provided a UEFI interface without all of the associated overhead, that would be very useful. * Everyone has different ideas about what’s needed as a minimal solution. * Voodoo is trying to get away from running all of this code in ring0. * No serious discussion about building anything new from scratch at this point, but that’s obviously not out of the question if someone wanted to start a new project. * Definitely no one-size fits all solution here * AI: Need to find out what linux is going to need. * Is this just what’s required for grub, or by linux itself - those are different things. * May be useful to have multiple implementations to find where the gaps are. * Any maintained implementations are welcome on review.coreboot.org! (no graveyard for yabits unless you start working on it) * Figure out boot services profile for linux as a payload * AI: look at what grub needs * Note that there is "grub as a payload" * UEFI spec is closed source * This would need to be addressed by the UEFI Forum board of directors. * Nate will pass along the request to make this open source. * What counts as working? * Will definitely set up build testing * Can 9elements help any with testing for their purposes at least. * 9elements will definitely test, but can’t say at this point how it will look. * Created edk2 repo: * Matt to start pushing patches. * Martin to set up build testers. * Discuss whether we need another meeting on the 26th at next week’s leadership meeting. ## Agenda & random notes below. * How do we approach this without turning coreboot into UEFI. 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. * Extend [Yabits]? This hasn’t had any new commits in over 3 years. It also leverages libpayload which is not so much alive either these days. * Through depthcharge, libpayload is probably the most exercised payload code you'll find these days that isn't a Linux kernel. * Fork EDK2 * There are already many private forks. It would be useful to have a central location to merge these. There is a worry about who will review the patches. I don’t think we want everyone on the internet to be able to submit and merge patches, so we probably want to create a group who can merge them. * Set up a jenkins builder * What codebase do we start with? * Extend Ron’s [Voodoo] project * This is now passing one of the tests from u-boot efi_selftest * Port to arm in progress * Write something from scratch * Add code to coreboot to create HOB structures and other requirements. * This was the initial suggestion that was proposed in the coreboot meeting last week. * Pull in u-boot’s UEFI implementation * How much of the [UEFI spec] is needed? * ARM has a [trimmed down UEFI spec]. Can a similar one be made for x86? * Boot services * Runtime services * Secure boot * Boot Variables * User identification? * Apparently EBBR requires mass storage as part of the spec, so more a payload matter [Bluejeans]: https://www.bluejeans.com/downloads [UEFI spec]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf [Yabits]: https://github.com/yabits/uefi [Voodoo]: https://github.com/linuxboot/voodoo [trimmed down UEFI spec]: https://arm-software.github.io/ebbr/

4 4

The coreboot.org edk2 repo is live! (But don't get a heart attack)
by Patrick Georgi 12 Oct '21

12 Oct '21

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

3 2

Atomic Accesses to Local APIC
by Julian Stecklina 06 Oct '21

06 Oct '21

Hello, I was looking at the Local APIC code in coreboot and was wondering about `lapic_write_atomic` in src/include/cpu/x86/lapic.h. This uses an atomic XCHG to write to Local APIC registers. I would like to understand why this would be necessary, because none of the OSes I've seen or worked on do anything similar. ALso the Intel SDM discourages acceses that are not plain loads/stores. In the coreboot code, this function seems to exist for a really long time. I've found this from 2004: #ifdef CONFIG_X86_GOOD_APIC # define FORCE_READ_AROUND_WRITE 0 # define lapic_read_around(x) lapic_read(x) # define lapic_write_around(x,y) lapic_write((x),(y)) #else # define FORCE_READ_AROUND_WRITE 1 # define lapic_read_around(x) lapic_read(x) # define lapic_write_around(x,y) lapic_write_atomic((x),(y)) #endif This seems to indicate that using atomic writes was a workaround of some kind. Does anyone know more? Thanks! Julian

6 17

how intel ME is connected to the internet ?
by Hendra 05 Oct '21

05 Oct '21

hi coreboot, I read in Wikipedia that Intel ME has an independent internet connection. But what does "independent" mean ? Is it an independent internet connection from the OS ? or is it an independent internet connection from the network related devices ? such as: wwan card, wlan card, bluetooth module, wimax card or maybe it has its own secret/hidden independent networking device, so it can connect to the internet, without depending on Laptop's networking device, such as: wwan card, wlan card, bluetooth module, wimax card ? regards,

9 16

Gigabyte D510UD MOBO
by Ilker C 04 Oct '21

04 Oct '21

Hello All, I have this computer since 11 years and working with triple boot from SSD and HDD. Also I have PCI graphics card Radeon 512 KB. I overclocked the CPU to 2Ghz to run Linux Mint and Win 10. I had a problem with windows 10 due to the PCI graphics card conflicting when installed ram is more than 2Gb. Linux does not have. It works with 4gb and PCI Graphics card. After checking all information I find out that PCI Hole is the main reason and legacy BIOS does not have memory remapping function. Maybe that was necessary for this board. While I was searching how to change the existing BIOS I ended up coreboot. I downloaded the latest release and compiled in linux mint. (There are some missing steps in the HOWTO page while compiling) Then I used flashrom internally. Seabios boot was successful. He are my findings : - Seabios boots only with the SSD. - Linux Mint in HDD did not boot. WIn10 in HDD did not boot. - 2nd RAM slot is not working. So max memory is 2gb only. - GRUB2 did not work. - PCI graphics card did not work. Only on Board. - Gigabyte SATA ports did not work. Only Sata ports of Intel chipset NM10. - There is no any improvement in Boot speed. Because of the above I revert and installed the stock BIOS from Gigabyte. I believe this project is great and I would like to thank for all contributers. Regards

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot