[coreboot] Re: Laptop EC questions
Have you turned off HP Sure Start in the BIOS setting when running the OEM firmware (in "Security->BIOS Integrity Checking")? There's a PEI and bootblock volume in the EC chip, which Sure Start may use to recover the BIOS. > The only thing I can think of would be the Embedded Controller. > Unfortunately there isnt a lot of documentation on how the EC could cause > these problems nor are there any hints towards how to potentially integrate > them into the build. I have found that the EC is an MEC1322 which is a part > of the chrome-ec project and was wondering if there may be an easy way to > do this integration to further test. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Laptop EC questions
Iru Cai wrote: > What we need to do is to find out how the BIOS > code initialize the EC so that the machine can be brought up. I can think of two ways. 1. Software - use SerialICE for dynamic analysis of the factory BIOS. 2. Hardware - monitor the LPC bus or see if the EC maybe has tracing or its debug UART enabled. The datasheet is good. I would tend to 2, but 1 requires no dealing with hardware. Alexander Couzens wrote an LPC sniffer for iCE40 FPGAs: https://github.com/lynxis/lpc_sniffer Someone modified it to only report specific addresses, that might be useful with the EC too: (But I wish they had just cloned lynxis repo..) https://github.com/denandz/lpc_sniffer_tpm //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Laptop EC questions
Hi Lomár, I'm currently trying to port coreboot to HP EliteBook 820 G1, which uses the same EC chip MEC1322 and may have the same kind of EC firmware. On Mon, Apr 06, 2020 at 07:12:24PM -0400, Lomár Berry wrote: > I have been looking at trying to port coreboot to my HP zBook 15 G2. > Everything is seemingly fine, I can get an image built as this machine is > similar to the Lenovo t440p. Unfortunately I have yet to have a successful > startup. There are a few differences in the machine which include having a What can you see when you try to start up your machine? > > The only thing I can think of would be the Embedded Controller. > Unfortunately there isnt a lot of documentation on how the EC could cause > these problems nor are there any hints towards how to potentially integrate > them into the build. I have found that the EC is an MEC1322 which is a part > of the chrome-ec project and was wondering if there may be an easy way to > do this integration to further test. EC is really a problem. HP uses a different kind of EC firmware, so we can't use the chrome-ec support code, unless we port chrome-ec to these laptops (I have thought of doing this, but it's another hard problem.). We don't need to extract the EC to put into the coreboot build process if the EC is located in another chip (as is the case in EliteBook 820 G1/G2). What we need to do is to find out how the BIOS code initialize the EC so that the machine can be brought up. Regards, Iru ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [PATCH v4 2/2] firmware: google: Expose coreboot tables over sysfs
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.
Update the ABI documentation to explain the new sysfs interface.
Tools can easily scan for the right coreboot table by reading
/sys/bus/coreboot/devices/coreboot*/attributes/id
The binary table data can then be read from
/sys/bus/coreboot/devices/coreboot*/attributes/data
Signed-off-by: Patrick Rudolph
---
-v2:
- Add ABI documentation
- Add 0x prefix on hex values
- Remove wrong ioremap hint as found by CI
-v3:
- Use BIN_ATTR_RO
-v4:
- Updated ABI documentation
---
Documentation/ABI/stable/sysfs-bus-coreboot | 30 +++
drivers/firmware/google/coreboot_table.c| 58 +
2 files changed, 88 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-bus-coreboot
b/Documentation/ABI/stable/sysfs-bus-coreboot
index 6055906f41f2..328153a1b3f4 100644
--- a/Documentation/ABI/stable/sysfs-bus-coreboot
+++ b/Documentation/ABI/stable/sysfs-bus-coreboot
@@ -42,3 +42,33 @@ Description:
buffer.
The file holds a read-only binary representation of the CBMEM
buffer.
+
+What: /sys/bus/coreboot/devices/.../attributes/id
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
attributes/id.
+ The file holds an ASCII representation of the coreboot table ID
+ in hex (e.g. 0x00ef). On coreboot enabled platforms the ID
is
+ usually called TAG.
+
+What: /sys/bus/coreboot/devices/.../attributes/size
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ attributes/size.
+ The file holds an ASCII representation as decimal number of the
+ coreboot table size (e.g. 64).
+
+What: /sys/bus/coreboot/devices/.../attributes/data
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ attributes/data.
+ The file holds a read-only binary representation of the coreboot
+ table.
diff --git a/drivers/firmware/google/coreboot_table.c
b/drivers/firmware/google/coreboot_table.c
index 0205987a4fd4..d0fc3eb93f4f 100644
--- a/drivers/firmware/google/coreboot_table.c
+++ b/drivers/firmware/google/coreboot_table.c
@@ -3,9 +3,11 @@
* coreboot_table.c
*
* Module providing coreboot table access.
+ * Exports coreboot tables as attributes in sysfs.
*
* Copyright 2017 Google Inc.
* Copyright 2017 Samuel Holland
+ * Copyright 2019 9elements Agency GmbH
*/
#include
@@ -84,6 +86,60 @@ void coreboot_driver_unregister(struct coreboot_driver
*driver)
}
EXPORT_SYMBOL(coreboot_driver_unregister);
+static ssize_t id_show(struct device *dev,
+ struct device_attribute *attr, char *buffer)
+{
+ struct coreboot_device *device = CB_DEV(dev);
+
+ return sprintf(buffer, "0x%08x\n", device->entry.tag);
+}
+
+static ssize_t size_show(struct device *dev,
+struct device_attribute *attr, char *buffer)
+{
+ struct coreboot_device *device = CB_DEV(dev);
+
+ return sprintf(buffer, "%u\n", device->entry.size);
+}
+
+static DEVICE_ATTR_RO(id);
+static DEVICE_ATTR_RO(size);
+
+static struct attribute *cb_dev_attrs[] = {
+ _attr_id.attr,
+ _attr_size.attr,
+ NULL
+};
+
+static ssize_t data_read(struct file *filp, struct kobject *kobj,
+struct bin_attribute *bin_attr,
+char *buffer, loff_t offset, size_t count)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct coreboot_device *device = CB_DEV(dev);
+
+ return memory_read_from_buffer(buffer, count, ,
+ >entry, device->entry.size);
+}
+
+static BIN_ATTR_RO(data, 0);
+
+static struct bin_attribute *cb_dev_bin_attrs[] = {
+ _attr_data,
+ NULL
+};
+
+static const struct attribute_group cb_dev_attr_group = {
+ .name = "attributes",
+ .attrs = cb_dev_attrs,
+ .bin_attrs = cb_dev_bin_attrs,
+};
+
+static const struct attribute_group *cb_dev_attr_groups[] = {
+ _dev_attr_group,
+ NULL
+};
+
static int coreboot_table_populate(struct device *dev, void *ptr)
{
int i, ret;
@@ -104,6 +160,8 @@ static int coreboot_table_populate(struct device *dev, void
*ptr)
device->dev.parent = dev;
device->dev.bus = _bus_type;
device->dev.release = coreboot_device_release;
+ device->dev.groups = cb_dev_attr_groups;
+
memcpy(>entry,
[coreboot] [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs
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
/sys/bus/coreboot/drivers/cbmem/coreboot*/cbmem_attributes/id
or
/sys/bus/coreboot/devices/coreboot*/cbmem_attributes/id
The binary table data can then be read from
/sys/bus/coreboot/drivers/cbmem/coreboot*/cbmem_attributes/data
or
/sys/bus/coreboot/devices/coreboot*/cbmem_attributes/data
Signed-off-by: Patrick Rudolph
---
-v2:
- Add ABI documentation
- Add 0x prefix on hex values
-v3:
- Use BIN_ATTR_RO
-v4:
- Use temporary memremap instead of persistent ioremap
- Constify a struct
- Get rid of unused headers
- Use dev_{get|set}_drvdata
- Use dev_groups to automatically handle attributes
- Updated file description
- Updated ABI documentation
---
Documentation/ABI/stable/sysfs-bus-coreboot | 44 +++
drivers/firmware/google/Kconfig | 9 ++
drivers/firmware/google/Makefile| 1 +
drivers/firmware/google/cbmem-coreboot.c| 128
drivers/firmware/google/coreboot_table.h| 14 +++
5 files changed, 196 insertions(+)
create mode 100644 Documentation/ABI/stable/sysfs-bus-coreboot
create mode 100644 drivers/firmware/google/cbmem-coreboot.c
diff --git a/Documentation/ABI/stable/sysfs-bus-coreboot
b/Documentation/ABI/stable/sysfs-bus-coreboot
new file mode 100644
index ..6055906f41f2
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-bus-coreboot
@@ -0,0 +1,44 @@
+What: /sys/bus/coreboot/devices/.../cbmem_attributes/id
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ cbmem_attributes/id if the device corresponds to a CBMEM
+ buffer.
+ The file holds an ASCII representation of the CBMEM ID in hex
+ (e.g. 0xdeadbeef).
+
+What: /sys/bus/coreboot/devices/.../cbmem_attributes/size
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ cbmem_attributes/size if the device corresponds to a CBMEM
+ buffer.
+ The file holds an representation as decimal number of the
+ CBMEM buffer size (e.g. 64).
+
+What: /sys/bus/coreboot/devices/.../cbmem_attributes/address
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ cbmem_attributes/address if the device corresponds to a CBMEM
+ buffer.
+ The file holds an ASCII representation of the physical address
+ of the CBMEM buffer in hex (e.g. 0x8000d000) and should
+ be used for debugging only.
+
+What: /sys/bus/coreboot/devices/.../cbmem_attributes/data
+Date: Apr 2020
+KernelVersion: 5.6
+Contact: Patrick Rudolph
+Description:
+ coreboot device directory can contain a file named
+ cbmem_attributes/data if the device corresponds to a CBMEM
+ buffer.
+ The file holds a read-only binary representation of the CBMEM
+ buffer.
diff --git a/drivers/firmware/google/Kconfig b/drivers/firmware/google/Kconfig
index a3a6ca659ffa..11a67c397ab3 100644
--- a/drivers/firmware/google/Kconfig
+++ b/drivers/firmware/google/Kconfig
@@ -58,6 +58,15 @@ config GOOGLE_FRAMEBUFFER_COREBOOT
This option enables the kernel to search for a framebuffer in
the coreboot table. If found, it is registered with simplefb.
+config GOOGLE_CBMEM_COREBOOT
+ tristate "Coreboot CBMEM access"
+ depends on GOOGLE_COREBOOT_TABLE
+ help
+ This option exposes all available CBMEM buffers to userland.
+ The CBMEM id, size and address as well as the raw table data
+ are exported as sysfs attributes of the corresponding coreboot
+ table.
+
config GOOGLE_MEMCONSOLE_COREBOOT
tristate "Firmware Memory Console"
depends on GOOGLE_COREBOOT_TABLE
diff --git a/drivers/firmware/google/Makefile b/drivers/firmware/google/Makefile
index d17caded5d88..62053cd6d058 100644
--- a/drivers/firmware/google/Makefile
+++ b/drivers/firmware/google/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_GOOGLE_SMI) += gsmi.o
obj-$(CONFIG_GOOGLE_COREBOOT_TABLE)+= coreboot_table.o
+obj-$(CONFIG_GOOGLE_CBMEM_COREBOOT)+= cbmem-coreboot.o
obj-$(CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT) += framebuffer-coreboot.o
obj-$(CONFIG_GOOGLE_MEMCONSOLE)+= memconsole.o
obj-$(CONFIG_GOOGLE_MEMCONSOLE_COREBOOT) +=
[coreboot] [PATCH v4 0/2] firmware: google: Expose coreboot tables and CBMEM
From: Patrick Rudolph
As user land tools currently use /dev/mem to access coreboot tables and
CBMEM, provide a better way by using read-only sysfs attributes.
Unconditionally expose all tables and buffers making future changes in
coreboot possible without modifying a kernel driver.
Changes in v2:
- Add ABI documentation
- Add 0x prefix on hex values
- Remove wrong ioremap hint as found by CI
Changes in v3:
- Use BIN_ATTR_RO
Changes in v4:
- Use temporary memremap instead of persistent ioremap
- Constify a struct
- Get rid of unused headers
- Use dev_{get|set}_drvdata
- Use dev_groups to automatically handle attributes
- Updated file description
- Updated ABI documentation
Patrick Rudolph (2):
firmware: google: Expose CBMEM over sysfs
firmware: google: Expose coreboot tables over sysfs
Documentation/ABI/stable/sysfs-bus-coreboot | 74 +++
drivers/firmware/google/Kconfig | 9 ++
drivers/firmware/google/Makefile| 1 +
drivers/firmware/google/cbmem-coreboot.c| 128
drivers/firmware/google/coreboot_table.c| 58 +
drivers/firmware/google/coreboot_table.h| 14 +++
6 files changed, 284 insertions(+)
create mode 100644 Documentation/ABI/stable/sysfs-bus-coreboot
create mode 100644 drivers/firmware/google/cbmem-coreboot.c
--
2.24.1
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] (no subject)
Hi, I am a complete newb, though I want nothing more than to be able to program at a bare metal level and help develop for this platform. How do I get started? I am sure there is likely many emails like this, and I have truly done my best hunting for information. I have a small understanding of assembly, and have tried reading TRMs to no avail. Is there any texts anyone could recommend to get me started? I would truly be ever so grateful for any advice. Thanks, Luke ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Laptop EC questions
I have been looking at trying to port coreboot to my HP zBook 15 G2. Everything is seemingly fine, I can get an image built as this machine is similar to the Lenovo t440p. Unfortunately I have yet to have a successful startup. There are a few differences in the machine which include having a dedicated Nvidia GPU, which i have loaded the video bios file for based on how things were done for SpookySkeletons' 8770w build at https://github.com/SpookySkeletons/Coreboot_8770w The only thing I can think of would be the Embedded Controller. Unfortunately there isnt a lot of documentation on how the EC could cause these problems nor are there any hints towards how to potentially integrate them into the build. I have found that the EC is an MEC1322 which is a part of the chrome-ec project and was wondering if there may be an easy way to do this integration to further test. Thanks ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
