public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "memristor2 via groups.io" <memristor2=proton.me@groups.io>
To: "Desimone, Nathaniel L" <nathaniel.l.desimone@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform
Date: Thu, 22 Feb 2024 13:50:37 +0000	[thread overview]
Message-ID: <PNMCtJ97xqUJ0Hi7FD3xNV0-6vNoK3gT5zhz5_HKbRAMwr5c-5vj6-n009ZIwkLeKigM3nzzg2hnQqgNWr-D10YhxfR1wSmjlgKb1l_E20s=@proton.me> (raw)
In-Reply-To: <PH0PR11MB583277BE86E7211D71523910CD562@PH0PR11MB5832.namprd11.prod.outlook.com>

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.desimone@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; memristor2@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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-02-22 13:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  6:59 [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform memristor2 via groups.io
2024-02-21  7:36 ` memristor2 via groups.io
2024-02-21 23:58 ` Laszlo Ersek
2024-02-22  0:12   ` Nate DeSimone
2024-02-22 13:50     ` memristor2 via groups.io [this message]
2024-02-23 20:45       ` Nate DeSimone
2024-02-24 13:30         ` memristor2 via groups.io
     [not found]         ` <17B6CFAF57BD7756.3842@groups.io>
2024-02-24 14:11           ` memristor2 via groups.io
2024-02-29 12:07             ` memristor2 via groups.io

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='PNMCtJ97xqUJ0Hi7FD3xNV0-6vNoK3gT5zhz5_HKbRAMwr5c-5vj6-n009ZIwkLeKigM3nzzg2hnQqgNWr-D10YhxfR1wSmjlgKb1l_E20s=@proton.me' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox