Sent with Proton Mail secure email.
On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L
<nathaniel.l.desim...@intel.com> wrote:
> > -----Original Message-----
> > From: memristor2 memrist...@proton.me
> > Sent: Thursday, February 22, 2024 5:51 AM
> > To: Desimone, Nathaniel L nathaniel.l.desim...@intel.com
> > Cc: devel@edk2.groups.io; ler...@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.desim...@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; memrist...@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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
