coreboot

coreboot@coreboot.org

4 participants
39683 discussions

Start a nNew thread

Re: Look at writing a doc stating what coreboot is
by James Feeney 05 Jan '24

05 Jan '24

1 0

How to build HOB
by Hamit Can Karaca 04 Jan '24

04 Jan '24

Hello I am new with coreboot and I am trying to understand base functionalities. Before coreboot I was using SBL and in SBL we could pass data to payload by building HOBs. I searched the coreboot code to see if there is a BuildHOB function but I couldn't find it. Is there a BuildHOB function in coreboot or does it have a different function which could pass data to payload. (I am using EDK2 as payload) Thanks for the answers.

2 1

Custom Coreboot
by Iu Che 03 Jan '24

03 Jan '24

Hello, I want to ask, is it possible to order coreboot porting from you to any of these laptop models? Lenovo ThinkPad X1 Carbon Gen 5, i7-7600U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 6, i7-8650U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 7, i5-8265U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 8, i5-8350U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 10, i7-1165G7, Iris Xe Graphics Lenovo ThinkPad X1 Carbon Gen 10, i5-1240P, Iris Xe Graphics Lenovo ThinkPad X1 Carbon Gen 11, i7-1360P, Iris Xe Graphics Lenovo ThinkPad T14p Gen 1, i9-13900H, Intel Iris Xe Lenovo ThinkPad T16 Gen 1, i7-1265U, Iris Xe Graphics Lenovo ThinkPad T16 Gen 2, i7-1360P, GeForce MX550 4G Lenovo Legion 5 Pro, i9-13900HX / RTX 4060 Lenovo Legion 7 Pro, i7-13700HX / RTX 4080 Lenovo Legion 7 Pro, i9-13900HX / RTX 4080 Lenovo Legion 7 Pro, i9-13900HX / RTX 4090 If this is possible, how much would such a service cost? The service of physical firmware is not needed, I can do it myself. Thank you!

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 01 Jan '24

01 Jan '24

Issue #121 has been updated by Patrick Rudolph. It looks like returning `PDM_APD_PPD` in get_power_down_mode() also fixes the issue. It matches the previous discoveries that the problem only appears when the package is in higher C-states. get_power_down_mode() seems to be only used when the DRAM is idle/ the package is in high C-states. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1726 * 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

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 31 Dec '23

31 Dec '23

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 28 Dec '23

28 Dec '23

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 24 Dec '23

24 Dec '23

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 24 Dec '23

24 Dec '23

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 24 Dec '23

24 Dec '23

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 21 Dec '23

21 Dec '23

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot