coreboot October 2020

coreboot@coreboot.org

37 participants
33 discussions

ThinkPad T420 and FireWire chip on Linux

by Alesandar Metodiev

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

1 month

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?

4 months, 3 weeks

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.

1 year

IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

by Mike Banon

Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change: https://review.coreboot.org/c/coreboot/+/46587/ When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated. Best regards, Mike Banon

1 year, 1 month

Coreboot Picasso FSP questions

by chen.kenyy＠inventec.com

Hi, I study in AMD AGESA v9 boot in the coreboot. So far, I boot to the FSP image failed as below log. CBFS: Locating 'fspm.bin' CBFS: 'fspm.bin' not found. FSPM not available or failed to load! And I google the related information, found the gerrit review information(https://review.coreboot.org/c/coreboot/+/34423/), I want to query you how to make/create the FSP binary for AMD or FSP information to coreboot image. Could you give me some instructions? Thanks.

1 year, 2 months

Flashing coreboot and Intel Flash Descriptor Erase Issue

by Balaji Sivakumar

Hello Everyone, We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? Any pointers would be appreciated. Thanks Balaji

1 year, 2 months

Flashing coreboot and Intel Flash Descriptor Erase Issue

by Balaji Sivakumar

We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? -- Thanks, Balaji

1 year, 2 months

AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

by Paul Menzel

Dear coreboot folks, Trying to finish the Asus F2A85-M PRO coreboot port (AMD Family 15h/Hudson), the internal network device does not work with the state from [1]. With the vendor firmware 6601, it is 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09) behind PCI bridge 00:15.2. > -[0000:00]-+-00.0 > +-00.2 > +-01.0 > +-01.1 > +-10.0 > +-10.1 > +-11.0 > +-12.0 > +-12.2 > +-13.0 > +-13.2 > +-14.0 > +-14.2 > +-14.3 > +-14.4-[01]-- > +-15.0-[02]-- > +-15.1-[03]----00.0 > +-15.2-[04]----00.0 > +-18.0 > +-18.1 > +-18.2 > +-18.3 > +-18.4 > \-18.5 In the current state [1], coreboot says device 00:15.2 is disabled > Show all devs... After init. > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > DOMAIN: 0000: enabled 1 > APIC: 10: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:00.2: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:01.1: enabled 1 > PCI: 00:02.0: enabled 0 > PCI: 00:03.0: enabled 0 > PCI: 00:04.0: enabled 0 > PCI: 00:05.0: enabled 0 > PCI: 00:06.0: enabled 0 > PCI: 00:07.0: enabled 0 > PCI: 00:08.0: enabled 0 > PCI: 00:10.0: enabled 1 > PCI: 00:10.1: enabled 1 > PCI: 00:11.0: enabled 1 > PCI: 00:12.0: enabled 1 > PCI: 00:12.2: enabled 1 > PCI: 00:13.0: enabled 1 > PCI: 00:13.2: enabled 1 > PCI: 00:14.0: enabled 1 > PCI: 00:14.1: enabled 0 > PCI: 00:14.2: enabled 1 > PCI: 00:14.3: enabled 1 > PCI: 00:14.4: enabled 1 > PCI: 00:14.7: enabled 0 > PCI: 00:15.0: enabled 1 > PCI: 00:15.1: enabled 1 > PCI: 00:15.2: enabled 0 > PCI: 00:18.0: enabled 1 But it is enabled in the devicetree `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`. device pci 15.2 on end # PCI bridge Please find the spew log attached. Any help is appreciated. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/46021/ "mb/asus/f2a85-m_pro: Enable super-i/o LDNs 0x0f and 0x14"

1 year, 2 months

Native RAM init

by Alif Ilhan

hello, Is there a way to extract mrc.bin from a normal(not chromehook rom) bios binary from the flash dump? There's no chromebook available with the Atom N2600 chip. There is one with Atom N570, but will it work? If not then I want to know if native ram init is supported in CedarTrail chipsets. I think it should be because Sandy bridge is supported and they were simillar(I think). CedarTail has no FSPs available on github so I must have to build the non-FPS version.....which means I cannot get mrc.bin.

1 year, 2 months

amd_blobs submodule update issue when using git sup alias and how to fix it

by Felix Held

Hi! Quick heads-up: In [1] I updated the submodule pointer of amd_blobs so that it now tracks the new official repository [2]. Since the new repository and the old don't have common ancestors, using the git sup alias to update the submodules, that rebases the changes, will fail causing git to fall back to a 3 way merge. Since the new repository contains updated firmware blobs, that merge also fails. To fix the issue run the following commands: (cd 3rdparty/amd_blobs; git rebase --abort); git submodule update --checkout Regards Felix [1] https://review.coreboot.org/c/coreboot/+/46594/ [2] https://github.com/amd/firmware_binaries

1 year, 2 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2020