coreboot November 2019

coreboot@coreboot.org

52 participants
51 discussions

MrChromebox 4.11 community release
by Matt DeVillier 26 Nov '19

26 Nov '19

Hot off the heels of the previous hotfix is a fresh release based on the newly-tagged coreboot 4.11. In addition to being rebased on the latest version of coreboot, this release features a host of improvements and fixes: * fixed issue with NVRAM being corrupted by Windows * new/improved UEFI Boot Options/Settings screens * improved header layout * simplified menu options * more descriptive naming for SATA, NVMe, and USB drives in boot menu * easier to make changes to and save bootorder entries * open-source coreboot native graphics init (libgfxinit) now used for Haswell, Broadwell, and Skylake devices instead of closed-source GOP driver * better scaling of boot splash/menus for HiDPI displays This MrChromebox release offers coreboot/Tianocore images for close to 70 Chromebooks/Chromeboxes as well as all Purism Librem laptops, all easily flashed using my ChromeOS Firmware Utility Script [1]; a full list of supported devices can be found on my site [2]. All other devices supported by the coreboot 4.11 release can easily take advantage of the improvements in my tree by cloning my coreboot repo and building as usual. All changes on the Tianocore side have already been merged and are available to anyone using the default coreboot repo. As usual, the full list of changes can be found on my github repos: https://github.com/MrChromebox/coreboot/commits/2019.11.28 https://github.com/MrChromebox/edk2/commits/2019.11.28 https://github.com/MrChromebox/chrome-ec/branches/all cheers, Matt [1] https://mrchromebox.tech/#fwscript [2] https://mrchromebox.tech/#devices

2 1

FOSDEM Open Source Firmware devroom CFP
by Michal Zygowski 24 Nov '19

24 Nov '19

Only 7 days remain for submitting a talk proposals for @fosdem Open Source Firmware, BMC and Bootloader Devroom! The Deadline is set to Saturday, 1st December 2019 23:59:59 UTC. Don't miss it! Visit: https://penta.fosdem.org/submission/FOSDEM20 Details: https://lists.fosdem.org/pipermail/fosdem/2019q4/002933.html -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com

1 0

Using kernelCI infrastructure for firmware testing
by Patrick Rudolph 22 Nov '19

22 Nov '19

Hi folks, this is an attempt to improve firmware testing by using the infrastructure and knowledge of the kernelci community. If you think this is not the right place, please point me in the right direction. I'm a coreboot[1] developer trying to make sure that the master branch[2] doesn't regress. Currently there's no public firmware testing, only internal validation suites used by some companies that lack direct and automated feedback before a commit is actually merged. As this isn't a coreboot only topic, but applies to all open source "bios vendors", I added the u-boot project in CC as well. For me firmware testing looks pretty similar to kernel testing: * flash firmware to test * boot a known good linux kernel * run tests in userspace and verify hardware/software works as expected On the hardware side we have boards in our lab that allow remote power cycling and firmware flashing. It is attached to self hosted stock LAVA2018. But as we are firmware engineers, we don't want to deal with the administration of servers. Here are a few questions for you: * Would it make sense to also cover open source firmware tests on kernelci? * Do you build the linux images yourself? * Would you accept firmware images generated by a third party? * Can anybody get an account for the LAVA server to run firmware test? * What communication channels do you recommend? * Will there be meetings or conferences to get in contact with the community to talk about this? [1]: https://coreboot.org/ [2]: https://review.coreboot.org/ Kind Regards, Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch

3 2

Looking for INTEL board compatible with Coreboot
by phakt＠elude.in 21 Nov '19

21 Nov '19

Hello, on FreeBSD forum there was a discussion about "FreeBSD friendly Motherboard compatible with Coreboot" link: https://forums.freebsd.org/threads/freebsd-friendly-motherboard-compatible-… the INTEL boards compatible with Coreboot seems to be: - Gigabyte GA-B75M-D3H - Asrock E350M1 does anyone know better options? another question still looking for answer: using flashrom if you type: -L | --list-supported print supported devices it says: Supported flash chips (total: 391): can someone check output and tell which are the best boards? Thanks

5 11

Planning coreboot 4.11
by Patrick Georgi 20 Nov '19

20 Nov '19

