coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Start a nNew thread

T480 support
by Даниил Солодов 23 Apr '21

23 Apr '21

Is it planning support Thinkpad T480 model?

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 23 Apr '21

23 Apr '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1452697: Resource leaks (RESOURCE_LEAK) /tests/lib/region_file-test.c: 32 in setup_region_file_test_group() ________________________________________________________________________________________________________ *** CID 1452697: Resource leaks (RESOURCE_LEAK) /tests/lib/region_file-test.c: 32 in setup_region_file_test_group() 26 27 rdev_chain_mem_rw(dev, mem_buffer, REGION_FILE_BUFFER_SIZE); 28 *state = dev; 29 30 clear_region_file(dev); 31 >>> CID 1452697: Resource leaks (RESOURCE_LEAK) >>> Variable "mem_buffer" going out of scope leaks the storage it points to. 32 return 0; 33 } 34 35 static int teardown_region_file_test_group(void **state) 36 { 37 struct region_device *dev = *state; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Bug #305] (New) Thermal sensors on Thinkpad X201 no longer working
by coreboot＠fe80.eu 23 Apr '21

23 Apr '21

Issue #305 has been reported by Stefan Ott. ---------------------------------------- Bug #305: Thermal sensors on Thinkpad X201 no longer working https://ticket.coreboot.org/issues/305 * Author: Stefan Ott * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- The thermal sensors on my Thinkpad are no longer working with the latest version of coreboot. Normally, the values should look like this: # cat /proc/acpi/ibm/thermal temperatures: 68 0 0 0 0 0 0 0 # sensors thinkpad-isa-0000 thinkpad-isa-0000 Adapter: ISA adapter fan1: 3440 RPM temp1: +68.0°C Now they look like this instead: # cat /proc/acpi/ibm/thermal temperatures: -128 0 0 0 0 0 0 0 # sensors thinkpad-isa-0000 thinkpad-isa-0000 Adapter: ISA adapter fan1: 0 RPM temp1: N/A It seems that this patch broke things: https://review.coreboot.org/c/coreboot/+/51072 -- 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

Help compiling image for Thinkpad T60
by cuckoohead＠disroot.org 20 Apr '21

20 Apr '21

I'm following the instructions of the Build HOWTO section of the Coreboot Wiki (https://www.coreboot.org/Build_HOWTO) and I'm having some issues. Following the quote from the wiki "It is worth checking the Supported Motherboards (https://coreboot.org/status/board-status.html) page to see if your mainboard is known to work with a particular version of coreboot. If your board is listed and you want to try a known-working version, click the "upstream tree" link to find the commit hash and then check it out in git:" So I find the commit hash and run: git checkout 87e36c442e33388493f259bfa14db460a4f02753 Which returns the output: warning: unable to rmdir '3rdparty/intel-sec-tools': Directory not empty warning: unable to rmdir '3rdparty/qc_blobs': Directory not empty warning: unable to rmdir '3rdparty/stm': Directory not empty Updating files: 100% (8604/8604), done. M 3rdparty/amd_blobs M 3rdparty/arm-trusted-firmware M 3rdparty/blobs M 3rdparty/chromeec M 3rdparty/fsp M 3rdparty/intel-microcode M 3rdparty/libgfxinit M 3rdparty/libhwbase M 3rdparty/vboot Note: switching to '87e36c442e33388493f259bfa14db460a4f02753'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false If I try to proceed with: git submodule update --checkout I receive the output: fatal: remote error: upload-pack: not our ref 0ac1af437d2cc461b94bd2cdaa195e86dd481d37 Fetched in submodule path '3rdparty/amd_blobs', but it did not contain 0ac1af437d2cc461b94bd2cdaa195e86dd481d37. Direct fetching of that commit failed. I'm not that familiar with git so I apologize if this is a simple problem. Sorry for the spam too, I missclicked the return key.

1 0

Help compiling image for Thinkpad T60
by cuckoohead＠disroot.org 20 Apr '21

