coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Hidden PCI device question (from 4.13 release notes)
by Rafael Send 23 Nov '20

23 Nov '20

Hi, Unsure if appending to the 4.13 announcement email was cool, so here's a separate thread. I was using coreboot for a while, but then discovered that something about it was not accessing hidden PCI devices correctly (not enough expertise to figure out what). In my particular case, I'm adding a Thunderbolt controller to an unsupported system. The process for waking it up / unhiding it involves poking an extended capability register of the device while it is still hidden, via the EFI shell. This works fine on stock BIOS + shell, but never worked in coreboot / Tianocore so unfortunately I had to give up using coreboot. Given the "hidden PCI device" change from the 4.13 release notes, should I expect that my use-case may work now? The notes talk about a specific device, but I'm unsure if all hidden devices are treated the same way. Cheers, R

2 3

Memory initialisation error
by Andy Pont 23 Nov '20

23 Nov '20

Hello, I have some life out of my Comet Lake based board but the debug output ends with FMAP: area RW_MRC_CACHE found @ 420000 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' PRMRR disabled by config. WEAK: src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params called FspMemoryInit returned 0x80000007 FspMemoryInit returned an error! The board has all of the memory soldered directly down. The spd.bin file in the build directory is 0 bytes. Is there a way to extract the correct SPD information from either the original UEFI firmware or from a running Linux system? -Andy.

4 11

IRQ routing: how to do the mainboard_picr_data/_intr_data structures?
by Mike Banon 21 Nov '20

21 Nov '20

Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change: https://review.coreboot.org/c/coreboot/+/46587/ When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated. Best regards, Mike Banon

4 10

Announcing coreboot 4.13
by Angel Pons 20 Nov '20

20 Nov '20