Hi everybody, I'm planning to release coreboot 4.11 two weeks from today, Nov 18th. As usual, it's a snapshot release, not aligned with any specific feature or development. coreboot releases exist to provide synchronization points with downstream projects, and simply to keep version numbers (which we derive automatically from git history) meaningful: coreboot-4.0-26987 provides less information at a glance (e.g. about the approximate year it's from) than coreboot-4.10-1355. We'll also use it as an opportunity to remove[0] a number of unmaintained platforms, MIPS and AMD Fam12h, directly after the release. Finally the releases give us the opportunity to issue a call for testing, encouraging folks to test the hardware they have at least twice every year on latest master. Of course, don't test random master revisions if you don't have the means to recover from a bad flash! So here's how you can help (I'll do the same, but the more, the merrier): - Test current master branch on the hardware you have around to make sure it's looking reasonable. - Ideally, prepare for testing in the days before the release when things have settled a bit, and report a recent status to the list, IRC or to me directly, so I don't pick a dud as release revision. - Fix issues you notice, or at least report them (the mailing list is a fine place for such reports) - Report the test results to the board-status repository (using the tools in util/board_status/) - Fill in any notable developments since 4.10 in Documentation/releases/coreboot-4.11-relnotes.md - Maybe wait with merging riskier changes until after the release Thanks, Patrick [0] https://review.coreboot.org/c/coreboot/+/34919 for MIPS, https://review.coreboot.org/c/coreboot/+/36187 for AMD Fam12h -- 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

5 7

Copy-first platform additions (was: Re: Re: Proposal to add teeth to our Gerrit guidelines)
by Nico Huber 20 Nov '19

20 Nov '19

