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.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 (#115816): https://edk2.groups.io/g/devel/message/115816
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]
-=-=-=-=-=-=-=-=-=-=-=-