Hi everyone, I'm pleased to announce that coreboot 4.13 has just been released, with release notes as follows: Since 4.12 there were 4200 new commits by over 234 developers. Of these, about 72 contributed to coreboot for the first time. Thank you to all developers who again helped made coreboot better than ever, and a big welcome to our new contributors! New mainboards -------------- - Acer G43T-AM3 - AMD Cereme - Asus A88XM-E FM2+ - Biostar TH61-ITX - BostenTech GBYT4 - Clevo L140CU/L141CU - Dell OptiPlex 9010 - Example Min86 (fake board) - Google Ambassador - Google Asurada - Google Berknip - Google Boldar - Google Boten - Google Burnet - Google Cerise - Google Coachz - Google Dalboz - Google Dauntless - Google Delbin - Google Dirinboz - Google Dooly - Google Drawcia - Google Eldrid - Google Elemi - Google Esche - Google Ezkinil - Google Faffy - Google Fennel - Google Genesis - Google Hayato - Google Lantis - Google Lindar - Google Madoo - Google Magolor - Google Metaknight - Google Morphius - Google Noibat - Google Pompom - Google Shuboz - Google Stern - Google Terrador - Google Todor - Google Trembyle - Google Vilboz - Google Voema - Google Volteer2 - Google Voxel - Google Willow - Google Woomax - Google Wyvern - HP EliteBook 2560p - HP EliteBook Folio 9480m - HP ProBook 6360b - Intel Alderlake-P RVP - Kontron COMe-bSL6 - Lenovo ThinkPad X230s - Open Compute Project DeltaLake - Prodrive Hermes - Purism Librem Mini - Purism Librem Mini v2 - Siemens Chili - Supermicro X11SSH-F - System76 lemp9 Removed mainboards ------------------ - Google Cheza - Google DragonEgg - Google Ripto - Google Sushi - Open Compute Project SonoraPass Significant changes ------------------- ### Native refcode implementation for Bay Trail Bay Trail no longer needs a refcode binary to function properly. The refcode was reimplemented as coreboot code, which should be functionally equivalent. Thus, coreboot only needs to run the MRC.bin to successfully boot Bay Trail. ### Unusual config files to build test more code There's some new highly-unusual config files, whose only purpose is to coerce Jenkins into build-testing several disabled-by-default coreboot config options. This prevents them from silently decaying over time because of build failures. ### Initial support for Intel Trusted eXecution Technology coreboot now supports enabling Intel TXT. Though it's not feature-complete yet, the code allows successfully launching tboot, a Measured Launch Environment. It was tested on Haswell using an Asrock B85M Pro4 mainboard with TPM 2.0 on LPC. Though support for other platforms is still not ready, it is being worked on. The Haswell MRC.bin needs to be patched so as to enable DPR. Given that the MRC binary cannot be redistributed, the best long-term solution is to replace it. ### Hidden PCI devices This new functionality takes advantage of the existing 'hidden' keyword in the devicetree. Since no existing boards were using the keyword, its usage was repurposed to make dealing with some unique PCI devices easier. The particular case here is Intel's PMC (Power Management Controller). During the FSP-S run, the PMC device is made hidden, meaning that its config space looks as if there is no device there (Vendor ID reads as 0xFFFF_FFFF). However, the device does have fixed resources, both MMIO and I/O. These were previously recorded in different places (MMIO was typically an SA fixed resource, and I/O was treated as an LPC resource). With this change, when a device in the tree is marked as 'hidden', it is not probed (`pci_probe_dev()`) but rather assumed to exist so that its resources can be placed in a more natural location. This also adds the ability for the device to participate in SSDT generation. ### Tools for generating SPDs for LP4x memory on TGL and JSL A set of new tools `gen_spd.go` and `gen_part_id.go` are added to automate the process of generating SPDs for LP4x memory and assigning hardware strap IDs for memory parts used on TGL and JSL based boards. The SPD data obtained from memory part vendors has to be massaged to format it correctly as per JEDEC and Intel MRC expectations. These tools take a list of memory parts describing their physical attributes as per their datasheet and convert those attributes into SPD files for the platforms. More details about the tools are added in [README.md](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/head…. ### New version of SMM loader A new version of the SMM loader which accommodates platforms with over 32 CPU threads. The existing version of SMM loader uses a 64K code/data segment and only a limited number of CPU threads can fit into one segment (because of save state, STM, other features, etc). This loader extends beyond the 64K segment to accommodate additional CPUs and in theory allows as many CPU threads as possible limited only by SMRAM space and not by 64K. By default this loader version is disabled. Please see cpu/x86/Kconfig for more info. ### Address Sanitizer coreboot now has an in-built Address Sanitizer, a runtime memory debugger designed to find out-of-bounds access and use-after-scope bugs. It is made available on all x86 platforms in ramstage and on QEMU i440fx, Intel Apollo Lake, and Haswell in romstage. Further, it can be enabled in romstage on other x86 platforms as well. Refer [ASan documentation](../technotes/asan.md) for more info. ### Initial support for x86_64 The x86_64 code support has been revived and enabled for QEMU. While it started as PoC and the only supported platform is an emulator, there's interest in enabling additional platforms. It would allow to access more than 4GiB of memory at runtime and possibly brings optimised code for faster execution times. It still needs changes in assembly, fixed integer to pointer conversions in C, wrappers for blobs, support for running Option ROMs, among other things. ### Preparations to minimize enabling PCI bus mastering For security reasons, bus mastering should be enabled as late as possible. In coreboot, it's usually not necessary and payloads should only enable it for devices they use. Since not all payloads enable bus mastering properly yet, some Kconfig options were added as an intermediate step to give some sort of "backwards compatibility", which allow enabling or disabling bus mastering by groups. Currently available groups are: * PCI bridges * Any devices For now, "Any devices" is enabled by default to keep the traditional behaviour, which also includes all other options. This is currently necessary, for instance, for libpayload-based payloads as the drivers don't enable bus mastering for PCI bridges. Exceptional cases, that may still need early bus master enabling in the future, should get their own per-reason Kconfig option. Ideally before the next release. ### Early runtime configurability of the console log level Traditionally, we didn't allow the log level of the `romstage` console to be changed at runtime (e.g. via `get_option()`). It turned out that the technical constraints for this (no global variables in `romstage`) vanished long ago, though. The new behaviour is to query `get_option()` now from the second stage that uses the console on. In other words, if the `bootblock` already enables the console, the `romstage` log level can be changed via `get_option()`. Keeping the log level of the first console static ensures that we can see console output even if there's a bug in the more involved code to query options. ### Resource allocator v4 A new revision of resource allocator v4 is now added to coreboot that supports mutiple ranges for allocating resources. Unlike the previous allocator (v3), it does not use the topmost available window for allocation. Instead, it uses the first window within the address space that is available and satisfies the resource request. This allows utilization of the entire available address space and also allows allocation above the 4G boundary. The old resource allocator v3 is still retained for some AMD platforms that do not conform to the requirements of the allocator. Deprecations ------------ ### PCI bus master configuration options In order to minimize the usage of PCI bus mastering, the options we introduced in this release will be dropped in a future release again. For more details, please see [Preparations to minimize enabling PCI bus mastering](#preparations-to-minimize-enabling-pci-bus-mastering-in-coreboot). ### Resource allocator v3 Resource allocator v3 is retained in coreboot tree because the following platforms do not conform to the requirements of the resource allocation i.e. not all the fixed resources of the platform are provided during the `read_resources()` operation: * northbridge/amd/pi/00630F01 * northbridge/amd/pi/00730F01 * northbridge/amd/pi/00660F01 * northbridge/amd/agesa/family14 * northbridge/amd/agesa/family15tn * northbridge/amd/agesa/family16kb In order to have a single unified allocator in coreboot, this notice is being added to ensure that the platforms listed above are fixed before the next release. If there is interest in maintaining support for these platforms beyond the next release, please ensure that the platforms are fixed to conform to the expectations of resource allocation. Best regards, Angel Pons

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 20 Nov '20

