coreboot November 2020

coreboot@coreboot.org

43 participants
36 discussions

A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).

by dponamorev＠gmail.com

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?

1 month

Reserve Device DRAM

by Bryan Angelo

I would appreciate any guidance on the proper way to reserve (arbitrary) DRAM for a MMIO device in coreboot such that the Linux driver for that device is also able to map the reserved DRAM. Based on code inspection, my attempt is to add a cbmem entry via cbmem_alloc and mark that memory as reserved via reserved_ram_resource in the read_resources operation for the device driver. static void foo_read_resources(struct device *dev) { void *buf; const unsigned long size = 0x8000; if (cbmem_entry_find(CBMEM_ID_FOO)) return; buf = cbmem_add(CBMEM_ID_FOO, size); if (!buf) return; reserved_ram_resource(dev, 0, ((unsigned long)buf) >> 10, size >> 10); } I can see that the resource is allocated during resource reading. MMIO: fd110500 resource base *8de82000* size 8000 align 0 gran 0 limit 0 flags f0004200 index 0 I then pass this resource to the linux driver via an ACPI device entry. acpigen_write_name("_CRS"); acpigen_write_resourcetemplate_header(); const struct cbmem_entry *ce = cbmem_entry_find(CBMEM_ID_FOO); if (ce) acpigen_write_mem32fixed(1, (uint32_t)cbmem_entry_start(ce), (uint32_t)cbmem_entry_size(ce)); However, the memory is presented to Linux as "type 16" instead of "reserved" in the physical RAM map. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 [ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000008de34fff] usable *[ 0.000000] BIOS-e820: [mem 0x000000008de35000-0x000000008fffffff] type 16* [ 0.000000] BIOS-e820: [mem 0x0000000090000000-0x00000000cfffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000022f33ffff] usable [ 0.000000] BIOS-e820: [mem 0x000000022f340000-0x000000022fffffff] reserved The e820 type 16 is unknown to the linux kernel, causing it to mark the region as busy. This subsequently causes devm_ioremap_resource to fail when called on the DRAM address from the ACPI device entry. Looking through the code, it seems that coreboot marks the entire cbmem as type 16 in bootmem despite my (improper, it would seem) attempt to mark the ram as reserved. What would be the proper way to reserve (arbitrary) DRAM for a MMIO device such that the memory is marked as reserved in the BIOS physical RAM map? Thanks.

8 months, 3 weeks

[SPECIFICATION RFC] The firmware and bootloader log specification

by Daniel Kiper

Hey, This is next attempt to create firmware and bootloader log specification. Due to high interest among industry it is an extension to the initial bootloader log only specification. It takes into the account most of the comments which I got up until now. The goal is to pass all logs produced by various boot components to the running OS. The OS kernel should expose these logs to the user space and/or process them internally if needed. The content of these logs should be human readable. However, they should also contain the information which allows admins to do e.g. boot time analysis. The log specification should be as much as possible platform agnostic and self contained. The final version of this spec should be merged into existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone spec, e.g. as a part of OASIS Standards. The former seems better but is not perfect too... Here is the description (pseudocode) of the structures which will be used to store the log data. struct bf_log { uint32_t version; char producer[64]; uint64_t flags; uint64_t next_bf_log_addr; uint32_t next_msg_off; bf_log_msg msgs[]; } struct bf_log_msg { uint32_t size; uint64_t ts_nsec; uint32_t level; uint32_t facility; uint32_t msg_off; char strings[]; } The members of struct bf_log: - version: the firmware and bootloader log format version number, 1 for now, - producer: the producer/firmware/bootloader/... type; the length allows ASCII UUID storage if somebody needs that functionality, - flags: it can be used to store information about log state, e.g. it was truncated or not (does it make sense to have an information about the number of lost messages?), - next_bf_log_addr: address of next bf_log struct; none if zero (I think newer spec versions should not change anything in first 5 bf_log members; this way older log parsers will be able to traverse/copy all logs regardless of version used in one log or another), - next_msg_off: the offset, in bytes, from the beginning of the bf_log struct, of the next byte after the last log message in the msgs[]; i.e. the offset of the next available log message slot; it is equal to the total size of the log buffer including the bf_log struct, - msgs: the array of log messages, - should we add CRC or hash or signatures here? The members of struct bf_log_msg: - size: total size of bf_log_msg struct, - ts_nsec: timestamp expressed in nanoseconds starting from 0, - level: similar to syslog meaning; can be used to differentiate normal messages from debug messages; the exact interpretation depends on the current producer type specified in the bf_log.producer, - facility: similar to syslog meaning; can be used to differentiate the sources of the messages, e.g. message produced by networking module; the exact interpretation depends on the current producer type specified in the bf_log.producer, - msg_off: the log message offset in strings[], - strings[0]: the beginning of log message type, similar to the facility member but NUL terminated string instead of integer; this will be used by, e.g., the GRUB2 for messages printed using grub_dprintf(), - strings[msg_off]: the beginning of log message, NUL terminated string. Note: The producers are free to use/ignore any given set of level, facility and/or log type members. Though the usage of these members has to be clearly defined. Ignored integer members should be set to 0. Ignored log message type should contain an empty NUL terminated string. The log message is mandatory but can be an empty NUL terminated string. There is still not fully solved problem how the logs should be presented to the OS. On the UEFI platforms we can use config tables to do that. Then probably bf_log.next_bf_log_addr should not be used. On the ACPI and Device Tree platforms we can use these mechanisms to present the logs to the OSes. The situation gets more difficult if neither of these mechanisms are present. However, maybe we should not bother too much about that because probably these platforms getting less and less common. Anyway, I am aware that this is not specification per se. The goal of this email is to continue the discussion about the idea of the firmware and booloader log and to find out where the final specification should land. Of course taking into the account assumptions made above. You can find previous discussions about related topics at [1], [2] and [3]. Additionally, I am going to present this during GRUB mini-summit session on Tuesday, 17th of November at 15:45 UTC. So, if you want to discuss the log design please join us. You can find more details here [4]. Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00107.html [2] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00079.html [3] https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00223.html [4] https://twitter.com/3mdeb_com/status/1327278804100931587

