coreboot September 2023

coreboot@coreboot.org

26 participants
33 discussions

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski 24 Apr '24

24 Apr '24

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 6

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 21 Feb '24

21 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

Restoring the opensource AGESA boards takes just 1% of git reverts since their removal
by Mike Banon 26 Nov '23

26 Nov '23

Dear friends, please take a look at this change: https://review.coreboot.org/c/coreboot/+/76832 This script reverts the opensource AGESA AMD boards removal that happened after 5e8e911b7caee021faff96c4e82a77a42544ea62 (0 point of history, or 0 PoH) - by git-reverting: 1) the "bad commits" (marked as "CBF" = coreboot build failure) - that either remove or break a code needed for our boards 2) the "unlucky commits" (marked as "GRF" = git revert failure) - that are a roadblock for git-reverting the "bad commits" Right now at 3bd83b27afbc840f184b652a1dd8ed539623a258 (3765 PoH), it takes 38 CBF git reverts - just 1% of 3765 commits since the OSS AGESA removal! - - making this removal look questionable and the idea of restoration viable. Btw plenty of these git reverts could be avoided if the changes to the "dropped code" are allowed: i.e. instead of git reverting the four patches numbered 497-500 at the script above, one could simply add a single " #define SPEEDSTEP_APIC_MAGIC 0xACAC " somewhere. Therefore the real number of "bad commits" (which either remove our boards or break the things for us) isn't that great and the opensource AGESA boards really can be brought back to coreboot with a bunch of ifdef's etc. Please let me know if you're interested in such a quest... SUCCESSFUL TESTS for the opensource AGESA boards which I own (Lenovo G505S - - fam15 laptop, ASUS A88XM-E - fam15 desktop, ASUS AM1I-A - fam16 desktop) : 1) only build: 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for AM1I-A, most likely boot works too but I didn't have the time to test 2) build & boot: 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for G505S and A88XM-E 11ba8ebbcc662ebd1dc8e14372a020eb32f26561 (3741 PoH) for G505S test only -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 3

