[edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

Hi,
I am trying to build edk2-platforms for EagleStream Platform. The problem I am facing now is that the Peims are not getting dispatched when The PeiMain routine calls PeiDispatcher().
After digging deeper into it it seems that the DepexSatisfied() routine is always returning false. So I also checked this and realized that the place that is returning false is inside the PeimDispatchReadiness
function:
​```
case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
StackPtr--;
//
// Check to make sure EvalStack is balanced. If not, then there is
// an error in the dependency grammar, so return EFI_INVALID_PARAMETER.
//
if (StackPtr != &EvalStack[0]) {

DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
return FALSE;
}

DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled (PeiServices, StackPtr) ? "TRUE" : "FALSE"));

return IsPpiInstalled (PeiServices, StackPtr);
```
It seems that when entering IsPpiInstalled StackPtr in always NULL.
Any thoughts on this?

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115748): https://edk2.groups.io/g/devel/message/115748
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 2611 bytes --]

[edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

Hi,
I am trying to build edk2-platforms for EagleStream Platform. The problem I am facing now is that the Peims are not getting dispatched when The PeiMain routine calls PeiDispatcher().
After digging deeper into it it seems that the DepexSatisfied() routine is always returning false. So I also checked this and realized that the place that is returning false is inside the PeimDispatchReadiness
function:
​```
case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
StackPtr--;
//
// Check to make sure EvalStack is balanced. If not, then there is
// an error in the dependency grammar, so return EFI_INVALID_PARAMETER.
//
if (StackPtr != &EvalStack[0]) {

DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
return FALSE;
}

DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled (PeiServices, StackPtr) ? "TRUE" : "FALSE"));

return IsPpiInstalled (PeiServices, StackPtr);
```
It seems that when entering IsPpiInstalled StackPtr in always NULL.Any thoughts on this?

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115749): https://edk2.groups.io/g/devel/message/115749
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 2562 bytes --]

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[Laszlo Ersek]

On 2/21/24 07:59, memristor2 via groups.io wrote:
> Hi,
> I am trying to build edk2-platforms for EagleStream Platform. The
> problem I am facing now is that the Peims are not getting dispatched
> when The PeiMain routine calls PeiDispatcher().
> After digging deeper into it it seems that the DepexSatisfied() routine
> is always returning false. So I also checked this and realized that the
> place that is returning false is inside the PeimDispatchReadiness
> function:
> ||​```
> case (EFI_DEP_END):        DEBUG ((DEBUG_DISPATCH, "  END\n"));
>         StackPtr--;
>         //
>         // Check to make sure EvalStack is balanced.  If not, then there is
>         // an error in the dependency grammar, so return
> EFI_INVALID_PARAMETER.
>         //
>         if (StackPtr != &EvalStack[0]) {
>  
>           DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Underflow Error)\n"));
>           return FALSE;
>         }
> 
>         DEBUG ((DEBUG_DISPATCH, "  RESULT = %a\n",
> IsPpiInstalled (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> 
>         return IsPpiInstalled (PeiServices, StackPtr);
> ```
> It seems that when entering IsPpiInstalled StackPtr in always NULL.
> Any thoughts on this?

StackPtr being NULL seems extremely unlikely; it is supposed to point to
elements of the EvalStack local array (or I guess one past the last
element).

Now, I can see two potential problems here:

- your depex is malformed (for whatever reason), and the eval stack is
not torn down entirely before reachig EFI_DEP_END. The code seems to
handle that correctly, by returning FALSE.

- your depex is malformed such that it immediately starts with an
EFI_DEP_END. The code is actually buggy for that case, because it
decrements StackPtr *first*, before comparing it against &EvalStack[0].
That decrement invokes undefined behavior. However, I assume in practice
the behavior will be the same as in the previous paragraph.

