Tim Wawrzynczak has submitted this change. ( https://review.coreboot.org/c/coreboot/+/42072 )
Change subject: libpayload: drivers/usb: add a USB pre-poll hook
......................................................................
libpayload: drivers/usb: add a USB pre-poll hook
This adds a hook so that a payload can optionally perform USB service
functions in conjunction with regular USB port status polling. In
particular, this allows depthcharge to control the state of an
external USB mux. Some SoCs like Tiger Lake have a USB mux for Type-C
ports that must be kept in sync with the state of the port as reported
by the TCPC. This can be achieved by hooking into the poll routine to
refresh the state of the USB mux.
BUG=b:149883933
TEST=booted into recovery from Type-C flash drive on volteer
Change-Id: Ic6c23756f64b891b3c5683cd650c605b8630b0fb
Signed-off-by: Caveh Jalali <caveh(a)chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42072
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
Reviewed-by: Julius Werner <jwerner(a)chromium.org>
---
M payloads/libpayload/drivers/usb/usb.c
M payloads/libpayload/include/usb/usb.h
2 files changed, 11 insertions(+), 0 deletions(-)
Approvals:
build bot (Jenkins): Verified
Julius Werner: Looks good to me, approved
diff --git a/payloads/libpayload/drivers/usb/usb.c b/payloads/libpayload/drivers/usb/usb.c
index accb228..b14abb4 100644
--- a/payloads/libpayload/drivers/usb/usb.c
+++ b/payloads/libpayload/drivers/usb/usb.c
@@ -86,6 +86,10 @@
{
if (usb_hcs == 0)
return;
+
+ if (usb_poll_prepare)
+ usb_poll_prepare();
+
hci_t *controller = usb_hcs;
while (controller != NULL) {
int i;
diff --git a/payloads/libpayload/include/usb/usb.h b/payloads/libpayload/include/usb/usb.h
index 8f3169e..f79fc27 100644
--- a/payloads/libpayload/include/usb/usb.h
+++ b/payloads/libpayload/include/usb/usb.h
@@ -345,6 +345,13 @@
}
/**
+ * To be implemented by libpayload-client. It's called by the USB
+ * stack just before iterating over known devices to poll them for
+ * status change.
+ */
+void __attribute__((weak)) usb_poll_prepare (void);
+
+/**
* To be implemented by libpayload-client. It's called by the USB stack
* when a new USB device is found which isn't claimed by a built in driver,
* so the client has the chance to know about it.
--
To view, visit https://review.coreboot.org/c/coreboot/+/42072
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ic6c23756f64b891b3c5683cd650c605b8630b0fb
Gerrit-Change-Number: 42072
Gerrit-PatchSet: 3
Gerrit-Owner: Caveh Jalali <caveh(a)chromium.org>
Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-MessageType: merged
Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41155 )
Change subject: soc/intel/common/block/systemagent: Use TOUUD as base for MMIO above 4G
......................................................................
soc/intel/common/block/systemagent: Use TOUUD as base for MMIO above 4G
This change sets the base for MMIO above 4G to TOUDD. It matches what
is used by resource allocator if MMIO resources are allocated above 4G
and also matches the expectation in northbridge.asl.
BUG=b:149186922
TEST=Verified that kernel does not complain about MMIO windows above
4G.
Signed-off-by: Furquan Shaikh <furquan(a)google.com>
Change-Id: Ibbbfbdad867735a43cf57c256bf206a3f040f383
---
M src/soc/intel/common/block/systemagent/systemagent.c
1 file changed, 31 insertions(+), 28 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/55/41155/1
diff --git a/src/soc/intel/common/block/systemagent/systemagent.c b/src/soc/intel/common/block/systemagent/systemagent.c
index d0e171d..9354c25 100644
--- a/src/soc/intel/common/block/systemagent/systemagent.c
+++ b/src/soc/intel/common/block/systemagent/systemagent.c
@@ -42,34 +42,6 @@
}
/*
- * This function will get above 4GB mmio enable config specific to soc.
- *
- * Return values:
- * 0 = Above 4GB memory is not enable
- * 1 = Above 4GB memory is enable
- */
-static int get_enable_above_4GB_mmio(void)
-{
- const struct soc_intel_common_config *common_config;
- common_config = chip_get_common_soc_structure();
-
- return common_config->enable_above_4GB_mmio;
-}
-
-/* Fill MMIO resource above 4GB into GNVS */
-void sa_fill_gnvs(global_nvs_t *gnvs)
-{
- if (get_enable_above_4GB_mmio()) {
- gnvs->e4gm = 1;
- gnvs->a4gb = ABOVE_4GB_MEM_BASE_ADDRESS;
- gnvs->a4gs = ABOVE_4GB_MEM_BASE_SIZE;
- printk(BIOS_DEBUG,
- "PCI space above 4GB MMIO is from 0x%llx to len = 0x%llx\n",
- gnvs->a4gb, gnvs->a4gs);
- }
-}
-
-/*
* Add all known fixed MMIO ranges that hang off the host bridge/memory
* controller device.
*/
@@ -125,6 +97,37 @@
*result = value;
}
+/*
+ * This function will get above 4GB mmio enable config specific to soc.
+ *
+ * Return values:
+ * 0 = Above 4GB memory is not enable
+ * 1 = Above 4GB memory is enable
+ */
+static int get_enable_above_4GB_mmio(void)
+{
+ const struct soc_intel_common_config *common_config;
+ common_config = chip_get_common_soc_structure();
+
+ return common_config->enable_above_4GB_mmio;
+}
+
+/* Fill MMIO resource above 4GB into GNVS */
+void sa_fill_gnvs(global_nvs_t *gnvs)
+{
+ if (!get_enable_above_4GB_mmio())
+ return;
+
+ struct device *sa_dev = pcidev_path_on_root(SA_DEVFN_ROOT);
+
+ gnvs->e4gm = 1;
+ sa_read_map_entry(sa_dev, &sa_memory_map[SA_TOUUD_REG], &gnvs->a4gb);
+ gnvs->a4gs = ABOVE_4GB_MEM_BASE_SIZE;
+ printk(BIOS_DEBUG, "PCI space above 4GB MMIO is from 0x%llx to len = 0x%llx\n",
+ gnvs->a4gb, gnvs->a4gs);
+}
+
+
static void sa_get_mem_map(struct device *dev, uint64_t *values)
{
int i;
--
To view, visit https://review.coreboot.org/c/coreboot/+/41155
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ibbbfbdad867735a43cf57c256bf206a3f040f383
Gerrit-Change-Number: 41155
Gerrit-PatchSet: 1
Gerrit-Owner: Furquan Shaikh <furquan(a)google.com>
Gerrit-MessageType: newchange
Eugene Myers has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41829 )
Change subject: [WIP] cpu/x86/smm: Enable SMM support for Xeon-SP
......................................................................
Patch Set 3:
(2 comments)
> Patch Set 3:
>
> (18 comments)
>
> > Patch Set 2:
> >
> > > Patch Set 2:
> > >
> > > (3 comments)
> > >
> > > This change is ready for review.
> >
> > Fat finger - needs changes first.
>
> Eugene,
> Thank you for the review. I've uploaded patch set 3 with your feedback. I also updated the SMRAM layout map (described on top of smm_load_module). STM stays as is. Moved stacks to the start of SMRAM since stacks grow downward and they can't corrupt any SMM code. SMM GDT (global descriptor table) is set for flat code and flat data, so there are no protections. By having stacks on top, in theory they could grow downward enough to corrupt code and data, though we have a canary in place, it could still cause problems. That is my reasoning for moving stacks to the bottom for better protection (unless we change the descriptor for stack segment and make it bound, then it can be anywhere in SMRAM).
Rocky,
I've ported your code to my test system and realized that there were a couple of issues.
The first is the location of the fxsave area, the calculation placed the area outside of SMRAM.
The second is that the algorithm to place the entrypoints has to account for the SMM save state areas. I've borrowed some documentation to help give you a start.
gene
https://review.coreboot.org/c/coreboot/+/41829/3/src/cpu/x86/smm/smm_module…
File src/cpu/x86/smm/smm_module_loader.c:
https://review.coreboot.org/c/coreboot/+/41829/3/src/cpu/x86/smm/smm_module…
PS3, Line 96:
When building these segments the algorithm needs to account for the SMM save state size and location. This area includes the SMM save state and the TXT Processor SMM Descriptor.
That layout is as follows:
SMBASE+0xFC00 SMM Save state map
SMBASE+0xFB00 TXT Processor SMM Descriptor
SMBASE+0x8000 Entry point
SMBASE
I believe what you are trying to do is something like this:
(note: this diagram is from - https://github.com/jyao1/STM/blob/master/Bios/StmCpuPkg/PiSmmCpuDxeSmm/PiSm… )
//
// The CPU save state and code for the SMI entry point are tiled within an SMRAM
// allocated buffer. The minimum size of this buffer for a uniprocessor system
// is 32 KB, because the entry point is SMBASE + 32KB, and CPU save state area
// just below SMBASE + 64KB. If more than one CPU is present in the platform,
// then the SMI entry point and the CPU save state areas can be tiles to minimize
// the total amount SMRAM required for all the CPUs. The tile size can be computed
// by adding the // CPU save state size, any extra CPU specific context, and
// the size of code that must be placed at the SMI entry point to transfer
// control to a C function in the native SMM execution mode. This size is
// rounded up to the nearest power of 2 to give the tile size for a each CPU.
// The total amount of memory required is the maximum number of CPUs that
// platform supports times the tile size. The picture below shows the tiling,
// where m is the number of tiles that fit in 32KB.
//
// +-----------------------------+ <-- 2^n offset from Base of allocated buffer
// | CPU m+1 Save State |
// +-----------------------------+
// | CPU m+1 Extra Data |
// +-----------------------------+
// | Padding |
// +-----------------------------+
// | CPU 2m SMI Entry |
// +#############################+ <-- Base of allocated buffer + 64 KB
// | CPU m-1 Save State |
// +-----------------------------+
// | CPU m-1 Extra Data |
// +-----------------------------+
// | Padding |
// +-----------------------------+
// | CPU 2m-1 SMI Entry |
// +=============================+ <-- 2^n offset from Base of allocated buffer
// | . . . . . . . . . . . . |
// +=============================+ <-- 2^n offset from Base of allocated buffer
// | CPU 2 Save State |
// +-----------------------------+
// | CPU 2 Extra Data |
// +-----------------------------+
// | Padding |
// +-----------------------------+
// | CPU m+1 SMI Entry |
// +=============================+ <-- Base of allocated buffer + 32 KB
// | CPU 1 Save State |
// +-----------------------------+
// | CPU 1 Extra Data |
// +-----------------------------+
// | Padding |
// +-----------------------------+
// | CPU m SMI Entry |
// +#############################+ <-- Base of allocated buffer + 32 KB == CPU 0 SMBASE + 64 KB
// | CPU 0 Save State |
// +-----------------------------+
// | CPU 0 Extra Data |
// +-----------------------------+
// | Padding |
// +-----------------------------+
// | CPU m-1 SMI Entry |
// +=============================+ <-- 2^n offset from Base of allocated buffer
// | . . . . . . . . . . . . |
// +=============================+ <-- 2^n offset from Base of allocated buffer
// | Padding |
// +-----------------------------+
// | CPU 1 SMI Entry |
// +=============================+ <-- 2^n offset from Base of allocated buffer
// | Padding |
// +-----------------------------+
// | CPU 0 SMI Entry |
// +#############################+ <-- Base of allocated buffer == CPU 0 SMBASE + 32 KB
https://review.coreboot.org/c/coreboot/+/41829/3/src/cpu/x86/smm/smm_module…
PS3, Line 573: fxsave_area -= total_stack_size + fxsave_size;
This calculation can place the location of the fxsave_area below the bottom of the TSEG. deleting the above line will place the fxsave_area above the stack. If you use base at this point for the location it will be below the MSEG + BIOS resource list
--
To view, visit https://review.coreboot.org/c/coreboot/+/41829
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I78bd74c11ca42fb430f63711b5ec87d4bfe6ca2a
Gerrit-Change-Number: 41829
Gerrit-PatchSet: 3
Gerrit-Owner: Rocky Phagura
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: David Hendricks <david.hendricks(a)gmail.com>
Gerrit-Reviewer: Eugene Myers <cedarhouse1(a)comcast.net>
Gerrit-Reviewer: Eugene Myers <cedarhouse(a)comcast.net>
Gerrit-Reviewer: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Reviewer: Martin Roth <martinroth(a)google.com>
Gerrit-Reviewer: Naresh Solanki <naresh.solanki.2011(a)gmail.com>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Ron Minnich <rminnich(a)google.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: HAOUAS Elyes <ehaouas(a)noos.fr>
Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Comment-Date: Fri, 05 Jun 2020 20:46:30 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Hello wouter.eckhardt(a)prodrive-technologies.com, Philipp Deppenwiese, build bot (Jenkins), Guido Beyer @ Prodrive Technologies, Justin van Son, Nico Huber, Patrick Georgi, Martin Roth, Patrick Rudolph, Patrick Rudolph, Stef van Os,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/37441
to look at the new patch set (#49).
Change subject: src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F
......................................................................
src/mainboard/supermicro/x11-lga1151v2-series: Add Support for X11SCH-F
This commit adds initial support for the Supermicro X11SCH-F.
What is working:
* Aspeed AST2500 Graphics Output
* Serial Console
* SuperIO DevTree Config
* Boots into Linux
* SATA Slots
* USB Slots
* IPMI KCS
* LinuxBoot
* Proper ACPI Tables
* Windows Support
* TPM Support (w/ patched IFD) - Patch IFD at 0x235=03 and 0x13E=84
Tested with Intel Xeon E-2186G and 64 GB ECC RAM.
Change-Id: I0ab1cb9462607b9af068bc2374508d99c60d0a30
Signed-off-by: Christian Walter <christian.walter(a)9elements.com>
---
M Documentation/mainboard/index.md
A Documentation/mainboard/supermicro/x11-lga1151v2-series/x11-lga1151v2-series.md
A Documentation/mainboard/supermicro/x11-lga1151v2-series/x11sch-f/x11sch-f.md
A Documentation/mainboard/supermicro/x11-lga1151v2-series/x11sch-f/x11sch-f_flash.jpg
A src/mainboard/supermicro/x11-lga1151v2-series/Kconfig
A src/mainboard/supermicro/x11-lga1151v2-series/Kconfig.name
A src/mainboard/supermicro/x11-lga1151v2-series/Makefile.inc
A src/mainboard/supermicro/x11-lga1151v2-series/acpi_tables.c
A src/mainboard/supermicro/x11-lga1151v2-series/board_info.txt
A src/mainboard/supermicro/x11-lga1151v2-series/bootblock.c
A src/mainboard/supermicro/x11-lga1151v2-series/devicetree.cb
A src/mainboard/supermicro/x11-lga1151v2-series/dsdt.asl
A src/mainboard/supermicro/x11-lga1151v2-series/memory.c
A src/mainboard/supermicro/x11-lga1151v2-series/ramstage.c
A src/mainboard/supermicro/x11-lga1151v2-series/romstage.c
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/Makefile.inc
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/board_info.txt
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/gpio.c
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/include/variant/gpio.h
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/include/variant/variants.h
A src/mainboard/supermicro/x11-lga1151v2-series/variants/x11sch-f/overridetree.cb
21 files changed, 1,027 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/41/37441/49
--
To view, visit https://review.coreboot.org/c/coreboot/+/37441
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I0ab1cb9462607b9af068bc2374508d99c60d0a30
Gerrit-Change-Number: 37441
Gerrit-PatchSet: 49
Gerrit-Owner: Christian Walter <christian.walter(a)9elements.com>
Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com>
Gerrit-Reviewer: Guido Beyer @ Prodrive Technologies <guido.beyer(a)prodrive-technologies.com>
Gerrit-Reviewer: Justin van Son <justin.van.son(a)prodrive-technologies.com>
Gerrit-Reviewer: Martin Roth <martinroth(a)google.com>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki(a)gmail.com>
Gerrit-Reviewer: Stef van Os <stef.van.os(a)prodrive-technologies.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Reviewer: wouter.eckhardt(a)prodrive-technologies.com
Gerrit-MessageType: newpatchset
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/42020 )
Change subject: drivers/ipmi: drop redundant option `wait_for_bmc`
......................................................................
Patch Set 2:
(2 comments)
https://review.coreboot.org/c/coreboot/+/42020/2/src/drivers/ipmi/ipmi_kcs_…
File src/drivers/ipmi/ipmi_kcs_ops.c:
https://review.coreboot.org/c/coreboot/+/42020/2/src/drivers/ipmi/ipmi_kcs_…
PS2, Line 87: Get IPMI version for ACPI and SMBIOS
> that comment is a lie \o/ we don't get *anything* here
This block is actually checking if the BMC is alive, or that is what it looks like...
https://review.coreboot.org/c/coreboot/+/42020/2/src/drivers/ipmi/ipmi_kcs_…
PS2, Line 107: retry_count < conf->bmc_boot_timeout
> Comparing u8 < u16 is a potential endless loop.
Yes, should we change retry_count or bmc_boot_timeout's type?
--
To view, visit https://review.coreboot.org/c/coreboot/+/42020
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Id26f85e82a13f53a3731ab88035f2ae4bbffac00
Gerrit-Change-Number: 42020
Gerrit-PatchSet: 2
Gerrit-Owner: Michael Niewöhner
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Jonathan Kollasch <jakllsch(a)kollasch.net>
Gerrit-Reviewer: Michael Niewöhner
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph
Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Comment-Date: Fri, 05 Jun 2020 12:28:44 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Nico Huber <nico.h(a)gmx.de>
Comment-In-Reply-To: Michael Niewöhner
Gerrit-MessageType: comment