I am a big FreeBSD fan, and also run NetBSD on an older machine. Haven't
used much Linux lately but installed Ubuntu to get a lspci for flashrom
use. Ubuntu is fine, but does not have superiotool available as best I see.
Looking back to FreeBSD I found superiotool just where I expected, as a
port to be compiled under sysutils. Works fine, but still never finds my
hidden bios I will call "SPI1" for lack of a better name.
Anyway, I keep looking for more tools, and have an extra disk drive for
another OS if anyone has any good suggestions?
Right now I'm in Ubuntu, listening to the coreboot & flashrom freenode IRC
channels. Quite a lot goes on there if you catch it right. Some real sharp
I heard about a project interested int creating coreboot compatible
open hardware. While that effort isn't ready to make any announcement,
questions came up about where to host such a project.
There's lots of open hardware out there already, but it's often
based on not-quite open base boards so there seems to be a hole in
the ecosystem approximately the shape of open hardware designs that
could serve as base for hardware of all sizes (SBC alikes to put
"shields" on, laptop/desktop designs that can be customized, maybe
even servers, ...)
That's where coreboot.org might come in: When I brought up the question in
today's leadership meeting, people were generally interested in having
coreboot.org host projects like that.
The idea isn't to create "coreboot branded" hardware, because that
makes as much sense as "UEFI branded" hardware (that is, none), but to
provide a place where people can cooperate on and publish open hardware
designs that are complex enough to require coreboot-style firmware.
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
I'd like to commit a patch to coreboot. I've followed the tutorials on
I've set up gerrit account, etc. created a local repo, configured git
for submit, set up change-id hook, etc. etc. etc. However at step 4a,
"git push", I got an error message from the server about missing
"Push" rights and to contact the administrator. How can I do that?
I was able to push the commit as a private patch:
I'm not sure if you can see this url, or is this for my user only.
I guess now I should add a reviewer, but how and who? Or how can I get
a "Push" right?
Thanks for your help,
After booting into Linux kacpid is constantly using 100% CPU and ACPI
interrupt is firing at ~10k/s.
My test environment is Optiplex 9010 with i5-3470 with dual channel DDR3
and an Nvidia GTX1650 installed as DGPU, running Fedora 32.
Coreboot logs and Linux dmesg is attached below. Captured with a build
of earlier master but still reproducible on the latest master.
I’m working on porting Coreboot to a laptop that uses Intel Comet Lake.
When the build completes it spits out the following warning:
** WARNING **
coreboot has been built without an Intel Firmware Descriptor.
Never write a complete coreboot.rom without an IFD to your
board's flash chip! You can use flashrom's IFD or layout
parameters to flash only to the BIOS region.
What is an IFD and how do I create one?
Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.
1 new defect(s) introduced to coreboot found with Coverity Scan.
179 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1432727: Resource leaks (RESOURCE_LEAK)
/src/drivers/intel/mipi_camera/camera.c: 458 in camera_fill_nvm()
*** CID 1432727: Resource leaks (RESOURCE_LEAK)
/src/drivers/intel/mipi_camera/camera.c: 458 in camera_fill_nvm()
452 static void camera_fill_nvm(const struct device *dev)
454 struct drivers_intel_mipi_camera_config *config = dev->chip_info;
455 struct acpi_dp *dsd = acpi_dp_new_table("_DSD");
457 if (!config->nvm_compat)
>>> CID 1432727: Resource leaks (RESOURCE_LEAK)
>>> Variable "dsd" going out of scope leaks the storage it points to.
460 /* It might be possible to default size or width based on type. */
461 if (!config->disable_nvm_defaults && !config->nvm_pagesize)
462 config->nvm_pagesize = 1;
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
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?
I have an Asus kgpe-d16 with 2 AMD opteron 6282 SE installed; obviously, since I had the first stock bios version the screen was black and no boot occurs because CPUs are not supported. So I have ordered a coreboot bios DIP and I have installed it but nothing has changed, same behaviour (only black screen and no sound, only fans starts). Can someone have some idea? I even try to log with the serial port but no log is shown at all...
P.S. Could it be that one of the CPUs is broken? Or that something went wrong during the flashing procedure over the DIP? Is there a way to check that the DIP is ok and with coreboot?
Thank you very much!