Quoting patrick.rudo...@9elements.com (2019-11-15 08:15:14)
> From: Patrick Rudolph
>
> As user land tools currently use /dev/mem to access coreboot tables and
> CBMEM, provide a better way by using sysfs attributes.
>
> Unconditionally expose all tables and buffers making future changes in
>
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.4-rc7 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option
From: Patrick Rudolph
Make all coreboot table entries available to userland. This is useful for
tools that are currently using /dev/mem.
Besides the tag and size also expose the raw table data itself.
Tools can easily scan for the right coreboot table by reading
From: Patrick Rudolph
Make all CBMEM buffers available to userland. This is useful for tools
that are currently using /dev/mem.
Make the id, size and address available, as well as the raw table data.
Tools can easily scan the right CBMEM buffer by reading
From: Patrick Rudolph
As user land tools currently use /dev/mem to access coreboot tables and
CBMEM, provide a better way by using sysfs attributes.
Unconditionally expose all tables and buffers making future changes in
coreboot possible without modifying a kernel driver.
Patrick Rudolph (2):
I've fixed 45 format-related warnings/errors of IDS_HDT_CONSOLE at AMD
16h vendorcode. Now a coreboot for fam16 could be built successfully
with IDS_HDT_CONSOLE enabled (IDSOPT_IDS_ENABLED TRUE and
IDSOPT_TRACING_ENABLED TRUE at board/OptionsIds.h) even with config
WARNINGS_ARE_ERRORS. Joined
Hi all,
Sorry my noob question but I would like to clarify something. The steps
detailed in the
'Signing the coreboot Image' section from
https://doc.coreboot.org/security/vboot/index.html
are already integrated in the coreboot.rom building process? Now I can see the
steps:
CREATE GBB
From: Arthur Heymans
Currently this driver is loaded if the DMI string matches coreboot
and has a proper smi_command in the ACPI FADT table, but a GSMI handler in
SMM is an optional feature in coreboot.
So probe for a SMM GSMI handler before initializing the driver.
If the smihandler leaves the
From: Arthur Heymans
Fix a bug where the kernel module couldn't be loaded after unloading,
as the platform driver wasn't released on exit.
Signed-off-by: Arthur Heymans
---
drivers/firmware/google/gsmi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/firmware/google/gsmi.c
From: Patrick Rudolph
Fix a bug where the kernel module can't be loaded after it has been
unloaded as the devices are still present and conflicting with the
to be created coreboot devices.
Signed-off-by: Patrick Rudolph
---
drivers/firmware/google/coreboot_table.c | 6 ++
1 file changed,
From: Patrick Rudolph
This patch series fixes 3 independent bugs in the google firmware
drivers.
Patch 1-2 do proper cleanup at kernel module unloading.
Patch 3 adds a check if the optional GSMI SMM handler is actually
present in the firmware and responses to the driver.
Arthur Heymans (2):
Thank you all, I found the necessary information in the document: Aspen Cove
Customer Reference Board (CRB)
User Guide March 2016 Document Number: 566111, Revision: 1.0
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to
Hi Wim Vervoorn
I use FSP 2.0 for denverton_ns.
Unfortunately in the directory for this processor the documentation does not
contain information on post codes
Regards,
Dmitry
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an
I use FSP version 2.0 for Intel Denverton_ns. Unfortunately in the directory
for this processor the documentation does not contain information on post
codes...
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to
14 matches
Mail list logo