20 Apr '21

1 0

Status of Tianocore EDK2 on Coreboot
by Julian Stecklina 19 Apr '21

19 Apr '21

Hello Coreboot Developers! First, I want to say that it is really a joy to work with Coreboot. The code is well-written and of high-quality. :) I'm currently trying to get Tianocore EDK2 running as a Coreboot payload in Qemu and meeting with limited success, though. I have a working configuration for the qemu q35 target. Building it for and running it with the 440fx/piix4 chipset results in the crash below. Is PIIX4 supported with Coreboot/EDK2 or should this configuration be avoided? I also appreciate any pointers in how to debug a situation like this. It looks like the crash happens in EDK2. Is there a way to get an ELF file that objdump understands, so I can see where in EDK2 code this issue originates from? BS: BS_PAYLOAD_LOAD run times (exec / console): 64 / 2 ms Jumping to boot code at 0x008008c0(0x7ff9b000) !!!! X64 Exception Type - 00(#DE - Divide Error) CPU Apic ID - 00000000 !!!! RIP - 000000007F92FAB0, CS - 0000000000000038, RFLAGS - 0000000000000202 RAX - 000000007F938C20, RCX - 000000007F938C20, RDX - 0000000000000008 RBX - 0000000000000008, RSP - 000000007FF4B278, RBP - 000000007FF666E0 RSI - 000000007FF65910, RDI - 0000000000000001 R8 - 000000007FF63480, R9 - 0000000000000038, R10 - 000000007F93CF08 R11 - 000000007FF64F08, R12 - 0000000000000000, R13 - 0000000000000080 R14 - 000000007FF66760, R15 - 000000007FAA9118 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010011, CR2 - 0000000000000000, CR3 - 000000007FC01000 CR4 - 0000000000000228, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007FBED718 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007F93A018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007FF4AED0 !!!! Can't find image information. !!!! Thanks! Julian

5 8

Re: Discrete graphic vbios extraction
by Mike Banon 18 Apr '21

18 Apr '21

Sorry, at the moment I could only suggest to "find" a Windows 7 USB, do a clean install & drivers installation and use this Belkasoft tool according to ultimate VGABIOS extraction writeup - that's if you need it quick. However, if you'll achieve a similar access with Lime, please let us know: it is much better if stuff like this could be done with the opensource software and no Windows hassle. On Fri, Apr 16, 2021 at 10:52 PM Peter Stuge <peter(a)stuge.se> wrote: > > Gian Lorenzo Spisso wrote: > > Thank you so much for your reply. > > > > Indeed, after a bit of research I've stumbled upon Lime which is a kernel > > module allowing the dump of the whole memory which I'm doing right now. > > Oh good, that's worth a try. > > > > Do you have any pointer on how to locate the bit I'm interested in? > > Here's a hex dump of the first 80 bytes of my VGA BIOS: > > 0000000: 55aa 80e9 a9e3 3030 3030 3030 3030 3030 U.....0000000000 > 0000010: 3030 b021 e9a1 2059 4000 e00a 3030 4942 00.!.. Y@...00IB > 0000020: 4d20 5647 4120 436f 6d70 6174 6962 6c65 M VGA Compatible > 0000030: 2042 494f 532e 2003 5b00 6b00 7900 8bc0 BIOS. .[.k.y... > 0000040: 5043 4952 8680 a227 0000 1800 0000 0003 PCIR...'........ > > Bytes 0 and 1, 0x55 and 0xaa, mark the start of the option ROM, > and offsets 0x44-48 (0x86 0x80 0xa2 0x27) contain the PCI ID of the > graphics hardware that this option ROM is for. > > The PCI ID of my graphics hardware is 8086:27a2; note that the two > 16-bit numbers are stored little-endian in the image. > > Searching for this in e.g. a large file again needs some programming, > because the individual bytes (0x55, 0xaa, or the ID bytes) will occur > quite frequently. > > One option might be to first look for some text strings in the > internal VGA option ROM and see if they occur in more locations in > the new memory dump, to then search only those regions manually. > > > > I am alsok wondering, should I make sure my gpu is running since > > its a discrete card for the vbios to be loaded in memory? > > Hm, I think that will depend on the particular hardware design of > your GPU and of your mainboard. The GPU should not be powered down, > because the option ROM is probably only accessible through the GPU. > > > Finally, if the software approach fails, another method may be to look > for the flash chip on the mainboard and read it out with hardware means. > > > Kind regards > > //Peter -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 16 Apr '21

16 Apr '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 17 new defect(s) introduced to coreboot found with Coverity Scan. 1 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 17 of 17 defect(s) ** CID 1452607: Control flow issues (DEADCODE) /src/drivers/elog/elog.c: 798 in elog_init() ________________________________________________________________________________________________________ *** CID 1452607: Control flow issues (DEADCODE) /src/drivers/elog/elog.c: 798 in elog_init() 792 if (elog_find_flash() < 0) 793 return -1; 794 795 elog_size = region_device_sz(&elog_state.nv_dev); 796 mirror_buffer = elog_mirror_buf; 797 if (!mirror_buffer) { >>> CID 1452607: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "ELOG: Unable to ...". 798 printk(BIOS_ERR, "ELOG: Unable to allocate backing store\n"); 799 return -1; 800 } 801 mem_region_device_rw_init(&elog_state.mirror_dev, mirror_buffer, 802 elog_size); 803 ** CID 1452606: Possible Control flow issues (DEADCODE) /src/cpu/intel/common/common_init.c: 62 in set_feature_ctrl_vmx() ________________________________________________________________________________________________________ *** CID 1452606: Possible Control flow issues (DEADCODE) /src/cpu/intel/common/common_init.c: 62 in set_feature_ctrl_vmx() 56 } 57 } 58 } 59 60 wrmsr(IA32_FEATURE_CONTROL, msr); 61 >>> CID 1452606: Possible Control flow issues (DEADCODE) >>> Execution cannot reach the expression ""disabled"" inside this statement: "printk(7, "VMX status: %s\n...". 62 printk(BIOS_DEBUG, "VMX status: %s\n", 63 enable ? "enabled" : "disabled"); 64 } 65 void set_feature_ctrl_lock(void) 66 { 67 msr_t msr; ** CID 1452605: Control flow issues (DEADCODE) /src/drivers/net/atl1e.c: 130 in atl1e_init() ________________________________________________________________________________________________________ *** CID 1452605: Control flow issues (DEADCODE) /src/drivers/net/atl1e.c: 130 in atl1e_init() 124 printk(BIOS_INFO, "atl1e NIC has SPI eeprom, not setting MAC\n"); 125 return; 126 } 127 128 /* Check if the base is invalid */ 129 if (!mem_base) { >>> CID 1452605: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "atl1e: Error can...". 130 printk(BIOS_ERR, "atl1e: Error cant find MEM resource\n"); 131 return; 132 } 133 /* Enable but do not set bus master */ 134 pci_write_config16(dev, PCI_COMMAND, 135 PCI_COMMAND_MEMORY | PCI_COMMAND_IO); ** CID 1452604: Possible Control flow issues (DEADCODE) /src/cpu/intel/common/common_init.c: 93 in set_feature_ctrl_lock() ________________________________________________________________________________________________________ *** CID 1452604: Possible Control flow issues (DEADCODE) /src/cpu/intel/common/common_init.c: 93 in set_feature_ctrl_lock() 87 if (lock) { 88 /* Set lock bit */ 89 msr.lo |= (1 << 0); 90 wrmsr(IA32_FEATURE_CONTROL, msr); 91 } 92 >>> CID 1452604: Possible Control flow issues (DEADCODE) >>> Execution cannot reach the expression ""unlocked"" inside this statement: "printk(7, "IA32_FEATURE_CON...". 93 printk(BIOS_DEBUG, "IA32_FEATURE_CONTROL status: %s\n", 94 lock ? "locked" : "unlocked"); 95 } 96 97 /* 98 * Init cppc_config in a way that's appropriate for Intel ** CID 1452603: Control flow issues (DEADCODE) /src/drivers/i2c/ww_ring/ww_ring.c: 391 in ww_ring_init() ________________________________________________________________________________________________________ *** CID 1452603: Control flow issues (DEADCODE) /src/drivers/i2c/ww_ring/ww_ring.c: 391 in ww_ring_init() 385 ledc->dev_addr = 0; /* Mark disabled. */ 386 } 387 388 printk(BIOS_INFO, "WW_RING: initialized %d out of %d\n", count, i); 389 if (count != i) { 390 if (count) >>> CID 1452603: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "WW_RING: will ke...". 391 printk(BIOS_WARNING, 392 "WW_RING: will keep going anyway\n"); 393 else 394 printk(BIOS_WARNING, 395 "WW_RING: LED ring not present\n"); 396 } ** CID 1452602: Control flow issues (UNREACHABLE) /src/cpu/x86/smm/smm_module_loaderv2.c: 461 in smm_setup_relocation_handler() ________________________________________________________________________________________________________ *** CID 1452602: Control flow issues (UNREACHABLE) /src/cpu/x86/smm/smm_module_loaderv2.c: 461 in smm_setup_relocation_handler() 455 * of concurrent stack users to be CONFIG_MAX_CPUS. */ 456 if (params->num_concurrent_stacks == 0) 457 params->num_concurrent_stacks = CONFIG_MAX_CPUS; 458 459 return smm_module_setup_stub(smram, SMM_DEFAULT_SIZE, 460 params, fxsave_area_relocation, smram); >>> CID 1452602: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "printk(8, "%s: exit\n", <an...". 461 printk(BIOS_SPEW, "%s: exit\n", __func__); 462 } 463 464 /* 465 *The SMM module is placed within the provided region in the following 466 * manner: ** CID 1452601: Control flow issues (DEADCODE) /src/drivers/ipmi/ipmi_fru.c: 43 in ipmi_read_fru() ________________________________________________________________________________________________________ *** CID 1452601: Control flow issues (DEADCODE) /src/drivers/ipmi/ipmi_fru.c: 43 in ipmi_read_fru() 37 ret = ipmi_kcs_message(port, IPMI_NETFN_STORAGE, 0x0, 38 IPMI_READ_FRU_DATA, (const unsigned char *) req, 39 sizeof(*req), (unsigned char *) &rsp, sizeof(rsp)); 40 if (rsp.resp.completion_code == 0x81) { 41 /* Device is busy */ 42 if (retry_count == MAX_FRU_BUSY_RETRY) { >>> CID 1452601: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "IPMI: %s command...". 43 printk(BIOS_ERR, "IPMI: %s command failed, " 44 "device busy timeout\n", __func__); 45 return CB_ERR; 46 } 47 printk(BIOS_ERR, "IPMI: FRU device is busy, " 48 "retry count:%d\n", retry_count); ** CID 1261216: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp_lowlevel.c: 448 in exynos_dp_start_aux_transaction() ________________________________________________________________________________________________________ *** CID 1261216: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp_lowlevel.c: 448 in exynos_dp_start_aux_transaction() 442 443 retry_cnt = 10; 444 while (retry_cnt) { 445 reg = lread32(&dp_regs->int_sta); 446 if (!(reg & RPLY_RECEIV)) { 447 if (retry_cnt == 0) { >>> CID 1261216: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "DP Reply Timeout...". 448 printk(BIOS_ERR, "DP Reply Timeout!!\n"); 449 ret = -1; 450 return ret; 451 } 452 mdelay(1); 453 retry_cnt--; ** CID 1261189: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 243 in tegra_dc_dpaux_read_chunk() ________________________________________________________________________________________________________ *** CID 1261189: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 243 in tegra_dc_dpaux_read_chunk() 237 timeout_retries); 238 /* clear the error bits */ 239 tegra_dpaux_writel(dp, DPAUX_DP_AUXSTAT, 240 *aux_stat); 241 continue; /* retry */ 242 } else { >>> CID 1261189: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "dp: aux read got...". 243 printk(BIOS_ERR, "dp: aux read got error" 244 " (0x%x)\n", *aux_stat); 245 return -1; 246 } 247 } 248 ** CID 1261055: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 145 in tegra_dc_dpaux_write_chunk() ________________________________________________________________________________________________________ *** CID 1261055: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 145 in tegra_dc_dpaux_write_chunk() 139 printk(BIOS_INFO, "dp: aux write retry (0x%x) -- %d\n", 140 *aux_stat, timeout_retries); 141 /* clear the error bits */ 142 tegra_dpaux_writel(dp, DPAUX_DP_AUXSTAT, *aux_stat); 143 continue; 144 } else { >>> CID 1261055: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "dp: aux write go...". 145 printk(BIOS_ERR, "dp: aux write got error (0x%x)\n", 146 *aux_stat); 147 return -1; 148 } 149 } 150 ** CID 1261018: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp.c: 785 in exynos_dp_config_video() ________________________________________________________________________________________________________ *** CID 1261018: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp.c: 785 in exynos_dp_config_video() 779 if (edp_info->video_info.master_mode == 0) { 780 retry_cnt = 10; 781 while (retry_cnt) { 782 ret = exynos_dp_is_slave_video_stream_clock_on(); 783 if (ret != EXYNOS_DP_SUCCESS) { 784 if (retry_cnt == 0) { >>> CID 1261018: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "DP stream_clock_...". 785 printk(BIOS_ERR, "DP stream_clock_on failed\n"); 786 return ret; 787 } 788 retry_cnt--; 789 mdelay(1); 790 } else { ** CID 1260932: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 258 in tegra_dc_dpaux_read_chunk() ________________________________________________________________________________________________________ *** CID 1260932: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 258 in tegra_dc_dpaux_read_chunk() 252 printk(BIOS_INFO, "dp: aux read defer (0x%x) -- %d\n", 253 *aux_stat, defer_retries); 254 /* clear the error bits */ 255 tegra_dpaux_writel(dp, DPAUX_DP_AUXSTAT, *aux_stat); 256 continue; 257 } else { >>> CID 1260932: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(6, "dp: aux read def...". 258 printk(BIOS_INFO, "dp: aux read defer exceeds max retries " 259 "(0x%x)\n", *aux_stat); 260 return -1; 261 } 262 } 263 ** CID 1260909: Control flow issues (DEADCODE) /src/cpu/x86/mp_init.c: 431 in start_aps() ________________________________________________________________________________________________________ *** CID 1260909: Control flow issues (DEADCODE) /src/cpu/x86/mp_init.c: 431 in start_aps() 425 return 0; 426 427 /* The vector is sent as a 4k aligned address in one byte. */ 428 sipi_vector = sipi_vector_location >> 12; 429 430 if (sipi_vector > max_vector_loc) { >>> CID 1260909: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(2, "SIPI vector too ...". 431 printk(BIOS_CRIT, "SIPI vector too large! 0x%08x\n", 432 sipi_vector); 433 return -1; 434 } 435 436 printk(BIOS_DEBUG, "Attempting to start %d APs\n", ap_count); ** CID 1260903: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp.c: 173 in exynos_dp_handle_edid() ________________________________________________________________________________________________________ *** CID 1260903: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp.c: 173 in exynos_dp_handle_edid() 167 while (retry_cnt) { 168 /* Read DPCD 0x0000-0x000b */ 169 ret = exynos_dp_read_bytes_from_dpcd(DPCD_DPCD_REV, 12, 170 buf); 171 if (ret != EXYNOS_DP_SUCCESS) { 172 if (retry_cnt == 0) { >>> CID 1260903: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "DP read_byte_fro...". 173 printk(BIOS_ERR, "DP read_byte_from_dpcd() failed\n"); 174 return ret; 175 } 176 retry_cnt--; 177 } else 178 break; ** CID 1260846: Control flow issues (DEADCODE) /src/soc/intel/braswell/southcluster.c: 109 in write_pci_config_irqs() ________________________________________________________________________________________________________ *** CID 1260846: Control flow issues (DEADCODE) /src/soc/intel/braswell/southcluster.c: 109 in write_pci_config_irqs() 103 uint16_t parent_bdf = 0; 104 uint8_t pirq = 0; 105 uint8_t device_num = 0; 106 const struct soc_irq_route *ir = &global_soc_irq_route; 107 108 if (ir == NULL) { >>> CID 1260846: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "Warning: Can't w...". 109 printk(BIOS_WARNING, "Warning: Can't write PCI IRQ assignments " 110 "because 'global_braswell_irq_route' structure does not exist\n"); 111 return; 112 } 113 114 /* ** CID 1260827: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp_lowlevel.c: 666 in exynos_dp_read_bytes_from_dpcd() ________________________________________________________________________________________________________ *** CID 1260827: Control flow issues (DEADCODE) /src/soc/samsung/exynos5420/dp_lowlevel.c: 666 in exynos_dp_read_bytes_from_dpcd() 660 lwrite32(reg, &dp_regs->aux_ch_ctl1); 661 662 /* Start AUX transaction */ 663 ret = exynos_dp_start_aux_transaction(); 664 if (ret != EXYNOS_DP_SUCCESS) { 665 if (retry_cnt == 0) { >>> CID 1260827: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "DP Aux Transacti...". 666 printk(BIOS_ERR, "DP Aux Transaction failed\n"); 667 return ret; 668 } 669 retry_cnt--; 670 } else 671 break; ** CID 1260783: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 160 in tegra_dc_dpaux_write_chunk() ________________________________________________________________________________________________________ *** CID 1260783: Control flow issues (DEADCODE) /src/soc/nvidia/tegra124/dp.c: 160 in tegra_dc_dpaux_write_chunk() 154 printk(BIOS_INFO, "dp: aux write defer (0x%x) -- %d\n", 155 *aux_stat, defer_retries); 156 /* clear the error bits */ 157 tegra_dpaux_writel(dp, DPAUX_DP_AUXSTAT, *aux_stat); 158 continue; 159 } else { >>> CID 1260783: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "printk(3, "dp: aux write de...". 160 printk(BIOS_ERR, "dp: aux write defer exceeds max retries " 161 "(0x%x)\n", *aux_stat); 162 return -1; 163 } 164 } 165 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Can we get rid of SMMSTORE_IN_CBFS?
by Julius Werner 15 Apr '21

15 Apr '21

As I'm trying to port all existing CBFS uses to the new APIs that support verification, the CONFIG_SMMSTORE_IN_CBFS option is a bit of a problem: It's the only CBFS use case where coreboot is actually trying to write back into CBFS, and thus needs access to the raw flash offsets of files (which is something I'm trying to stop from leaking out of the abstraction). Does anyone still need this? As far as I know it was just a hack invented to backport SMMSTORE onto a Chromebook that couldn't make FMAP changes anymore, and we never ended up using it after all. Anyone still using SMMSTORE today should be putting it in a separate FMAP section. Would anyone mind if I just remove the CBFS option?

5 7

autoport of p8h61-m-lx2 boots + has anyone managed to install Windows on a sandy/Ivy (or Haswell) coreboot desktop system?
by Dave Widyaatmadja 15 Apr '21

15 Apr '21

Hello, the folllowing is probably not the best-worded E-mail ever (especially as someone completely new here even though a laptop I use has been running Coreboot for some time), but I hope it can still be understood anyway and without coming off in a negative way. Tl;DR: 1. Possible new Asus p8h61-m-lx2 port 2. Coreboot + PCI-E dGPU + Windows install how (if someone here has expertise in setting up something like that)? 3. where/how to get i3-2100 vbios? 1. I was tempted by a relatively well-priced p8h61-m-lx2 with the hope of compatibility with the p8h61-m-lx preset, but I couldn't get the p8h61-m-lx2 to work with the p8h61-m-lx's preset, and while I haven't tried the one made for the p8h61-m-lx3 I have run Autoport on the p8h61-m-lx2 and (p.s. I don't really know what I'm doing) after some copying and pasting from the p8h61-m-lx folder and commenting out some of the lines Autoport generated it seems to boot. I think it may be a good idea to upload those Autoport results, but how exactly would I do that? (uploading the entire Coreboot directory complete with the GCC I believe would've been built inside of it along with various binary blobs would probably not be very wise?) I suspect just uploading the src/mainboard/system_manufacturer directory that was generated may be enough (or maybe do a new git clone of coreboot's repository manually 'patching' that with the generated folder plus some renaming and some edits to the relevant Kconfig files and uploading the 'patched' version somewhere?) but perhaps I missed something else Autoport spat out. Working: ps/2 keyboard (in Seabios at least), i3-2100 iGPU with libgfxinit, PCI-E dGPU (booted with nomodeset but my video card doesn't seem to play well with Linux with the default settings regardless of BIOS) either with Graphics initialisation set to none or to the Card's vbios, Ethernet, Sound output to headphones, (probably all) USB ports, USB headers (only tested one at a time but all seem to work), PCI-E USB 3.0 card (only tested in Seabios). Problem: I only had one Sata storage drive connected and it seems only the one SATA port to which it was connected when I ran Autoport worked once Coreboot was installed (ran Autoport at least twice and different ports when Autoport ran seem to have resulted in different operational ports under Coreboot). Untested: Suspend, etc 2. Does anyone have experience of Installing Windows on a desktop Sandy/Ivy Bridge (or perhaps Haswell, using a patch that was never merged notwithstanding) system with coreboot on it (set to use a dGPU's vbios, I don't think Windows' installer can be accessed when booting with libgfxinit)? I'm thinking about trying to install Windows on the system with coreboot present but as coreboot's documentation warned I was met with a BSOD. The closest I seem to have come to a solution is booting that system (with coreboot set to load a vbios blob) into a distro and then using SSDTtime to extract what I believe can be referred to as the ACPI's .aml file, decompiling that with iasl, and then have the result of that replace the dsdt.asl present in the motherboard's directory, and then rebuild coreboot and flash the resulting BIOS. The problem then for me was that while the computer somehow made it to the windows installer without a bluescreen, I couldn't get any input from the keyboard or mouse to work. I'm honestly about out of ideas and ready to give up on that exercise, but I suppose asking here one last time if someone actually has done something like that successfully before actually giving up can't hurt. 3. One idea I haven't properly tested on the p8h61-m-lx2: does someone know where a vbios for the i3-2100 can be obtained? One thing I haven't really tried is installing Windows with the iGPU's vbios (a laptop from that era being able to run windows 10 for me when compiled with the vbios was the reason I thought the entire idea of coreboot + dGPU + Windows should be possible). I've got an i3-2100, how can I get the correct vbios file for it (assuming it would work as well as on the laptop?). I've tried the vbios files from I believe "Driver Revision: https://downloadcenter.intel.com/download/22520/Intel-Graphics-Media-Accele… but none seem to work at all. While the web page implies that it only works with earlier iGPUs the readmes in the actual archive did make a reference to 2nd-gen processors, which kind of gave me hope. Assuming I do manage to make it work with an iGPU vbios, would planning to have Windows be able to use a dGPU be overoptimistic? Thanks in advance for the response.

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