coreboot April 2020

coreboot@coreboot.org

39 participants
36 discussions

Mainboard porting assistance
by Benjamin Doron 09 Apr '20

09 Apr '20

Hi all, I own an Acer Aspire VN7-572G and have not been impressed with its OEM firmware. After discovering that it does not utilise Intel's Boot Guard technology, that several Skylake and Kabylake laptops (it has a Skylake chip, but I read that the platforms are similar) have received successful coreboot ports and reading the porting guide on the wiki, I figured that I could give porting coreboot to my laptop a shot. When I was done, I figured that I had an image that might boot so I flashed it to my laptop with a Raspberry Pi and a SOIC clip. However, here's what it does: a) It powers on quietly, as expected; b) The backlight and power LED light up; c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too. After 15 minutes and a second attempt, I figured that I could no longer blame anything on a long first boot-up and gave up and flashed back to stock. Now, in all honesty I should have tried first without cleaning Intel ME but I find it so much more likely that I did something wrong than that cleaning ME was the sole problem. Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot

7 42

(no subject)
by Luke Mawson 09 Apr '20

09 Apr '20

Hi, I am a complete newb, though I want nothing more than to be able to program at a bare metal level and help develop for this platform. How do I get started? I am sure there is likely many emails like this, and I have truly done my best hunting for information. I have a small understanding of assembly, and have tried reading TRMs to no avail. Is there any texts anyone could recommend to get me started? I would truly be ever so grateful for any advice. Thanks, Luke

2 1

USE_BLOBS vs AMD platforms
by Michal Zygowski 09 Apr '20

09 Apr '20

Hello coreboot community, On the recent coreboot leadership a discussion arose around the patches touching USE_BLOBS option: https://review.coreboot.org/c/coreboot/+/39884 https://review.coreboot.org/c/coreboot/+/37972 A lot of items have been pointed to be solved: 1. A global policy about building blobless images. Currently there is no unified policy how coreboot build system should behave when building with blobs or not. There are numerous mainbaords that require blobs in order to obtain bootable image: FSP, AGESA, MICROCODE, PSP FW. Some of them can be built without blobs with a warning at the end of build process that crucial silicon initialization blobs are missing (example: amd/gardenia), however this behavior is not consistent across whole coreboot tree. There is already very few boards that do not require any blobs in buld process to obtain bootable image. 2. People building coreboot may think that they are building fully open image, but for x86 architecture in particular, it is impossible currently, unless we make some steps to avoid it (which I will describe below). On the second hand, if a new-to-coreboot person build an image that is not bootable, he may be discouraged to use coreboot if his device will be bricked. So a conclusion from the leadrship meeting is to have USE_BLOBS enabled by default (however not selected) in order to keep the usability of the built images. I encourage to refer to the meeting minutes from coreboot leadership meeting: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… tl;dr; In the light of above matters I came up with an idea to build coreboot for AMD based boards without blobs by using flashmap. The main goal is to build a coreboot image purely from source code and update only parts of the firmware that contain BIOS code. A mechanism similar to Intel's flash descriptor and bios region, however not present on AMD firmware layout. My idea is intended to be a close equivalent to the Intel's flash descriptor. Example basic layout for AMD firmware could look like this: FLASH $(CONFIG_ROM_SIZE) { PSPFW(PRESERVE) 0x100000 COREBOOT(CBFS) AGESA(PRESERVE)@$(AGESA_BINARY_PI_LOCATION) 0xa0000 UNUSED BOOTBLOCK 0x10000 } - PSPFW should contain AMD PSP firmware which lies at fixed offsets of the SPI flash (typically is put at offset of 0x20000 of the beginning of the flash). In order to utilize the FMAP with PSP firmware one can use AMDFW_OUTSIDE_CBFS which will `dd` the whole PSP firmware to the coreboot image at offset 0x20000. The preceding 128KiB (offsets 0x0 - 0x20000) may be either sacrificed as unused or used for other purposes (CONSOLE, SMMSTORE, VPD etc.). According to my knowledge the whole PSP firmware is less than 1MB for family 16h and earlier, however with "dual" PSP directory it may consume more. For family 17h and later it also may be insufficient, but one can always adjust it for families that need it. - AGESA is typically a blob that must be placed at fixed offset defined at blob build time (except open-surce AGESA). AGESA does not have any rebase mechanism as FSP 2.0 and later have, thus a separate FMAP region is added for the blob. Assumed 640K but may be adjusted if needed. The interface to the binary will have to be adjusted to use FMAP to locate it (or a Kconfig option could be used to do switch between FMAP and CBFS). - bootblock is always placed at the bottom of SPI flash (excpet family 17h which can define the reset vector entry point to be elsewhere than 0xFFFFFFF0) so another region has been added for the entire bootblock. Default size for the x86 bootblock is 64K. - UNUSED is a gap between AGESA blob and the bootblock which may be used for other purposes (CONSOLE, SMMSTORE, VPD etc.) - the rest of the space will be occupied by coreboot CBFS The main advantage is that if one flashes the full image with blobs once, each next update can be built without them. Flashrom with FMAP support would allow to flash only COREBOOT and BOOTBLOCK regions without touching blobs. Of course appropriate warnings should be printed at the end of build process that no blobs have been used and one must ensure these are already present on the SPI flash. This way coreboot can be built purely from source, since microcode is embedded into AGESA binary. Also the situation when blobs have been enabled an waring may be printed, that coreboot used blobs to build the image. These warnings should be consistent for all boards that use blobs (although there may be exceptions, for ARM I guess?). I assume there will be many questions and I haven't covered everything with my idea, so any suggestions and feedback are welcome. Regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