A NULL StackPtr value I cannot explain at all.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115757): https://edk2.groups.io/g/devel/message/115757
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[Nate DeSimone]

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: Wednesday, February 21, 2024 3:59 PM
> To: devel@edk2.groups.io; memristor2@proton.me
> Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> Platform
> 
> On 2/21/24 07:59, memristor2 via groups.io wrote:
> > Hi,
> > I am trying to build edk2-platforms for EagleStream Platform. The
> > problem I am facing now is that the Peims are not getting dispatched
> > when The PeiMain routine calls PeiDispatcher().
> > After digging deeper into it it seems that the DepexSatisfied()
> > routine is always returning false. So I also checked this and realized
> > that the place that is returning false is inside the
> > PeimDispatchReadiness
> > function:
> > ||​```
> > case (EFI_DEP_END):        DEBUG ((DEBUG_DISPATCH, "  END\n"));
> >         StackPtr--;
> >         //
> >         // Check to make sure EvalStack is balanced.  If not, then
> > there is
> >         // an error in the dependency grammar, so return
> > EFI_INVALID_PARAMETER.
> >         //
> >         if (StackPtr != &EvalStack[0]) {
> >
> >           DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Underflow
> > Error)\n"));
> >           return FALSE;
> >         }
> >
> >         DEBUG ((DEBUG_DISPATCH, "  RESULT = %a\n", IsPpiInstalled
> > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> >
> >         return IsPpiInstalled (PeiServices, StackPtr); ``` It seems
> > that when entering IsPpiInstalled StackPtr in always NULL.
> > Any thoughts on this?
> 
> StackPtr being NULL seems extremely unlikely; it is supposed to point to
> elements of the EvalStack local array (or I guess one past the last element).
> 
> Now, I can see two potential problems here:
> 
> - your depex is malformed (for whatever reason), and the eval stack is not torn
> down entirely before reachig EFI_DEP_END. The code seems to handle that
> correctly, by returning FALSE.
> 
> - your depex is malformed such that it immediately starts with an
> EFI_DEP_END. The code is actually buggy for that case, because it decrements
> StackPtr *first*, before comparing it against &EvalStack[0].
> That decrement invokes undefined behavior. However, I assume in practice the
> behavior will be the same as in the previous paragraph.
> 
> A NULL StackPtr value I cannot explain at all.

Agreed with Laszlo here... the only thing that I could think of is memory corruption. Several people at Intel (myself included) as working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms right now. I would recommend you wait for us to release our code as opposed to trying to develop support for Eagle Steam independently.

> 
> Laszlo
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115760): https://edk2.groups.io/g/devel/message/115760
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

Thank you. Based on what you told me (memory corruption and and the unlikelihood of the stack pointer being NULL) my only suspicion would be the microcode I am using, since the only platform dependent parts up until this part would be the microcode and the FSP-T and since I am using the FSP for EagleStream only the microcode would be left to change. Up until now I was using Whitley's microcode (since EagleStream's hadn't been released yet). To be honest I still don't have a proper comprehension of the concept of the microcode so I thought maybe I could use Whitley's microcode. But now that EagleStream's microcode has been released I'll try with that and let you know whether it works or not. Yet I am still skeptical about it being a microcode issue because my thought is that the microcode is procosser architecture-based code rather than it being platform-based code. Please correct me if I am wrong on this matter.


On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L <nathaniel.l.desimone@intel.com> wrote:

