coreboot

coreboot@coreboot.org

6 participants
39687 discussions

[BUG] nb/intel/i945: smm_subregion() prints assert when it should not
by Petr Cvek 25 Apr '22

25 Apr '22

Hello, On i945 northbridge: ASSERTION ERROR: file 'src/cpu/x86/smm/tseg_region.c', line 31 can be triggered by some configurations. The assert ASSERT(IS_ALIGNED(sub_base, sub_size)); tests alignment of SMM base with SMM size. The problem is that IGD stolen memory can offset the SMM base by a smaller size than the SMM size. This causes SMM base to be unaligned. For example: 80000000: 2 GiB Top of RAM, stored in TOLUD 7ff00000: 1 MiB Stolen IGD RAM base, address in BSM 7fd00000: 2 MiB SMM base, defined as SMM size in ESMRAMC -> 0x7fd00000 is not aligned to SMM size. Probably works for different settings too. RFC: should the assert from https://elixir.bootlin.com/coreboot/4.16/source/src/cpu/x86/smm/tseg_region… be removed, changed or ignored on i945? The correct test should be probably for 1 MiB alignement as the base of stolen IGD memory have [31:20] bits. But I understand the smm_subregion() test is a generic one. regards, Petr

2 6

Deprecation of the Intel Quark SoC
by Felix Singer 24 Apr '22

24 Apr '22

Hi all, to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead. Does anyone use this platform? Any opinions against this? // Felix [1] https://review.coreboot.org/c/coreboot/+/63283

15 55

PS/2 connected state and ACPI + BUG(s)
by Petr Cvek 24 Apr '22

24 Apr '22

Hi, Observing ACPI on my new ryzen machine it seems its UEFI can generate the state of PS/2 mouse and keyboard accordingly to which one of them is connected or disconnected. I was trying to add something like that to my Core 2 Duo testing setup, but it seems there is no easy way how to export information of used PS/2 port. It seems the status (_STA) is defined at the compilation time. This means the linux autodetection can have a problem if one PS/2 device is not plugged when defined. If the export is possible it should be probably done inside src/drivers/pc80/pc/keyboard.c am I correct? Also slightly related bugs: Having CONFIG_DRIVERS_PS2_KEYBOARD enabled and while holding a key (for example escape) during a reset. The keyboard gets stuck in seabios, payloads (nvramcui) and bootloader until linux kernel resets it. Disabling CONFIG_DRIVERS_PS2_KEYBOARD fixes it. I can add the warning in the kconfig help description if this is just limited to a specific board configuration and it is not bug. Having CONFIG_DRIVERS_PS2_KEYBOARD disabled, but having PS/2 keyboard and generic USB mouse connected will cause nvramcui to not respond until the USB mouse is disconnected. This is probably problem with SeaBIOS, but it would be useful to have some confirmation. P.S. I'm not an expert in ACPI, I learned most of it just from .asl source files from coreboot. regards, Petr

1 0

[RFC] i945 RAM init failure
by Petr Cvek 24 Apr '22

24 Apr '22

Hi, My board Kontron 986lcd-m (i945) sometimes fails in quick_ram_check_or_die() with RAM INIT FAILURE! The failure occurs in about 33% of reboots. RAM modules are fine (multiple memtest checks over the years), used RAM modules are rated with a reserve (DDR2-800 compatible modules and i945 supports up to DDR2-667). If the check will not fail the system will be long term stable. The checked memory is in the valid RAM (below top of the ram, below stolen IGD memory, below SMM region). If I force the checked word to not be the last 32b word (ex. 0x7fbffffc) but to be aligned to 256 bytes (ex. 0x7fbfff00) the test didn't fail even during multiple reset spamming. During the failed test the tested word looks like this (modification for printing the tested 32bit word): [DEBUG] ===FAIL1 5555b2ef //test for 0x5555555 [DEBUG] ===FAIL2 aaaab2aa //test for 0xaaaaaaa [DEBUG] ===FAIL3 0000b2ef //test for 0x0000000 [DEBUG] ===FAIL4 ffffb2ef //test for 0xfffffff At least the top half of the read_phys() value seems to be valid over subsequent reads (for loop). RFC: Could this be some problem with cache initialization, DDR2 controller impedance settings, or something else? Does anybody with i945 board or directly with 986lcd-m have the same problem? Regards, Petr

1 0

Re: Deprecation of the Intel Quark SoC
by Martin Roth 23 Apr '22

