coreboot June 2019

coreboot@coreboot.org

56 participants
49 discussions

How to enable the SMBus0 in coreboot for Intel Atom C2000?
by dponamorev＠gmail.com 11 Jun '19

11 Jun '19

There is motherboard based on the Intel Rangeley Atom C2000 (C2758) series processor. How to enable the SMBus0 in coreboot? If I use OEM BIOS or BIOS from Intel (EDVLCRB1.86B.0048.R00.1508181657_MPK) for mohon peak crb, then I see on the SMBus0 (i2c-1 in Fedora 28) memory DIMM spd (0x50 & 0x52), clock generator (0x69) and other devices. If I use a coreboot based bios for the Mohon peak platform - I do not see any devices on i2c-1. I see an data exchange on the SMBus0 with oscilloscope at boot time only. When I send "i2cdetect -y 1" command in Linux no activity on SMBus0 and no device found.

4 5

New on blogs.coreboot.org: [GSoC] Ghidra firmware utilities, week 3
by blogs.coreboot.org 11 Jun '19

11 Jun '19

1 0

Early kernel Panic linux 4.19 on ASUS KGPE-D16
by Kinky Nekoboi 10 Jun '19

10 Jun '19

Linked bugreports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029 https://bugzilla.kernel.org/show_bug.cgi?id=203855 Kernel Output: Loading Linux 4.19.0-5-amd64 ...Loading Linux 4.19.0-5-amd64 .. . Loading initial ramdisk ...Loading initial ramdisk .. . [ 0.000000] Linux version 4.19.0-5-amd64 (debian-kernel(a)lists.debian.org) (g) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=0 [ 0.000000] random: get_random_u32 called from bsp_init_amd+0x20b/0x2b0 with0 [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point reg' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes,. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000b7d97fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000b7d98000-0x00000000b7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000b8000000-0x00000000bfffafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000bfffb000-0x00000000cfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fcf00000-0x00000000fcf03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000feb00000-0x00000000feb00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000437ffffff] usable [ 0.000000] BIOS-e820: [mem 0x0000000438000000-0x000000043fffffff] reserved [ 0.000000] bootconsole [earlyser0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe36 05/31/2019 [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 2500.121 MHz processor [ 0.010404] AGP: No AGP bridge found [ 0.013881] last_pfn = 0x438000 max_arch_pfn = 0x400000000 [ 0.021404] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT Memory KASLR using RDTSC... [ 0.030856] last_pfn = 0xbfffb max_arch_pfn = 0x400000000 [ 0.042030] Using GB pages for direct mapping [ 0.046429] RAMDISK: [mem 0x3476f000-0x363aefff] [ 0.050877] ACPI: Early table checksum verification disabled [ 0.056563] ACPI: RSDP 0x00000000000F6250 000024 (v02 COREv4) [ 0.062225] ACPI: XSDT 0x00000000B7D990E0 000074 (v01 COREv4 COREBOOT 000000) [ 0.070720] ACPI: FACP 0x00000000B7D9B9A0 0000F4 (v03 COREv4 COREBOOT 000000) [ 0.079213] ACPI: DSDT 0x00000000B7D99280 00271A (v02 COREv4 COREBOOT 000000) [ 0.087704] ACPI: FACS 0x00000000B7D99240 000040 [ 0.092298] ACPI: FACS 0x00000000B7D99240 000040 [ 0.096890] ACPI: SSDT 0x00000000B7D9BAA0 0020F2 (v02 COREv4 COREBOOT 000000) [ 0.105383] ACPI: MCFG 0x00000000B7D9DBA0 00003C (v01 COREv4 COREBOOT 000000) [ 0.113875] ACPI: APIC 0x00000000B7D9DBE0 0000DE (v02 COREv4 COREBOOT 000000) [ 0.122369] ACPI: SRAT 0x00000000B7D9DCC0 0001A8 (v01 COREv4 COREBOOT 000000) [ 0.130862] ACPI: SLIT 0x00000000B7D9DE68 000030 (v01 COREv4 COREBOOT 000000) [ 0.139355] ACPI: SRAT 0x00000000B7D9DEA0 0001A8 (v01 COREv4 COREBOOT 000000) [ 0.147848] ACPI: SLIT 0x00000000B7D9E048 000030 (v01 COREv4 COREBOOT 000000) [ 0.156341] ACPI: IVRS 0x00000000B7D9E080 0000BC (v01 COREv4 COREBOOT 000000) [ 0.164834] ACPI: HPET 0x00000000B7D9E140 000038 (v01 COREv4 COREBOOT 000000) [ 0.173380] SRAT: PXM 0 -> APIC 0x00 -> Node 0 [ 0.177747] SRAT: PXM 0 -> APIC 0x01 -> Node 0 [ 0.182167] SRAT: PXM 0 -> APIC 0x02 -> Node 0 [ 0.186586] SRAT: PXM 0 -> APIC 0x03 -> Node 0 [ 0.191006] SRAT: PXM 0 -> APIC 0x04 -> Node 0 [ 0.195426] SRAT: PXM 0 -> APIC 0x05 -> Node 0 [ 0.199845] SRAT: PXM 0 -> APIC 0x06 -> Node 0 [ 0.204264] SRAT: PXM 0 -> APIC 0x07 -> Node 0 [ 0.208685] SRAT: PXM 1 -> APIC 0x08 -> Node 1 [ 0.213104] SRAT: PXM 1 -> APIC 0x09 -> Node 1 [ 0.217525] SRAT: PXM 1 -> APIC 0x0a -> Node 1 [ 0.221944] SRAT: PXM 1 -> APIC 0x0b -> Node 1 [ 0.226364] SRAT: PXM 1 -> APIC 0x0c -> Node 1 [ 0.230784] SRAT: PXM 1 -> APIC 0x0d -> Node 1 [ 0.235204] SRAT: PXM 1 -> APIC 0x0e -> Node 1 [ 0.239624] SRAT: PXM 1 -> APIC 0x0f -> Node 1 [ 0.244046] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0009ffff] [ 0.250025] ACPI: SRAT: Node 1 PXM 1 [mem 0x00100000-0xbfffffff] [ 0.256004] ACPI: SRAT: Node 1 PXM 1 [mem 0x100000000-0x43fffffff] [ 0.262162] NUMA: Node 1 [mem 0x00100000-0xbfffffff] + [mem 0x100000000-0x43] [ 0.272647] NODE_DATA(1) allocated [mem 0x437ff8000-0x437ffcfff] [ 0.278660] node 0 must be removed before remove section 134 [ 0.284272] Zone ranges: [ 0.286769] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.292922] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.299075] Normal [mem 0x0000000100000000-0x0000000437ffffff] [ 0.305228] Device empty [ 0.308088] Movable zone start for each node [ 0.312335] Early memory node ranges [ 0.315888] node 0: [mem 0x0000000000001000-0x000000000009efff] [ 0.322128] node 1: [mem 0x0000000000100000-0x00000000b7d97fff] [ 0.328368] node 1: [mem 0x00000000b8000000-0x00000000bfffafff] [ 0.334607] node 1: [mem 0x0000000100000000-0x0000000437ffffff] [ 0.340850] Reserved but unavailable: 98 pages [ 0.340852] Initmem setup node 1 [mem 0x0000000000100000-0x0000000437ffffff] [ 0.466889] ACPI: PM-Timer IO Port: 0x820 [ 0.470732] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [ 0.476453] IOAPIC[0]: apic_id 32, version 33, address 0xfec00000, GSI 0-23 [ 0.483376] IOAPIC[1]: apic_id 33, version 33, address 0xfd000000, GSI 24-55 [ 0.490395] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.496721] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [ 0.503224] Using ACPI (MADT) for SMP configuration information [ 0.509114] ACPI: HPET id: 0x43538301 base: 0xfed00000 [ 0.514232] smpboot: Allowing 16 CPUs, 0 hotplug CPUs [ 0.519255] NODE_DATA(0) allocated [mem 0x00093000-0x00097fff] [ 0.525066] Initmem setup node 0 [mem 0x0000000000001000-0x000000000009efff] [ 0.532110] PM: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.538492] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff] [ 0.544905] PM: Registered nosave memory: [mem 0x000a0000-0x000effff] [ 0.551318] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff] [ 0.557733] PM: Registered nosave memory: [mem 0xb7d98000-0xb7ffffff] [ 0.564146] PM: Registered nosave memory: [mem 0xbfffb000-0xcfffffff] [ 0.570558] PM: Registered nosave memory: [mem 0xd0000000-0xfcefffff] [ 0.576971] PM: Registered nosave memory: [mem 0xfcf00000-0xfcf03fff] [ 0.583384] PM: Registered nosave memory: [mem 0xfcf04000-0xfeafffff] [ 0.589797] PM: Registered nosave memory: [mem 0xfeb00000-0xfeb00fff] [ 0.596209] PM: Registered nosave memory: [mem 0xfeb01000-0xfebfffff] [ 0.602622] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.609035] PM: Registered nosave memory: [mem 0xfec01000-0xfecfffff] [ 0.615449] PM: Registered nosave memory: [mem 0xfed00000-0xfed00fff] [ 0.621862] PM: Registered nosave memory: [mem 0xfed01000-0xfed3ffff] [ 0.628275] PM: Registered nosave memory: [mem 0xfed40000-0xfed44fff] [ 0.634688] PM: Registered nosave memory: [mem 0xfed45000-0xffffffff] [ 0.641103] [mem 0xd0000000-0xfcefffff] available for PCI devices [ 0.647167] Booting paravirtualized kernel on bare hardware [ 0.652717] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xfffs [ 0.795517] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:16 nr_n2 [ 0.804648] percpu: Embedded 44 pages/cpu s143256 r8192 d28776 u262144 [ 0.811044] Built 2 zonelists, mobility grouping on. Total pages: 4095761 [ 0.817843] Policy zone: Normal [ 0.820965] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 roo0 [ 0.854959] AGP: Checking aperture... [ 0.866845] AGP: No AGP bridge found [ 0.870252] AGP: Node 0: aperture [bus addr 0xf8000000-0xfbffffff] (64MB) [ 0.877011] AGP: Node 1: aperture [bus addr 0xf8000000-0xfbffffff] (64MB) [ 0.975916] Memory: 16260640K/16643268K available (10252K kernel code, 1242K) [ 0.989765] BUG: unable to handle kernel NULL pointer dereference at 00000000 [ 0.997523] PGD 0 P4D 0 [ 1.000037] Oops: 0002 [#1] SMP NOPTI [ 1.003678] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-5-amd64 #1 Debian3 [ 1.011562] Hardware name: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe369 [ 1.019541] RIP: 0010:_raw_spin_lock+0xc/0x20 [ 1.023869] Code: 01 00 00 75 05 48 89 d8 5b c3 e8 1f f7 9a ff eb f4 66 66 2b [ 1.042588] RSP: 0000:ffffffff91803e08 EFLAGS: 00010046 [ 1.047788] RAX: 0000000000000000 RBX: ffff996c80083d80 RCX: 4132840b73c45ab1 [ 1.054893] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000 [ 1.061999] RBP: ffffffff91803ec8 R08: ffff996c80080000 R09: ffff996c80083d80 [ 1.069107] R10: 0000000000000000 R11: ffff996c80080000 R12: ffffed5880002000 [ 1.076213] R13: 00000000802a0002 R14: 0000000000000001 R15: ffff996c80083c00 [ 1.083320] FS: 0000000000000000(0000) GS:ffff9970a7c00000(0000) knlGS:00000 [ 1.091380] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.097098] CR2: 0000000000000000 CR3: 0000000023c0a000 CR4: 00000000000406b0 [ 1.104206] Call Trace: [ 1.106638] deactivate_slab.isra.71+0x2d2/0x630 [ 1.111232] ? bootstrap+0x1f/0x12c [ 1.114693] ? kmem_cache_alloc+0x1b8/0x1c0 [ 1.118854] bootstrap+0x66/0x12c [ 1.122148] kmem_cache_init+0x8c/0x145 [ 1.125962] start_kernel+0x2a6/0x52c [ 1.129602] secondary_startup_64+0xa4/0xb0 [ 1.133759] Modules linked in: [ 1.136791] CR2: 0000000000000000 [ 1.140094] ---[ end trace a6e00f6a2ecfb185 ]--- [ 1.144679] RIP: 0010:_raw_spin_lock+0xc/0x20 [ 1.149011] Code: 01 00 00 75 05 48 89 d8 5b c3 e8 1f f7 9a ff eb f4 66 66 2b [ 1.167730] RSP: 0000:ffffffff91803e08 EFLAGS: 00010046 [ 1.172929] RAX: 0000000000000000 RBX: ffff996c80083d80 RCX: 4132840b73c45ab1 [ 1.180036] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000 [ 1.187143] RBP: ffffffff91803ec8 R08: ffff996c80080000 R09: ffff996c80083d80 [ 1.194248] R10: 0000000000000000 R11: ffff996c80080000 R12: ffffed5880002000 [ 1.201355] R13: 00000000802a0002 R14: 0000000000000001 R15: ffff996c80083c00 [ 1.208462] FS: 0000000000000000(0000) GS:ffff9970a7c00000(0000) knlGS:00000 [ 1.216520] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.222241] CR2: 0000000000000000 CR3: 0000000023c0a000 CR4: 00000000000406b0 [ 1.229350] Kernel panic - not syncing: Attempted to kill the idle task! [ 1.236028] ---[ end Kernel panic - not syncing: Attempted to kill the idle - [ 1.243910] PANIC: double fault, error_code: 0xffffffff9087cc95 [ 1.249801] CPU: 0 PID: 0 Comm: swapper Tainted: G D 4.19.0-53 [ 1.259073] Hardware name: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe369 [ 1.267048] RIP: 0246:0x10 [ 1.269732] Code: Bad RIP value. [ 1.272939] RSP: 0000:0000000000000000 EFLAGS: ffffffff91803e58 [ 1.278832] RAX: 000000000000004a RBX: ffffffff91813700 RCX: ffffffff9184dda8 [ 1.285938] RDX: 0000000000000000 RSI: 0000000000000096 RDI: 0000000000000046 [ 1.293045] RBP: ffffffff91803ec8 R08: 00000000000000d2 R09: 2d2d2d5d20216b73 [ 1.300151] R10: 74206c6c696b206f R11: 20656c6469206568 R12: 0000000000000000 [ 1.307257] R13: 0000000000000000 R14: 0000000000000009 R15: 0000000000000001 [ 1.314364] FS: 0000000000000000 GS: 0000000000000000 [ 1.319564] Kernel panic - not syncing: Machine halted. [ 1.324770] ---[ end Kernel panic - not syncing: Machine halted. ]---