> > -----Original Message-----
> > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > Ersek
> > Sent: Wednesday, February 21, 2024 3:59 PM
> > To: devel@edk2.groups.io; memristor2@proton.me
> > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> > Platform
> > 
> > On 2/21/24 07:59, memristor2 via groups.io wrote:
> > 
> > > Hi,
> > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > problem I am facing now is that the Peims are not getting dispatched
> > > when The PeiMain routine calls PeiDispatcher().
> > > After digging deeper into it it seems that the DepexSatisfied()
> > > routine is always returning false. So I also checked this and realized
> > > that the place that is returning false is inside the
> > > PeimDispatchReadiness
> > > function:
> > > ||```
> > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > StackPtr--;
> > > //
> > > // Check to make sure EvalStack is balanced. If not, then
> > > there is
> > > // an error in the dependency grammar, so return
> > > EFI_INVALID_PARAMETER.
> > > //
> > > if (StackPtr != &EvalStack[0]) {
> > > 
> > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow
> > > Error)\n"));
> > > return FALSE;
> > > }
> > > 
> > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > > 
> > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems
> > > that when entering IsPpiInstalled StackPtr in always NULL.
> > > Any thoughts on this?
> > 
> > StackPtr being NULL seems extremely unlikely; it is supposed to point to
> > elements of the EvalStack local array (or I guess one past the last element).
> > 
> > Now, I can see two potential problems here:
> > 
> > - your depex is malformed (for whatever reason), and the eval stack is not torn
> > down entirely before reachig EFI_DEP_END. The code seems to handle that
> > correctly, by returning FALSE.
> > 
> > - your depex is malformed such that it immediately starts with an
> > EFI_DEP_END. The code is actually buggy for that case, because it decrements
> > StackPtr first, before comparing it against &EvalStack[0].
> > That decrement invokes undefined behavior. However, I assume in practice the
> > behavior will be the same as in the previous paragraph.
> > 
> > A NULL StackPtr value I cannot explain at all.
> 
> 
> Agreed with Laszlo here... the only thing that I could think of is memory corruption. Several people at Intel (myself included) as working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms right now. I would recommend you wait for us to release our code as opposed 
> 
> > Laszlo
> > 
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115816): https://edk2.groups.io/g/devel/message/115816
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[Nate DeSimone]

> -----Original Message-----
> From: memristor2 <memristor2@proton.me>
> Sent: Thursday, February 22, 2024 5:51 AM
> To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
> Cc: devel@edk2.groups.io; lersek@redhat.com
> Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> Platform
> 
> Thank you. Based on what you told me (memory corruption and and the
> unlikelihood of the stack pointer being NULL) my only suspicion would be the
> microcode I am using, since the only platform dependent parts up until this
> part would be the microcode and the FSP-T and since I am using the FSP for
> EagleStream only the microcode would be left to change.

Having correct microcode is absolutely essential for sure. But microcode & FSP
are not the only platform dependent components. Any code contained in a
*BoardPkg is considered to be platform dependent in some way. I would be
surprised if simply adding the microcode will fix this problem.

> Up until now I was using Whitley's microcode (since EagleStream's hadn't been
> released yet). To be honest I still don't have a proper comprehension of the
> concept of the microcode so I thought maybe I could use Whitley's microcode.

Here is what microcode is in a nutshell. Every x86 processor designed since
~1990 is actually a RISC-based CPU design internally. The microcode contains a
lookup table that maps each CPU instruction into one or more sub-instructions
(sometimes called micro-instructions or micro-OPs (µOPs for short)) which are
the instructions that the hidden RISC processor executes. This hidden RISC
processor has an unpublished instruction set that no one outside of the CPU
vendor sees.

The initial purpose of RISC was to eliminate the need for microcode, as the
complex decode engine and ROM consumed transistors that could instead be used
for things like a wider ALU. But then in the mid-1990s, a new technology came
along called out-of-order execution. The idea behind out-of-order execution is
that we can expand the purpose of microcode to be more than just a lookup table,
it can actually change the sequence of micro-OPs so that the program runs
faster. So now, microcode is not only a lookup table, but it also provides a
programmable instruction _scheduler_.

The use of out-of-order execution was made possible by Moore's law. Moore's law
drove rapidly increasing transistor counts during the 1990s. No longer would you
need to decide whether to use your transistor budget for microcode or for a
wider ALU... you had plenty of transistors so you could do both! Both of them
together yields the fastest CPU designs by a large margin. All of these factors
came together at once, and suddenly any CPU design that didn't use microcode was
obsolete by the year 2000.

Fast forward to today, the RISC vs. CISC argument is obsolete. Modern
high-performance CPUs require very complex microcode. The existence of that
microcode abstracts most of the differences between traditionally RISC ISAs like
ARM and traditionally CISC ISAs like x86.

> But now that EagleStream's microcode has been released I'll try with that and
> let you know whether it works or not. Yet I am still skeptical about it being
> a microcode issue because my thought is that the microcode is procosser
> architecture-based code rather than it being platform-based code. Please
> correct me if I am wrong on this matter.

You intuition that it is not a microcode issue is correct. There are a lot of
things in the BoardPkg that change with each platform design. For an example of
that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg.
> 
> 
> On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L
> <nathaniel.l.desimone@intel.com> wrote:
> 
> > > -----Original Message-----
> > > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > > Ersek
> > > Sent: Wednesday, February 21, 2024 3:59 PM
> > > To: devel@edk2.groups.io; memristor2@proton.me
> > > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in
> > > EagleStream Platform
> > >
> > > On 2/21/24 07:59, memristor2 via groups.io wrote:
> > >
> > > > Hi,
> > > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > > problem I am facing now is that the Peims are not getting
> > > > dispatched when The PeiMain routine calls PeiDispatcher().
> > > > After digging deeper into it it seems that the DepexSatisfied()
> > > > routine is always returning false. So I also checked this and
> > > > realized that the place that is returning false is inside the
> > > > PeimDispatchReadiness
> > > > function:
> > > > ||```
> > > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > > StackPtr--; // // Check to make sure EvalStack is balanced. If
> > > > not, then there is // an error in the dependency grammar, so
> > > > return EFI_INVALID_PARAMETER.
> > > > //
> > > > if (StackPtr != &EvalStack[0]) {
> > > >
> > > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
> > > > return FALSE; }
> > > >
> > > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > > >
> > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems that
> > > > when entering IsPpiInstalled StackPtr in always NULL.
> > > > Any thoughts on this?
> > >
> > > StackPtr being NULL seems extremely unlikely; it is supposed to
> > > point to elements of the EvalStack local array (or I guess one past the last
> element).
> > >
> > > Now, I can see two potential problems here:
> > >
> > > - your depex is malformed (for whatever reason), and the eval stack
> > > is not torn down entirely before reachig EFI_DEP_END. The code seems
> > > to handle that correctly, by returning FALSE.
> > >
> > > - your depex is malformed such that it immediately starts with an
> > > EFI_DEP_END. The code is actually buggy for that case, because it
> > > decrements StackPtr first, before comparing it against &EvalStack[0].
> > > That decrement invokes undefined behavior. However, I assume in
> > > practice the behavior will be the same as in the previous paragraph.
> > >
> > > A NULL StackPtr value I cannot explain at all.
> >
> >
> > Agreed with Laszlo here... the only thing that I could think of is
> > memory corruption. Several people at Intel (myself included) as
> > working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms
> > right now. I would recommend you wait for us to release our code as
> > opposed
> >
> > > Laszlo
> > >
> > > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115894): https://edk2.groups.io/g/devel/message/115894
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

