On 03/06/18 01:45, Brian J. Johnson wrote:
> On 03/05/2018 12:22 PM, Laszlo Ersek wrote:
>> PEIMs generally "execute in place" (XIP), i.e. they run from flash, not
>> RAM. In this status they use "temporary RAM" (e.g. CPU caches configured
>> like RAM) for stack & heap; whatever HOBs they produce a
On 03/05/2018 12:22 PM, Laszlo Ersek wrote:
PEIMs generally "execute in place" (XIP), i.e. they run from flash, not
RAM. In this status they use "temporary RAM" (e.g. CPU caches configured
like RAM) for stack & heap; whatever HOBs they produce are stored in
"temp RAM" as well. Then one of the PEI
Laszlo:
I also suggest to check the generated ProcessLibraryConstructorList ()
function. It is in the driver build output AutoGen.c code. You can check what
library function be called in this function. Then, further add debug message in
the library function. I suspect some function does the wr
> On Mar 5, 2018, at 10:22 AM, Laszlo Ersek wrote:
>
> On 03/05/18 15:05, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Feb 23, 2018 at 8:45 PM, Andrew Fish wrote:
>>>
>>>
On Feb 23, 2018, at 5:23 AM, marcandre.lur...@redhat.com wrote:
From: Marc-André Lureau
With
On 03/05/18 15:05, Marc-André Lureau wrote:
> Hi
>
> On Fri, Feb 23, 2018 at 8:45 PM, Andrew Fish wrote:
>>
>>
>>> On Feb 23, 2018, at 5:23 AM, marcandre.lur...@redhat.com wrote:
>>>
>>> From: Marc-André Lureau
>>>
>>> Without this hack, GetNextHob() loops infinitely with the next
>>> patch. I do
Hi
On Fri, Feb 23, 2018 at 8:45 PM, Andrew Fish wrote:
>
>
>> On Feb 23, 2018, at 5:23 AM, marcandre.lur...@redhat.com wrote:
>>
>> From: Marc-André Lureau
>>
>> Without this hack, GetNextHob() loops infinitely with the next patch.
>> I don't understand the reason.
>>
>> The loop is triggered by
> On Feb 23, 2018, at 5:23 AM, marcandre.lur...@redhat.com wrote:
>
> From: Marc-André Lureau
>
> Without this hack, GetNextHob() loops infinitely with the next patch.
> I don't understand the reason.
>
> The loop is triggered by the GetFirstGuidHob (&gTpmErrorHobGuid) call.
>
> CC: Laszlo E