1 0

Cannot access PCI Extended Capabilities registers with Coreboot?
by Rafael Send 07 Apr '20

07 Apr '20

Hi, I've been trying to get a PCIe add-in card working in my X210 M.2 slot for a couple weeks. There is a hack to get it recognized which involves writing to one of the Extended Capability registers from an EFI shell, but apparently something about the way Coreboot initializes PCI (?) makes these inaccessible. It appears to work fine on stock BIOS, so I'm wondering (1) what about Coreboot might cause this issue and (2) how would one go about debugging / fixing it? Cheers, Rafael

1 0

Laptop EC questions
by Lomár Berry 07 Apr '20

07 Apr '20

I have been looking at trying to port coreboot to my HP zBook 15 G2. Everything is seemingly fine, I can get an image built as this machine is similar to the Lenovo t440p. Unfortunately I have yet to have a successful startup. There are a few differences in the machine which include having a dedicated Nvidia GPU, which i have loaded the video bios file for based on how things were done for SpookySkeletons' 8770w build at https://github.com/SpookySkeletons/Coreboot_8770w The only thing I can think of would be the Embedded Controller. Unfortunately there isnt a lot of documentation on how the EC could cause these problems nor are there any hints towards how to potentially integrate them into the build. I have found that the EC is an MEC1322 which is a part of the chrome-ec project and was wondering if there may be an easy way to do this integration to further test. Thanks

3 4

Debug MRC.BIN, how to make ramstage CBMEM persistant across reboot ?
by baylee4＠protonmail.com 05 Apr '20

05 Apr '20

Hi, I'm trying to debug the MRC.BIN on a T440p (more details here : https://www.reddit.com/r/coreboot/comments/ft4950/t440p_32gb_of_ram/) However I cannot access the debug logs of the previous boot when I use CBMEM, it seems it's wiped out on the next boot. Do you know how could I access the ramstage CBMEM logs to see exactly where the MRC.BIN fails ? There is no serial port on the T440p, and the USB 2.0 debug port is not exposed, so it seems that using CBMEM is the only option. Thank you, Baylee4

3 9

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2020