coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Printing u32 on 32-bit and 64-bit without cast
by Paul Menzel 27 May '21

27 May '21

Dear coreboot folks, There is no common length modifier for u32 for “32-bit and 64-bit”. Currently, I am running into problems building `src/cpu/x86/smm/smm_module_loader.c:415:42` with `x86_64-linux-gnu-gcc-10 -m32` [1]. printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n", __func__, stub_params->stack_top - total_stack_size); Using `PRIx32` fixes the build with 64-bit but now it fails with 32-bit, as commit 3a323808 (include, lib: Add <inttypes.h> printf macros) [2] adds src/include/inttypes.h:#define PRIx32 "x" which is dependent on the architecture(?), and is not the right length modifier for u32 on 32-bit. Is there an elegant way around it besides casting the values? Do we need specific headers for 32-bit or 64-bit? Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/54343 [2]: https://review.coreboot.org/c/coreboot/+/33823

2 1

failure cherry-picking patches from https://review.coreboot.org/coreboot
by Bensaid, Selma 26 May '21

26 May '21

Hi, We are observing since 3 days instabilities while cherry-picking patches from coreboot.org: git fetch https://review.coreboot.org/coreboot refs/changes/40/52140/3 && git cherry-pick FETCH_HEAD fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header This is happening on several machines, our automation is also impacted. Any change/issue that could explain such behavior? Thanks, Selma.

3 7

google/sarien (Dell Chromebook): Recovery options
by Paul Menzel 25 May '21

25 May '21

Dear coreboot folks, In a few days I am going to get my hands on a Dell Latitude 5400 Chromebook Enterprise (google/sarien) [1][2], and my goal is to install upstream coreboot on it. According to *Developer Information for Chrome OS Devices* [1], Case Closed Debugging (CCD) [3] is not supported, which is unfortunate, as the flash ROM chip is a WSON-8 package, which I do not have equipment for to flash externally. Do you have some tips what options there are in case of a bad flash? Kind regards, Paul [1]: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… [2]: https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/dell-latitu… [3]: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/c…

2 1

ec/google/wilco: Details on EC firmware
by Paul Menzel 25 May '21

25 May '21

Dear coreboot folks, Some Google Chromebooks come with a Google Wilco EC (EC_GOOGLE_WILCO) instead of Google Chrome EC. coreboot implements the interface for the Google Wilco EC. Unfortunately, I was unable to find more details on the firmware. Phoronix claims is “open-source firmware” [1]. It’d be great if somebody could provide some details. Kind regards, Paul [1]: https://www.phoronix.com/scan.php?page=news_item&px=ChromeOS-Wilco-EC-Linux

2 1

asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
by Branden Waldner 25 May '21

25 May '21

When testing the latest coreboot code before the 4.14 release, I found I couldn't build a working image with the default (or what I usually use) config for the asus/p2b. I figured out that it failed to build with an error of not enough space in cbfs after the merge to enable bootblock console for intel 440bx. Following this, I just disabled microcode firmware to free up space and it worked fine, even without the microcode update. Specifically selecting the microcode for the cpu I'm using would probably be better though. I'm just commenting on my findings, not really expecting anything. I had intended on trying to obtain some larger flash chips yet, though I never got around to it. It would still leave a broken default build config though with the standard rom size.

3 4

Free coreboot training! - and how you can help it
by Mike Banon 20 May '21

20 May '21

This summer, free & open-source OpenSecurityTraining website - will be relaunched as OpenSecurityTraining2 ( https://x.ost.fyi/ ) with even higher quality free training courses! Since Piotr Król volunteered as a content provider for coreboot-related topics, we at 3mdeb developed a new "Architecture 4031: x86-64 Reset Vector Implementation: coreboot" course. And now, we're looking for beta testers for the introductory coreboot class. If you: * learned coreboot elsewhere and willing to provide your expert feedback, * or you are getting started with coreboot and want to learn it faster, - please help us to improve this class! Feel free to share your valuable ideas, and even the fixes for the auto-generated captions will be a huge help. Beta testing will end by mid-June, so - if you're interested in this course, please subscribe by this link to access its' beta version - https://newsletter.3mdeb.com/subscription/23ERA9Fb0 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Debian doesn't boot after firewire card insertion
by d.verdi 19 May '21

19 May '21

Hello, recently I add to my asus kgpe d16 a pci-e to firewire card adapter, a sunix FWB3400T; after that, my Debian distro previously installed doesn't boot anymore, it boot partially but at one point it show "hdaudio no AFG or MFG node found" and then the PC restart itself. I have also installed a Fedora 33, which starts without problem, so does anyone have some suggestion to make Debian boot again? The configuration is this sunix adapter, another sunix to parallel adapter (PAR6408A) and an nvidia quadro P2000 as graphic card; 2 opteron 6282SE and 96 Gb ram of hynix ECC registered memory ( btw, I tried with 128 gb but machine doesn't starts). Thanks a lot Dav Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Supporting different SUPER IO CHips in the Protectli FW6C /devices YANGLINGs you buy from aliexpress
by lain 17 May '21

17 May '21

this code worked for me i am hyped can we make something out of it ?

2 1

Yangling/ FW6C board with different SUPERIO CHIP, I found the problem
by lain 15 May '21

15 May '21

Hello Michal, i found the regarding problem. The board i got from aliexpress has an SUPERIO 8613 insteat of a SUPERIO 8772F, this other superio seem to be support by coreboot but dumbly changing this in the .config seems to fail, do you think you could help me compiling it for this SUPERIO chip ? best regards lain

4 8

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

14 May '21

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. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1453149: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1453149: Uninitialized variables (UNINIT) /tests/lib/spd_cache-test.c: 178 in test_check_if_dimm_changed_sn_error() 172 assert_int_equal(CB_SUCCESS, load_spd_cache(&spd_cache, &spd_cache_sz)); 173 fill_spd_cache_ddr4(spd_cache, spd_cache_sz); 174 assert_int_equal(CB_SUCCESS, spd_fill_from_cache(spd_cache, &blk)); 175 176 /* Simulate error */ 177 will_return_count(get_spd_sn, CB_ERR, 1); >>> CID 1453149: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "blk.addr_map" when calling "check_if_dimm_changed". 178 assert_true(check_if_dimm_changed(spd_cache, &blk)); 179 } 180 181 __attribute__((unused)) 182 static void test_check_if_dimm_changed_sodimm_lost(void **state) 183 { ** CID 1453148: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1453148: Uninitialized variables (UNINIT) /tests/lib/spd_cache-test.c: 162 in test_check_if_dimm_changed_not_changed() 156 fill_spd_cache_ddr4(spd_cache, spd_cache_sz); 157 assert_int_equal(CB_SUCCESS, spd_fill_from_cache(spd_cache, &blk)); 158 159 get_sn_from_spd_cache(spd_cache, get_spd_sn_ret_sn); 160 get_spd_sn_ret_sn_idx = 0; 161 will_return_count(get_spd_sn, CB_SUCCESS, SC_SPD_NUMS); >>> CID 1453148: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "blk.addr_map" when calling "check_if_dimm_changed". 162 assert_false(check_if_dimm_changed(spd_cache, &blk)); 163 } 164 165 __attribute__((unused)) 166 static void test_check_if_dimm_changed_sn_error(void **state) 167 { ** CID 1453147: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1453147: Uninitialized variables (UNINIT) /tests/lib/spd_cache-test.c: 233 in test_check_if_dimm_changed_sn_changed() 227 assert_int_equal(CB_SUCCESS, spd_fill_from_cache(spd_cache, &blk)); 228 get_sn_from_spd_cache(spd_cache, get_spd_sn_ret_sn); 229 *(u32 *)(spd_cache + SC_SPD_OFFSET(0) + DDR4_SPD_SN_OFF) = 0x43211234; 230 231 get_spd_sn_ret_sn_idx = 0; 232 will_return_always(get_spd_sn, CB_SUCCESS); >>> CID 1453147: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "blk.addr_map" when calling "check_if_dimm_changed". 233 assert_true(check_if_dimm_changed(spd_cache, &blk)); 234 } 235 236 int main(void) 237 { 238 const struct CMUnitTest tests[] = { ** CID 1453146: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1453146: Uninitialized variables (UNINIT) /tests/lib/spd_cache-test.c: 196 in test_check_if_dimm_changed_sodimm_lost() 190 assert_int_equal(CB_SUCCESS, spd_fill_from_cache(spd_cache, &blk)); 191 get_sn_from_spd_cache(spd_cache, get_spd_sn_ret_sn); 192 memset(spd_cache + spd_data_ddr4_1_sz, 0xff, spd_data_ddr4_2_sz); 193 194 get_spd_sn_ret_sn_idx = 0; 195 will_return_always(get_spd_sn, CB_SUCCESS); >>> CID 1453146: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "blk.addr_map" when calling "check_if_dimm_changed". 196 assert_true(check_if_dimm_changed(spd_cache, &blk)); 197 } 198 199 __attribute__((unused)) 200 static void test_check_if_dimm_changed_new_sodimm(void **state) 201 { ** CID 1453145: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1453145: Uninitialized variables (UNINIT) /tests/lib/spd_cache-test.c: 215 in test_check_if_dimm_changed_new_sodimm() 209 get_sn_from_spd_cache(spd_cache, get_spd_sn_ret_sn); 210 memcpy(spd_cache + spd_data_ddr4_1_sz + spd_data_ddr4_2_sz, 211 spd_data_ddr4_2, spd_data_ddr4_2_sz); 212 213 get_spd_sn_ret_sn_idx = 0; 214 will_return_always(get_spd_sn, CB_SUCCESS); >>> CID 1453145: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "blk.addr_map" when calling "check_if_dimm_changed". 215 assert_true(check_if_dimm_changed(spd_cache, &blk)); 216 } 217 218 __attribute__((unused)) 219 static void test_check_if_dimm_changed_sn_changed(void **state) 220 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

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