coreboot August 2020

coreboot@coreboot.org

22 participants
22 discussions

ASAN-related build error at coreboot master
by Mike Banon 21 Aug '20

21 Aug '20

Could be temporarily fixed by changing uintptr_t to unsigned int * : ... GEN build.h CC bootblock/arch/x86/id.o CC bootblock/arch/x86/memcpy.o In file included from src/arch/x86/memcpy.c:5: src/include/asan.h:63:1: error: unknown type name 'uintptr_t'; did you mean 'wint_t'? uintptr_t __asan_shadow_offset(uintptr_t addr); ^~~~~~~~~ wint_t src/include/asan.h:63:32: error: unknown type name 'uintptr_t'; did you mean 'wint_t'? uintptr_t __asan_shadow_offset(uintptr_t addr); ^~~~~~~~~ wint_t cc1: error: unrecognized command line option '-Wno-address-of-packed-member' [-Werror] cc1: all warnings being treated as errors make: *** [Makefile:362: build/bootblock/arch/x86/memcpy.o] Error 1

2 1

Naming convention of register update functions
by Angel Pons 20 Aug '20

20 Aug '20

Dear mailing list, I've been asked in https://review.coreboot.org/42134 to please start a discussion on the mailing list about the naming convention of the functions I've added in said patch. I decided to use `unset_and_set` because that's what libgfxinit uses. In coreboot, we already have `clrsetbits` to operate on memory-mapped addresses. However, `pci_update_config` functions have different semantics, as they take an and-mask instead of an unset-mask. This requires one to use explicit casts to silence spurious overflow warnings if using bitwise negations on shorter-than-int types and the most significant bit is set. Since the added functions operate on bytes, the casts are necessary too often, which clutters the code and suppresses valid overflow warnings. Using an unset-mask solves all these problems, but having `update` in the names of two function families with different semantics would be too cruel. And `clrsetbits` doesn't look too good as a middle `word` in a function name, which is why I went with `unset_and_set` instead. Any thoughts? Best regards, Angel

1 0

kabylake RVP7 coreboot pcie/sata issue
by john brown 20 Aug '20

20 Aug '20

2 1

intel leak hits torrents
by Simon Newton 18 Aug '20

18 Aug '20

https://www.tomshardware.com/news/massive-20gb-intel-data-breach-floods-the… n fact, the title of many of the documents do correlate to the list of purported information posted by the leaker: - Intel ME Bringup guides + (flash) tooling + samples for various platforms - Kabylake (Purley Platform) BIOS Reference Code and Sample Code + Initialization code (some of it as exported git repos with full history) - Intel CEFDK (Consumer Electronics Firmware Development Kit (Bootloader stuff)) SOURCES - Silicon / FSP source code packages for various platforms - Various Intel Development and Debugging Tools - Simics Simulation for Rocket Lake S and potentially other platforms - Various roadmaps and other documents - Binaries for Camera drivers Intel made for SpaceX - Schematics, Docs, Tools + Firmware for the unreleased Tiger Lake platform - (very horrible) Kabylake FDK training videos - Intel Trace Hub + decoder files for various Intel ME versions - Elkhart Lake Silicon Reference and Platform Sample Code - Some Verilog stuff for various Xeon Platforms, unsure what it is exactly. - Debug BIOS/TXE builds for various Platforms - Bootguard SDK (encrypted zip) - Intel Snowridge / Snowfish Process Simulator ADK - Various schematics - Intel Marketing Material Templates (InDesign) - Lots of other things -- Kind Regards, Simon Newton E: Simon.newton(a)gmail.com

3 3

Building coreboot for custom design
by Derryl Tauro 18 Aug '20

18 Aug '20

Hi, I have been doing research on building coreboot to a custom design with Intel chipset. I couldn't find an appropriate document for the same. Is there a document available that I have missed? Regards, Derryl Tauro

2 1

New on blogs.coreboot.org: [GSoC] Address Sanitizer, Part 2
by blogs.coreboot.org 17 Aug '20

17 Aug '20

1 0

OS driver access to FW reserved region
by Jonathan Zhang (Infra) 13 Aug '20

13 Aug '20

