December 2023 - coreboot - mail.coreboot.org

[coreboot - Bug #448] (New) Thinkpad T440P ACPI Battery Value Issues
by Karsten Schnier May 5, 2026

May 5, 2026

Issue #448 has been reported by Karsten Schnier. ---------------------------------------- Bug #448: Thinkpad T440P ACPI Battery Value Issues https://ticket.coreboot.org/issues/448 * Author: Karsten Schnier * Status: New * Priority: Normal * Target version: none * Start date: 2023-01-11 * Affected versions: master * Related links: [[https://github.com/linrunner/TLP/issues/657]] * Affected hardware: Thinkpad T440p * Affected OS: Artix / Arch Linux ---------------------------------------- Hello, I have been having some issues with TLP on my corebooted T440p. I am running artix linux with grub on top of coreboot (self compiled libreboot). I have had issues with the ACPI battery readings. Coreboot does not provide power readings, but instead only current readings. More details can be found in the TLP github issue: [[https://github.com/linrunner/TLP/issues/657#issuecomment-1293730559]] This causes TLP to not recognize the thinkpad and go to default mode. Additional, it prevents recalibration of the battery even when the thinkpad battery driver is forced. Is this due to misconfiguration in the coreboot build or issues with coreboot itself? Thank you! -- 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 #449] (New) ThinkPad T440p fail to start, continous beeping & LED blinking
by Crazy Fox Feb. 21, 2026

Feb. 21, 2026

Issue #449 has been reported by Crazy Fox. ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449 * Author: Crazy Fox * Status: New * Priority: Normal * Category: coreboot common code * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.18 * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 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

4 5

[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. 20, 2024

Feb. 20, 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

[coreboot - Bug #522] (New) `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
by Vadim Zaliva Feb. 10, 2024

Feb. 10, 2024

Issue #522 has been reported by Vadim Zaliva. ---------------------------------------- Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522 * Author: Vadim Zaliva * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-12-27 * Affected versions: master ---------------------------------------- `region_overlap()` function checks whether or not two memory regions overlap. Memory regions are represented as a region struct that contains the region's offset and size. This function then relies on `region_end()` function to compute the end of the region. `region_end()` function is susceptible to an integer overflow, which might result in the incorrect behaviour of `region_overlap()` function. An example of inputs that lead to wrong behaviour: ``` struct region r1 = {SIZE_MAX - 10, 20}; struct region r2 = {SIZE_MAX - 20, 15}; ``` It returns 0, but since the regions actually overlap, it should return 1. `region_overlap()` function is used in `smm_region_overlaps_handler()` function, which is itself used in SMI handlers to validate address values that come from an untrusted environment. This is necessary to prevent security vulnerabilities such as described in [BARing the System by Yuriy Bulygin, Oleksandr Bazhaniuk et al.](https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf) We do not have an example of an exploit based on this incorrect behaviour and are aware of the existence of one. However, theoretically, this could lead to security vulnerabilities. This bug was found during an ongoing [Coreboot Formal Verification Project](https://zaliva.org/UCSC-Twisted-Presentation-20231211.pdf), which aims to prove some important security properties of the coreboot’s SMI handler for the Gemini Lake/Octopus platform using Coq proof assistant and Verified Software Toolchain framework. -- 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

6 16

Is there a way to enable a PCI-PCI bridge on bus 3 early?
by Keith Hui Jan. 11, 2024

Jan. 11, 2024

In my quest to get POST codes to show on my Asus P8Z77-M, and fixing sb/bd82x6x [1] along the way, I'm still not quite getting them. I have a ISA/PCI POST card, but it isn't giving me anything. I bought a little "Debug Card Expert" off Amazon that looks like a mini-PCI/mini-PCIe cross, but in today's testing I found out that it isn't wired properly (i.e. isn't going to work) for PCIe at all, but I did get it to show POST codes over LPC via the TPM header. I have another of this same little PoS that broke in half on arrival. Now that I know it only really works over LPC and only 9 signals, I'll attempt to repair the broken traces and glue it together. My board has a PCI-PCI bridge on bus:device.func 3:0.0 (so bus 3, this will be important) that services the PCI slot. After applying [1] to have the PCH send port 80 data to PCI as I specified in Kconfig, I still don't get any POST code... and not over LPC either, so I know my patch works. Now I think I may need to enable CONFIG_EARLY_PCI_BRIDGE. Problem is the bridge has to be a device on bus 0. How can I enable this PCI bridge on bus 3 early so a POST card sitting on it can get codes? Thanks Keith [1] https://review.coreboot.org/c/coreboot/+/79725

2 7

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

Dec. 31, 2023

Issue #121 has been updated by Patrick Rudolph. It looks like this issue doesn't appear any more when using the MRC.bin instead of native raminit. Thus it's likely that there's a difference between MRC and NRI that causes this issue. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1725 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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

[PATCH] firmware: coreboot: framebuffer: Avoid invalid zero physical address
by Alper Nebi Yasak Dec. 27, 2023

Dec. 27, 2023

On ARM64 systems coreboot defers framebuffer allocation to its payload, to be done by a libpayload function call. In this case, coreboot tables still include a framebuffer entry with display format details, but the physical address field is set to zero (as in [1], for example). Unfortunately, this field is not automatically updated when the framebuffer is initialized through libpayload, citing that doing so would invalidate checksums over the entire coreboot table [2]. This can be observed on ARM64 Chromebooks with stock firmware. On a Google Kevin (RK3399), trying to use coreboot framebuffer driver as built-in to the kernel results in a benign error. But on Google Hana (MT8173) and Google Cozmo (MT8183) it causes a hang. When the framebuffer physical address field in the coreboot table is zero, we have no idea where coreboot initialized a framebuffer, or even if it did. Instead of trying to set up a framebuffer located at zero, return ENODEV to indicate that there isn't one. [1] https://review.coreboot.org/c/coreboot/+/17109 [2] https://review.coreboot.org/c/coreboot/+/8797 Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- (I was previously told on #coreboot IRC that I could add coreboot mailing list to CC for kernel patches related to coreboot.) drivers/firmware/google/framebuffer-coreboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/google/framebuffer-coreboot.c b/drivers/firmware/google/framebuffer-coreboot.c index c323a818805c..5c84bbebfef8 100644 --- a/drivers/firmware/google/framebuffer-coreboot.c +++ b/drivers/firmware/google/framebuffer-coreboot.c @@ -36,6 +36,9 @@ static int framebuffer_probe(struct coreboot_device *dev) .format = NULL, }; + if (!fb->physical_address) + return -ENODEV; + for (i = 0; i < ARRAY_SIZE(formats); ++i) { if (fb->bits_per_pixel == formats[i].bits_per_pixel && fb->red_mask_pos == formats[i].red.offset && base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f -- 2.42.0

3 2

[coreboot - Bug #521] (New) gizmosphere/gizmo2 development board VGA support not working
by 8oDE 03 Dec. 24, 2023

Dec. 24, 2023

Issue #521 has been reported by 8oDE 03. ---------------------------------------- Bug #521: gizmosphere/gizmo2 development board VGA support not working https://ticket.coreboot.org/issues/521 * Author: 8oDE 03 * Status: New * Priority: High * Category: board support * Target version: none * Start date: 2023-12-24 * Affected versions: 4.18 * Needs backport to: none * Affected hardware: GizmoSphere Gizmo 2 ---------------------------------------- I got a gizmo2 development board. the official hardware and software support stopped a long time ago and no BIOS source code was released. I tried to compile coreboot firmware to support some new features. The latest supported coreboot version is 4.18. I flashed and booted the gizmo2 development board, there is no video output during the coreboot startup phase, but it boots the OS normally and the OS has video output, I purchased a FT232H board for printing logs, and it seems like there are a lot of problems. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs_master_header 0x0 cbfs header 32 none config 0x80 raw 562 none revision 0x300 raw 720 none build_info 0x600 raw 103 none spd.bin 0x6c0 spd 128 none fallback/dsdt.aml 0x780 raw 6172 none cmos_layout.bin 0x2000 cmos_layout 616 none fallback/postcar 0x22c0 stage 22312 none payload_config 0x7a40 raw 1621 none payload_revision 0x80c0 raw 237 none (empty) 0x8200 null 31652 none apu/amdfw 0xfdc0 raw 135168 none fallback/romstage 0x30e00 stage 387544 none fallback/ramstage 0x8f880 stage 136240 LZMA (311716 decompressed) pci1002,9830.rom 0xb0d40 optionrom 59392 none fallback/payload 0xbf580 simple elf 72695 none (empty) 0xd11c0 null 3255268 none bootblock 0x3ebdc0 bootblock 16384 none ``` ---Files-------------------------------- coreboot-4.18-bootlog.txt (25.9 KB) .config (15.1 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

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

Dec. 23, 2023

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 5 new defect(s) introduced to coreboot found with Coverity Scan. 442 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 5 of 5 defect(s) ** CID 1532881: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1532881: (OVERRUN) /src/soc/intel/apollolake/mmap_boot.c: 73 in bios_mmap_init() 67 */ 68 bios_mapped_size = size - 256 * KiB; 69 70 rdev_chain_mem(&shadow_dev, (void *)base, bios_mapped_size); 71 72 xlate_window_init(&real_dev_window, &shadow_dev, start, bios_mapped_size); >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 73 xlate_region_device_ro_init(&real_dev, 1, &real_dev_window, CONFIG_ROM_SIZE); 74 75 bios_size = size; 76 77 /* Check that the CBFS lies within the memory mapped area. It's too 78 easy to forget the SRAM mapping when crafting an FMAP file. */ /src/soc/intel/common/block/fast_spi/mmap_boot.c: 134 in bios_mmap_init() 128 ext_win_flash_base = fixed_win_flash_base - ext_win_size; 129 initialize_window(EXT_BIOS_DECODE_WINDOW, ext_win_host_base, 130 ext_win_flash_base, ext_win_size); 131 win_count++; 132 } 133 >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 134 xlate_region_device_ro_init(&real_dev, win_count, real_dev_windows, CONFIG_ROM_SIZE); 135 136 init_done = true; 137 } 138 139 const struct region_device *boot_device_ro(void) ** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() ________________________________________________________________________________________________________ *** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() 52 { 53 uint8_t j, k; 54 55 k = (idx >> 8) + 1; 56 j = (idx >> 4) & 0x0f; 57 *addr = idx & 0x0f; >>> CID 1532880: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "j" with type "uint8_t" (8 bits, unsigned) is promoted in "j << 4 * k" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "j << 4 * k" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 58 *addr |= j << (4*k); 59 *value = 0x01010101 << (j & 7); 60 if (j & 8) 61 *value = ~(*value); 62 } 63 ** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() ________________________________________________________________________________________________________ *** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() 249 250 static void post_mp_init(void) 251 { 252 global_smi_enable(); 253 254 if (CONFIG(SOC_INTEL_COMMON_BLOCK_SGX_ENABLE)) >>> CID 1532879: Error handling issues (CHECKED_RETURN) >>> Calling "mp_run_on_all_cpus" without checking return value (as is done elsewhere 4 out of 5 times). 255 mp_run_on_all_cpus(sgx_configure, NULL); 256 } 257 258 static const struct mp_ops mp_ops = { 259 .pre_mp_init = pre_mp_init, 260 .get_cpu_count = get_cpu_count, ** CID 1532878: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1532878: Null pointer dereferences (FORWARD_NULL) /src/soc/qualcomm/common/qup_se_handler.c: 167 in qup_handle_transfer() 161 m_irq = qup_wait_for_m_irq(bus); 162 if ((m_irq & M_RX_FIFO_WATERMARK_EN) || 163 (m_irq & M_RX_FIFO_LAST_EN)) 164 rx_rem_bytes -= handle_rx(bus, din + size 165 - rx_rem_bytes, rx_rem_bytes); 166 if (m_irq & M_TX_FIFO_WATERMARK_EN) >>> CID 1532878: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "dout + size - tx_rem_bytes" to "handle_tx", which dereferences it. 167 tx_rem_bytes -= handle_tx(bus, dout + size 168 - tx_rem_bytes, tx_rem_bytes); 169 if (m_irq & M_CMD_DONE_EN) { 170 write32(&regs->geni_m_irq_clear, m_irq); 171 break; 172 } ** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() ________________________________________________________________________________________________________ *** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() 335 cl_node_t *node = malloc(sizeof(cl_node_t)); 336 if (!node) 337 return NULL; 338 339 node->data = malloc(len * sizeof(u32)); 340 if (!(node->data)) >>> CID 1532877: Resource leaks (RESOURCE_LEAK) >>> Variable "node" going out of scope leaks the storage it points to. 341 return NULL; 342 343 node->size = len * sizeof(u32); 344 node->next = NULL; 345 346 return node; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Installed memory in DIMM B of both channels. SNB native raminit reports memory in DIMM A?
by Keith Hui Dec. 23, 2023

Dec. 23, 2023

I'm having more fun with my P8Z77-M. I put my two sticks of GSkill Ripjaws in slots A2 and B2 (aka C0S1, C1S1) following manual recommendations. Surprise 1: It actually worked at full speed now! It previously would totally croak, at least when I hook up serial to watch things go. Installing only one at C1S0 still didn't boot. And that's with me putting my max memory clock back to 800. Surprise 2: This is why I'm writing this email. I got this in the console: ... [DEBUG] memcfg DDR3 ref clock 133 MHz [DEBUG] memcfg DDR3 clock 1596 MHz [DEBUG] memcfg channel assignment: A: 0, B 1, C 2 [DEBUG] memcfg channel[0] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected [DEBUG] memcfg channel[1] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected ... Am I seeing things? Why did it report memory in DIMMA when I put my memory in slot 1 only? Regards Keith

1 0

Re: Planned maintenance on Thu Dec 21 8:00 - 10:00 UTC
by Martin Roth Dec. 21, 2023

Dec. 21, 2023

All three drive exchanges were just putting in blank drives and letting the raid1 resync. Dec 21, 2023 at 08:21 by coreboot(a)coreboot.org: > On 20.12.23 23:50, Martin Roth via coreboot wrote: > >> It's trivial to them, and a pain in the ass for us. It's complete bullshit that they'd do this. The company should do better. This is crap customer service, and we both know it. They deserve to be called out for that. People should know that they're happy to screw their customers over when they screw up. >> > > So what did they do in the end? Did they take the disk and copy the data > to the new one, or just swap them and let you start over with an empty > disk? > > Nico > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Planned maintenance on Thu Dec 21 8:00 - 10:00 UTC
by Felix Singer Dec. 21, 2023

Dec. 21, 2023

Our hoster made a mistake during the last maintenance this week and it needs to be fixed. That requires another (but last!) downtime at the following time for two hours. Start of maintenance: Thursday, Dec 21 8:00 UTC Expected end of maintenance: Thursday, Dec 21 10:00 UTC We are sorry for the inconveniences. Felix

3 6

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

Dec. 20, 2023

Issue #121 has been updated by Patrick Rudolph. It's still not clear why subsystem to look at. Even with access to Intel confidential documents it's hard to tell what happens when package C states are entered. Due to the nature that the CPU isn't running at deeper C-states, it doesn't make it easier to debug. What could help: - Compare MSRs against vendor firmware - Compare power/idle related registers against vendor firmware - Disable PCI devices and test if the problem persists - Test on desktops. So far only mobile users have reported problems. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1722 * Author: Julz Buckton * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 - Feature #185] (Resolved) x86_64 support on real hardware
by Patrick Rudolph Dec. 20, 2023

Dec. 20, 2023

Issue #185 has been updated by Patrick Rudolph. Status changed from New to Resolved Coreboot has gained x86_64 support. Closing. ---------------------------------------- Feature #185: x86_64 support on real hardware https://ticket.coreboot.org/issues/185#change-1721 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2018-12-08 ---------------------------------------- * port a coreboot supported mainboard from x86 to x86_64 (ROMSTAGE / RAMSTAGE only) * Get familiar with protected mode and long mode * Learn about paging * Fix existing code to support x86_64 (struct packing, linker alignment, ...) * Might need to write assembler code * Write Documentation -- 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 - Feature #197] (Resolved) QEMU x86_64 support
by Patrick Rudolph Dec. 20, 2023

Dec. 20, 2023

Issue #197 has been updated by Patrick Rudolph. Status changed from New to Resolved x86_64 is working fine on QEMU and real hardware. Closing. ---------------------------------------- Feature #197: QEMU x86_64 support https://ticket.coreboot.org/issues/197#change-1720 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2019-02-14 ---------------------------------------- WIP: * https://review.coreboot.org/q/topic:%22x86_64_support%22+(status:open%20OR%… Currently broken: * Relocatable ramstage on x86_64 using GCC 8 -- 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 #262] (Resolved) Sandy Bridge/IvyBridge: Only advertise supported MWAIT states as ACPI C states
by Patrick Rudolph Dec. 20, 2023

Dec. 20, 2023

Issue #262 has been updated by Patrick Rudolph. Status changed from New to Resolved Implemented here: https://review.coreboot.org/c/coreboot/+/78194 ---------------------------------------- Bug #262: Sandy Bridge/IvyBridge: Only advertise supported MWAIT states as ACPI C states https://ticket.coreboot.org/issues/262#change-1719 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2020-06-18 ---------------------------------------- Some CPUs might not support MWAIT(C6)/MWAIT(C7). Don't advertise them as ACPI C3 as not supported. -- 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

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

Dec. 20, 2023

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 55 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 20 of 55 defect(s) ** CID 1531473: Error handling issues (CHECKED_RETURN) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/CCX/Common/AmdTable.c: 135 in SetSmnTableEntry() ________________________________________________________________________________________________________ *** CID 1531473: Error handling issues (CHECKED_RETURN) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/CCX/Common/AmdTable.c: 135 in SetSmnTableEntry() 129 130 Status = SilGetIp2IpApi (SilId_SmuClass, (void **)&SmuApi); 131 if (Status != SilPass) { 132 XUSL_TRACEPOINT (SIL_TRACE_ERROR, "SMU API not found!\n"); 133 return Status; 134 } >>> CID 1531473: Error handling issues (CHECKED_RETURN) >>> Calling "SilGetIp2IpApi" without checking return value (as is done elsewhere 28 out of 29 times). 135 SilGetIp2IpApi (SilId_DfClass, (void**) &DfApi); 136 if (Status != SilPass) { 137 XUSL_TRACEPOINT (SIL_TRACE_ERROR, "DF API not found!\n"); 138 return Status; 139 } 140 ** CID 1531471: Control flow issues (DEADCODE) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/FCH/Common/FchCore/FchHwAcpi/FchHwAcpi.c: 315 in ProgramCpuRstBTmr() ________________________________________________________________________________________________________ *** CID 1531471: Control flow issues (DEADCODE) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/FCH/Common/FchCore/FchHwAcpi/FchHwAcpi.c: 315 in ProgramCpuRstBTmr() 309 uint32_t RegEbx; 310 uint8_t PkgType; 311 312 RegEbx = 0; 313 PkgType = (uint8_t) (RegEbx >> 28); 314 if (PkgType == 0x4) { >>> CID 1531471: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "xUSLMemReadModifyWrite8((vo...". 315 xUSLMemReadModifyWrite8((void *)(size_t)(ACPI_MMIO_BASE + PMIO_BASE + FCH_PMIOA_REG20 + 2), 0, 0xFF); 316 xUSLMemReadModifyWrite8((void *)(size_t)(ACPI_MMIO_BASE + PMIO_BASE + FCH_PMIOA_REG20 + 3), 0xF8, 0x07); 317 } 318 } 319 320 static void FchInitEnableWdt (FCHCLASS_INPUT_BLK *FchDataPtr) ** CID 1531470: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/options.go: 379 in github.com/alecthomas/kong.Configuration.anonymous%0(*github.com/alecthomas… ________________________________________________________________________________________________________ *** CID 1531470: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/options.go: 379 in github.com/alecthomas/kong.Configuration.anonymous%0(*github.com/alecthomas… 373 if os.IsNotExist(err) || os.IsPermission(err) { 374 continue 375 } 376 377 return err 378 } >>> CID 1531470: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "f.Close()" is not explicitly checked. 379 f.Close() 380 381 resolver, err := k.LoadConfig(path) 382 if err != nil { 383 return errors.Wrap(err, path) 384 } ** CID 1531469: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 1121 in github.com/fxamacker/cbor/v2.encodeTime(*github.com/fxamacker/cbor/v2.encod…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531469: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 1121 in github.com/fxamacker/cbor/v2.encodeTime(*github.com/fxamacker/cbor/v2.encod…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 1115 return encode(e, em, v.Elem()) 1116 } 1117 1118 func encodeTime(e *encoderBuffer, em *encMode, v reflect.Value) error { 1119 t := v.Interface().(time.Time) 1120 if t.IsZero() { >>> CID 1531469: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 1121 e.Write(cborNil) // Even if tag is required, encode as CBOR null. 1122 return nil 1123 } 1124 if em.timeTag == EncTagRequired { 1125 tagNumber := 1 1126 if em.time == TimeRFC3339 || em.time == TimeRFC3339Nano { ** CID 1531468: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 795 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 791 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 804 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 808 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531468: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 795 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 789 vk := v.Kind() 790 if vk == reflect.Slice && v.IsNil() { 791 e.Write(cborNil) 792 return nil 793 } 794 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 795 e.Write(b) 796 } 797 slen := v.Len() 798 if slen == 0 { 799 return e.WriteByte(byte(cborTypeByteString)) 800 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 791 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 785 return nil 786 } 787 788 func encodeByteString(e *encoderBuffer, em *encMode, v reflect.Value) error { 789 vk := v.Kind() 790 if vk == reflect.Slice && v.IsNil() { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 791 e.Write(cborNil) 792 return nil 793 } 794 if b := em.encTagBytes(v.Type()); b != nil { 795 e.Write(b) 796 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 804 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 798 if slen == 0 { 799 return e.WriteByte(byte(cborTypeByteString)) 800 } 801 encodeHead(e, byte(cborTypeByteString), uint64(slen)) 802 if vk == reflect.Array { 803 for i := 0; i < slen; i++ { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.WriteByte((uint8)v.Index(i).Uint())" is not explicitly checked. 804 e.WriteByte(byte(v.Index(i).Uint())) 805 } 806 return nil 807 } 808 e.Write(v.Bytes()) 809 return nil /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 808 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 802 if vk == reflect.Array { 803 for i := 0; i < slen; i++ { 804 e.WriteByte(byte(v.Index(i).Uint())) 805 } 806 return nil 807 } >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(v.Bytes())" is not explicitly checked. 808 e.Write(v.Bytes()) 809 return nil 810 } 811 812 func encodeString(e *encoderBuffer, em *encMode, v reflect.Value) error { 813 if b := em.encTagBytes(v.Type()); b != nil { ** CID 1531467: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 828 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 832 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531467: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 828 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 822 type arrayEncodeFunc struct { 823 f encodeFunc 824 } 825 826 func (ae arrayEncodeFunc) encode(e *encoderBuffer, em *encMode, v reflect.Value) error { 827 if v.Kind() == reflect.Slice && v.IsNil() { >>> CID 1531467: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 828 e.Write(cborNil) 829 return nil 830 } 831 if b := em.encTagBytes(v.Type()); b != nil { 832 e.Write(b) 833 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 832 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 826 func (ae arrayEncodeFunc) encode(e *encoderBuffer, em *encMode, v reflect.Value) error { 827 if v.Kind() == reflect.Slice && v.IsNil() { 828 e.Write(cborNil) 829 return nil 830 } 831 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531467: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 832 e.Write(b) 833 } 834 alen := v.Len() 835 if alen == 0 { 836 return e.WriteByte(byte(cborTypeArray)) 837 } ** CID 1531466: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 43118 in wuffs_jpeg__decoder__decode_sof() ________________________________________________________________________________________________________ *** CID 1531466: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 43118 in wuffs_jpeg__decoder__decode_sof() 43112 } 43113 if (self->private_impl.f_height == 0u) { 43114 status = wuffs_base__make_status(wuffs_jpeg__error__unsupported_implicit_height); 43115 goto exit; 43116 } 43117 { >>> CID 1531466: Control flow issues (MISSING_BREAK) >>> The case for value "4U" is not terminated by a "break" statement. 43118 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(4); 43119 uint32_t t_2; 43120 if (WUFFS_BASE__LIKELY(io2_a_src - iop_a_src >= 2)) { 43121 t_2 = ((uint32_t)(wuffs_base__peek_u16be__no_bounds_check(iop_a_src))); 43122 iop_a_src += 2; 43123 } else { ** CID 1531465: Incorrect expression (NO_EFFECT) /src/vendorcode/wuffs/wuffs-v0.4.c: 42580 in wuffs_jpeg__decoder__do_decode_image_config() ________________________________________________________________________________________________________ *** CID 1531465: Incorrect expression (NO_EFFECT) /src/vendorcode/wuffs/wuffs-v0.4.c: 42580 in wuffs_jpeg__decoder__do_decode_image_config() 42574 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 42575 goto suspend; 42576 } 42577 iop_a_src += self->private_data.s_do_decode_image_config[0].scratch; 42578 self->private_impl.f_payload_length = 0u; 42579 } >>> CID 1531465: Incorrect expression (NO_EFFECT) >>> Assigning "self->private_impl.choosy_decode_idct" to itself has no effect. 42580 self->private_impl.choosy_decode_idct = ( 42581 #if defined(WUFFS_BASE__CPU_ARCH__X86_64) 42582 wuffs_base__cpu_arch__have_x86_avx2() ? &wuffs_jpeg__decoder__decode_idct_x86_avx2 : 42583 #endif 42584 self->private_impl.choosy_decode_idct); 42585 self->private_impl.f_frame_config_io_position = wuffs_base__u64__sat_add((a_src ? a_src->meta.pos : 0), ((uint64_t)(iop_a_src - io0_a_src))); ** CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() ________________________________________________________________________________________________________ *** CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() 19860 // These deltas are conceptually int32_t (signed) but after squaring, 19861 // it's equivalent to work in uint32_t (unsigned). 19862 pb -= cb; 19863 pg -= cg; 19864 pr -= cr; 19865 pa -= ca; >>> CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "pg * pg" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 19866 uint64_t score = ((uint64_t)(pb * pb)) + ((uint64_t)(pg * pg)) + 19867 ((uint64_t)(pr * pr)) + ((uint64_t)(pa * pa)); 19868 if (best_score > score) { 19869 best_score = score; 19870 best_index = i; 19871 } ** CID 1531463: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42377 in wuffs_jpeg__decoder__do_decode_image_config() ________________________________________________________________________________________________________ *** CID 1531463: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42377 in wuffs_jpeg__decoder__do_decode_image_config() 42371 42372 if (self->private_impl.f_call_sequence != 0u) { 42373 status = wuffs_base__make_status(wuffs_base__error__bad_call_sequence); 42374 goto exit; 42375 } 42376 { >>> CID 1531463: Control flow issues (MISSING_BREAK) >>> The case for value "1U" is not terminated by a "break" statement. 42377 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(1); 42378 if (WUFFS_BASE__UNLIKELY(iop_a_src == io2_a_src)) { 42379 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 42380 goto suspend; 42381 } 42382 uint8_t t_0 = *iop_a_src++; ** CID 1531462: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 316 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 301 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 267 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 275 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 218 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 291 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 305 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 217 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 285 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 261 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 270 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 308 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 205 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 282 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 219 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() ________________________________________________________________________________________________________ *** CID 1531462: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 316 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 310 keys := v.MapKeys() 311 if f.cs.SortKeys { 312 sortValues(keys, f.cs) 313 } 314 for i, key := range keys { 315 if i > 0 { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(spaceBytes)" is not explicitly checked. 316 f.fs.Write(spaceBytes) 317 } 318 f.ignoreNextType = true 319 f.format(f.unpackValue(key)) 320 f.fs.Write(colonBytes) 321 f.ignoreNextType = true /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 301 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 295 // Do nothing. We should never get here since pointers have already 296 // been handled above. 297 298 case reflect.Map: 299 // nil maps should be indicated as different than empty maps 300 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 301 f.fs.Write(nilAngleBytes) 302 break 303 } 304 305 f.fs.Write(openMapBytes) 306 f.depth++ /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 267 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 261 f.fs.Write(nilAngleBytes) 262 break 263 } 264 fallthrough 265 266 case reflect.Array: >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openBracketBytes)" is not explicitly checked. 267 f.fs.Write(openBracketBytes) 268 f.depth++ 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 275 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() 273 for i := 0; i < numEntries; i++ { 274 if i > 0 { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(spaceBytes)" is not explicitly checked. 275 f.fs.Write(spaceBytes) 276 } 277 f.ignoreNextType = true 278 f.format(f.unpackValue(v.Index(i))) 279 } 280 } /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 218 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 212 return 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { 217 f.fs.Write(openParenBytes) >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(([]byte)v.Type().String())" is not explicitly checked. 218 f.fs.Write([]byte(v.Type().String())) 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 223 // Call Stringer/error interfaces if they exist and the handle methods /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 291 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: 288 // The only time we should get here is for nil interfaces due to 289 // unpackValue calls. 290 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 291 f.fs.Write(nilAngleBytes) 292 } 293 294 case reflect.Ptr: 295 // Do nothing. We should never get here since pointers have already 296 // been handled above. /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 305 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 299 // nil maps should be indicated as different than empty maps 300 if v.IsNil() { 301 f.fs.Write(nilAngleBytes) 302 break 303 } 304 >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openMapBytes)" is not explicitly checked. 305 f.fs.Write(openMapBytes) 306 f.depth++ 307 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 308 f.fs.Write(maxShortBytes) 309 } else { 310 keys := v.MapKeys() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 217 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 211 f.formatPtr(v) 212 return 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openParenBytes)" is not explicitly checked. 217 f.fs.Write(openParenBytes) 218 f.fs.Write([]byte(v.Type().String())) 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 285 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 279 } 280 } 281 f.depth-- 282 f.fs.Write(closeBracketBytes) 283 284 case reflect.String: >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(([]byte)v.String())" is not explicitly checked. 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: 288 // The only time we should get here is for nil interfaces due to 289 // unpackValue calls. 290 if v.IsNil() { /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 261 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 255 256 case reflect.Complex128: 257 printComplex(f.fs, v.Complex(), 64) 258 259 case reflect.Slice: 260 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 261 f.fs.Write(nilAngleBytes) 262 break 263 } 264 fallthrough 265 266 case reflect.Array: /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 270 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 264 fallthrough 265 266 case reflect.Array: 267 f.fs.Write(openBracketBytes) 268 f.depth++ 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(maxShortBytes)" is not explicitly checked. 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() 273 for i := 0; i < numEntries; i++ { 274 if i > 0 { 275 f.fs.Write(spaceBytes) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 308 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 302 break 303 } 304 305 f.fs.Write(openMapBytes) 306 f.depth++ 307 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(maxShortBytes)" is not explicitly checked. 308 f.fs.Write(maxShortBytes) 309 } else { 310 keys := v.MapKeys() 311 if f.cs.SortKeys { 312 sortValues(keys, f.cs) 313 } /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 205 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 199 // dealing with and formats it appropriately. It is a recursive function, 200 // however circular data structures are detected and handled properly. 201 func (f *formatState) format(v reflect.Value) { 202 // Handle invalid reflect values immediately. 203 kind := v.Kind() 204 if kind == reflect.Invalid { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(invalidAngleBytes)" is not explicitly checked. 205 f.fs.Write(invalidAngleBytes) 206 return 207 } 208 209 // Handle pointers specially. 210 if kind == reflect.Ptr { /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 282 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 276 } 277 f.ignoreNextType = true 278 f.format(f.unpackValue(v.Index(i))) 279 } 280 } 281 f.depth-- >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(closeBracketBytes)" is not explicitly checked. 282 f.fs.Write(closeBracketBytes) 283 284 case reflect.String: 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 219 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { 217 f.fs.Write(openParenBytes) 218 f.fs.Write([]byte(v.Type().String())) >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(closeParenBytes)" is not explicitly checked. 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 223 // Call Stringer/error interfaces if they exist and the handle methods 224 // flag is enabled. ** CID 1531461: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 206 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 205 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() ________________________________________________________________________________________________________ *** CID 1531461: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 206 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() 200 if err != nil && t.Get("short") != "" { 201 return fmt.Errorf("invalid short flag name %q: %s", t.Get("short"), err) 202 } 203 t.Hidden = t.Has("hidden") 204 t.Format = t.Get("format") 205 t.Sep, _ = t.GetSep("sep", ',') >>> CID 1531461: (SUPPRESSED_ERROR) >>> The error returned by the function "t.GetSep("mapsep", 59)" is not explicitly checked. 206 t.MapSep, _ = t.GetSep("mapsep", ';') 207 t.Group = t.Get("group") 208 for _, xor := range t.GetAll("xor") { 209 t.Xor = append(t.Xor, strings.FieldsFunc(xor, tagSplitFn)...) 210 } 211 t.Prefix = t.Get("prefix") /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 205 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() 199 t.Short, err = t.GetRune("short") 200 if err != nil && t.Get("short") != "" { 201 return fmt.Errorf("invalid short flag name %q: %s", t.Get("short"), err) 202 } 203 t.Hidden = t.Has("hidden") 204 t.Format = t.Get("format") >>> CID 1531461: (SUPPRESSED_ERROR) >>> The error returned by the function "t.GetSep("sep", 44)" is not explicitly checked. 205 t.Sep, _ = t.GetSep("sep", ',') 206 t.MapSep, _ = t.GetSep("mapsep", ';') 207 t.Group = t.Get("group") 208 for _, xor := range t.GetAll("xor") { 209 t.Xor = append(t.Xor, strings.FieldsFunc(xor, tagSplitFn)...) 210 } ** CID 1531460: Null pointer dereferences (FORWARD_NULL) /src/vendorcode/wuffs/wuffs-v0.4.c: 43686 in wuffs_jpeg__decoder__do_decode_frame() ________________________________________________________________________________________________________ *** CID 1531460: Null pointer dereferences (FORWARD_NULL) /src/vendorcode/wuffs/wuffs-v0.4.c: 43686 in wuffs_jpeg__decoder__do_decode_frame() 43680 { 43681 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(2); 43682 if (WUFFS_BASE__UNLIKELY(iop_a_src == io2_a_src)) { 43683 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 43684 goto suspend; 43685 } >>> CID 1531460: Null pointer dereferences (FORWARD_NULL) >>> Incrementing null pointer "iop_a_src". 43686 uint8_t t_0 = *iop_a_src++; 43687 v_c = t_0; 43688 } 43689 if (v_c == 255u) { 43690 break; 43691 } ** CID 1531459: Audit impact security (SUPPRESSED_ERROR) /util/goswid/pkg/uswid/uswid.go: 342 in github.com/9elements/goswid/pkg/uswid.UswidSoftwareIdentity.ToCBOR(bool)([]…, error)() ________________________________________________________________________________________________________ *** CID 1531459: Audit impact security (SUPPRESSED_ERROR) /util/goswid/pkg/uswid/uswid.go: 342 in github.com/9elements/goswid/pkg/uswid.UswidSoftwareIdentity.ToCBOR(bool)([]…, error)() 336 var buf bytes.Buffer 337 zlibWriter := zlib.NewWriter(&buf) 338 _, err := zlibWriter.Write(cborBuf) 339 if err != nil { 340 return nil, fmt.Errorf("cannot zlib compress CBOR data: %w", err) 341 } >>> CID 1531459: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "zlibWriter.Close()" is not explicitly checked. 342 zlibWriter.Close() 343 return buf.Bytes(), nil 344 } else { 345 return cborBuf, nil 346 } ** CID 1531458: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 689 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 657 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 680 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 642 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531458: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 689 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 683 } 684 685 // Encode float32 686 // Don't use encodeFloat32() because it cannot be inlined. 687 e.scratch[0] = byte(cborTypePrimitives) | byte(26) 688 binary.BigEndian.PutUint32(e.scratch[1:], math.Float32bits(f32)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:5:nil])" is not explicitly checked. 689 e.Write(e.scratch[:5]) 690 return nil 691 } 692 693 func encodeInf(e *encoderBuffer, em *encMode, v reflect.Value) error { 694 f64 := v.Float() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 657 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 651 fopt := em.shortestFloat 652 if v.Kind() == reflect.Float64 && (fopt == ShortestFloatNone || cannotFitFloat32(f64)) { 653 // Encode float64 654 // Don't use encodeFloat64() because it cannot be inlined. 655 e.scratch[0] = byte(cborTypePrimitives) | byte(27) 656 binary.BigEndian.PutUint64(e.scratch[1:], math.Float64bits(f64)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:9:nil])" is not explicitly checked. 657 e.Write(e.scratch[:9]) 658 return nil 659 } 660 661 f32 := float32(f64) 662 if fopt == ShortestFloat16 { /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 680 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 674 } 675 if p == float16.PrecisionExact { 676 // Encode float16 677 // Don't use encodeFloat16() because it cannot be inlined. 678 e.scratch[0] = byte(cborTypePrimitives) | byte(25) 679 binary.BigEndian.PutUint16(e.scratch[1:], uint16(f16)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:3:nil])" is not explicitly checked. 680 e.Write(e.scratch[:3]) 681 return nil 682 } 683 } 684 685 // Encode float32 /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 642 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 636 encodeHead(e, byte(cborTypePositiveInt), v.Uint()) 637 return nil 638 } 639 640 func encodeFloat(e *encoderBuffer, em *encMode, v reflect.Value) error { 641 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 642 e.Write(b) 643 } 644 f64 := v.Float() 645 if math.IsNaN(f64) { 646 return encodeNaN(e, em, v) 647 } ** CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 3939 in wuffs_base__color_u32_argb_premul__as__color_u64_argb_nonpremul() ________________________________________________________________________________________________________ *** CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 3939 in wuffs_base__color_u32_argb_premul__as__color_u64_argb_nonpremul() 3933 uint64_t g16 = 0x101 * (0xFF & (c >> 8)); 3934 uint64_t b16 = 0x101 * (0xFF & (c >> 0)); 3935 return 0xFFFF000000000000u | (r16 << 32) | (g16 << 16) | (b16 << 0); 3936 } else if (a == 0) { 3937 return 0; 3938 } >>> CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "a * 257U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 3939 uint64_t a16 = a * 0x101; 3940 3941 uint64_t r = 0xFF & (c >> 16); 3942 uint64_t r16 = (r * (0x101 * 0xFFFF)) / a16; 3943 uint64_t g = 0xFF & (c >> 8); 3944 uint64_t g16 = (g * (0x101 * 0xFFFF)) / a16; ** CID 1531456: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 777 in github.com/fxamacker/cbor/v2.encodeFloat32(*github.com/fxamacker/cbor/v2.en…, float32)error() ________________________________________________________________________________________________________ *** CID 1531456: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 777 in github.com/fxamacker/cbor/v2.encodeFloat32(*github.com/fxamacker/cbor/v2.en…, float32)error() 771 return nil 772 } 773 774 func encodeFloat32(e *encoderBuffer, f32 float32) error { 775 e.scratch[0] = byte(cborTypePrimitives) | byte(26) 776 binary.BigEndian.PutUint32(e.scratch[1:], math.Float32bits(f32)) >>> CID 1531456: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:5:nil])" is not explicitly checked. 777 e.Write(e.scratch[:5]) 778 return nil 779 } 780 781 func encodeFloat64(e *encoderBuffer, f64 float64) error { 782 e.scratch[0] = byte(cborTypePrimitives) | byte(27) ** CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() ________________________________________________________________________________________________________ *** CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() 19860 // These deltas are conceptually int32_t (signed) but after squaring, 19861 // it's equivalent to work in uint32_t (unsigned). 19862 pb -= cb; 19863 pg -= cg; 19864 pr -= cr; 19865 pa -= ca; >>> CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "pb * pb" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 19866 uint64_t score = ((uint64_t)(pb * pb)) + ((uint64_t)(pg * pg)) + 19867 ((uint64_t)(pr * pr)) + ((uint64_t)(pa * pa)); 19868 if (best_score > score) { 19869 best_score = score; 19870 best_index = i; 19871 } ** CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) /util/goswid/vendor/github.com/davecgh/go-spew/spew/bypass.go: 36 in () ________________________________________________________________________________________________________ *** CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) /util/goswid/vendor/github.com/davecgh/go-spew/spew/bypass.go: 36 in () 30 const ( 31 // UnsafeDisabled is a build-time constant which specifies whether or 32 // not access to the unsafe package is available. 33 UnsafeDisabled = false 34 35 // ptrSize is the size of a pointer on the current arch. >>> CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) >>> Using unsafe function Sizeof. 36 ptrSize = unsafe.Sizeof((*byte)(nil)) 37 ) 38 39 type flag uintptr 40 41 var ( ** CID 1531453: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42830 in wuffs_jpeg__decoder__decode_appn() ________________________________________________________________________________________________________ *** CID 1531453: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42830 in wuffs_jpeg__decoder__decode_appn() 42824 iop_a_src = io1_a_src; 42825 io2_a_src = io0_a_src + a_src->meta.wi; 42826 } 42827 42828 uint32_t coro_susp_point = self->private_impl.p_decode_appn[0]; 42829 switch (coro_susp_point) { >>> CID 1531453: Control flow issues (MISSING_BREAK) >>> The case for value "0U" is not terminated by a "break" statement. 42830 WUFFS_BASE__COROUTINE_SUSPENSION_POINT_0; 42831 42832 do { 42833 if (a_marker == 224u) { 42834 if (self->private_impl.f_payload_length >= 5u) { 42835 self->private_impl.f_payload_length -= 5u; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

Dec. 20, 2023

Issue #121 has been updated by Anastasios Koutian. After upgrading to coreboot 4.22.01, the issue seems to have returned for me. Hardware is the same as above, however now there is no black screen and no graphical corruption. Instead the whole screen just freezes (along with the entire system). Also, it happens only after 1-2 days whereas before it would appear within 1-2 hours. I am now limiting package C-state to 2 using MSR_PKG_CST_CONFIG_CONTROL as you suggested. I can confirm ~0.7 - 1.0 W extra power usage when idle. If you would like me to test anything else, please let me know and I would be happy to help. If this issue could be eliminated, it would be great for these older laptops, since their battery life is already limited. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1718 * Author: Julz Buckton * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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

Re: ramstage video display on Chromebook?
by James Feeney Dec. 19, 2023

Dec. 19, 2023

Down the rabbit hole... > Geminilake devices use the FSP PEI GOP driver for display init Hmm - "Pre-EFI Initialization Graphics Output Protocol"? Is this something completely different from the coreboot gfxinit? INTEL_GMA_ADD_VBT help says: The VBT describes the integrated GPU and connections, and is needed by the GOP driver integrated into FSP and the OS driver in order to initialize the display. https://wiki.osdev.org/GOP tells me: GOP is an EFI Boot Time Service, meaning you can't access it after you call ExitBootServices(). However, the framebuffer provided by GOP persists, so you can continue to use it for graphics output in your OS. How does the payload find this framebuffer? Is that info in the VBT? Or, the payload ignores this framebuffer, starts over and completely re-initializes the graphics? > so the display backlight will come on during ramstage (when FSP-S runs) That's very useful to know. > but the platform does not currently support any output / proof of life prior to the payload, other than maybe an early boot splash screen (you'd have to look if GLK supports that) Could be fun - eye candy. Martin says "Intel better than others thanks to libgfxinit", so if GOP is not GFX, then maybe a splash screen will not work? Or GFX also knows how to write to the GOP framebuffer? > simply connecting the debug cable and flashing a serial output enabled build will tell you the same thing Geminilake has serial output? This bluebird chromebook has one USB-C and one USB-A. Is the serial output going through the debug cable? It's not just some buried header on the circuit board? > coreboot saves the console output to memory and to any other output you have enabled in Kconfig. "console output to memory" meaning RAM? Or only to ROM? Or either? > The ROM does have a limited write capacity, but it's typically 100K erase/write cycles at this point, which should be enough for anyone. > Worth to mention that the flash console driver never erases. When it's full, it's full, the user needs to erase it manually. In my case, I don't like to be writing and erasing the system ROM. > Would a live Q/A session help? I'd be happy to host something. Thanks, but email is fine. It gives me time to digest, and hopefully it may leave a useful trail for someone else. Mostly, I'm being curious. Sometimes I have to stumble around before I can ask a meaningful question, and everyone's patience is much appreciated.

2 1

ramstage video display on Chromebook?
by James Feeney Dec. 19, 2023

Dec. 19, 2023

On 12/18/2023 1:00 PM MST Matt DeVillier <matt.devillier(a)gmail.com> wrote: ... Thanks for all that, Matt. A little perspective helps me a lot! I'm wondering, with MrChrombox coreboot will anything normally show on a chromebook screen at ramstage, before payload? Or, if not, can anything be *made* to show on the screen, like status or debug info? I'm thinking, if a payload fails, at least something on the screen from coreboot ramstage would indicate that coreboot executed up through ramstage, without needing to connect a debug cable - and sort of geek eye-candy. Also, it looks like there is a way to save coreboot debug messages to a file. But, does that use CAR, or would messages be repeatedly written to the ROM with every boot? Maybe cache is too small to use for debug messages - geminilake? Or repeatedly writing to ROM reduces its life?

4 3

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 18, 2023

Dec. 18, 2023

> Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection. Well, there are over 100 files named "ramstage.c" in the github repository. Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that? > It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve. But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image? And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?

2 3

coreboot services are back up
by coreboot org Dec. 17, 2023

Dec. 17, 2023

This should have taken care of the issues we've been seeing recently with gerrit. If you see any issues with any of the services, other than the redmine service at ticket.coreboot.org, which is on a different server, please respond to this email and let us know what you're seeing. Martin

1 0

coreboot.org downtime for a couple of hours right *NOW*
by coreboot org Dec. 17, 2023

Dec. 17, 2023

Hi All, We're taking down the coreboot servers for a couple of hours to do some emergency maintenance. Sorry for the short notice - everything should be back up in a couple of hours. Martin

1 0

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

> If you do need to update the EC firmware, just flash it manually. Don't bother with the automatic update. It doesn't make sense for you to build it into the firmware. Thanks. That makes more sense. Though still, I don't know where or when this "automatic update" happens. Maybe it happens when ChromeOS itself starts? If that is the case, then the EC update would *never* happen automatically if ChromeOS is replaced with something else. On the other hand, if the EC binary itself is somehow searching the CPU ROM for an EC ROM image, then it might get confused if there is no EC ROM image to find. Maybe Matt knows how this works? Matt? I also see that the Google flashrom fork seems to know how to do this update manually, if a filesystem exists, where http://goo.gl/i5sMq , "Flashrom @ Chromium.org", has: Similarly, to write the x86 and EC firmware ROMs (assume write-protection disabled): flashrom -p internal:bus=spi -w bios.bin # write x86 firmware flashrom -p internal:bus=lpc -w ec.bin # write EC firmware As far as I know, linux does not know how to directly mount a ROM coreboot filesystem.

2 1

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

>> Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > you can't, without knowing the exact build they came from. If they are Google built firmware images, they are using the Google FSP binaries/headers. Is that to say that the Google FSP headers may not match *any* version of the coreboot headers available? The FSP headers look to be setting some address offsets, which would not end well, if the wrong values were being used by coreboot. > For anything else, you'd need to know the tree/hash it was built from and which header values were selected by the build. Hmm - so in the end, "trial and error", if I really wanted to use the extracted Google FSP binaries. I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? >> Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload? > I have no idea what you are asking here - edk2 FSP files? That phrase does not make sense to me. I'm also not familiar with the LinuxBoot payload or how it would relate to edk2 Ha! I'm expecting that the FSP files being used should have nothing at all to do with the eventual coreboot payload. I was just asking for confirmation. Though I'm not completely unfamiliar with firmware generally, with coreboot and Google firmware, sometimes my assumptions are correct, and sometimes they are completely off-base and wrong. As far as playing with LinuxBoot itself, yes, I know that I may be on my own for that.

3 2

Google Embedded Controller blob - how does that get to the EC?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

>> I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? > As far as the EC, it's all open source, and in public repos at Google. You can rebuild it instead of using their binary. Thanks for that Martin. Still, I'm intimidated by the EC blob. On my board, Google's forked flashrom says: Found Nuvoton flash chip "NPCX796F". Some Nuvoton ECs, and probably this one, are ARM chips. 3rdparty/chromeec/README.md says: If you want instant gratification, you can fetch the source code directly. However, you will need the tool-chain provided by the Chromium OS development environment to build a binary. And then, at http://goo.gl/i5sMq, "Flashrom @ Chromium.org" says: For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC. And then, no matter how this EC blob is acquired, that Google page does not seem to disclose exactly *how* this EC ROM image is suppose to get from the coreboot ROM image, and into the separate EC ROM. But, for instance, I see u-boot/cmd/Kconfig actually has: menu "Firmware commands" config CMD_CROS_EC bool "Enable crosec command" depends on CROS_EC default y help Enable command-line access to the Chrome OS EC (Embedded Controller). This provides the 'crosec' command which has a number of sub-commands for performing EC tasks such as updating its flash, accessing a small saved context area and talking to the I2C bus behind the EC (if there is one). So, even after going to the trouble of getting an EC ROM image into coreboot, how does this get into the EC ROM? Does coreboot have some "magic" that checks the EC ROM version, and then automatically flash the EC ROM? Or, does this have to be done manually? And, if manually, and if u-boot is not being used, does this "crosec" command have to be found or built, to run in an x86 linux for instance, and used to actually flash the EC ROM?

3 2

Re: geminilake fsp on Google Chromebook?
by Martin Roth Dec. 17, 2023

Dec. 17, 2023

Actually, Intel doesn't have much to do with this. I can look at adding the feature, but the chromeos team would need to evaluate the size differences and decide to whether to enable it. Dec 17, 2023 at 12:09 by coreboot(a)coreboot.org: > Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > >> Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. >> > > Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. > > I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea.

1 0

COM Express type 7 / 6 board?
by ron minnich Dec. 15, 2023

Dec. 15, 2023

I'm looking for a COM Express board, type 6 or 7, that runs coreboot, thought I would start here.

4 5

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 15, 2023

Dec. 15, 2023

>> … I expect that that refers to an even newer "release 9" versus a "release 8". And, this "-r9" should also work with the setting: CONFIG_FSP_HEADER_PATH= "src/vendorcode/intel/fsp/fsp2 _0/geminilake/ 2.2.3.1 " Is that correct? > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. Oops! I was looking at your binaries in 3rdparty/blobs/mainboard/google/octopus/casta/ instead of your binaries from the site-local/Kconfig, 3rdparty/blobs/soc/intel/glk/fsp/release/. $ strings 3rdparty/blobs/soc/intel/glk/fsp/release/Fsp_M.fd |grep -i gemini|head -1 c:\tcwork\bxt_ap7829\Build\GeminilakeFspPkg\RELEASE_VS2013x86\IA32\GeminilakeSiliconPkg\NorthCluster\MemoryInitGlk\MemoryInitFsp\DEBUG\AutoGen.c Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload?

2 1

Re: geminilake fsp on Google Chromebook?
by Matt DeVillier Dec. 14, 2023

Dec. 14, 2023

On Thu, Dec 14, 2023 at 6:07 PM James Feeney <james(a)nurealm.net> wrote: > > To get it to update values to new default settings, run: > > make savedefconfig && make defconfig KBUILD_DEFCONFIG=${PWD}/defconfig > > The Kconfig in coreboot document is written with developers writing > Kconfig files in mind, but it's got a lot of useful information about how > Kconfig works. > > That helps. It's sort of a "process", building a ".config", rather than a > single "make nconfig" and done. > since you're starting with my defconfigs, you don't need to change anything. They are the exact configs I use to build my release firmware and are known/tested working. > > > all this mess is because you're trying to use an existing config rather > than start from my defconfig, which is designed to work with my repo. The > selections are currently guarded appropriately. ADD_FSP_BINARIES only needs > to be selected if not using the 3rdparty/fsp repo (as it's selected by > default there). > > Ah! Ok, I see that now. I'm stumbling-around, trying to understand config > options. It's overwhelming at first. And it requires learning to "trust > the defaults". > you're not trusting the defaults, you're trusting my configs which are used to build working firmware. The defaults are not sane or there wouldn't be a dozen lines in the defconfigs and a handful more in my site-local/Kconfig > > Some config options for a board are "required - don't touch!", and others > really are "optional". I'm getting a sense of which is which, but there > doesn't seem to really be a "config overview" or centralized guidance. And > it's probably different for every different cpu architecture. > indeed, knowing what can/should be changed in many cases requires being a firmware developer with reasonable familiarity with coreboot, the platform, and the board in question > > >> … Hmm - so, if the blob files referenced in site-local/Kconfig are not > extracted from the stock ChromeOS firmware images for GLK boards, and they > are not built from source by coreboot, then where are they from? > > > they're extracted from another coreboot device which uses newer FSP > blobs than the Google ones. Which is why I use the newer headers. > > Aha! Thanks for that. > > Comparing the latest "bluebird" update, > bios-casta.ro-11297-222-0.rw-11297-411-0.bin, from > chromeos_15604.57.0_octopus_recovery_stable-channel_mp-v32.bin, and your > newer FSP blobs, I see: > > $ strings 2023Dec01/fsps.bin |grep octopus|head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r9/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > $ strings 3rdparty/blobs/mainboard/google/octopus/casta/fsps.bin | grep > octopus | head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r8/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > The most recent bios has that "-r9", versus the "-r8". I expect that that > refers to an even newer "release 9" versus a "release 8". And, this "-r9" > should also work with the setting: > CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ > 2.2.3.1" > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. TBF, this is unnecessarily confusing because Intel chose to not publicly release FSP headers/binaries for Geminilake (or Jasperlake). Everything is set correctly in my repo so that a user who clones my repo/submodules and uses my build script will end up with a functional firmware image for a given board. > Is that correct? > > >

1 0

2023-12-13 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org Dec. 14, 2023

Dec. 14, 2023

# 2023-12-13 - coreboot Leadership Meeting Minutes ## Attendees Martin R, Werner Zeh, Christian Walter, Matt DeVillier, Felix Singer, Felix Held, Jay Talbott, Marshall Dawson, Simon Glass, David Hendricks, Maximilian Brune, Jeremy Compostella, Jonathan Hall, Karthik R, Nico H, Mina A, Lean Sheng Tan. ## Open Action Items * 2023-12-13 * Patrick? FelixS?: Look at improving the responsiveness of gerrit. * Swapping issues? * Jenkins taking resources * 504 error code - 500 error code * Same patch pushed twice, same change-ID two different gerrit ids. * Patches showing up as open even after they’re merged * Move coreboot resources off of stefan’s server? * 2023-11-29 * [Open] FelixS: Draft a proof-of-concept proposal to switch to meson. * 2023-11-15 * [Done] Martin: Publish coreboot FAQ https://review.coreboot.org/c/coreboot/+/79441 * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * No progress yet * 2023-10-18 * [Started](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/th… XKVCP3YIFJEE/) MattD and WernerZ: Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * Move to next year. * [On hold] [pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * 2023-10-4 * [Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUg… Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * Not started * 2023-09-20 * [Started](https://review.coreboot.org/c/coreboot/+/78832) Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/78832). * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See [CB:78833](https://review.coreboot.org/c/coreboot/+/78833) for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add [bitfield](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/inte… example to 78833 * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Covered open action items ### [Martin] Present Projects & RFCs list ### [Sheng] Decision for Bootflow on Arm64 Server * As mentioned in previous leadership meeting and a special meeting on 05 Dec 2023, the leadership team will make decision on going forward with the proposal here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3… WM/ * We’re proposing that there are two additional boot flows added to Arm’s document. https://docs.google.com/document/d/1z3fLdUmbOBKvHJfub8ki9YWjuqpK_1PY0H4BWwm… ### Decision * We’re agreeing to change the coreboot codebase to support the modified bootflow, based on the understanding that the standard coreboot arm bootflow will also be included. If that isn’t accepted, we’ll need to revisit this. If Arm agrees to include both boot flows in their document, we will get the patches merged, but we’d like an agreement from them before that’s done. * Nico: The secure monitor is still an issue. That’s not open source. * [Martin] But the secure boot monitor is not part of coreboot or even called by coreboot in the new boot flow. Let’s have a discussion about it, but there are other topics we want to cover in this meeting. ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. * Please take a look and voice opinions. * Some problems: * Makefiles at the directory tips frequently have `ifeq` blocks surrounding the entire contents. https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/… * We probably shouldn’t indent the entire file. * To indent ifeq/ifneq/endif statements inside a target, we need to use spaces instead of tabs. This leads to an ugly mix of spaces and tabs, which can be confusing, and will break the build if it’s done incorrectly. ### [Martin] Cancel the December 27th meeting? * Cancel this! ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * With the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. * Flow: * Propose the idea to the mailing list * Present a draft * Do a small implementation (Qemu or similar) * Present an RFC * Review on mailing list & in leadership meeting. * ??? * Profit??? * Felixs: Start a forum? Replace the mailing list with a forum? * Felixh: We already have the bugtracker - it uses a different login than gerrit, so it’s already problematic to use. Let’s not create another. * Nico: The mailing list is the most accessible method. Everyone can participate well. * Felixs: Just looking at how other open source projects done today open projects on gitlab or github, and people discuss things there. People today are used to that. People don’t like writing emails. Modern solutions look nicer and are more accessible. * SJG: Mailing list is searchable and everything can be seen later. Other things are more of a walled garden. Replacing the mailing list would be a bad decision. * Nico: Forums are accessible only to people able to use a web browser. * This can at least be an example process, if not the only process. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, ~~cbor or protobuf~~)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… for *any* solution * Kconfig [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * Kconfig [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 Now updated to allow use of a CBFS file. * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. # Next meeting * January 10, 2024. * [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 0

Re: coreboot Meetings Announcement And Agenda Call
by Julius Werner Dec. 11, 2023

Dec. 11, 2023

[edit: that was meant to go to the list, too] On Mon, Dec 11, 2023 at 3:12 PM Julius Werner <jwerner(a)chromium.org> wrote: >> >> ### [Simon]: Serial RFC >> * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 >> * Does the -2 indicate that this is being killed? >> * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without >> agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. >> * I’ve already stated numerous times that I don’t think that an option method based solely on >> including the configuration directly into bootblock is the right way to go about things. If we do >> pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, >> which will be far more useful in the long-run, in my opinion. > > > Unfortunately I'll be on a plane this Wednesday and won't be able to join this discussion. Would you mind if we move this to next meeting?

2 2

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Dec. 11, 2023

Dec. 11, 2023

Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023.[1] You are welcome to add things you wish to see addressed during the meeting to the current agenda items. [2] ## Current Agenda Items ### [Martin] Cover open action items ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. ### [Martin] Cancel the December 27th meeting? ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * with the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, cbor or protobuf)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… * [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is. ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

geminilake fsp on Google Chromebook?
by James Feeney Dec. 10, 2023

Dec. 10, 2023

Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=. ./src/soc/intel/apollolake/Kconfig has: config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/" But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"', as might be expected. Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp? Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS? Thanks James

3 4

Need help with porting coreboot.
by bud Dec. 8, 2023

Dec. 8, 2023

Hello, I would like some help with porting coreboot using autoport. I do not understand most of the instructions given in the documentation, for example: "Grab coreboot tree" Which coreboot tree? This one?: git clone ssh://review.coreboot.org:29418/coreboot or this one?: git clone https://review.coreboot.org/coreboot.git Apart from this, I have many other issues with understanding the documentation I would really appreciate it if you could provide step by step instructions with the commands to execute, without any vague instructions from the documentation. Thank you, bud (NOTE: I apologize if my tone of writing sounded rude.)

2 1

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Dec. 8, 2023

Dec. 8, 2023

Dear community, We are happy to announce that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023. [1] Please take a moment to update the current agenda items with matters you wish to see addressed during the meeting. [2] [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

How to add additional LPC decode ranges to Baytrail.
by Jose Trujillo Dec. 8, 2023

Dec. 8, 2023

Hello Dear Community: I am trying to enable UART port addresses 3e8 and 2e8 to one of my 2 superios I have attached to the same LPC port. I need 4 UART ports. Both superio chips work if I set 3f8 and 2f8 but one at the time (i need to disable the other SIO). Today I was looking at baytrail code but I got lost; I did not even find how the code add 3f8/2f8 in order to do the same to 3e8/2e8. i found the function "lpc_open_pmio_window()" but this didn't build for me on Baytrail. Do somebody know to to add LPC decode ranges for 3e8 and 2e8 on Baytrail? Please let me know. Jose Trujillo.

1 0

[coreboot - Bug #519] (New) make gconfig - could not find glade file
by James Feeney Dec. 7, 2023

Dec. 7, 2023

Issue #519 has been reported by James Feeney. ---------------------------------------- Bug #519: make gconfig - could not find glade file https://ticket.coreboot.org/issues/519 * Author: James Feeney * Status: New * Priority: Normal * Target version: none * Start date: 2023-12-07 * Affected versions: 4.21 ---------------------------------------- $ git rev-parse HEAD 62c25351c101a3d5c7104aa6fc34e71990478dde Arch Linux make 4.4.1-2 $ make gconfig ... (gconf:825619): libglade-WARNING **: 09:26:11.670: could not find glade file '/sdb/coreboot.main/build/util/kconfig/gconf.glade' ** (gconf:825619): ERROR **: 09:26:11.673: GUI loading failed ! make: *** [build/util/kconfig/Makefile.real:47: gconfig] Trace/breakpoint trap (core dumped) $ find -name gconf.glade ./util/kconfig/gconf.glade $ ll /sdb/coreboot.main/build/util/kconfig/gconf.glade /bin/ls: cannot access '/sdb/coreboot.main/build/util/kconfig/gconf.glade': No such file or directory -- 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 1

[coreboot - Bug #518] (New) make xconfig - g++: fatal error: no input files
by James Feeney Dec. 7, 2023

Dec. 7, 2023

Issue #518 has been reported by James Feeney. ---------------------------------------- Bug #518: make xconfig - g++: fatal error: no input files https://ticket.coreboot.org/issues/518 * Author: James Feeney * Status: New * Priority: Normal * Category: build system * Target version: none * Start date: 2023-12-07 * Affected versions: 4.21 ---------------------------------------- $ git rev-parse HEAD 62c25351c101a3d5c7104aa6fc34e71990478dde Arch Linux make 4.4.1-2 $ make -d xconfig ... Found '/sdb/coreboot.main/util/kconfig/qconf.cc'. ... No implicit rule found for '/sdb/coreboot.main/util/kconfig/qconf.cc'. ... Finished prerequisites of target file 'build/util/kconfig/qconf.o'. Must remake target 'build/util/kconfig/qconf.o'. /sdb/coreboot.main/util/kconfig/Makefile.inc:63: update target 'build/util/kconfig/qconf.o' due to: target does not exist ... g++: fatal error: no input files compilation terminated. ... -- 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

Baytrail issue to communicate with superios.
by Jose Trujillo Dec. 6, 2023

Dec. 6, 2023

Hello All: I hope you are doing great. The system: Baytrail E3845, 4GB DDR3, fintek (f81803a) @0x4e and Winbond (w83627dhg) @0x2e, etc... I just built coreboot (master) the last few days, everything works wonderfully except 2 things: - Libgfxinit probably because this board is using the AUX channel instead DDI to communicate with the monitors; seems to me libgfxinit cannot find monitors thru DP ports but I could be wrong because neither VGA gets initialized; and eventually Linux always initialize the video correctly. - SuperIOs not working; "cat /proc/interrupts" shows not activity from any serial port to any processor, but, I set accordingly (konfig, devicetree and superio.asl) I will check on Monday if the route definitions of "irqroute.h" are ok. Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped all its registries but doesn't show Fintek f81803 because of lack of support, so, data exchange between the processor and the SIO chips via LPC port seems to be fine, maybe just need to fix the interrupt issues. Any help will be highly appreciated, Thank you, JT

2 7

Announcement: flashrom-stable continues as flashprog
by Nico Huber Dec. 6, 2023

Dec. 6, 2023

Hi everybody! as you may know already, flashrom-stable was removed from review.coreboot.org a while ago. flashrom-stable was a short- lived semi-fork, based on flashrom v1.2 [1]. The effort to keep developing a stable flash programming tool for everyone, however, shall continue. I have hence renamed flashrom-stable to *flashprog*. Now it's definitely a fork. The main reason for the fork is that I saw the flashrom master (now main) branch to become unmaintainable. Probably because we merged too much code together, without actually managing to work together on a product. Beside names, I tried to keep everything as usual. There's a wiki (slowly filled with contents from the old one) https://flashprog.org/ an IRC channel #flashprog on libera.chat and a mailing list, of course flashprog(a)flashprog.org managed at https://mail.sourcearcade.org/postorius/lists/flashprog.flashprog.org/ Review continues on a Gerrit instance, albeit on https://review.sourcearcade.org/ And you can clone the repository from a GitHub mirror https://github.com/SourceArcade/flashprog.git Now that all this is done, I hope to return to work on the source code again. There are still many patches open that were pending for flashrom-stable. And it looks like the next release candidate is only one commit away :) So stay tuned! Nico [1] https://mail.coreboot.org/hyperkitty/list/flashrom-stable@flashrom.org/thre…

1 0

Bootflow on ARM64 Server Discussion
by mina＠coreboot.org Dec. 5, 2023

Dec. 5, 2023

Thank you to all who were able to join the discussion pertaining to Bootflow on ARM64 server. Please access the overview of the meeting using the link below: https://docs.google.com/document/d/1z3fLdUmbOBKvHJfub8ki9YWjuqpK_1PY0H4BWwm… .

1 0

Linux boot delayed by value of generic.reset_off_delay_ms (touchscreen reset)?
by Paul Menzel Dec. 5, 2023

Dec. 5, 2023

Dear coreboot folks, On the Dell Latitude 5430 Chromebook (google/brya/var/crota) there is a delay of 160 ms during startup in the Linux kernel [1]: [ 0.000000] microcode: microcode updated early to revision 0x430, date = 2023-06-07 [ 0.000000] Linux version 5.15.124-20281-g306376f9e9db (chrome-bot@chromeos-release-builder-us-central1-c-x32-9-oel9) (Chromium OS 17.0_pre496208_p20230501-r16 clang version 17.0.0 (/mnt/host/source/src/third_party/llvm-project 98f5a340975bc00197c57e39eb4ca26e2da0e8a2), LLD 17.0.0) #1 SMP PREEMPT Mon Oct 2 18:31:36 PDT 2023 […] [ 0.150271] ACPI: PM: Power Resource [PR00] [ 0.313289] ACPI: PM: Power Resource [PR01] A @google.com person commented, that this *could* be caused by the reset delay of the ELAN touchscreen. From `src/third_party/coreboot/src/mainboard/google/brya/variants/crota/overridetree.cb`: device ref i2c3 on chip drivers/i2c/hid register "generic.hid" = ""ELAN900C"" register "generic.desc" = ""ELAN Touchscreen"" register "generic.irq" = "ACPI_IRQ_LEVEL_LOW(GPP_C7_IRQ)" register "generic.detect" = "1" register "generic.reset_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C1)" register "generic.reset_delay_ms" = "150" register "generic.reset_off_delay_ms" = "1" register "generic.enable_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_C0)" register "generic.enable_delay_ms" = "6" register "generic.stop_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C6)" register "generic.stop_off_delay_ms" = "1" register "generic.has_power_resource" = "1" register "hid_desc_reg_offset" = "0x01" device i2c 0x16 on end end end As I have been bitten the last time, I tried to flash a Dell Chromebook, I am weary to test, so I am asking here. > The delay is unavoidable, although I suppose there's room for > improvement on making ACPI power sequencing parallelizable or > otherwise deferring it until the device is actually getting probed > (preferably using asynchronous probe, since this is a slow device -- > ChromeOS tends to configure touchscreen drivers for async probe > already, or else loaded as modules). > > Perhaps you can take this problem upstream if you'd like to work on > something, but from a ChromeOS perspective this is either Intended > Behavior or a Feature Request. I don't think we're interested in > tracking this as a Feature Request here. During startup this reset delay should not hold up the boot, should it? Could the firmware reset the touchscreen, and somehow message the OS, that it’s not needed anymore? Kind regards, Paul [1]: https://issuetracker.google.com/issues/303565666 PS: I was unable to change the issue title to correct PR01 to PR00.

2 1

48 hours before DUG #4 & vPub 0x9 opensource online party!
by Mike Banon Dec. 5, 2023

Dec. 5, 2023

Dear friends, I invite you to a joint DUG #4 & vPub 0x9 event that starts this Thursday at 5 PM UTC - in exactly 48 hours since this e-mail. Would you like to learn & discuss about: * coreboot-based Dasharo firmware distribution and its unique features? * cool hardware devices supporting the opensource firmwares, like NovaCustom new laptop? * opensource firmware world and its current events in general, i.e. AMD OpenSIL news? Then this upcoming event - is an excellent opportunity for you to have a great time in a friendly company of firmware enthusiasts. The 1st part of our event - DUG #4 - is dedicated to Dasharo distribution of coreboot opensource firmware with advanced features like GUI & FLASHBIOS and the ecosystem around it. DUG will take place between 5-7 PM UTC - and then around 7 PM UTC will switch to vPub opensource online party! The past joint events have been highly successful and I'm sure you will find this one interesting as well ;-) Both sound/video and text chats will be available for your convenience More details and Join links are available here - [*] https://vpub.dasharo.com/e/11/dasharo-user-group-4 P.S. to avoid missing out future events, join our Matrix or tiny-volume event notification newsletter: [*] https://matrix.to/#/#dasharo-osf-vpub:matrix.org [*] https://newsletter.3mdeb.com/subscription/0_K65I7ro (just ~4 e-mails per year) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

[coreboot - Bug #516] (New) brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)`
by Paul Menzel Dec. 4, 2023

Dec. 4, 2023

Issue #516 has been reported by Paul Menzel. ---------------------------------------- Bug #516: brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)` https://ticket.coreboot.org/issues/516 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2023-12-02 ---------------------------------------- On the Dell Latitude 5430 Chromebook (brya/var/crota) with ChromeOS, Linux 5.15.133 reports an ACPI error: [ 0.000000] Linux version 5.15.133-20573-g839a3133d611 (chrome-bot@chromeos-release-builder-us-central1-a-x32-6-ibti) (Chromium OS 17.0_pre498229-r6 clang version 17.0.0 (/mnt/host/source/src/third_party/llvm-project 14f0776550b5a49e1c42f49a00213f7f3fa047bf), LLD 17.0.0) #1 SMP PREEMPT Sun Nov 26 18:55:03 PST 2023 2023-12-01T11:43:58.591525Z INFO kernel: [ 0.000000] Command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure drm.trace=0x106 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 6348800 verity payload=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 hashtree=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 hashstart=6348800 alg=sha256 root_hexdigest=4ad313ce4c441485f2be87533efe22a0d8b61bffb78260d17ccd2672e7edb538 salt=8051d68355ccfca99de821939b957ff34d38b866a2951a595e4c0613a1c51f97" noinitrd vt.global_cursor_default=0 kern_guid=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4 add_efi_memmap noresume i915.modeset=1 ramoops.ecc=1 tpm_tis.force=0 intel_pmc_core.warn_on_s0ix_failures=1 i915.enable_guc=3 i915.enable_dc=4 xdomain=0 swiotlb=65536 intel_iommu=on i915.enable_psr=1 […] [ 0.000000] DMI: Google Crota/Crota, BIOS Google_Crota.14505.456.0 04/21/2023 […] [ 0.146114] ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327) [ 0.146117] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20210730/psobject-220) […] -- 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 4