Felix Singer has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/44028 )
Change subject: soc/intel/skylake: Enable SDXC depending on devicetree configuration
......................................................................
soc/intel/skylake: Enable SDXC depending on devicetree configuration
Currently SDXC gets enabled by the option ScsSdCardEnabled,
but this duplicates the devicetree on/off options. Therefore use the
on/off options for the enablement of the SDXC controller.
I checked all corresponding mainboards if the devicetree configuration
matches the ScsSdCardEnabled setting.
Change-Id: I298b7d0b0fe2a7346dbadcea4be22dc67fce4de8
Signed-off-by: Felix Singer <felixsinger(a)posteo.net>
---
M src/soc/intel/skylake/chip.c
M src/soc/intel/skylake/chip.h
2 files changed, 3 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/28/44028/1
diff --git a/src/soc/intel/skylake/chip.c b/src/soc/intel/skylake/chip.c
index 6423cf4..cb0d2fc 100644
--- a/src/soc/intel/skylake/chip.c
+++ b/src/soc/intel/skylake/chip.c
@@ -257,7 +257,9 @@
dev = pcidev_path_on_root(PCH_DEVFN_EMMC);
params->ScsEmmcEnabled = dev ? dev->enabled : 0;
params->ScsEmmcHs400Enabled = config->ScsEmmcHs400Enabled;
- params->ScsSdCardEnabled = config->ScsSdCardEnabled;
+
+ dev = pcidev_path_on_root(PCH_DEVFN_SDCARD);
+ params->ScsSdCardEnabled = dev && dev->enabled;
if (!!params->ScsEmmcHs400Enabled && !!config->EmmcHs400DllNeed) {
params->PchScsEmmcHs400DllDataValid =
diff --git a/src/soc/intel/skylake/chip.h b/src/soc/intel/skylake/chip.h
index e332a6b..404a9f4 100644
--- a/src/soc/intel/skylake/chip.h
+++ b/src/soc/intel/skylake/chip.h
@@ -306,7 +306,6 @@
/* eMMC and SD */
u8 ScsEmmcHs400Enabled;
- u8 ScsSdCardEnabled;
u8 EmmcHs400DllNeed;
u8 ScsEmmcHs400RxStrobeDll1;
u8 ScsEmmcHs400TxDataDll;
--
To view, visit https://review.coreboot.org/c/coreboot/+/44028
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I298b7d0b0fe2a7346dbadcea4be22dc67fce4de8
Gerrit-Change-Number: 44028
Gerrit-PatchSet: 1
Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net>
Gerrit-MessageType: newchange
Felix Singer has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/44297 )
Change subject: mb/asrock/h110m: Fix devicetree and unwanted rebase
......................................................................
mb/asrock/h110m: Fix devicetree and unwanted rebase
Unfortunately it came to an unwanted rebase while changing the commit
message with gerrit at CB:44026, which breaks building the Asrock H110M
on master. Therefore remove Device4Enable from devicetree, since it
doesn't exist anymore.
It looks like with changing the commit message at CB:44026, gerrit rebased all
previous commits on master. In this case, this is CB:44027. The rebase
is not mentioned in the log, but the diff between patchset 1 and
patchset 2 (which is new and not made by me) shows that the parent changed.
CB:43919 relocated several devicetree options, including the option
Device4Enable, and to me it looks like with the rebase this line just
disappeared for gerrit and thus it just removed it from CB:44026.
Change-Id: I848b6442a16f392b71b80bf82c8337bf46d7d771
Signed-off-by: Felix Singer <felixsinger(a)posteo.net>
---
M src/mainboard/asrock/h110m/devicetree.cb
1 file changed, 1 insertion(+), 3 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/97/44297/1
diff --git a/src/mainboard/asrock/h110m/devicetree.cb b/src/mainboard/asrock/h110m/devicetree.cb
index 68ef2a4..6de2a63 100644
--- a/src/mainboard/asrock/h110m/devicetree.cb
+++ b/src/mainboard/asrock/h110m/devicetree.cb
@@ -152,9 +152,7 @@
device pci 02.0 on # Integrated Graphics Device
subsystemid 0x1849 0x1912
end
- device pci 04.0 on # Thermal Subsystem
- register "Device4Enable" = "1"
- end
+ device pci 04.0 on end # Thermal Subsystem
device pci 08.0 off end # Gaussian Mixture Model
device pci 14.0 on # USB xHCI
subsystemid 0x1849 0xa131
--
To view, visit https://review.coreboot.org/c/coreboot/+/44297
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I848b6442a16f392b71b80bf82c8337bf46d7d771
Gerrit-Change-Number: 44297
Gerrit-PatchSet: 1
Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net>
Gerrit-MessageType: newchange
Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44244 )
Change subject: [RFC|WIP] soc/intel/skylake: replace native SGX initialization by FSP
......................................................................
Patch Set 2:
> Patch Set 2:
>
> > Patch Set 2:
> >
> > > Patch Set 2:
> > >
> > > > Patch Set 2:
> > > >
> > > > > Patch Set 2:
> > > > >
> > > > > > Patch Set 2:
> > > > > >
> > > > > > > Patch Set 2:
> > > > > > >
> > > > > > > if i remember correctly, this programming sequence requirement was from cannon-lake onwards. skylake/kabylake can still use native (coreboot) sgx init flow.
> > > > > >
> > > > > > On SKL LT_MEMORY_LOCK has to be set, too, and FSP does this with SkipMpInit=0. AFAICT native SGX init can't be used on SKL for the same reasons we can't use it on CNL.
> > > > > >
> > > > > > >
> > > > > > > From cannon-lake onwards, sgx init needs fsp for the reasons mentioned in https://review.coreboot.org/c/coreboot/+/36356/2/src/soc/intel/cannonlake/f…. i guess mp-ppi may also be used for cannon-lake onwards. Please follow Nate's recommendation for that.
> > > > > > >
> > > > > > > PS: I see my gmail was added earlier and that notification was in spam. Thanks for adding my @intel email. I am off next week, I’ll respond the following week if there are follow-up questions.
> > > > > >
> > > > > > See CB:36356. Native SGX init is not used in CNL, so there is nothing more to do.
> > > > >
> > > > > "FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."* I dont think i got into this issue when i wrote native sgx init flow. At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected.
> > > > >
> > > > > @Nate: is this* valid for SKL/KBL as well?
> > > >
> > >
> > > Yes, this is valid and exactly the point, why native SGX init can't be used. LT_MEMORY_LOCK must be set, *before* native SGX init (well, more specifically before microcode reload). That conflicts with the requirement of FSP-S to be able to write registers.
> > >
> > > > At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected
> > >
> > > Yes, SGX works. No, not in a secure way with native SGX init without LT_MEMORY_LOCK.
> >
> > in my original code i.e. native sgx init, i was doing exactly that.
> > lock LT mem, reload ucode and so on. (my original code below - commit 418535e222ccd9f688facbb7d9663ca4cacc2739) which was working.
No, it was not working, because FSP-S can't lock TSEGMB and PAVPC. See the relation chain of this CB, please.
> >
> > void sgx_configure(void)
> > {
> > const void *microcode_patch = intel_mp_current_microcode();
> >
> > if (!soc_sgx_enabled() || !is_sgx_supported() || !is_prmrr_set()) {
> > printk(BIOS_ERR, "SGX: pre-conditions not met\n");
> > return;
> > }
> >
> > /* Enable the SGX feature */
> > enable_sgx();
> >
> > /* Update the owner epoch value */
> > if (owner_epoch_update() < 0)
> > return;
> >
> > /* Ensure to lock memory before reload microcode patch */
> > cpu_lock_sgx_memory();
> >
> > /* Reload the microcode patch */
> > intel_microcode_load_unlocked(microcode_patch);
> >
> > /* Lock the SGX feature */
> > lock_sgx();
> >
> > /* Activate the SGX feature, if PRMRR config was aprroved by MCHECK */
> > if (is_prmrr_approved())
> > activate_sgx();
> > }
>
> I'll let Nate comment on "FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."*
That was already discussed and ack'ed by him.
--
To view, visit https://review.coreboot.org/c/coreboot/+/44244
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4251c6f1155ae7d1f0cd9064af55cd346ec88845
Gerrit-Change-Number: 44244
Gerrit-PatchSet: 2
Gerrit-Owner: Michael Niewöhner
Gerrit-Reviewer: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: Nathaniel L Desimone <nathaniel.l.desimone(a)intel.com>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Reviewer: Pratik Prajapati <pratik.prajapati(a)gmail.com>
Gerrit-Reviewer: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Comment-Date: Fri, 07 Aug 2020 23:44:02 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Pratikkumar V Prajapati has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44244 )
Change subject: [RFC|WIP] soc/intel/skylake: replace native SGX initialization by FSP
......................................................................
Patch Set 2:
> Patch Set 2:
>
> > Patch Set 2:
> >
> > > Patch Set 2:
> > >
> > > > Patch Set 2:
> > > >
> > > > > Patch Set 2:
> > > > >
> > > > > > Patch Set 2:
> > > > > >
> > > > > > if i remember correctly, this programming sequence requirement was from cannon-lake onwards. skylake/kabylake can still use native (coreboot) sgx init flow.
> > > > >
> > > > > On SKL LT_MEMORY_LOCK has to be set, too, and FSP does this with SkipMpInit=0. AFAICT native SGX init can't be used on SKL for the same reasons we can't use it on CNL.
> > > > >
> > > > > >
> > > > > > From cannon-lake onwards, sgx init needs fsp for the reasons mentioned in https://review.coreboot.org/c/coreboot/+/36356/2/src/soc/intel/cannonlake/f…. i guess mp-ppi may also be used for cannon-lake onwards. Please follow Nate's recommendation for that.
> > > > > >
> > > > > > PS: I see my gmail was added earlier and that notification was in spam. Thanks for adding my @intel email. I am off next week, I’ll respond the following week if there are follow-up questions.
> > > > >
> > > > > See CB:36356. Native SGX init is not used in CNL, so there is nothing more to do.
> > > >
> > > > "FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."* I dont think i got into this issue when i wrote native sgx init flow. At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected.
> > > >
> > > > @Nate: is this* valid for SKL/KBL as well?
> > >
> >
> > Yes, this is valid and exactly the point, why native SGX init can't be used. LT_MEMORY_LOCK must be set, *before* native SGX init (well, more specifically before microcode reload). That conflicts with the requirement of FSP-S to be able to write registers.
> >
> > > At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected
> >
> > Yes, SGX works. No, not in a secure way with native SGX init without LT_MEMORY_LOCK.
>
> in my original code i.e. native sgx init, i was doing exactly that.
> lock LT mem, reload ucode and so on. (my original code below - commit 418535e222ccd9f688facbb7d9663ca4cacc2739) which was working.
>
> void sgx_configure(void)
> {
> const void *microcode_patch = intel_mp_current_microcode();
>
> if (!soc_sgx_enabled() || !is_sgx_supported() || !is_prmrr_set()) {
> printk(BIOS_ERR, "SGX: pre-conditions not met\n");
> return;
> }
>
> /* Enable the SGX feature */
> enable_sgx();
>
> /* Update the owner epoch value */
> if (owner_epoch_update() < 0)
> return;
>
> /* Ensure to lock memory before reload microcode patch */
> cpu_lock_sgx_memory();
>
> /* Reload the microcode patch */
> intel_microcode_load_unlocked(microcode_patch);
>
> /* Lock the SGX feature */
> lock_sgx();
>
> /* Activate the SGX feature, if PRMRR config was aprroved by MCHECK */
> if (is_prmrr_approved())
> activate_sgx();
> }
I'll let Nate comment on "FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."*
--
To view, visit https://review.coreboot.org/c/coreboot/+/44244
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4251c6f1155ae7d1f0cd9064af55cd346ec88845
Gerrit-Change-Number: 44244
Gerrit-PatchSet: 2
Gerrit-Owner: Michael Niewöhner
Gerrit-Reviewer: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: Nathaniel L Desimone <nathaniel.l.desimone(a)intel.com>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Reviewer: Pratik Prajapati <pratik.prajapati(a)gmail.com>
Gerrit-Reviewer: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Comment-Date: Fri, 07 Aug 2020 22:56:44 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Pratikkumar V Prajapati has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/44244 )
Change subject: [RFC|WIP] soc/intel/skylake: replace native SGX initialization by FSP
......................................................................
Patch Set 2:
> Patch Set 2:
>
> > Patch Set 2:
> >
> > > Patch Set 2:
> > >
> > > > Patch Set 2:
> > > >
> > > > > Patch Set 2:
> > > > >
> > > > > if i remember correctly, this programming sequence requirement was from cannon-lake onwards. skylake/kabylake can still use native (coreboot) sgx init flow.
> > > >
> > > > On SKL LT_MEMORY_LOCK has to be set, too, and FSP does this with SkipMpInit=0. AFAICT native SGX init can't be used on SKL for the same reasons we can't use it on CNL.
> > > >
> > > > >
> > > > > From cannon-lake onwards, sgx init needs fsp for the reasons mentioned in https://review.coreboot.org/c/coreboot/+/36356/2/src/soc/intel/cannonlake/f…. i guess mp-ppi may also be used for cannon-lake onwards. Please follow Nate's recommendation for that.
> > > > >
> > > > > PS: I see my gmail was added earlier and that notification was in spam. Thanks for adding my @intel email. I am off next week, I’ll respond the following week if there are follow-up questions.
> > > >
> > > > See CB:36356. Native SGX init is not used in CNL, so there is nothing more to do.
> > >
> > > "FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."* I dont think i got into this issue when i wrote native sgx init flow. At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected.
> > >
> > > @Nate: is this* valid for SKL/KBL as well?
> >
>
> Yes, this is valid and exactly the point, why native SGX init can't be used. LT_MEMORY_LOCK must be set, *before* native SGX init (well, more specifically before microcode reload). That conflicts with the requirement of FSP-S to be able to write registers.
>
> > At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected
>
> Yes, SGX works. No, not in a secure way with native SGX init without LT_MEMORY_LOCK.
in my original code i.e. native sgx init, i was doing exactly that.
lock LT mem, reload ucode and so on. (my original code below - commit 418535e222ccd9f688facbb7d9663ca4cacc2739) which was working.
void sgx_configure(void)
{
const void *microcode_patch = intel_mp_current_microcode();
if (!soc_sgx_enabled() || !is_sgx_supported() || !is_prmrr_set()) {
printk(BIOS_ERR, "SGX: pre-conditions not met\n");
return;
}
/* Enable the SGX feature */
enable_sgx();
/* Update the owner epoch value */
if (owner_epoch_update() < 0)
return;
/* Ensure to lock memory before reload microcode patch */
cpu_lock_sgx_memory();
/* Reload the microcode patch */
intel_microcode_load_unlocked(microcode_patch);
/* Lock the SGX feature */
lock_sgx();
/* Activate the SGX feature, if PRMRR config was aprroved by MCHECK */
if (is_prmrr_approved())
activate_sgx();
}
--
To view, visit https://review.coreboot.org/c/coreboot/+/44244
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4251c6f1155ae7d1f0cd9064af55cd346ec88845
Gerrit-Change-Number: 44244
Gerrit-PatchSet: 2
Gerrit-Owner: Michael Niewöhner
Gerrit-Reviewer: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org>
Gerrit-Reviewer: Nathaniel L Desimone <nathaniel.l.desimone(a)intel.com>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Patrick Rudolph
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Reviewer: Pratik Prajapati <pratik.prajapati(a)gmail.com>
Gerrit-Reviewer: Pratikkumar V Prajapati <pratikkumar.v.prajapati(a)intel.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Comment-Date: Fri, 07 Aug 2020 22:54:39 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment