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
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?
Hi!
Have you experienced anything like this while compiling from the branch 4.8.1?
I have a fresh and a ~ 1 year old crossgcc pack, but both are end up
after a make menuconfig ; make -j8 with the same way.
In the latest crossgcc build, I had to apply an include string fix to
binutils and a -Wl,--allow-multiple-definition to the acpica's
LDFLAGS.
####
$ CC=/usr/bin/gcc make -d -j8
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Reading makefile '/media/ramdisk/coreboot/util/kconfig/Makefile'
(search path) (no ~ expansion)...
Reading makefile '/media/ramdisk/coreboot/.config' (search path) (no ~
expansion)...
Reading makefile '.xcompile' (search path) (don't care) (no ~ expansion)...
Reading makefile 'toolchain.inc' (search path) (no ~ expansion)...
Reading makefile 'Makefile.inc' (search path) (don't care) (no ~ expansion)...
Skipping submodule '3rdparty/blobs'
Reading makefile 'util/crossgcc/Makefile.inc' (search path) (no ~ expansion)...
.
.
Reading makefile 'src/vendorcode/amd/pi/00670F00/Makefile.inc' (search
path) (don't care) (no ~ expansion)...
Segmentation error (core dumped)
####
$ dmesg | tail -1
[30582.804975] make[750110]: segfault at 7fffb5d2dff8 ip
00007fd105838cff sp 00007fffb5d2e000 error 6 in
libc-2.32.so[7fd1057d3000+14d000]
[30582.804983] Code: 00 00 00 48 3b 1d 51 64 13 00 0f 82 ab 00 00 00
64 8b 04 25 18 00 00 00 85 c0 0f 85 23 01 00 00 48 89 ee 48 8d 3d 01
6d 13 00 <e8> cc e2 ff ff 49 89 c0 48 85 c0 0f 84 c8 00 00 00 48 8b 40
f8 a8
####
Do you have any ideas? I'm using Arch Linux 5.9 with GCC 10.2
I had a try on another machine with Arch Linux 4.19 LTS@GCC 10.2
Thanks
Hello everyone,
I have a kgpe d16 motherboard with coreboot and seabios, and 2 opteron 6282 SE processor with 64 gb of RAM: all the modules are 16 Gb hynix HMT42GR7AFR4C - RD and all are inserted into the orange slots. The problem is, if I add 2 additional modules, inside the last 2 orange slots, the machine doesn't starts and only black screen is shown, no log is detected over COM port. Any suggestion? Maybe another RAM module configuration is needed, because I read that 192 Gb of RAM is possible to obtain (I have followed the official Asus manual for the RAM-Slots configuration)
Thank you very much
Best regards
Ale
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.
Hello coreboot community!
I would like to formally announce a new project I've been working on for
the last few weeks.
Retroboot is based on coreboot, and today I have made an official
release. This release is available from the https://retroboot.org/ with
ROM images and source code provided. Please read the Retroboot
documentation if you wish to learn how to use them. Support is provided
at the #retroboot IRC channel on Freenode.
Retroboot is a new coreboot distribution, forked from the Libreboot
20160907 build system, but allows binary blobs from coreboot and uses an
up to date version of coreboot. The purpose of Retroboot is to provide
pre-compiled ROM images for any system that coreboot supports.
Retroboot, based on coreboot, provides hardware initialization on
supported x86 computers; it sets up the hardware and boots an operating
system such as GNU+Linux, BSD and Windows.
Retroboot provides an automated build system that compiled coreboot,
GRUB, SeaBIOS and various other required software, with specific
configurations. It provides a completely automated way to build and test
ROM images of coreboot, in various configurations. Each board added to
Retroboot can specify a coreboot version at a specific commit ID from
the coreboot Git repository, and custom patches. It can then be used
with any number of coreboot payloads such as GRUB, SeaBIOS and (planned
for a future release) Tianocore and linuxboot. Read the documentation on
the Retroboot website for more information about each system supported
in the Retroboot build system.
The aim of Retroboot is to make coreboot easy to use. Coreboot is
notoriously difficult to build, and very much not user friendly.
Retroboot provides user focused documentation and professional support
based on years of experience dealing with coreboot. I, Leah Rowe, am the
founder of the Retroboot project and I am also the founder of the
Libreboot project.
This release, marked beta, released on 28 December 2020, supports the
following machines:
* ThinkPad X220 (untested at the time of release)
* ThinkPad X230 (tested on a few machines at the time of release)
* ThinkPad X230 Tablet (untested at the time of release, but X230 is
the same board as the X230T, with minor differences, so the X230T
ROMs should work)
* ThinkPad T60 with ATI Mobility Radeon X1400, PCI ID 1002:7145
(tested on one machine at the time of release)
NOTE: /tested/ in this context means that the machine can be observed
booting a Linux kernel. Also, Windows 10 was confirmed to boot on the
X230 with Intel VGA ROM and SeaBIOS payload. (we recommend the use of
free operating systems like GNU+Linux).
For documentation, refer to the accompnying source code release archive.
Documentation is included in that archive. You can also refer to the
documentation hosted directly at https://retroboot.org/ and this is more
recommended due to it being more up to date.
This is a public /beta/ release. The ROM images provided in this release
are NOT guaranteed to boot correctly on your machine. If you install
this, you should make sure that you have SPI flashing equipment (for
flashing 25XX NOR flash) and, ideally, debugging equipment such as EHCI
debug dongle.
Extensive testing is required for all of the ROMs in this release, so
user testing is highly encouraged! The plan for Retroboot is to have
long, long periods of /testing/ releases, before versions are marked
stable (similar to how the Debian project operates).
More information about Retroboot can be found on the Retroboot website:
https://retroboot.org/
Extensive documentation is provided, including for developers.
I'm currently looking for people to add and maintain boards in
Retroboot. The entire build system is documented here:
https://retroboot.org/docs/maintain/
--
Leah Rowe,
And now, a song:
https://blog.vimuser.org/free-firmware-song.html
Hi Everyone,
On the Baytrail platform with ALC262 Realtek Codec, HDA Audio is enumerated
as PCI device 00 1b 00,
the verb table is being programmed on HDABAR + command offset.
Using uefi Payload which has PchInit -> DetectAndInitializeAzalia, there
are no Errors in this path, all looks good
Either Beep or Audio speakers fail to work in EFI Shell and also in Ubuntu
aplay -l does not Audio ALC Codec as sound card
what is missing to enumerate, FSP path\SoC Straps are enabled for Audio so
they seem to be fine too
Appreciate for any clues to make HDA to work on a BayTrail Platform
Thanks
Ranga
Dear Coreboot community,
I am developing bios for my custom Apollo Lake SoC E3950 mainboard. I got to a point where SeaBios is loaded and awaits to choose a boot option. The problem is that its getting stuck while waiting for timeout or keyboard press (see log attached). I figured out that it is getting stuck on wait_irq() function. In particular, call stack looks like this:
interactive_bootmenu() (/coreboot/payloads/external/SeaBIOS/seabios/src/boot.c)
get_keystroke() (int scan_code = get_keystroke(menutime);)
get_keystroke_full()
yield_toirq()
wait_irq()
__stack_hop_back_wait_irq()
Why can this happen? Is hardware not initialized properly during Coreboot operation or it should be done in SeaBios?
Looks like interrupts from timer and keyboard are not working. I tried loading with FILO payload and keyboard was working Ok except keyboard leds were not working.
Best Regards,
Anatolii Vorobev
Hello all,
There are two/three devices which I would like to run coreboot on, which are variants of devices explicitly supported by coreboot.
These document pages, however, are a little ambiguous as to which variants of the supported devices would work. I seek clarification.
On the page https://doc.coreboot.org/mainboard/asrock/h110m-dvs.html is linked ASRock's information page about the H110M-DVS R2.0. I should like to run coreboot on the H110M-DVS R3.0, as this one is of the mini-DTX form-factor, which the R2.0 is not. Does anyone know if coreboot's H110M-DVS port would function on the R3.0? There is no indication (other than the fact that the doc page links to the R2.0's info) that this would not be the case. Indeed, the documentation page consistently refers to the motherboard as merely the 'H110M-DVS,' without the revision specifier.
Another, related question, is whether the very-similar H110M-DGS would be supported by this coreboot port. http://www.asrock.com/mb/Intel/H110M-DGS/index.asp
Note that the H81M-DGS is supported by coreboot.
On the page https://doc.coreboot.org/mainboard/libretrend/lt1000.html is linked Libretrend's purchase website for their 'Librebox.' Libretrend is, quite sadly, defunct - it was the maker of the 'librebox' which to my knowledge is the sole 'thin mini-ITX' motherboard supported by coreboot. However, Libretrend did not manufacture their own hardware, but instead seemingly ordered it from an external OEM - indeed this OEM is linked to in the coreboot docs. The page for their version of the board is here: http://www.minicase.net/product_LR-i7S65T1.html
Indeed the OEM version, the LR-i7S65T1, looks exactly the same as the Libretrend Librebox.
Would anyone happen to know if the OEM LR-i7S65T1 would be supported by the Libretrend Librebox coreboot port? Or is the hardware between the OEM (minicase) and distributor (libretrend) versions of this board different somehow?
Thanks all,
- Daniel C.