23 Apr '22

Here's a list for coreboot. https://review.coreboot.org/c/coreboot/+/63797 Martin Apr 22, 2022, 18:46 by rminnich(a)gmail.com: > oh oops the person doing that misunderstood me, we'll have to fix it > > On Fri, Apr 22, 2022 at 5:41 PM Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hey Ron, >> I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. >> This is the solution I was talking about in the coreboot leadership meeting: >> https://review.coreboot.org/c/coreboot/+/63754 >> >> Take care. >> Martin >> Apr 22, 2022, 17:24 by rminnich(a)gmail.com: >> >> > The discussion here has been pretty helpful to my thinking. I think >> > the concerns people are raising are important. >> > >> > We are deprecating ALL boards on oreboot that need FSP, as we took the >> > decision a few weeks ago to drop boards >> > that require blobs on the main CPU (we're accepting PSP blobs for now) >> > >> > This leaves two x86 boards behind, not counting qemu. >> > >> > But, based on what has come up here, we decided we did not want to >> > leave all memory of old efforts behind. >> > >> > This is the result: https://github.com/oreboot/oreboot/pull/570/files >> > >> > Not sure if this would be desired for coreboot, but I am mentioning it >> > here for reference. >> > >> > Thanks >> > >> > ron >> > >> > On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper <sam.kuper(a)uclmail.net> wrote: >> > >> >> >> >> (I'm not a Coreboot dev/maintainer, so apologies for commenting from the >> >> peanut gallery...) >> >> >> >> >> >> On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote: >> >> > [...] >> >> > 2) Decide on a set of criteria that we can use to evaluate whether or >> >> > not things should be removed from the master branch and maintained on >> >> > a release branch. >> >> >> >> Makes sense. >> >> >> >> >> >> > Currently, the only reason we have specified that a platform will be >> >> > moved to a release branch is if it's hindering progress. Basically if >> >> > it's not using an API we want to mark a required, or using code that >> >> > is being deprecated. >> >> > >> >> > If hindering progress is the only reason that something should ever be >> >> > removed from the master branch, I'm fine with that. Let's decide that >> >> > and document it so we don't have to have this discussion in the >> >> > future. >> >> >> >> Surely there will sometimes be platforms/chips that, for good reason, >> >> the community wants to keep in master - even if this would mean rewrites >> >> for those platforms/chips re the two matters you mentioned above: >> >> >> >> a. not using APIs that future versions of coreboot will require; >> >> >> >> b. using code that is being deprecated? >> >> >> >> >> >> Such "good reasons" could include that the plaform/chip: >> >> >> >> 1. is in widespread use with coreboot, even if long out of production >> >> (e.g. certain server boards or Thinkpad models); or >> >> >> >> 2. is targeted by related projects (e.g. Heads) that coreboot >> >> developers would prefer to avoid unnecessarily inconveniencing; or >> >> >> >> 3. has active coreboot testers/maintainers able to integrate relevant >> >> updates, and is passing all significant CI tests. >> >> >> >> >> >> > Other options we could look at: >> >> > >> >> > - A platform has not been sold in X years. >> >> > >> >> > - A chip has not been produced for X years. >> >> >> >> I can see the appeal of these criteria: they are easy to define. >> >> However, they are probably not wise criteria, as they may conflict with >> >> one or more of the "good reasons" above, especially reason 1. >> >> >> >> >> >> > - A platform has not been tested in X years. >> >> > >> >> > - A platform hasn't had an active maintainer for X years. (Maybe the >> >> > maintainer should be asked to test a platform as well?) >> >> >> >> These seem much better criteria. >> >> >> >> To make them easier to apply, should coreboot comprehensively track, for >> >> platforms/chips (roughly as Debian does for packages): >> >> >> >> - the current maintainer(s) for that platform/chip, >> >> >> >> - the current tester(s) for that platform/chip, >> >> >> >> - when that platform/chip was last tested, and >> >> >> >> - what the test results were? >> >> >> >> I think coreboot already tracks some of this data via >> >> https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain. >> >> >> >> That being so, I propose some draft policy wording (please >> >> change/improve...): >> >> >> >> "For any given platform or chip that has ever been targeted by the >> >> coreboot project: >> >> >> >> - For each coreboot "version" (point release, master, or >> >> hardware-specific branch): >> >> >> >> - if the platform/chip has been tested on that version, but >> >> the test was unsuccessful, the platform/chip shall be >> >> labelled *broken* re that version; else >> >> >> >> - if the test was successful, the platform/chip shall be >> >> labelled *working* re that version; else >> >> >> >> - the platform/chip shall be labelled *untested* re that >> >> version. >> >> >> >> - If the platform/chip has known security vulnerabilities on that >> >> version, the shall be labelled *vulnerable* re that version. >> >> >> >> - If the platform/chip has a person/team assigned to test/maintain >> >> it re master, it shall be labelled *maintained*, unless it has >> >> been *vulnerable*, *broken*, or *untested* re master for at >> >> least 6 months in which case it shall be labelled >> >> *unmaintained*, >> >> >> >> - If a platform/chip has been labelled *unmaintained* for at least >> >> 6 months, a branch shall be created for it, from the last >> >> coreboot point-release for which it was tested and found to be >> >> working. Such a platform/chip shall be labelled *relegated*. >> >> >> >> - A person/team who merges subsequent updates from master into >> >> such a branch, such that the branch becomes acceptable to the >> >> gatekeepers of master for merging back into master, and who also >> >> successfully tests the relegated platform/chip on the resulting >> >> codebase, and who volunteers to maintain that platform/chip for >> >> the foreseeable future, may become that platform/chip's >> >> maintainer, and upon the relevant changes being merged into >> >> master, the platform/chip shall no longer be labelled >> >> *relegated* but instead shall be labelled *tested* and >> >> *maintained*." >> >> >> >> >> >> > Thanks everyone [...] I'm not trying to argue with anyone, just >> >> > looking to get an actual decision of some sort out of this thread. >> >> >> >> Ditto! >> >> >> >> Sam >> >> _______________________________________________ >> >> coreboot mailing list -- coreboot(a)coreboot.org >> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> >> >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >> > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