1 0

"remote: You need 'Create' rights to create new reference" when pushing to Gerrit
by Peter Lemenkov 10 Jun '19

10 Jun '19

Hello All, It seems that after the switch to a new UI some bits were missed in transition. Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap): git review remote: error: branch refs/publish/master/lenovo_z61t_no_ctrl_swap: remote: You need 'Create' rights to create new references. remote: User: lemenkov remote: Contact an administrator to fix the permissions remote: remote: Processing changes: refs: 1 remote: Processing changes: refs: 1, done To ssh://review.coreboot.org:29418/coreboot ! [remote rejected] HEAD -> refs/publish/master/lenovo_z61t_no_ctrl_swap (prohibited by Gerrit: not permitted: create) error: failed to push some refs to 'ssh://lemenkov@review.coreboot.org:29418/coreboot' Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap): I didn't change anything - so I guess the issue is on the Gerrit's side. -- With best regards, Peter Lemenkov.

3 4

Re: MRC cache save/readback failure (SKL/KBL)
by Nico Huber 07 Jun '19

07 Jun '19

Hi Alex, On 07.06.19 08:56, Alex Feinman wrote: > I've checked the upper 16 MB - simply dumped the block at 0xff9f0000 > (0xff000000 is the last 16 MB + MRC cache region offset 0x9f0000 from > the layout file ) where in my image the MRC cache region resides (I can > confirm it's there by dumping the image from flash). The data I read > from the supposed memory mapping is all 0xff. IIRC, you already confirmed with an external programmer that the data is written at this location, right? If the data is there but not memory mapped, maybe that offset isn't covered by the BIOS region in IFD? > > fmd and .config files are attached I didn't spot anything problematic there. But as you don't have CONFIG_VBOOT selected, you could also try a much simpler FMD file or just the automatically generated default, by unsetting CONFIG_FMDFILE. Nico