20 Nov '20

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1436518: Error handling issues (CHECKED_RETURN) /src/lib/hardwaremain.c: 447 in main() ________________________________________________________________________________________________________ *** CID 1436518: Error handling issues (CHECKED_RETURN) /src/lib/hardwaremain.c: 447 in main() 441 cbmem_initialize(); 442 443 timestamp_add_now(TS_START_RAMSTAGE); 444 post_code(POST_ENTRY_RAMSTAGE); 445 446 /* Handoff sleep type from romstage. */ >>> CID 1436518: Error handling issues (CHECKED_RETURN) >>> Calling "acpi_is_wakeup_s3" without checking return value (as is done elsewhere 89 out of 93 times). 447 acpi_is_wakeup_s3(); 448 threads_initialize(); 449 450 /* Schedule the static boot state entries. */ 451 boot_state_schedule_static_entries(); 452 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

System gcc requirements
by Branden Waldner 20 Nov '20

20 Nov '20

I recently looked in to why I couldn't build coreboot on one of my systems any longer and I think I found the cause. It looks like vboot uses features not available in gcc 6 on Debian Stretch. I actually did manage to get it to build and work by commenting out the offending gcc warning flags and a fallthrough switch attribute, but that's kind of pointless. Is there an expected minimal system gcc version and if so, is it documented? I couldn't find it noted anywhere. Branden

8 31

Termin mit Notiz abgesagt: coreboot Leadership Meeting - Mi 2. Dez. 2020 19:00 - 20:00 (MEZ) (coreboot@coreboot.org)
by Patrick Georgi 18 Nov '20

18 Nov '20

Dieser Termin wurde mit der folgenden Notiz abgesagt: "It's OSFC!" Titel: coreboot Leadership Meeting Meeting Minutes - If you don't have edit access and want it, please ask Patrick G. Wann: Mi 2. Dez. 2020 19:00 – 20:00 Mitteleuropäische Zeit - Berlin Teilnahmeinformationen: Teilnehmen mit: Google Meet https://meet.google.com/syn-toap-agu Per Telefon teilnehmen (US) +1 347-554-5113 (PIN: 858153) Weitere Telefonnummern: https://tel.meet/syn-toap-agu?pin=5345676483196&hs=0 Kalender: coreboot(a)coreboot.org Wer * Patrick Georgi - Organisator * Martin Roth- Veranstalter, Optional * WIM * Dossym Nurmukhanov * christian.walter(a)9elements.com * marshalldawson3rd(a)gmail.com * Stefan Reinauer * jeremy(a)system76.com * Marc Jones * Werner Zeh * David Hendricks * zaolin.daisuki(a)googlemail.com * quasisec(a)google.com * epeers(a)google.com * felix.held(a)amd.corp-partner.google.com * gduynisveld(a)eltan.com * Held, Felix * coreboot(a)coreboot.org * subrata.banik(a)intel.com - Optional * patrick.rudolph(a)9elements.com - Optional * matt.devillier(a)gmail.com - Optional * Ron Minnich - Optional * deb(a)sfconservancy.org - Optional * jaytalbott(a)sysproconsulting.com - Optional * jonzhang(a)fb.com - Optional * Furquan Shaikh - Optional * kerry.brown(a)silverbackltd.com - Optional * Julius Werner - Optional * felix-coreboot(a)felixheld.de - Optional * nico.h(a)gmx.de - Optional * felix(a)felixheld.de - Optional * ed.benyukhis(a)amd.com - Optional * arthur(a)aheymans.xyz - Optional Einladung von Google Kalender: https://calendar.google.com/calendar/ Sie erhalten diese E-Mail unter coreboot(a)coreboot.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie können auch unter https://calendar.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen für Ihren gesamten Kalender steuern. Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger eine Antwort an den Organisator senden und zur Gästeliste hinzugefügt werden. Außerdem könnte er weitere Nutzer einladen und Ihre Antwort ändern. Weitere Informationen: https://support.google.com/calendar/answer/37135#forwarding

1 0

Re: System gcc requirements
by Branden Waldner 18 Nov '20

18 Nov '20