Sent with Proton Mail secure email.

On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L <nathaniel.l.desimone@intel.com> wrote:

> > -----Original Message-----
> > From: memristor2 memristor2@proton.me
> > Sent: Thursday, February 22, 2024 5:51 AM
> > To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com
> > Cc: devel@edk2.groups.io; lersek@redhat.com
> > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> > Platform
> > 
> > Thank you. Based on what you told me (memory corruption and and the
> > unlikelihood of the stack pointer being NULL) my only suspicion would be the
> > microcode I am using, since the only platform dependent parts up until this
> > part would be the microcode and the FSP-T and since I am using the FSP for
> > EagleStream only the microcode would be left to change.
> 
> 
> Having correct microcode is absolutely essential for sure. But microcode & FSP
> are not the only platform dependent components. Any code contained in a
> *BoardPkg is considered to be platform dependent in some way. I would be
> surprised if simply adding the microcode will fix this problem.
> 
> > Up until now I was using Whitley's microcode (since EagleStream's hadn't been
> > released yet). To be honest I still don't have a proper comprehension of the
> > concept of the microcode so I thought maybe I could use Whitley's microcode.
> 
> 
> Here is what microcode is in a nutshell. Every x86 processor designed since
> ~1990 is actually a RISC-based CPU design internally. The microcode contains a
> lookup table that maps each CPU instruction into one or more sub-instructions
> (sometimes called micro-instructions or micro-OPs (µOPs for short)) which are
> the instructions that the hidden RISC processor executes. This hidden RISC
> processor has an unpublished instruction set that no one outside of the CPU
> vendor sees.
> 
> The initial purpose of RISC was to eliminate the need for microcode, as the
> complex decode engine and ROM consumed transistors that could instead be used
> for things like a wider ALU. But then in the mid-1990s, a new technology came
> along called out-of-order execution. The idea behind out-of-order execution is
> that we can expand the purpose of microcode to be more than just a lookup table,
> it can actually change the sequence of micro-OPs so that the program runs
> faster. So now, microcode is not only a lookup table, but it also provides a
> programmable instruction scheduler.
> 
> The use of out-of-order execution was made possible by Moore's law. Moore's law
> drove rapidly increasing transistor counts during the 1990s. No longer would you
> need to decide whether to use your transistor budget for microcode or for a
> wider ALU... you had plenty of transistors so you could do both! Both of them
> together yields the fastest CPU designs by a large margin. All of these factors
> came together at once, and suddenly any CPU design that didn't use microcode was
> obsolete by the year 2000.
> 
> Fast forward to today, the RISC vs. CISC argument is obsolete. Modern
> high-performance CPUs require very complex microcode. The existence of that
> microcode abstracts most of the differences between traditionally RISC ISAs like
> ARM and traditionally CISC ISAs like x86.
Thank you I just learned as much as I learned in my Advanced Computer Architecture course. Your explanations are higly appreciated.  
> 
> > But now that EagleStream's microcode has been released I'll try with that and
> > let you know whether it works or not. Yet I am still skeptical about it being
> > a microcode issue because my thought is that the microcode is procosser
> > architecture-based code rather than it being platform-based code. Please
> > correct me if I am wrong on this matter.
> 
> 
> You intuition that it is not a microcode issue is correct. There are a lot of
> things in the BoardPkg that change with each platform design. For an example of
> that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg.
So I must take back my first thought that the StackPtr was NULL now it wasn't. StackPtr->Operator is always NULL, Which is another issue. The thing is that all of the Peims are found inside the FV but whenever the PeimDispatchReadiness() routine calls IsPpiInstalled() it seems it doesn't find the Ppis and I don't have any idea why
> 
> > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L
> > nathaniel.l.desimone@intel.com wrote:
> > 
> > > > -----Original Message-----
> > > > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > > > Ersek
> > > > Sent: Wednesday, February 21, 2024 3:59 PM
> > > > To: devel@edk2.groups.io; memristor2@proton.me
> > > > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in
> > > > EagleStream Platform
> > > > 
> > > > On 2/21/24 07:59, memristor2 via groups.io wrote:
> > > > 
> > > > > Hi,
> > > > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > > > problem I am facing now is that the Peims are not getting
> > > > > dispatched when The PeiMain routine calls PeiDispatcher().
> > > > > After digging deeper into it it seems that the DepexSatisfied()
> > > > > routine is always returning false. So I also checked this and
> > > > > realized that the place that is returning false is inside the
> > > > > PeimDispatchReadiness
> > > > > function:
> > > > > ||```
> > > > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > > > StackPtr--; // // Check to make sure EvalStack is balanced. If
> > > > > not, then there is // an error in the dependency grammar, so
> > > > > return EFI_INVALID_PARAMETER.
> > > > > //
> > > > > if (StackPtr != &EvalStack[0]) {
> > > > > 
> > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
> > > > > return FALSE; }
> > > > > 
> > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > > > > 
> > > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems that
> > > > > when entering IsPpiInstalled StackPtr in always NULL.
> > > > > Any thoughts on this?
> > > > 
> > > > StackPtr being NULL seems extremely unlikely; it is supposed to
> > > > point to elements of the EvalStack local array (or I guess one past the last
> > > > element).
> > > > 
> > > > Now, I can see two potential problems here:
> > > > 
> > > > - your depex is malformed (for whatever reason), and the eval stack
> > > > is not torn down entirely before reachig EFI_DEP_END. The code seems
> > > > to handle that correctly, by returning FALSE.
> > > > 
> > > > - your depex is malformed such that it immediately starts with an
> > > > EFI_DEP_END. The code is actually buggy for that case, because it
> > > > decrements StackPtr first, before comparing it against &EvalStack[0].
> > > > That decrement invokes undefined behavior. However, I assume in
> > > > practice the behavior will be the same as in the previous paragraph.
> > > > 
> > > > A NULL StackPtr value I cannot explain at all.
> > > 
> > > Agreed with Laszlo here... the only thing that I could think of is
> > > memory corruption. Several people at Intel (myself included) as
> > > working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms
> > > right now. I would recommend you wait for us to release our code as
> > > opposed
> > > 
> > > > Laszlo
> > > > 
> > > > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115904): https://edk2.groups.io/g/devel/message/115904
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

Sent with Proton Mail secure email.

On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io <memristor2=proton.me@groups.io> wrote:

> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L nathaniel.l.desimone@intel.com wrote:
> 
> > > -----Original Message-----
> > > From: memristor2 memristor2@proton.me
> > > Sent: Thursday, February 22, 2024 5:51 AM
> > > To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com
> > > Cc: devel@edk2.groups.io; lersek@redhat.com
> > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> > > Platform
> > > 
> > > Thank you. Based on what you told me (memory corruption and and the
> > > unlikelihood of the stack pointer being NULL) my only suspicion would be the
> > > microcode I am using, since the only platform dependent parts up until this
> > > part would be the microcode and the FSP-T and since I am using the FSP for
> > > EagleStream only the microcode would be left to change.
> > 
> > Having correct microcode is absolutely essential for sure. But microcode & FSP
> > are not the only platform dependent components. Any code contained in a
> > *BoardPkg is considered to be platform dependent in some way. I would be
> > surprised if simply adding the microcode will fix this problem.
> > 
> > > Up until now I was using Whitley's microcode (since EagleStream's hadn't been
> > > released yet). To be honest I still don't have a proper comprehension of the
> > > concept of the microcode so I thought maybe I could use Whitley's microcode.
> > 
> > Here is what microcode is in a nutshell. Every x86 processor designed since
> > ~1990 is actually a RISC-based CPU design internally. The microcode contains a
> > lookup table that maps each CPU instruction into one or more sub-instructions
> > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which are
> > the instructions that the hidden RISC processor executes. This hidden RISC
> > processor has an unpublished instruction set that no one outside of the CPU
> > vendor sees.
> > 
> > The initial purpose of RISC was to eliminate the need for microcode, as the
> > complex decode engine and ROM consumed transistors that could instead be used
> > for things like a wider ALU. But then in the mid-1990s, a new technology came
> > along called out-of-order execution. The idea behind out-of-order execution is
> > that we can expand the purpose of microcode to be more than just a lookup table,
> > it can actually change the sequence of micro-OPs so that the program runs
> > faster. So now, microcode is not only a lookup table, but it also provides a
> > programmable instruction scheduler.
> > 
> > The use of out-of-order execution was made possible by Moore's law. Moore's law
> > drove rapidly increasing transistor counts during the 1990s. No longer would you
> > need to decide whether to use your transistor budget for microcode or for a
> > wider ALU... you had plenty of transistors so you could do both! Both of them
> > together yields the fastest CPU designs by a large margin. All of these factors
> > came together at once, and suddenly any CPU design that didn't use microcode was
> > obsolete by the year 2000.
> > 
> > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern
> > high-performance CPUs require very complex microcode. The existence of that
> > microcode abstracts most of the differences between traditionally RISC ISAs like
> > ARM and traditionally CISC ISAs like x86.
> 
> Thank you I just learned as much as I learned in my Advanced Computer Architecture course. Your explanations are higly appreciated.
> 
> > > But now that EagleStream's microcode has been released I'll try with that and
> > > let you know whether it works or not. Yet I am still skeptical about it being
> > > a microcode issue because my thought is that the microcode is procosser
> > > architecture-based code rather than it being platform-based code. Please
> > > correct me if I am wrong on this matter.
> > 
> > You intuition that it is not a microcode issue is correct. There are a lot of
> > things in the BoardPkg that change with each platform design. For an example of
> > that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg.
I forgot to mention one thing. The microcode released for EagleStream has two issues:
1. It was "EaglestreamSiliconBinPkg" instead of "EagleStreamSiliconBinPkg".
2. There was no .inf file defined for it
So I added the .INF file but as we both thought it didn't change the outcome, but I for sure could say each tick became shorter resulting in preformance improvement
> 
> So I must take back my first thought that the StackPtr was NULL now it wasn't. StackPtr->Operator is always NULL, Which is another issue. The thing is that all of the Peims are found inside the FV but whenever the PeimDispatchReadiness() routine calls IsPpiInstalled() it seems it doesn't find the Ppis and I don't have any idea why
> 
> > > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L
> > > nathaniel.l.desimone@intel.com wrote:
> > > 
> > > > > -----Original Message-----
> > > > > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > > > > Ersek
> > > > > Sent: Wednesday, February 21, 2024 3:59 PM
> > > > > To: devel@edk2.groups.io; memristor2@proton.me
> > > > > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in
> > > > > EagleStream Platform
> > > > > 
> > > > > On 2/21/24 07:59, memristor2 via groups.io wrote:
> > > > > 
> > > > > > Hi,
> > > > > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > > > > problem I am facing now is that the Peims are not getting
> > > > > > dispatched when The PeiMain routine calls PeiDispatcher().
> > > > > > After digging deeper into it it seems that the DepexSatisfied()
> > > > > > routine is always returning false. So I also checked this and
> > > > > > realized that the place that is returning false is inside the
> > > > > > PeimDispatchReadiness
> > > > > > function:
> > > > > > ||```
> > > > > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > > > > StackPtr--; // // Check to make sure EvalStack is balanced. If
> > > > > > not, then there is // an error in the dependency grammar, so
> > > > > > return EFI_INVALID_PARAMETER.
> > > > > > //
> > > > > > if (StackPtr != &EvalStack[0]) {
> > > > > > 
> > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
> > > > > > return FALSE; }
> > > > > > 
> > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > > > > > 
> > > > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems that
> > > > > > when entering IsPpiInstalled StackPtr in always NULL.
> > > > > > Any thoughts on this?
> > > > > 
> > > > > StackPtr being NULL seems extremely unlikely; it is supposed to
> > > > > point to elements of the EvalStack local array (or I guess one past the last
> > > > > element).
> > > > > 
> > > > > Now, I can see two potential problems here:
> > > > > 
> > > > > - your depex is malformed (for whatever reason), and the eval stack
> > > > > is not torn down entirely before reachig EFI_DEP_END. The code seems
> > > > > to handle that correctly, by returning FALSE.
> > > > > 
> > > > > - your depex is malformed such that it immediately starts with an
> > > > > EFI_DEP_END. The code is actually buggy for that case, because it
> > > > > decrements StackPtr first, before comparing it against &EvalStack[0].
> > > > > That decrement invokes undefined behavior. However, I assume in
> > > > > practice the behavior will be the same as in the previous paragraph.
> > > > > 
> > > > > A NULL StackPtr value I cannot explain at all.
> > > > 
> > > > Agreed with Laszlo here... the only thing that I could think of is
> > > > memory corruption. Several people at Intel (myself included) as
> > > > working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms
> > > > right now. I would recommend you wait for us to release our code as
> > > > opposed
> > > > 
> > > > > Laszlo
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115905): https://edk2.groups.io/g/devel/message/115905
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