2 3

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

07 Jun '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 34 new defect(s) introduced to coreboot found with Coverity Scan. 17 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 34 defect(s) ** CID 1401794: Control flow issues (MISSING_BREAK) /3rdparty/vboot/firmware/lib/vboot_ui.c: 266 in vb2_enter_vendor_data_ui() ________________________________________________________________________________________________________ *** CID 1401794: Control flow issues (MISSING_BREAK) /3rdparty/vboot/firmware/lib/vboot_ui.c: 266 in vb2_enter_vendor_data_ui() 260 case VB_KEY_ESC: 261 /* Escape pressed - return to developer screen */ 262 VB2_DEBUG("Vendor Data UI - user pressed Esc: " 263 "exit to Developer screen\n"); 264 data_value[0] = '\0'; 265 return VBERROR_SUCCESS; >>> CID 1401794: Control flow issues (MISSING_BREAK) >>> The case for value "122U" is not terminated by a 'break' statement. 266 case 'a'...'z': 267 key = toupper(key); 268 case '0'...'9': 269 case 'A'...'Z': 270 if ((len > 0 && is_vowel(key)) || 271 len >= VENDOR_DATA_LENGTH) { ** CID 1401793: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/futility/updater.c: 240 in host_get_platform_version() ________________________________________________________________________________________________________ *** CID 1401793: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/futility/updater.c: 240 in host_get_platform_version() 234 /* Result should be 'revN' */ 235 if (strncmp(result, STR_REV, strlen(STR_REV)) == 0) 236 rev = strtol(result + strlen(STR_REV), NULL, 0); 237 DEBUG("Raw data = [%s], parsed version is %d", result, rev); 238 239 free(result); >>> CID 1401793: Insecure data handling (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "rev" used as return value. 240 return rev; 241 } 242 243 /* 244 * A helper function to invoke flashrom(8) command. 245 * Returns 0 if success, non-zero if error. ** CID 1401792: Error handling issues (CHECKED_RETURN) /3rdparty/vboot/futility/updater.c: 99 in updater_create_temp_file() ________________________________________________________________________________________________________ *** CID 1401792: Error handling issues (CHECKED_RETURN) /3rdparty/vboot/futility/updater.c: 99 in updater_create_temp_file() 93 } 94 close(fd); 95 new_temp = (struct tempfile *)malloc(sizeof(*new_temp)); 96 if (new_temp) 97 new_temp->filepath = strdup(new_path); 98 if (!new_temp || !new_temp->filepath) { >>> CID 1401792: Error handling issues (CHECKED_RETURN) >>> Calling "remove(new_path)" without checking return value. This library function may fail and return an error code. 99 remove(new_path); 100 free(new_temp); 101 ERROR("Failed to allocate buffer for new temp file."); 102 return NULL; 103 } 104 DEBUG("Created new temporary file: %s.", new_path); ** CID 1401791: Security best practices violations (SECURE_TEMP) /3rdparty/vboot/futility/updater.c: 89 in updater_create_temp_file() ________________________________________________________________________________________________________ *** CID 1401791: Security best practices violations (SECURE_TEMP) /3rdparty/vboot/futility/updater.c: 89 in updater_create_temp_file() 83 const char *updater_create_temp_file(struct updater_config *cfg) 84 { 85 struct tempfile *new_temp; 86 char new_path[] = P_tmpdir "/fwupdater.XXXXXX"; 87 int fd; 88 >>> CID 1401791: Security best practices violations (SECURE_TEMP) >>> Calling "mkstemp" without securely setting umask first. 89 fd = mkstemp(new_path); 90 if (fd < 0) { 91 ERROR("Failed to create new temp file in %s", new_path); 92 return NULL; 93 } 94 close(fd); ** CID 1401790: (RESOURCE_LEAK) /3rdparty/vboot/futility/cmd_update.c: 137 in do_update() /3rdparty/vboot/futility/cmd_update.c: 178 in do_update() ________________________________________________________________________________________________________ *** CID 1401790: (RESOURCE_LEAK) /3rdparty/vboot/futility/cmd_update.c: 137 in do_update() 131 132 opterr = 0; 133 while ((i = getopt_long(argc, argv, short_opts, long_opts, 0)) != -1) { 134 switch (i) { 135 case 'h': 136 print_help(argc, argv); >>> CID 1401790: (RESOURCE_LEAK) >>> Variable "cfg" going out of scope leaks the storage it points to. 137 return !!errorcnt; 138 case 'd': 139 debugging_enabled = 1; 140 args.verbosity++; 141 break; 142 case 'v': /3rdparty/vboot/futility/cmd_update.c: 178 in do_update() 172 break; 173 case OPT_QUIRKS: 174 args.quirks = optarg; 175 break; 176 case OPT_QUIRKS_LIST: 177 updater_list_config_quirks(cfg); >>> CID 1401790: (RESOURCE_LEAK) >>> Variable "cfg" going out of scope leaks the storage it points to. 178 return 0; 179 case OPT_OUTPUT_DIR: 180 args.output_dir = optarg; 181 break; 182 case OPT_MODEL: 183 args.model = optarg; ** CID 1401789: Error handling issues (CHECKED_RETURN) /3rdparty/vboot/futility/updater.c: 120 in updater_remove_all_temp_files() ________________________________________________________________________________________________________ *** CID 1401789: Error handling issues (CHECKED_RETURN) /3rdparty/vboot/futility/updater.c: 120 in updater_remove_all_temp_files() 114 static void updater_remove_all_temp_files(struct updater_config *cfg) 115 { 116 struct tempfile *tempfiles = cfg->tempfiles; 117 while (tempfiles != NULL) { 118 struct tempfile *target = tempfiles; 119 DEBUG("Remove temporary file: %s.", target->filepath); >>> CID 1401789: Error handling issues (CHECKED_RETURN) >>> Calling "remove(target->filepath)" without checking return value. This library function may fail and return an error code. 120 remove(target->filepath); 121 free(target->filepath); 122 tempfiles = target->next; 123 free(target); 124 } 125 cfg->tempfiles = NULL; ** CID 1390695: (RESOURCE_LEAK) /3rdparty/vboot/host/lib/crossystem.c: 112 in vb2_get_nv_storage() /3rdparty/vboot/host/lib/crossystem.c: 121 in vb2_get_nv_storage() ________________________________________________________________________________________________________ *** CID 1390695: (RESOURCE_LEAK) /3rdparty/vboot/host/lib/crossystem.c: 112 in vb2_get_nv_storage() 106 /* TODO: locking around NV access */ 107 if (!vnc_read) { 108 memset(&cached_ctx, 0, sizeof(cached_ctx)); 109 if (sh && sh->flags & VBSD_NVDATA_V2) 110 cached_ctx.flags |= VB2_CONTEXT_NVDATA_V2; 111 if (0 != vb2_read_nv_storage(&cached_ctx)) >>> CID 1390695: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 112 return -1; 113 vb2_nv_init(&cached_ctx); 114 115 /* TODO: If vnc.raw_changed, attempt to reopen NVRAM for write 116 * and save the new defaults. If we're able to, log. */ 117 /3rdparty/vboot/host/lib/crossystem.c: 121 in vb2_get_nv_storage() 115 /* TODO: If vnc.raw_changed, attempt to reopen NVRAM for write 116 * and save the new defaults. If we're able to, log. */ 117 118 vnc_read = 1; 119 } 120 >>> CID 1390695: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 121 return (int)vb2_nv_get(&cached_ctx, param); 122 } 123 124 int vb2_set_nv_storage(enum vb2_nv_param param, int value) 125 { 126 VbSharedDataHeader* sh = VbSharedDataRead(); ** CID 1390694: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1390694: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/firmware/lib/tpm_lite/tlcl.c: 215 in StartOSAPSession() 209 sizeof(TPM_NONCE)) != VB2_SUCCESS) { 210 return TPM_E_INTERNAL_ERROR; 211 } 212 213 /* Send OSAP command. */ 214 uint8_t response[TPM_LARGE_ENOUGH_COMMAND_SIZE]; >>> CID 1390694: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "cmd.buffer" to a tainted sink. 215 uint32_t result = TlclSendReceive(cmd.buffer, response, 216 sizeof(response)); 217 if (result != TPM_SUCCESS) { 218 return result; 219 } 220 ** CID 1390693: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1390693: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/firmware/lib/tpm_lite/tlcl.c: 1230 in TlclReadPubek() 1224 return TPM_E_INTERNAL_ERROR; 1225 } 1226 1227 /* The response contains the public endorsement key, so use a large 1228 * response buffer. */ 1229 uint8_t response[TPM_LARGE_ENOUGH_COMMAND_SIZE + TPM_RSA_2048_LEN]; >>> CID 1390693: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "cmd.buffer" to a tainted sink. 1230 uint32_t result = TlclSendReceive(cmd.buffer, response, 1231 sizeof(response)); 1232 if (result != TPM_SUCCESS) { 1233 return result; 1234 } 1235 ** CID 1390692: (RESOURCE_LEAK) /3rdparty/vboot/host/lib/crossystem.c: 134 in vb2_set_nv_storage() /3rdparty/vboot/host/lib/crossystem.c: 141 in vb2_set_nv_storage() /3rdparty/vboot/host/lib/crossystem.c: 145 in vb2_set_nv_storage() ________________________________________________________________________________________________________ *** CID 1390692: (RESOURCE_LEAK) /3rdparty/vboot/host/lib/crossystem.c: 134 in vb2_set_nv_storage() 128 129 /* TODO: locking around NV access */ 130 memset(&ctx, 0, sizeof(ctx)); 131 if (sh && sh->flags & VBSD_NVDATA_V2) 132 ctx.flags |= VB2_CONTEXT_NVDATA_V2; 133 if (0 != vb2_read_nv_storage(&ctx)) >>> CID 1390692: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 134 return -1; 135 vb2_nv_init(&ctx); 136 vb2_nv_set(&ctx, param, (uint32_t)value); 137 138 if (ctx.flags & VB2_CONTEXT_NVDATA_CHANGED) { 139 vnc_read = 0; /3rdparty/vboot/host/lib/crossystem.c: 141 in vb2_set_nv_storage() 135 vb2_nv_init(&ctx); 136 vb2_nv_set(&ctx, param, (uint32_t)value); 137 138 if (ctx.flags & VB2_CONTEXT_NVDATA_CHANGED) { 139 vnc_read = 0; 140 if (0 != vb2_write_nv_storage(&ctx)) >>> CID 1390692: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 141 return -1; 142 } 143 144 /* Success */ 145 return 0; 146 } /3rdparty/vboot/host/lib/crossystem.c: 145 in vb2_set_nv_storage() 139 vnc_read = 0; 140 if (0 != vb2_write_nv_storage(&ctx)) 141 return -1; 142 } 143 144 /* Success */ >>> CID 1390692: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 145 return 0; 146 } 147 148 /* 149 * Set a param value, and try to flag it for persistent backup. It's okay if 150 * backup isn't supported (which it isn't, in current designs). It's ** CID 1387030: (RESOURCE_LEAK) /3rdparty/chromeec/util/genvif.c: 520 in gen_vif() /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() ________________________________________________________________________________________________________ *** CID 1387030: (RESOURCE_LEAK) /3rdparty/chromeec/util/genvif.c: 520 in gen_vif() 514 515 /* Write Source PDOs */ 516 for (i = 0; i < src_pdo_cnt; i++) { 517 pwr = write_pdo_to_buf(&buf, src_pdo[i], SRC, i+1); 518 if (pwr < 0) { 519 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 520 return 1; 521 } 522 523 if (pwr > max_power) 524 max_power = pwr; 525 } /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() 544 /* Write Sink PDOs */ 545 for (i = 0; i < pd_snk_pdo_cnt; i++) { 546 pwr = write_pdo_to_buf(&buf, pd_snk_pdo[i], SNK, i+1); 547 548 if (pwr < 0) { 549 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 550 return 1; 551 } 552 553 if (pwr > max_power) 554 max_power = pwr; 555 } /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() 544 /* Write Sink PDOs */ 545 for (i = 0; i < pd_snk_pdo_cnt; i++) { 546 pwr = write_pdo_to_buf(&buf, pd_snk_pdo[i], SNK, i+1); 547 548 if (pwr < 0) { 549 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 550 return 1; 551 } 552 553 if (pwr > max_power) 554 max_power = pwr; 555 } ** CID 1385420: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/region-init.c: 45 in VbGbbReadHWID() ________________________________________________________________________________________________________ *** CID 1385420: Null pointer dereferences (REVERSE_INULL) /3rdparty/vboot/firmware/lib/region-init.c: 45 in VbGbbReadHWID() 39 struct vb2_shared_data *sd = vb2_get_sd(ctx); 40 41 if (!max_size) 42 return VBERROR_INVALID_PARAMETER; 43 *hwid = '\0'; 44 StrnAppend(hwid, "{INVALID}", max_size); >>> CID 1385420: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "ctx" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 45 if (!ctx) 46 return VBERROR_INVALID_GBB; 47 48 if (0 == sd->gbb->hwid_size) { 49 VB2_DEBUG("VbHWID(): invalid hwid size\n"); 50 return VBERROR_SUCCESS; /* oddly enough! */ ** CID 1365395: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1365395: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_bdb.c: 489 in do_verify() 483 fprintf(stderr, 484 "Invalid digest size: %d\n", key_digest_size); 485 goto exit; 486 } 487 } 488 >>> CID 1365395: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "bdb" to a tainted sink. 489 rv = bdb_verify(bdb, bdb_size, key_digest); 490 switch (rv) { 491 case BDB_SUCCESS: 492 fprintf(stderr, "BDB is successfully verified.\n"); 493 break; 494 case BDB_GOOD_OTHER_THAN_KEY: ** CID 1365394: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1365394: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_vbutil_key.c: 128 in do_unpack() 122 printf("Public Key file: %s\n", infile); 123 printf("Algorithm: %u %s\n", pubkey->algorithm, 124 vb2_get_crypto_algorithm_name(pubkey->algorithm)); 125 printf("Key Version: %u\n", pubkey->key_version); 126 printf("Key sha1sum: %s\n", 127 packed_key_sha1_string(pubkey)); >>> CID 1365394: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "pubkey->key_size" to a tainted sink. 128 if (outfile && 129 VB2_SUCCESS != vb2_write_packed_key(outfile, pubkey)) { 130 fprintf(stderr, "butil_key: Error writing key copy\n"); 131 free(pubkey); 132 return 1; 133 } ** CID 1365393: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1365393: (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_bdb.c: 358 in do_resign() 352 struct bdb_key *key = bdb_create_key(bdbkey_pub_filename, 353 bdbkey_version, NULL); 354 if (!key) { 355 fprintf(stderr, "Unable to read BDB key\n"); 356 goto exit; 357 } >>> CID 1365393: (TAINTED_SCALAR) >>> Passing tainted variable "bdb" to a tainted sink. 358 if (install_bdbkey(&bdb, key)) { 359 fprintf(stderr, "Unable to install new BDB key\n"); 360 goto exit; 361 } 362 } 363 /3rdparty/vboot/futility/cmd_bdb.c: 371 in do_resign() 365 struct bdb_key *key = bdb_create_key(datakey_pub_filename, 366 datakey_version, NULL); 367 if (!key) { 368 fprintf(stderr, "Unable to read data key\n"); 369 goto exit; 370 } >>> CID 1365393: (TAINTED_SCALAR) >>> Passing tainted variable "bdb" to a tainted sink. 371 if (install_datakey(&bdb, key)) { 372 fprintf(stderr, "Unable to install new data key\n"); 373 goto exit; 374 } 375 } 376 /3rdparty/vboot/futility/cmd_bdb.c: 446 in do_resign() 440 /* This is not expected. We installed new keys and resigned 441 * BDB but it's still invalid. */ 442 fprintf(stderr, "BDB is resigned but it's invalid: %d\n", rv); 443 goto exit; 444 } 445 >>> CID 1365393: (TAINTED_SCALAR) >>> Passing tainted variable "bdb_size_of(bdb)" to a tainted sink. 446 rv = write_file(bdb_filename, bdb, bdb_size_of(bdb)); 447 if (rv) { 448 fprintf(stderr, "Unable to write BDB.\n"); 449 goto exit; 450 } 451 /3rdparty/vboot/futility/cmd_bdb.c: 391 in do_resign() 385 if (!bdbkey_pri_filename) { 386 fprintf(stderr, "Private BDB key is required but not " 387 "provided.\n"); 388 goto exit; 389 } 390 bdbkey_pri = read_pem(bdbkey_pri_filename); >>> CID 1365393: (TAINTED_SCALAR) >>> Passing tainted variable "bdb" to a tainted sink. 391 rv = bdb_sign_datakey(&bdb, bdbkey_pri); 392 if (rv) { 393 fprintf(stderr, "Failed to resign data key: %d\n", rv); 394 goto exit; 395 } 396 fprintf(stderr, "Data key is resigned.\n"); /3rdparty/vboot/futility/cmd_bdb.c: 446 in do_resign() 440 /* This is not expected. We installed new keys and resigned 441 * BDB but it's still invalid. */ 442 fprintf(stderr, "BDB is resigned but it's invalid: %d\n", rv); 443 goto exit; 444 } 445 >>> CID 1365393: (TAINTED_SCALAR) >>> Passing tainted variable "bdb_size_of(bdb)" to a tainted sink. 446 rv = write_file(bdb_filename, bdb, bdb_size_of(bdb)); 447 if (rv) { 448 fprintf(stderr, "Unable to write BDB.\n"); 449 goto exit; 450 } 451 ** CID 1365392: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1365392: (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_vbutil_keyblock.c: 121 in Pack() 115 "vbutil_keyblock: Invalid --pem_algorithm %" 116 PRIu64 "\n", pem_algorithm); 117 return 1; 118 } 119 if (external_signer) { 120 /* External signing uses the PEM file directly. */ >>> CID 1365392: (TAINTED_SCALAR) >>> Passing tainted variable "data_key->key_size" to a tainted sink. 121 block = vb2_create_keyblock_external(data_key, 122 signprivate_pem, 123 pem_algorithm, 124 flags, 125 external_signer); 126 } else { /3rdparty/vboot/futility/cmd_vbutil_keyblock.c: 135 in Pack() 129 pem_algorithm); 130 if (!signing_key) { 131 fprintf(stderr, "vbutil_keyblock:" 132 " Error reading signing key.\n"); 133 return 1; 134 } >>> CID 1365392: (TAINTED_SCALAR) >>> Passing tainted variable "data_key->key_size" to a tainted sink. 135 block = vb2_create_keyblock(data_key, signing_key, 136 flags); 137 } 138 } else { 139 if (signprivate) { 140 signing_key = vb2_read_private_key(signprivate); /3rdparty/vboot/futility/cmd_vbutil_keyblock.c: 147 in Pack() 141 if (!signing_key) { 142 fprintf(stderr, "vbutil_keyblock:" 143 " Error reading signing key.\n"); 144 return 1; 145 } 146 } >>> CID 1365392: (TAINTED_SCALAR) >>> Passing tainted variable "data_key->key_size" to a tainted sink. 147 block = vb2_create_keyblock(data_key, signing_key, flags); 148 } 149 150 free(data_key); 151 if (signing_key) 152 free(signing_key); ** CID 1365391: (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_vbutil_firmware.c: 159 in do_vblock() ________________________________________________________________________________________________________ *** CID 1365391: (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_vbutil_firmware.c: 159 in do_vblock() 153 /* Write the output file */ 154 FILE *f = fopen(outfile, "wb"); 155 if (!f) { 156 VbExError("Can't open output file %s\n", outfile); 157 goto vblock_cleanup; 158 } >>> CID 1365391: (TAINTED_SCALAR) >>> Passing tainted variable "keyblock->keyblock_size" to a tainted sink. 159 int i = ((1 != fwrite(keyblock, keyblock->keyblock_size, 1, f)) || 160 (1 != fwrite(preamble, preamble->preamble_size, 1, f))); 161 fclose(f); 162 if (i) { 163 VbExError("Can't write output file %s\n", outfile); 164 unlink(outfile); /3rdparty/vboot/futility/cmd_vbutil_firmware.c: 146 in do_vblock() 140 if (!body_sig) { 141 VbExError("Error calculating body signature\n"); 142 goto vblock_cleanup; 143 } 144 145 /* Create preamble */ >>> CID 1365391: (TAINTED_SCALAR) >>> Passing tainted variable "kernel_subkey->key_size" to a tainted sink. 146 preamble = vb2_create_fw_preamble(version, kernel_subkey, body_sig, 147 signing_key, preamble_flags); 148 if (!preamble) { 149 VbExError("Error creating preamble.\n"); 150 goto vblock_cleanup; 151 } ** CID 1365390: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1365390: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/futility/cmd_bdb.c: 133 in do_add() 127 } 128 129 /* Update data header */ 130 data_header->num_hashes++; 131 data_header->signed_size += sizeof(*new_hash); 132 >>> CID 1365390: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "bdb_header->bdb_size" to a tainted sink. 133 rv = write_file(bdb_filename, bdb_header, bdb_header->bdb_size); 134 if (rv) { 135 fprintf(stderr, "Unable to write BDB\n"); 136 goto exit; 137 } 138 ** CID 1365387: (RESOURCE_LEAK) /3rdparty/vboot/futility/cmd_bdb.c: 360 in do_resign() /3rdparty/vboot/futility/cmd_bdb.c: 362 in do_resign() /3rdparty/vboot/futility/cmd_bdb.c: 373 in do_resign() /3rdparty/vboot/futility/cmd_bdb.c: 375 in do_resign() ________________________________________________________________________________________________________ *** CID 1365387: (RESOURCE_LEAK) /3rdparty/vboot/futility/cmd_bdb.c: 360 in do_resign() 354 if (!key) { 355 fprintf(stderr, "Unable to read BDB key\n"); 356 goto exit; 357 } 358 if (install_bdbkey(&bdb, key)) { 359 fprintf(stderr, "Unable to install new BDB key\n"); >>> CID 1365387: (RESOURCE_LEAK) >>> Variable "key" going out of scope leaks the storage it points to. 360 goto exit; 361 } 362 } 363 364 if (datakey_pub_filename) { 365 struct bdb_key *key = bdb_create_key(datakey_pub_filename, /3rdparty/vboot/futility/cmd_bdb.c: 362 in do_resign() 356 goto exit; 357 } 358 if (install_bdbkey(&bdb, key)) { 359 fprintf(stderr, "Unable to install new BDB key\n"); 360 goto exit; 361 } >>> CID 1365387: (RESOURCE_LEAK) >>> Variable "key" going out of scope leaks the storage it points to. 362 } 363 364 if (datakey_pub_filename) { 365 struct bdb_key *key = bdb_create_key(datakey_pub_filename, 366 datakey_version, NULL); 367 if (!key) { /3rdparty/vboot/futility/cmd_bdb.c: 373 in do_resign() 367 if (!key) { 368 fprintf(stderr, "Unable to read data key\n"); 369 goto exit; 370 } 371 if (install_datakey(&bdb, key)) { 372 fprintf(stderr, "Unable to install new data key\n"); >>> CID 1365387: (RESOURCE_LEAK) >>> Variable "key" going out of scope leaks the storage it points to. 373 goto exit; 374 } 375 } 376 377 /* Check validity for the new bdb key */ 378 rv = bdb_verify(bdb, bdb_size_of(bdb), NULL); /3rdparty/vboot/futility/cmd_bdb.c: 375 in do_resign() 369 goto exit; 370 } 371 if (install_datakey(&bdb, key)) { 372 fprintf(stderr, "Unable to install new data key\n"); 373 goto exit; 374 } >>> CID 1365387: (RESOURCE_LEAK) >>> Variable "key" going out of scope leaks the storage it points to. 375 } 376 377 /* Check validity for the new bdb key */ 378 rv = bdb_verify(bdb, bdb_size_of(bdb), NULL); 379 if (rv == BDB_ERROR_HEADER_SIG) { 380 /* This is expected failure if we installed a new BDB key. ** CID 1361273: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361273: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/host/lib21/host_key.c: 230 in vb21_private_key_read() 224 *key_ptr = NULL; 225 226 rv = vb2_read_file(filename, &buf, &size); 227 if (rv) 228 return rv; 229 >>> CID 1361273: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "buf" to a tainted sink. 230 rv = vb21_private_key_unpack(key_ptr, buf, size); 231 232 free(buf); 233 234 return rv; 235 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

MRC cache save/readback failure (SKL/KBL)
by Alex Feinman 07 Jun '19

07 Jun '19

In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is: 1) On first boot the MRC cache is not found (correct). MRC test is done and the MRC cache is saved successfully. If I pull the BIOS image down, I can see valid contents of the MRC cache where they are supposed to be 2) On the second boot MRC verification fails because rdev_mmap does not have .mmap method in the rdev ops. Since this rdev is based on boot_device_rw_nommap, this seems to be both intended and clearly wrong. 3) At this point MRC test is rerun and is written to the flash *without erasing it first* resulting in corrupted data. 4) Next and all subsequent boots result in reading back corrupt header from MRC cache and a failure followed by retrain. I was able to hack it by replacing 3 calls to mmap with readat and adding erase before the MRC update, but clearly it is supposed to work, so what am I missing? The board is fairly close to KBL RVP3 and the changes to coreboot are minimal. FMD file has MRC cache section I'm open to suggestions Alex

2 4

coreboot leadership meeting minutes for June 5
by Martin Roth 06 Jun '19

06 Jun '19

Attendees: ========== Patrick, Matt, Stefan, Arthur, David, Felix, Ron, Philipp, Martin, Michal (3mdeb) Topics: ======= ### New feature enablement with gerrit 3.0? * [https://twitter.com/GerritReview/status/1128687067217768448](https://twitte… jenkins integration in gerrit * [https://twitter.com/vogella/status/1123969623584538624](https://twitter.com… gerritstats * Not urgent - Patrick [will look](https://ticket.coreboot.org/issues/212) at adding these features when he has some time. ### Blog access (syndication of a subset of their own blog posts) for registered [vendors](https://coreboot.org/products.html)/[consultants](https://coreboot… * Maybe with some rules on content, like “must be useful information for non-customers” and “explicit advertisement for services and products only in the last paragraph, at most X words” to avoid becoming a vendor bulletin board (also known as spam trap)? * Stefan approves, David approves, with clear guidelines for the vendors. * 3mdeb is interested, 9esec is interested, Martin to ask Kerry (Silverback), David to ping Eltan * Example that led to this idea: [https://blog.3mdeb.com/2019/2019-05-22-reproducible-builds/](https://blog.3… * “At most 100 words” would be plenty of space for their (in Patrick’s humble opinion) reasonable ad paragraph while avoiding a 500 words article with 25000 words of ads in a single paragraph * Next steps? * Ask the vendors if there’s interest * Who will drive the logistics? * What do we (and the vendors) prefer, direct blog access or syndication from their own blogs? ## Discuss deprecating additional platforms after coreboot 4.11 release. Aside from the FSP platforms, these should mainly platforms that are no longer actively being worked. FSP 1.0 chips * Broadwell DE * David to follow-up with Intel this week. * Rangeley * Baytrail FSP 1.1 chips * Why remove fsp 1.1? It’s maintained, “not too bad”, active developers? * Braswell - Keep this * Arthur says we have C bootblock support * 4 new platforms in flight. * Actively being maintained * Skylake 1.1 (Also has a 2.0 implementation) * Drop Skylake 1.1 in favor of 2.0 * Need to update skylake 1.1 platforms to 2.0 Other Possible chips to remove if not being maintained or used * Via Vx900 * AMD F10 * AMD F12h * soc/samsung/exynos5250 * ti am335x * allwinner/a10? * southbridge/broadcom * southbridge/nvidia * southbridge/amd/amd111 * southbridge/amd/amd8132 Other items relating to platform removal * Announce removal for 4.11 “unless a maintainer shows up”? * What are the requirements on the maintainer? * At least submitting a working board-status quarterly * For now, 'boots to kernel' is a minimum requirement. * Ramp up the requirements for maintainers (because we had folks registering themselves as maintainer only to disappear) * The boots-to-kernel + board-status requirement is only for the boards that are supposed to be removed for 4.11 * Increase the requirements once board-status (or whatever succeeds it) [can track it](https://ticket.coreboot.org/issues/210). No use requiring stuff that we have no systematic way for maintainers to report. * Request specific things for 4.11 release? C_ENVIRONMENT_BOOTBLOCK, NO_CAR_GLOBAL_MIGRATION? (for applicable platforms) * Agreed on announcing this in 4.10 release ### Should we change the version numbering for coreboot releases * After making the 4.11 branch and removing the unused platforms from ToT, should the next release be 5.0? * Do we want to go with a Year-based version numbering scheme instead? 2019.X * “Coreboot 95” (although that would be Caesar Domitian’s release) * Stefan likes version numbers (over year based numbers) * David does too, major.minor versions have useful info * Fall 2019 release plan: * 4.11 release is done (~Oct 2019) * Remove unmaintained platforms * 5.0 release is tagged (~Oct 2019) * Old platforms can continue to be maintained on 4.11 branch * Needs jenkins integration ([build on branch with branch toolchain](https://ticket.coreboot.org/issues/211)) * 5.1 release will be in spring 2020 ### 4.10 release is behind schedule * Patrick hopes for release this week ## Should we add Rust support in coreboot? * Idea is based on Ron’s oreboot project [https://github.com/oreboot/oreboot](https://github.com/oreboot/oreboot) * Ron prefers talking about compiler guards (again) (kidding!) * Needs coreboot toolchain support * What would we use it for? (no answers) (write romrustc) * Maybe too soon to look into this * Stefan would like to see the oreboot project re-implement a base coreboot feature set before pulling it into coreboot. * Rust can give a lot of features for free, but the binaries are definitely bigger. ### Authors file * Martin to write a script to remove copyright lines and add them to the AUTHORS file * This will happen after the 4.10 release ### OSFC * Call for papers - [https://easychair.org/cfp/osfc2019](https://easychair.org/cfp/osfc2019) * Still looking for more submissions * Change submission requirement to paragraph summary * Add draft slides / outline requirement for 1 month after submission * New deadline for submissions is July 1 * Travel subsidies available for speakers if needed * Philipp to post call for papers to coreboot mailing list Public link to coreboot leadership minutes document: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… Anyone interested in joining the leadership meetings in the future can check the calendar on the coreboot website for call-in information. https://coreboot.org/calendar.html The next meeting is Wednesday June 19, 17:00 UTC

1 0

libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS
by Martin Kepplinger 06 Jun '19

06 Jun '19

Hi, Just tested a build using this config: https://github.com/merge/skulls/blob/master/x230/nonfree-defconfig-139b3cef… with a recent coreboot (my master branch HEAD is at 0da3a8a91b soc/intel/baytrail: set default VBIOS filename and PCI ID) When selecting "3" or "4" for the secondary payloads like coreinfo in Seabios, I always hit this: payloads/libpayload/drivers/i8042/keyboard.c: printf("ERROR: Keyboard reset failed ACK: 0x%x\n", ret); I get "ERROR: Keyboard reset failed ACK: 0x1". and I basically have to shutdown. what's wrong? I think commit 7ae606f57f0b3d450ae748141b0e2367041b27d3 Paul? thanks, martin

5 13

How would an open source vgabios work?
by Matt B 05 Jun '19

05 Jun '19

Hello, This is perhaps naive, but it's a question that I've been thinking about for a while. Pretty much all AMD GPUs (both integrated and otherwise, including PCIe cards) rely on vgabios blobs for init and to support the driver(s). From what I've heard, the people writing open source drivers for these GPUs really don't want to deal with the init and modesetting, ect. Does this mean it's more practical to try to make open source versions than to try to eliminate their use outright? If that's the case, it seems like there's insufficient tooling? There's been some stuff about reading and writing of vgabios blobs with flashrom [1] but I haven't heard anything about a compiler or toolchain that can produce them. The closest is the available disassembler [2], which can provide some insight but probably wouldn't be useful for building vgabios blobs from source as part of a coreboot build. (I think there were also some modified radeon drivers for tracing vgabios calls, but I can't find them now) Besides a compiler, what other infrastructure would be needed? Maybe tools for testing and debugging? -------------------------------------------------- A side tangent: One thing realized recently is some versions of the G505s contain slightly different versions of the same rom. It seems my G505s' for example has different LVDS timings that perfectly match the slightly different panel that mine shipped with. [4] I haven't been able to try a "normal" rom with the panel yet, but one theory to be tested is that the proprietary bios is patching the rom with the values from the panel's EDID information. (I tried installing a different panel, but was only met with a temporarily nonfunctional laptop) Assuming it's not the rom modifying itself (do vgabios' have access to EDID information?), would it be correct to supply values from the EDID information to the vgabios build? Or would it be better to have the coreboot's loader patch the tables by parsing the current panel's EDID info? (I've seen comments that coreboot's lack of EDID parsing support also makes native graphics init harder [5]) Does anyone else know of other tooling that's out there? Sincerely, -Matt -------------------------------------------------- [1] https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Patches [2] https://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&num… [3] [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4… [5] https://www.raptorengineering.com/coreboot/kcma-d8-status.php I also came across some other misc stuff: https://www.phoronix.com/scan.php?page=news_item&px=MTQyMTg https://www.nongnu.org/vgabios/ --------------------------------------------------

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2019