2022-04-20 - coreboot Leadership meeting minutes
by coreboot org 23 Apr '22

23 Apr '22

# 2022-04-20 - coreboot Leadership Next meeting: 2022-05-04 ## Attendees: Jay, Martin, Felix, Christian, Piotr, Tim, Ron, Arthur, Julius, Felix Held, David, Stefan, Paul, Patrick ## Decisions * Martin will write up a document about when platforms would be moved to a branch: Basically only when it hinders progress, not because it's untested. * Martin will do an example of Kconfig where the platforms have been removed keep the mainboard names in the tree. When selected, it will show the branch where the platform is maintained. We can also include the last known good commit for current mainboards. * Patrick will look at adding the security mailing list to the page at [http://mail.coreboot.org](http://mail.coreboot.org) * Felix Singer will investigate adding better user authentication to our redmine server. ## Minutes ### [Felix S] The German government wants to fund open source projects. More information will follow next year 2022. [1] * I did some research and asked around, since I didn’t hear anything. The German government agreed on this funding last year, but their presented household finance plan (~22th March) doesn’t contain anything for open source. The final finance plan will likely be decided this summer. Until then it’s possible to change that. * Official statement from OKFN (only german) [2] * Alternative funding projects are the [Prototype Fund](https://prototypefund.de/en/) and the [Hardware Prototype Fund](https://hardware.prototypefund.de/en/), but they are expecting you to invent something new and all participants of a group should have their residents in Germany. Prototype fund is going until 2024. 5 or 6 projects are accepted every 6 months, and a project can get up to 50,000 euros. * Something “new” would have to be added to coreboot. * Hardware prototype fund is similar, but more specific to hardware. * [Piotr] [Technology Common Trust Open Firmware Fund](https://technologycommons.org/OFF/) in cryptocurrency. 50k Euros. Mostly for EU citizens, but have funded north american projects in the past as well. * What do we want to do with these funds? * Do the people working on the project get the funds? * Do we just put these up on the website as a way to help get coreboot projects funded if someone wants to do something? ### [Martin] Moving platforms to a stable branch. * What are the requirements? * I think (roughly) everyone agrees that platforms can be moved to a release branch if they’re blocking forward progress. * Is this the ONLY reason things should be removed? * Felix H, Paul: yes * Martin will write up something about this and push it to documentation to review. * David: We discussed before that platforms would be removed if it hasn’t been tested. * Give a release cycle or two to have it tested and remove it if it doesn’t get tested in that 6 months. * Boards that are moving to a stable/release branch are announced in the release notes prior to being moved, so there is time to update/test a target if a developer wishes to keep it in main. * Put the last known working version in the Kconfig. * Paul: Need to avoid having too many branches. ChromeOS, for example, has hundreds of branches that are difficult to understand. Security patches would need to be ported to many branches. * Ron: Everyone acts like leaving an unused target in the tree has no cost, and that’s not true. * There are other costs than just the jenkins builds. * FelixS many of us use freetime to do the maintenance, and this could be better used. * Can we make a requirement going forward that all mainboards must have maintainers and can we require that the mainboards be tested by the maintainer? Does this place too much of a burden on people contributing mainboards? * Julius: This may be a bit extreme. If we remove things that haven’t been tested in the last 6 monts this will remove most of the tree. * Martin: Can chromeos test all of their boards. * Answer: Not really. * Julius, David: There is an advantage to maintaining old mainboards that keep us away from focusing on specific architectures. * Also, people interested in porting coreboot to a board will look for examples. This could be some random embedded single board computer, or an experimental work done for a new architecture (POWER9 work based on POWER8 work?). * Ron: Keep old code in the tree, but stop building it. Then it can be used as a reference. ### [dhendrix] Make GCC the official compiler of coreboot? [3] * This is basically simply continuing what we're doing now, but making it formal instead of an unwritten rule. * Julius: Just because some extensions are allowed (like dollar signs in names), we don’t need to allow them. * [Martin]Should coreboot follow the linux kernel’s lead and look to switch to -std=gcc11 [4]? * The makefile is already specifying gcc11, so no change is needed here. We should document it somewhere though. ### [Martin] Proposal for handling platforms moved to a stable branch to make them easier to use: * Add all those mainboards back into the Kconfig in ToT, just with the branch name that they’re being maintained in and which host compiler is needed. * Offer to check out that branch if desired. * Branches are already being built by jenkins, so patches can be pushed directly to the 4.11, 12, 14, 15, and 4.16 branches. * Update buildgcc on those branches to pull the tools from the coreboot download site instead of the original sites. * Martin will implement and post for review. ### [Martin (Arthur)] SMM security fixes [5] * Backport to 4.14, 15, & 4.16 branches. * Martin will do releases of the branches after the fixes are in. * Should this have gone to the security mailing list instead of the general mailing list? * Probably. Arthur looked for the security mailing list, but didn't find it. * Add to the mailman interface page? Is this possible? * Patrick will look at this. ### [Martin(Arthur)] Deprecate lb_serial uart_pci_addr field [6] * How does this help us? * It removes ugly code. * We’d still want to keep the field in the structure so that a payload that uses it doesn’t misinterpret the field. * Make this field reserved. ### [Jay]: Martin, any sign of the ITRenew server? * No, still no signs of it. :-( ### [Martin] New page at coreboot website: Help the coreboot project. * Add small projects * Add requests for testing. * Make it easier to test things. * FelixH: Build an image, post coreboot output & dmesg output and have this parsed and added to the test list. * Replacement for board status. * Don’t need to check out the 2GB git repo. * Paul will take a look at how to download less. * Script doesn’t always work. * Felix s: Add a control server that allows distributed testing of mainboards for people. * Need to be some sort of authentication mechanism for pushing - git serves this purpose. * David: Make a branch that can be checked out. * Martin has a script that will remove old versions. ### [FelixH] Can we add oauth authorization to redmine? * FelixS: There’s a plugin, but it’s not officially supported. * FelixH: is there a bugtracker that better integrates with gerrit? * FelixS: we can look, but redmine has the best interface in my opinion, and it is very customizable. * FelixH: Not suggesting switching, but it's a hassle to use separate credentials. [1]: https://sovereigntechfund.de/en [2]: https://okfn.de/blog/2022/03/stf-offener-brief/ [3]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/3C2… [4]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.18-C11-Plan [5]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PAT6… [6]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/RYKU… # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

