August 2019 - coreboot - mail.coreboot.org

OpenBSD won't install on an x220 Thinkpad with Coreboot
by Robert Milton April 12, 2020

April 12, 2020

I'm trying to get OpenBSD to install on an x220 Thinkpad with Coreboot/SeaBIOS but I'm running into two problems: the ethernet device doesn't work and OpenBSD doesn't detect my HDD. dmesg said em0 wouldn't load because the EEPROM had an invalid signature. I have no idea why OpenBSD doesn't see my HDD though. It's strange because everything works fine under Linux. And I cannot seem to mount a usb drive under the OpenBSD installer to attach dmesg errors. I originally posted this as a bug report to bug report mailing list but Theo said it would be better suited for Coreboot's and wasn't a bug in OpenBSD.

4 4

Optiplex 790 now has preliminary support by coreboot
by Taiidan＠gmx.com Jan. 15, 2020

Jan. 15, 2020

https://review.coreboot.org/21774 In case anyone else didn't notice - It is a sandy/ivy system with IOMMU. This is great and should help get coreboot in to the corporate user world.

2 1

[AMD 16h / ASUS AM1I-A] 1866MHz CL9 RAM runs only as 1333MHz CL9 - how to fix?
by Mike Banon Nov. 17, 2019

Nov. 17, 2019

A pair of 1866MHz CL9 RAM modules* runs only as 1333MHz CL9 on 16h AM1I-A with coreboot is installed, but worked faster when a proprietary UEFI was installed. To fix this "turtle RAM" coreboot problem I tried to play with buildOpts.c - https://review.coreboot.org/c/coreboot/+/33920 , but the things like "#define BLDCFG_MEMORY_CLOCK_SELECT DDR1866_FREQUENCY" sadly did not help. Any ideas how to improve the RAM speeds? How I can force this RAM to run faster? Best regards, Mike Banon [*] Crucial Ballistix Tactical Series DDR3 1866MHz CL9 (PC3-14900 9-9-9-24) UDIMM 240-Pin modules, part number BLT8G3D1869DT1TX0

3 9

Web site revamp
by Timothy Pearson Sept. 13, 2019

Sept. 13, 2019

I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful. I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation: "Fast, secure and flexible OpenSource firmware" "coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology." present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth. One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD. Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion. I would propose the following changes, and welcome discussion on these topics: The heading could read something like "Flexible, open source frameworks for system firmware" and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology." Thoughts? -- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com

10 26

Verified boot on AMD Picasso
by Kyösti Mälkki Sept. 1, 2019

Sept. 1, 2019

Open letter to coreboot leadership I have spent some time helping out sort some fundamentals on the tree to bring up that new amd/picasso platforms. During the reviews I found some proceedings there somewhat alarming, so I am hoping for coreboot leadership and trademark holder to make some clear statements on the topic. Now, I may know a bit more than I can write here in public, I try defer from disclosing information received in private emails and stick with the information that can be found in gerrit review commits. In short; appers it has been decided verstage will run on PSP instead of x86 cores. So which of the following approaches do You find acceptable: a) Platform shall use proprietary ARM TrustZone instead of vboot for any cryptographics and measurements of firmware. This may be the AMD endorsed way of doing things. b) Platform shall use vboot, built and signed internally at AMD, for the Security Processor (aka PSP), using their choice of proprietary tools. While GPL compliance may say build scripts are to be published in such case (IANAL!!), that does not mean the used compiler is available for purchase on open market. c) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Built PSP vboot binary shall be reproducible and signed with OEM key. Community developers will not be able to run custom verstage builds, but are able to audit integrity of the source. d) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Built PSP vboot binary should be reproducible. Community developers are able to run custom verstage builds, but state of PSP/TPM/etc may reveal to the OS that sections of the firmware does not originate from the OEM, as detected by the lack of signage or use of insecure key published for experimental use only. User experience or DRM might suffer. e) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Developers can run whatever they want on PSP, without OS ever noticing it. f) Something else in between the presented choices or outside of them? Regards, Kyösti Mälkki

3 7

Chainloading Windows from a Linux Payload
by Matt B Aug. 27, 2019

Aug. 27, 2019

Greetings, From what I can find, Linux can only chainload another linux kernel. (via kexec) Does this mean that a Linux payload like LinuxBoot cannot be used to boot Windows or another OS, either directly or by chainloading another payload from CBFS? It's nice that a Linux payload can provide superior flexibility and configurability than UEFI with the added benefit of a battle-hardened environment, but the ability to only boot a Linux OS seems like a pretty significant limitation (if this is indeed the case). Sincerely, -Matt

7 12

Configure SATA controller in IDE mode?
by Rafael Send Aug. 23, 2019

Aug. 23, 2019

Hi, I'm running a Tianocore payload on coreboot and I'm not able to boot Windows (or Windows installers). I eventually get errors like "UNMOUNTABLE_BOOT_VOLUME" and "DRIVER_PNP_WATCHDOG". Some searching leads me to the conclusion that in some cases putting one's SATA controller in IDE mode allows these devices to boot. Is there a KConfig option that enables this? Thanks, Rafael

2 2

Final calls for S3 suspend support on amdfam10-15
by Kyösti Mälkki Aug. 22, 2019

Aug. 22, 2019

Hi The decisions are out on 4.11 release requirements. Unless anyone acts on it, amdfam10-15 boards will hit deprecation due to: * RELOCATABLE_RAMSTAGE=n * CAR_GLOBAL_MIGRATION=y * C_ENVIRONMENT_BOOTBLOCK=n To smooth down the path, should anyone want to attempt on fixing these, I have pushed a patchset [1] that removes S3 suspend support from said platform. Depending of what the response is, I hope to have that submitted already before 4.11 release. The latest info [2] I have is asus/kcma-d8 not working and asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, that is. No resume logs have been brought to my knowledge for 12 months. I also had some suspicions that tests results were mistakenly from suspend-to-disk (S4). Affected boards are asus/kcma-d8 and asus/kgpe-d16. [1] https://review.coreboot.org/c/coreboot/+/15474 [2] https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html Kind regards, Kyösti

5 12

Deprecate Cavium ThunderX support
by Patrick Rudolph Aug. 20, 2019

Aug. 20, 2019

Hi folks, Currently there are only 2 boards using Cavium's ThunderX (CN81xx) and both aren't available on the free market. Cavium haven't upstreamed their Arm Trusted Firmware, so it's a bit of maintenance work to keep it alive. If nobody wants to take care of if, it will marked deprecated with he next release (4.11) and removed before the 4.12 release. 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

1 0

Proposal: Improved ACPI generation
by Patrick Rudolph Aug. 20, 2019

Aug. 20, 2019

Hi folks, for improved runtime ACPI generation I would like to introduce a new member in struct device_operations. It would return the ACPI HID for the given device similar to the ACPI NAME that's already implemented: const char *(*acpi_name)(const struct device *dev); It would look like this: const char *(*acpi_hid)(const struct device *dev); How about that? 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