[coreboot - Bug #475] (New) mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended
by Bill XIE 17 Nov '23

17 Nov '23

Issue #475 has been reported by Bill XIE. ---------------------------------------- Bug #475: mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended https://ticket.coreboot.org/issues/475 * Author: Bill XIE * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2023-03-30 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: x200 ---------------------------------------- Date back to coreboot 4.9, mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c calls get_blc_pwm_freq_value(NULL), making the following if condition always falling to the first, not to mention null dereference on strcmp() in get_blc_pwm_freq_value(). In order to determine the correct vbt filename at runtime, edid ascii string should be obtained first. This issue may be distantly related to #474. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 4

[coreboot - Support #485] (New) Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake)
by Rajat Dongre 17 Nov '23

17 Nov '23

Issue #485 has been reported by Rajat Dongre. ---------------------------------------- Support #485: Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake) https://ticket.coreboot.org/issues/485 * Author: Rajat Dongre * Status: New * Priority: Immediate * Assignee: Rajat Dongre * Target version: none * Start date: 2023-04-27 ---------------------------------------- Hi, I am writing this email to request support for the Intel Xeon 1700 D processor family (Ice Lake) in Coreboot. As you may be aware, the support for the IceLake SOC has been removed, and I am using a processor from the same family. I would appreciate any help or guidance on how to bring up my processor using Coreboot. I have been using Coreboot for some time and am familiar with its functionalities, but I am facing difficulties with the processor mentioned above. and Can I used to older version of coreboot where you give support for the Ice lake but the Intel Xeon 1700 D processor family launch in Dec 2022. so I have doubt I will work for this SOC as the Icelake is not updated from last 4 years in coreboot. I would be grateful if you could provide any relevant documentation, code, or instructions to help me with my request. I believe that my request will not only benefit me but also other members of the community who are facing similar challenges. Thank you for your time and consideration, and I look forward to hearing from you soon. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

5 6

[coreboot - Other #479] (New) [legal] ISC License copyright violation in ubsan
by Jonas Termansen 17 Nov '23

17 Nov '23

Issue #479 has been reported by Jonas Termansen. ---------------------------------------- Other #479: [legal] ISC License copyright violation in ubsan https://ticket.coreboot.org/issues/479 * Author: Jonas Termansen * Status: New * Priority: Normal * Target version: none * Start date: 2023-04-09 ---------------------------------------- Hi :) coreboot has removed my copyright statement from the ubsan implementation, which violates my copyright as licensed to you under the terms of the ISC License: ``` * Copyright (c) 2014, 2015 Jonas 'Sortie' Termansen. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * ... ``` The file in question is: https://github.com/coreboot/coreboot/blob/master/src/lib/ubsan.c The file does clearly state it's forked from my original ubsan implementation: https://gitlab.com/sortix/sortix/-/blob/master/libc/ubsan/ubsan.c However, the coreboot copy has removed my copyright notice, which is one of only two terms of the license. It's fine that the permission notice has been changed to `SPDX-License-Identifier: ISC` which is unambiguously information preserving, but removing my copyright notice is a loss of information. The copyright notice was removed in https://github.com/coreboot/coreboot/commit/16849bbe0c8a79277e1a682dcb42eaf… which moved my name to AUTHORS. Although a mention in AUTHORS is appreciated, it removes the association between the file's contents and my identity and my moral rights to my work. Although the full information is available in the git history, that's not good enough. I'm concerned that further copies of the file in other projects may lose the authorship information entirely. Please restore my copyright notice at the top of the file :) Jonas 'Sortie' Termansen -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 4

[coreboot - Bug #500] (New) libgfxinit bootsplash only supports jpeg and does not support extended resolutions
by Thierry Laurion 17 Nov '23

17 Nov '23

Issue #500 has been reported by Thierry Laurion. ---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500 * Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad… WiP PoC: https://github.com/osresearch/heads/pull/1403 * Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAt… Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad…) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-…) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS. - support for all crazy resolutions we currently have, not being stuck in 2000. - Be able to promote coreboot from raminit code. ---Files-------------------------------- signal-2023-07-13-164022.jpeg (269 KB) signal-2023-07-13-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

4 10

Replacing BIOS
by R B 31 Oct '23

31 Oct '23

Dear Sir / Madam, I bought a mini PC with an N100 CPU and AMI BIOS on Aliexpress. Is it possible to replace the AMI BIOS with coreboot? Yours sincerely, Rachid. P.S. I read on the internet that Chinese equipment may be spying via devices/electronics. Is that true? And will changing BIOS help against this?

3 4

Re: RFC: Post-build control of serial console
by Martin Roth 18 Oct '23

18 Oct '23

Hi Simon, Sep 29, 2023, 13:04 by sjg(a)chromium.org: > Hi Martin, > > On Mon, 25 Sept 2023 at 13:51, Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hey Simon, I think this is a good summary of the current situation, though the table doesn't come through in the text version of the email at all. Maybe upload an RFC to the documentation directory so it can be commented on in gerrit? >> > > Can you see this? > > https://docs.google.com/document/d/17vLMUFYuUVZnJkHdG2My4iyX_FJW185HosHSIwR… > Yes, thanks. > > I did upload a PoC but I think I was ahead of the game as it needed an > RFC first. > >> As I mentioned in the leadership meeting, I have concerns about a solution that relies solely on embedding this in bootblock. Some of these issues are specific to AMD, but if we're doing this, it should be a solution that we can use across different platforms and architectures. >> >> Issues I see with embedding it the option mechanism in bootblock:1) Bootblock can be signed for verification by cbfs. Modifying the bootblock will cause the CBFS verification to fail. >> 2) The AMD bootblock is part of the overall AMDFW binary, and not at the top of the ROM as it used to be. This makes locating it and modifying it more difficult - it's not a separate CBFS area as you specified. >> 3) For AMD, the bootblock can be compressed, which makes it difficult (or impossible) to update this table.4) AMD has 3 copies of the bootblock. Which one gets updated? If all need to be updated, that's very inconvenient and creates issues keeping them in sync. >> 5) Assuming that you want this to be available to the 1st stage that's run, on AMD, that doesn't have to be bootblock, that can be PSP_verstage instead. >> 6) What happens when there's only one bootblock and it's in RO, so the options can't be updated? Maybe that's not an issue for ChromeOS because the table would only be used for debug, but if we're adding something new, let's design it so that it's useful for everyone. >> >> >> I think it would be better to have a single table at a known fixed location in the firmware boot media so that it can be accessed before CBFS is enabled. This can be a separate partition in FMAP and parsed out by Make at build-time, or set as a Kconfig option and put anywhere in flash that is convenient to the architecture or platform (while still being writable). As Arthur said, it's inconvenient when the firmware boot media isn't memory mapped, so we probably need to design this with both options in mind. >> >> I'm fine with an option that lets us choose between embedding something in the bootblock and placing the table somewhere else, so long as we use the same format in either place and only have a single copy in any given coreboot.rom image. >> > > OK, got it. > >> >> Also, I'd really like to see this use an existing configuration mechanism instead of adding yet another configuration API. Here are 3 options I see: >> >> CMOS_BUT_IN_FLASH >> One option is to use the same interface inside coreboot that we currently use for CMOS. We should be able to just read the options from the boot media (or memory after copying it from flash) instead of CMOS, but use the rest of the parsing mechanisms as they already exist. CCB would just be added as another OPTION_BACKEND in Kconfig. I do like the way we have a method of adding default values for CMOS, so I'd prefer to see the exact same mechanism that we use in CMOS, but stored in flash instead. This would work well as an option for either putting into the bootblock or somewhere else in flash. >> > > It looks like only one backend can be active, but for x86 boards we > would want CMOS RAM (for normal settings) as well as SPI flash for > CCB). Also the options are accessed using strings which is less > efficient than an enum. > I'm not sure why we'd need to use multiple backends, or why we need CMOS for "normal" settings. Is there a reason we couldn't use the SPI flash for all of the settings instead of CMOS? I guess if you want to store the information just in the bootblock, that could be problematic, or we'd have to come up with a way to keep that data around for other stages. >> SMMSTORE_VIA_ANOTHER_MECHANISM >> If that's not practical, we could use the same partition and format used by SMMstore, and create non-SMM routines to be cross-platform and allow it to be used earlier. It looks like SMMstore can already be used as another OPTION_BACKEND. I haven't looked into SMMstore, so I don't know if this is practical, but this still seems better than creating something completely new. Obviously, this doesn't work well to embed into the bootblock. >> > > That looks like a ramstage thing that does some sort of system call to > access the data. See for example smmstore_exec(). I am not sure how I > could use that here. > I was really suggesting that we implement a new routine to access the SMMSTORE data directly from flash early in the boot process. Just from the name, I assumed that it wasn't available to pre-memory stages. >> >> CBI_IN_FLASH >> Even extending CBI to read data from the firmware boot media instead of (or in addition to) the EC would be better than creating an entirely new interface. There's a CBI interface to read the bits directly, but CBI also hooks into devicetree allowing devices to be enabled or disabled at runtime. CBI is currently limited to 64 bits, but that could be extended. This also works well for either embedding into bootblock or placing somewhere else in flash. >> > > That looks more plausible, since it allows reading from multiple > places in fw_config_get(). As you say it is only a 64-bit word. Plus > it doesn't seem to be standardised across boards. Each one defines its > own bits! > > Having said that, it looks like the top bit is free in all cases, so I > could perhaps add a 'global' config which is used by all boards? > > Alternatively, I could rename perhaps fw_config_get() to > fw_config_get_base() and add an enum parameter to fw_config_get(). > But I would need to plumb this into coreboot's 'devicetree'. That > doesn't seem to allow for configs which are common to all boards. > > What do you think? > Well, There's a reason that CBI was my 3rd option. If we're implementing something new, it would be really nice to implement something that can store an "arbitrarily large" amount of data in various different formats. CBI is perfect for flags and options that can be stored in a few bits, but it wasn't designed to handle strings or really even byte values. We might be able to overcome that, but since the offsets are currently bit-based, it'd take some rearchitecting or it could get ugly quickly. Maybe we could just update the fields from bit#s to dword:bit pairs. I think current implementations all only use the first dword, so that shouldn't be too difficult. If we do go with CBI, I think having a global list of names that could be used for CBI settings to enable/disable common code blocks makes sense. If you want a setting to affect something like enabling/disabling serial console, you would use a specific CBI name for it. If a platform doesn't have that name in CBI, it just gets ignored, and no option is used. One of the things that I like about the CMOS option mechanism is that it allows for a clean fallback path if an option is not defined for a board or if the options feature is disabled. Whatever setting options method we use, I'd like to continue that architecture. Allowing a clean fallback if a name isn't in CBI kind of implies that as well. Since CBI was a Google implementation and there's a Google internal spec, if we go that route, I think we'd want that spec to be public. Actually, since it's implemented in coreboot, and a part of devicetree, I think it probably should be public anyway. And maybe renamed from "CrOS board information" to "coreboot board information". We could then extend the CBI spec to be able to handle more than just the EC. We'd need to define a way to identify, read from and update different storage mediums based on the dword. It would definitely be nice to have something that can actually handle multiple storage mediums at the same time. I could definitely see a lot of use to having something so that different options are read from various size areas in EC, flash, CMOS, a data segment in the code, hardcoded build-time values, or any other future mechanism, all at the same time. Take careMartin

3 3

[coreboot - Bug #508] (New) Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled
by Yu-Ping Wu 18 Oct '23

18 Oct '23

Issue #508 has been reported by Yu-Ping Wu. ---------------------------------------- Bug #508: Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled https://ticket.coreboot.org/issues/508 * Author: Yu-Ping Wu * Status: New * Priority: Normal * Assignee: Nico Huber * Target version: none * Start date: 2023-08-31 * Affected versions: 4.21 ---------------------------------------- Similar to #499, after https://review.coreboot.org/c/coreboot/+/75012, Dojo fails to boot. Disabling CONFIG_RESOURCE_ALLOCATION_TOP_DOWN fixes the problem. However I'm not sure how to fix it from MediaTek's PCIe functions or settings (for example mtk_pcie_domain_read_resources). ---Files-------------------------------- ap-bad.log (32.8 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2023