4 3

Get Coreboot version and build details in linux.
by Putsala Amar 23 Apr '22

23 Apr '22

Hi, We are working on intel c508 intel denverton board. We have programmed coreboot image in 16MB NOR flash. How can i get the coreboot version and build time stamp details in linux user mode? Does it creates any sys/proc entry? Thanks in advance.., Thanks & Regards, Amar Putsala ( ID : 2353 ) 4th Floor , Cubical : 4058 J.P. Software Park, Electronic City Phase-1, Hosur Road, 560100 Ext. No: 8110

2 1

2022-03-29 - coreboot UEFI working group meeting minutes
by coreboot org 23 Apr '22

23 Apr '22

# 2022-03-29 - coreboot UEFI working group Next meeting: 2022-04-26 ## Attendees: Jay, Werner, Martin, Sheng, Ron, David ## Minutes: * In the coreboot meeting last week, we discussed a proposal from Intel to change the handoff mechanism to payloads [1]. After that discussion, the decision was made to move further discussion of that topic over to the UEFI working group meeting. There was another meeting on Monday, March 28th where we got a much better understanding of what’s going on and the reasons behind the proposal. * Intel wants to look at modifying the payload handoff as a part of their universal-scalable-firmware [2] initiative. * The current payload handoff method has a number of flaws that they’d like to fix, such as the address for stack being hardcoded. * This likely also gives coreboot an opportunity to address other parts of the USF spec that cause issues or incompatibilities for us. * The coreboot project got involved when Sheng suggested to Intel that it would be good to align the payload-handoff format with other projects such as coreboot. * Thanks Sheng! * Using CBOR is the current proposal, but Intel was open to discussing different formats than CBOR if anyone has a better suggestion. * If anyone is not familiar with CBOR, you can get more information at cbor.io [3]. * In the coreboot meeting, it was suggested that we push to just use coreboot tables as they’re already supported in a number of payloads. This really isn’t practical however. Intel would need to be able to modify the list of known cbmem IDs and they would need to be able to change the description format to something that’s more self-describing. * The coreboot project can, however, encapsulate a CBOR-based handoff-structure into cbmem, similar to what we currently do with ACPI tables. * Additionally Intel was willing to look at using CBOR structures as input and output to the FSP, so we could get rid of both the UPDs & HOBs. * The coreboot community can help to drive this, and Intel has said that they will send an email to the coreboot mailing list. * Since this is a part of the Universal-Scalable-Firmware initiative, it would be good to look that over for issues as well. Currently, it’s very Intel oriented, and specifies that the FSP will be used as the silicon initialization layer, which obviously doesn’t work for non-x86 platforms. * The details for the weekly meeting are below. * Self Describing Blob discussion. A copy of this meeting has been added to the coreboot calendar [4]. Biweekly on Monday, 4:00 – 5:00pm CET/CEST Berlin (Currently UTC+2) Video call link: https://meet.google.com/gha-shza-wnw Or dial: ‪(DE) +49 30 300195187‬ PIN: ‪848 847 031‬# More phone numbers: https://tel.meet/gha-shza-wnw?pin=2380921555764 Self Describing Blob discussion Meeting minutes [5]. * Sean Rhodes from StarLabs has worked to get all of the coreboot related EDK2 patches submitted to their repo. These are still currently in review. [1]: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [2]: https://universalscalablefirmware.github.io/documentation/ [3]: https://cbor.io/ [4]: https://calendar.google.com/event?action=TEMPLATE&tmeid=NHVvZDRuYXZ2bjdtZTJ… [5]: https://docs.google.com/document/d/1IDQqr4cv8dQHa9faSxBc29xHSeKuXNTiMP3a3bL…

