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
coreboot have two types of sanitizers already: Ubsan and Asan. This is good starting point. I found a few catches by simply enabling CONFIG_COVERAGE, CONFIG_UBSAN and CONFIG_ASAN:
The developer seems haven't enable them in the testing process yet. It would be better if we add those debug features by default during the development which could possibly kill more bugs in the coreboot and the sanitizers themselves. Any ideas?
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)
const unsigned long size = 0x8000;
buf = cbmem_add(CBMEM_ID_FOO, size);
reserved_ram_resource(dev, 0, ((unsigned long)buf) >> 10, size >>
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.
const struct cbmem_entry *ce = cbmem_entry_find(CBMEM_ID_FOO);
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
[ 0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff]
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000008de34fff] usable
*[ 0.000000] BIOS-e820: [mem 0x000000008de35000-0x000000008fffffff] type
[ 0.000000] BIOS-e820: [mem 0x0000000090000000-0x00000000cfffffff]
[ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff]
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000022f33ffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000022f340000-0x000000022fffffff]
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?