September 2023 - coreboot - mail.coreboot.org

Replacing BIOS
by R B Oct. 30, 2023

Oct. 30, 2023

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 Oct. 18, 2023

Oct. 18, 2023

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 Oct. 18, 2023

Oct. 18, 2023

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

How to get reviews on gerrit? aka. patches ignored for three years.
by Daniel Gröber Oct. 5, 2023

Oct. 5, 2023

Hi, could someone tell me how I'm supposed to deal with unresponsive reviewers on gerrit? Clearly I must be doing something wrong as the patches have been gathering dust for around three years now. https://review.coreboot.org/q/topic:%22macronix-spi-bp%22 --Daniel

6 11

Qemu with persistent CMOS RAM (save / restore)
by Simon Glass Sept. 30, 2023

Sept. 30, 2023

Hi, Is it possible to save and restore CMOS RAM with qemu, or some other emulator? I'd like it to be kept in a file on my system, so I can run coreboot multiple times and the CMOS RAM is preserved across runs. For example, if I make a change to a CMOS location, then I'd like that change to still be visible on the next run. Regards, Simon

1 0

RFC: Post-build control of serial console
by Simon Glass Sept. 29, 2023

Sept. 29, 2023

Hi, RFC: Post-build control of serial console It is annoying to have to create and maintain two completely different builds of coreboot just to enable or disable the console. It would be much more convenient to have a 'silent' flag in the image, which can be updated as needed, without needing to rebuild coreboot. For example, if something goes wrong and coreboot hangs, it would be nice to be able to enable serial on the same image, then boot it again to see how far it gets. I propose a 'Coreboot Control Block' (CCB) which can hold a small number of such settings. It is designed to be available very early in bootblock, before CBFS is ready. It is able to control the output of the very first bootblock banner. early silicon-init, etc. It is built as part of the bootblock image, so can be accessed simply as a static C struct within the bootblock code. That means that the code overhead is very low and we could perhaps enable it by default. The bootblock can have a CBFS file attribute that indicates that it contains a CCB and the offset where it is stored. Other coreboot stages can read this as well, or it could be duplicated in a separate file. We can provide options in cbfstool to get and set settings in the CCB. This makes it easy to use this feature, e.g. to enable silent: cbfstool coreboot.rom ccb-set -n serial -V silent Why not use a separate CBFS file? - Boards typically read the entire bootblock and start execution from it. The console is started early so the settings are needed before CBFS is available. By putting the CCB inside the bootblock, it can control things from an early stage. Why not CMOS RAM / VVRAM? - If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM. Why not use Firmware Handoff to pass the CCB to following stages? - We could do that, particularly if CCB attracts some additional features, such as logging. Regards, Simon

3 5

google/brya/var/crota: selfboot jump reached after 1.2 s
by Paul Menzel Sept. 28, 2023

Sept. 28, 2023