I solved my issue it seems that I fo got to add the crucial PcdPei.inf peim (yes all this fuss for a simple mistake) to my fdf file thank you for your help 




Sent with Proton Mail secure email.

On Saturday, February 24th, 2024 at 5:41 PM, memristor2 <memristor2@proton.me> wrote:

> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io memristor2=proton.me@groups.io wrote:
> 
> > Sent with Proton Mail secure email.
> > 
> > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L nathaniel.l.desimone@intel.com wrote:
> > 
> > > > -----Original Message-----
> > > > From: memristor2 memristor2@proton.me
> > > > Sent: Thursday, February 22, 2024 5:51 AM
> > > > To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com
> > > > Cc: devel@edk2.groups.io; lersek@redhat.com
> > > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleStream
> > > > Platform
> > > > 
> > > > Thank you. Based on what you told me (memory corruption and and the
> > > > unlikelihood of the stack pointer being NULL) my only suspicion would be the
> > > > microcode I am using, since the only platform dependent parts up until this
> > > > part would be the microcode and the FSP-T and since I am using the FSP for
> > > > EagleStream only the microcode would be left to change.
> > > 
> > > Having correct microcode is absolutely essential for sure. But microcode & FSP
> > > are not the only platform dependent components. Any code contained in a
> > > *BoardPkg is considered to be platform dependent in some way. I would be
> > > surprised if simply adding the microcode will fix this problem.
> > > 
> > > > Up until now I was using Whitley's microcode (since EagleStream's hadn't been
> > > > released yet). To be honest I still don't have a proper comprehension of the
> > > > concept of the microcode so I thought maybe I could use Whitley's microcode.
> > > 
> > > Here is what microcode is in a nutshell. Every x86 processor designed since
> > > ~1990 is actually a RISC-based CPU design internally. The microcode contains a
> > > lookup table that maps each CPU instruction into one or more sub-instructions
> > > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which are
> > > the instructions that the hidden RISC processor executes. This hidden RISC
> > > processor has an unpublished instruction set that no one outside of the CPU
> > > vendor sees.
> > > 
> > > The initial purpose of RISC was to eliminate the need for microcode, as the
> > > complex decode engine and ROM consumed transistors that could instead be used
> > > for things like a wider ALU. But then in the mid-1990s, a new technology came
> > > along called out-of-order execution. The idea behind out-of-order execution is
> > > that we can expand the purpose of microcode to be more than just a lookup table,
> > > it can actually change the sequence of micro-OPs so that the program runs
> > > faster. So now, microcode is not only a lookup table, but it also provides a
> > > programmable instruction scheduler.
> > > 
> > > The use of out-of-order execution was made possible by Moore's law. Moore's law
> > > drove rapidly increasing transistor counts during the 1990s. No longer would you
> > > need to decide whether to use your transistor budget for microcode or for a
> > > wider ALU... you had plenty of transistors so you could do both! Both of them
> > > together yields the fastest CPU designs by a large margin. All of these factors
> > > came together at once, and suddenly any CPU design that didn't use microcode was
> > > obsolete by the year 2000.
> > > 
> > > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern
> > > high-performance CPUs require very complex microcode. The existence of that
> > > microcode abstracts most of the differences between traditionally RISC ISAs like
> > > ARM and traditionally CISC ISAs like x86.
> > 
> > Thank you I just learned as much as I learned in my Advanced Computer Architecture course. Your explanations are higly appreciated.
> > 
> > > > But now that EagleStream's microcode has been released I'll try with that and
> > > > let you know whether it works or not. Yet I am still skeptical about it being
> > > > a microcode issue because my thought is that the microcode is procosser
> > > > architecture-based code rather than it being platform-based code. Please
> > > > correct me if I am wrong on this matter.
> > > 
> > > You intuition that it is not a microcode issue is correct. There are a lot of
> > > things in the BoardPkg that change with each platform design. For an example of
> > > that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg.
> 
> I forgot to mention one thing. The microcode released for EagleStream has two issues:
> 1. It was "EaglestreamSiliconBinPkg" instead of "EagleStreamSiliconBinPkg".
> 2. There was no .inf file defined for it
> So I added the .INF file but as we both thought it didn't change the outcome, but I for sure could say each tick became shorter resulting in preformance improvement
> 
> > So I must take back my first thought that the StackPtr was NULL now it wasn't. StackPtr->Operator is always NULL, Which is another issue. The thing is that all of the Peims are found inside the FV but whenever the PeimDispatchReadiness() routine calls IsPpiInstalled() it seems it doesn't find the Ppis and I don't have any idea why
> > 
> > > > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L
> > > > nathaniel.l.desimone@intel.com wrote:
> > > > 
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Laszlo
> > > > > > Ersek
> > > > > > Sent: Wednesday, February 21, 2024 3:59 PM
> > > > > > To: devel@edk2.groups.io; memristor2@proton.me
> > > > > > Subject: Re: [edk2-devel] Peims are not gettting Dispatched in
> > > > > > EagleStream Platform
> > > > > > 
> > > > > > On 2/21/24 07:59, memristor2 via groups.io wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > > I am trying to build edk2-platforms for EagleStream Platform. The
> > > > > > > problem I am facing now is that the Peims are not getting
> > > > > > > dispatched when The PeiMain routine calls PeiDispatcher().
> > > > > > > After digging deeper into it it seems that the DepexSatisfied()
> > > > > > > routine is always returning false. So I also checked this and
> > > > > > > realized that the place that is returning false is inside the
> > > > > > > PeimDispatchReadiness
> > > > > > > function:
> > > > > > > ||```
> > > > > > > case (EFI_DEP_END): DEBUG ((DEBUG_DISPATCH, " END\n"));
> > > > > > > StackPtr--; // // Check to make sure EvalStack is balanced. If
> > > > > > > not, then there is // an error in the dependency grammar, so
> > > > > > > return EFI_INVALID_PARAMETER.
> > > > > > > //
> > > > > > > if (StackPtr != &EvalStack[0]) {
> > > > > > > 
> > > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = FALSE (Underflow Error)\n"));
> > > > > > > return FALSE; }
> > > > > > > 
> > > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT = %a\n", IsPpiInstalled
> > > > > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE"));
> > > > > > > 
> > > > > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems that
> > > > > > > when entering IsPpiInstalled StackPtr in always NULL.
> > > > > > > Any thoughts on this?
> > > > > > 
> > > > > > StackPtr being NULL seems extremely unlikely; it is supposed to
> > > > > > point to elements of the EvalStack local array (or I guess one past the last
> > > > > > element).
> > > > > > 
> > > > > > Now, I can see two potential problems here:
> > > > > > 
> > > > > > - your depex is malformed (for whatever reason), and the eval stack
> > > > > > is not torn down entirely before reachig EFI_DEP_END. The code seems
> > > > > > to handle that correctly, by returning FALSE.
> > > > > > 
> > > > > > - your depex is malformed such that it immediately starts with an
> > > > > > EFI_DEP_END. The code is actually buggy for that case, because it
> > > > > > decrements StackPtr first, before comparing it against &EvalStack[0].
> > > > > > That decrement invokes undefined behavior. However, I assume in
> > > > > > practice the behavior will be the same as in the previous paragraph.
> > > > > > 
> > > > > > A NULL StackPtr value I cannot explain at all.
> > > > > 
> > > > > Agreed with Laszlo here... the only thing that I could think of is
> > > > > memory corruption. Several people at Intel (myself included) as
> > > > > working on getting an EaglestreamOpenBoardPkg posted to edk2-platforms
> > > > > right now. I would recommend you wait for us to release our code as
> > > > > opposed
> > > > > 
> > > > > > Laszlo
> > 
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116162): https://edk2.groups.io/g/devel/message/116162
Mute This Topic: https://groups.io/mt/104498510/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-