May 2021 - coreboot - mail.coreboot.org

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev April 9, 2022

April 9, 2022

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 Oct. 27, 2021

Oct. 27, 2021

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 Sept. 7, 2021

Sept. 7, 2021

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 Aug. 26, 2021

Aug. 26, 2021

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

Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
by Branden Waldner June 8, 2021

June 8, 2021

On 5/25/21, Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > Dear Branden, > > > Am 22.05.21 um 20:03 schrieb Branden Waldner: >> On 5/21/21, Arthur Heymans <arthur(a)aheymans.xyz> wrote: > >>> Thanks for sharing your findings. The flash is 256K big, which is quite >>> small these days. >>> When building coreboot with default settings but without a payload I >>> find >>> that there is 69K empty space left for payloads. >>> >>> Some future developments I have been working on might give a bit more >>> breathing space. >>> - I want to make romstage optional and include the sources in the >>> bootblock: That should shave off roughly 10K of romstage. >>> - I have compressing postcar working (maybe you can also disable the >>> postcar console to reduce size). That's also 2-3k size gains >>> at likely the const of a tiny bit of boot performance on this platform. >>> - I also have some WIP code to merge postcar into ramstage which would >>> save >>> 15k. >>> >>> Maybe on coreboot release 4.15 you will have a better time building a >>> fully >>> working image with the default configuration. > >> I didn't realize there was development going on to save rom space, >> that's good to know. > > I just built the asus/p2b from commit d981c490 (mb/google/mancomb: > Enable some PCIe power saving features) with the Debian sid/unstable > toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110). > > There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. > Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot > image built fine. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 17336 none > cpu_microcode_blob.bin 0x44c0 microcode 83968 none > fallback/ramstage 0x18d00 stage 53376 LZMA > (112168 decompressed) > build_info 0x25e00 raw 89 none > fallback/dsdt.aml 0x25e80 raw 5514 none > cmos_layout.bin 0x27440 cmos_layout 704 none > fallback/postcar 0x27740 stage 16888 none > fallback/payload 0x2b980 simple elf 69886 none > (empty) 0x3cac0 null 1956 none > bootblock 0x3d280 bootblock 11088 none > ``` > > Building with Jacob’s link time optimization changes [1], which he > thankfully rebased, saved 13 kB, so the configuration file would fit in > too. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 14752 none > cpu_microcode_blob.bin 0x3ac0 microcode 83968 none > fallback/ramstage 0x18300 stage 46277 LZMA > (95496 decompressed) > build_info 0x23840 raw 89 none > fallback/dsdt.aml 0x238c0 raw 5514 none > cmos_layout.bin 0x24e80 cmos_layout 704 none > fallback/postcar 0x25180 stage 14872 none > fallback/payload 0x28c00 simple elf 69886 none > (empty) 0x39d40 null 15012 none > bootblock 0x3d800 bootblock 9664 none > ``` > > (If you have a recovery option and some spare time, it’d be great if you > tested the LTO patches.) I could probably test them out, though I'm not sure I'll get around to it right away. Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options. Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both? My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet. I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket. I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples. > > Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/40815/ > (whole series) > Branden

5 11

cgit on review.coreboot.org
by Julius Werner June 1, 2021

June 1, 2021

Hi Patrick, Martin, I just noticed that we seem to have dropped support for cgit on the coreboot Gerrit. I don't exactly remember how it worked, but I seem to have been able to get a link like https://review.coreboot.org/cgit/qc_blobs.git/plain/sc7180/qtiseclib/libqti… some time last year. Now that just redirects to Gitiles. The problem with Gitiles is it's impossible to just get a direct download link to a file -- you can only see source files in the browser view (with the Gitiles UI on the side), but you can't download the raw file exactly as it is in the repo. This is especially problematic for binary files where there is (as far as I can tell? Maybe I just can't find it...) no way to get their contents at all without downloading a whole tarball of a directory and extracting it (which is pretty cumbersome). Do you guys know why this happened and is there any chance we could get cgit back? Thanks, Julius

5 7

[coreboot - Bug #309] (New) crossgcc: Handle missing tarballs in download step
by coreboot＠fe80.eu May 29, 2021

May 29, 2021

Issue #309 has been reported by Patrick Georgi. ---------------------------------------- Bug #309: crossgcc: Handle missing tarballs in download step https://ticket.coreboot.org/issues/309 * Author: Patrick Georgi * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- We keep a copy of the tarballs used by crossgcc in coreboot releases in https://coreboot.org/releases/crossgcc-sources/, so we should fall back if a download failed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

NEW board development
by Zaroe May 28, 2021

May 28, 2021

Hello, I am interested in developing coreboot for my new board. I would like some assistance with regards to the development.

1 0

What should we do about freenode IRC services?
by Patrick Georgi May 28, 2021

May 28, 2021

Hi everybody, you might have heard that freenode.org recently changed management under weird circumstances. Given that we use their services for our project chat, this concerns us as well. In last week's leadership meeting we had a wide variety of opinions: To go for libera.chat (a network created by former freenode staff), some other IRC network, to leave IRC behind and go for something newer and Matrix and Mattermost have been brought up as examples of where this might lead. Of course, we could also decide to stay on freenode, although from what transpires that option seems less and less attractive every day. So, what should we do? Regards, Patrick

13 17

Printing u32 on 32-bit and 64-bit without cast
by Paul Menzel May 27, 2021

May 27, 2021

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

2 1