FW reserved regions are needed for OS to access FW data such as ACPI APEI (ACPI Platform Error Interface) data. The ACPI APEI data may include previous boot error record (BERT), or error record reported through firmware runtime component (such as SMI handler). Such FW reserved region needs to be:
a. Updateable by firmware bootloader or firmware runtime component.
b. Updateable by OS drivers (for instance, the Linux ACPI BERT driver needs to be able to grab and clear the record.
c. Reserved from being used as normal memory by OS.
If I just add BERT memory region through cbmem_add(), I get this OS error message:
[ 12.899311] APEI: Can not request [mem 0x75319000-0x7531911b] for APEI BERT registers
If I also make this change:
diff --git a/src/lib/bootmem.c b/src/lib/bootmem.c
index 1fe23c2828..721d74ac75 100644
@@ -49,7 +49,7 @@ static uint32_t bootmem_to_lb_tag(const enum bootmem_type tag)
- return LB_MEM_TABLE;
+ return LB_MEM_RESERVED;
Then it works fine, I get this:
[ 12.902253] BERT: Error records from previous boot:
[ 12.912270] [Hardware Error]: event severity: fatal
[ 12.922288] [Hardware Error]: precise tstamp: 2020-08-13 21:56:18
[ 12.934980] [Hardware Error]: Error 0, type: fatal
[ 12.944995] [Hardware Error]: section_type: general processor error
[ 12.958227] [Hardware Error]: processor_type: 0, IA32/X64
[ 12.969674] [Hardware Error]: error_type: 0x02
[ 12.979157] [Hardware Error]: TLB error
[ 12.987390] [Hardware Error]: version_info: 0x000000000005065a
[ 12.999733] [Hardware Error]: processor_id: 0x0000000000000000
So the question is why we need to make memory attribute of cbmem as LB_MEM_TABLE, instead of LB_MEM_RESERVED?
The 1.14.0 version of SeaBIOS has now been released. For more
information on the release, please see:
New in this release:
* New virtio MMIO support. Support for finding virtio MMIO devices via
an ACPI DSDT parser. Support for handling a large number of virtio
* Improved handling of USB keyboards with non-standard packet size.
* Improved KVM CPU frequency detection.
* Support for PCI mmconfig support on QEMU.
* Several bug fixes and code cleanups.
For information on obtaining SeaBIOS, please see:
===== git shortlog -n rel-1.13.0..rel-1.14.0 =====
Gerd Hoffmann (25):
boot: cache HALT priority
virtio-scsi: skip initializing non-bootable devices
nvme: skip initializing non-bootable devices
timer: add tsctimer_setfreq()
kvm: detect unconditionally
kvm: add support for reading tsc frequency via cpuid.
kvm: add support for reading tsc frequency from kvmclock
sercon: vbe modeset is int 10h function 4f02 not 4f00
pci: factor out ioconfig_cmd()
pci: add mmconfig support
qemu: factor out qemu_cfg_detect()
qemu: rework e820 detection
qemu: check rtc presence before reading cpu count from cmos
virtio-mmio: device probing and initialization.
virtio-mmio: add support to vp_*() functions
virtio-mmio: add support for scsi devices.
virtio-mmio: add support for block devices.
virtio-mmio: print device type
acpi: add xsdt support
acpi: add dsdt parser
acpi: skip kbd init if not present
acpi: find and register virtio-mmio devices
rewrap Makefile lines.
pci: fix mmconfig support
vga: fix cirrus bios
Kevin O'Connor (6):
usb-hid: Improve max packet size checking
Revert "ps2port: adjust init routine to fix PS/2 keyboard issues"
boot: Fixup check for only one item in boot list
vgabios: Fix preserve memory flag in handle_1000
ldnoexec: Add script to remove ET_EXEC flag from intermediate build objects
docs: Note v1.14.0 release
Paul Menzel (5):
std/tcg: Replace zero-length array with flexible-array member
boot: Extend `etc/show-boot-menu` to configure skipping boot menu with only one device
boot: Log, if boot menu is skipped
cdrom: Demote `scsi_is_ready` return print to debug level
nvme: Increase `nvme_cmd_readwrite()` message log level from 3 to 5
Matt DeVillier (4):
hw/usb-hid: Don't abort if setting key repeat rate fails
Skip boot menu and timeout with only one boot device
ps2port: adjust init routine to fix PS/2 keyboard issues
boot: Fix logic for boot menu display
Stefan Berger (3):
tcgbios: Only write logs for PCRs that are in active PCR banks
tcgbios: Fix the vendorInfoSize to be of type u8
tcgbios: Add support for SHA3 type of algorithms
Alexey Kirillov (2):
boot: Detect strict boot order (HALT record) in function
virtio: Do not init non-bootable devices
Christian Ehrhardt (1):
build: use -fcf-protection=none when available
Jason Andryuk (1):
serialio: Preserve Xen DebugOutputPort
Roman Bolshakov (1):
timer: Handle decrements of PIT counter
Stefan Reiter (1):
virtio-scsi: fix boot prio detection by using correct lun
I hope you are staying safe and healthy through these unusual times!
Many of you may already know about the project I am working on and the
progress we made through my blog post
We had added support for ASan in ramstage for all x86 platforms.
In the next phase, to check the boards on which ASan in romstage can be
enabled, I ran 'make what-jenkins-does' and build failed only for the
boards having either Braswell or i440bx chipsets. So, I am pretty hopeful
we can add support for ASan in romstage on all x86 platforms except these
We have already tested and added support for ASan in romstage on Haswell
<https://review.coreboot.org/c/coreboot/+/44160> and Apollolake
<https://review.coreboot.org/c/coreboot/+/44159> platforms based on the
hardware that Werner and I had access to.
I am currently in the final phase of GSoC and before signing off, I want
this debugging tool to be available on as many platforms as possible. So,
if you have access to a hardware based on an x86 platform (other than
Haswell and Apollolake), I would be grateful if you volunteer to test this
Please follow these steps if you are willing to test ASan:
1. Pull this change: https://review.coreboot.org/c/coreboot/+/43938
2. Rebuild the toolchain
3. Select 'Address sanitizer support' from the 'General setup' menu
3. Build coreboot
4. Flash the image and run it on your hardware
It should boot cleanly and you must see statements prefixed with 'ASan' in
your console log in case of both romstage and ramstage.
If ASan in romstage works on your hardware, please reply to this thread
with the x86 platform name and the name of the board you used, so that I
can push a change enabling ASan on that platform.
If it gets stuck while booting or you get a compile error while building,
please share the log along with the hardware details. We might be able to
resolve those errors and add support for ASan on that platform too.
Thanking you in advance,
(hst on IRC)
n fact, the title of many of the documents do correlate to the list of
purported information posted by the leaker:
- Intel ME Bringup guides + (flash) tooling + samples for various
- Kabylake (Purley Platform) BIOS Reference Code and Sample Code +
Initialization code (some of it as exported git repos with full history)
- Intel CEFDK (Consumer Electronics Firmware Development Kit (Bootloader
- Silicon / FSP source code packages for various platforms
- Various Intel Development and Debugging Tools
- Simics Simulation for Rocket Lake S and potentially other platforms
- Various roadmaps and other documents
- Binaries for Camera drivers Intel made for SpaceX
- Schematics, Docs, Tools + Firmware for the unreleased Tiger Lake
- (very horrible) Kabylake FDK training videos
- Intel Trace Hub + decoder files for various Intel ME versions
- Elkhart Lake Silicon Reference and Platform Sample Code
- Some Verilog stuff for various Xeon Platforms, unsure what it is
- Debug BIOS/TXE builds for various Platforms
- Bootguard SDK (encrypted zip)
- Intel Snowridge / Snowfish Process Simulator ADK
- Various schematics
- Intel Marketing Material Templates (InDesign)
- Lots of other things
As my title suggests, what to be prepared for _‘‘externally’’_ flashing Coreboot on a microSD?
If external flash is done, *what* to be prepared to port Coreboot for my Sony VPCCB17FG laptop, with known supported Intel *HM65* chipsets, but even the vendor, Sony, is *unknown* to be supported or not?
Are there any up-to-date wikies or docs on committing like this?
> (Reference: https://firstname.lastname@example.org/thread/62E6…)