coreboot April 2021

coreboot@coreboot.org

34 participants
37 discussions

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev 09 Apr '22

09 Apr '22

Hello, Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop. It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe. The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right? Thanks

6 28

TigerLake RVP TCSS init failure
by Michal Zygowski 27 Oct '21

27 Oct '21

Dear coreboot community, I have encountered problem with silicon init on Tiger Lake RVP platform. I managed to resolve previous issues with memory initialization and now hitting an error with TCSS init. The FSP asserts on IOM ready check, which is 0. The configuration has selected CONFIG_USE_INTEL_FSP_MP_INIT (without MP PPI service). When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is selected, then the FSP-S returns smoothly (at least from one of the phases I guess) and resets after clearing MCEs in coreboot's CPU init: CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Setting up local APIC... apic_id: 0x00 done. Turbo is available but hidden Turbo is available and visible CPU #0 initialized Initializing CPU #2 Initializing CPU #6 Initializing CPU #7 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Cl (tutaj następuje reset) Any ideas what may cause these issues? When I clean this up, I will upstream the DDR4 variant of TGL UP3 RVP. -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

6 16

Currently broken devicetrees (was Re: X200 dock has been broken since November 2019)
by Nico Huber 07 Sep '21

07 Sep '21

Hi all, that we had another case of a missing-device-below-chip in a devicetree made me write a patch for `sconfig` [1]. Now that it's checking for the issue, that uncovered a few (31) more cases [2] that need to be fixed before upstream can benefit from the patch. Please help to fix the devicetrees. Note, `sconfig` currently doesn't print the file name of override trees, e.g. when it says SCONFIG mainboard/.../devicetree.cb line 10: end: syntax error that might as well refer to line 10 in an override tree. Nico [1] https://review.coreboot.org/c/coreboot/+/51119 [2] https://qa.coreboot.org/job/coreboot-gerrit/164572/ Failing boards: board.AMD_BILBY board.AMD_CEREME board.AMD_MANDOLIN board.GETAC_P470 board.GOOGLE_BRYA0 board.GOOGLE_FALCO board.GOOGLE_PEPPY board.GOOGLE_WOLF board.KONTRON_BSL6 board.LENOVO_R500 board.LENOVO_T430S board.LENOVO_T431S board.LENOVO_T520 board.LENOVO_T530 board.LENOVO_W530 board.LENOVO_X1 board.LENOVO_X220 board.LENOVO_X220I board.LENOVO_X220_MRC_BIN board.LENOVO_X220_OPTION_TABLE_DEBUG_TPM_EXTENDED_CBFS board.LENOVO_X230 board.LENOVO_X230S board.LENOVO_X230T board.LENOVO_X301 board.LENOVO_X60 board.RODA_RK886EX board.SIEMENS_BOXER26

1 1

A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
by dponamorev＠gmail.com 25 Aug '21

25 Aug '21

