coreboot

coreboot@coreboot.org

17 participants
39654 discussions

05 Sep '22

First, I just want to thank all of you for what you do. Using Coreboot is delightful. I had a question about how the program verifies UEFI OS's. I'm using it to update a chromebook to ChromeOS flex and receiving the error; doesn't contain a verifiable 64-bit UEFI OS.d From the documentation ChromeOS Flex is supposed to be a 64 bit UEFI so I"m wondering if it could be something I did while creating the boot media, a problem with updating chromebook, or how coreboot is verifying the OS? After entering the menu I can boot to the USB and install just fine so no big deal just curious why it gave that error. Thanks again for putting in the work! We all appreciate it.

3 5

Invalid opcode exception(06) while loading network drivers in CamelBack Mountain CRB (Coreboot-4.11 + Uefipayload)
by Noyal Johnson 29 Aug '22

29 Aug '22

Hi, I am building the coreboot-4.11 with Uefipayload for Camelback Mountain FSP-based CRB. I am seperately compiling the Uefipayload in the edk2 tool (version : uefipayload_202107) downloaded from Mrchromebox in the github and merging as an ELF executable payload. The coreboot was succesfully loaded and OS was booted. In the UEFI shell, when I tried to use network, it was seen that network controller and stack drivers are not available in the payload. I have seperataly compiled the network stack drivers in the same edk2 tool and tried to load at runtime in the UEFI shell along with the network controller driver provided by Intel. At first, I loaded network controller driver and the device was detected as given below "Intel(R) I210 Gigabit Network Connection" Later, I tried loading the network stack drivers in the sequence given below 1, SnpDxe.efi 2, MnpDxe.efi 3, ArpDxe.efi While loading the "ArpDxe.efi", an exception has been occured given below, !!!! X64 Exception Type - 06 (#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!! !!! Cant find image information !!! I tried loading Uefipayload in which network stack drivers are merged at compile time, still the result was same. But, when I tried loading the network stack drivers compiled in same edk2 tool and network controller driver in the actual BIOS present in CRB, all the network stack drivers was successfully loaded and ethernet was initilized. I am suspecting that network stack driver / controller driver is trying to execute a particular instruction which is not supported in coreboot. Whether any instruction sets I have to separately enable in coreboot. If no, what could be the reason for this exception. Regards, Noyal Johnson

2 1

Coreboot
by Sion Buckler 28 Aug '22

28 Aug '22

Sirs, Is the following UpBoard suitable for coreboot? Sion Intel Atom® x5-z8350

1 0

Invalid opcode exception(06) while loading network drivers in CamelBack Mountain CRB (Coreboot-4.11 + Uefipayload)
by Noyal Johnson 27 Aug '22

27 Aug '22

1 0

LEAVE - UNSUBSCRIBE
by Gert Vanhaerents 26 Aug '22

26 Aug '22

Hi, I have sended a several mails to leave this group, but the mails comes always back. Please Unsubscribe me from this group! BR, Gert

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 26 Aug '22

26 Aug '22

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 1493415: Null pointer dereferences (REVERSE_INULL) /src/soc/intel/alderlake/hsphy.c: 71 in heci_get_hsphy_payload() ________________________________________________________________________________________________________ *** CID 1493415: Null pointer dereferences (REVERSE_INULL) /src/soc/intel/alderlake/hsphy.c: 71 in heci_get_hsphy_payload() 65 uint32_t reserved[2]; 66 uint32_t status; 67 uint8_t hash_type; 68 uint8_t hash[MAX_HASH_SIZE]; 69 } __packed reply; 70 >>> CID 1493415: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "buf_size" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 71 if (!buf || !buf_size || !hash_buf || !hash_alg) { 72 printk(BIOS_ERR, "%s: Invalid parameters\n", __func__); 73 return -1; 74 } 75 76 reply_size = sizeof(reply); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Fwd: Issues with ACPI _CRS and E820 memory map
by Tim Wawrzynczak 25 Aug '22

25 Aug '22

