September 2023 - coreboot - mail.coreboot.org

[coreboot - Bug #439] (New) Lenovo X201 Turbo Boost not working
by Lukas Karg Nov. 17, 2025

Nov. 17, 2025

Issue #439 has been reported by Lukas Karg. ---------------------------------------- Bug #439: Lenovo X201 Turbo Boost not working https://ticket.coreboot.org/issues/439 * Author: Lukas Karg * Status: New * Priority: High * Target version: none * Start date: 2022-11-18 * Affected versions: master * Affected hardware: Lenovo X201 * Affected OS: Linux, 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

1 7

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski Sept. 7, 2025

Sept. 7, 2025

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

5 7

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes May 2, 2025

May 2, 2025

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 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

3 6

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel Aug. 7, 2024

Aug. 7, 2024

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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 12

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

Feb. 21, 2024

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 Nov. 26, 2023

Nov. 26, 2023

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 Nov. 17, 2023

Nov. 17, 2023

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 Nov. 17, 2023

Nov. 17, 2023

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 Nov. 17, 2023

Nov. 17, 2023

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 Nov. 17, 2023

Nov. 17, 2023

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 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

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph Sept. 24, 2023

Sept. 24, 2023

Issue #121 has been updated by Patrick Rudolph. 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. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1666 * 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

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph Sept. 24, 2023

Sept. 24, 2023

Issue #121 has been updated by Patrick Rudolph. Does limiting the max C-state in MSR MSR_PKG_CST_CONFIG_CONTROL also work around the issue? What setting is being used on vendor firmware for MSR MSR_PKG_CST_CONFIG_CONTROL? Currently the code doesn't check if the processor supports C6/C3 sleep states, it just assumes it does. According to the BWG, when bus masters, that cannot tolerate long bus master latency, are present, the BM_STS avoidance must be used for C3/C6 states. It sounds a bit like this could be the case here. The CPU is in C3/C6 and takes too long to wake in order to handle the bus master request. If enabled the acpi_idle_bm_check() would then prevent the CPU from entering a higher C-state (deeper sleep) when a bus master is active (similar to what intel_idle.max_cstate=2 does). ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1665 * 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

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

Sept. 24, 2023

Issue #121 has been updated by Anastasios Koutian. File defconfig added The issue is resolved for me after doing the following: a) Change motherboards from FRU 04W2049 (dGPU + iGPU) to FRU 04W2045 (iGPU). b) Update coreboot to 4.21 with EDK II (defconfig is attached). System has been stable for 6+ hours with no c-state limit. Previously it would freeze after 1-3 hours. Everything else is the same as my previous post. I recommend anyone still facing this issue to try the above. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1664 * 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

Jasper Lake: Commit 21e61847 (ramtop caching) causes FSP-M to fail with EFI_UNSUPPORTED
by Jonathon Hall Sept. 22, 2023

Sept. 22, 2023

2 1

2023-09-20 - coreboot Leadership meeting minutes
by coreboot org Sept. 20, 2023

Sept. 20, 2023

# 2023-09-20 - coreboot Leadership meeting minutes ## Attendees: MartinR, MarshallD, MattD, RonM, TimC, FelixH, KarthikR, JuliusW, DanielM, JonathanH, SimonG, JonM, StefanR, NicoH, MinaW ## Minutes: ### sjg - RFC: Post-build control of serial console * https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/F5NP… * outside of the thread: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/D2PI… * Enable/Disable the serial console on images with the console previously disabled/enabled. * In CrOS, both serial and non-serial are built. * Put control in the boot block. * Martin] This presents multiple issues: * Changing the bootblock will mess up cbfs verification * On AMD platforms, the bootblock is part of the AMDFW binary, not in the typical place. * CBFSTOOL would access the “coreboot control block” to enable/disable serial. CBFS attribute - use a magic number in the boot block. * [Martin] Let’s separate this into 2 issues - do we want this feature & how to enable it. * [Matt] What’s the size difference & impact to boot time. * No impact if serial is disabled at build time (since this feature of course will not be enabled) * Size of the serial drivers * Boot time is not impacted unless serial is enabled. * Stefan] We have defaults for cmos settings that can be changed (though obviously not all systems have cmos). There’s no uniformity across all platforms. Let’s make enabling/disabling options flexible so that we can use different back-ends depending on the platform. Can’t write to CMOS when the machine is up and running. * Julius] CBFS attributes are already (mostly) written up. * CBFS may not be a good option because of the code needed to read it. * [martin]This is just an argument about how to set up a new configuration mechanism. * Let’s use something that works with the current CMOS option mechanism. * Stefan] Let’s see if we can get rid of the ChromeOS GBB flags while we do this. * Julius] this is being discussed, but not really relevant here. We can already put the existing GBB flags in CBFS. * Martin] Let’s not add yet another method of configuration. * Smmstore - SJG: uses an FMAP region so available later in bootblock? * CMOS - SJG: not controlled by firmware image * can we use the options API? * one drawback?? is that it uses strings to access the values * Stefan] Can only be modified when the board is running. * Devicetree - SJG: build-time * CBI - SJG: doesn't this fetch from the EC? * Martin] Yes * Storing things in the SPI ROM. - that is this proposal. * Martin] I believe that there’s already a method for doing this that’s implemented. * CBFS flag files - SJG: available later in bootblock? * VPD - SJG: not available in bootblock? * Kconfig? - SJG: build-time * Nobody disagrees with the idea of being able to enable/disable the serial console at runtime, the thing that needs to be figured out is the method. ### [Nico] What to do about undisclosed downstream coreboot used in production? (cf. discussion of [CB:77466](https://review.coreboot.org/c/coreboot/+/77466)) * Martin] There was a misunderstanding about whether this code was used in production images or not. From the discussion last meeting, as David described it, the EINJ is strictly for debug. * What’s our official position? * [Martin] We decided this in the last meeting. EINJ is *debug* code and would never be used in a production image. It’s useful code, so the agreement was that it should be left in coreboot, but could be moved to vendorcode. * How could we push back? E.g. ask to add absence of such conflicts to the criteria for “OCP accepted” badge? * [Martin] I think pushing back should be handled on a case-by case basis. * Concerns: * It seems unfair to deny the addition of new blob support on one hand and allow direct linking to proprietary code on the other. * [Martin] Are you arguing that we should allow other blobs because of a blob that’s never going to be used in production images? * Weakening the idea of the GPL might make it harder to get code out of companies that see a business advantage in their work. * [Martin] How does this weaken the GPL? * We need better communication about what any code that is used along with sources outside of the tree are for. There needs to be a maintainer for these items. * Let’s discuss this further later. ### [MartinR] Formatting arguments: What’s the coreboot standard for wrapped lines? * Should they match the start of the previous block or just use two tabs beyond the previous indentation? Or something else? * Julius] Decide on place-by-place basis - let the developer decide. * Can we start using clang-format for everything so that we can stop arguing about formatting? * Julius] Let the author decide - new contributors should just follow the existing format. * Ron] This worked well on other platforms - Rust & Go communities - just format it and move on. * Nico] We decided on clang-format already. * Martin] We just need to finish the implementation. Clang format versions caused issues. * Jon] Not using clang-format causes confusion and keeps people from wanting to update patches. * Felixs] hook up clang-format to the CI and allow the reviewers to decide * Ron] this would keep the current situation. Make the automaton the arbiter. * Simon] Agrees with ron - let’s not argue about formatting. * Clang-format would be done a directory at a time. * Felix] Patches that are in flight will be problematic. * There’s a script to reformat patches: clang/tools/clang-format/clang-format-diff.py * Martin] I will pick up the existing patch for the clang-format config, and we can discuss the configuration settings. I’ll send out a sample to the mailing list and write up some instructions on how to use it. * We can use the clang-format from the coreboot toolchain. ### [MartinR] I’m planning on hiring someone to help with this meeting. Duties include: * Announcing the upcoming meeting on IRC, Slack & Discord. * Helping keep minutes during the meeting * Sending the minutes to the mailing list at the conclusion of the meeting. I’ve already picked a person, and hope they’ll start attending in the next few meetings. I’m paying for this out of my own pocket to avoid any issues with having the SFC pay someone, which involves contracts & whatnot. # Next meeting October 4th, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [coreboot Calendar](https://coreboot.org/calendar.html) # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 1

RFC: Post-build control of serial console
by Keith Hui Sept. 18, 2023

Sept. 18, 2023

Hi Simon, > 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. (Pardon the formatting; I copied this out of my semi-regular digest) Many boards already have this space allocated in their cmos.layout. Take for example my sandybridge board, asus/p8z77-m: # coreboot config options: console 395 4 e 4 debug_level [...] # debug_level 4 0 Emergency 4 1 Alert 4 2 Critical 4 3 Error 4 4 Warning 4 5 Notice 4 6 Info 4 7 Debug 4 8 Spew Setting this to 0 suppresses almost all outputs unless it's a "I'm going to die()" scream. For development/hacking we do want to start with debug outputs on the console. If after ample testing a build has proved itself to be stable, cmos.default (that is a separate file) in CBFS can be patched to change the default log level. This would be done through cbfstool (albeit indirectly - extract, patch, re-insert) or a hex editor. I'd propose a tool that operates on this binary cmos.layout instead. In short, in my opinion, we don't need a new construct. Regards Keith

2 1

[coreboot - Bug #505] (New) Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system.
by Dmitry Ponamorev Sept. 15, 2023

Sept. 15, 2023

Issue #505 has been reported by Dmitry Ponamorev. ---------------------------------------- Bug #505: Intel Harcuvar CRB Denverton_NS С3000. Only 15 cores of a 16 core processor is defined in the operating system. https://ticket.coreboot.org/issues/505 * Author: Dmitry Ponamorev * Status: New * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.15 * Start date: 2023-08-22 * Affected versions: 4.15 * Affected hardware: Intel Harcuvar CRB, Intel(R) Atom(TM) CPU C3958 * Affected OS: Debian 11, Ubunto 20.04 (and later) ---------------------------------------- Found a bug with the definition of not all processor cores of the Intel(R) Atom(TM) CPU C3958 processor in operating systems. The Debian or Ubuntu operating system defines only 15 cores. The problem concerns exactly the 16th core processor. For processors with fewer cores, the number of cores is determined correctly. The problem was found in coreboot version 4.14 and later. Version coreboot 4.11 did not have this problem. Most likely this is due to incorrect initialization of apic_id. (apic_id 0) An example of the initialization output of the processor cores is below: Will perform SMM setup. CPU: Intel(R) Atom(TM) CPU C3958 @ 2.00GHz. AP: slot 1 apic_id 6, MCU rev: 0x00000034 AP: slot 13 apic_id 1e, MCU rev: 0x00000034 AP: slot 6 apic_id a, MCU rev: 0x00000034 AP: slot 14 apic_id e, MCU rev: 0x00000034 AP: slot 5 apic_id 4, MCU rev: 0x00000034 AP: slot 2 apic_id 10, MCU rev: 0x00000034 AP: slot 4 apic_id 14, MCU rev: 0x00000034 AP: slot 11 apic_id 1c, MCU rev: 0x00000034 AP: slot 15 apic_id 8, MCU rev: 0x00000034 AP: slot 8 apic_id 16, MCU rev: 0x00000034 AP: slot 10 apic_id c, MCU rev: 0x00000034 AP: slot 3 apic_id 1a, MCU rev: 0x00000034 AP: slot 9 apic_id 2, MCU rev: 0x00000034 AP: slot 7 apic_id 12, MCU rev: 0x00000034 AP: slot 12 apic_id 18, MCU rev: 0x00000034 smm_place_entry_code: smbase 7ffe8400, stack_top 7fe08000 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffec000, cpu = 0 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9000, cpu = 12 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8800, cpu = 14 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9c00, cpu = 9 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8400, cpu = 15 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb800, cpu = 2 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9400, cpu = 11 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe8c00, cpu = 13 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea000, cpu = 8 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb400, cpu = 3 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeb000, cpu = 4 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea400, cpu = 7 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffe9800, cpu = 10 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffebc00, cpu = 1 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffea800, cpu = 6 smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7ffeac00, cpu = 5 Initializing CPU #0 Turbo is unavailable CPU #0 initialized Initializing CPU #8 Initializing CPU #12 Initializing CPU #14 Initializing CPU #4 Initializing CPU #9 Initializing CPU #10 Initializing CPU #1 Initializing CPU #15 Initializing CPU #7 Initializing CPU #11 Initializing CPU #3 Initializing CPU #2 Initializing CPU #13 Initializing CPU #6 CPU #7 initialized CPU #14 initialized CPU #15 initialized CPU #2 initialized CPU #6 initialized CPU #12 initialized Initializing CPU #5 CPU #3 initialized CPU #1 initialized CPU #10 initialized CPU #4 initialized CPU #11 initialized CPU #5 initialized CPU #9 initialized CPU #8 initialized CPU #13 initialized -- 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 2

First time using coreboot+edk2, I didn't get to see the beginning.
by Keith Hui Sept. 14, 2023

Sept. 14, 2023

tldr: After my latest reflash of coreboot with edk2 payload, serial log didn't start flowing right away and no on screen activity until OS on drive has begun booting. What gives? After hacking on coreboot with SeaBIOS for so long, I finally tried edk2. It wasn't the smoothest transition. My testing hard drive has a bit of special hackery done[1] in hope it will boot under both legacy and UEFI schemes. I did add SeaBIOS as secondary payload, and it couldn't boot. Then I pulled out the main drive out of my laptop which is all UEFI, and it booted fine after probably 30 seconds of nothing - the first thing I saw on screen is the Fedora spinner. Nothing from edk2 or grub on the drive. There also was a bit of delay on my connected serial console, then when info finally started flowing, it's already well into ramstage. And when I checked cbmem, it unfortunately overflowed so I lost logs of raminit, which would be most important given my patch train now under review. It would take a warm reboot before I start getting the head of the boot logs. I didn't set a boot logo. What more set up I have to do to get my edk2 and grub boot menu back? I've attached logs from minicom, cbmem, and my Kconfig, if it helps. Thanks for any insights. Keith [1] If I remember correctly, it is GPT partitioned with ESP plus a BIOS boot partition where grub can hide itself.

4 4

coreboot has switched the default git branch from "master" to "main"
by coreboot org Sept. 12, 2023

Sept. 12, 2023

Hello all. As was mentioned in the 4.21 release notes, coreboot has switched the default branch from "master" to "main". We're currently in the process of updating the documentation and scripts in the coreboot repository, but anyone running scripts of their own will need to update them to point to the main branch. To change your coreboot local tree, see what's in your git config: /work/git/coreboot ((dc75d3e6c1...))% git config -l | grep master remote.origin.push=HEAD:refs/for/master branch.master.remote=origin branch.master.merge=refs/heads/master branch.master.rebase=true You can edit your .git/config file to change these to main, or do it from the command line: git config remote.origin.push HEAD:refs/for/main git config --remove-section branch.master git config branch.main.remote origin git config branch.main.merge refs/heads/main git config branch.main.rebase true In general, this name change shouldn't create any significant impact. Basically anything you previously used "master" for, you should change to "main". Instead of using "push origin HEAD:refs/for/master" you'll now use "push origin HEAD:refs/for/main". Instead of checking out or rebasing on master, you'll now use main. All of the open coreboot patches in gerrit have been updated to be pushed to main when merged. The master branch will no longer accept pushes. We will keep the master branch in sync with the main branch for a while so that everyone has time to switch any scripts that are running over to the main branch, but this will be discontinued at some point - probably around the end of November, after the 4.22 release. If you have any questions or issues about how to do things relating to this change, please feel free to reply to this message and we'll try to help solve any issues. Martin

3 2

Patches moved to main branch lost review scores
by Compostella, Jeremy Sept. 12, 2023

Sept. 12, 2023

Hi, Most of my gerrit patches moved to the main branch over the week-end. But they lost reviews score such +2 or V+1. Typically, <https://review.coreboot.org/c/coreboot/+/77615>. If V+1 is mandatory how do I trigger the Jenkins gerrit build ? Regards, -- *Jeremy* /One Emacs to rule them all/

3 2

2023-08-23 - coreboot Leadership meeting minutes
by coreboot org Sept. 11, 2023

Sept. 11, 2023

# 2023-08-23 - coreboot Leadership # Attendees: * ChrisW, MartinR, SubrataB, WernerZ, JonathanH, PatrickG, PaulP, JeremyC, KapilP, AnilK, HannahW, JasonG, RajA, FelixH, SimonG, JayT, JuliusW, ShelleyC, Nico, DavidH, MaximilianB, PratikkumarP, JonM, VincentZ, StefanR, MarshallD, ArthurH, FelixS # Minutes: ## [Subrata] Intel AP FW team would like to present the uGOP **implementation** meant for early Sign of Life (SOL). * The support commitment about libgfxinit is not strong from Intel management hence, Intel wished to leverage existing GFX PEIM in a much smaller format to support early display init. I’m hoping to invite the Intel team to present the talk. * [Martin] I’m not sure that we want to replace an open source solution with a proprietary solution. If we can get the uGOP source code opened, that would be ideal, but I can’t imagine how difficult that would be. * Discussion was started on the mailing list _[RFC] Pre-Memory Sign-of-Life using Intel uGOP_: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/4OS4… * [sjg] Has there been discussion of libgfxinit in C? * https://code.google.com/archive/p/i915tool/source/default/source * https://review.coreboot.org/c/coreboot/+/76762 * The root cause is long memory-training times on recent Intel devices. For AMD it is around 1 second per GB, but Intel takes longer * The uGOP driver is needed to show graphics during the long DDR5 Initialization. * Why can’t the uGOP driver be in the FSPM? * An API needs to be exposed. * Intel wants to have a unified interface between coreboot & UEFI firmware, which is why they want to use the uGOP driver. * So why can’t the uGOP driver be open source? * Because of intel. Maybe in a year the situation will have changed. * This isn’t coreboot’s problem. The Meteor Lake GPU VPU Linux driver was [open sourced last year](https://patchwork.kernel.org/project/dri-devel/patch/20220728131709.1…. * Release the information, and the community can help. * The uGOP is needed for early bringup of the chip, but Google needs the uGOP driver for the length of the program, because any other possibility won’t be tested. * The uGOP driver allows comparison with libgfxinit. * But we can already compare libgfxinit with the full GOP driver. * Again, why should the coreboot community care? * The only way we can get Intel to change and actually support open source is by putting our foot down now and refusing the uGOP driver. Intel has *no* incentive to change otherwise. * coreboot does *NOT* want another blob. Intel keeps telling coreboot that it’s just not possible or that it’s going to take too long, but if they had started on a previous project, they’d be ready now. * Intel: Not able to make changes for current platform but may consider them in future. * [Patrick] Same answer as in the last 13 years. Nothing ever happens (and I don’t blame the messengers, I fully believe that they try) ## [FelixS] Broken Matrix/IRC bridge * Bridge is disconnected from IRC and will not be coming back soon. What can we do for coreboot? * Can we set up our own matrix bridge. We can do this, but need to work out the details. * GDPR may be a concern (need to limit data collection). ## [Martin]How do we want to handle renaming I2C master/slave to controller/target. The I2C Spec has changed the names, but most datasheets have not. * Should we rename everything I2C across all of coreboot so that the naming is consistent inside coreboot, but register names are different from datasheets. * Should we leave the master/slave terminology for registers so they match the datasheets, and have the mismatch inside of coreboot. * https://review.coreboot.org/c/coreboot/+/77098 * Julius and Arthur vote to leave the register names using the terminology from their datasheets. * [Nic] This seems to be in line with what is published on https://doc.coreboot.org/community/language_style.html * Consensus during meeting: Keep drivers consistent with datasheets, however the higher-level APIs can use the newer language. ## [Martin] Does anyone know if the workaround for xeon_sp/spr: Enable BROKEN_FSP_NEEDS_STACK_ABOVE_BSS is still needed? * https://review.coreboot.org/c/coreboot/+/61164/3 * Arthur can look to see. ## [Martin] A while back, we discussed trying to help people with patches to keep things from getting stale. Over the past several weeks, I’ve been trying to review things that are starting to get a little old. While this can be cumbersome with long patch trains, I think it’s very useful overall. Here are the searches I’ve been using: * [cb_review_1_week_ignore_starred](https://review.coreboot.org/q/repo:coreboo… * [cb_review_1_week](https://review.coreboot.org/q/repo:coreboot+AND+status:op… * [cb_review_2_weeks](https://review.coreboot.org/q/repo:coreboot+AND+status:o… * The 1 week search filters out a lot of patches - anything with open comments, anything that isn’t verified, anything with open comments. * The 2 week patch just filters WIP and anything over 3 months old. * I’ve been trying to keep fresh patches from getting over 7 days old. ## [Martin] Within AMD, we’ve been discussing the licensing for the APCB (AMD PSP Customization Block) blobs. We believe that they should be licensed similar to how we license the vbt.bin files - as pure configuration data. Currently we’re using the CC-PDDC license for those files, and including them in the main coreboot repository. How would people feel about doing the same with the APCB files? * APCB configuration tooling isn’t public, so the data block itself is the best that can be offered * Still, it’s only data (like SPD or VBT) * Concern if this is data that ought to be changed more often than, say, SPD? * It makes sense to keep APCB with mainboard, but user should be aware that APCB may get reconfigured at runtime, thus it will not necessarily match the blob stored in the repo. ## [FelixS] [https://felixsinger.github.io/bootguard-status/](https://felixsinger.github… * People often ask on which boards coreboot can be ported on or if their boards can be supported by coreboot. * This tracks hardware which has BootGuard enabled or disabled. * What do people think of this? Would it be reasonable to host this at a coreboot.org domain? * Yes, but let’s make it more generic to support other companies. * Maybe merge with the board-status list? * This is autogenerated, so it would be difficult. * Let’s put it on coreboot.org as it is now, but update it for other platforms. ## [Paul] Please let’s use the mailing list more. Some topics on the agenda could be discussed there first. The agenda sometimes looks like a different/alternative forum. * It’s easier to discuss things in the meeting by speaking than having to write an email. * People should look at the agenda, and add arguments here before the meeting, such as the discussion about renaming I2c. This does help shorten the meetings. ## [Paul] Experienced reviewers from coreboot companies? Who replaced Aaron, Furqan and Tim? Currently my feeling is, only 9elements does “deep” review for the general code base. * It’s hard to get the experience to do the in-depth reviews - When experienced people leave the companies, it’s hard to replace them * [David] Need to recruit more people to develop coreboot professionally. * FelixH and MartinR review everything they merge pretty thoroughly. ## [Paul] Early MRC caching: https://review.coreboot.org/c/coreboot/+/77295 * New Kconfig option or should integration with all platforms be evaluated first * (Ran out of time, we’ll discuss on the mailing list.) ## [Paul] Status amount of funds and spending thereof. * (Ran out of time, we’ll discuss on the mailing list.) ## [Kyösti] Public document, or some other approach, needed to complete review of Intel Thunderbolt: https://review.coreboot.org/c/coreboot/+/75286 * Add JeremyC to the review, and he can try to help find someone. * Bring up on the mailing list so the people at intel have more visibility. # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

9 17

[coreboot - Bug #175] Most USB3 external disk enclosures do not work with coreboot on X230
by Robert Alessi Sept. 10, 2023

Sept. 10, 2023

Issue #175 has been updated by Robert Alessi. Patrick Rudolph wrote in #note-3: > The RCBA register for USB seems fine, but we don't do that much xhci initialisation in coreboot. > From the error description I guess it's related to over-current or transmitter margins. Does this mean the situation is hopeless? As it stands, the problem seems to persist under both Linux and OpenBSD, which seems to indicate that neither kernel can complete the xhci initialitation. More information here: https://codeberg.org/libreboot/lbmk/issues/120 And here (please read the whole thread): https://marc.info/?t=151482563500001&r=1&w=2 Thank you! ---------------------------------------- Bug #175: Most USB3 external disk enclosures do not work with coreboot on X230 https://ticket.coreboot.org/issues/175#change-1656 * Author: Tobis Greer * Status: New * Priority: Normal * Start date: 2018-10-16 ---------------------------------------- I would like to report issues with USB3 external disk enclosures and coreboot on the Lenovo X230. I have several enclosures, and only one works without issues: Toshiba Stor E Alu 2.5. Every other one will cause the following messages in dmesg over USB3 (USB2 is fine): ``` [ 73.788819] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd [ 73.809949] usb 4-2: New USB device found, idVendor=0080, idProduct=a001 [ 73.809955] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 73.809958] usb 4-2: Product: External USB 3.0 [ 73.809961] usb 4-2: Manufacturer: TOSHIBA [ 73.809964] usb 4-2: SerialNumber: 201503310007F [ 73.813049] scsi host8: uas [ 73.813861] scsi 8:0:0:0: Direct-Access TO Exter nal USB 3.0 0204 PQ: 0 ANSI: 6 [ 73.814609] sd 8:0:0:0: Attached scsi generic sg4 type 0 [ 73.815157] sd 8:0:0:0: [sde] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 73.815161] sd 8:0:0:0: [sde] 4096-byte physical blocks [ 73.815326] sd 8:0:0:0: [sde] Write Protect is off [ 73.815330] sd 8:0:0:0: [sde] Mode Sense: 53 00 00 08 [ 73.815659] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 73.819382] sde: sde1 [ 73.820711] sd 8:0:0:0: [sde] Attached SCSI disk [ 105.329243] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 105.329252] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 00 80 00 01 80 00 [ 105.329334] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 105.329342] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 00 40 00 00 38 00 [ 105.345200] scsi host8: uas_eh_device_reset_handler start [ 105.345276] usb 4-2: cmd cmplt err -2 [ 105.473565] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 105.495210] scsi host8: uas_eh_device_reset_handler success [ 138.096012] sd 8:0:0:0: [sde] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN [ 138.096016] sd 8:0:0:0: [sde] tag#5 CDB: Read(10) 28 00 09 50 f5 d8 00 00 28 00 [ 138.096184] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 138.096187] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f5 28 00 00 a8 00 [ 138.116005] scsi host8: uas_eh_device_reset_handler start [ 138.116027] usb 4-2: cmd cmplt err -2 [ 138.244231] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 138.265440] scsi host8: uas_eh_device_reset_handler success [ 168.816132] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 168.816138] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f7 b8 00 00 48 00 [ 168.816174] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 168.816177] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 09 50 f7 28 00 00 80 00 [ 168.816208] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 168.816212] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 09 50 f6 68 00 00 b8 00 [ 168.832129] scsi host8: uas_eh_device_reset_handler start [ 168.832153] usb 4-2: cmd cmplt err -2 [ 168.960341] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 168.981496] scsi host8: uas_eh_device_reset_handler success [ 201.583792] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 201.583796] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 10 00 00 00 08 00 [ 201.599793] scsi host8: uas_eh_device_reset_handler start [ 201.599817] usb 4-2: cmd cmplt err -2 [ 201.728046] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 201.749283] scsi host8: uas_eh_device_reset_handler success [ 234.351266] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 234.351270] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 08 80 00 01 80 00 [ 234.351343] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 234.351345] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 08 40 00 00 38 00 [ 234.375267] scsi host8: uas_eh_device_reset_handler start [ 234.375319] usb 4-2: cmd cmplt err -2 [ 234.503509] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 234.524774] scsi host8: uas_eh_device_reset_handler success [ 267.118802] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 267.118810] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 0a 00 00 02 00 00 [ 267.138781] scsi host8: uas_eh_device_reset_handler start [ 267.138872] usb 4-2: cmd cmplt err -2 [ 267.267064] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 267.288888] scsi host8: uas_eh_device_reset_handler success [ 297.838883] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 297.838890] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 60 08 00 00 00 08 00 [ 297.854785] scsi host8: uas_eh_device_reset_handler start [ 297.854827] usb 4-2: cmd cmplt err -2 [ 297.983104] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 298.004091] scsi host8: uas_eh_device_reset_handler success ``` Note that it says it's a Toshiba enclosure but it's not the Stor E Alu 2.5, it's from an Orico 2588US3-V1-BK-PRO with a 2.5" Intel X25M SSD in it. If I use Lenovo's BIOS, then I don't have any errors at all in dmesg, and I'm able to use the disk normally. With coreboot, I can't mount the disk at all and dmesg gets these error messages continuously. ---Files-------------------------------- .config (22.5 KB) lenovo_inteltool.txt (117 KB) cb_inteltool.txt (171 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

1 0

Jenkins V-1 failure due to internal error
by Compostella, Jeremy Sept. 6, 2023

Sept. 6, 2023

Hi, It happened to me a couple of times in the past and again today. I got a V-1 on <https://review.coreboot.org/c/coreboot/+/77560> without any "good reasons" as <https://qa.coreboot.org/job/coreboot-gerrit/244243/console> error seems to be unrelated to my patch. Is there a way to restart the build and get rid of the V-1 without re-submitting a patch with a minor commit message change ? Regards, -- *Jeremy* /One Emacs to rule them all/

2 1

[RFC] x86: Add .data section support for XIP pre-RAM stages
by Compostella, Jeremy Sept. 6, 2023

Sept. 6, 2023

Dear coreboot community, I am looking for feedback on the following topic. x86 Pre-memory stages do not support the `.data' section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of .data section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage last year has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some .data symbols in the _bss region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Instead of going though these workarounds and as it was suggested on [[RFC] VGA Text mode in romstage] last year, I believe we could add support for a `.data' section. I have been working on a solution for eXecute-In-Place (XIP) pre-memory stages (`bootblock', `verstage' and `romstage') which deliver good results (cf. <https://review.coreboot.org/c/coreboot/+/77289>). In short this patch: 1. creates a new ELF segment to hold the `.data' section 2. creates a `.data' section with its Virtual Memory Address (VMA) within Cache-as-RAM (CAR) boundaries and its Load Memory Address (LMA) following the .text section (at `_etext'). cbfstools is also updated: - To process this new segment and `.data' section - To place the .data section content right after the code (cf. `parse_elf_to_xip_stage' function) At the moment, this patch makes cbfstool detects the presence of the segment automatically and assume this is a "data" segment. But we could add a new parameter to make this new behavior less automatic if you think this would be better. This patch also adds a piece of assembly code (or C-code for bootblock) to copy the `.data' section content to Cache-As-RAM at runtime. Regards, -- *Jeremy* /One Emacs to rule them all/ [[RFC] VGA Text mode in romstage] <https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2DYB…>

2 2

[PATCH v3 1/2] x86: coreboot: Update cbmem table
by Simon Glass Sept. 4, 2023

Sept. 4, 2023

This changed a few years ago to include an overflow flag. Bring in the new structure. This comes from coreboot commit: 6f5ead14b4 ("mb/google/nissa/var/joxer: Update eMMC DLL settings") Note: There are several implementations of this in coreboot. I have chosen to follow the one in src/lib/cbmem_console.c Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v3: - Drop __packed as it does nothing useful arch/x86/include/asm/coreboot_tables.h | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/coreboot_tables.h b/arch/x86/include/asm/coreboot_tables.h index 4de137fbab9d..0dfb64babb96 100644 --- a/arch/x86/include/asm/coreboot_tables.h +++ b/arch/x86/include/asm/coreboot_tables.h @@ -299,11 +299,24 @@ struct cb_vdat { #define CB_TAG_TIMESTAMPS 0x0016 #define CB_TAG_CBMEM_CONSOLE 0x0017 +#define CBMC_CURSOR_MASK ((1 << 28) - 1) +#define CBMC_OVERFLOW BIT(31) + +/* + * struct cbmem_console - In-memory console buffer for coreboot + * + * Structure describing console buffer. It is overlaid on a flat memory area, + * with body covering the extent of the memory. Once the buffer is full, + * output will wrap back around to the start of the buffer. The high bit of the + * cursor field gets set to indicate that this happened. If the underlying + * storage allows this, the buffer will persist across multiple boots and append + * to the previous log. + */ struct cbmem_console { u32 size; u32 cursor; - char body[0]; -} __packed; + u8 body[0]; +}; #define CB_TAG_MRC_CACHE 0x0018 -- 2.41.0.694.ge786442a9b-goog

2 3

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Sept. 1, 2023

Sept. 1, 2023

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 15 new defect(s) introduced to coreboot found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 15 of 15 defect(s) ** CID 1518916: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518916: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); >>> CID 1518916: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseHsuartEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); ** CID 1518915: (TAINTED_SCALAR) /src/soc/qualcomm/common/qupv3_config.c: 155 in qupv3_se_fw_load_and_init() /src/soc/qualcomm/common/qupv3_config.c: 83 in qupv3_se_fw_load_and_init() /src/soc/qualcomm/common/qupv3_config.c: 86 in qupv3_se_fw_load_and_init() ________________________________________________________________________________________________________ *** CID 1518915: (TAINTED_SCALAR) /src/soc/qualcomm/common/qupv3_config.c: 155 in qupv3_se_fw_load_and_init() 149 (hdr->fw_version & 0xFF << 150 FW_REV_VERSION_SHFT); 151 write32(&regs->se_s_fw_revision, reg_value); 152 153 assert(hdr->fw_size_in_items <= SIZE_GENI_FW_RAM); 154 >>> CID 1518915: (TAINTED_SCALAR) >>> Passing tainted expression "hdr->fw_size_in_items * 4UL" to "memcpy", which uses it as an offset. [Note: The source code implementation of the function has been overridden by a builtin model.] 155 memcpy((&regs->se_geni_cfg_ramn), fw_val_arr, 156 hdr->fw_size_in_items * sizeof(uint32_t)); 157 158 /* HPG section 3.1.7.12 */ 159 write32(&regs->geni_force_default_reg, 0x1); 160 setbits_le32(&regs->geni_cgc_ctrl, GENI_CGC_CTRL_PROG_RAM_SCLK_OFF_BMSK /src/soc/qualcomm/common/qupv3_config.c: 83 in qupv3_se_fw_load_and_init() 77 write32(&regs->geni_cgc_ctrl, DEFAULT_CGC_EN); 78 79 /* HPG section 3.1.7.4 */ 80 write32(&regs->geni_init_cfg_revision, hdr->cfg_version); 81 write32(&regs->geni_s_init_cfg_revision, hdr->cfg_version); 82 >>> CID 1518915: (TAINTED_SCALAR) >>> Using tainted variable "hdr->cfg_size_in_items - 1" as an index to pointer "cfg_idx_arr". 83 assert(cfg_idx_arr[hdr->cfg_size_in_items - 1] * sizeof(uint32_t) <= 84 MAX_OFFSET_CFG_REG); 85 86 for (i = 0; i < hdr->cfg_size_in_items; i++) 87 write32(&regs->geni_cfg_reg0 + cfg_idx_arr[i], 88 cfg_val_arr[i]); /src/soc/qualcomm/common/qupv3_config.c: 86 in qupv3_se_fw_load_and_init() 80 write32(&regs->geni_init_cfg_revision, hdr->cfg_version); 81 write32(&regs->geni_s_init_cfg_revision, hdr->cfg_version); 82 83 assert(cfg_idx_arr[hdr->cfg_size_in_items - 1] * sizeof(uint32_t) <= 84 MAX_OFFSET_CFG_REG); 85 >>> CID 1518915: (TAINTED_SCALAR) >>> Using tainted variable "hdr->cfg_size_in_items" as a loop boundary. 86 for (i = 0; i < hdr->cfg_size_in_items; i++) 87 write32(&regs->geni_cfg_reg0 + cfg_idx_arr[i], 88 cfg_val_arr[i]); 89 90 /* HPG section 3.1.7.9 */ 91 /* non-UART configuration, UART driver can configure as desired for UART ** CID 1518914: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518914: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() 154 pse_fw_base = (uintptr_t)&psefwbuf; 155 params->SiipRegionBase = pse_fw_base; 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ >>> CID 1518914: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseDmaEnable" of 3 bytes by passing it to a function which accesses it at byte offset 11 using argument "12UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); ** CID 1518913: (TAINTED_SCALAR) /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() ________________________________________________________________________________________________________ *** CID 1518913: (TAINTED_SCALAR) /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } ** CID 1518912: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518912: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); >>> CID 1518912: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseQepEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); ** CID 1518911: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518911: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); >>> CID 1518911: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseCanEnable" of 2 bytes by passing it to a function which accesses it at byte offset 7 using argument "8UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); 180 params->PchPseAdcEnable = config->PseAdcOwn; ** CID 1518910: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518910: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); >>> CID 1518910: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiCs1Enable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); ** CID 1518909: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518909: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); >>> CID 1518909: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseI2sEnable" of 2 bytes by passing it to a function which accesses it at byte offset 7 using argument "8UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); ** CID 1518908: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518908: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); >>> CID 1518908: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseI2cEnable" of 8 bytes by passing it to a function which accesses it at byte offset 31 using argument "32UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); ** CID 1518907: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1518907: Null pointer dereferences (FORWARD_NULL) /src/acpi/acpi.c: 1499 in write_acpi_tables() 1493 current = acpi_align_current(current); 1494 1495 /* clear all table memory */ 1496 memset((void *)start, 0, current - start); 1497 1498 acpi_write_rsdp(rsdp, rsdt, xsdt, oem_id); >>> CID 1518907: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "rsdt" to "acpi_write_rsdt", which dereferences it. 1499 acpi_write_rsdt(rsdt, oem_id, oem_table_id); 1500 acpi_write_xsdt(xsdt, oem_id, oem_table_id); 1501 1502 if (ENV_X86) { 1503 printk(BIOS_DEBUG, "ACPI: * FACS\n"); 1504 current = ALIGN_UP(current, 64); ** CID 1518906: (BUFFER_SIZE) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518906: (BUFFER_SIZE) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseHsuartEnable" by writing the maximum 16 bytes from "config->PseHsuartOwn". 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() 154 pse_fw_base = (uintptr_t)&psefwbuf; 155 params->SiipRegionBase = pse_fw_base; 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 3 byte destination string "params->PchPseDmaEnable" by writing the maximum 12 bytes from "config->PseDmaOwn". 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 8 byte destination string "params->PchPseI2cEnable" by writing the maximum 32 bytes from "config->PseI2cOwn". 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiEnable" by writing the maximum 16 bytes from "config->PseSpiOwn". 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiCs0Enable" by writing the maximum 16 bytes from "config->PseSpiCs0Own". 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 2 byte destination string "params->PchPseI2sEnable" by writing the maximum 8 bytes from "config->PseI2sOwn". 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseQepEnable" by writing the maximum 16 bytes from "config->PseQepOwn". 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 2 byte destination string "params->PchPseCanEnable" by writing the maximum 8 bytes from "config->PseCanOwn". 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); 180 params->PchPseAdcEnable = config->PseAdcOwn; /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiCs1Enable" by writing the maximum 16 bytes from "config->PseSpiCs1Own". 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 6 byte destination string "params->PchPseUartEnable" by writing the maximum 24 bytes from "config->PseUartOwn". 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); ** CID 1518905: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518905: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); >>> CID 1518905: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); ** CID 1518904: Integer handling issues (BAD_SHIFT) /src/security/intel/txt/common.c: 277 in intel_txt_prepare_bios_acm() ________________________________________________________________________________________________________ *** CID 1518904: Integer handling issues (BAD_SHIFT) /src/security/intel/txt/common.c: 277 in intel_txt_prepare_bios_acm() 271 } 272 273 /* 274 * The ACM should be aligned to it's size, but that's not possible, as 275 * some ACMs are not power of two. Use the next power of two for verification. 276 */ >>> CID 1518904: Integer handling issues (BAD_SHIFT) >>> In expression "1UL << log2_ceil(*acm_len)", shifting by a negative amount has undefined behavior. The shift amount, "log2_ceil(*acm_len)", is -1. 277 if (!IS_ALIGNED((uintptr_t)acm_data, (1UL << log2_ceil(*acm_len)))) { 278 printk(BIOS_ERR, "TEE-TXT: BIOS ACM isn't aligned to its size.\n"); 279 cbfs_unmap(acm_data); 280 return NULL; 281 } 282 ** CID 1518903: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518903: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); >>> CID 1518903: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseUartEnable" of 6 bytes by passing it to a function which accesses it at byte offset 23 using argument "24UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); ** CID 1518902: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518902: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); >>> CID 1518902: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiCs0Enable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0