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