Hello fellow coreboot folks, I recently received this message from some associates in the Linux kernel community which describes a bug in coreboot firmware for many Intel boards. The gist of it related to inconsistencies between the hostbridge's _CRS method in ACPI and the E820 table (although technically generated by the payload, the e820 table is generally, AFAIK, converted straight from the LB_TAG_MEMORY entry in the coreboot table by most payloads). I have some thoughts on how to address this, but I would like to hear the community's thoughts first. Thanks, -Tim ---------- Forwarded message --------- From: Bjorn Helgaas <helgaas(a)kernel.org> Date: Thu, Aug 11, 2022 at 12:30 PM Subject: Issues with ACPI _CRS and E820 memory map To: <linux-pci(a)vger.kernel.org> Cc: Hans de Goede <hdegoede(a)redhat.com>, Myron Stowe <mstowe(a)redhat.com>, Kai-Heng Feng <kai.heng.feng(a)canonical.com>, Andy Shevchenko < andriy.shevchenko(a)linux.intel.com>, <linux-acpi(a)vger.kernel.org>, < linux-kernel(a)vger.kernel.org> This is a heads-up about what I think is a firmware defect in the way some platforms build _CRS methods. We've had a Linux workaround for several years, but the workaround breaks some new machines, so the workaround will be disabled for 2023 and newer machines. Machines that depend on the workaround include: - Dell Precision T3500 - Lenovo ThinkPad X1 Gen 2 - Asus C523NA (Coral) Chromebook - Likely any machine using coreboot firmware The current versions of the machines above work fine, but 2023 versions with similar firmware are likely to break unless the firmware changes. Please forward this to any firmware folks who may be able to help with this issue. Bjorn SUMMARY A Linux change will break future platforms that rely on the E820 memory map to exclude portions of the PCI host bridge windows reported by ACPI _CRS methods. Linux discovers PCI host bridge MMIO windows by evaluating the _CRS method of the ACPI PNP0A03 device that describes the host bridge. It uses these windows to assign address space to PCI BARs. In some cases these _CRS methods are incomplete or incorrect, and it's hard for an OS to work around this. Below are examples of typical problems with _CRS methods. PLATFORMS REPORT NON-WINDOW SPACE VIA _CRS Sometimes _CRS includes host bridge register space or space assigned to hidden PCI devices that are not enumerable by the OS. When an OS assigns this space to PCI devices, it may cause conflicts or devices may not work. This appears to be a firmware defect. Many platforms report this non-window space as "reserved" in the E820 memory map, and since 2010, Linux has worked around the _CRS defect by excluding these E820 "reserved" regions from the host bridge MMIO windows [4]. Example 1: _CRS includes space that's not usable for PCI devices [1]: E820: [mem 0xdceff000-0xdfa0ffff] reserved PNP0A08 _CRS: [mem 0xdfa00000-0xfebfffff] Note that [mem 0xdfa00000-0xdfa0ffff] is included in both the E820 entry and _CRS. If Linux assigns [mem 0xdfa00000-0xdfbfffff] to a PCI device, the system doesn't resume correctly from suspend. If Linux avoids the [mem 0xdfa00000-0xdfa0ffff] area and instead assigns [mem 0xdfb00000-0xdfcfffff], resume works correctly. Example 2: _CRS includes space assigned to a "hidden" PCI device [2, 5]: PCI: 00:0d.0 10 base d0000000 limit d0ffffff mem (fixed) # BIOS log E820: [mem 0xd0000000-0xd0ffffff] PNP0A08 _CRS: [mem 0x80000000-0xe0000000] The 00:0d.0 device is assigned the [mem 0xd0000000-0xd0ffffff] space, but the device is hidden so the OS cannot enumerate it, so the OS doesn't know what space the device consumes. PLATFORMS SUPPLY E820 ENTRIES COVERING ENTIRE _CRS WINDOWS Some recent platforms supply E820 "reserved" regions that cover entire PCI host bridge windows. If Linux excludes these E820 regions from the windows, it cannot assign space to PCI BARs, which means hot-added devices don't work. Example 3: E820 has a "reserved" region that completely covers the 32-bit MMIO window from _CRS [3]: E820: [mem 0x4bc50000-0xcfffffff] reserved PNP0A08 _CRS: [mem 0x65400000-0xbfffffff] Historically, Linux has avoided putting PCI devices in E820 reserved regions to avoid the problems in examples 1 and 2. Avoiding those regions in this case means Linux can't assign space for hot-added devices, so they don't work. LINUX PLANS As far as I know, the ACPI spec does not require an OS to exclude space from _CRS resources based on the E820 memory map, and these conflicting requirements make it impractical for Linux to do so. The "avoid E820 regions" workaround worked for several years, but it no longer works because of platforms that advertise E820 regions that cover *entire* _CRS windows. We plan to make Linux stop excluding E820 regions from _CRS resources for platforms with a BIOS date of 2023 or newer, so new platforms or new BIOS releases that rely on excluding E820 regions may break [6]. Linux is likely to be broken on future versions of these platforms unless the firmware updates _CRS methods. If these platforms do not update _CRS methods to be complete and accurate, Linux may not boot. The user's options are to: - Manually boot with a kernel command line option like "pci=use_e820". - Wait for an updated kernel with a platform-specific workaround. WHY DOESN'T THIS AFFECT MICROSOFT WINDOWS? Short answer: I suspect it *does*, but it's less likely to be a problem on Windows. As far as I know, Windows does not exclude MMIO space from _CRS based on the E820 memory map. But Windows allocates PCI BARs from the top down, while Linux allocates from the bottom up. Most of the issues happen with space at the bottom of the _CRS MMIO windows, so Linux is more likely to trip over them than Windows is. REFERENCES [1] https://bugzilla.redhat.com/show_bug.cgi?id=2029207 [2] https://lore.kernel.org/linux-pci/4e9fca2f-0af1-3684-6c97-4c35befd5019@redh… [3] https://bugzilla.kernel.org/show_bug.cgi?id=206459 [4] https://bugzilla.kernel.org/show_bug.cgi?id=16228 [5] https://review.coreboot.org/plugins/gitiles/coreboot/+/dbcf7b16219d%5E%21/ [6] https://git.kernel.org/linus/0ae084d5a674