Am 05.11.19 um 20:23 schrieb Patrick Georgi: > On Tue, Nov 05, 2019 at 06:37:02PM +0100, Nico Huber wrote: >> I mean "rubber-stamping of *huge* commits". That huge that it is >> obvious that no review happened, e.g. 1k+ LOC copy-pasta. Also, the >> guidelines say "This means you shouldn't +2 a patch just because you >> trust the author of a patch [...]" I didn't want to quote the whole >> paragraph, maybe I should have ;) > Some of the mega patches are copies of a predecessor chip (with the > minimum amount of changes to integrate it in the build), that are > then modified to fit the new chip. Ack. I think that is a problem. If this procedure is intended, I think we should update our guidelines to reflect that. > > The idea was precisely to ensure that changes between the generations > are visible in the history. That's nice for historians, but what about maintenance? There is nothing in the Git history if a piece of code was intended/validated/reviewed for a given chip (unless it was adapted which is the less common case). > > That was considered an acceptable strategy for a long time (after > we broke up 82801xx because fixing one variant broke another). We > can certainly revisit that, but to me that change appears to have > happened gradually and without much notice. That's news to me. I didn't witness this break up. And it looks like afterwards, new chipsets were added with already patched code bases. The first unpatched copy I could find (didn't look very long) is soc/intel/braswell/. Was there any public discussion that I could look up? What I'd like to figure out most is how our Gerrit guidelines are supposed to be interpreted for a review of such a patch. I see no exception for not reviewing such patches and have no idea how one could review one. Also what would be the responsibilities of a reviewer after review? Nico -- M. Sc. Nico Huber Senior Consultant SINA Software Development and Verification Division Defence secunet Security Networks AG Phone: +49-201-5454-3635, Fax: +49-201-5454-1325 E-Mail: nico.huber(a)secunet.com Mergenthalerallee 77, 65760 Eschborn, Deutschland www.secunet.com _____________________________________________________________________ secunet Security Networks AG Registered at: Kurfuerstenstraße 58, 45138 Essen, Germany Amtsgericht Essen HRB 13615 Management Board: Axel Deininger (CEO), Torsten Henn, Dr. Kai Martius, Thomas Pleines Chairman of Supervisory Board: Ralf Wintergerst ______________________________________________________________________

6 8

Announcing coreboot 4.11
by Patrick Georgi 19 Nov '19

19 Nov '19

It's my pleasure to announce that coreboot 4.11 was just released. Release notes follow. Note that there are deprecations listed that will be in effect immediately. The first two (Fam12 and MIPS) probably don't affect anybody, but the third item has quite a lot of ripple effect. I was considering giving affected platforms a chance until the end of this year but that carries the risk that the deprecation will be postponed even longer. While these platforms will be removed soon (patches to that end are appearing on review.coreboot.org) we'll be very happy to welcome them back as soon as they're brought up to current standards. If this is done soon, the difference between the trees won't be significant so the amount of extra work should be reasonable. Regards, Patrick --- release notes --- This release cycle was a bit shorter to get closer to our regular schedule of releasing in spring and autumn. Since 4.10 there were 1630 new commits by over 130 developers. Of these, about 30 contributed to coreboot for the first time. Thank you to all contributors who made 4.11 what it is and welcome to the project to all new contributors! Clean Up -------- The past few months saw lots of cleanup across the source tree: The included headers in source files were stripped down to avoid reading unused headers, and unused code fragments, duplicate preprocessor symbols and configuration options were eliminated. Even ACPI got its share of attention, making our tables and bytecode more standards compliant than ever. The code across Intel's chipsets was unified some more into drivers for common function blocks, an effort we're more confident will succeed now that Intel itself is driving it. Chipset work ------------ Most activity in the last couple months was on Intel support, specifically the Kaby Lake and Cannon Lake drivers were extended for the generations following them. On ARM, the Mediatek 8173 chipset support saw significant work while the AMD side worked on getting Picasso support in. But everything else also saw some action, the relatively old (e.g. Intel GM45, Via VX900), the tiny (RISC-V) and the obscure (Quark). Verified Boot ------------- The vboot feature that Chromebooks brought into coreboot was extended to work on devices that weren't specially adapted for it: In addition to its original device family it's now supported on various Lenovo laptops, Open Compute Project systems and Siemens industrial machines. Eltan's support for measured boot continues to be integrated with vboot, sharing data structures and generally working together where possible. New devices ----------- With 4.11 there's the beginning of support for Intel Tiger Lake and Qualcomm's SC7180 SoCs, while we removed the unmaintained support for Allwinner's A10 SoC. There are also 25 new mainboards in our tree: * AMD PADMELON * ASUS P5QL-EM * EMULATION QEMU-AARCH64 * GOOGLE AKEMI * GOOGLE ARCADA CML * GOOGLE DAMU * GOOGLE DOOD * GOOGLE DRALLION * GOOGLE DRATINI * GOOGLE JACUZZI * GOOGLE JUNIPER * GOOGLE KAKADU * GOOGLE KAPPA * GOOGLE PUFF * GOOGLE SARIEN CML * GOOGLE TREEYA * GOOGLE TROGDOR * LENOVO R60 * LENOVO T410 * LENOVO THINKPAD T440P * LENOVO X301 * RAZER BLADE-STEALTH KBL * SIEMENS MC-APL6 * SUPERMICRO X11SSH-TF * SUPERMICRO X11SSM-F In addition to the Cubieboard (which uses the A10 SoC), we also removed Google Hatch WHL. Deprecations ------------ Because there was only a single developer board (AMD Torpedo) using AGESA family 12h, and because there were multiple, unique Coverity issues with it, the associated vendorcode will be removed shortly after this release. Support for the MIPS architecture will also be removed shortly after this release as the only board in the tree was a discontinued development board and no other work has picked up MIPS support, so it's very likely broken already. After more than a year of planning and following the announcement in coreboot 4.10, platforms not using relocatable ramstage, a C bootblock and, on systems using Cache as RAM, a postcar stage, won't be supported going forward. Significant changes ------------------- ### `__PRE_RAM__` is deprecated Preprocessor use of `defined(__PRE_RAM__)` have been mostly replaced with `if (ENV_ROMSTAGE_OR_BEFORE)` or the inverse `if (ENV_RAMSTAGE)`. The remaining cases and `-D__PRE_RAM__` are to be removed soon after release. ### `__BOOTBLOCK__` et.al. are converted This applies to all `ENV_xxx` definitions found in `<rules.h>`. Write code without preprocessor directives whenever possible, replacing `#ifdef __BOOTBLOCK__` with `if (ENV_BOOTBLOCK)` In cases where preprocessor is needed use `#if ENV_BOOTBLOCK` instead. ### `CAR_GLOBAL` is removed where possible For all platform code with `NO_CAR_GLOBAL_MIGRATION=y`, any `CAR_GLOBAL` attributes have been removed. Remaining cases from common code are to be removed soon after release. ### `TSEG` and `cbmem_top()` mapping Significant refactoring has bee done to achieve some consistency across platforms and to reduce code duplication. ### Build system amenities ### The build system now has an `all` class of source files to remove the need to list source files for each and every source class (romstage, ramstage, ...) The site-local/ mechanism became more robust. ### Stricter coding standards to improve security ### The build now fails on variable length arrays (that make it way too easy to smash a stack) and case statements falling through without a note that it is intentional. ### Shorter file headers ### This project is still under way, but we started moving author information from individual files into the global AUTHORS file (and there's the git history for more details). In the future, we also want to replace the license headers (lots of lines) in each file with spdx identifiers (one line) and so we added a LICENSES/ directory that contains the full text of all the licenses that are used throughout our tree. ### Variant creation scripts ### To ease the creation of variant boards, `util/mainboard/` now contains scripts to generate a new variant to a given board. These are still specific to google/hatch at this time, but they're written with the idea of becoming more generally useful. ### Payloads ### Payload integration has been updated, coreinfo learned to cope with UPPER CASE commands and libpayload knows how to deal with USB3 hubs. ### Added VBOOT support to the following platforms: * intel/gm45 * intel/nehalem ### Moved the following platforms to C_ENVIRONMENT_BOOTBLOCK: * intel/i945 * intel/x4x * intel/gm45 * intel/nehalem * intel/sandybridge * intel/braswell ### libgfxinit ### Most notable, dynamic CDClk configuration was added to libgfxinit, to support higher resolution displays without changes in the static configuration. It also received some fixes for better DP and eDP compatibility, better error recovery for Intel's fickle GMBus and updated platform support: * Correct HDMI clock limit for G45. * DP support for Ibex Peak (Ironlake graphics). * Fixed scaling on eDP for Broadwell. * Support for ULX variants of Haswell and later. * Support for Kaby, Amber, Coffee and Whiskey Lake. ### Other * Did cleanups around TSC timer * Improved automatic VR configuration on SKL/KBL * Filled additional fields in SMBIOS type 4 * Removed magic value replay from Intel Nehalem/ibexpeak code base * Added OpenSBI on RISCV platforms * Did more preparations for Intel TXT support * Did more preparations for x86_64 stage support * Added SSDT generator for arbitrary SuperIO chips based on devicetree.cb -- 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