Dear Google Chromebook folks, I got a Dell Latitude 5340 Chromebook with coreboot-v1.9308_26_0.0.22-26491-g38c6637296 With hot MRC cache, ChromeOS login screen is reached after around six seconds, which is great. According to the firmware time stamps in `chrome://system`, coreboot takes 1.2 until starting depthcharge: 82 entries total: 990:CSME ROM started execution 0 944:CSE sent 'Boot Stall Done' to PMC 119,000 945:CSE started to handle ICC configuration 119,000 (0) 946:CSE sent 'Host BIOS Prep Done' to PMC 123,000 (4,000) 947:CSE received 'CPU Reset Done Ack sent' from PMC 307,000 (184,000) 0:1st timestamp 342,717 (35,717) So the Converged Security Engine alone takes 342 ms – as long as coreboot takes to execute on older systems. 11:start of bootblock 352,538 (9,821) 12:end of bootblock 358,690 (6,151) 501:starting to load verstage 358,693 (3) 502:finished loading verstage 359,785 (1,092) 5:start of verified boot 361,037 (1,252) 503:starting to initialize TPM 361,739 (701) 504:finished TPM initialization 450,095 (88,356) 88 ms is high, but I think common for TPM initialization. 505:starting to verify keyblock/preamble (RSA) 471,441 (21,345) 506:finished verifying keyblock/preamble (RSA) 476,234 (4,793) 507:starting to verify body (load+SHA2+RSA) 476,256 (22) 508:finished loading body 679,079 (202,822) Another 200 ms is spent here. 509:finished calculating body hash (SHA2) 686,553 (7,473) 510:finished verifying body signature (RSA) 688,054 (1,501) 511:starting TPM PCR extend 690,511 (2,456) 512:finished TPM PCR extend 719,107 (28,596) 513:starting locking TPM 719,107 (0) 514:finished locking TPM 733,290 (14,183) 6:end of verified boot 747,454 (14,163) 13:starting to load romstage 747,563 (108) 14:finished loading romstage 747,575 (12) 1:start of romstage 747,587 (12) 515:starting EC software sync 747,596 (8) 516:EC vboot hash ready 749,955 (2,359) 517:waiting for EC to allow higher power draw 753,883 (3,928) 518:finished EC software sync 755,385 (1,501) 948:starting CSE firmware sync 756,428 (1,043) 949:finished CSE firmware sync 759,141 (2,712) 970:loading FSP-M 760,597 (1,456) 2:before RAM initialization 760,603 (5) 950:calling FspMemoryInit 785,801 (25,198) 951:returning from FspMemoryInit 825,967 (40,165) 550:starting to load ChromeOS VPD 826,013 (45) 551:finished loading ChromeOS VPD (RO) 826,099 (86) 552:finished loading ChromeOS VPD (RW) 826,132 (32) 3:after RAM initialization 826,196 (64) 4:end of romstage 827,576 (1,379) 100:start of postcar 836,651 (9,074) 101:end of postcar 836,651 (0) 8:starting to load ramstage 836,655 (3) 15:starting LZMA decompress (ignore for x86) 836,701 (46) 16:finished LZMA decompress (ignore for x86) 866,740 (30,039) 9:finished loading ramstage 866,880 (139) 10:start of ramstage 866,929 (48) 17:starting LZ4 decompress (ignore for x86) 867,936 (1,006) 18:finished LZ4 decompress (ignore for x86) 907,401 (39,465) 30:device enumeration 913,217 (5,816) 971:loading FSP-S 923,807 (10,589) 954:calling FspSiliconInit 934,237 (10,430) 955:returning from FspSiliconInit 968,817 (34,579) 962:calling FspMultiPhaseSiInit 968,822 (5) 963:returning from FspMultiPhaseSiInit 1,146,574 (177,751) 177 ms are spent here in the FSP blob? 942:before sending EOP to ME 1,146,823 (248) 40:device configuration 1,149,840 (3,016) 50:device enable 1,162,440 (12,600) 60:device initialization 1,167,018 (4,578) 114:started elog init 1,168,482 (1,464) 115:finished elog init 1,170,862 (2,379) 15:starting LZMA decompress (ignore for x86) 1,174,928 (4,065) 16:finished LZMA decompress (ignore for x86) 1,175,208 (280) 70:device setup done 1,186,831 (11,622) 75:cbmem post 1,187,518 (686) 80:write tables 1,187,593 (75) 85:finalize chips 1,195,483 (7,889) 553:started TPM enable update 1,204,169 (8,685) 554:finished TPM enable update 1,223,291 (19,122) 90:starting to load payload 1,223,317 (26) 15:starting LZMA decompress (ignore for x86) 1,223,459 (141) 16:finished LZMA decompress (ignore for x86) 1,236,494 (13,035) 943:after sending EOP to ME 1,240,485 (3,990) 99:selfboot jump 1,240,607 (122) 1000:depthcharge start 1,248,752 (8,144) 1002:RO vboot init 1,249,204 (452) 1020:vboot select&load kernel 1,249,228 (23) 1040:finished storage device initialization 1,282,580 (33,352) 1050:finished reading kernel from disk 1,288,042 (5,461) 1100:finished vboot kernel verification 1,295,930 (7,887) 1101:jumping to kernel 1,314,111 (18,180) Total Time: 1,314,072 I thought ChromeOS requirement is to reach `selfboot jump` below (still quite high) one second. Or is the actually met by not counting from power-on but from 1st timestamp? Does somebody know, why the CSE takes so long? Is Intel aware of that and going to improve that? I think there was something similar in the past, where Duncan Laurie(?), experienced, that coreboot was faster than the ME initialization, and had to wait for the Intel ME to send the ready signal. I think Intel improved on that later on? Kind regards, Paul