2 2

Coffee Lake Refresh RVP11 + Integrated graphics initialisation + Uefipayload
by Moorthi M.s 25 Aug '22

25 Aug '22

Hi, I am developing coreboot along with Uefipayload for CFL H RVP11 CRB. I have added the required binary files (me, desc, ec and gbe) by extracting from the BIOS image. I have also extracted and added the vbt.bin from BIOS to coreboot. For graphics initialisation, i selected "Run a GOP driver" and for Framebuffer mode, i selected "Linear high resolution framebuffer". Compiled and loaded the coreboot image with above configuration. Coreboot booted and the debug prints are displayed in UART port, but nothing came in the graphics. The Display is connected to the DP port of the CRB. And i checked the debug prints, there it is mentioned as "GMA: Found valid VBT in CBFS" and in the next line "Graphics hand-off block not found". From the above prints i assume that the vbt.bin is proper but still the FSP is not returning the graphics HOB. I am using coreboot 4.17 for my development. Is there any other configurations need to be done with respect to integrated graphics? Regards, Moorthi S

2 3

CBFS CSE version Mismatch
by Sameeruddin Shaik 23 Aug '22

23 Aug '22

hi , I built a coreboot image for ADL RVP, In that image cse lite cbfs version is not matching with the cse lite RO and RW version. As a result, target is updating the CBFS cse lite and rebooting again and again. Any Thoughts on how to fix this?. Below is the log ------------------------------ romstage starting (log level: 8)... [0m [0m[DEBUG] pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000 [0m [0m[DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [0m [0m[DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [0m [0m[DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [0m [0m[DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [0m [0m[DEBUG] TCO_STS: 0000 0000 [0m [0m[DEBUG] GEN_PMCON: a1054000 00000204 [0m [0m[DEBUG] GBLRST_CAUSE: 00000040 00000000 [0m [0m[DEBUG] HPR_CAUSE0: 00000000 [0m [0m[DEBUG] prev_sleep_state 5 [0m [0m[DEBUG] cse_lite: Number of partitions = 3 [0m [0m[DEBUG] cse_lite: Current partition = RO [0m [0m[DEBUG] cse_lite: Next partition = RO [0m [0m[DEBUG] cse_lite: Flags = 0x3 [0m [0m[DEBUG] cse_lite: RO version = 16.0.15.1752 (Status=0x0, Start=0x2000, End=0x19bfff) [0m [0m[DEBUG] cse_lite: RW version = 16.0.15.1752 (Status=0x0, Start=0x205000, End=0x439fff) [0m [0m[DEBUG] FMAP: area SI_ME found @ 81000 (5763072 bytes) [0m [0m[INFO ] SF: Detected 00 0000 with sector size 0x1000, total 0x2000000 [0m [0m[DEBUG] cse_lite: CSE RW partition: offset = 0x205000, size = 0x235000 [0m [0m[DEBUG] FMAP: area FW_MAIN_A found @ 610000 (4718528 bytes) [0m [0m[INFO ] MMAP window: SPI flash base=0x1000000, Host base=0xff000000, Size=0x1000000 [0m [0m[INFO ] MMAP window: SPI flash base=0x600000, Host base=0xf9600000, Size=0xa00000 [0m [0m[INFO ] CBFS: Found 'me_rw.version' @0xa4b80 size 0xd in mcache @0xfef877e8 [0m [0m[DEBUG] cse_lite: CSE CBFS RW version : 16.0.15.1620 [0m [0m[DEBUG] cse_lite: CSE RW update is initiated [0m [0m[DEBUG] FMAP: area ME_RW_A found @ a90000 (3604480 bytes) [0m [0m[INFO ] CBFS: Found 'me_rw' @0x0 size 0x235000 [0m [0m[INFO ] CBFS: Found 'me_rw.hash' @0xa4bc0 size 0x20 in mcache @0xfef87810 [0m [0m[SPEW ] cse_lite: Computed SHA of CSE CBFS RW Image matches the provided hash in the metadata [0m [0m[DEBUG] cse_lite: Sending DATA CLEAR HECI command [0m [0m[DEBUG] HECI: Send HMRFPO Enable Command [0m [0m[SPEW ] Erasing flash addr 286000 + 4 KiB [0m [0m[SPEW ] Erasing flash addr 287000 + 4 KiB [0m [0m[SPEW ] Erasing flash addr 288000 + 4 KiB [0m --sameer.

2 2

Issues with ACPI _CRS and E820 memory map
by Tim Wawrzynczak 22 Aug '22

22 Aug '22

Re-forwarding the prior email as an attachment per Paul M's request. -Tim

1 0

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