From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id C2A49740034 for ; Sat, 24 Feb 2024 14:12:15 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=jDEzhaUiCBK6yKKBw5XKGbyp948kppMHkQD+UwQdARs=; c=relaxed/simple; d=groups.io; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:Feedback-ID:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1708783934; v=1; b=I18pgLxbZyHBJU1iL9aJhLyjs6CcbzjSFQI3JwYQT8B94Un/EVbEy1lws+Su2c/fODS+dBQq OMlPtYbS5r9Z3rbyFgzeZAqG/B0pcOmntIIfV94ZpS6tFS3iSz4DJeWI495H702rHAMoI92G/zf SlMA0Dus2ZwcYjgeHL/Tg0KM= X-Received: by 127.0.0.2 with SMTP id eQo3YY7687511x5BqhTrQmMn; Sat, 24 Feb 2024 06:12:14 -0800 X-Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by mx.groups.io with SMTP id smtpd.web10.19217.1708783933554981726 for ; Sat, 24 Feb 2024 06:12:13 -0800 Date: Sat, 24 Feb 2024 14:11:48 +0000 To: devel@edk2.groups.io From: "memristor2 via groups.io" Cc: "Desimone, Nathaniel L" , "lersek@redhat.com" Subject: Re: [edk2-devel] Peims are not gettting Dispatched in EagleStream Platform Message-ID: In-Reply-To: <17B6CFAF57BD7756.3842@groups.io> References: <0600b231-8baf-645a-a287-8d623f692bd8@redhat.com> <17B6CFAF57BD7756.3842@groups.io> Feedback-ID: 99609138:user:proton MIME-Version: 1.0 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,memristor2@proton.me List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: S2kYjB9KKZ01G3mPwJnVp2e3x7686176AA= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=I18pgLxb; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Sent with Proton Mail secure email. On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io wrote: >=20 >=20 >=20 >=20 >=20 > Sent with Proton Mail secure email. >=20 >=20 > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L natha= niel.l.desimone@intel.com wrote: >=20 > > > -----Original Message----- > > > From: memristor2 memristor2@proton.me > > > Sent: Thursday, February 22, 2024 5:51 AM > > > To: Desimone, Nathaniel L nathaniel.l.desimone@intel.com > > > Cc: devel@edk2.groups.io; lersek@redhat.com > > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in EagleS= tream > > > Platform > > >=20 > > > 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 unti= l this > > > part would be the microcode and the FSP-T and since I am using the FS= P for > > > EagleStream only the microcode would be left to change. > >=20 > > Having correct microcode is absolutely essential for sure. But microcod= e & 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 b= e > > surprised if simply adding the microcode will fix this problem. > >=20 > > > Up until now I was using Whitley's microcode (since EagleStream's had= n'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 mic= rocode. > >=20 > > Here is what microcode is in a nutshell. Every x86 processor designed s= ince > > ~1990 is actually a RISC-based CPU design internally. The microcode con= tains a > > lookup table that maps each CPU instruction into one or more sub-instru= ctions > > (sometimes called micro-instructions or micro-OPs (=C2=B5OPs for short)= ) which are > > the instructions that the hidden RISC processor executes. This hidden R= ISC > > processor has an unpublished instruction set that no one outside of the= CPU > > vendor sees. > >=20 > > The initial purpose of RISC was to eliminate the need for microcode, as= the > > complex decode engine and ROM consumed transistors that could instead b= e used > > for things like a wider ALU. But then in the mid-1990s, a new technolog= y came > > along called out-of-order execution. The idea behind out-of-order execu= tion is > > that we can expand the purpose of microcode to be more than just a look= up table, > > it can actually change the sequence of micro-OPs so that the program ru= ns > > faster. So now, microcode is not only a lookup table, but it also provi= des a > > programmable instruction scheduler. > >=20 > > The use of out-of-order execution was made possible by Moore's law. Moo= re'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 f= or a > > wider ALU... you had plenty of transistors so you could do both! Both o= f 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 micr= ocode was > > obsolete by the year 2000. > >=20 > > 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. >=20 > Thank you I just learned as much as I learned in my Advanced Computer Arc= hitecture course. Your explanations are higly appreciated. >=20 > > > 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 procoss= er > > > architecture-based code rather than it being platform-based code. Ple= ase > > > correct me if I am wrong on this matter. > >=20 > > 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 ex= ample of > > that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg. I forgot to mention one thing. The microcode released for EagleStream has t= wo 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 outcom= e, but I for sure could say each tick became shorter resulting in preforman= ce improvement >=20 > So I must take back my first thought that the StackPtr was NULL now it wa= sn'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 PeimDispa= tchReadiness() routine calls IsPpiInstalled() it seems it doesn't find the = Ppis and I don't have any idea why >=20 > > > On Thursday, February 22nd, 2024 at 3:42 AM, Desimone, Nathaniel L > > > nathaniel.l.desimone@intel.com wrote: > > >=20 > > > > > -----Original Message----- > > > > > From: devel@edk2.groups.io devel@edk2.groups.io On Behalf Of Lasz= lo > > > > > 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 > > > > >=20 > > > > > On 2/21/24 07:59, memristor2 via groups.io wrote: > > > > >=20 > > > > > > Hi, > > > > > > I am trying to build edk2-platforms for EagleStream Platform. T= he > > > > > > 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 !=3D &EvalStack[0]) { > > > > > >=20 > > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT =3D FALSE (Underflow Error)\n"= )); > > > > > > return FALSE; } > > > > > >=20 > > > > > > DEBUG ((DEBUG_DISPATCH, " RESULT =3D %a\n", IsPpiInstalled > > > > > > (PeiServices, StackPtr) ? "TRUE" : "FALSE")); > > > > > >=20 > > > > > > return IsPpiInstalled (PeiServices, StackPtr); ``` It seems tha= t > > > > > > when entering IsPpiInstalled StackPtr in always NULL. > > > > > > Any thoughts on this? > > > > >=20 > > > > > StackPtr being NULL seems extremely unlikely; it is supposed to > > > > > point to elements of the EvalStack local array (or I guess one pa= st the last > > > > > element). > > > > >=20 > > > > > Now, I can see two potential problems here: > > > > >=20 > > > > > - your depex is malformed (for whatever reason), and the eval sta= ck > > > > > is not torn down entirely before reachig EFI_DEP_END. The code se= ems > > > > > to handle that correctly, by returning FALSE. > > > > >=20 > > > > > - 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 paragra= ph. > > > > >=20 > > > > > A NULL StackPtr value I cannot explain at all. > > > >=20 > > > > 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-platfo= rms > > > > right now. I would recommend you wait for us to release our code as > > > > opposed > > > >=20 > > > > > Laszlo >=20 >=20 >=20 >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-