Aaron Durbin has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33367
Change subject: commonlib: reliicense to for > GPL-2
......................................................................
commonlib: reliicense to for > GPL-2
Allow compatibility with > GPL-2 code bases such that the current
implementations of:
- iobuf
- mem_pol
- region
can be utilitized in other projects.
Change-Id: If4d947d87bf04313a956e2bece9399c3dc770f19
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
M src/commonlib/include/commonlib/iobuf.h
M src/commonlib/include/commonlib/mem_pool.h
M src/commonlib/include/commonlib/region.h
M src/commonlib/iobuf.c
M src/commonlib/mem_pool.c
M src/commonlib/region.c
6 files changed, 6 insertions(+), 6 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/67/33367/1
diff --git a/src/commonlib/include/commonlib/iobuf.h b/src/commonlib/include/commonlib/iobuf.h
index c5a0f4c..fee789e 100644
--- a/src/commonlib/include/commonlib/iobuf.h
+++ b/src/commonlib/include/commonlib/iobuf.h
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/src/commonlib/include/commonlib/mem_pool.h b/src/commonlib/include/commonlib/mem_pool.h
index c21fa0e..0b6f08c 100644
--- a/src/commonlib/include/commonlib/mem_pool.h
+++ b/src/commonlib/include/commonlib/mem_pool.h
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/src/commonlib/include/commonlib/region.h b/src/commonlib/include/commonlib/region.h
index 45484dd..efb7931 100644
--- a/src/commonlib/include/commonlib/region.h
+++ b/src/commonlib/include/commonlib/region.h
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/src/commonlib/iobuf.c b/src/commonlib/iobuf.c
index b73ee19..219d692 100644
--- a/src/commonlib/iobuf.c
+++ b/src/commonlib/iobuf.c
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/src/commonlib/mem_pool.c b/src/commonlib/mem_pool.c
index cb3e726..69b1160 100644
--- a/src/commonlib/mem_pool.c
+++ b/src/commonlib/mem_pool.c
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/src/commonlib/region.c b/src/commonlib/region.c
index 541a125..8840ecd 100644
--- a/src/commonlib/region.c
+++ b/src/commonlib/region.c
@@ -5,7 +5,7 @@
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * the Free Software Foundation; version 2 or later of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
--
To view, visit https://review.coreboot.org/c/coreboot/+/33367
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: If4d947d87bf04313a956e2bece9399c3dc770f19
Gerrit-Change-Number: 33367
Gerrit-PatchSet: 1
Gerrit-Owner: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-MessageType: newchange
Patrick Rudolph has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33663
Change subject: Documentation: Convert cbfs.txt to markdown
......................................................................
Documentation: Convert cbfs.txt to markdown
Convert the document to markdown.
Needs to be fixed in a separate commit as it doesn't reflect coreboot v4.
Change-Id: I0fb2713a9cda08e528902ec641dd4a4e0dc148fe
Signed-off-by: Patrick Rudolph <patrick.rudolph(a)9elements.com>
---
A Documentation/lib/cbfs.md
M Documentation/lib/index.md
2 files changed, 372 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/63/33663/1
diff --git a/Documentation/lib/cbfs.md b/Documentation/lib/cbfs.md
new file mode 100644
index 0000000..83d8b44
--- /dev/null
+++ b/Documentation/lib/cbfs.md
@@ -0,0 +1,371 @@
+# coreboot CBFS Specification
+by Jordan Crouse <jordan(a)cosmicpenguin.net>
+
+**WARNING: This documentation is written against coreboot v1.**
+
+**TODO: Update this document ASAP**
+
+## Introduction
+
+This document describes the coreboot CBFS specification (from here
+referred to as CBFS). CBFS is a scheme for managing independent chunks
+of data in a system ROM. Though not a true filesystem, the style and
+concepts are similar.
+
+
+## Architecture
+
+The CBFS architecture looks like the following:
+
+```
+/---------------\ <-- Start of ROM
+| /-----------\ | --|
+| | Header | | |
+| |-----------| | |
+| | Name | | |-- Component
+| |-----------| | |
+| |Data | | |
+| |.. | | |
+| \-----------/ | --|
+| |
+| /-----------\ |
+| | Header | |
+| |-----------| |
+| | Name | |
+| |-----------| |
+| |Data | |
+| |.. | |
+| \-----------/ |
+| |
+| ... |
+| /-----------\ |
+| | | |
+| | Bootblock | |
+| | --------- | |
+| | Reset | | <- 0xFFFFFFF0
+| \-----------/ |
+\---------------/
+```
+
+The CBFS architecture consists of a binary associated with a physical
+ROM disk referred hereafter as the ROM. A number of independent of
+components, each with a header prepended on to data are located within
+the ROM. The components are nominally arranged sequentially, though they
+are aligned along a pre-defined boundary.
+
+The bootblock occupies the last 20k of the ROM. Within
+the bootblock is a master header containing information about the ROM
+including the size, alignment of the components, and the offset of the
+start of the first CBFS component within the ROM.
+
+## Master Header
+
+The master header contains essential information about the ROM that is
+used by both the CBFS implementation within coreboot at runtime as well
+as host based utilities to create and manage the ROM. The master header
+will be located somewhere within the bootblock (last 20k of the ROM). A
+pointer to the location of the header will be located at offset
+-4 from the end of the ROM. This translates to address 0xFFFFFFFC on a
+normal x86 system. The pointer will be to physical memory somewhere
+between - 0xFFFFB000 and 0xFFFFFFF0. This makes it easier for coreboot
+to locate the header at run time. Build time utilities will
+need to read the pointer and do the appropriate math to locate the header.
+
+The following is the structure of the master header:
+
+```c
+struct cbfs_header {
+ u32 magic;
+ u32 version;
+ u32 romsize;
+ u32 bootblocksize;
+ u32 align;
+ u32 offset;
+ u32 architecture;
+ u32 pad[1];
+} __packed;
+```
+
+The meaning of each member is as follows:
+
+`magic` is a 32 bit number that identifies the ROM as a CBFS type. The
+magic
+number is 0x4F524243, which is 'ORBC' in ASCII.
+
+`version` is a version number for CBFS header. cbfs_header structure may be
+different if version is not matched.
+
+`romsize` is the size of the ROM in bytes. coreboot will subtract 'size' from
+0xFFFFFFFF to locate the beginning of the ROM in memory.
+
+`bootblocksize` is the size of bootblock reserved in firmware image.
+
+`align` is the number of bytes that each component is aligned to within the
+ROM. This is used to make sure that each component is aligned correctly
+with
+regards to the erase block sizes on the ROM - allowing one to replace a
+component at runtime without disturbing the others.
+
+`offset` is the offset of the first CBFS component (from the start of
+the ROM). This is to allow for arbitrary space to be left at the beginning
+of the ROM for things like embedded controller firmware.
+
+`architecture` describes which architecture (x86, arm, ...) this CBFS is created
+for.
+
+## Bootblock
+The bootblock is a mandatory component in the ROM. It is located in the
+last 20k of the ROM space, and contains, among other things, the location of the
+master header and the entry point for the loader firmware. The bootblock
+does not have a component header attached to it.
+
+## Components
+
+CBFS components are placed in the ROM starting at 'offset' specified in
+the master header and ending at the bootblock. Thus the total size
+available for components in the ROM is (ROM size - 20k - 'offset').
+Each CBFS component is to be aligned according to the 'align' value in the
+header.
+Thus, if a component of size 1052 is located at offset 0 with an 'align'
+value of 1024, the next component will be located at offset 2048.
+
+Each CBFS component will be indexed with a unique ASCII string name of
+unlimited size.
+
+Each CBFS component starts with a header:
+
+```c
+struct cbfs_file {
+ char magic[8];
+ unsigned int len;
+ unsigned int type;
+ unsigned int checksum;
+ unsigned int offset;
+};
+```
+
+`magic` is a magic value used to identify the header. During runtime,
+coreboot will scan the ROM looking for this value. The default magic is
+the string 'LARCHIVE'.
+
+`len` is the length of the data, not including the size of the header and
+the size of the name.
+
+`type` is a 32 bit number indicating the type of data that is attached.
+The data type is used in a number of ways, as detailed in the section
+below.
+
+`checksum` is a 32bit checksum of the entire component, including the
+header and name.
+
+`offset` is the start of the component data, based off the start of the
+header.
+The difference between the size of the header and offset is the size of the
+component name.
+
+Immediately following the header will be the name of the component,
+which will null terminated and 16 byte aligned. The following picture shows the
+structure of the header:
+
+```
+/--------\ <- start
+| Header |
+|--------| <- sizeof(struct cbfs_file)
+| Name |
+|--------| <- 'offset'
+| Data |
+| ... |
+\--------/ <- start + 'offset' + 'len'
+```
+
+### Searching Algorithm
+
+To locate a specific component in the ROM, one starts at the 'offset'
+specified in the CBFS master header. For this example, the offset will
+be 0.
+
+From that offset, the code should search for the magic string on the
+component, jumping 'align' bytes each time. So, assuming that 'align' is
+16, the code will search for the string 'LARCHIVE' at offset 0, 16, 32, etc.
+If the offset ever exceeds the allowable range for CBFS components, then no
+component was found.
+
+Upon recognizing a component, the software then has to search for the
+specific name of the component. This is accomplished by comparing the
+desired name with the string on the component located at
+`offset + sizeof(struct cbfs_file)`. If the string matches, then the
+component has been located, otherwise the software should add
+`'offset' + 'len'` to the offset and resume the search for the magic value.
+
+### Data Types
+
+The 'type' member of struct cbfs_file is used to identify the content
+of the component data, and is used by coreboot and other
+run-time entities to make decisions about how to handle the data.
+
+There are three component types that are essential to coreboot, and so
+are defined here.
+
+#### Stages
+
+Stages are code loaded by coreboot during the boot process. They are
+essential to a successful boot. Stages are comprised of a single blob
+of binary data that is to be loaded into a particular location in memory
+and executed. The uncompressed header contains information about how
+large the data is, and where it should be placed, and what additional memory
+needs to be cleared.
+
+Stages are assigned a component value of 0x10. When coreboot sees this
+component type, it knows that it should pass the data to a sub-function
+that will process the stage.
+
+The following is the format of a stage component:
+
+```
+/--------\
+| Header |
+|--------|
+| Binary |
+| .. |
+\--------/
+```
+
+The header is defined as:
+
+```c
+struct cbfs_stage {
+ unsigned int compression;
+ unsigned long long entry;
+ unsigned long long load;
+ unsigned int len;
+ unsigned int memlen;
+};
+```
+
+`compression` is an integer defining how the data is compressed. There
+are three compression types defined by this version of the standard:
+none (0x0), lzma (0x1), and nrv2b (0x02, deprecated), though additional
+types may be added assuming that coreboot understands how to handle the scheme.
+
+`entry` is a 64 bit value indicating the location where the program
+counter should jump following the loading of the stage. This should be
+an absolute physical memory address.
+
+`load` is a 64 bit value indicating where the subsequent data should be
+loaded. This should be an absolute physical memory address.
+
+`len` is the length of the compressed data in the component.
+
+`memlen` is the amount of memory that will be used by the component when
+it is loaded.
+
+The component data will start immediately following the header.
+
+When coreboot loads a stage, it will first zero the memory from 'load' to
+'memlen'. It will then decompress the component data according to the
+specified scheme and place it in memory starting at 'load'. Following that,
+it will jump execution to the address specified by 'entry'.
+Some components are designed to execute directly from the ROM - coreboot
+knows which components must do that and will act accordingly.
+
+#### Payloads
+
+Payloads are loaded by coreboot following the boot process.
+
+Stages are assigned a component value of 0x20. When coreboot sees this
+component type, it knows that it should pass the data to a sub-function
+that will process the payload. Furthermore, other run time applications such
+as 'bayou' may easily index all available payloads
+on the system by searching for the payload type.
+
+
+The following is the format of a stage component:
+
+```
+/-----------\
+| Header |
+| Segment 1 |
+| Segment 2 |
+| ... |
+|-----------|
+| Binary |
+| .. |
+\-----------/
+```
+
+The header is as follows:
+
+```c
+struct cbfs_payload {
+ struct cbfs_payload_segment segments;
+}
+```
+
+The header contains a number of segments corresponding to the segments
+that need to be loaded for the payload.
+
+The following is the structure of each segment header:
+
+```c
+struct cbfs_payload_segment {
+ unsigned int type;
+ unsigned int compression;
+ unsigned int offset;
+ unsigned long long load_addr;
+ unsigned int len;
+ unsigned int mem_len;
+};
+```
+
+`type` is the type of segment, one of the following:
+
+```eval_rst
++----------------------+-------------+---------------------------------------+
+|PAYLOAD_SEGMENT_CODE | 0x45444F43 | The segment contains executable code |
++----------------------+-------------+---------------------------------------+
+|PAYLOAD_SEGMENT_DATA | 0x41544144 | The segment contains data |
++----------------------+-------------+---------------------------------------+
+|PAYLOAD_SEGMENT_BSS | 0x20535342 | The memory specified by the segment |
+| | | should be zeroed |
++----------------------+-------------+---------------------------------------+
+|PAYLOAD_SEGMENT_PARAMS| 0x41524150 | The segment contains information for |
+| | | the payload |
++----------------------+-------------+---------------------------------------+
+|PAYLOAD_SEGMENT_ENTRY | 0x52544E45 | The segment contains the entry point |
+| | | for the payload |
++----------------------+-------------+---------------------------------------+
+```
+
+`compression` is the compression scheme for the segment. Each segment can
+be independently compressed. There are three compression types defined by
+this version of the standard: none (0x0), lzma (0x1), and nrv2b
+(0x02, deprecated), though additional types may be added assuming that
+coreboot understands how to handle the scheme.
+
+`offset` is the address of the data within the component, starting from
+the component header.
+
+`load_addr` is a 64 bit value indicating where the segment should be placed
+in memory.
+
+`len` is a 32 bit value indicating the size of the segment within the
+component.
+
+`mem_len` is the size of the data when it is placed into memory.
+
+The data will located immediately following the last segment.
+
+#### Option ROMS
+
+The third specified component type will be Option ROMs. Option ROMS will
+have component type '0x30'. They will have no additional header, the
+uncompressed binary data will be located in the data portion of the
+component.
+
+#### NULL
+
+There is a 4th component type ,defined as NULL (0xFFFFFFFF). This is
+the "don't care" component type. This can be used when the component
+type is not necessary (such as when the name of the component is unique.
+i.e. option_table). It is recommended that all components be assigned a
+unique type, but NULL can be used when the type does not matter.
diff --git a/Documentation/lib/index.md b/Documentation/lib/index.md
index 99b8061..808bac8 100644
--- a/Documentation/lib/index.md
+++ b/Documentation/lib/index.md
@@ -6,4 +6,5 @@
## Structure and layout
- [Flashmap and Flashmap Descriptor](flashmap.md)
- [ABI data consumption](abi-data-consumption.md)
+- [CBFS](cbfs.md)
- [Timestamps](timestamp.md)
--
To view, visit https://review.coreboot.org/c/coreboot/+/33663
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I0fb2713a9cda08e528902ec641dd4a4e0dc148fe
Gerrit-Change-Number: 33663
Gerrit-PatchSet: 1
Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-MessageType: newchange
Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/32989
Change subject: mb/pcengines/apu2: describe serial ports in ACPI
......................................................................
mb/pcengines/apu2: describe serial ports in ACPI
FreeBSD users had to manually configure serial ports on their
installations. Defining serial ports in ACPI save that effort.
Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Change-Id: I0de4172a1884abbe9d625060a9045c9d71469e27
---
A src/mainboard/pcengines/apu2/acpi/superio.asl
M src/mainboard/pcengines/apu2/dsdt.asl
2 files changed, 68 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/89/32989/1
diff --git a/src/mainboard/pcengines/apu2/acpi/superio.asl b/src/mainboard/pcengines/apu2/acpi/superio.asl
new file mode 100644
index 0000000..c61e3d7
--- /dev/null
+++ b/src/mainboard/pcengines/apu2/acpi/superio.asl
@@ -0,0 +1,65 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2019 PC Engines Gmbh
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+Scope (\_SB.PCI0.LIBR) {
+
+ Device (COM1) {
+ Name (_HID, EISAID ("PNP0501"))
+ Name (_UID, 1)
+
+ Method (_STA, 0, NotSerialized) {
+ Return (0x0F)
+ }
+
+ Name (_CRS, ResourceTemplate ()
+ {
+ IO (Decode16, 0x03F8, 0x3F8, 0x08, 0x08)
+ IRQNoFlags () {4}
+ })
+
+ Name (_PRS, ResourceTemplate ()
+ {
+ StartDependentFn (0, 0) {
+ IO (Decode16, 0x03F8, 0x3F8, 0x08, 0x08)
+ IRQNoFlags () {4}
+ }
+ EndDependentFn ()
+ })
+ }
+
+ Device (COM2) {
+ Name (_HID, EISAID ("PNP0501"))
+ Name (_UID, 2)
+
+ Method (_STA, 0, NotSerialized) {
+ Return (0x0F)
+ }
+
+ Name (_CRS, ResourceTemplate ()
+ {
+ IO (Decode16, 0x02F8, 0x2F8, 0x08, 0x08)
+ IRQNoFlags () {3}
+ })
+
+ Name (_PRS, ResourceTemplate ()
+ {
+ StartDependentFn (0, 0) {
+ IO (Decode16, 0x02F8, 0x2F8, 0x08, 0x08)
+ IRQNoFlags () {3}
+ }
+ EndDependentFn ()
+ })
+ }
+}
\ No newline at end of file
diff --git a/src/mainboard/pcengines/apu2/dsdt.asl b/src/mainboard/pcengines/apu2/dsdt.asl
index 3bf0ed6..409f03d 100644
--- a/src/mainboard/pcengines/apu2/dsdt.asl
+++ b/src/mainboard/pcengines/apu2/dsdt.asl
@@ -81,5 +81,8 @@
/* Define the System Indicators for the platform */
#include "acpi/si.asl"
+
+ /* Super IO devices (COM ports) */
+ #include "acpi/superio.asl"
}
/* End of ASL file */
--
To view, visit https://review.coreboot.org/c/coreboot/+/32989
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I0de4172a1884abbe9d625060a9045c9d71469e27
Gerrit-Change-Number: 32989
Gerrit-PatchSet: 1
Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com>
Gerrit-MessageType: newchange
Rizwan Qureshi has uploaded this change for review. ( https://review.coreboot.org/c/vboot/+/32679
Change subject: vboot: Fix build error related to VB2_SHARED_DATA_VERSION_MINOR
......................................................................
vboot: Fix build error related to VB2_SHARED_DATA_VERSION_MINOR
vboot fails to compile with the error
"error: comparison is always false due to limited range
of data type [-Werror=type-limits]"
since struct_version_minor is uint16_t and can never be less than
VB2_SHARED_DATA_VERSION_MINOR (0)
Signed-off-by: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Change-Id: I0e68981fbecafe7ba40e00ee657e82c024a89325
---
M firmware/2lib/2misc.c
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/vboot refs/changes/79/32679/1
diff --git a/firmware/2lib/2misc.c b/firmware/2lib/2misc.c
index 95cbae3..195a0f9 100644
--- a/firmware/2lib/2misc.c
+++ b/firmware/2lib/2misc.c
@@ -128,7 +128,7 @@
return VB2_ERROR_SHARED_DATA_MAGIC;
if (sd->struct_version_major != VB2_SHARED_DATA_VERSION_MAJOR ||
- sd->struct_version_minor < VB2_SHARED_DATA_VERSION_MINOR)
+ sd->struct_version_minor != VB2_SHARED_DATA_VERSION_MINOR)
return VB2_ERROR_SHARED_DATA_VERSION;
return VB2_SUCCESS;
--
To view, visit https://review.coreboot.org/c/vboot/+/32679
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: vboot
Gerrit-Branch: master
Gerrit-Change-Id: I0e68981fbecafe7ba40e00ee657e82c024a89325
Gerrit-Change-Number: 32679
Gerrit-PatchSet: 1
Gerrit-Owner: Rizwan Qureshi <rizwan.qureshi(a)intel.com>
Gerrit-MessageType: newchange
Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30470
Change subject: mb/intel/dg41wv: Inherit the subsystemid
......................................................................
mb/intel/dg41wv: Inherit the subsystemid
Don't reprogram the same subsystemid for each PCI device.
Change-Id: Ieaeef728e200bfa826c4ae25de3e8532c493c877
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
---
M src/mainboard/intel/dg41wv/devicetree.cb
1 file changed, 23 insertions(+), 46 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/70/30470/1
diff --git a/src/mainboard/intel/dg41wv/devicetree.cb b/src/mainboard/intel/dg41wv/devicetree.cb
index d96ad95..da91ea2 100644
--- a/src/mainboard/intel/dg41wv/devicetree.cb
+++ b/src/mainboard/intel/dg41wv/devicetree.cb
@@ -24,14 +24,10 @@
end
end
device domain 0 on # PCI domain
- subsystemid 0x1458 0x5000 inherit
- device pci 0.0 on # Host Bridge
- subsystemid 0x8086 0x5756
- end
+ subsystemid 0x8086 0x5756 inherit
+ device pci 0.0 on end # Host Bridge
device pci 1.0 on end # PEG
- device pci 2.0 on # Integrated graphics controller
- subsystemid 0x8086 0x5756
- end
+ device pci 2.0 on end # Integrated graphics controller
chip southbridge/intel/i82801gx # Southbridge
register "pirqa_routing" = "0x0b"
register "pirqb_routing" = "0x0b"
@@ -66,39 +62,24 @@
register "sata_ahci" = "0x0" # AHCI not supported on this ICH7 variant
register "gpe0_en" = "0x440"
- device pci 1b.0 on # Audio
- subsystemid 0x8086 0x5756
+ device pci 1b.0 on end # Audio
+ device pci 1c.0 on end # PCIe 1
+ device pci 1c.1 on # PCIe 2: NIC
+ device pci 00.0 on end
end
- device pci 1c.0 on end # PCIe 1
- device pci 1c.1 on # PCIe 2: NIC
- device pci 00.0 on
- subsystemid 0x8086 0x5756
- end
- end
- device pci 1c.2 off end # PCIe 3
- device pci 1c.3 off end # PCIe 4
- device pci 1c.4 off end # PCIe 5
- device pci 1c.5 off end # PCIe 6
- device pci 1d.0 on # USB
- subsystemid 0x8086 0x5756
- end
- device pci 1d.1 on # USB
- subsystemid 0x8086 0x5756
- end
- device pci 1d.2 on # USB
- subsystemid 0x8086 0x5756
- end
- device pci 1d.3 on # USB
- subsystemid 0x8086 0x5756
- end
- device pci 1d.7 on # USB
- subsystemid 0x8086 0x5756
- end
- device pci 1e.0 on end # PCI bridge
- device pci 1e.2 off end # AC'97 Audio Controller
- device pci 1e.3 off end # AC'97 Modem Controller
- device pci 1f.0 on # ISA bridge
- subsystemid 0x8086 0x5756
+ device pci 1c.2 off end # PCIe 3
+ device pci 1c.3 off end # PCIe 4
+ device pci 1c.4 off end # PCIe 5
+ device pci 1c.5 off end # PCIe 6
+ device pci 1d.0 on end # USB
+ device pci 1d.1 on end # USB
+ device pci 1d.2 on end # USB
+ device pci 1d.3 on end # USB
+ device pci 1d.7 on end # USB
+ device pci 1e.0 on end # PCI bridge
+ device pci 1e.2 off end # AC'97 Audio Controller
+ device pci 1e.3 off end # AC'97 Modem Controller
+ device pci 1f.0 on # ISA bridge
chip superio/winbond/w83627dhg
device pnp 2e.0 on # Floppy
# global
@@ -155,12 +136,9 @@
end
end
device pci 1f.1 off end # PATA/IDE
- device pci 1f.2 on # SATA
- subsystemid 0x8086 0x5756
- end
- device pci 1f.3 on # SMbus
- subsystemid 0x8086 0x5756
- chip drivers/i2c/ck505
+ device pci 1f.2 on end # SATA
+ device pci 1f.3 on # SMbus
+ chip drivers/i2c/ck505
register "mask" = "{ 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
@@ -173,7 +151,6 @@
0x06, 0x00, 0xea }"
device i2c 69 on end
end
-
end
end
end
--
To view, visit https://review.coreboot.org/c/coreboot/+/30470
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ieaeef728e200bfa826c4ae25de3e8532c493c877
Gerrit-Change-Number: 30470
Gerrit-PatchSet: 1
Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-MessageType: newchange