Hi, FW reserved regions are needed for OS to access FW data such as ACPI APEI (ACPI Platform Error Interface) data. The ACPI APEI data may include previous boot error record (BERT), or error record reported through firmware runtime component (such as SMI handler). Such FW reserved region needs to be: a. Updateable by firmware bootloader or firmware runtime component. b. Updateable by OS drivers (for instance, the Linux ACPI BERT driver needs to be able to grab and clear the record. c. Reserved from being used as normal memory by OS. If I just add BERT memory region through cbmem_add(), I get this OS error message: [ 12.899311] APEI: Can not request [mem 0x75319000-0x7531911b] for APEI BERT registers If I also make this change: diff --git a/src/lib/bootmem.c b/src/lib/bootmem.c index 1fe23c2828..721d74ac75 100644 --- a/src/lib/bootmem.c +++ b/src/lib/bootmem.c @@ -49,7 +49,7 @@ static uint32_t bootmem_to_lb_tag(const enum bootmem_type tag) case BM_MEM_BL31: return LB_MEM_RESERVED; case BM_MEM_TABLE: - return LB_MEM_TABLE; + return LB_MEM_RESERVED; Then it works fine, I get this: [ 12.902253] BERT: Error records from previous boot: [ 12.912270] [Hardware Error]: event severity: fatal [ 12.922288] [Hardware Error]: precise tstamp: 2020-08-13 21:56:18 [ 12.934980] [Hardware Error]: Error 0, type: fatal [ 12.944995] [Hardware Error]: section_type: general processor error [ 12.958227] [Hardware Error]: processor_type: 0, IA32/X64 [ 12.969674] [Hardware Error]: error_type: 0x02 [ 12.979157] [Hardware Error]: TLB error [ 12.987390] [Hardware Error]: version_info: 0x000000000005065a [ 12.999733] [Hardware Error]: processor_id: 0x0000000000000000 So the question is why we need to make memory attribute of cbmem as LB_MEM_TABLE, instead of LB_MEM_RESERVED? Thank you, Jonathan

1 0

[ANNOUNCE] SeaBIOS 1.14.0
by Kevin O'Connor 10 Aug '20

10 Aug '20

The 1.14.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * New virtio MMIO support. Support for finding virtio MMIO devices via an ACPI DSDT parser. Support for handling a large number of virtio devices. * Improved handling of USB keyboards with non-standard packet size. * Improved KVM CPU frequency detection. * Support for PCI mmconfig support on QEMU. * Several bug fixes and code cleanups. For information on obtaining SeaBIOS, please see: http://seabios.org/Download ===== git shortlog -n rel-1.13.0..rel-1.14.0 ===== Gerd Hoffmann (25): boot: cache HALT priority virtio-scsi: skip initializing non-bootable devices nvme: skip initializing non-bootable devices timer: add tsctimer_setfreq() kvm: detect unconditionally kvm: add support for reading tsc frequency via cpuid. kvm: add support for reading tsc frequency from kvmclock sercon: vbe modeset is int 10h function 4f02 not 4f00 pci: factor out ioconfig_cmd() pci: add mmconfig support qemu: factor out qemu_cfg_detect() qemu: rework e820 detection qemu: check rtc presence before reading cpu count from cmos virtio-mmio: device probing and initialization. virtio-mmio: add support to vp_*() functions virtio-mmio: add support for scsi devices. virtio-mmio: add support for block devices. virtio-mmio: print device type acpi: add xsdt support acpi: add dsdt parser acpi: skip kbd init if not present acpi: find and register virtio-mmio devices rewrap Makefile lines. pci: fix mmconfig support vga: fix cirrus bios Kevin O'Connor (6): usb-hid: Improve max packet size checking Revert "ps2port: adjust init routine to fix PS/2 keyboard issues" boot: Fixup check for only one item in boot list vgabios: Fix preserve memory flag in handle_1000 ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects docs: Note v1.14.0 release Paul Menzel (5): std/tcg: Replace zero-length array with flexible-array member boot: Extend `etc/show-boot-menu` to configure skipping boot menu with only one device boot: Log, if boot menu is skipped cdrom: Demote `scsi_is_ready` return print to debug level nvme: Increase `nvme_cmd_readwrite()` message log level from 3 to 5 Matt DeVillier (4): hw/usb-hid: Don't abort if setting key repeat rate fails Skip boot menu and timeout with only one boot device ps2port: adjust init routine to fix PS/2 keyboard issues boot: Fix logic for boot menu display Stefan Berger (3): tcgbios: Only write logs for PCRs that are in active PCR banks tcgbios: Fix the vendorInfoSize to be of type u8 tcgbios: Add support for SHA3 type of algorithms Alexey Kirillov (2): boot: Detect strict boot order (HALT record) in function virtio: Do not init non-bootable devices Christian Ehrhardt (1): build: use -fcf-protection=none when available Jason Andryuk (1): serialio: Preserve Xen DebugOutputPort Roman Bolshakov (1): timer: Handle decrements of PIT counter Stefan Reiter (1): virtio-scsi: fix boot prio detection by using correct lun

1 0

[GSoC]: Request for testing of "Address Sanitizer" feature
by Harshit Sharma 09 Aug '20

09 Aug '20

Hello everyone, I hope you are staying safe and healthy through these unusual times! Many of you may already know about the project I am working on and the progress we made through my blog post <https://blogs.coreboot.org/blog/2020/07/16/gsoc-address-sanitizer-part-1/>. We had added support for ASan in ramstage for all x86 platforms. In the next phase, to check the boards on which ASan in romstage can be enabled, I ran 'make what-jenkins-does' and build failed only for the boards having either Braswell or i440bx chipsets. So, I am pretty hopeful we can add support for ASan in romstage on all x86 platforms except these two. We have already tested and added support for ASan in romstage on Haswell <https://review.coreboot.org/c/coreboot/+/44160> and Apollolake <https://review.coreboot.org/c/coreboot/+/44159> platforms based on the hardware that Werner and I had access to. I am currently in the final phase of GSoC and before signing off, I want this debugging tool to be available on as many platforms as possible. So, if you have access to a hardware based on an x86 platform (other than Haswell and Apollolake), I would be grateful if you volunteer to test this feature. Please follow these steps if you are willing to test ASan: 1. Pull this change: https://review.coreboot.org/c/coreboot/+/43938 2. Rebuild the toolchain 3. Select 'Address sanitizer support' from the 'General setup' menu 3. Build coreboot 4. Flash the image and run it on your hardware It should boot cleanly and you must see statements prefixed with 'ASan' in your console log in case of both romstage and ramstage. If ASan in romstage works on your hardware, please reply to this thread with the x86 platform name and the name of the board you used, so that I can push a change enabling ASan on that platform. If it gets stuck while booting or you get a compile error while building, please share the log along with the hardware details. We might be able to resolve those errors and add support for ASan on that platform too. Thanking you in advance, Best, Harshit (hst on IRC)

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 07 Aug '20

07 Aug '20

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 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 2 of 2 defect(s) ** CID 1431154: Control flow issues (DEADCODE) /src/ec/kontron/kempld/kempld_i2c.c: 254 in kempld_i2c_device_init() ________________________________________________________________________________________________________ *** CID 1431154: Control flow issues (DEADCODE) /src/ec/kontron/kempld/kempld_i2c.c: 254 in kempld_i2c_device_init() 248 if (spec_major == 1) 249 prescale = KEMPLD_CLK / (KEMPLD_I2C_FREQ_STD * 5) - 1000; 250 else 251 prescale = KEMPLD_CLK / (KEMPLD_I2C_FREQ_STD * 4) - 3000; 252 253 if (prescale < 0) >>> CID 1431154: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "prescale = 0L;". 254 prescale = 0; 255 256 /* Round to the best matching value */ 257 prescale_corr = prescale / 1000; 258 if (prescale % 1000 >= 500) 259 prescale_corr++; ** CID 1353302: (OVERRUN) /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 74 in keyboard_raw_drive_column() /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 71 in keyboard_raw_drive_column() /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 66 in keyboard_raw_drive_column() /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 83 in keyboard_raw_drive_column() ________________________________________________________________________________________________________ *** CID 1353302: (OVERRUN) /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 74 in keyboard_raw_drive_column() 68 69 if (out == KEYBOARD_COLUMN_ALL) { 70 /* drive low (clear bit) */ 71 bsrr |= gpio_list[j].mask << 16; 72 } else if (out == KEYBOARD_COLUMN_NONE) { 73 /* put output in hi-Z state (set bit) */ >>> CID 1353302: (OVERRUN) >>> Overrunning array "gpio_list" of 41 16-byte elements at element index 47 (byte offset 767) using index "j" (which evaluates to 47). 74 bsrr |= gpio_list[j].mask; 75 } else if (j - GPIO_KB_OUT00 == out) { 76 /* 77 * Drive specified output low, others => hi-Z. 78 * 79 * To avoid conflict, tri-state all outputs /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 71 in keyboard_raw_drive_column() 65 for (j = GPIO_KB_OUT00; j <= GPIO_KB_OUT12; j++) { 66 if (gpio_list[j].port != kb_out_ports[i]) 67 continue; 68 69 if (out == KEYBOARD_COLUMN_ALL) { 70 /* drive low (clear bit) */ >>> CID 1353302: (OVERRUN) >>> Overrunning array "gpio_list" of 41 16-byte elements at element index 47 (byte offset 767) using index "j" (which evaluates to 47). 71 bsrr |= gpio_list[j].mask << 16; 72 } else if (out == KEYBOARD_COLUMN_NONE) { 73 /* put output in hi-Z state (set bit) */ 74 bsrr |= gpio_list[j].mask; 75 } else if (j - GPIO_KB_OUT00 == out) { 76 /* /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 66 in keyboard_raw_drive_column() 60 61 for (i = 0; i < ARRAY_SIZE(kb_out_ports); i++) { 62 uint32_t bsrr = 0; 63 int j; 64 65 for (j = GPIO_KB_OUT00; j <= GPIO_KB_OUT12; j++) { >>> CID 1353302: (OVERRUN) >>> Overrunning array "gpio_list" of 41 16-byte elements at element index 47 (byte offset 767) using index "j" (which evaluates to 47). 66 if (gpio_list[j].port != kb_out_ports[i]) 67 continue; 68 69 if (out == KEYBOARD_COLUMN_ALL) { 70 /* drive low (clear bit) */ 71 bsrr |= gpio_list[j].mask << 16; /3rdparty/chromeec/chip/stm32/keyboard_raw.c: 83 in keyboard_raw_drive_column() 77 * Drive specified output low, others => hi-Z. 78 * 79 * To avoid conflict, tri-state all outputs 80 * first, then assert specified output. 81 */ 82 keyboard_raw_drive_column(KEYBOARD_COLUMN_NONE); >>> CID 1353302: (OVERRUN) >>> Overrunning array "gpio_list" of 41 16-byte elements at element index 47 (byte offset 767) using index "j" (which evaluates to 47). 83 bsrr |= gpio_list[j].mask << 16; 84 done = 1; 85 break; 86 } 87 } 88 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2020