Hi! We developed our CRB motherboard on Intel Atom C3538 (4 core) Denverton_NS processor. Faced with the following problem. For part of processors with the same SKU and steping (Atom C3538), lapic #4 in devicetree.cb needed (95%), and for the other part lapic #0 (5%). Intel confirmed that it might be so and that's okay ... Part of devicetree.cb: device cpu_cluster 0 on device lapic 4 on end end If we do not specify lapic id correctly in devicetree.cb, freeBSD OS does not BOOT (Unix like). FreeBSD BOOT log (set lapic #4 in devicetree.cb but need lapic #0): Table 'FACP' at 0x7f768070 Table 'SSDT' at 0x7f768170 Table 'MCFG' at 0x7f7693e0 Table 'APIC' at 0x7f769420 APIC: Found table at 0x7f769420 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 4 ACPI ID 1: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 12 ACPI ID 2: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 16 ACPI ID 3: enabled SMP: Added CPU 16 (AP) MADT: Found CPU APIC ID 24 ACPI ID 4: enabled SMP: Added CPU 24 (AP) Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.3-RELEASE #0 r349754: Fri Jul 5 04:45:24 UTC 2019 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) Table 'FACP' at 0x7f768070 Table 'SSDT' at 0x7f768170 Table 'MCFG' at 0x7f7693e0 Table 'APIC' at 0x7f769420 Table 'HPET' at 0x7f7694a0 ACPI: No SRAT table found PPIM 0: PA=0xa0000, VA=0xffffffff82410000, size=0x10000, mode=0 VT(vga): resolution 640x480 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8226d000. Calibrating TSC clock ... TSC clock: 2100071708 Hz CPU: Intel(R) Atom(TM) CPU C3538 @ 2.10GHz (2100.07-MHz K8-class CPU) Origin="GenuineIntel" Id=0x506f1 Family=0x6 Model=0x5f Stepping=1 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x4ff8ebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x101<LAHF,Prefetch> Structured Extended Features=0x2294e283<FSGSBASE,TSCADJ,SMEP,ERMS,NFPUSG,MPX,PQE,RDSEED,SMAP,CLFLUSHOPT,PROCTRACE,SHA> Structured Extended Features3=0xac000400<MD_CLEAR,IBPB,STIBP,ARCH_CAP,SSBD> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> IA32_ARCH_CAPS=0x69<RDCL_NO,SKIP_L1DFL_VME> VT-x: Basic Features=0xda0400<SMM,INS/OUTS,TRUE> Pin-Based Controls=0xff<ExtINT,NMI,VNMI,PreTmr,PostIntr> Primary Processor Controls=0xfff9fffe<INTWIN,TSCOff,HLT,INVLPG,MWAIT,RDPMC,RDTSC,CR3-LD,CR3-ST,CR8-LD,CR8-ST,TPR,NMIWIN,MOV-DR,IO,IOmap,MTF,MSRmap,MONITOR,PAUSE> Secondary Processor Controls=0x1d6fff<APIC,EPT,DT,RDTSCP,x2APIC,VPID,WBINVD,UG,APIC-reg,VID,PAUSE-loop,RDRAND,VMFUNC,VMCS,XSAVES> Exit Controls=0xda0400<PAT-LD,EFER-SV,PTMR-SV> Entry Controls=0xda0400 EPT Features=0x6334141<XO,PW4,UC,WB,2M,1G,INVEPT,AD,single,all> VPID Features=0xf01<INVVPID,individual,single,all,single-globals> TSC: P-state invariant, performance statistics DTLB: 4k pages, fully associative, 32 entries Data TLB: 4 KBytes pages, 4-way set associative, 512 entries Instruction TLB: 4 KByte pages, fully associative, 48 entries DTLB: 2M/4M Byte pages, 4-way associative, 32 entries L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000002400000 - 0x000000007f74ffff, 2100625408 bytes (512848 pages) 0x0000000100000000 - 0x000000027012efff, 6175256576 bytes (1507631 pages) avail memory = 8220336128 (7839 MB) Table 'FACP' at 0x7f768070 Table 'SSDT' at 0x7f768170 Table 'MCFG' at 0x7f7693e0 Table 'APIC' at 0x7f769420 Table 'HPET' at 0x7f7694a0 ACPI: No DMAR table found Event timer "LAPIC" quality 600 ACPI APIC Table: <COREv4 COREBOOT> WARNING: L1 data cache covers less APIC IDs than a core 0 < 1 Package ID shift: 5 L2 cache ID shift: 2 L1 cache ID shift: 1 Core ID shift: 1 panic: AP #4 (PHY# 0) failed! cpuid = 0 KDB: stack backtrace: #0 0xffffffff80b4c4b7 at kdb_backtrace+0x67 #1 0xffffffff80b054ce at vpanic+0x17e #2 0xffffffff80b05343 at panic+0x43 #3 0xffffffff80f752a4 at native_start_all_aps+0x344 #4 0xffffffff80f74c4f at cpu_mp_start+0x2ef #5 0xffffffff80b5cb76 at mp_start+0xa6 #6 0xffffffff80aa0b48 at mi_startup+0x118 #7 0xffffffff8031202c at btext+0x2c Uptime: 1s Other Linux OS boot but show an incorrect number of cores (5 instead of 4) and offline processor cores appear (see log). Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64) # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 5 On-line CPU(s) list: 0,2-4 Off-line CPU(s) list: 1 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 95 Model name: Intel(R) Atom(TM) CPU C3538 @ 2.10GHz Stepping: 1 CPU MHz: 2097.502 CPU max MHz: 2100.0000 CPU min MHz: 800.0000 BogoMIPS: 4200.00 Virtualization: VT-x L1d cache: 24K L1i cache: 32K L2 cache: 2048K NUMA node0 CPU(s): 0,2-4 What can be done in this situation? How to make a universal version of devicetree.cb?

8 16

[RFC] How should we manage tree-wide changes?
by Patrick Georgi 10 May '21

10 May '21

Hi everybody, In our leadership meeting[1] we discussed how we should deal with tree-wide changes (ranging from "new file header" to "some API is gone now"). The concern was that right now, anything can change at any time, making local development harder. There have been a few ideas but nothing definite yet: One idea was to declare some interfaces (e.g. those used by src/mainboards/**), with varying stability horizons (e.g. "only change right after a release"), or backward compatibility guarantees (although the details still seemed hazy on how that could work in practice.) Another idea brought up was to require that such changes come with documentation and, ideally, migration support in the form of scripts and the like. We had something like this in the past[2] and I created a proposal[3] to establish it as a rule and build a culture around documenting sweeping changes. One doesn't exclude the other, and there may be other approaches on how to make development easier without calcifying our codebase. Or maybe people don't see a problem that needs fixing? In any case, I wanted to bring it up in a larger forum to make sure that we find rough consensus across the community before a decision is made on how to proceed here. Regards, Patrick [1] minutes at https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [2] http://web.archive.org/web/20130315025026/http://www.coreboot.org/Flag_Days [3] https://review.coreboot.org/c/coreboot/+/52576 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

6 21

Default-timings in Designware I2C driver
by Zeh, Werner 10 May '21

10 May '21

Hi everybody. We do have a driver for a widely used I2C-controller from Designware in src/drivers/i2c/designware. It is used across multiple platforms and has a quite good configurability from mainboard side. One can tweak everything needed and make it work with the needed timing easily. Though I stumbled lately across a thing I wouldn't expect the way it is. It is possible to define the speed one needs to operate the I2C bus on in devicetree by setting the .speed-value to one of the supported defines (I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or I2C_SPEED_FAST_ULTRA), e.g.: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD } }" If one just sets the .speed value, the driver will take care about the needed SCL clock rate and set it up to a default value. Yes, these values might be not the best for the current bus load but should at least provide a clock that matches the requested speed. This default values are defined in src/drivers/i2c/designware/dw_i2c.c as follows: /* High and low times in different speed modes (in ns) */ enum { /* SDA Hold Time */ DEFAULT_SDA_HOLD_TIME = 300, /* Standard Speed */ MIN_SS_SCL_HIGHTIME = 4000, MIN_SS_SCL_LOWTIME = 4700, /* Fast Speed */ MIN_FS_SCL_HIGHTIME = 600, MIN_FS_SCL_LOWTIME = 1300, /* Fast Plus Speed */ MIN_FP_SCL_HIGHTIME = 260, MIN_FP_SCL_LOWTIME = 500, /* High Speed */ MIN_HS_SCL_HIGHTIME = 60, MIN_HS_SCL_LOWTIME = 160, }; While these values do match the needed _minimum_ durations for the high and low period of the SCL signal according to the I2C-specification [1], they are not enough for the overall clock cycle to match the requested speed. Let's take standard speed for example: MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 114,943 kHz instead of 100 kHz The same applies to the other speeds as well. As the driver is aware of the clock the IP is clocked with inside the Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. There is code already which computes the needed counter values for high and low period from the provided IP-clock, *LOWTIME and *HIGHTIME in dw_i2c_gen_speed_config(): ... if (speed >= I2C_SPEED_HIGH) { /* High speed */ hcnt_min = MIN_HS_SCL_HIGHTIME; lcnt_min = MIN_HS_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST_PLUS) { /* Fast-Plus speed */ hcnt_min = MIN_FP_SCL_HIGHTIME; lcnt_min = MIN_FP_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST) { /* Fast speed */ hcnt_min = MIN_FS_SCL_HIGHTIME; lcnt_min = MIN_FS_SCL_LOWTIME; } else { /* Standard speed */ hcnt_min = MIN_SS_SCL_HIGHTIME; lcnt_min = MIN_SS_SCL_LOWTIME; } config->speed = speed; config->scl_hcnt = ic_clk * hcnt_min / KHz; config->scl_lcnt = ic_clk * lcnt_min / KHz; config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz; ... I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) to match the needed minimum constraints while still fulfilling the overall clock cycle, e.g. by increasing the HIGHTIME. But I would like to hear other opinions on that. Surely I am not aware of all the use cases out there. And again: These default values can easily be overridden in the devicetree with something like this: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD, .speed_config[0] = { .speed = I2C_SPEED_STANDARD, .scl_lcnt = 664, .scl_hcnt = 657, /*This value is smaller due to the IP adding a count of 8 internally, see [2]*/ .sda_hold = 39 } }, }" But I would expect the driver to do it right in the default configuration. Any input is highly welcome. Werner [1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf [2] https://dokumen.tips/documents/designware-dw-apb-i2c-databook-pudn-designwa…

3 6

ACPI SSDT Help
by Rocky Phagura 07 May '21

07 May '21

Hello, Looking for some recommendations here. I have a situation where I would like to compile ACPI ASL code into its own definition block and load it dynamically based on some features present in the HW. For example, the code below has its own definition block. Today all of the projects in Coreboot seem to be using only 1 definition block (in dsdt.asl) and the whole thing is loaded at once. I'm looking to create a second definition block and load it dynamically. The SSDT table in Coreboot is mostly derived from C code generating asl code. I prefer iasl compile the asl code. The code I have below functions correctly using the SSDT method. My issue is that it doesn't work well with the existing make system. Right now I have to use a 2 step approach. (1) compile the asl code manually, iasl -tc ras.asl (2) compile Coreboot and include the newly generated hex file (iasl generates c code include file, ras.hex) which links with c code that creates an SSDT table at runtime just like all other tables are added (madt, hpet, etc). While the above 2 step process works, its not clean. I think there is a better way and I'm looking for the Coreboot community's help. Any recommendations are welcome. Thank you, DefinitionBlock ( "ras.aml", "SSDT", 2, "Test", "Test", 0x1000 ) { Scope (\_GPE) { //#include <acpi/acpi.h> OperationRegion (PMIO, SystemIO, 0x500, 0xFF) Field (PMIO, ByteAcc, NoLock, Preserve) { Offset(0x34), /* 0x34, SMI/SCI STS*/ , 9, SGCS, 1, /* SWGPE STS BIT */ Offset(0x40), /* 0x40, SMI/SCI_EN*/ , 17, SGPC, 1, /* SWGPE CTRL BIT */ Offset(0x8C), /* 0x8C, General Purpose Event 0 Status [127:96] */ , 2, SGPS, 1, /* SWGPE STATUS */ Offset(0x9C), /* 0x9C, General Purpose Event 0 Enable [127:96] */ , 2, SGPE, 1 /* SWGPE ENABLE */ } Device (RAS) { Name (_HID, EisaId ("PNP0C33")) Name (_UID, 0) Name (_DDN, "RAS Error Device Controller") Store(" Initialized RAS Device PNP0C33", Debug) } Method(_L62, 0) { Store(" SWGPE Method _L62", Debug) Store(0, SGPC) // clear SWGPE enable Store(1, SGPS) // clear SWGPE Status Notify(RAS, 0x80) } } }

2 2

[Survey] Ideal platform for coreboot training?
by Mike Banon 02 May '21

02 May '21

Dear Friends, please share your thoughts to help us at 3mdeb to advance a coreboot project - by participating in this opensource survey of just 7 questions: * Ideal platform for coreboot training? https://corequest.limesurvey.net/274886?lang=en Thank you very much in advance! -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 2

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

30 Apr '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1452766: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 914 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452766: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 914 in acpi_create_einj() 908 einj_smi->trigger_action_table = (u64) (uintptr_t)tat; 909 910 for (i = 0; i < ACTION_COUNT; i++) 911 printk(BIOS_DEBUG, "default_actions[%d].reg.addr is %llx\n", i, 912 default_actions[i].reg.addr); 913 >>> CID 1452766: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "einj" of type "acpi_einj_t *" and argument "4UL /* sizeof (einj) */" to function "memset" is suspicious. 914 memset((void *)einj, 0, sizeof(einj)); 915 916 /* Fill out header fields. */ 917 memcpy(header->signature, "EINJ", 4); 918 memcpy(header->oem_id, OEM_ID, 6); 919 memcpy(header->oem_table_id, ACPI_TABLE_CREATOR, 8); ** CID 1452765: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 810 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452765: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 810 in acpi_create_einj() 804 acpi_einj_trigger_table_t *tat; 805 if (!header) 806 return; 807 808 printk(BIOS_DEBUG, "%s einj_smi = %p\n", __func__, einj_smi); 809 memset(einj_smi, 0, sizeof(acpi_einj_smi_t)); >>> CID 1452765: Incorrect expression (SIZEOF_MISMATCH) >>> Adding "540UL /* sizeof (acpi_einj_smi_t) */" to pointer "einj_smi" of type "acpi_einj_smi_t *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 540 bytes, of the pointed-to type, "acpi_einj_smi_t". Most likely, "sizeof (acpi_einj_smi_t)" is extraneous and should be replaced with 1. 810 tat = (acpi_einj_trigger_table_t *)(einj_smi + sizeof(acpi_einj_smi_t)); 811 tat->header_size = 16; 812 tat->revision = 0; 813 tat->table_size = sizeof(acpi_einj_trigger_table_t) + 814 sizeof(acpi_einj_action_table_t) * actions - 1; 815 tat->entry_count = actions; ** CID 1452764: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 931 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452764: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 931 in acpi_create_einj() 925 inj_header->einj_header_size = sizeof(acpi_injection_header_t); 926 inj_header->entry_count = ACTION_COUNT; 927 928 printk(BIOS_DEBUG, "%s einj->action_table = %p\n", 929 __func__, einj->action_table); 930 memcpy((void *)einj->action_table, (void *)default_actions, sizeof(einj->action_table)); >>> CID 1452764: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "einj" of type "acpi_einj_t *" and argument "4U /* sizeof (einj) */" to function "acpi_checksum" is suspicious. 931 header->checksum = acpi_checksum((void *)einj, sizeof(einj)); 932 } 933 934 void acpi_create_vfct(const struct device *device, 935 acpi_vfct_t *vfct, 936 unsigned long (*acpi_fill_vfct)(const struct device *device, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Dropping the "cbfs master header" file
by Arthur Heymans 30 Apr '21

30 Apr '21

Hi Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs master header" at the bottom of this fmap region and the X86 bootblock has a pointer at 0xFFFFFFFC to it. Other ARCH have a "header pointer" file at the top of that FMAP region pointing to it. Currently this file is only used as an anchor point to use cbfs with walkcbfs_asm on X86 to access cbfs in assembly (before any C code). There are 2 uses for this at the moment: 1) updating microcode on Intel systems that don't feature FIT before setting up CAR 2) finding FSP-T (if FSP_CAR is used) before jumping to it Both the cbfstool and the C coreboot code don't rely on it anymore, so it is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a VBOOT setup don't feature it. Accessing cbfs with walkcbfs_asm breaks hardware based root of trust security mechanisms like Intel bootguard/TXT/CBnT, because no verification or measurement whatsoever happens on either " cbfs master header" of "fsp-t" files. So for instance even if TXT/Bootguard measured or verified FSP-T as an IBB so that it is trusted, an attacker could insert a new cbfs file with the same name, "fsp-t" at a lower address and coreboot will run it anyway. So a static pointer to fsp-t is required. Sidenote/Rant: FSP-T continuously causes such integration problems... Blobs that set up the execution environment are just a very bad idea. So I propose to drop the legacy "cbfs master header" file and adapt the 2 current use cases in the following way: - Reuse the Intel FIT table and implement FIT microcode updates in assembly/software. (I had this working on some point, before I decided to use walkcbfs_asm) - Either fix the location of FSP-T via for instance a Kconfig option or add a pointer to "fsp-t" at a fixed location in the bootblock and have the tooling update the pointer during the build process. I think the Kconfig option is the least amount of work and cbfstool is already overloaded with options and flags, so my preference goes to this. Let me know what you think. Kind regards Arthur Heymans

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2021