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