1 0

T440P: Unable to initialize memory speeds above 1600 MT/s
by ad-min＠mailbox.org 19 Nov '19

19 Nov '19

I just bought a pair of HyperX DDR3L-2133 CL11 memory. They are supported and run fine at 2133 MT/s with the original Lenovo firmware. However Coreboot only registers them at 1600 MT/s. Changing the value of .max_ddr3_freq to 2133 in src/mainboard/lenovo/t440p/romstage.c leads to a bricked notebook. A beeping sound occurs, regardless of the installed memory type (1600 or 2133).

2 2

[PATCH v3 0/3] firmware: google: Fix minor bugs
by patrick.rudolph＠9elements.com 18 Nov '19

18 Nov '19

From: Patrick Rudolph <patrick.rudolph(a)9elements.com> This patch series fixes 3 independent bugs in the google firmware drivers. Patch 1-2 do proper cleanup at kernel module unloading. Patch 3 adds a check if the optional GSMI SMM handler is actually present in the firmware and responses to the driver. Changes in v2: - Add missing return statement - Add s-o-b on GSMI patches - Add define for reserved GSMI command Changes in v3: - Cosmetic changes only Arthur Heymans (2): firmware: google: Unregister driver_info on failure and exit in gsmi firmware: google: Probe for a GSMI handler in firmware Patrick Rudolph (1): firmware: google: Release devices before unregistering the bus drivers/firmware/google/coreboot_table.c | 7 +++++++ drivers/firmware/google/gsmi.c | 25 ++++++++++++++++++++++++ 2 files changed, 32 insertions(+) -- 2.21.0

1 1

Leafhill / Apollolake : S3 resume failed
by Praveen.hp7＠gmail.com 18 Nov '19

18 Nov '19

Hi all, any body tested out suspend/resume functionality on any of Apollolake based board and found working ? On Leafhill board ( with HAVE_ACPI_RESUME is selected in mainboard Kconfig ) , suspend works fine and 'previous sleep state' reads correctly but in resume path boot hangs in romstage ( FSP-M init ) for while and board reboots (behaves as warm boot ) S3 suspend/resume with Fsp from github works fine on other Boot loaders like UEFI & Slim Boot loader. please anyone can suggest me do i need enable extra config's in mainboard or is it know issue ?

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 November 2019