Hi all, This is an info mail for addressing this patch (soc/intel/elkhartlake: Introduce Intel PSE [1]): With the Elkhart Lake Platform Intel has introduced an additional subsystem controller inside the Chipset which can be used to offload different kind of tasks from the main CPU. This controller is called the Programmable Service Engine (PSE) and is an ARM Cortex M7 based CPU with 384 KB of Tightly Coupled Memory (TCM for data and code) and 1MB of L2 SRAM. The firmware this controller executes has to be loaded during boot-time of the main CPU and can be any custom designed piece of firmware that serves the needs of the application. In addition, the PSE can be a Zephyr OS based.
In order to perform the task in a given application, which might be e.g., real-time communication over Time Sensitive Network (TSN), Intel(r) EC Lite Service, Out Of Band (OOB) Management or even a network proxy, there are several SoC internal peripherals that can be assigned to the PSE (.../pci_devs.h [2]). This assignment must be done at boot time of the main CPU and cannot be changed later. So once a peripheral is assigned to the PSE, it disappears from the host subsystem and is only useable with the PSE to perform the task in question. There is one communication channel between the host subsystem and the PSE subsystem so that the host CPU can communicate with the application running on the PSE. IPC HW with HECI protocol. There is further no way that the PSE application can access host dedicated peripherals. To achieve this the PSE is equipped with a dedicated MMU which isolates both subsystems.
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake. There is a patch on Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake: Introduce Intel PSE [1]. This patch does not introduce the PSE-Firmware itself nor does it add a new blob to the coreboot repository. In fact, this patch acquires the PSE firmware to load located inside the CBFS and loads it into DRAM, adds some settings related to the PSE like peripheral ownership and passes this DRAM buffer to the FSP, which then performs the loading of the firmware among with the settings into the PSE controller itself.
Please and thank you, Sheng
[1]: https://review.coreboot.org/c/coreboot/+/55367 [2]: https://review.coreboot.org/c/coreboot/+/58466
Hi Sheng,
On Wed, Oct 27, 2021 at 1:19 AM Tan, Lean Sheng lean.sheng.tan@intel.com wrote:
Hi all, This is an info mail for addressing this patch (soc/intel/elkhartlake: Introduce Intel PSE [1]): With the Elkhart Lake Platform Intel has introduced an additional subsystem controller inside the Chipset which can be used to offload different kind of tasks from the main CPU. This controller is called the Programmable Service Engine (PSE) and is an ARM Cortex M7 based CPU with 384 KB of Tightly Coupled Memory (TCM for data and code) and 1MB of L2 SRAM. The firmware this controller executes has to be loaded during boot-time of the main CPU and can be any custom designed piece of firmware that serves the needs of the application. In addition, the PSE can be a Zephyr OS based.
Sounds quite useful. Does Intel plan to do any of the following?
- Release datasheets and register specs? - Add support to Zephyr OS upstream? - Release (open source) a reference application for PSE based on Zephyr OS?
In order to perform the task in a given application, which might be e.g., real-time communication over Time Sensitive Network (TSN), Intel(r) EC Lite Service, Out Of Band (OOB) Management or even a network proxy, there are several SoC internal peripherals that can be assigned to the PSE (.../pci_devs.h [2]). This assignment must be done at boot time of the main CPU and cannot be changed later. So once a peripheral is assigned to the PSE, it disappears from the host subsystem and is only useable with the PSE to perform the task in question. There is one communication channel between the host subsystem and the PSE subsystem so that the host CPU can communicate with the application running on the PSE. IPC HW with HECI protocol. There is further no way that the PSE application can access host dedicated peripherals. To achieve this the PSE is equipped with a dedicated MMU which isolates both subsystems.
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake. There is a patch on Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake: Introduce Intel PSE [1]. This patch does not introduce the PSE-Firmware itself nor does it add a new blob to the coreboot repository. In fact, this patch acquires the PSE firmware to load located inside the CBFS and loads it into DRAM, adds some settings related to the PSE like peripheral ownership and passes this DRAM buffer to the FSP, which then performs the loading of the firmware among with the settings into the PSE controller itself.
Is PSE required to boot? Or can it be disabled like ISH when it's not needed?
Please and thank you, Sheng
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Jack, Appreciated for your reply! Here are my replies:
1. Sounds quite useful. Does Intel plan to do any of the following? · Release datasheets and register specs? · Add support to Zephyr OS upstream? · Release (open source) a reference application for PSE based on Zephyr OS? Reply: Unfortunately I could not commit on behalf of PSE team (as it was handled by the other org), but for what I know, the PSE OS is built on Zephyr OS and is under Apache license, which means any Intel customers who are using it has the freedom to open source the code 😊
1. Is PSE required to boot? Or can it be disabled like ISH when it's not needed?
Reply: Actually I made sight mistake on this statement that PSE is mandatory to load.. If fact PSE can be turned off (like ISH) without blocking the bootflow unless you need to use the PSE peripherals such as PSE GbE.
Please and thank you, Sheng
From: Jack Rosenthal jrosenth@chromium.org Sent: Thursday, October 28, 2021 4:05 AM To: Tan, Lean Sheng lean.sheng.tan@intel.com Cc: coreboot@coreboot.org; paulepanter@mailbox.org Subject: Re: [coreboot] Providing an Interface to load PSE FW for Intel Elkhart Lake Platform
Hi Sheng,
On Wed, Oct 27, 2021 at 1:19 AM Tan, Lean Sheng <lean.sheng.tan@intel.commailto:lean.sheng.tan@intel.com> wrote: Hi all, This is an info mail for addressing this patch (soc/intel/elkhartlake: Introduce Intel PSE [1]): With the Elkhart Lake Platform Intel has introduced an additional subsystem controller inside the Chipset which can be used to offload different kind of tasks from the main CPU. This controller is called the Programmable Service Engine (PSE) and is an ARM Cortex M7 based CPU with 384 KB of Tightly Coupled Memory (TCM for data and code) and 1MB of L2 SRAM. The firmware this controller executes has to be loaded during boot-time of the main CPU and can be any custom designed piece of firmware that serves the needs of the application. In addition, the PSE can be a Zephyr OS based.
Sounds quite useful. Does Intel plan to do any of the following?
* Release datasheets and register specs? * Add support to Zephyr OS upstream? * Release (open source) a reference application for PSE based on Zephyr OS?
In order to perform the task in a given application, which might be e.g., real-time communication over Time Sensitive Network (TSN), Intel(r) EC Lite Service, Out Of Band (OOB) Management or even a network proxy, there are several SoC internal peripherals that can be assigned to the PSE (.../pci_devs.h [2]). This assignment must be done at boot time of the main CPU and cannot be changed later. So once a peripheral is assigned to the PSE, it disappears from the host subsystem and is only useable with the PSE to perform the task in question. There is one communication channel between the host subsystem and the PSE subsystem so that the host CPU can communicate with the application running on the PSE. IPC HW with HECI protocol. There is further no way that the PSE application can access host dedicated peripherals. To achieve this the PSE is equipped with a dedicated MMU which isolates both subsystems.
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake. There is a patch on Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake: Introduce Intel PSE [1]. This patch does not introduce the PSE-Firmware itself nor does it add a new blob to the coreboot repository. In fact, this patch acquires the PSE firmware to load located inside the CBFS and loads it into DRAM, adds some settings related to the PSE like peripheral ownership and passes this DRAM buffer to the FSP, which then performs the loading of the firmware among with the settings into the PSE controller itself.
Is PSE required to boot? Or can it be disabled like ISH when it's not needed?
Please and thank you, Sheng
[1]: https://review.coreboot.org/c/coreboot/+/55367 [2]: https://review.coreboot.org/c/coreboot/+/58466
_______________________________________________ coreboot mailing list -- coreboot@coreboot.orgmailto:coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.orgmailto:coreboot-leave@coreboot.org
Hi Sheng,
On 27.10.21 06:29, Tan, Lean Sheng wrote:
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake. There is a patch on Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake: Introduce Intel PSE [1]. This patch does not introduce the PSE-Firmware itself nor does it add a new blob to the coreboot repository. In fact, this patch acquires the PSE firmware to load located inside the CBFS and loads it into DRAM, adds some settings related to the PSE like peripheral ownership and passes this DRAM buffer to the FSP, which then performs the loading of the firmware among with the settings into the PSE controller itself.
so as far as I understand it this is not necessarily a blob, your patch only treats it like one? Or is there any need to make it proprietary?
It seems very valuable to me to be able to build a bootable coreboot image just with the sources and submodules in the coreboot repository. Would it be possible to provide the minimum source code that would make it bootable? Integration into coreboot should be quite easy as I remem- ber that coreboot's build system already supports individual stages of different architectures. For the build system, the PSE firmware could just be another stage, compiled for ARM. Let me know if you want to integrate it and need help with that.
OTOH, if we'd add an option to load an external file like your patch suggests, we'd lose a lot. Not only, would it complicate the build process, we'd also have another platform that can't boot without external files. And that is more error-prone and always leads to more support requests, frustration etc. It's bad for the project, IMHO.
Nico
Oct 31, 2021, 15:03 by nico.h@gmx.de:
Hi Sheng,
On 27.10.21 06:29, Tan, Lean Sheng wrote:
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake.
...
so as far as I understand it this is not necessarily a blob, your patch only treats it like one? Or is there any need to make it proprietary?
...
OTOH, if we'd add an option to load an external file like your patch suggests, we'd lose a lot. Not only, would it complicate the build process, we'd also have another platform that can't boot without external files. And that is more error-prone and always leads to more support requests, frustration etc. It's bad for the project, IMHO.
Nico
The issue of loading the PSE firmware was brought up in the coreboot leadership meeting on October 20.
Sheng mentioned that the desire/plan is to open the code for the PSE binary at some point, but it isn't open yet.
This binary is also mandatory for the elkhart lake platform, so to support this platform, loading this is required, whether it's built from source as a part of the coreboot build or supplied as a blob.
The decision at the leadership meeting was to allow this binary to be loaded by coreboot, so long as the PSE acts like an EC, and does not have access to the X86 memory space.
The load method wasn't discussed beyond what's in CB:55367, so if there's a different load method that's desired, that could be acceptable, but I think we can close the discussion on whether or not to allow the binary loader to be added, provided Sheng can show that this part doesn't have security implications for the X86 side.
Martin
On 05.11.21 18:58, Martin Roth wrote:
Oct 31, 2021, 15:03 by nico.h@gmx.de:
Hi Sheng,
On 27.10.21 06:29, Tan, Lean Sheng wrote:
As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake.
...
so as far as I understand it this is not necessarily a blob, your patch only treats it like one? Or is there any need to make it proprietary?
...
OTOH, if we'd add an option to load an external file like your patch suggests, we'd lose a lot. Not only, would it complicate the build process, we'd also have another platform that can't boot without external files. And that is more error-prone and always leads to more support requests, frustration etc. It's bad for the project, IMHO.
Nico
The issue of loading the PSE firmware was brought up in the coreboot leadership meeting on October 20.
Sheng mentioned that the desire/plan is to open the code for the PSE binary at some point, but it isn't open yet.
This binary is also mandatory for the elkhart lake platform, so to support this platform, loading this is required, whether it's built from source as a part of the coreboot build or supplied as a blob.
That's not true. Just rumors?
The decision at the leadership meeting was to allow this binary to be loaded by coreboot, so long as the PSE acts like an EC, and does not have access to the X86 memory space.
The discussion happened under a false pretext and with outdated information. Also, the PSE is nothing like an EC. Hint: does an EC do parts of the SoC silicon init that would usually be done by our ramstage?
Maybe to avoid wasting time with premature decisions, we should make up some guidelines? For instance, first discuss something on the mailing list, then in the leadership meeting? This way people could at least get a little information before they make decisions.
The load method wasn't discussed beyond what's in CB:55367, so if there's a different load method that's desired, that could be acceptable, but I think we can close the discussion on whether or not to allow the binary loader to be added, provided Sheng can show that this part doesn't have security implications for the X86 side.
Interesting point about the security. I'm also curious. I couldn't find anything about the mentioned MMU in Intel's docs.
Nico
PS. Please have a look at the available documentation before making decisions.
Nov 5, 2021, 14:10 by nico.h@gmx.de:
On 05.11.21 18:58, Martin Roth wrote:
This binary is also mandatory for the elkhart lake platform, so to support this platform, loading this is required, whether it's built from source as a part of the coreboot build or supplied as a blob.
That's not true. Just rumors?
This is what was reported by the intel representative in the leadership meeting. I can't say whether it's true or not, this is however what was reported.
If it's optional though, then why do you even care, just don't use it and default it to off. If other people want to be able to use it, why are you concerned about preventing them?
The decision at the leadership meeting was to allow this binary to be loaded by coreboot, so long as the PSE acts like an EC, and does not have access to the X86 memory space.
The discussion happened under a false pretext and with outdated information. Also, the PSE is nothing like an EC. Hint: does an EC do parts of the SoC silicon init that would usually be done by our ramstage?
Then you shouldn't be worried. It was decided to accept it *so long as the PSE acts like an EC* as i said above. If that's not actually the case, then Sheng won't be able to show that it acts like an EC and there's no issue. Though if it's actually optional, again, what's the issue?
What is it that it does that's normally done by coreboot's ramstage?
Maybe to avoid wasting time with premature decisions, we should make up some guidelines? For instance, first discuss something on the mailing list, then in the leadership meeting? This way people could at least get a little information before they make decisions.
There are lots of options here: - There's an agenda that's posted before the meeting. Other things do come up in the meeting, but this item had been posted for at least a week before the leadership meeting, so there was plenty of time to look at it and decide whether or not to come. - People who believe they have information to share or want their opinions heard can come to the leadership meeting. If they aren't there, they don't get to voice an opinion in the meeting. - People can respond to the meeting minutes when they're posted to the mailing list or look at the minutes in the document.
Ultimately, the decision about the direction that the coreboot project is going to go is decided by the coreboot leaders, currently Stefan, Werner, and David. Sure, discussions can happen on the mailing list, but the leadership meeting is where the decisions get made.
I've added your suggestion about requiring discussions on the mailing list to the meeting minutes of the next meeting. If you'd like to discuss the idea in the meeting, please attend.
The load method wasn't discussed beyond what's in CB:55367, so if there's a different load method that's desired, that could be acceptable, but I think we can close the discussion on whether or not to allow the binary loader to be added, provided Sheng can show that this part doesn't have security implications for the X86 side.
Interesting point about the security. I'm also curious. I couldn't find anything about the mentioned MMU in Intel's docs.
Nico
PS. Please have a look at the available documentation before making decisions.
And again, the decision was made conditionally upon the information we were given. If you want to voice concerns, please come to the meetings.
Martin
On 06.11.21 23:40, Martin Roth wrote:
Nov 5, 2021, 14:10 by nico.h@gmx.de:
On 05.11.21 18:58, Martin Roth wrote:
This binary is also mandatory for the elkhart lake platform, so to support this platform, loading this is required, whether it's built from source as a part of the coreboot build or supplied as a blob.
That's not true. Just rumors?
This is what was reported by the intel representative in the leadership meeting. I can't say whether it's true or not, this is however what was reported.
The current notion seems to be that the PSE firmware is not needed to boot an EHL SoC, however is needed to make use of all its integrated peripherals (e.g. the PSE related ethernet MACs).
If it's optional though, then why do you even care, just don't use it and default it to off. If other people want to be able to use it, why are you concerned about preventing them?
I already gave some reasoning in the quote you dropped with this mail. Related: Somebody found a marketing page of Intel that literally states that the coreboot community does their support. Anyway, here's another attempt:
The coreboot.org frontpage states about coreboot:
Fast, secure and flexible OpenSource firmware
When something is pushed into our repository that looks like the *exact* opposite, I am naturally concerned. FWIW, some of the blob infrastruc- ture that was bluntly added over the last few years made coreboot slow, insecure and inflexible. At some point this has to stop. Otherwise, I fear, we'll be run down by other projects eventually, while we crawl under the blob pressure. IMHO, coreboot's biggest advantage used to be the reasonable code base that provided a very nice development experience. I guess we still do much better than EDK2, but how does it look like compared to Project Mu? (I don't know actually, never looked into it) Should we really throw that advantage away?
Sorry, now I feel like I derailed this thread :-/
The decision at the leadership meeting was to allow this binary to be loaded by coreboot, so long as the PSE acts like an EC, and does not have access to the X86 memory space.
The discussion happened under a false pretext and with outdated information. Also, the PSE is nothing like an EC. Hint: does an EC do parts of the SoC silicon init that would usually be done by our ramstage?
Then you shouldn't be worried. It was decided to accept it *so long as the PSE acts like an EC* as i said above. If that's not actually the case, then Sheng won't be able to show that it acts like an EC and there's no issue. Though if it's actually optional, again, what's the issue?
I'm sorry. I must have misinterpreted your email. You replied below my quoted words, so I assumed that your mail is related to them. But I couldn't find any clear message and assumed that you are opposed to what I wrote. Sorry if that was a misinterpretation.
One issue left, I guess, it seems people want to go on with the patch without showing anything about being EC like or about the security implications. Maybe because the leadership decision wasn't clearly communicated?
What is it that it does that's normally done by coreboot's ramstage?
As far as we know so far, the PSE is the only processor core that can access all the registers of the related peripherals, like the MACs mentioned above. Some of these registers need to be written as part of the silicon init, just like all the PCI drivers do that we usually have in ramstage. So it's like a detour one has to take to do ram- stage's job.
The PSE can do much more than that.
Maybe to avoid wasting time with premature decisions, we should make up some guidelines? For instance, first discuss something on the mailing list, then in the leadership meeting? This way people could at least get a little information before they make decisions.
There are lots of options here:
- There's an agenda that's posted before the meeting. Other things do come up in the meeting, but this item had been posted for at least a week before the leadership meeting, so there was plenty of time to look at it and decide whether or not to come.
- People who believe they have information to share or want their opinions heard can come to the leadership meeting. If they aren't there, they don't get to voice an opinion in the meeting.
- People can respond to the meeting minutes when they're posted to the mailing list or look at the minutes in the document.
Well, the minutes weren't very clear. Your mail from yesterday was the first time I heard about a decision.
Ultimately, the decision about the direction that the coreboot project is going to go is decided by the coreboot leaders, currently Stefan, Werner, and David. Sure, discussions can happen on the mailing list, but the leadership meeting is where the decisions get made.
There seems to be a gap when decisions are made but not communicated. It doesn't feel like the leadership actually cares if their decisions are honored.
I've added your suggestion about requiring discussions on the mailing list to the meeting minutes of the next meeting. If you'd like to discuss the idea in the meeting, please attend.
I'll try.
The load method wasn't discussed beyond what's in CB:55367, so if there's a different load method that's desired, that could be acceptable, but I think we can close the discussion on whether or not to allow the binary loader to be added, provided Sheng can show that this part doesn't have security implications for the X86 side.
Interesting point about the security. I'm also curious. I couldn't find anything about the mentioned MMU in Intel's docs.
Nico
PS. Please have a look at the available documentation before making decisions.
And again, the decision was made conditionally upon the information we were given. If you want to voice concerns, please come to the meetings.
Well, not all people have weeks to waste. In such a scenario should I -2 a patch and wait for the next meeting? and if that's not conclusive wait for the next? It doesn't seem fair for the authors.
So please, coreboot leadership, take part in the project, please attend the mailing list. At least when you decide something, just send an email. :) The mailing list is the only place where everyone gets a chance to attend equally.
Nico
Hi Nico, One thing that's unclear to me is if there are lingering technical reasons for holding the patch back, aside from a Kconfig variable that Michael recently requested. Werner asked that question as well but the answer(s), if any, seem to have been lost in the philosophical aspects.
If the patch still needs work then the author should continue to work on it, but please keep the technical and non-technical arguments separate.
Sadly, I don't think Sheng will be able to solve the blob situation on Intel platforms in this patch.
Other responses are in-line:
So please, coreboot leadership, take part in the project
You saw Werner's comments in the patch, right? I think you did since you replied to them...
At least when you decide something, just send an email. :)
Like this? https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/SCV36...
The mailing list is the only place where everyone gets a chance to attend equally.
Does this link work for you? https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...
If not, please let us know - permissions should be set so that anyone can view it.
-
David Hendricks -
Jack Rosenthal -
Martin Roth -
Nico Huber -
Tan, Lean Sheng