6 13

Flashing EC is getting failed
by Sameeruddin Shaik 23 Apr '22

23 Apr '22

hi, I am getting the below error while flashing the EC image with the micro servo, Did anyone know about this?. sudo ./util/flash_ec --board=adlrvpp_ite --image build/adlrvpp_ite/ec.bin INFO: Using servo_micro. INFO: Using ec image : build/adlrvpp_ite/ec.bin INFO: Flashing chip it83xx. INFO: Asking servo to send the dbgr special waveform to it83xx 2022-04-02 11:38:29,203 - Controls - ERROR - (ptyError) Failed getting enable_ite_dfu: servo_micro: Timeout waiting for response. There was output: enable_ite_dfu, Command 'enable_ite_dfu' not found or ambiguous., > Problem with ['enable_ite_dfu'] :: servo_micro: Timeout waiting for response. There was output: enable_ite_dfu, Command 'enable_ite_dfu' not found or ambiguous., > ERROR: command exited 1 (non-zero): dut-control enable_ite_dfu INFO: Restoring servo settings... Please help!!!, thanks in advance --sameer

1 1

Two Payloads
by Lukas Jungbauer 21 Apr '22

21 Apr '22

Hi, is it possible to run two Payloads on Coreboot at the same Time, like Heads and TianoCore? Payloads can only be installed by building a new Image and Software-Flashing it, correct? Best Regards, Lukas

3 2

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