Well, this seems to be really going off topic. My only intention was to ask what the required/recommended host(system) compiler was and what documentation there was for that. Branden Waldner wrote: > Is there an expected minimal system gcc version and if so, is it > documented? I couldn't find it noted anywhere. Nico Huber Wrote: > I don't think it's documented. As you already noticed, we depend on a 3rdparty library (vboot), > so we actually don't know the minimum. I think it would be nice to document the expected compatible version(s), especially if it can done in a version/release relevant way. Trying to build "old" projects without any build system documentation can get pretty frustrating for example. Julius Werner wrote: > So I think the "official" rule is basically that the minimum requirement for host utilities is the > same compiler and version that crossgcc uses, which I think makes some amount of sense > (otherwise we'll just have to keep tracking and deploying two separate versions). It's kind of hard to say it's a rule when it's not written anywhere. Also, while it sounds okay in theory to _require_ and test against a specific version of gcc, that ends up leading to some practicality issues in potentially needing to build a specific version of gcc on the host if it's not packaged, followed by the usual crossgcc build. Though in my situation, updating from Debian Stretch to Buster would likely fix the problem for now (and be significantly faster then compiling gcc as well (I would also likely already have most of the packages cached locally)). Following up on that, if Jenkins only tests using the same version of gcc as the current coreboot crossgcc, doesn't that leave out testing potential compatibility problems with newer (or older) versions of gcc (or clang?) that could be automatically tested for and identified as early as possible? Of course, that could end up with orders of magnitude more work for the build bot to do, which could end up being impractical. Julius Werner wrote: > FWIW I do seem to recall that this already came up back when __attribute__((fallthrough)) was > added to vboot, and back then everyone seemed to agree that it was reasonable to assume the > same version for the host compiler that we use in crossgcc. I would consider "assuming" the same host compiler as crossgcc to be a bug, since a coded check can do a lot better then that, with the the required maintenance of only being changed (automatically?) when crossgcc is updated. I don't recall when I first noticed the problem, but I "assumed" it was a regression that would be fixed, not that my system no longer had a new enough version of gcc. It was also confusing why vboot was being pulled in even though I didn't have it selected. While it sounds simple enough that cbfstool builds in crypto/hash support from vboot, it also doesn't really seem that big a deal to expect it to be able to option it out either. Of course there is some extra maintenance involved in that, but with cbfs being a stable for quite a while (according to recent posts at least), there shouldn't be too many changes? That is not necessarily tied in to the host gcc problem though - I realize that I need a newer version and didn't specifically complain about it, other then it being for rather trivial reasons. Also, an interesting reference for the required build environment is the linux kernel of course: https://www.kernel.org/doc/html/latest/process/changes.html (that url seems weird, but the page title is "Minimal requirements to compile the Kernel"). That likely requires some automated testing to verify and also probably ends up with a lot of work to maintain, but at least it's there. I hope I at least managed to add something of value to the conversation, though some of it just seems like me complaining... Branden Walder

1 0

Planning the next coreboot release
by Angel Pons 17 Nov '20

17 Nov '20

Hi everybody, It's high time we looked into cutting yet another release. As usual, other than our 6-monthly cadence of incrementing a number on our tree and pushing out tarballs and press releases, no particular rationale prompts this event. Unlike previous occasions, this is my first time executing the coreboot release process along with Patrick Georgi. We plan to do the release on Wednesday, November 18. This announcement is in conformity with the process described on https://doc.coreboot.org/releases/checklist.html, as we're currently at the "~2 weeks prior to release" point. For this reason, I would earnestly appreciate it if you (everyone subscribed to this list, but given that you're reading this mail, yes, you too!) could help out with the following: 1. Testing: the more, the better. Please test as much of your coreboot-supported hardware as you can, report and/or address any issues, and upload fresh reports to the board-status repo. Despite having no quality requirement to give a new number to our tree (create a new release), it is important to ensure what we have in the tree is still functional, since it lowers the work needed to pin-point new issues (bisections since 4.12 should still take 12 steps or less at this time, even though there's about 40% more commits than between the last two releases). 2. Please try to postpone riskier changes and similar until the release is done (unless they're ready to land in the next few days), in order to keep the tree stable while people test whether their hardware still works as expected. If a major feature doesn't make it into this release, don't worry; it can always be part of the following release. Let's make sure this coreboot release keeps booting. 3. Please take a look at the preliminary release notes in Documentation/releases/coreboot-4.13-relnotes.md and add whatever happened since 4.12 that is worth mentioning. If unsure, simply push a change to Gerrit and have your fellow developers discuss it. Thanks, Angel Pons

1 2

Coreboot Picasso FSP questions
by chen.kenyy＠inventec.com 16 Nov '20

16 Nov '20

Hi, I study in AMD AGESA v9 boot in the coreboot. So far, I boot to the FSP image failed as below log. CBFS: Locating 'fspm.bin' CBFS: 'fspm.bin' not found. FSPM not available or failed to load! And I google the related information, found the gerrit review information(https://review.coreboot.org/c/coreboot/+/34423/), I want to query you how to make/create the FSP binary for AMD or FSP information to coreboot image. Could you give me some instructions? Thanks.

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