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

["Nate DeSimone" <nathaniel.l.desimone@intel.com>]

> -----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]
-=-=-=-=-=-=-=-=-=-=-=-