9 months, 2 weeks

Moving from 4.12 to 4.13 breaks boot

by Andy Pont

Hello, I have migrated my work-in-progress project, adding a new mainboard, from coreboot v4.12 to v4.13 and now the boot using Tianocore is now broken! Under v4.12 it would boot into Ubuntu but under v4.13 it is just putting me at a menu screen with three options: “Default Boot”, “Boot Menu” and “Boot Manager”. If I choose “Boot Menu” it doesn’t list any boot devices. Uisng "Boot Manager” -> “Boot from file” I can navigate into one of the NVMe partitions and down the folders efi/boot/bootx64.efi and that will boot into Ubuntu via the following messages being shown on the screen: System BootOrder not found. Initialising defaults. Creating boot entry “Boot0004” with label “ubuntu” for file “EFI\ubuntu\shimx64.efi” Could not create variable: Device Error When I reboot I just get back to the menu screen. I’m guessing there is a ne option in v4.13 that needs to be set or there is something that has changed v4.12 -> v4.13 but half a day of staring at it hasn’t shown it up. Given the messages are referring to shimx64.efi I guess it is something to do with secure boot. -Andy.

9 months, 4 weeks

Accessing extended capabilities PCI registers?

by Rafael Send

Hi, Breaking this out from my other email for title clarity purposes, hope that's ok. Anyway, I think my issue comes down to coreboot not being able to access (?) PCI extended registers in the current setup. I guess this is a general question: CAN coreboot access the extended capabilities registers of PCI devices? If yes, are there any special options that need to be set or adjusted during the build? I've attached a "pci -i" dump from the EFI shell for my device on stock BIOS vs coreboot - as one can see, the coreboot log ends before outputting any of the extended registers whereas the BIOS log dumps the full config space. Any ideas for what I could try here, or reasons why it might not (be expected to) work? Cheers, R

10 months

Upcoming virtual OSFC 2020

by Philipp Deppenwiese

Hello people, This is a last reminder on the upcoming OSFC 2020 (www.osfc.io) which will start tomorrow noon CET. If you are interested in attending the conference, please get your tickets via https://hopin.com/events/osfc-2020 Best regards, Philipp

10 months

Feature request: add payload "Tianocore with SeaBIOS CSM"

by Volkert

Hi! This is my first post in this mailing list. Nice to meet you all. I have a feature request. (I'm not sure if I'm the first to request this, so feel free to direct me to any existing discussions about this topic, if there is one.) Would it be possible to add a payload option "Tianocore with SeaBIOS CSM" in the config menu? Right now, we have to choose between a Tianocore payload and a SeaBIOS payload, or otherwise provide our own manually built payload. It's possible for SeaBIOS to be built as a Compatibility Support Module (CSM) FOR UEFI BIOSes, and Tianocore can be built with the resulting CSM. However, right now people need to first build SeaBIOS as a CSM, then build Tianocore with the CSM and then add it as a custom ELF executable payload during the "make menuconfig" or "make nconfig" stage of the Coreboot build procedure. Those are quite a few extra error-prone manual steps. It would be really helpful if all these manual steps could be skipped by adding this payload option to the existing payload options and doing all the required intermediate building for us. The vendor BIOS that I wish to replace with Coreboot already contains a UEFI with a CSM, and I'd like to preserve that functionality once I switch to Coreboot. I'm sure I'm not the only one who'd like to have the flexibility of being able to boot both modern OSes through UEFI and legacy OSes using the CSM. Since new UEFI hardware will be shipping without CSMs as of 2020, having this in Coreboot by default would make Coreboot even more attractive to people who'd like to add back such legacy compatibility. Thanks for considering this!