2 1

CML v1 / v2 FSP
by Jonathon Hall Sept. 27, 2023

Sept. 27, 2023

Hi all, As many of you probably know, Comet Lake v1/v2 have different FSP binaries, and hence separate Kconfigs `SOC_INTEL_COMETLAKE_1` and `..._2`. In short, the same SKU could be either depending on the stepping. We're getting new steppings in future batches of products, which will move them from CML v1 to CML v2. These aren't otherwise "new versions" of the product. It would simplify life for my customers if they had the same firmware image. From an initial look it seems reasonable to embed both FSPs and select at runtime using the CPUID as suggested by Intel: * The headers for both FSPs are equivalent (differ only in comments), so there should be no issue switching at runtime * The _1 / _2 Kconfigs are only used to select FSP headers/binary, nothing else * It'll cost some flash space, so separate _1 / _2 should continue to exist, but in my case that tradeoff is fine Has anyone looked into this in the past? Is there any other reason this is not a good idea? From my initial look, I would try: * Add another Comet Lake Kconfig, say `SOC_INTEL_COMETLAKE_1_2` (or `..._1_AND_2`, etc.) * Embed a second FSP - probably add an optional `FSP_FD_PATH_2` to the FSP 2.0 Kconfig, the `..._1_2` SoC Kconfig would then put its second FSP here * Add a second `FSP_M_CBFS`/`FSP_S_CBFS` (the names of the files in cbfs) * For `SOC_INTEL_COMETLAKE_1_2`, select the correct cbfs name based on CPUID. Those are only used in a few places, so the impact wouldn't be very large. Thanks, Jonathon

2 2

[coreboot - Bug #509] (New) SD Card hotplug not working on Apollo Lake
by CoolStar Organization Sept. 27, 2023

Sept. 27, 2023

Issue #509 has been reported by CoolStar Organization. ---------------------------------------- Bug #509: SD Card hotplug not working on Apollo Lake https://ticket.coreboot.org/issues/509 * Author: CoolStar Organization * Status: New * Priority: Normal * Category: chipset configuration * Target version: master * Start date: 2023-09-27 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Needs backport to: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: Apollo Lake * Affected OS: Linux, Windows 10, Windows 11 ---------------------------------------- Something is broken with the SD Card enumeration on Apollo Lake where hotplug is broken in both Linux and Windows -- 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 1

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian Sept. 26, 2023

Sept. 26, 2023

Issue #121 has been updated by Anastasios Koutian. Patrick Rudolph wrote in #note-75: > I compared the vendor ACPI code for T520 and T530: > - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. > - The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63 in coreboot. > It's possible that too short advertised exit latencies causes issues when meeting deadlines within the kernel. > The kernel will pick deeper C-states, while it shouldn't, as it assumes that those wake much faster. Hi Patrick, I have done some digging with MSRs but never looked into this particular one. I have a spare T420 motherboard now and I could flash the vendor firmware back in, to examine the value. If that would contribute to solving this issue, I'd be happy to do it. Thank you for looking into this. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1667 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg) whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- 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

1 0