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 <memrist...@proton.me>
wrote:
>
>
>
>
>
> Sent with Proton Mail secure email.
>
>
> On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io
> memristor2=proton...@groups.io wrote:
>
> > 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.
>
> 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.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 (#116162): https://edk2.groups.io/g/devel/message/116162
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]
-=-=-=-=-=-=-=-=-=-=-=-