10 months

Change wcaps value through cim_verb_data[]

by Andy Pont

Hello, With the stock BIOS in the board I am working on one of the nodes for the ALC256 CODEC is: Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x02214020: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x02 0x03* In the real world we are finding that the detection of headphones being plugged in aren’t being detected and the audio continues to be played through the onboard speakers. Based on experimentation the customer has determined that the alc256-asus-mic quirk in the Linux kernel gets it work properly but I want to fix this issue properly in Coreboot. The only change in the output of /proc/asound/card/codec#0 appears to be: Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out changes to: Node 0x21 [Pin Complex] wcaps 0x03211020: Stereo Amp-Out I’m assuming that this needs me to add some raw 32bit values into cim_verb_data[] as well as the AZALIA_PIN_CFG() definitions that I already have. Based on what I have seen in files such (src/mainboard/intel/coffeelake_rvp/variants/cml_u/include/variant/hda_verb.h then I guess this is going to be multiple values that will be of the form 0x021xxxxx. How do I convert the change I need to make to fill in the xxxxx values? -Andy.

10 months

Splashscreens

by Andy Pont

Hello, Using the VBT route for graphics initialisation and TianoCore as the payload gives two options within .config for splash screen: CONFIG_BOOTSPLASH: This option shows a graphical bootsplash screen. The graphics are loaded from the CBFS file bootsplash.jpg. CONFIG_TIANOCORE_BOOTSPLASH_IMAGE: Select this option if you have a bootsplash image that you would like to be used. If this option is not selected, the default coreboot logo (European Brown Hare) will used. Do I need to define both? What are the requirements for the images in terms of size, colour depth, etc? -Andy.

10 months

One too many I2C busses

by Andy Pont

Hello all, When I boot my board (Intel Comet Lake based) using Coreboot I have one too many I2C busses compared to the stock AMI BIOS. Using i2cdetect under Ubuntu with the stock BIOS it shows: $ i2cdetect -l i2c-3 unknown i915 gmbus dpc N/A i2c-1 unknown Synopsys DesignWare I2C adapter N/A i2c-6 unknown DPDDC-A N/A i2c-4 unknown i915 gmbus misc N/A i2c-2 unknown i915 gmbus dpb N/A i2c-0 unknown SMBus I801 adapter at efa0 N/A i2c-7 unknown DPDDC-C N/A i2c-5 unknown i915 gmbus dpd N/A When I run the same command having booted using Coreboot then it gives: $ i2cdetect -l i2c-3 unknown i915 gmbus dpb N/A i2c-1 unknown SMBus I801 adapter at efa0 N/A i2c-8 unknown DPDDC-C N/A i2c-6 unknown i915 gmbus dpd N/A i2c-4 unknown i915 gmbus dpc N/A i2c-2 unknown Synopsys DesignWare I2C adapter N/A i2c-0 unknown Synopsys DesignWare I2C adapter N/A i2c-7 unknown DPDDC-A N/A i2c-5 unknown i915 gmbus misc N/A I’m guessing these are controlled by the devices that are configured in the devicetree.cb file. What I have currently that appears to be related to I2C is: register "SerialIoDevMode" = "{ [PchSerialIoIndexI2C0] = PchSerialIoPci, [PchSerialIoIndexI2C1] = PchSerialIoPci, [PchSerialIoIndexI2C2] = PchSerialIoPci, [PchSerialIoIndexI2C3] = PchSerialIoPci, [PchSerialIoIndexI2C4] = PchSerialIoDisabled, [PchSerialIoIndexI2C5] = PchSerialIoDisabled, }” device pci 15.0 on end # I2C #0 device pci 15.1 off end # I2C #1 device pci 15.2 off end # I2C #2 device pci 15.3 off end # I2C #3 device pci 19.0 off end # I2C #4 device pci 19.1 off end # I2C #5 device pci 1f.4 on end # SMBus The definitions of “on” and “off” are based on lspci only reporting PCI devices 15.0 and 1f.4 when Linux is booted using the stock BIOS. -Andy.

10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2020