[edk2] EDKII_WRITE FUNCTION TO A FILE DOES NOT WORK(for me)

[Gabor Puha]

All,

I am developing an efi loader and having problem to write an allocated mem
or text to a file on efi partition. I can create and del but I am not able
to write a file. I have checked all doc but example with declaration was
not found. Please, help with an example(or correct my one)...regards
Gab..

here my code:


static CHAR16 *PATH = L"\\TEST\\test.txt

EFI_STATUS SavePass(EFI_DEVICE_PATH **LoaderDevicePath2)
{
EFI_FILE_IO_INTERFACE *Device_unit;

EFI_FILE_HANDLE efi_hand_root,pass_file;

EFI_HANDLE* efi_hand_array;

UINTN handler,i;

EFI_STATUS ferr,err;


UINTN Size,wsize;
VOID *OsKernelBuffer = NULL;
*LoaderDevicePath2 = (EFI_DEVICE_PATH *)NULL;

Size=0x0012;

BS->AllocatePool(EfiLoaderData, Size, &OsKernelBuffer);


wsize=sizeof(OsKernelBuffer);


  err =
efi_hand_root->Open(efi_hand_root,&pass_file,PATH,EFI_FILE_MODE_WRITE |
EFI_FILE_MODE_CREATE | EFI_FILE_MODE_READ,0);  //THIS IS OK. ITS CREATE IS
SUCCESS

if(err == EFI_SUCCESS)

{



Print(L"[*] File Opened..\r\n");


ferr=efi_hand_root->Write(efi_hand_root,wsize,OsKernelBuffer); //IT
returns with 80002 means  EFI_INVALID_PARAMETER


Print(L"\nPress [ENTER] to continue...\n");
Input(NULL,Keypass,10);

Print(L"Write ERROR: %lX \r\n",ferr);
if(ferr == EFI_SUCCESS)
{
efi_hand_root->Flush(pass_file);
efi_hand_root->Close(pass_file);


Print(L"[*] Write Success...\r\n");
}

efi_hand_root->Close(pass_file);

*LoaderDevicePath2 = FileDevicePath(efi_hand_array[i],PATH);


break;

}



break;

}


}



FreePool(OsKernelBuffer);

return err;
}
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Sergey Isakov]

Is it possible to include new family?
---
  Ia32/Thunk16.s| CLANG 
  Ia32/Thunk16.nasm | GCC 

---

On 28.08.2014, at 8:27, Andrew Fish wrote:

> 
> On Aug 27, 2014, at 8:51 PM, Jordan Justen  wrote:
> 
>> On Wed, Aug 27, 2014 at 8:43 PM, Sergey Isakov  wrote:
>>> Jordan,
>>> There was no issue with gcc49 toolchain in x86_64.
>>> I made an attempt to use nasm with XCLANG toolset but failed on ld:
>>> I seems have to wait while Andrew make XCODE5 fully working.
>> 
>> Since this change will affect all toolchains except Visual Studio and
>> ICC, I think we need to make sure we don't break builds that use
>> XCLANG. Would you (or Andrew) be able to help debug the build issue
>> you are seeing?
>> 
> 
> Is there any way to still use the current .S files with XCODE?  I was hoping 
> we could use the BUILDRULEFAMILY, but that does not seem to be supported. 
> I’ve never tried nasm, so I have no idea how well it works?
> 
>> (Arg, we really need to get clang working on Linux…)
> 
> If you send me the error messages I can point you in the right direction.
> 
> Thanks,
> 
> Andrew Fish
> 
>> -Jordan
>> 
>>> On 28 авг. 2014 г., at 7:32, Andrew Fish  wrote:
>>> 
>>> On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:
>>> 
>>> Hi,
>>> What change do you make? In previous mail, you mention x86_64 there is no
>>> issue.
>>> 
>>> Liming,
>>> 
>>> On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the
>>> prefix applied to user labels (symbols visible to C) in assembly. Some
>>> versions set it to '', and some version have it set to ‘_'
>>> 
>>> #define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)
>>> 
>>> So you can have a bug that passes on one version and fails on another.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> Thanks
>>> Liming
>>> From: Sergey Isakov [mailto:isakov...@bk.ru]
>>> Sent: Thursday, August 28, 2014 4:42 AM
>>> To: edk2-devel@lists.sourceforge.net
>>> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for
>>> non-MSVC
>>> 
>>> The error disappeared but I still have other mistakes
>>> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj)
>>> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
>>> Still in work
>>> 
>>> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>>> 
>>> 
>>> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>>> 
>>> And one new question. Why _16GdtrBase with underscore while m16Start without
>>> it?
>>> 
>>> Does replacing m16Start with ASM_PFX(m16Start) help?
>>> 
>>> It looks like I didn't convert this up properly. The MASM code didn't
>>> use ASM_PFX...
>>> 
>>> -Jordan
>>> 
>>> 
>>> ——
>>> ;
>>> ; These are global constant to convey information to C code.
>>> ;
>>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>>> m16Start
>>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>>> 
>>> —
>>> I got an error with this
>>> Thunk16.iii:60: error: symbol `m16Start' undefined
>>> 
>>> 
>>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>>> 
>>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>>> 
>>> Hi sirs,
>>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>>> For ia32 compilation disasm shows not good codes
>>> -
>>>  :
>>> 0: 00 00 add%al,(%eax)
>>> 2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 <_BackFromUserCode>:
>>> 6: 16   push   %ss
>>> 7: 0e   push   %cs
>>> 8: 67 e8 00 00 66 9c addr16 call 9c66000e
>>> 
>>> 
>>> 000c <_BackFromUserCode.Base>:
>>> c: 66 9c pushfw
>>> e: fa   cli
>>> 
>>> -
>>> to compare gcc-4.9.1 cvompilation
>>> -
>>>  :
>>> 0: 00 00 add%al,(%eax)
>>> 2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 :
>>> 6: 16   push   %ss
>>> 7: 0e   push   %cs
>>> 8: 66 e8 00 00   callw  c 
>>> ...
>>> 
>>> 000e :
>>> e: 66 9c pushfw
>>> 10: fa   cli
>>> 
>>> --
>>> May be change a32 prefix to o32 in the line:
>>> "a32 call.Base   ; push eip"
>>> ?
>>> 
>>> 
>>> In the X64 file, I used:
>>> calldword .Base
>>> 
>>> I notice this produced the same code as:
>>> o32 calldword .Base
>>> 
>>> But,
>>> o32 call.Base
>>> seems to produce invalid code. (OVMF hangs.)
>>> 
>>> It does seem like:
>>> a32 call.Base
>>> is functional as well, but I know we are attempting to make the new
>>> nasm code produce similar code to the old asm code where reasonable.
>>> 
>>> I think I only changed it in the X64 file to try to match the old 'db' code.
>>> 
>>> -Jordan
>>> 
>>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>>> 
>>> On Tu

Re: [edk2] [Patch]ShellPkg: Remove 'STATIC' from function declarations to avoid source level debugging problem

[Andrew Fish]

On Aug 27, 2014, at 9:35 PM, Scott Duplichan  wrote:

> A couple of more points on this unusual policy of avoiding static functions:
>  
> 1) Wouldn't it make more sense for the debugger vendor to fix their bug 
> rather than endlessly code around it?
> 2) If static functions are not banned, then why are they getting removed?
>  
> I view it as an unsound engineering practice and unprofessional behavior for 
> employees of Intel to drive static functions out of an important open source 
> project because of a problem with some unnamed tool vendor. What other open 
> source project solves debugger problems this way? Where else in the world is 
> use of static functions banned discouraged in modern C code? The more UEFI 
> code differs from mainstream C code, the more difficult it is to get new 
> engineers interested in developing it.
>  

Since there is no dynamic linking in EFI the use of static functions in a 
driver or application has limited use. If you want to hide your code from 
yourself then static makes sense. The use of static probably makes more sense 
for private functions and globals in libraries, or in just porting existing 
code.

> Actually I think this debugger problem is an urban legend.

I seem to remember, it was 10+ years ago, that it was VS2003. It was probably a 
bug in the toolchain related to non standard usage for embedded development. 
Thus this rule ended up in the original Tiano coding style document, and it has 
probably been copied into subsequent versions (I only wrote the 1st one). 

Also since there is no dynamic linking it is possible that each module has a 
different instance of the same library function at a different address. I’ve 
seen this confuse debuggers in the past, usually due to a single symbol file 
having N instances of code at different addressees. Sometimes the issue is 
related to the debugger UI. 

Your debugger may vary (EmbeddedPkg breaking in at the BDS UI):
(lldb) br set -n DebugAssert
Breakpoint 2: 74 locations.
(lldb) br list
Current breakpoints:
1: name = 'SecGdbScriptBreak', locations = 1, resolved = 1, hit count = 72
Breakpoint commands:
  return lldbefi.LoadEmulatorEfiSymbols(frame, bp_loc, internal_dict)

  1.1: where = Host`SecGdbScriptBreak + 18 at Host.c:1143, address = 
0x0001e402, resolved, hit count = 72 

2: name = 'DebugAssert', locations = 74, resolved = 72, hit count = 0
  2.1: where = Host`DebugAssert + 15 at DebugLib.c:73, address = 
0x0001729f, resolved, hit count = 0 
  2.2: where = CarbonCore`DebugAssert + 57 at Debugging.c:100, address = 
0x7fff82585033, resolved, hit count = 0 
  2.3: where = EmuSec.dll`DebugAssert + 15 at DebugLib.c:136, address = 
0x000102022641, resolved, hit count = 0 
  2.4: where = PeiCore.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x000102024a03, resolved, hit count = 0 
  2.5: where = ReportStatusCodeRouterPei.dll`DebugAssert + 27 at 
DebugLib.c:271, address = 0x000102039373, resolved, hit count = 0 
  2.6: where = StatusCodeHandlerPei.dll`DebugAssert + 27 at DebugLib.c:271, 
address = 0x00010203bb53, resolved, hit count = 0 
  2.7: where = PcdPeim.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x0001020331cf, resolved, hit count = 0 
  2.8: where = BootModePei.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x00010204023f, resolved, hit count = 0 
  2.9: where = AutoScanPei.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x000102042237, resolved, hit count = 0 
  2.10: where = PeiCore.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x0aa3, unresolved, hit count = 0 
  2.11: where = FirmwareVolumePei.dll`DebugAssert + 27 at DebugLib.c:271, 
address = 0x000106fee1db, resolved, hit count = 0 
  2.12: where = FlashMapPei.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x000106feb00f, resolved, hit count = 0 
  2.13: where = ThunkPpiToProtocolPei.dll`DebugAssert + 27 at DebugLib.c:271, 
address = 0x000106fe8137, resolved, hit count = 0 
  2.14: where = FaultTolerantWritePei.dll`DebugAssert + 27 at DebugLib.c:271, 
address = 0x000106fe4d47, resolved, hit count = 0 
  2.15: where = PeiVariable.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x000106fe1163, resolved, hit count = 0 
  2.16: where = DxeIpl.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x000106fd97bf, resolved, hit count = 0 
  2.17: where = DxeCore.dll`DebugAssert + 15 at DebugLib.c:136, address = 
0x000106f8ccca, resolved, hit count = 0 
  2.18: where = DxeCore.dll`DebugAssert + 15 at DebugLib.c:136, address = 
0x2a8a, unresolved, hit count = 0 
  2.19: where = PcdDxe.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x00010665c4f3, resolved, hit count = 0 
  2.20: where = Metronome.dll`DebugAssert + 27 at DebugLib.c:271, address = 
0x00010666429f, resolved, hit count = 0 
  2.21: where = ReportStatusCodeRouterRuntimeDxe.dll`DebugAssert + 27 at 
DebugLib.c:271, address = 0x00010664844b, resolv

[edk2] Bitwise OR operator problems

[Tim Lewis]

It appears that this should prevent the display of the text statement. However, 
to my surprise, it works on NT32. Per operator precedence, it should be 8|8 is 
8, and 8 == 8 is TRUE.

suppressif 8|8 == 0x8;
text
help = STRING_TOKEN(STR_BITWISE_OR_HELP),
text  = STRING_TOKEN(STR_BITWISE_OR_PROMPT);
endif;

The equivalent 8&8 == 0x8 has no problem.
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib

[Tim Lewis]

Mike -
Using a non-RSC version of debug lib isn't an option for these customers.
Is it possible to handle the allocation outside of the RSC call itself? And get 
notification if a new handler is installed to update
Tim

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 28, 2014 12:22 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode 
version of DebugLib

Tim,
Yes.  This issue has been around a while.  The workaround when you want to 
monitor every single pool operation in the DXE Core is to use a DebugLib 
instance that sends debug messages directly to a debug device such as 
MdePkg/Library/BaseDebugLibSerialPort.
The issue with using a DebugLib instance that sends debug messages through 
report status code is that the report status code services allocate from pool, 
which causes the recursion.
Thanks,
Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 27, 2014 9:00 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version 
of DebugLib

Symptom:
If "DEBUG_POOL" bit is set in PcdDebugPrintErrorLevel, BIOS will enter 
recursive loop. (A call B, B call C, C call A, )
Description:
This happens when the PeiDxeDebugLibReportStatusCode.inf version of DebugLib is 
used. We found it can be duplicated with revision 15913, although it appears 
the problem has been there for a while.
Procedure: Step by Step

1.DxeMain.c - Line 237, DxeMain()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

2.   DxeMain.c - Line 419, CoreInstallMultipleProtocolInterfaces()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

3.   Handle.c - Line 582, CoreInstallProtocolInterface()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

4.Handle.c - Line 311, CoreInstallProtocolInterfaceNotify()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

5.   Handle.c - Line 384, CoreAcquireProtocolLock()   <-First Lock

~\MdeModulePkg\Core\Dxe\Hand\Handle.c

6.   Handle.c - Line 389, CoreFindProtocolEntry (Protocol, TRUE)
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

7.   Handle.c - Line 136, AllocatePool()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

8.   MemoryAllocationLib.c - Line 405, InternalAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

9.   MemoryAllocationLib.c - Line 380, CoreAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

10.   Pool.c - Line 216, CoreAllocatePoolI()
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

11.   Pool.c - Line 343, DEBUG()  <- It will run when efidebug BIOS + 
(PcdDebugPrintErrorLevel  | DEBUG_POOL)
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

12.   DebugLib.c - Line 50, DebugPrint()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

13.   DebugLib.c - Line 219, REPORT_STATUS_CODE_EX()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

14.   ReportStatusCodeLib.c - Line 481, ReportStatusCodeEx()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

15.   ReportStatusCodeLib.c - Line 555, InternalReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

16.   ReportStatusCodeLib.c - Line 102, InternalGetReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

17.   ReportStatusCodeLib.c - Line 57, gBS->LocateProtocol()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

18.   Locate.c - Line 552, CoreLocateProtocol()
~\MdeModulePkg\Core\Dxe\Hand\Locate.c

19.   Locate.c - Line 583, CoreAcquireProtocolLock() <-Second Lock (enter 
ASSERT())

~\MdeModulePkg\Core\Dxe\Hand\Locate.c

20.   DebugLib.c - Line 253, DebugAssert()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

21.   DebugLib.c - Line 317, REPORT_STATUS_CODE_EX()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

22.Enter recursive loop, step 
21->14->15->...->21->14->15->..

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch]ShellPkg: Remove 'STATIC' from function declarations to avoid source level debugging problem

[Scott Duplichan]

A couple of more points on this unusual policy of avoiding static functions:

 

1) Wouldn't it make more sense for the debugger vendor to fix their bug rather 
than endlessly code around it?

2) If static functions are not banned, then why are they getting removed?

 

I view it as an unsound engineering practice and unprofessional behavior for 
employees of Intel to drive static functions out of an
important open source project because of a problem with some unnamed tool 
vendor. What other open source project solves debugger
problems this way? Where else in the world is use of static functions banned 
discouraged in modern C code? The more UEFI code
differs from mainstream C code, the more difficult it is to get new engineers 
interested in developing it.

 

Actually I think this debugger problem is an urban legend. Debuggers generally 
process Microsoft PDB files using code supplied by
Microsoft. If either the PDB contents or the Microsoft supplied processing code 
had a problem, it would likely show up everywhere
Microsoft build tools are used.

 

Thanks,

Scott

From: Qiu, Shumin [mailto:shumin@intel.com] 
Sent: Wednesday, August 27, 2014 09:40 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch]ShellPkg: Remove 'STATIC' from function declarations to 
avoid source level debugging problem

 

Hi Jaben,

Can you help to review this patch? Internal linkage (ie. STATIC) functions have 
caused problems with source level debugging before,
so we generally avoid STATIC in ShellPkg.

 

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Qiu Shumin mailto:shumin@intel.com> >

 

Thanks

Shumin

 

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Andrew Fish]

On Aug 27, 2014, at 8:51 PM, Jordan Justen  wrote:

> On Wed, Aug 27, 2014 at 8:43 PM, Sergey Isakov  wrote:
>> Jordan,
>> There was no issue with gcc49 toolchain in x86_64.
>> I made an attempt to use nasm with XCLANG toolset but failed on ld:
>> I seems have to wait while Andrew make XCODE5 fully working.
> 
> Since this change will affect all toolchains except Visual Studio and
> ICC, I think we need to make sure we don't break builds that use
> XCLANG. Would you (or Andrew) be able to help debug the build issue
> you are seeing?
> 

Is there any way to still use the current .S files with XCODE?  I was hoping we 
could use the BUILDRULEFAMILY, but that does not seem to be supported. 
I’ve never tried nasm, so I have no idea how well it works?

> (Arg, we really need to get clang working on Linux…)

If you send me the error messages I can point you in the right direction.

Thanks,

Andrew Fish

> -Jordan
> 
>> On 28 авг. 2014 г., at 7:32, Andrew Fish  wrote:
>> 
>> On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:
>> 
>> Hi,
>>  What change do you make? In previous mail, you mention x86_64 there is no
>> issue.
>> 
>> Liming,
>> 
>> On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the
>> prefix applied to user labels (symbols visible to C) in assembly. Some
>> versions set it to '', and some version have it set to ‘_'
>> 
>> #define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)
>> 
>> So you can have a bug that passes on one version and fails on another.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> Thanks
>> Liming
>> From: Sergey Isakov [mailto:isakov...@bk.ru]
>> Sent: Thursday, August 28, 2014 4:42 AM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for
>> non-MSVC
>> 
>> The error disappeared but I still have other mistakes
>> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj)
>> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
>> Still in work
>> 
>> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>> 
>> 
>> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>> 
>> And one new question. Why _16GdtrBase with underscore while m16Start without
>> it?
>> 
>> Does replacing m16Start with ASM_PFX(m16Start) help?
>> 
>> It looks like I didn't convert this up properly. The MASM code didn't
>> use ASM_PFX...
>> 
>> -Jordan
>> 
>> 
>> ——
>> ;
>> ; These are global constant to convey information to C code.
>> ;
>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>> m16Start
>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>> 
>> —
>> I got an error with this
>> Thunk16.iii:60: error: symbol `m16Start' undefined
>> 
>> 
>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>> 
>> Hi sirs,
>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>> For ia32 compilation disasm shows not good codes
>> -
>>  :
>> 0: 00 00 add%al,(%eax)
>> 2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 <_BackFromUserCode>:
>> 6: 16   push   %ss
>> 7: 0e   push   %cs
>> 8: 67 e8 00 00 66 9c addr16 call 9c66000e
>> 
>> 
>> 000c <_BackFromUserCode.Base>:
>> c: 66 9c pushfw
>> e: fa   cli
>> 
>> -
>> to compare gcc-4.9.1 cvompilation
>> -
>>  :
>> 0: 00 00 add%al,(%eax)
>> 2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 :
>> 6: 16   push   %ss
>> 7: 0e   push   %cs
>> 8: 66 e8 00 00   callw  c 
>> ...
>> 
>> 000e :
>> e: 66 9c pushfw
>> 10: fa   cli
>> 
>> --
>> May be change a32 prefix to o32 in the line:
>> "a32 call.Base   ; push eip"
>> ?
>> 
>> 
>> In the X64 file, I used:
>> calldword .Base
>> 
>> I notice this produced the same code as:
>> o32 calldword .Base
>> 
>> But,
>> o32 call.Base
>> seems to produce invalid code. (OVMF hangs.)
>> 
>> It does seem like:
>> a32 call.Base
>> is functional as well, but I know we are attempting to make the new
>> nasm code produce similar code to the old asm code where reasonable.
>> 
>> I think I only changed it in the X64 file to try to match the old 'db' code.
>> 
>> -Jordan
>> 
>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>> 
>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>  wrote:
>> 
>> This series:
>> 
>> * Adds support for creating object files from .nasm source files to
>> 
>> allow NASM source files to be linked into libraries and images
>> 
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> 
>> * Convert BaseLib to use NASM Source Files for Thu

Re: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib

[Kinney, Michael D]

Tim,
Yes.  This issue has been around a while.  The workaround when you want to 
monitor every single pool operation in the DXE Core is to use a DebugLib 
instance that sends debug messages directly to a debug device such as 
MdePkg/Library/BaseDebugLibSerialPort.
The issue with using a DebugLib instance that sends debug messages through 
report status code is that the report status code services allocate from pool, 
which causes the recursion.
Thanks,
Mike

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 27, 2014 9:00 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version 
of DebugLib

Symptom:
If "DEBUG_POOL" bit is set in PcdDebugPrintErrorLevel, BIOS will enter 
recursive loop. (A call B, B call C, C call A, )
Description:
This happens when the PeiDxeDebugLibReportStatusCode.inf version of DebugLib is 
used. We found it can be duplicated with revision 15913, although it appears 
the problem has been there for a while.
Procedure: Step by Step

1.DxeMain.c - Line 237, DxeMain()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

2.   DxeMain.c - Line 419, CoreInstallMultipleProtocolInterfaces()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

3.   Handle.c - Line 582, CoreInstallProtocolInterface()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

4.Handle.c - Line 311, CoreInstallProtocolInterfaceNotify()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

5.   Handle.c - Line 384, CoreAcquireProtocolLock()   <-First Lock

~\MdeModulePkg\Core\Dxe\Hand\Handle.c

6.   Handle.c - Line 389, CoreFindProtocolEntry (Protocol, TRUE)
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

7.   Handle.c - Line 136, AllocatePool()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

8.   MemoryAllocationLib.c - Line 405, InternalAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

9.   MemoryAllocationLib.c - Line 380, CoreAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

10.   Pool.c - Line 216, CoreAllocatePoolI()
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

11.   Pool.c - Line 343, DEBUG()  <- It will run when efidebug BIOS + 
(PcdDebugPrintErrorLevel  | DEBUG_POOL)
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

12.   DebugLib.c - Line 50, DebugPrint()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

13.   DebugLib.c - Line 219, REPORT_STATUS_CODE_EX()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

14.   ReportStatusCodeLib.c - Line 481, ReportStatusCodeEx()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

15.   ReportStatusCodeLib.c - Line 555, InternalReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

16.   ReportStatusCodeLib.c - Line 102, InternalGetReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

17.   ReportStatusCodeLib.c - Line 57, gBS->LocateProtocol()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

18.   Locate.c - Line 552, CoreLocateProtocol()
~\MdeModulePkg\Core\Dxe\Hand\Locate.c

19.   Locate.c - Line 583, CoreAcquireProtocolLock() <-Second Lock (enter 
ASSERT())

~\MdeModulePkg\Core\Dxe\Hand\Locate.c

20.   DebugLib.c - Line 253, DebugAssert()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

21.   DebugLib.c - Line 317, REPORT_STATUS_CODE_EX()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

22.Enter recursive loop, step 
21->14->15->...->21->14->15->..

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Endless Loop when DEBUG_POOL used with ReportStatusCode version of DebugLib

[Tim Lewis]

Symptom:
If "DEBUG_POOL" bit is set in PcdDebugPrintErrorLevel, BIOS will enter 
recursive loop. (A call B, B call C, C call A, )
Description:
This happens when the PeiDxeDebugLibReportStatusCode.inf version of DebugLib is 
used. We found it can be duplicated with revision 15913, although it appears 
the problem has been there for a while.
Procedure: Step by Step

1.DxeMain.c - Line 237, DxeMain()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

2.   DxeMain.c - Line 419, CoreInstallMultipleProtocolInterfaces()
~\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c

3.   Handle.c - Line 582, CoreInstallProtocolInterface()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

4.Handle.c - Line 311, CoreInstallProtocolInterfaceNotify()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

5.   Handle.c - Line 384, CoreAcquireProtocolLock()   <-First Lock

~\MdeModulePkg\Core\Dxe\Hand\Handle.c

6.   Handle.c - Line 389, CoreFindProtocolEntry (Protocol, TRUE)
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

7.   Handle.c - Line 136, AllocatePool()
~\MdeModulePkg\Core\Dxe\Hand\Handle.c

8.   MemoryAllocationLib.c - Line 405, InternalAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

9.   MemoryAllocationLib.c - Line 380, CoreAllocatePool()
~\MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c

10.   Pool.c - Line 216, CoreAllocatePoolI()
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

11.   Pool.c - Line 343, DEBUG()  <- It will run when efidebug BIOS + 
(PcdDebugPrintErrorLevel  | DEBUG_POOL)
~\MdeModulePkg\Core\Dxe\Mem\Pool.c

12.   DebugLib.c - Line 50, DebugPrint()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

13.   DebugLib.c - Line 219, REPORT_STATUS_CODE_EX()
~\IntelFrameworkModulePkg\Library\PeiDxeDebugLibReportStatusCode\DebugLib.c

14.   ReportStatusCodeLib.c - Line 481, ReportStatusCodeEx()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

15.   ReportStatusCodeLib.c - Line 555, InternalReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

16.   ReportStatusCodeLib.c - Line 102, InternalGetReportStatusCode()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

17.   ReportStatusCodeLib.c - Line 57, gBS->LocateProtocol()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

18.   Locate.c - Line 552, CoreLocateProtocol()
~\MdeModulePkg\Core\Dxe\Hand\Locate.c

19.   Locate.c - Line 583, CoreAcquireProtocolLock() <-Second Lock (enter 
ASSERT())

~\MdeModulePkg\Core\Dxe\Hand\Locate.c

20.   DebugLib.c - Line 253, DebugAssert()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

21.   DebugLib.c - Line 317, REPORT_STATUS_CODE_EX()
~\MdeModulePkg\Library\DxeReportStatusCodeLib\ReportStatusCodeLib.c

22.Enter recursive loop, step 
21->14->15->...->21->14->15->..

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Andrew Fish]

On Aug 27, 2014, at 8:43 PM, Sergey Isakov  wrote:

> Jordan,
> There was no issue with gcc49 toolchain in x86_64.
> I made an attempt to use nasm with XCLANG toolset but failed on ld:
> I seems have to wait while Andrew make XCODE5 fully working.

 __USER_LABEL_PREFIX__ is set to _ on clang (XCODE5). 

Actually I just noticed you are getting an illegal text-relocation error. This 
is usually caused by an absolute relocation, and clang wants it to be IP 
relative. Basically Xcode/clang only supports a subset of the relocations that 
gcc uses for X64. 

Thanks,

Andrew Fish

> Sergey
> 
> On 28 авг. 2014 г., at 7:32, Andrew Fish  wrote:
> 
>> 
>> On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:
>> 
>>> Hi,
>>>   What change do you make? In previous mail, you mention x86_64 there is no 
>>> issue.
>>>  
>> 
>> Liming,
>> 
>> On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the 
>> prefix applied to user labels (symbols visible to C) in assembly. Some 
>> versions set it to '', and some version have it set to ‘_'
>> 
>> #define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)
>> 
>> So you can have a bug that passes on one version and fails on another. 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks
>>> Liming
>>> From: Sergey Isakov [mailto:isakov...@bk.ru] 
>>> Sent: Thursday, August 28, 2014 4:42 AM
>>> To: edk2-devel@lists.sourceforge.net
>>> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for 
>>> non-MSVC
>>>  
>>> The error disappeared but I still have other mistakes
>>> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj) 
>>> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
>>> Still in work
>>>  
>>> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>>> 
>>> 
>>> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>>> 
>>> And one new question. Why _16GdtrBase with underscore while m16Start without
>>> it?
>>> 
>>> Does replacing m16Start with ASM_PFX(m16Start) help?
>>> 
>>> It looks like I didn't convert this up properly. The MASM code didn't
>>> use ASM_PFX...
>>> 
>>> -Jordan
>>> 
>>> 
>>> ——
>>> ;
>>> ; These are global constant to convey information to C code.
>>> ;
>>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>>> m16Start
>>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>>> 
>>> —
>>> I got an error with this
>>> Thunk16.iii:60: error: symbol `m16Start' undefined
>>> 
>>> 
>>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>>> 
>>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>>> 
>>> Hi sirs,
>>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>>> For ia32 compilation disasm shows not good codes
>>> -
>>>  :
>>>  0: 00 00 add%al,(%eax)
>>>  2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 <_BackFromUserCode>:
>>>  6: 16   push   %ss
>>>  7: 0e   push   %cs
>>>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
>>> 
>>> 
>>> 000c <_BackFromUserCode.Base>:
>>>  c: 66 9c pushfw
>>>  e: fa   cli
>>> 
>>> -
>>> to compare gcc-4.9.1 cvompilation
>>> -
>>>  :
>>>  0: 00 00 add%al,(%eax)
>>>  2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 :
>>>  6: 16   push   %ss
>>>  7: 0e   push   %cs
>>>  8: 66 e8 00 00   callw  c 
>>> ...
>>> 
>>> 000e :
>>>  e: 66 9c pushfw
>>> 10: fa   cli
>>> 
>>> --
>>> May be change a32 prefix to o32 in the line:
>>> "a32 call.Base   ; push eip"
>>> ?
>>> 
>>> 
>>> In the X64 file, I used:
>>> calldword .Base
>>> 
>>> I notice this produced the same code as:
>>> o32 calldword .Base
>>> 
>>> But,
>>> o32 call.Base
>>> seems to produce invalid code. (OVMF hangs.)
>>> 
>>> It does seem like:
>>> a32 call.Base
>>> is functional as well, but I know we are attempting to make the new
>>> nasm code produce similar code to the old asm code where reasonable.
>>> 
>>> I think I only changed it in the X64 file to try to match the old 'db' code.
>>> 
>>> -Jordan
>>> 
>>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>>> 
>>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>>  wrote:
>>> 
>>> This series:
>>> 
>>> * Adds support for creating object files from .nasm source files to
>>> 
>>> allow NASM source files to be linked into libraries and images
>>> 
>>> * Adds NASM source files for Thunk16 on IA32 and X64
>>> 
>>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>>> 
>>> GNU Assembler (.S) files
>>> 
>>> - This will make NASM a build requirement for MdePkg with IA32 &
>>> 
>>>   X64 on all toolchains except MSVC a

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Jordan Justen]

On Wed, Aug 27, 2014 at 8:43 PM, Sergey Isakov  wrote:
> Jordan,
> There was no issue with gcc49 toolchain in x86_64.
> I made an attempt to use nasm with XCLANG toolset but failed on ld:
> I seems have to wait while Andrew make XCODE5 fully working.

Since this change will affect all toolchains except Visual Studio and
ICC, I think we need to make sure we don't break builds that use
XCLANG. Would you (or Andrew) be able to help debug the build issue
you are seeing?

(Arg, we really need to get clang working on Linux...)

-Jordan

> On 28 авг. 2014 г., at 7:32, Andrew Fish  wrote:
>
> On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:
>
> Hi,
>   What change do you make? In previous mail, you mention x86_64 there is no
> issue.
>
> Liming,
>
> On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the
> prefix applied to user labels (symbols visible to C) in assembly. Some
> versions set it to '', and some version have it set to ‘_'
>
> #define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)
>
> So you can have a bug that passes on one version and fails on another.
>
> Thanks,
>
> Andrew Fish
>
> Thanks
> Liming
> From: Sergey Isakov [mailto:isakov...@bk.ru]
> Sent: Thursday, August 28, 2014 4:42 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for
> non-MSVC
>
> The error disappeared but I still have other mistakes
> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj)
> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
> Still in work
>
> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>
>
> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>
> And one new question. Why _16GdtrBase with underscore while m16Start without
> it?
>
> Does replacing m16Start with ASM_PFX(m16Start) help?
>
> It looks like I didn't convert this up properly. The MASM code didn't
> use ASM_PFX...
>
> -Jordan
>
>
> ——
> ;
> ; These are global constant to convey information to C code.
> ;
> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
> m16Start
> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>
> —
> I got an error with this
> Thunk16.iii:60: error: symbol `m16Start' undefined
>
>
> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>
> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>
> Hi sirs,
> I tested Thunk16.nasm too. For x86_64 there is no issue.
> For ia32 compilation disasm shows not good codes
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
>
> 0006 <_BackFromUserCode>:
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
> 
>
> 000c <_BackFromUserCode.Base>:
>  c: 66 9c pushfw
>  e: fa   cli
>
> -
> to compare gcc-4.9.1 cvompilation
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
>
> 0006 :
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 66 e8 00 00   callw  c 
> ...
>
> 000e :
>  e: 66 9c pushfw
> 10: fa   cli
>
> --
> May be change a32 prefix to o32 in the line:
> "a32 call.Base   ; push eip"
> ?
>
>
> In the X64 file, I used:
> calldword .Base
>
> I notice this produced the same code as:
> o32 calldword .Base
>
> But,
> o32 call.Base
> seems to produce invalid code. (OVMF hangs.)
>
> It does seem like:
> a32 call.Base
> is functional as well, but I know we are attempting to make the new
> nasm code produce similar code to the old asm code where reasonable.
>
> I think I only changed it in the X64 file to try to match the old 'db' code.
>
> -Jordan
>
> On 27.08.2014, at 9:50, Jordan Justen wrote:
>
> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
>
> This series:
>
> * Adds support for creating object files from .nasm source files to
>
> allow NASM source files to be linked into libraries and images
>
> * Adds NASM source files for Thunk16 on IA32 and X64
>
> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>
> GNU Assembler (.S) files
>
> - This will make NASM a build requirement for MdePkg with IA32 &
>
>   X64 on all toolchains except MSVC and ICC.
>
>
> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>
> have not been tested very well yet.)
>
>
> This series is available in this git branch:
>
> https://github.com/jljusten/edk2.git nasm-v1
>
>
> I update my nasm branch based on the feedback.
>
> The differences vs. v1 are in the attached patch.
>
> Is anyone interested in seeing a v2 posted to the list?
>
> Liming, in p

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Sergey Isakov]

Jordan,
There was no issue with gcc49 toolchain in x86_64.
I made an attempt to use nasm with XCLANG toolset but failed on ld:
I seems have to wait while Andrew make XCODE5 fully working.
Sergey

On 28 авг. 2014 г., at 7:32, Andrew Fish  wrote:

> 
> On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:
> 
>> Hi,
>>   What change do you make? In previous mail, you mention x86_64 there is no 
>> issue.
>>  
> 
> Liming,
> 
> On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the 
> prefix applied to user labels (symbols visible to C) in assembly. Some 
> versions set it to '', and some version have it set to ‘_'
> 
> #define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)
> 
> So you can have a bug that passes on one version and fails on another. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> Thanks
>> Liming
>> From: Sergey Isakov [mailto:isakov...@bk.ru] 
>> Sent: Thursday, August 28, 2014 4:42 AM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for 
>> non-MSVC
>>  
>> The error disappeared but I still have other mistakes
>> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj) 
>> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
>> Still in work
>>  
>> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>> 
>> 
>> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>> 
>> And one new question. Why _16GdtrBase with underscore while m16Start without
>> it?
>> 
>> Does replacing m16Start with ASM_PFX(m16Start) help?
>> 
>> It looks like I didn't convert this up properly. The MASM code didn't
>> use ASM_PFX...
>> 
>> -Jordan
>> 
>> 
>> ——
>> ;
>> ; These are global constant to convey information to C code.
>> ;
>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>> m16Start
>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>> 
>> —
>> I got an error with this
>> Thunk16.iii:60: error: symbol `m16Start' undefined
>> 
>> 
>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>> 
>> Hi sirs,
>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>> For ia32 compilation disasm shows not good codes
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 <_BackFromUserCode>:
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
>> 
>> 
>> 000c <_BackFromUserCode.Base>:
>>  c: 66 9c pushfw
>>  e: fa   cli
>> 
>> -
>> to compare gcc-4.9.1 cvompilation
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 :
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 66 e8 00 00   callw  c 
>> ...
>> 
>> 000e :
>>  e: 66 9c pushfw
>> 10: fa   cli
>> 
>> --
>> May be change a32 prefix to o32 in the line:
>> "a32 call.Base   ; push eip"
>> ?
>> 
>> 
>> In the X64 file, I used:
>> calldword .Base
>> 
>> I notice this produced the same code as:
>> o32 calldword .Base
>> 
>> But,
>> o32 call.Base
>> seems to produce invalid code. (OVMF hangs.)
>> 
>> It does seem like:
>> a32 call.Base
>> is functional as well, but I know we are attempting to make the new
>> nasm code produce similar code to the old asm code where reasonable.
>> 
>> I think I only changed it in the X64 file to try to match the old 'db' code.
>> 
>> -Jordan
>> 
>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>> 
>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>  wrote:
>> 
>> This series:
>> 
>> * Adds support for creating object files from .nasm source files to
>> 
>> allow NASM source files to be linked into libraries and images
>> 
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> 
>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>> 
>> GNU Assembler (.S) files
>> 
>> - This will make NASM a build requirement for MdePkg with IA32 &
>> 
>>   X64 on all toolchains except MSVC and ICC.
>> 
>> 
>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>> 
>> have not been tested very well yet.)
>> 
>> 
>> This series is available in this git branch:
>> 
>> https://github.com/jljusten/edk2.git nasm-v1
>> 
>> 
>> I update my nasm branch based on the feedback.
>> 
>> The differences vs. v1 are in the attached patch.
>> 
>> Is anyone interested in seeing a v2 posted to the list?
>> 
>> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
>> any testing to add to that?
>> 
>> -Jordan
>> 
>> Jorda

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Andrew Fish]

On Aug 27, 2014, at 8:08 PM, Gao, Liming  wrote:

> Hi,
>   What change do you make? In previous mail, you mention x86_64 there is no 
> issue.
>  

Liming,

On the various GNU (including clang) toolchains __USER_LABEL_PREFIX__ is the 
prefix applied to user labels (symbols visible to C) in assembly. Some versions 
set it to '', and some version have it set to ‘_'

#define ASM_PFX(name) _CONCATENATE (__USER_LABEL_PREFIX__, name)

So you can have a bug that passes on one version and fails on another. 

Thanks,

Andrew Fish

> Thanks
> Liming
> From: Sergey Isakov [mailto:isakov...@bk.ru] 
> Sent: Thursday, August 28, 2014 4:42 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for 
> non-MSVC
>  
> The error disappeared but I still have other mistakes
> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj) from 
> '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
> Still in work
>  
> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
> 
> 
> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
> 
> And one new question. Why _16GdtrBase with underscore while m16Start without
> it?
> 
> Does replacing m16Start with ASM_PFX(m16Start) help?
> 
> It looks like I didn't convert this up properly. The MASM code didn't
> use ASM_PFX...
> 
> -Jordan
> 
> 
> ——
> ;
> ; These are global constant to convey information to C code.
> ;
> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
> m16Start
> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
> 
> —
> I got an error with this
> Thunk16.iii:60: error: symbol `m16Start' undefined
> 
> 
> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
> 
> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
> 
> Hi sirs,
> I tested Thunk16.nasm too. For x86_64 there is no issue.
> For ia32 compilation disasm shows not good codes
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
> 
> 0006 <_BackFromUserCode>:
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
> 
> 
> 000c <_BackFromUserCode.Base>:
>  c: 66 9c pushfw
>  e: fa   cli
> 
> -
> to compare gcc-4.9.1 cvompilation
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
> 
> 0006 :
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 66 e8 00 00   callw  c 
> ...
> 
> 000e :
>  e: 66 9c pushfw
> 10: fa   cli
> 
> --
> May be change a32 prefix to o32 in the line:
> "a32 call.Base   ; push eip"
> ?
> 
> 
> In the X64 file, I used:
> calldword .Base
> 
> I notice this produced the same code as:
> o32 calldword .Base
> 
> But,
> o32 call.Base
> seems to produce invalid code. (OVMF hangs.)
> 
> It does seem like:
> a32 call.Base
> is functional as well, but I know we are attempting to make the new
> nasm code produce similar code to the old asm code where reasonable.
> 
> I think I only changed it in the X64 file to try to match the old 'db' code.
> 
> -Jordan
> 
> On 27.08.2014, at 9:50, Jordan Justen wrote:
> 
> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
> 
> This series:
> 
> * Adds support for creating object files from .nasm source files to
> 
> allow NASM source files to be linked into libraries and images
> 
> * Adds NASM source files for Thunk16 on IA32 and X64
> 
> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
> 
> GNU Assembler (.S) files
> 
> - This will make NASM a build requirement for MdePkg with IA32 &
> 
>   X64 on all toolchains except MSVC and ICC.
> 
> 
> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
> 
> have not been tested very well yet.)
> 
> 
> This series is available in this git branch:
> 
> https://github.com/jljusten/edk2.git nasm-v1
> 
> 
> I update my nasm branch based on the feedback.
> 
> The differences vs. v1 are in the attached patch.
> 
> Is anyone interested in seeing a v2 posted to the list?
> 
> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
> any testing to add to that?
> 
> -Jordan
> 
> Jordan Justen (8):
> 
> BaseTools/tools_def: Add NASM_FLAGS
> 
> BaseTools/build_rule: Add .nasm => .obj build rule
> 
> MdePkg/Base.h: Always define ASM_PFX
> 
> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
> 
> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
> 
> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
> 
> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
> 
> MdePkg/BaseLib NASM Th

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Jordan Justen]

On Wed, Aug 27, 2014 at 8:08 PM, Gao, Liming  wrote:
> Hi,
>
>   What change do you make? In previous mail, you mention x86_64 there is no
> issue.

Sergey, also, which toolchain are you looking at?

-Jordan

> From: Sergey Isakov [mailto:isakov...@bk.ru]
> Sent: Thursday, August 28, 2014 4:42 AM
> To: edk2-devel@lists.sourceforge.net
>
>
> Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for
> non-MSVC
>
>
>
> The error disappeared but I still have other mistakes
>
> ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj)
> from '_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
>
> Still in work
>
>
>
> On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:
>
>
>
> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>
> And one new question. Why _16GdtrBase with underscore while m16Start without
> it?
>
>
> Does replacing m16Start with ASM_PFX(m16Start) help?
>
> It looks like I didn't convert this up properly. The MASM code didn't
> use ASM_PFX...
>
> -Jordan
>
>
> ——
> ;
> ; These are global constant to convey information to C code.
> ;
> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
> m16Start
> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>
> —
> I got an error with this
> Thunk16.iii:60: error: symbol `m16Start' undefined
>
>
> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>
> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>
> Hi sirs,
> I tested Thunk16.nasm too. For x86_64 there is no issue.
> For ia32 compilation disasm shows not good codes
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
>
> 0006 <_BackFromUserCode>:
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
> 
>
> 000c <_BackFromUserCode.Base>:
>  c: 66 9c pushfw
>  e: fa   cli
>
> -
> to compare gcc-4.9.1 cvompilation
> -
>  :
>  0: 00 00 add%al,(%eax)
>  2: 00 00 add%al,(%eax)
> ...
>
> 0006 :
>  6: 16   push   %ss
>  7: 0e   push   %cs
>  8: 66 e8 00 00   callw  c 
> ...
>
> 000e :
>  e: 66 9c pushfw
> 10: fa   cli
>
> --
> May be change a32 prefix to o32 in the line:
> "a32 call.Base   ; push eip"
> ?
>
>
> In the X64 file, I used:
> calldword .Base
>
> I notice this produced the same code as:
> o32 calldword .Base
>
> But,
> o32 call.Base
> seems to produce invalid code. (OVMF hangs.)
>
> It does seem like:
> a32 call.Base
> is functional as well, but I know we are attempting to make the new
> nasm code produce similar code to the old asm code where reasonable.
>
> I think I only changed it in the X64 file to try to match the old 'db' code.
>
> -Jordan
>
> On 27.08.2014, at 9:50, Jordan Justen wrote:
>
> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
>
> This series:
>
> * Adds support for creating object files from .nasm source files to
>
> allow NASM source files to be linked into libraries and images
>
> * Adds NASM source files for Thunk16 on IA32 and X64
>
> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>
> GNU Assembler (.S) files
>
> - This will make NASM a build requirement for MdePkg with IA32 &
>
>   X64 on all toolchains except MSVC and ICC.
>
>
> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>
> have not been tested very well yet.)
>
>
> This series is available in this git branch:
>
> https://github.com/jljusten/edk2.git nasm-v1
>
>
> I update my nasm branch based on the feedback.
>
> The differences vs. v1 are in the attached patch.
>
> Is anyone interested in seeing a v2 posted to the list?
>
> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
> any testing to add to that?
>
> -Jordan
>
> Jordan Justen (8):
>
> BaseTools/tools_def: Add NASM_FLAGS
>
> BaseTools/build_rule: Add .nasm => .obj build rule
>
> MdePkg/Base.h: Always define ASM_PFX
>
> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>
> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>
> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>
> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>
> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>
>
> BaseTools/Conf/build_rule.template   |  15 ++
>
> BaseTools/Conf/tools_def.template| 287 ++-
>
> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Base.h|  25 ++-
>
> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Gao, Liming]

Hi,
  What change do you make? In previous mail, you mention x86_64 there is no 
issue.

Thanks
Liming
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Thursday, August 28, 2014 4:42 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for 
non-MSVC

The error disappeared but I still have other mistakes
ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj) from 
'_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
Still in work

On 28 авг. 2014 г., at 0:33, Jordan Justen 
mailto:jljus...@gmail.com>> wrote:


On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov 
mailto:isakov...@bk.ru>> wrote:

And one new question. Why _16GdtrBase with underscore while m16Start without
it?

Does replacing m16Start with ASM_PFX(m16Start) help?

It looks like I didn't convert this up properly. The MASM code didn't
use ASM_PFX...

-Jordan


——
;
; These are global constant to convey information to C code.
;
ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
m16Start
ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
ASM_PFX(mTransition) DW  _EntryPoint - m16Start

—
I got an error with this
Thunk16.iii:60: error: symbol `m16Start' undefined


On 27 авг. 2014 г., at 22:04, Jordan Justen 
mailto:jljus...@gmail.com>> wrote:

On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov 
mailto:isakov...@bk.ru>> wrote:

Hi sirs,
I tested Thunk16.nasm too. For x86_64 there is no issue.
For ia32 compilation disasm shows not good codes
-
 :
 0: 00 00 add%al,(%eax)
 2: 00 00 add%al,(%eax)
...

0006 <_BackFromUserCode>:
 6: 16   push   %ss
 7: 0e   push   %cs
 8: 67 e8 00 00 66 9c addr16 call 9c66000e


000c <_BackFromUserCode.Base>:
 c: 66 9c pushfw
 e: fa   cli

-
to compare gcc-4.9.1 cvompilation
-
 :
 0: 00 00 add%al,(%eax)
 2: 00 00 add%al,(%eax)
...

0006 :
 6: 16   push   %ss
 7: 0e   push   %cs
 8: 66 e8 00 00   callw  c 
...

000e :
 e: 66 9c pushfw
10: fa   cli

--
May be change a32 prefix to o32 in the line:
"a32 call.Base   ; push eip"
?


In the X64 file, I used:
calldword .Base

I notice this produced the same code as:
o32 calldword .Base

But,
o32 call.Base
seems to produce invalid code. (OVMF hangs.)

It does seem like:
a32 call.Base
is functional as well, but I know we are attempting to make the new
nasm code produce similar code to the old asm code where reasonable.

I think I only changed it in the X64 file to try to match the old 'db' code.

-Jordan

On 27.08.2014, at 9:50, Jordan Justen wrote:

On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
mailto:jordan.l.jus...@intel.com>> wrote:

This series:

* Adds support for creating object files from .nasm source files to

allow NASM source files to be linked into libraries and images

* Adds NASM source files for Thunk16 on IA32 and X64

* Convert BaseLib to use NASM Source Files for Thunk16 rather than

GNU Assembler (.S) files

- This will make NASM a build requirement for MdePkg with IA32 &

  X64 on all toolchains except MSVC and ICC.


Thanks for Liming Gao for the tools_def changes for MSVC. (But, these

have not been tested very well yet.)


This series is available in this git branch:

https://github.com/jljusten/edk2.git nasm-v1


I update my nasm branch based on the feedback.

The differences vs. v1 are in the attached patch.

Is anyone interested in seeing a v2 posted to the list?

Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
any testing to add to that?

-Jordan

Jordan Justen (8):

BaseTools/tools_def: Add NASM_FLAGS

BaseTools/build_rule: Add .nasm => .obj build rule

MdePkg/Base.h: Always define ASM_PFX

MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version

MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version

MdePkg/BaseLib NASM Thunk16: Use NASM local labels

MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code

MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code


BaseTools/Conf/build_rule.template   |  15 ++

BaseTools/Conf/tools_def.template| 287 ++-

MdePkg/Include/AArch64/ProcessorBind.h   |   4 +

MdePkg/Include/Arm/ProcessorBind.h   |   4 +

MdePkg/Include/Base.h|  25 ++-

MdePkg/Include/Ebc/ProcessorBind.h   |   4 +

MdePkg/Include/Ia32/ProcessorBind.h  |   4 +

MdePkg/Include/Ipf/ProcessorBind.h   |   4 +

MdePkg/Include/X64/ProcessorBind.h   |   4 +

MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-

MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 260 +

MdePkg

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Andrew Fish]

On Aug 27, 2014, at 7:42 PM, Jordan Justen  wrote:

> It appeared to build fine with gcc 4.9 and gcc 4.4.
> 

Thanks for testing.

Andrew Fish

> -Jordan
> 
> On Wed, Aug 27, 2014 at 5:53 PM, Andrew Fish  wrote:
>> Jordan,
>> 
>> Could you make this change and make sure the BaseTools still compile with
>> GCC49? I want to figure out if we can share the flags, or if I need to add
>> and if?
>> 
>> cd BaseTools
>> make clean
>> make
>> 
>> Index: Source/C/Makefiles/header.makefile
>> ===
>> --- Source/C/Makefiles/header.makefile (revision 15924)
>> +++ Source/C/Makefiles/header.makefile (working copy)
>> @@ -41,7 +41,7 @@
>> 
>> 
>> 
>> INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I
>> $(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I
>> $(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE)
>> CPPFLAGS = $(INCLUDE)
>> -CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants
>> -nostdlib -Wall -Werror -c -g
>> +CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
>> -Wno-deprecated-declarations -Wno-self-assign -nostdlib -c -g
>> LFLAGS =
>> 
>> 
>> 
>> ifeq ($(ARCH), IA32)
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> On Aug 27, 2014, at 4:39 PM, Jordan Justen  wrote:
>> 
>> 0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
>> commit message:
>> * Line lengths are a bit long
>> 
>> 0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
>> commit message:
>> * Missing Contributed-under/Signed-off-by
>> * Line lengths are a bit long
>> * hte => the
>> * Do you expect the lldb support would work with other toolchains?
>> 
>> 0004-BaseTools-Add-support-for-Xcode5.patch
>> commit message:
>> * Name misspelled in Signed-off-by. (Maybe look at git commit -s parameter?)
>> 
>> GCC49
>> Tested-by: Jordan Justen 
>> 
>> Reviewed-by: Jordan Justen 
>> 
>> On Wed, Aug 27, 2014 at 3:30 PM, Andrew Fish  wrote:
>> 
>> Jordan,
>> 
>> Here is the updated patch set for the emulator. Please review.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> 
>> 
>> On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>> 
>> 
>> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>> 
>> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>> 
>> EmulatorPkg:Host: Port emulator to Xcode5
>> 
>> Xcode5 retired gdb, so this patch adds support for using, and loading
>> symbols in, lldb.
>> 
>> 
>> Cool, but I don't think the subject is right:
>> -EmulatorPkg:Host: Port emulator to Xcode5
>> +EmulatorPkg Unix Host: Add LLDB support
>> 
>> Well Xcode 5 does not support gdb, and only supports lldb.
>> 
>> 
>> Right. I just think the lldb support should be the focus, and Xcode 5
>> could be mentioned in the main commit message body as one motivation.
>> 
>> -Jordan
>> 
>> I don't see XCODE5 in the patch. Seems fine to mention in the commit
>> message that Xcode5 is the motivation for adding the LLDB support.
>> 
>> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
>> on each run? Why is that needed?
>> 
>> 
>> It pushes control to the lldb Python script. Loading symbols dynamically
>> allows the setting of breakpoints prior to loading the module. Loading the
>> symbols will resolve the breakpoint and activate it.
>> The files written by the emulator are not used by lldb. I should probably
>> just move the call to SecGdbScriptBreak() out of the if PCD construct that
>> defines how the files get written.
>> 
>> Since the breakpoint script is just doing a few reads from the stack it is
>> very fast. The emulator runs about the same speed if you load symbols or
>> not.
>> 
>> What's the "+ 1" change in the call to SecGdbScriptBreak?
>> 
>> 
>> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
>> Module.dll.
>> 
>> I think the X stuff could be a separate commit from the LLDB part.
>> 
>> 
>> OK
>> 
>> -Jordan
>> 
>> The lldb script also supports dumping out the build generated guid database
>> and it prints guids out with thier Cname if available. lldbefi.py also
>> contains some EFI specific type formatters.
>> 
>> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
>> X11, since it is now an external package.
>> X11IncludeHack is a symbolic link to /opt/X11/include
>> 
>> To get X11 to work on a Mac you now have to install XQuartz:
>> http://xquartz.macosforge.org
>> 
>> To fully work the -combine needs to be removed from the
>> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a
>> separate commit.
>> 
>> ---
>> EmulatorPkg/Unix/Host/Host.c |   5 +-
>> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
>> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
>> EmulatorPkg/Unix/lldbefi.py  | 540
>> +++
>> EmulatorPkg/Unix/lldbinit|   3 +
>> 5 files changed, 549 insertions(+), 2 deletions(-)
>> create mode 12 Emul

Re: [edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE

[Yao, Jiewen]

Thank, Star.
This patch looks good to me.
Reviewed by: Jiewen Yao 

From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Wednesday, August 27, 2014 8:29 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE

Hi Alexei,

Thanks for your finding, attach the patch for your review.

MdePkg Acpi51.h: Correct the declaration of 
EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Star Zeng mailto:star.z...@intel.com>>

Thanks,
Star
From: Alexei Fedorov [mailto:alexei.fedo...@arm.com]
Sent: Wednesday, August 27, 2014 9:35 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE


EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE declaration in 
\edk2\MdePkg\Include\IndustryStandard\Acpi51.h has wrong field lengths:



///

/// SBSA Generic Watchdog Structure

///

typedef struct {

  UINT8   Type;

  UINT8   Length;

  UINT16  Reserved;

...



This should be



typedef struct {

  UINT8   Type;

  UINT16  Length;

  UINT8   Reserved;

...



According to Table 5-123 SBSA Generic Watchdog Structure Format of ACPI 5.1 
Specification on p.197:



FieldByte Length Byte Offset Description

Type 1   0   0x1 Watchdog GT

Length   2   1   28

Reserved 1   3   Must be zero



Alexei.



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Jordan Justen]

It appeared to build fine with gcc 4.9 and gcc 4.4.

-Jordan

On Wed, Aug 27, 2014 at 5:53 PM, Andrew Fish  wrote:
> Jordan,
>
> Could you make this change and make sure the BaseTools still compile with
> GCC49? I want to figure out if we can share the flags, or if I need to add
> and if?
>
> cd BaseTools
> make clean
> make
>
> Index: Source/C/Makefiles/header.makefile
> ===
> --- Source/C/Makefiles/header.makefile (revision 15924)
> +++ Source/C/Makefiles/header.makefile (working copy)
> @@ -41,7 +41,7 @@
>
>
>
>  INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I
> $(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I
> $(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE)
>  CPPFLAGS = $(INCLUDE)
> -CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants
> -nostdlib -Wall -Werror -c -g
> +CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror
> -Wno-deprecated-declarations -Wno-self-assign -nostdlib -c -g
>  LFLAGS =
>
>
>
>  ifeq ($(ARCH), IA32)
>
> Thanks,
>
> Andrew Fish
>
> On Aug 27, 2014, at 4:39 PM, Jordan Justen  wrote:
>
> 0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
> commit message:
> * Line lengths are a bit long
>
> 0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
> commit message:
> * Missing Contributed-under/Signed-off-by
> * Line lengths are a bit long
> * hte => the
> * Do you expect the lldb support would work with other toolchains?
>
> 0004-BaseTools-Add-support-for-Xcode5.patch
> commit message:
> * Name misspelled in Signed-off-by. (Maybe look at git commit -s parameter?)
>
> GCC49
> Tested-by: Jordan Justen 
>
> Reviewed-by: Jordan Justen 
>
> On Wed, Aug 27, 2014 at 3:30 PM, Andrew Fish  wrote:
>
> Jordan,
>
> Here is the updated patch set for the emulator. Please review.
>
> Thanks,
>
> Andrew Fish
>
>
>
>
>
> On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:
>
> On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>
>
> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>
> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>
> EmulatorPkg:Host: Port emulator to Xcode5
>
> Xcode5 retired gdb, so this patch adds support for using, and loading
> symbols in, lldb.
>
>
> Cool, but I don't think the subject is right:
> -EmulatorPkg:Host: Port emulator to Xcode5
> +EmulatorPkg Unix Host: Add LLDB support
>
> Well Xcode 5 does not support gdb, and only supports lldb.
>
>
> Right. I just think the lldb support should be the focus, and Xcode 5
> could be mentioned in the main commit message body as one motivation.
>
> -Jordan
>
> I don't see XCODE5 in the patch. Seems fine to mention in the commit
> message that Xcode5 is the motivation for adding the LLDB support.
>
> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
> on each run? Why is that needed?
>
>
> It pushes control to the lldb Python script. Loading symbols dynamically
> allows the setting of breakpoints prior to loading the module. Loading the
> symbols will resolve the breakpoint and activate it.
> The files written by the emulator are not used by lldb. I should probably
> just move the call to SecGdbScriptBreak() out of the if PCD construct that
> defines how the files get written.
>
> Since the breakpoint script is just doing a few reads from the stack it is
> very fast. The emulator runs about the same speed if you load symbols or
> not.
>
> What's the "+ 1" change in the call to SecGdbScriptBreak?
>
>
> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
> Module.dll.
>
> I think the X stuff could be a separate commit from the LLDB part.
>
>
> OK
>
> -Jordan
>
> The lldb script also supports dumping out the build generated guid database
> and it prints guids out with thier Cname if available. lldbefi.py also
> contains some EFI specific type formatters.
>
> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
> X11, since it is now an external package.
> X11IncludeHack is a symbolic link to /opt/X11/include
>
> To get X11 to work on a Mac you now have to install XQuartz:
> http://xquartz.macosforge.org
>
> To fully work the -combine needs to be removed from the
> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a
> separate commit.
>
> ---
> EmulatorPkg/Unix/Host/Host.c |   5 +-
> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
> EmulatorPkg/Unix/lldbefi.py  | 540
> +++
> EmulatorPkg/Unix/lldbinit|   3 +
> 5 files changed, 549 insertions(+), 2 deletions(-)
> create mode 12 EmulatorPkg/Unix/Host/X11IncludeHack
> create mode 100755 EmulatorPkg/Unix/lldbefi.py
> create mode 100644 EmulatorPkg/Unix/lldbinit
>
> diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
> index 7eecbce..480bc54 100644
> --- a/EmulatorPkg/Unix/Host/Host.c
> +++ b/EmulatorPkg/Unix/Host

[edk2] [Patch]ShellPkg: Remove 'STATIC' from function declarations to avoid source level debugging problem

[Qiu, Shumin]

Hi Jaben,
Can you help to review this patch? Internal linkage (ie. STATIC) functions have 
caused problems with source level debugging before, so we generally avoid 
STATIC in ShellPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks
Shumin



ShellPkg_STATIC.patch
Description: ShellPkg_STATIC.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ShellPkg: shell can't recognize 'ren' command

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 


From: Bjorge, Erik C
Sent: Monday, August 25, 2014 2:44 PM
To: Shah, Tapan; Carsey, Jaben; edk2-devel@lists.sourceforge.net
Subject: RE: ShellPkg: shell can't recognize 'ren' command
Importance: High

Reviewed-by: Erik Bjorge 

From: Shah, Tapan [mailto:tapands...@hp.com]
Sent: Monday, August 25, 2014 12:54 PM
To: Carsey, Jaben; Bjorge, Erik C; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: shell can't recognize 'ren' command

Jaben / Erik,
   Can you please review this?

This patch fixes 'ren' alias for 'mv' command.


ShellPkg: Fix 'ren' alias for 'mv' command.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 



--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Andrew Fish]

Jordan,

I don’t seem to have commit access after the svn move. Can you commit these 
patches for me? I attempted to fix all the issues in your comments.

Thanks,

Andrew Fish

On Aug 27, 2014, at 4:39 PM, Jordan Justen  wrote:

> 0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
> commit message:
> * Line lengths are a bit long
> 

EmulatorPkg:Unix: Add support for X11 on Mac OS X via XQuartz

Starting in OS X Mountain Lion X11 is not longer part of the OS install, so 
you must download it from http://xquartz.macosforge.org.
To make XQuartz work with the EmulatorPkg an include path needs to be added.
The build tools fail the build if you try to add an absolute inculde path to 
the X11 headers, so Unix/Host/X11IncludeHack, a symbolic link, was added to 
get the system building.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Jordan Justen 


> 0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
> commit message:
> * Missing Contributed-under/Signed-off-by
> * Line lengths are a bit long
> * hte => the
> * Do you expect the lldb support would work with other toolchains?
> 

EmulatorPkg Unix Host: Add LLDB support for Xcode 5

Xcode5 retired gdb, so this patch adds support for using, and loading symbols 
in, lldb. It also supports building with Xcode 5.

The lldb script also supports dumping out the build generated guid database 
and it prints guids out with thier Cname if available. lldbefi.py also 
contains some EFI specific type formatters. Symbols are loaded via the
lldbefi.py script setting a breakpoint on SecGdbScriptBreak() and runing a 
breakpoint action Python function that uses the arguments to 
SecGdbScriptBreak() to load symbols.

lldb may work on some versions of Xcode 4.*, but it has not been tested.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Jordan Justen 
GCC49
Tested-by: Jordan Justen 


> 0004-BaseTools-Add-support-for-Xcode5.patch
> commit message:
> * Name misspelled in Signed-off-by. (Maybe look at git commit -s parameter?)
> 

BaseTools: add support Xcode 5 in the EmulatorPkg

The XCODE32 target is used to build the x86_64 Mac OS X application for the 
emulator. The other Xcode targets build the EFIAPI needed for UEFI. This patch
removes an obsolete command line argument.

Signed-off-by: Andrew Fish 
Reviewed-by: Jordan Justen 


Yikes wrong patch:




0003-BaseTools-add-support-Xcode-5-in-the-EmulatorPkg-app.patch
Description: Binary data




> GCC49
> Tested-by: Jordan Justen 
> 
> Reviewed-by: Jordan Justen 
> 
> On Wed, Aug 27, 2014 at 3:30 PM, Andrew Fish  wrote:
>> Jordan,
>> 
>> Here is the updated patch set for the emulator. Please review.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> 
>> 
>> On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>> 
>> 
>> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>> 
>> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>> 
>> EmulatorPkg:Host: Port emulator to Xcode5
>> 
>> Xcode5 retired gdb, so this patch adds support for using, and loading
>> symbols in, lldb.
>> 
>> 
>> Cool, but I don't think the subject is right:
>> -EmulatorPkg:Host: Port emulator to Xcode5
>> +EmulatorPkg Unix Host: Add LLDB support
>> 
>> Well Xcode 5 does not support gdb, and only supports lldb.
>> 
>> 
>> Right. I just think the lldb support should be the focus, and Xcode 5
>> could be mentioned in the main commit message body as one motivation.
>> 
>> -Jordan
>> 
>> I don't see XCODE5 in the patch. Seems fine to mention in the commit
>> message that Xcode5 is the motivation for adding the LLDB support.
>> 
>> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
>> on each run? Why is that needed?
>> 
>> 
>> It pushes control to the lldb Python script. Loading symbols dynamically
>> allows the setting of breakpoints prior to loading the module. Loading the
>> symbols will resolve the breakpoint and activate it.
>> The files written by the emulator are not used by lldb. I should probably
>> just move the call to SecGdbScriptBreak() out of the if PCD construct that
>> defines how the files get written.
>> 
>> Since the breakpoint script is just doing a few reads from the stack it is
>> very fast. The emulator runs about the same speed if you load symbols or
>> not.
>> 
>> What's the "+ 1" change in the call to SecGdbScriptBreak?
>> 
>> 
>> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
>> Module.dll.
>> 
>> I think the X stuff could be a separate commit from the LLDB part.
>> 
>> 
>> OK
>> 
>> -Jordan
>> 
>> The lldb script also supports dumping out the build generated guid database
>> and it prints guids out with thier Cname if available. lldbefi.py also
>> contains some EFI specific type formatters.
>> 
>> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
>> X11, since it is now an external pack

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Andrew Fish]

Jordan,

Could you make this change and make sure the BaseTools still compile with 
GCC49? I want to figure out if we can share the flags, or if I need to add and 
if?

cd BaseTools
make clean
make

Index: Source/C/Makefiles/header.makefile
===
--- Source/C/Makefiles/header.makefile  (revision 15924)
+++ Source/C/Makefiles/header.makefile  (working copy)
@@ -41,7 +41,7 @@
 
 INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I 
$(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I 
$(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE) 
 CPPFLAGS = $(INCLUDE)
-CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -nostdlib 
-Wall -Werror -c -g
+CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror 
-Wno-deprecated-declarations -Wno-self-assign -nostdlib -c -g
 LFLAGS =
 
 ifeq ($(ARCH), IA32)

Thanks,

Andrew Fish

On Aug 27, 2014, at 4:39 PM, Jordan Justen  wrote:

> 0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
> commit message:
> * Line lengths are a bit long
> 
> 0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
> commit message:
> * Missing Contributed-under/Signed-off-by
> * Line lengths are a bit long
> * hte => the
> * Do you expect the lldb support would work with other toolchains?
> 
> 0004-BaseTools-Add-support-for-Xcode5.patch
> commit message:
> * Name misspelled in Signed-off-by. (Maybe look at git commit -s parameter?)
> 
> GCC49
> Tested-by: Jordan Justen 
> 
> Reviewed-by: Jordan Justen 
> 
> On Wed, Aug 27, 2014 at 3:30 PM, Andrew Fish  wrote:
>> Jordan,
>> 
>> Here is the updated patch set for the emulator. Please review.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> 
>> 
>> On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>> 
>> 
>> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>> 
>> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>> 
>> EmulatorPkg:Host: Port emulator to Xcode5
>> 
>> Xcode5 retired gdb, so this patch adds support for using, and loading
>> symbols in, lldb.
>> 
>> 
>> Cool, but I don't think the subject is right:
>> -EmulatorPkg:Host: Port emulator to Xcode5
>> +EmulatorPkg Unix Host: Add LLDB support
>> 
>> Well Xcode 5 does not support gdb, and only supports lldb.
>> 
>> 
>> Right. I just think the lldb support should be the focus, and Xcode 5
>> could be mentioned in the main commit message body as one motivation.
>> 
>> -Jordan
>> 
>> I don't see XCODE5 in the patch. Seems fine to mention in the commit
>> message that Xcode5 is the motivation for adding the LLDB support.
>> 
>> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
>> on each run? Why is that needed?
>> 
>> 
>> It pushes control to the lldb Python script. Loading symbols dynamically
>> allows the setting of breakpoints prior to loading the module. Loading the
>> symbols will resolve the breakpoint and activate it.
>> The files written by the emulator are not used by lldb. I should probably
>> just move the call to SecGdbScriptBreak() out of the if PCD construct that
>> defines how the files get written.
>> 
>> Since the breakpoint script is just doing a few reads from the stack it is
>> very fast. The emulator runs about the same speed if you load symbols or
>> not.
>> 
>> What's the "+ 1" change in the call to SecGdbScriptBreak?
>> 
>> 
>> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
>> Module.dll.
>> 
>> I think the X stuff could be a separate commit from the LLDB part.
>> 
>> 
>> OK
>> 
>> -Jordan
>> 
>> The lldb script also supports dumping out the build generated guid database
>> and it prints guids out with thier Cname if available. lldbefi.py also
>> contains some EFI specific type formatters.
>> 
>> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
>> X11, since it is now an external package.
>> X11IncludeHack is a symbolic link to /opt/X11/include
>> 
>> To get X11 to work on a Mac you now have to install XQuartz:
>> http://xquartz.macosforge.org
>> 
>> To fully work the -combine needs to be removed from the
>> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a
>> separate commit.
>> 
>> ---
>> EmulatorPkg/Unix/Host/Host.c |   5 +-
>> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
>> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
>> EmulatorPkg/Unix/lldbefi.py  | 540
>> +++
>> EmulatorPkg/Unix/lldbinit|   3 +
>> 5 files changed, 549 insertions(+), 2 deletions(-)
>> create mode 12 EmulatorPkg/Unix/Host/X11IncludeHack
>> create mode 100755 EmulatorPkg/Unix/lldbefi.py
>> create mode 100644 EmulatorPkg/Unix/lldbinit
>> 
>> diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
>> index 7eecbce..480bc54 100644
>> --- a/EmulatorPkg/Unix/Host/Host.c
>> +++ b/EmulatorPkg/Unix/Host/Host.c
>> @@ -1161,6 +1161,9

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Jordan Justen]

0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
commit message:
* Line lengths are a bit long

0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
commit message:
* Missing Contributed-under/Signed-off-by
* Line lengths are a bit long
* hte => the
* Do you expect the lldb support would work with other toolchains?

0004-BaseTools-Add-support-for-Xcode5.patch
commit message:
* Name misspelled in Signed-off-by. (Maybe look at git commit -s parameter?)

GCC49
Tested-by: Jordan Justen 

Reviewed-by: Jordan Justen 

On Wed, Aug 27, 2014 at 3:30 PM, Andrew Fish  wrote:
> Jordan,
>
> Here is the updated patch set for the emulator. Please review.
>
> Thanks,
>
> Andrew Fish
>
>
>
>
>
> On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:
>
> On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>
>
> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>
> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>
> EmulatorPkg:Host: Port emulator to Xcode5
>
> Xcode5 retired gdb, so this patch adds support for using, and loading
> symbols in, lldb.
>
>
> Cool, but I don't think the subject is right:
> -EmulatorPkg:Host: Port emulator to Xcode5
> +EmulatorPkg Unix Host: Add LLDB support
>
> Well Xcode 5 does not support gdb, and only supports lldb.
>
>
> Right. I just think the lldb support should be the focus, and Xcode 5
> could be mentioned in the main commit message body as one motivation.
>
> -Jordan
>
> I don't see XCODE5 in the patch. Seems fine to mention in the commit
> message that Xcode5 is the motivation for adding the LLDB support.
>
> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
> on each run? Why is that needed?
>
>
> It pushes control to the lldb Python script. Loading symbols dynamically
> allows the setting of breakpoints prior to loading the module. Loading the
> symbols will resolve the breakpoint and activate it.
> The files written by the emulator are not used by lldb. I should probably
> just move the call to SecGdbScriptBreak() out of the if PCD construct that
> defines how the files get written.
>
> Since the breakpoint script is just doing a few reads from the stack it is
> very fast. The emulator runs about the same speed if you load symbols or
> not.
>
> What's the "+ 1" change in the call to SecGdbScriptBreak?
>
>
> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
> Module.dll.
>
> I think the X stuff could be a separate commit from the LLDB part.
>
>
> OK
>
> -Jordan
>
> The lldb script also supports dumping out the build generated guid database
> and it prints guids out with thier Cname if available. lldbefi.py also
> contains some EFI specific type formatters.
>
> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
> X11, since it is now an external package.
> X11IncludeHack is a symbolic link to /opt/X11/include
>
> To get X11 to work on a Mac you now have to install XQuartz:
> http://xquartz.macosforge.org
>
> To fully work the -combine needs to be removed from the
> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a
> separate commit.
>
> ---
> EmulatorPkg/Unix/Host/Host.c |   5 +-
> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
> EmulatorPkg/Unix/lldbefi.py  | 540
> +++
> EmulatorPkg/Unix/lldbinit|   3 +
> 5 files changed, 549 insertions(+), 2 deletions(-)
> create mode 12 EmulatorPkg/Unix/Host/X11IncludeHack
> create mode 100755 EmulatorPkg/Unix/lldbefi.py
> create mode 100644 EmulatorPkg/Unix/lldbinit
>
> diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
> index 7eecbce..480bc54 100644
> --- a/EmulatorPkg/Unix/Host/Host.c
> +++ b/EmulatorPkg/Unix/Host/Host.c
> @@ -1161,6 +1161,9 @@ GdbScriptAddImage (
>  SymbolsAddr
>  );
>fclose (GdbTempFile);
> +
> +// for lldb call the stub function too
> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer) + 1, (long unsigned
> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>  } else {
>ASSERT (FALSE);
>  }
> @@ -1179,7 +1182,7 @@ GdbScriptAddImage (
>// Target for gdb breakpoint in a script that uses
> gGdbWorkingFileName to set a breakpoint.
>// Hey what can you say scripting in gdb is not that great
>//
> -SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer), (long unsigned int)(ImageContext->ImageAddress +
> ImageContext->SizeOfHeaders), 1);
> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer) + 1, (long unsigned
> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>  } else {
>ASSERT (FALSE);
>  }
> diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.inf
> index dee2e0d..f8a4e99 100644
> --- a/EmulatorPkg/Unix/Host/Host.inf
> 

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Laszlo Ersek]

On 08/27/14 17:12, Ard Biesheuvel wrote:

>  create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c

sorry, forgot to say: please rename the Driver pathname component (the
directory name) to VirtFdtDxe.

Thanks
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Laszlo Ersek]

Some comments below

On 08/27/14 17:12, Ard Biesheuvel wrote:
> This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
> The following assumptions are made about the target:
> - ARM architected timer
> - PL011 UART at 0x900
> - at least 1 MB of DRAM at 0x4000, containing the device tree blob
>
> The following information is retrieved from the device tree:
> - GIC base addresses
> - virtual timer interrupt
> - RTC base address
> - system memory base and size
> - virtio MMIO transports
>
> The DTB image is relocated and installed as a configuration table so an
> EFI stub enabled kernel can be booted directly without the need for a
> bootloader.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Casadevall 
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../AArch64Virtualization-KVM.dsc  | 222 ++
>  .../AArch64Virtualization-KVM.fdf  | 307 +++
>  .../AArch64Virtualization.dsc.inc  | 336 
> +
>  .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  61 
>  .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 249 +++
>  .../Include/Platform/KVM/ArmPlatform.h |  27 ++
>  .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  57 
>  .../Library/AArch64VirtualizationLibKVM/KVM.c  | 143 +
>  .../AArch64VirtualizationLibKVM/KVMHelper.S|  86 ++
>  .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 102 +++
>  .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
>  .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 +++
>  .../Library/PlatformPei/PlatformPeiLib.c   |  47 +++
>  .../Library/PlatformPei/PlatformPeiLib.inf |  58 
>  .../Library/ResetSystemLib/ResetSystemLib.c|  97 ++
>  .../Library/ResetSystemLib/ResetSystemLib.inf  |  36 +++
>  .../Library/ResetSystemLib/ResetSystemPsci.S   |  40 +++
>  17 files changed, 1998 insertions(+)

First of all, this ginormous patch should be split up in several smaller
ones. I apologize for requesting this only now, at v3.

edk2 is very modular, and this patch dumps 5 (FIVE) modules at once at
the poor reviewer. It is impenetrable, and the granularity of any
Acked-by or Reviewed-by is very bad -- you can't carry an A-b or an R-b
forward that has been given only for one module among the five.

So let's see:

>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc

Please include these in a zeroth patch. It's not a requirement that
AArch64VirtualizationPkg be buildable at each stage, during bisection --
for example, it's not buildable before you introduce it *at all*. If it
isn't too hard, please shave these off to a separate patch.

>  create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c

This should be module #1.

>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h

Yikes. After a while I managed to understand the dependency that this
header file resolves. Please make it a separate patch. Can be an early
one.

>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVM.c
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMHelper.S
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMMem.c

Module #2.

>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.inf

Module #3.

>  create mode 100755 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPeiLib.c
>  create mode 100755 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPeiLib.inf

Module #4.

>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.inf
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemPsci.S

Module #5.

If I'm counting right, that's 7 new patches, in place of this huge one.
Five module patches, one patch for the header file, and one patch for
the DSC / FDF / etc meta files.

The module patches should be ordered logically, if

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Andrew Fish]

Jordan,Here is the updated patch set for the emulator. Please review.Thanks,Andrew Fish


0001-EmulatorPkg-Unix-Add-support-for-X11-on-Mac-OS-X-via.patch
Description: Binary data



0002-EmulatorPkg-Unix-Host-Add-LLDB-support-for-Xcode-5.patch
Description: Binary data



0004-BaseTools-Add-support-for-Xcode5.patch
Description: Binary data
On Aug 27, 2014, at 10:22 AM, Jordan Justen  wrote:On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:EmulatorPkg:Host: Port emulator to Xcode5Xcode5 retired gdb, so this patch adds support for using, and loadingsymbols in, lldb.Cool, but I don't think the subject is right:-EmulatorPkg:Host: Port emulator to Xcode5+EmulatorPkg Unix Host: Add LLDB supportWell Xcode 5 does not support gdb, and only supports lldb.Right. I just think the lldb support should be the focus, and Xcode 5could be mentioned in the main commit message body as one motivation.-JordanI don't see XCODE5 in the patch. Seems fine to mention in the commitmessage that Xcode5 is the motivation for adding the LLDB support.Is the new SecGdbScriptBreak call going to cause EmulatorPkg to breakon each run? Why is that needed?It pushes control to the lldb Python script. Loading symbols dynamicallyallows the setting of breakpoints prior to loading the module. Loading thesymbols will resolve the breakpoint and activate it.The files written by the emulator are not used by lldb. I should probablyjust move the call to SecGdbScriptBreak() out of the if PCD construct thatdefines how the files get written.Since the breakpoint script is just doing a few reads from the stack it isvery fast. The emulator runs about the same speed if you load symbols ornot.What's the "+ 1" change in the call to SecGdbScriptBreak?StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and notModule.dll.I think the X stuff could be a separate commit from the LLDB part.OK-JordanThe lldb script also supports dumping out the build generated guid databaseand it prints guids out with thier Cname if available. lldbefi.py alsocontains some EFI specific type formatters.Unix/Host/X11IncludeHack is a symbolic link that is need to add the path forX11, since it is now an external package.X11IncludeHack is a symbolic link to /opt/X11/includeTo get X11 to work on a Mac you now have to install XQuartz:http://xquartz.macosforge.orgTo fully work the -combine needs to be removed from the*_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be aseparate commit.---EmulatorPkg/Unix/Host/Host.c |   5 +-EmulatorPkg/Unix/Host/Host.inf   |   2 +-EmulatorPkg/Unix/Host/X11IncludeHack |   1 +EmulatorPkg/Unix/lldbefi.py  | 540+++EmulatorPkg/Unix/lldbinit    |   3 +5 files changed, 549 insertions(+), 2 deletions(-)create mode 12 EmulatorPkg/Unix/Host/X11IncludeHackcreate mode 100755 EmulatorPkg/Unix/lldbefi.pycreate mode 100644 EmulatorPkg/Unix/lldbinitdiff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.cindex 7eecbce..480bc54 100644--- a/EmulatorPkg/Unix/Host/Host.c+++ b/EmulatorPkg/Unix/Host/Host.c@@ -1161,6 +1161,9 @@ GdbScriptAddImage ( SymbolsAddr );   fclose (GdbTempFile);++    // for lldb call the stub function too+    SecGdbScriptBreak (ImageContext->PdbPointer, strlen(ImageContext->PdbPointer) + 1, (long unsignedint)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1); } else {   ASSERT (FALSE); }@@ -1179,7 +1182,7 @@ GdbScriptAddImage (   // Target for gdb breakpoint in a script that usesgGdbWorkingFileName to set a breakpoint.   // Hey what can you say scripting in gdb is not that great   //-    SecGdbScriptBreak (ImageContext->PdbPointer, strlen(ImageContext->PdbPointer), (long unsigned int)(ImageContext->ImageAddress +ImageContext->SizeOfHeaders), 1);+    SecGdbScriptBreak (ImageContext->PdbPointer, strlen(ImageContext->PdbPointer) + 1, (long unsignedint)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1); } else {   ASSERT (FALSE); }diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.infindex dee2e0d..f8a4e99 100644--- a/EmulatorPkg/Unix/Host/Host.inf+++ b/EmulatorPkg/Unix/Host/Host.inf@@ -145,4 +145,4 @@  XCODE:*_*_X64_DLINK_PATH == gcc  XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/Host -L/usr/X11R6/lib -lXext-lX11 -framework Carbon  XCODE:*_*_X64_ASM_FLAGS == -g-+   XCODE:*_*_X64_CC_FLAGS = -include $(DEST_DIR_DEBUG)/AutoGen.h-I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHackdiff --git a/EmulatorPkg/Unix/Host/X11IncludeHackb/EmulatorPkg/Unix/Host/X11IncludeHacknew file mode 12index 000..f7ab103--- /dev/null+++ b/EmulatorPkg/Unix/Host/X11IncludeHack@@ -0,0 +1 @@+/opt/X11/include\ No newline at end of filediff --git a/EmulatorPkg/Unix/lldbefi.py b/Emula

[edk2] [PATCH] ShellPkg: SmbiosView updates

[El-Haj-Mahmoud, Samer]

Jaben,

Can you please review this and submit it?


Update SmbiosView Shell command to display additional CPU Family

and Socket designations, and fix a couple of typos


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



SmbiosView.patch
Description: SmbiosView.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg , NetworkPkg: Speed up network stack : check for IPsec only once

[El-Haj-Mahmoud, Samer]

Dear MdeModulePkg and NetworkPkg maintainers,

Please find the attached patch that speeds up network stack by removing 
unnecessary IPSEC protocol locate in the
main IPv4 and IPv6 packet processing paths.



Do not try to locate gEfiIpSec2ProtocolGuid on every IPv4 datagram TX/RX.

The locate protocol function can be expensive (10 us on some implementations).

This change speeds up the network stack performance by as much as 20% for

large file downloads.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]



IpSecCheckOnce.patch
Description: IpSecCheckOnce.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Sergey Isakov]

The error disappeared but I still have other mistakes
ld: illegal text-relocation to '_NullSeg' in  … BaseLib.lib(Thunk16.obj) from 
'_16GdtrBase’ in … BaseLib.lib(Thunk16.obj) for architecture x86_64
Still in work

On 28 авг. 2014 г., at 0:33, Jordan Justen  wrote:

> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>> And one new question. Why _16GdtrBase with underscore while m16Start without
>> it?
> 
> Does replacing m16Start with ASM_PFX(m16Start) help?
> 
> It looks like I didn't convert this up properly. The MASM code didn't
> use ASM_PFX...
> 
> -Jordan
> 
>> ——
>> ;
>> ; These are global constant to convey information to C code.
>> ;
>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>> m16Start
>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>> 
>> —
>> I got an error with this
>> Thunk16.iii:60: error: symbol `m16Start' undefined
>> 
>> 
>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>> 
>> Hi sirs,
>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>> For ia32 compilation disasm shows not good codes
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 <_BackFromUserCode>:
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
>> 
>> 
>> 000c <_BackFromUserCode.Base>:
>>  c: 66 9c pushfw
>>  e: fa   cli
>> 
>> -
>> to compare gcc-4.9.1 cvompilation
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 :
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 66 e8 00 00   callw  c 
>> ...
>> 
>> 000e :
>>  e: 66 9c pushfw
>> 10: fa   cli
>> 
>> --
>> May be change a32 prefix to o32 in the line:
>> "a32 call.Base   ; push eip"
>> ?
>> 
>> 
>> In the X64 file, I used:
>> calldword .Base
>> 
>> I notice this produced the same code as:
>> o32 calldword .Base
>> 
>> But,
>> o32 call.Base
>> seems to produce invalid code. (OVMF hangs.)
>> 
>> It does seem like:
>> a32 call.Base
>> is functional as well, but I know we are attempting to make the new
>> nasm code produce similar code to the old asm code where reasonable.
>> 
>> I think I only changed it in the X64 file to try to match the old 'db' code.
>> 
>> -Jordan
>> 
>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>> 
>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>  wrote:
>> 
>> This series:
>> 
>> * Adds support for creating object files from .nasm source files to
>> 
>> allow NASM source files to be linked into libraries and images
>> 
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> 
>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>> 
>> GNU Assembler (.S) files
>> 
>> - This will make NASM a build requirement for MdePkg with IA32 &
>> 
>>   X64 on all toolchains except MSVC and ICC.
>> 
>> 
>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>> 
>> have not been tested very well yet.)
>> 
>> 
>> This series is available in this git branch:
>> 
>> https://github.com/jljusten/edk2.git nasm-v1
>> 
>> 
>> I update my nasm branch based on the feedback.
>> 
>> The differences vs. v1 are in the attached patch.
>> 
>> Is anyone interested in seeing a v2 posted to the list?
>> 
>> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
>> any testing to add to that?
>> 
>> -Jordan
>> 
>> Jordan Justen (8):
>> 
>> BaseTools/tools_def: Add NASM_FLAGS
>> 
>> BaseTools/build_rule: Add .nasm => .obj build rule
>> 
>> MdePkg/Base.h: Always define ASM_PFX
>> 
>> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>> 
>> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>> 
>> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>> 
>> 
>> BaseTools/Conf/build_rule.template   |  15 ++
>> 
>> BaseTools/Conf/tools_def.template| 287 ++-
>> 
>> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Base.h|  25 ++-
>> 
>> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>> 
>> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-
>> 
>> MdePkg/Librar

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Andrew Fish]

On Aug 27, 2014, at 1:33 PM, Jordan Justen  wrote:

> On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
>> And one new question. Why _16GdtrBase with underscore while m16Start without
>> it?
> 
> Does replacing m16Start with ASM_PFX(m16Start) help?
> 
> It looks like I didn't convert this up properly. The MASM code didn't
> use ASM_PFX…
> 

Per my previous mail you will need to follow the ASM_PFX() usage in the *.S 
file. 
ASM_GLOBAL ASM_PFX(m16Start)
ASM_GLOBAL ASM_PFX(m16Size)
ASM_GLOBAL ASM_PFX(mThunk16Attr)
ASM_GLOBAL ASM_PFX(m16Gdt)
ASM_GLOBAL ASM_PFX(m16GdtrBase)
ASM_GLOBAL ASM_PFX(mTransition)
ASM_GLOBAL ASM_PFX(InternalAsmThunk16)
Thanks,

Andrew Fish

> -Jordan
> 
>> ——
>> ;
>> ; These are global constant to convey information to C code.
>> ;
>> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
>> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
>> m16Start
>> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
>> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
>> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>> 
>> —
>> I got an error with this
>> Thunk16.iii:60: error: symbol `m16Start' undefined
>> 
>> 
>> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>> 
>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>> 
>> Hi sirs,
>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>> For ia32 compilation disasm shows not good codes
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 <_BackFromUserCode>:
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 67 e8 00 00 66 9c addr16 call 9c66000e
>> 
>> 
>> 000c <_BackFromUserCode.Base>:
>>  c: 66 9c pushfw
>>  e: fa   cli
>> 
>> -
>> to compare gcc-4.9.1 cvompilation
>> -
>>  :
>>  0: 00 00 add%al,(%eax)
>>  2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 :
>>  6: 16   push   %ss
>>  7: 0e   push   %cs
>>  8: 66 e8 00 00   callw  c 
>> ...
>> 
>> 000e :
>>  e: 66 9c pushfw
>> 10: fa   cli
>> 
>> --
>> May be change a32 prefix to o32 in the line:
>> "a32 call.Base   ; push eip"
>> ?
>> 
>> 
>> In the X64 file, I used:
>> calldword .Base
>> 
>> I notice this produced the same code as:
>> o32 calldword .Base
>> 
>> But,
>> o32 call.Base
>> seems to produce invalid code. (OVMF hangs.)
>> 
>> It does seem like:
>> a32 call.Base
>> is functional as well, but I know we are attempting to make the new
>> nasm code produce similar code to the old asm code where reasonable.
>> 
>> I think I only changed it in the X64 file to try to match the old 'db' code.
>> 
>> -Jordan
>> 
>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>> 
>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>  wrote:
>> 
>> This series:
>> 
>> * Adds support for creating object files from .nasm source files to
>> 
>> allow NASM source files to be linked into libraries and images
>> 
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> 
>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>> 
>> GNU Assembler (.S) files
>> 
>> - This will make NASM a build requirement for MdePkg with IA32 &
>> 
>>   X64 on all toolchains except MSVC and ICC.
>> 
>> 
>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>> 
>> have not been tested very well yet.)
>> 
>> 
>> This series is available in this git branch:
>> 
>> https://github.com/jljusten/edk2.git nasm-v1
>> 
>> 
>> I update my nasm branch based on the feedback.
>> 
>> The differences vs. v1 are in the attached patch.
>> 
>> Is anyone interested in seeing a v2 posted to the list?
>> 
>> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
>> any testing to add to that?
>> 
>> -Jordan
>> 
>> Jordan Justen (8):
>> 
>> BaseTools/tools_def: Add NASM_FLAGS
>> 
>> BaseTools/build_rule: Add .nasm => .obj build rule
>> 
>> MdePkg/Base.h: Always define ASM_PFX
>> 
>> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>> 
>> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>> 
>> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>> 
>> 
>> BaseTools/Conf/build_rule.template   |  15 ++
>> 
>> BaseTools/Conf/tools_def.template| 287 ++-
>> 
>> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Base.h|  25 ++-
>> 
>> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>> 
>> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/X

Re: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

[El-Haj-Mahmoud, Samer]

Any objection to adding this to IntelFrameworkModulePkg?


From: El-Haj-Mahmoud, Samer
Sent: Monday, August 25, 2014 8:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: RE: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

Fair enough. How about an HiiExLib library in IntelFrameworkModulePkg ?







-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Monday, 25 Aug 2014, 8:26PM
To: edk2-devel@lists.sourceforge.net 
[edk2-devel@lists.sourceforge.net]
Subject: Re: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib
Samer:
  Label Opcode is EDKII extension GUIDED opcode, not standard UEFI HII opcode. 
And, HiiLib is generic HII Library for UEFI HII. So, I don't suggest to include 
this API in HiiLib.

Thanks
Liming
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Tuesday, August 26, 2014 12:10 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg: Add HiiCreateGuidLabelOpCode to HiiLib

Dear MdeModulePkg maintainers,

Please find the attached patch that adds a new function 
HiiCreateGuidLabelOpCode() to HiiLib


Add a new function HiiCreateGuidLabelOpCode() to HiiLib to help with creation 
of Label IFR op-codes dynamically


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud el...@hp.com



Samer El-Haj-Mahmoud
System Firmware Architect
HP Servers

el...@hp.com
T +1.281.514.5973
C +1.512.659.1523
Hewlett-Packard Company
hp.com/go/proliant/uefi

[Description: Description: C:\Users\elhajmah\HpLogo.png]

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Jordan Justen]

On Wed, Aug 27, 2014 at 1:08 PM, Sergey Isakov  wrote:
> And one new question. Why _16GdtrBase with underscore while m16Start without
> it?

Does replacing m16Start with ASM_PFX(m16Start) help?

It looks like I didn't convert this up properly. The MASM code didn't
use ASM_PFX...

-Jordan

> ——
> ;
> ; These are global constant to convey information to C code.
> ;
> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 -
> m16Start
> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
>
> —
> I got an error with this
> Thunk16.iii:60: error: symbol `m16Start' undefined
>
>
> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
>
> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>
> Hi sirs,
> I tested Thunk16.nasm too. For x86_64 there is no issue.
> For ia32 compilation disasm shows not good codes
> -
>  :
>   0: 00 00 add%al,(%eax)
>   2: 00 00 add%al,(%eax)
> ...
>
> 0006 <_BackFromUserCode>:
>   6: 16   push   %ss
>   7: 0e   push   %cs
>   8: 67 e8 00 00 66 9c addr16 call 9c66000e
> 
>
> 000c <_BackFromUserCode.Base>:
>   c: 66 9c pushfw
>   e: fa   cli
>
> -
> to compare gcc-4.9.1 cvompilation
> -
>  :
>   0: 00 00 add%al,(%eax)
>   2: 00 00 add%al,(%eax)
> ...
>
> 0006 :
>   6: 16   push   %ss
>   7: 0e   push   %cs
>   8: 66 e8 00 00   callw  c 
> ...
>
> 000e :
>   e: 66 9c pushfw
>  10: fa   cli
>
> --
> May be change a32 prefix to o32 in the line:
> "a32 call.Base   ; push eip"
> ?
>
>
> In the X64 file, I used:
> calldword .Base
>
> I notice this produced the same code as:
> o32 calldword .Base
>
> But,
> o32 call.Base
> seems to produce invalid code. (OVMF hangs.)
>
> It does seem like:
> a32 call.Base
> is functional as well, but I know we are attempting to make the new
> nasm code produce similar code to the old asm code where reasonable.
>
> I think I only changed it in the X64 file to try to match the old 'db' code.
>
> -Jordan
>
> On 27.08.2014, at 9:50, Jordan Justen wrote:
>
> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
>
> This series:
>
> * Adds support for creating object files from .nasm source files to
>
>  allow NASM source files to be linked into libraries and images
>
> * Adds NASM source files for Thunk16 on IA32 and X64
>
> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>
>  GNU Assembler (.S) files
>
>  - This will make NASM a build requirement for MdePkg with IA32 &
>
>X64 on all toolchains except MSVC and ICC.
>
>
> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>
> have not been tested very well yet.)
>
>
> This series is available in this git branch:
>
> https://github.com/jljusten/edk2.git nasm-v1
>
>
> I update my nasm branch based on the feedback.
>
> The differences vs. v1 are in the attached patch.
>
> Is anyone interested in seeing a v2 posted to the list?
>
> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
> any testing to add to that?
>
> -Jordan
>
> Jordan Justen (8):
>
> BaseTools/tools_def: Add NASM_FLAGS
>
> BaseTools/build_rule: Add .nasm => .obj build rule
>
> MdePkg/Base.h: Always define ASM_PFX
>
> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>
> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>
> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>
> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>
> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>
>
> BaseTools/Conf/build_rule.template   |  15 ++
>
> BaseTools/Conf/tools_def.template| 287 ++-
>
> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Base.h|  25 ++-
>
> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>
> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>
> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>
> MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-
>
> MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 260 +
>
> MdePkg/Library/BaseLib/X64/Thunk16.nasm  | 321
> +++
>
> 12 files changed, 914 insertions(+), 22 deletions(-)
>
> create mode 100644 MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
>
> create mode 100644 MdePkg/Library/BaseLib/X64/Thunk16.nasm
>
>
> --
>
> 2.1.0
>
>
>
> --
>
> Slashdot TV.
>
> Video for Nerds.  Stuff that matters.
>

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Andrew Fish]

On Aug 27, 2014, at 1:08 PM, Sergey Isakov  wrote:

> And one new question. Why _16GdtrBase with underscore while m16Start without 
> it?
> ——
> ;
> ; These are global constant to convey information to C code.
> ;
> ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
> ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 - m16Start
> ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
> ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
> ASM_PFX(mTransition) DW  _EntryPoint - m16Start
> 
> —
> I got an error with this
> Thunk16.iii:60: error: symbol `m16Start' undefined
> 

Anything that is exported to C needs to wrapped in ASM_PFX(). Some compilers 
mangle a ‘_’ in front of the C names, and some do not. 

From looking at Thunk16.S I think m16Start is exported to C so it needs to 
referenced as ASM_PFX(m16Start) in the file. 

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BaseLib/X64/Thunk16.S
ASM_GLOBAL ASM_PFX(m16Start)

Thanks,

Andrew Fish

> 
> On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:
> 
>> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>>> Hi sirs,
>>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>>> For ia32 compilation disasm shows not good codes
>>> -
>>>  :
>>>   0: 00 00 add%al,(%eax)
>>>   2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 <_BackFromUserCode>:
>>>   6: 16   push   %ss
>>>   7: 0e   push   %cs
>>>   8: 67 e8 00 00 66 9c addr16 call 9c66000e
>>> 
>>> 
>>> 000c <_BackFromUserCode.Base>:
>>>   c: 66 9c pushfw
>>>   e: fa   cli
>>> 
>>> -
>>> to compare gcc-4.9.1 cvompilation
>>> -
>>>  :
>>>   0: 00 00 add%al,(%eax)
>>>   2: 00 00 add%al,(%eax)
>>> ...
>>> 
>>> 0006 :
>>>   6: 16   push   %ss
>>>   7: 0e   push   %cs
>>>   8: 66 e8 00 00   callw  c 
>>> ...
>>> 
>>> 000e :
>>>   e: 66 9c pushfw
>>>  10: fa   cli
>>> 
>>> --
>>> May be change a32 prefix to o32 in the line:
>>> "a32 call.Base   ; push eip"
>>> ?
>> 
>> In the X64 file, I used:
>> calldword .Base
>> 
>> I notice this produced the same code as:
>> o32 calldword .Base
>> 
>> But,
>> o32 call.Base
>> seems to produce invalid code. (OVMF hangs.)
>> 
>> It does seem like:
>> a32 call.Base
>> is functional as well, but I know we are attempting to make the new
>> nasm code produce similar code to the old asm code where reasonable.
>> 
>> I think I only changed it in the X64 file to try to match the old 'db' code.
>> 
>> -Jordan
>> 
>>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>>> 
>>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>>  wrote:
>>> 
>>> This series:
>>> 
>>> * Adds support for creating object files from .nasm source files to
>>> 
>>>  allow NASM source files to be linked into libraries and images
>>> 
>>> * Adds NASM source files for Thunk16 on IA32 and X64
>>> 
>>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>>> 
>>>  GNU Assembler (.S) files
>>> 
>>>  - This will make NASM a build requirement for MdePkg with IA32 &
>>> 
>>>X64 on all toolchains except MSVC and ICC.
>>> 
>>> 
>>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>>> 
>>> have not been tested very well yet.)
>>> 
>>> 
>>> This series is available in this git branch:
>>> 
>>> https://github.com/jljusten/edk2.git nasm-v1
>>> 
>>> 
>>> I update my nasm branch based on the feedback.
>>> 
>>> The differences vs. v1 are in the attached patch.
>>> 
>>> Is anyone interested in seeing a v2 posted to the list?
>>> 
>>> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
>>> any testing to add to that?
>>> 
>>> -Jordan
>>> 
>>> Jordan Justen (8):
>>> 
>>> BaseTools/tools_def: Add NASM_FLAGS
>>> 
>>> BaseTools/build_rule: Add .nasm => .obj build rule
>>> 
>>> MdePkg/Base.h: Always define ASM_PFX
>>> 
>>> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>>> 
>>> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>>> 
>>> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>>> 
>>> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>>> 
>>> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>>> 
>>> 
>>> BaseTools/Conf/build_rule.template   |  15 ++
>>> 
>>> BaseTools/Conf/tools_def.template| 287 ++-
>>> 
>>> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>>> 
>>> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>>> 
>>> MdePkg/Include/Base.h|  25 ++-
>>> 
>>> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>>> 
>>> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>>> 
>>> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>>> 
>>> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>>> 
>>> Md

Re: [edk2] [PATCH v3 10/10] AArch64-KVM: add support for non-volatile variable store

[Laszlo Ersek]

some comments below

On 08/27/14 17:12, Ard Biesheuvel wrote:
> This adds support for retaining UEFI environment variables in the second
> emulated NOR flash which resides at phys address 0x0400 (64 MB).
> 
> Note that this requires booting QEMU with two -pflash arguments, each of which
> points to a NOR image file of exactly 64 MB in size. The second one will be 
> used
> as the variable store.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../AArch64Virtualization-KVM.dsc  | 16 +-
>  .../AArch64Virtualization-KVM.fdf  |  4 +-
>  .../Include/Platform/KVM/ArmPlatform.h |  6 +++
>  .../Library/NorFlashKVM/NorFlashKVM.c  | 63 
> ++
>  .../Library/NorFlashKVM/NorFlashKVM.inf| 35 
>  5 files changed, 122 insertions(+), 2 deletions(-)
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.c
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
> 
> diff --git 
> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> index 89c5ff134b41..31d3cb19628c 100644
> --- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> @@ -113,6 +113,16 @@
>#
>gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
>  
> +  #
> +  # NV Storage PCDs. Use base of 0x0400 for NOR1
> +  #
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
> +
>  [PcdsDynamicDefault.common]
># System Memory -- 1 MB initially, actual size will be fetched from DT
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
> @@ -178,7 +188,7 @@
>MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> -  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
> +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> @@ -196,6 +206,10 @@
>  
>ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> +  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf {
> +
> +
> NorFlashPlatformLib|ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>  
>#
> diff --git 
> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf 
> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
> index 78efb8dbb100..1495ebb31c6c 100644
> --- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
> @@ -109,8 +109,8 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> -  INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
>INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
> +  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>INF 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
>INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
> @@ -128,6 +128,7 @@ READ_LOCK_STATUS   = TRUE
>  
>INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> +  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
>INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>  
>#
> @@ -185,6 +186,7 @@ READ_LOCK_STATUS   = TRUE
>INF ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
>INF ArmPkg/Drivers/CpuPei/CpuPei.inf
>INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
> +  INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
>INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>  
> diff --git 
> a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KV

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Sergey Isakov]

And one new question. Why _16GdtrBase with underscore while m16Start without it?
——
;
; These are global constant to convey information to C code.
;
ASM_PFX(m16Size) DW  InternalAsmThunk16 - m16Start
ASM_PFX(mThunk16Attr)DW  _BackFromUserCode.ThunkAttrEnd - 4 - m16Start
ASM_PFX(m16Gdt)  DW  _NullSeg - m16Start
ASM_PFX(m16GdtrBase) DW  _16GdtrBase - m16Start
ASM_PFX(mTransition) DW  _EntryPoint - m16Start

—
I got an error with this
Thunk16.iii:60: error: symbol `m16Start' undefined


On 27 авг. 2014 г., at 22:04, Jordan Justen  wrote:

> On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
>> Hi sirs,
>> I tested Thunk16.nasm too. For x86_64 there is no issue.
>> For ia32 compilation disasm shows not good codes
>> -
>>  :
>>   0: 00 00 add%al,(%eax)
>>   2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 <_BackFromUserCode>:
>>   6: 16   push   %ss
>>   7: 0e   push   %cs
>>   8: 67 e8 00 00 66 9c addr16 call 9c66000e
>> 
>> 
>> 000c <_BackFromUserCode.Base>:
>>   c: 66 9c pushfw
>>   e: fa   cli
>> 
>> -
>> to compare gcc-4.9.1 cvompilation
>> -
>>  :
>>   0: 00 00 add%al,(%eax)
>>   2: 00 00 add%al,(%eax)
>> ...
>> 
>> 0006 :
>>   6: 16   push   %ss
>>   7: 0e   push   %cs
>>   8: 66 e8 00 00   callw  c 
>> ...
>> 
>> 000e :
>>   e: 66 9c pushfw
>>  10: fa   cli
>> 
>> --
>> May be change a32 prefix to o32 in the line:
>> "a32 call.Base   ; push eip"
>> ?
> 
> In the X64 file, I used:
> calldword .Base
> 
> I notice this produced the same code as:
> o32 calldword .Base
> 
> But,
> o32 call.Base
> seems to produce invalid code. (OVMF hangs.)
> 
> It does seem like:
> a32 call.Base
> is functional as well, but I know we are attempting to make the new
> nasm code produce similar code to the old asm code where reasonable.
> 
> I think I only changed it in the X64 file to try to match the old 'db' code.
> 
> -Jordan
> 
>> On 27.08.2014, at 9:50, Jordan Justen wrote:
>> 
>> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>>  wrote:
>> 
>> This series:
>> 
>> * Adds support for creating object files from .nasm source files to
>> 
>>  allow NASM source files to be linked into libraries and images
>> 
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> 
>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>> 
>>  GNU Assembler (.S) files
>> 
>>  - This will make NASM a build requirement for MdePkg with IA32 &
>> 
>>X64 on all toolchains except MSVC and ICC.
>> 
>> 
>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>> 
>> have not been tested very well yet.)
>> 
>> 
>> This series is available in this git branch:
>> 
>> https://github.com/jljusten/edk2.git nasm-v1
>> 
>> 
>> I update my nasm branch based on the feedback.
>> 
>> The differences vs. v1 are in the attached patch.
>> 
>> Is anyone interested in seeing a v2 posted to the list?
>> 
>> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
>> any testing to add to that?
>> 
>> -Jordan
>> 
>> Jordan Justen (8):
>> 
>> BaseTools/tools_def: Add NASM_FLAGS
>> 
>> BaseTools/build_rule: Add .nasm => .obj build rule
>> 
>> MdePkg/Base.h: Always define ASM_PFX
>> 
>> MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>> 
>> MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>> 
>> MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>> 
>> MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>> 
>> 
>> BaseTools/Conf/build_rule.template   |  15 ++
>> 
>> BaseTools/Conf/tools_def.template| 287 ++-
>> 
>> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Base.h|  25 ++-
>> 
>> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>> 
>> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>> 
>> MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-
>> 
>> MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 260 +
>> 
>> MdePkg/Library/BaseLib/X64/Thunk16.nasm  | 321
>> +++
>> 
>> 12 files changed, 914 insertions(+), 22 deletions(-)
>> 
>> create mode 100644 MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
>> 
>> create mode 100644 MdePkg/Library/BaseLib/X64/Thunk16.nasm
>> 
>> 
>> --
>> 
>> 2.1.0
>> 
>> 
>> 
>> --
>> 
>> Slashdot TV.
>> 
>> Video for Nerds.  Stuff that matters.
>> 
>> http://tv.slashdot.org/
>> 

Re: [edk2] [PATCH v3 08/10] ArmPlatformPkg: separate PlatformPei and PlatformPeiLib

[Laszlo Ersek]

On 08/27/14 17:12, Ard Biesheuvel wrote:
> This separates PlatformPei and PlatformPeiLib so the latter can be
> overridden by a specific platform.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/PlatformPei/PlatformPeim.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf 
> b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
> index 8ed44e7e395f..3822b093503b 100755
> --- a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
> +++ b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
> @@ -29,7 +29,6 @@
>  
>  [Sources]
>PlatformPeim.c
> -  PlatformPeiLib.c
>  
>  [Packages]
>MdePkg/MdePkg.dec
> @@ -43,6 +42,7 @@
>DebugLib
>HobLib
>ArmPlatformLib
> +  PlatformPeiLib
>  
>  [Ppis]
>gEfiPeiMasterBootModePpiGuid  # PPI ALWAYS_PRODUCED
> 

I verified this patch as follows: I checked all library class to
instance resolutions for PlatformPeiLib. Namely, with this patch, we
delegate PlatformPeim's dependency on PlatformPeiLib.c from its own
specific INF file to a library resolution.

All the resolutions currently say

  PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf

which in turn lists only one source file, PlatformPeiLib.c (in that
directory). So no regressions here. Hence,

Reviewed-by: Laszlo Ersek 

--o--

While grepping, I did find what looks like a bug in an *independent*
part of the source. In
"ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf", it reads:

  BASE_NAME  = ArmMemoryInitPeiLib
  [...]
  LIBRARY_CLASS  = PlatformPeiLib

Both of these seem to be wrong (although apparently they don't cause
issues in practice): both Defines should say "MemoryInitPeiLib".

Olivier, what's your take on this?

I don't suggest to fix this up in this series, it's just confusing when
someone greps for PlatformPeiLib.

Thanks,
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 07/10] ArmPkg: introduce PCD gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress

[Laszlo Ersek]

On 08/27/14 17:12, Ard Biesheuvel wrote:
> Introduce gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which will be used by
> virtual machine ports that discover the system configuration from a flattened
> device tree DTB image.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dec | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index 43eff6641294..9408b321d45e 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -154,6 +154,8 @@
>gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum|26|UINT32|0x0040
>gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|27|UINT32|0x0041
>  
> +  gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0|UINT64|0x0042
> +
>  [PcdsFixedAtBuild.ARM]
>#
># ARM Security Extension
> 

Looks good to me.

Reviewed-by: Laszlo Ersek 

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Laszlo Ersek]

On 08/27/14 21:02, Ard Biesheuvel wrote:
> On 27 August 2014 20:17, Peter Maydell  wrote:
>> On 27 August 2014 19:15, Olivier Martin  wrote:
>>> I have been through the patchset yet. But I noticed the name of the platform
>>> in another email.
>>> Is this new platform AArch64 specific? Could we imagine this platform being
>>> easily ported to ARMv7 (with Virtualization extension)?
>>
>> No, it's not 64-bit specific. QEMU supports this same board model
>> for both 64-bit and 32-bit CPU types, and we're expecting it to be
>> used for both with KVM.
>>
> 
> You are right. I inherited the name from Michael Casadevall, and did
> not give it any more thought, but in fact, there is very little code
> in there that is specific to AArch64
> 
> I will change the names when I spin a v4.

Please skim the UINTN variables too, I vaguely remember that at some
point in my earlier review I said "this is OK because the code is 64-bit
only".

... It might have been in relation to DEBUGs and their format strings.
The general rule for printing an UINTN in code that can be both 32-bit
and 64-bit is to always cast it to UINT64 explicitly, and use %Lx. When
padding to a specific field width, say 016.

(
The conversion specifiers in edk2 DEBUGs have a few quirks. For example,
you can't print *all* unsigned integers in *decimal*; there's no %u
support. You can only print the full range of unsigned integer types in
hex (%x, %Lx). There's one "trick" for UINT32 though: you can cast such
to INT64 losslessly, then print them with %Ld, in decimal. But there is
no decimal support for the full range of UINT64.

Another quirk is that the "L" (and "l") modifiers don't stand for
"long", they mean "64-bit", even in ILP32 builds. That's why I always
use "L" rather than "l" for UINT64 / INT64: "L" doesn't exist in
standard C, nor in POSIX, for integers, hence it stands out from the
edk2 source as a non-portable length modifier.
)

Thanks
Laszlo


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 06/10] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Laszlo Ersek]

On 08/27/14 17:12, Ard Biesheuvel wrote:
> This changes the definition and a bunch of references to
> gArmTokenSpaceGuid.PcdSystemMemoryBase and
> gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic PCDs
> by the platform. Also, move the non-SEC call to
> ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to set
> these PCDs before they are first referenced.
> 
> The purpose is allowing dynamically instantiated virtual machines to declare
> the system memory by passing a device tree.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dec| 12 ++--
>  ArmPkg/Library/BdsLib/BdsLib.inf |  3 ++-
>  .../PrePi/PrePiArmPlatformGlobalVariableLib.inf  |  7 ---
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf|  6 --
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c| 16 
> 
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf  |  6 --
>  ArmPlatformPkg/PrePi/PeiUniCore.inf  |  6 --
>  7 files changed, 32 insertions(+), 24 deletions(-)

Okay, this patch is identical to the v2 version, but the additional
questions we discussed there will be addressed in separate patches in
this version of the set.

In addition, I checked all implementations of
ArmPlatformInitializeSystemMemory(). There are seven of them. Only one
of them, in
"ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/CTA9x4.c",
is not empty; but even this non-empty implementation is independent of
the PCDs. Hence no regression seems to be possible.

Reviewed-by: Laszlo Ersek 


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 03/10] ArmPkg: allow dynamic GIC base addresses

[Laszlo Ersek]

On 08/27/14 17:12, Ard Biesheuvel wrote:
> Allow the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
> gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase to be redeclared
> as PcdsDynamic by the platform, so virtual machines can set these
> properties during boot. As the PcdGet32() calls now call into the
> PCD database, cache the values that are required during the handling
> of interrupts.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dec | 15 +++--
>  ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  4 +++-
>  ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 37 
> ++-
>  ArmPkg/Library/BdsLib/BdsLib.inf  |  2 +-
>  4 files changed, 33 insertions(+), 25 deletions(-)

Acked-by: Laszlo Ersek 

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Ard Biesheuvel]

On 27 August 2014 20:17, Peter Maydell  wrote:
> On 27 August 2014 19:15, Olivier Martin  wrote:
>> I have been through the patchset yet. But I noticed the name of the platform
>> in another email.
>> Is this new platform AArch64 specific? Could we imagine this platform being
>> easily ported to ARMv7 (with Virtualization extension)?
>
> No, it's not 64-bit specific. QEMU supports this same board model
> for both 64-bit and 32-bit CPU types, and we're expecting it to be
> used for both with KVM.
>

You are right. I inherited the name from Michael Casadevall, and did
not give it any more thought, but in fact, there is very little code
in there that is specific to AArch64

I will change the names when I spin a v4.

-- 
Ard.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Laszlo Ersek]

On 08/27/14 20:09, Peter Maydell wrote:
> On 27 August 2014 17:58, Ard Biesheuvel  wrote:
>> On 27 August 2014 18:03, Laszlo Ersek  wrote:
>>> - Why require a 64MB flash drive, if we only use 768 KB of it?
>>>
>>
>> The ARM Versatile Express development hardware is set up like this,
>> that is the whole and only reason.
>> I guess we could change it if there is a strong reason to do so, but
>> parity with the other emulated machines makes the maintenance job a
>> bit easier, I imagine.
> 
> Yeah, this isn't a strong requirement from the QEMU side, but
> the thought process went something like:
>  * two flash devices is better than one, so we can allow a split
>between what kind of backing file they get (treating ROM
>image differently than non-volatile storage)

ACK for that, positively

>  * might as well be reasonably generous with the sizing, to
>allow for future expansion in what software uses
>  * having an asymmetric "one small, one large" setup seems
>kind of weird
>  * UEFI isn't necessarily the only user of this board model

Okay. Thanks!

> If we've done something silly with the way we've instantiated
> the flash device in QEMU that means it has a stupid large
> block size then we might be able to fix that.

The old wisdom says "measure it first" :)

I think this should only matter on KVM, if it matters at all. And one
way to measure it (if someone really cares) would be to run a Linux
guest, and massage some non-volatile variables from there, in a loop.

An example program is under
.

However I think this investigation can be postponed indefinitely (unless
someone notices a perf degradation with the naked eye). The only thing
that caught my eye was the block size being *different* from OVMF's and
"hw/i386/pc_sysfw.c"'s, but that isn't necessarily a problem.

I think this patch is fine unless proven otherwise in practice.

Thanks,
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Olivier Martin]

I have been through the patchset yet. But I noticed the name of the platform
in another email.
Is this new platform AArch64 specific? Could we imagine this platform being
easily ported to ARMv7 (with Virtualization extension)?
If yes, we should maybe rename it 'ArmVirtualizationPkg' to avoid to
duplicate the code if someone does the port at some point.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 27 August 2014 16:13
> To: ler...@redhat.com; Olivier Martin; edk2-
> de...@lists.sourceforge.net; peter.mayd...@linaro.org;
> christoffer.d...@linaro.org; drjo...@redhat.com;
> ilias.bi...@linaro.org; leif.lindh...@linaro.org
> Cc: Ard Biesheuvel; Michael Casadevall
> Subject: [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-
> virt target
> 
> This adds support for executing UEFI in a QEMU/mach-virt emulated
> environment.
> The following assumptions are made about the target:
> - ARM architected timer
> - PL011 UART at 0x900
> - at least 1 MB of DRAM at 0x4000, containing the device tree blob
> 
> The following information is retrieved from the device tree:
> - GIC base addresses
> - virtual timer interrupt
> - RTC base address
> - system memory base and size
> - virtio MMIO transports
> 
> The DTB image is relocated and installed as a configuration table so an
> EFI stub enabled kernel can be booted directly without the need for a
> bootloader.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Casadevall 
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../AArch64Virtualization-KVM.dsc  | 222
> ++
>  .../AArch64Virtualization-KVM.fdf  | 307
> +++
>  .../AArch64Virtualization.dsc.inc  | 336
> +
>  .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  61 
>  .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 249
> +++
>  .../Include/Platform/KVM/ArmPlatform.h |  27 ++
>  .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  57 
>  .../Library/AArch64VirtualizationLibKVM/KVM.c  | 143 +
>  .../AArch64VirtualizationLibKVM/KVMHelper.S|  86 ++
>  .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 102 +++
>  .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
>  .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 +++
>  .../Library/PlatformPei/PlatformPeiLib.c   |  47 +++
>  .../Library/PlatformPei/PlatformPeiLib.inf |  58 
>  .../Library/ResetSystemLib/ResetSystemLib.c|  97 ++
>  .../Library/ResetSystemLib/ResetSystemLib.inf  |  36 +++
>  .../Library/ResetSystemLib/ResetSystemPsci.S   |  40 +++
>  17 files changed, 1998 insertions(+)
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatfor
> m.h
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLi
> bKVM/AArch64KVMLib.inf
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLi
> bKVM/KVM.c
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLi
> bKVM/KVMHelper.S
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLi
> bKVM/KVMMem.c
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSy
> sConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSy
> sConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.inf
>  create mode 100755
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPei
> Lib.c
>  create mode 100755
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPei
> Lib.inf
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSys
> temLib.c
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSys
> temLib.inf
>  create mode 100644
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSys
> temPsci.S
> 
> diff --git
> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> new file mode 100644
> index ..89c5ff134b41
> --- /dev/null
> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-
> KVM.dsc
> @@ -0,0 +1,222 @@
> +#
> +#  Copyright (c) 2011

Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Peter Maydell]

On 27 August 2014 19:15, Olivier Martin  wrote:
> I have been through the patchset yet. But I noticed the name of the platform
> in another email.
> Is this new platform AArch64 specific? Could we imagine this platform being
> easily ported to ARMv7 (with Virtualization extension)?

No, it's not 64-bit specific. QEMU supports this same board model
for both 64-bit and 32-bit CPU types, and we're expecting it to be
used for both with KVM.

-- PMM

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Peter Maydell]

On 27 August 2014 17:58, Ard Biesheuvel  wrote:
> On 27 August 2014 18:03, Laszlo Ersek  wrote:
>> I'll mention in passing that
>> "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf" is
>> good for a non-authenticated variable store only, ie. no secure boot
>> support. For secure boot support, CryptoPkg / OpensslLib would be
>> necessary too, and another variable driver from under SecurityPkg, etc
>> etc etc, but for this series, the patch definitely suffices.
>>
>
> Yes, I am aware of that. I implemented Secure Boot for the Foundation
> model and VExpress-A15 here:
> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-authenticated-boot
>
> I intend to port those changes onto this platform, which will make my
> remaining work regarding secure boot a lot easier.

That reminds me, what are our plans for potentially supporting EL2
and/or EL3 booting once QEMU eventually supports them in TCG
emulation? Would we have one UEFI image that can cope with
being started in any of EL1/2/3, or would we need separate images?
(EL2/EL3 support is still a little way off, and in any case KVM will
always be EL1 only, so the EL1 config is the most important.)

> (The ARM semihosting interface does not support listing directories
> only opening files directly, which doesn't work with mokmanager/shim)

You probably know this already, but note that enabling semihosting
lets the guest do a pile of exciting things to the host so it's not really
suitable for production configs anyway...

thanks
-- PMM

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Peter Maydell]

On 27 August 2014 17:58, Ard Biesheuvel  wrote:
> On 27 August 2014 18:03, Laszlo Ersek  wrote:
>> - Why require a 64MB flash drive, if we only use 768 KB of it?
>>
>
> The ARM Versatile Express development hardware is set up like this,
> that is the whole and only reason.
> I guess we could change it if there is a strong reason to do so, but
> parity with the other emulated machines makes the maintenance job a
> bit easier, I imagine.

Yeah, this isn't a strong requirement from the QEMU side, but
the thought process went something like:
 * two flash devices is better than one, so we can allow a split
   between what kind of backing file they get (treating ROM
   image differently than non-volatile storage)
 * might as well be reasonably generous with the sizing, to
   allow for future expansion in what software uses
 * having an asymmetric "one small, one large" setup seems
   kind of weird
 * UEFI isn't necessarily the only user of this board model

If we've done something silly with the way we've instantiated
the flash device in QEMU that means it has a stupid large
block size then we might be able to fix that.

thanks
-- PMM

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Laszlo Ersek]

On 08/27/14 18:58, Ard Biesheuvel wrote:

> The ARM Versatile Express development hardware is set up like this,
> that is the whole and only reason.
> I guess we could change it if there is a strong reason to do so, but
> parity with the other emulated machines makes the maintenance job a
> bit easier, I imagine.
> Both the size and the block size are fixed, currently.

Thanks for enlightening me. Just stick with it then, I'd say.

> Considering this is all emulated anyway, is there a performance
> penalty we should taken into account when using such a relatively
> large block size?

It depends on the NOR flash driver (the driver that produces the
FirmwareVolumeBlockProtocol, or FirmwareVolumeBlock2Protocol).

The FVB (and FVB2) protocols expose a block-centric view of the flash.
The performance (when running on QEMU/KVM) largely depends on the CFI
command that the driver uses to reprogram or erase the flash. If those
commands are block level, then you trap once per block (I think anyway).
If you use byte-level programming, then you trap once per byte (this I
know for sure).

During FTW reclaim, the whole live and spare areas are rewritten several
times. OVMF's flash driver currently uses byte-level CFI commands -- and
I have a *very* distant plan to update that to block level, given that
the FVB(2) interface is block-level anyway --, and therefore the reclaim
is *somewhat* noticeable on x86_64 KVM. You get like 100% system load
from the VCPU (the virtual BP) that is running edk2, for 1 or 2 seconds.
(Reclaim happens very rarely.)

Individual non-volatile variable writes are unnoticeable.

Given that OVMF's live area is 56K, and its spare area is 64K (and the
block size is only 4K), you could see more serious CPU demand with a
block size of 256KB. It probably doesn't matter with TCG (which is slow
anyway), but it could be noticeable with KVM.

This is pure speculation of course.

Also, we could actually check out the FVB(2) driver in question,
"ArmPlatformPkg/Drivers/NorFlashDxe":

FvbWrite() [NorFlashFvbDxe.c]
  NorFlashWriteSingleBlock() [NorFlashDxe.c]

It seems to have a trick for writes <= 128 bytes (operating with 4-byte
words --> NorFlashWriteSingleWord()), and for larger writes, it seems to
call NorFlashWriteBlocks() --> NorFlashWriteFullBlock().

NorFlashWriteFullBlock() says

  // To speed up the programming operation, NOR Flash is programmed
using the Buffered Programming method.

... I guess you shouldn't see delays even on KVM; the driver appears
performance-conscious. There's probably nothing to do until you can
notice and measure any tight loops.

> 
>>>  [PcdsDynamicDefault.common]
>>># System Memory -- 1 MB initially, actual size will be fetched from DT
>>>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
>>> @@ -179,7 +189,7 @@
>>>MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>>>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>>>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>>> -  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
>>> +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>>
>> I'll mention in passing that
>> "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf" is
>> good for a non-authenticated variable store only, ie. no secure boot
>> support. For secure boot support, CryptoPkg / OpensslLib would be
>> necessary too, and another variable driver from under SecurityPkg, etc
>> etc etc, but for this series, the patch definitely suffices.
>>
> 
> Yes, I am aware of that. I implemented Secure Boot for the Foundation
> model and VExpress-A15 here:
> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-authenticated-boot

Awesome!

> I intend to port those changes onto this platform, which will make my
> remaining work regarding secure boot a lot easier.
> (The ARM semihosting interface does not support listing directories
> only opening files directly, which doesn't work with mokmanager/shim)

Right. With qemu you can use the vvfat block protocol driver for easy
semihosting, such as:

  -drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \
  -device virtio-blk-device,drive=drive0

It can expose a host directory as a FAT16 volume (up to "516.06 MB" in
size), which should be enough for keys that you want to enrol etc.

Alternatively, guestfish (from libguestfs fame) is very good at quickly
modifying offline virtual disk images.

Thanks,
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Jordan Justen]

On Wed, Aug 27, 2014 at 5:18 AM, Sergey Isakov  wrote:
> Hi sirs,
> I tested Thunk16.nasm too. For x86_64 there is no issue.
> For ia32 compilation disasm shows not good codes
> -
>  :
>0: 00 00 add%al,(%eax)
>2: 00 00 add%al,(%eax)
> ...
>
> 0006 <_BackFromUserCode>:
>6: 16   push   %ss
>7: 0e   push   %cs
>8: 67 e8 00 00 66 9c addr16 call 9c66000e
> 
>
> 000c <_BackFromUserCode.Base>:
>c: 66 9c pushfw
>e: fa   cli
>
> -
> to compare gcc-4.9.1 cvompilation
> -
>  :
>0: 00 00 add%al,(%eax)
>2: 00 00 add%al,(%eax)
> ...
>
> 0006 :
>6: 16   push   %ss
>7: 0e   push   %cs
>8: 66 e8 00 00   callw  c 
> ...
>
> 000e :
>e: 66 9c pushfw
>   10: fa   cli
>
> --
> May be change a32 prefix to o32 in the line:
> "a32 call.Base   ; push eip"
> ?

In the X64 file, I used:
calldword .Base

I notice this produced the same code as:
o32 calldword .Base

But,
o32 call.Base
seems to produce invalid code. (OVMF hangs.)

It does seem like:
a32 call.Base
is functional as well, but I know we are attempting to make the new
nasm code produce similar code to the old asm code where reasonable.

I think I only changed it in the X64 file to try to match the old 'db' code.

-Jordan

> On 27.08.2014, at 9:50, Jordan Justen wrote:
>
> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
>
> This series:
>
> * Adds support for creating object files from .nasm source files to
>
>   allow NASM source files to be linked into libraries and images
>
> * Adds NASM source files for Thunk16 on IA32 and X64
>
> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>
>   GNU Assembler (.S) files
>
>   - This will make NASM a build requirement for MdePkg with IA32 &
>
> X64 on all toolchains except MSVC and ICC.
>
>
> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>
> have not been tested very well yet.)
>
>
> This series is available in this git branch:
>
> https://github.com/jljusten/edk2.git nasm-v1
>
>
> I update my nasm branch based on the feedback.
>
> The differences vs. v1 are in the attached patch.
>
> Is anyone interested in seeing a v2 posted to the list?
>
> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
> any testing to add to that?
>
> -Jordan
>
> Jordan Justen (8):
>
>  BaseTools/tools_def: Add NASM_FLAGS
>
>  BaseTools/build_rule: Add .nasm => .obj build rule
>
>  MdePkg/Base.h: Always define ASM_PFX
>
>  MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>
>  MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>
>  MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>
>  MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>
>  MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>
>
> BaseTools/Conf/build_rule.template   |  15 ++
>
> BaseTools/Conf/tools_def.template| 287 ++-
>
> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Base.h|  25 ++-
>
> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>
> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>
> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>
> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>
> MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-
>
> MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 260 +
>
> MdePkg/Library/BaseLib/X64/Thunk16.nasm  | 321
> +++
>
> 12 files changed, 914 insertions(+), 22 deletions(-)
>
> create mode 100644 MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
>
> create mode 100644 MdePkg/Library/BaseLib/X64/Thunk16.nasm
>
>
> --
>
> 2.1.0
>
>
>
> --
>
> Slashdot TV.
>
> Video for Nerds.  Stuff that matters.
>
> http://tv.slashdot.org/
>
> ___
>
> edk2-devel mailing list
>
> edk2-devel@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> --
>
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.ne

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Jordan Justen]

On Wed, Aug 27, 2014 at 9:50 AM, Andrew Fish  wrote:
>
> On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:
>
> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>
> EmulatorPkg:Host: Port emulator to Xcode5
>
> Xcode5 retired gdb, so this patch adds support for using, and loading
> symbols in, lldb.
>
>
> Cool, but I don't think the subject is right:
> -EmulatorPkg:Host: Port emulator to Xcode5
> +EmulatorPkg Unix Host: Add LLDB support
>
> Well Xcode 5 does not support gdb, and only supports lldb.

Right. I just think the lldb support should be the focus, and Xcode 5
could be mentioned in the main commit message body as one motivation.

-Jordan

> I don't see XCODE5 in the patch. Seems fine to mention in the commit
> message that Xcode5 is the motivation for adding the LLDB support.
>
> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
> on each run? Why is that needed?
>
>
> It pushes control to the lldb Python script. Loading symbols dynamically
> allows the setting of breakpoints prior to loading the module. Loading the
> symbols will resolve the breakpoint and activate it.
> The files written by the emulator are not used by lldb. I should probably
> just move the call to SecGdbScriptBreak() out of the if PCD construct that
> defines how the files get written.
>
> Since the breakpoint script is just doing a few reads from the stack it is
> very fast. The emulator runs about the same speed if you load symbols or
> not.
>
> What's the "+ 1" change in the call to SecGdbScriptBreak?
>
>
> StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not
> Module.dll.
>
> I think the X stuff could be a separate commit from the LLDB part.
>
>
> OK
>
> -Jordan
>
> The lldb script also supports dumping out the build generated guid database
> and it prints guids out with thier Cname if available. lldbefi.py also
> contains some EFI specific type formatters.
>
> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for
> X11, since it is now an external package.
> X11IncludeHack is a symbolic link to /opt/X11/include
>
> To get X11 to work on a Mac you now have to install XQuartz:
> http://xquartz.macosforge.org
>
> To fully work the -combine needs to be removed from the
> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a
> separate commit.
>
> ---
> EmulatorPkg/Unix/Host/Host.c |   5 +-
> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
> EmulatorPkg/Unix/lldbefi.py  | 540
> +++
> EmulatorPkg/Unix/lldbinit|   3 +
> 5 files changed, 549 insertions(+), 2 deletions(-)
> create mode 12 EmulatorPkg/Unix/Host/X11IncludeHack
> create mode 100755 EmulatorPkg/Unix/lldbefi.py
> create mode 100644 EmulatorPkg/Unix/lldbinit
>
> diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
> index 7eecbce..480bc54 100644
> --- a/EmulatorPkg/Unix/Host/Host.c
> +++ b/EmulatorPkg/Unix/Host/Host.c
> @@ -1161,6 +1161,9 @@ GdbScriptAddImage (
>   SymbolsAddr
>   );
> fclose (GdbTempFile);
> +
> +// for lldb call the stub function too
> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer) + 1, (long unsigned
> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>   } else {
> ASSERT (FALSE);
>   }
> @@ -1179,7 +1182,7 @@ GdbScriptAddImage (
> // Target for gdb breakpoint in a script that uses
> gGdbWorkingFileName to set a breakpoint.
> // Hey what can you say scripting in gdb is not that great
> //
> -SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer), (long unsigned int)(ImageContext->ImageAddress +
> ImageContext->SizeOfHeaders), 1);
> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen
> (ImageContext->PdbPointer) + 1, (long unsigned
> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>   } else {
> ASSERT (FALSE);
>   }
> diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.inf
> index dee2e0d..f8a4e99 100644
> --- a/EmulatorPkg/Unix/Host/Host.inf
> +++ b/EmulatorPkg/Unix/Host/Host.inf
> @@ -145,4 +145,4 @@
>XCODE:*_*_X64_DLINK_PATH == gcc
>XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/Host -L/usr/X11R6/lib -lXext
> -lX11 -framework Carbon
>XCODE:*_*_X64_ASM_FLAGS == -g
> -
> +   XCODE:*_*_X64_CC_FLAGS = -include $(DEST_DIR_DEBUG)/AutoGen.h
> -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack
> diff --git a/EmulatorPkg/Unix/Host/X11IncludeHack
> b/EmulatorPkg/Unix/Host/X11IncludeHack
> new file mode 12
> index 000..f7ab103
> --- /dev/null
> +++ b/EmulatorPkg/Unix/Host/X11IncludeHack
> @@ -0,0 +1 @@
> +/opt/X11/include
> \ No newline at end of file
> diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
> new file mode 100755
> index 000..64549ce
> --- /dev/null
> ++

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Ard Biesheuvel]

On 27 August 2014 18:03, Laszlo Ersek  wrote:
> some comments
>
> On 08/26/14 15:03, Ard Biesheuvel wrote:
>> This adds support for retaining UEFI environment variables in the second
>> emulated NOR flash which resides at phys address 0x0400 (64 MB).
>>
>> Note that this requires booting QEMU with two -pflash arguments, each of 
>> which
>> points to a NOR image file of exactly 64 MB in size. The second one will be 
>> used
>> as the variable store.
>>
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  .../AArch64Virtualization-KVM.dsc  | 16 +-
>>  .../AArch64Virtualization-KVM.fdf  |  4 +-
>>  .../Include/Platform/KVM/ArmPlatform.h |  6 +++
>>  .../Library/NorFlashKVM/NorFlashKVM.c  | 63 
>> ++
>>  .../Library/NorFlashKVM/NorFlashKVM.inf| 35 
>>  5 files changed, 122 insertions(+), 2 deletions(-)
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
>>
>> diff --git 
>> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
>> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>> index e0817fca927e..78e83e92be2d 100644
>> --- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>> @@ -117,6 +117,16 @@
>>#
>>gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
>>
>> +  #
>> +  # NV Storage PCDs. Use base of 0x0400 for NOR1
>> +  #
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
>> +
>
> Hrmpf. These look strange. I'll explain why.
>
> The promise of this patch is to set up a 64 MB flash chip (which is
> absolutely huge, at least for varstore purposes). Then, supposedly,
> looking at the definition and the use of the QEMU_NOR_BSIZE macro
> (SIZE_256KB, NOR_FLASH_DESCRIPTION.BlockSize), this 64MB flash chip
> would be handled in blocks of 256KB.
>
> Which I could imagine, in theory, but the above PCDs mean different
> things. These PCD's control the "Fault Tolerant Write" driver
> (MdeModulePkg/Universal/FaultTolerantWriteDxe).
>
> The FTW driver (no, it doesn't mean "for the win", not by far :)),
> implements a kind of "journaled storage" in the flash, the point being
> that at no point during flash writes should a power loss cause data
> corruption.
>
[...]
>
> Here's the things that surprise me:
>
> - Why require a 64MB flash drive, if we only use 768 KB of it?
>

The ARM Versatile Express development hardware is set up like this,
that is the whole and only reason.
I guess we could change it if there is a strong reason to do so, but
parity with the other emulated machines makes the maintenance job a
bit easier, I imagine.
Both the size and the block size are fixed, currently.

> - Why set the block size of the flash drive to 256 KB? That will mean
>   basically that each of the three areas, live, working, and spare,
>   consists of 1 block only. Since these beasts are addressed on
>   the block level, any modification to an area will always rewrite the
>   entire area (== 1 block).
>

See above

> - In comparison, here's how the OVMF varstore looks like. The block
>   size is 4 KB.
>
> +--+-++
> | live data, 14 * 4KB == 56 KB | event log, 4 KB | working area, 4 KB |
> +--+-++
> |   spare area, 16 * 4KB == 64 KB |
> +-+
>
> The 1st difference is that OVMF has much smaller flash block size (4KB
> vs. 256 KB), and that OVMF's varstore is actually organized of *several*
> of these 4KB blocks. (Whereas ARM's is just 1 block / area.)
>
> The 2nd difference is that OVMF has an event log area. No clue why it is
> useful, but it's interesting why ARM doesn't have one.
>
> The 3rd difference is that OVMF's working area is just 1 block (a
> fraction of the live data area), while on ARM the live and working block
> areas are same-sized. I think this is a direct consequence of the flash
> block size being huge (256KB). All areas must be an integral multiple of
> the block size, and you can't go below 1 block.
>
> The 4th difference is that OVMF's spare area, 64KB, mirrors not only the
> live area (56KB), but also the event log (4KB) and the working area
> (4KB). Whereas on ARM, the

Re: [edk2] BuildMemoryAllocationHob() vs. gEfiPeiMemoryDiscoveredPpiGuid

[Andrew Fish]

On Aug 27, 2014, at 2:07 AM, Laszlo Ersek  wrote:

> Hi All,
> 
> based on Chapter 11, PEI Physical Memory Usage, in the PI spec, I think
> that any PEIM that wants to call BuildMemoryAllocationHob() must make
> sure that it runs on permanent PEI RAM.
> 
> In other words, it seems like BuildMemoryAllocationHob() is restricted
> to PEI code that runs after permanent PEI RAM installation.
> 
> One way a PEIM can conform to this requirement is apparently a Depex on
> gEfiPeiMemoryDiscoveredPpiGuid.
> 
> Questions:
> - Is BuildMemoryAllocationHob() in fact restricted this way?

No. The HOB structures are independent of memory addresses. When the migration 
is made from temp ram to memory the PEI Core re-initializes it’s self and 
copies the HOBs over.  

> - If so, is a gEfiPeiMemoryDiscoveredPpiGuid Depex a good way to comply
>  with this restriction in a PEIM (that doesn't itself install the
>  permanent PEI RAM)?
> 

Yes, and this means the PEIM can be shadowed into memory. It also makes it 
possible to compress the PEIM if needed. 

> In practice, this question has no consequences for OvmfPkg, because
> there we already conform to the (apparent) requirement, and we ensure
> the ordering simply by installing the permanent PEI RAM in the *same*
> PEIM that later on calls BuildMemoryAllocationHob().
> 
> However, in ArmPlatformPkg/AArch64VirtualizationPkg, we might call
> BuildMemoryAllocationHob() in a PEIM that is *separate* from the PEIM
> that installs the permantent PEI RAM. Hence I think that this dependency
> should be spelled out explicitly in the dependent PEIM's depex.
> 
> Thanks!
> Laszlo
> 
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [EmulatorPkg][PATCH]EmulatorPkg:Host: Port emulator to Xcode5

[Andrew Fish]

On Aug 26, 2014, at 11:17 PM, Jordan Justen  wrote:

> On Tue, Aug 26, 2014 at 9:34 PM, Andrew Fish  wrote:
>> EmulatorPkg:Host: Port emulator to Xcode5
>> 
>> Xcode5 retired gdb, so this patch adds support for using, and loading 
>> symbols in, lldb.
> 
> Cool, but I don't think the subject is right:
> -EmulatorPkg:Host: Port emulator to Xcode5
> +EmulatorPkg Unix Host: Add LLDB support
> 

Well Xcode 5 does not support gdb, and only supports lldb. 

> I don't see XCODE5 in the patch. Seems fine to mention in the commit
> message that Xcode5 is the motivation for adding the LLDB support.
> 
> Is the new SecGdbScriptBreak call going to cause EmulatorPkg to break
> on each run? Why is that needed?
> 

It pushes control to the lldb Python script. Loading symbols dynamically allows 
the setting of breakpoints prior to loading the module. Loading the symbols 
will resolve the breakpoint and activate it. 
The files written by the emulator are not used by lldb. I should probably just 
move the call to SecGdbScriptBreak() out of the if PCD construct that defines 
how the files get written. 

Since the breakpoint script is just doing a few reads from the stack it is very 
fast. The emulator runs about the same speed if you load symbols or not. 

> What's the "+ 1" change in the call to SecGdbScriptBreak?
> 

StrSize vs. StrLen. So it was a bug. Lldb was only getting Module.dl and not 
Module.dll. 

> I think the X stuff could be a separate commit from the LLDB part.
> 

OK

> -Jordan
> 
>> The lldb script also supports dumping out the build generated guid database 
>> and it prints guids out with thier Cname if available. lldbefi.py also 
>> contains some EFI specific type formatters.
>> 
>> Unix/Host/X11IncludeHack is a symbolic link that is need to add the path for 
>> X11, since it is now an external package.
>> X11IncludeHack is a symbolic link to /opt/X11/include
>> 
>> To get X11 to work on a Mac you now have to install XQuartz: 
>> http://xquartz.macosforge.org
>> 
>> To fully work the -combine needs to be removed from the 
>> *_XCODE32_X64_CC_FLAGS in BaseTools/Conf/tools_def.template, this will be a 
>> separate commit.
>> 
>> ---
>> EmulatorPkg/Unix/Host/Host.c |   5 +-
>> EmulatorPkg/Unix/Host/Host.inf   |   2 +-
>> EmulatorPkg/Unix/Host/X11IncludeHack |   1 +
>> EmulatorPkg/Unix/lldbefi.py  | 540 
>> +++
>> EmulatorPkg/Unix/lldbinit|   3 +
>> 5 files changed, 549 insertions(+), 2 deletions(-)
>> create mode 12 EmulatorPkg/Unix/Host/X11IncludeHack
>> create mode 100755 EmulatorPkg/Unix/lldbefi.py
>> create mode 100644 EmulatorPkg/Unix/lldbinit
>> 
>> diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
>> index 7eecbce..480bc54 100644
>> --- a/EmulatorPkg/Unix/Host/Host.c
>> +++ b/EmulatorPkg/Unix/Host/Host.c
>> @@ -1161,6 +1161,9 @@ GdbScriptAddImage (
>>   SymbolsAddr
>>   );
>> fclose (GdbTempFile);
>> +
>> +// for lldb call the stub function too
>> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen 
>> (ImageContext->PdbPointer) + 1, (long unsigned 
>> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>>   } else {
>> ASSERT (FALSE);
>>   }
>> @@ -1179,7 +1182,7 @@ GdbScriptAddImage (
>> // Target for gdb breakpoint in a script that uses 
>> gGdbWorkingFileName to set a breakpoint.
>> // Hey what can you say scripting in gdb is not that great
>> //
>> -SecGdbScriptBreak (ImageContext->PdbPointer, strlen 
>> (ImageContext->PdbPointer), (long unsigned int)(ImageContext->ImageAddress + 
>> ImageContext->SizeOfHeaders), 1);
>> +SecGdbScriptBreak (ImageContext->PdbPointer, strlen 
>> (ImageContext->PdbPointer) + 1, (long unsigned 
>> int)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders), 1);
>>   } else {
>> ASSERT (FALSE);
>>   }
>> diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.inf
>> index dee2e0d..f8a4e99 100644
>> --- a/EmulatorPkg/Unix/Host/Host.inf
>> +++ b/EmulatorPkg/Unix/Host/Host.inf
>> @@ -145,4 +145,4 @@
>>XCODE:*_*_X64_DLINK_PATH == gcc
>>XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/Host -L/usr/X11R6/lib -lXext 
>> -lX11 -framework Carbon
>>XCODE:*_*_X64_ASM_FLAGS == -g
>> -
>> +   XCODE:*_*_X64_CC_FLAGS = -include $(DEST_DIR_DEBUG)/AutoGen.h 
>> -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack
>> diff --git a/EmulatorPkg/Unix/Host/X11IncludeHack 
>> b/EmulatorPkg/Unix/Host/X11IncludeHack
>> new file mode 12
>> index 000..f7ab103
>> --- /dev/null
>> +++ b/EmulatorPkg/Unix/Host/X11IncludeHack
>> @@ -0,0 +1 @@
>> +/opt/X11/include
>> \ No newline at end of file
>> diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
>> new file mode 100755
>> index 000..64549ce
>> --- /dev/null
>> +++ b/EmulatorPkg/Unix/lldbefi.py
>> @@ -0,0 +1,540 @@
>> +#!/usr/bin/python
>> +
>> +#
>> +#  Copyright 2014 Apple 

Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II packages

[Jordan Justen]

On Tue, Aug 26, 2014 at 10:38 PM, Gao, Liming  wrote:
> Jordan:
>   After UPT clean up, those files can still edit easily. UPT tool just
> changes section Order and Alignment. The source package can
> still directly be compared. So, daily work is no change.

No, they cannot be directly compared. Just look at the size of your
patch. It will not be possible to compare a tree before and after this
change.

It is not even really possible to review the patch.

Source control history is being sacrificed for UPT.

Isn't this exactly the kind of thing that people hate? A tree wide,
search-replace that makes diff'ing impossible?

I still think it is strange that UPT can't help the user to diff
things, rather than munging all these source files in the tree.

And, this is not just a one time thing. It'll happen every release...

-Jordan

> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
> Sent: Wednesday, August 27, 2014 12:16 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK II 
> packages
>
> On Tue, Aug 26, 2014 at 7:17 AM, Gao, Liming  wrote:
>> Jordan:
>> UPT clean up main purpose has been mentioned in Mike email. "This
>> allows UDP packages installed by UPT to be compared against EDK II
>> trunk/branches using standard diff utilities."
>
> I thought we moved away from xml files to have files that a developer could 
> edit easily with a text editor. But, now we can't just edit these files 
> unless we do things just right for some tool. (That I personally don't plan 
> to ever use.)
>
> So, you will sacrifice being able to diff the actual files in source control 
> so you can diff the files after running them through some tool?
>
>> For new added section, they may not follow UPT order.
>> We can clean up them together on next major release.
>
> Great. So, this will just keep happening. Woohoo.
>
> -Jordan
>
>> -Original Message-
>> From: Jordan Justen [mailto:jljus...@gmail.com]
>> Sent: Tuesday, August 26, 2014 2:28 PM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] [Patch 2/2] [MdePkg] INF/DEC file updates to EDK
>> II packages
>>
>> On Mon, Aug 25, 2014 at 7:01 PM, Gao, Liming  wrote:
>>> Jordan:
>>>   The real requirement is that some users use UPT to install core
>>> package into the different directories, such as Core\MdePkg.
>>>  After the installation, they want to easily compare the original
>>> package and installed package.
>>
>> Can't the tool help to easily compare the package without the order of these 
>> sections being so strict?
>>
>>>   This change is required by EDKII project major release, but not required 
>>> for daily development.
>>>
>>>   The section order will not be changed unless new section are introduced 
>>> in INF/DEC.
>>
>> But what about when a developer add a new section to a .inf or .dec?
>> Will there be a major EDK II cleaning every six months?
>>
>>>   Yes. Those changes are directly output from UPT tool. And, we have test 
>>> to cover this tool. So, I have  confidence.
>>
>> Okay, so it seems likely that either the tool:
>> * broke the world, or
>> * didn't break anything
>>
>> At least there shouldn't be a needle in a haystack problem.
>>
>>>   So far, I have no branch for those change. If you request, I could
>>> send zip the source INF/DEC (before UPT and after
>>> UPT) to you.
>>
>> No thanks. I would prefer that you start using git, and post a branch with 
>> your changes incorporated.
>>
>> -Jordan
>>
>> --
>> 
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>> --
>> 
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that 

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Laszlo Ersek]

On 08/27/14 11:47, Paolo Bonzini wrote:
> Il 26/08/2014 18:49, Laszlo Ersek ha scritto:
>> The problem is that a number of tables are not linked into the RSDT,
>> they are referenced by other tables. Basically, all the pointer fields
>> in all tables that are updated (relocated / absolutized) by AddPointer
>> commands, point *potentially* to further ACPI tables.
> 
> Right, the FADT's pointers to FACS and DSDT are an exception.  But are
> there others?  And you don't really care about _where_ the tables are,
> just if they are there, and you know that FACS+DSDT are always provided
> by QEMU.

This is probably implementable, if someone can come up with a clear list
of reasonably future-proof rules.

It would be good to avoid revisiting this OVMF code every now and then,
whenever QEMU's ACPI generator undergoes a bit more intrusive changes.

>> The above would mean two things at the same time:
>> - precisely the ACPI knowledge that the linker/loader interface is
>> supposed to obviate in the firmware,
>> - precisely the ACPI knowledge that the current implementation of
>> EFI_ACPI_TABLE_PROTOCOL encodes, and updates from time to time, when
>> some new table is standardized (or when something already standardized
>> breaks simply due to bugs).
> 
> Yes, this is unfortunate.  But I still believe that all you need to know
> is the format of the RSDT/XSDT.
> 
> Is it possible to at least provide a *dummy* implementation of the ACPI
> table protocol, that returns an error?  This would avoid weird
> situations where booting from iSCSI breaks CPU hotplug or something like
> that.

Sure, that's certainly possible; it crossed my mind too.

(We could also consistently lie and return EFI_SUCCESS -- who knows
which one would do less damage. Drivers that depend on
EFI_ACPI_TABLE_PROTOCOL *and* have sensible error handling would cope
with a persistent error just fine (at worst the service wouldn't be
available). But some drivers are lazy and just say ASSERT_EFI_ERROR(),
and then an error would halt the firmware.)

Anyway, implementing such a dummy driver would take a build time flag
(-D ...), and when it was present, we'd build and include this dummy
protocol implementation in the firmware, rather than the one from
MdeModulePkg. (Because, although EFI_ACPI_TABLE_PROTOCOL is not an
"architectural" protocol, it's definitely a "singleton" one, so clients
just grab the first instance they find.)

Not sure how Jordan would like this though :)

Thanks
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

[Laszlo Ersek]

some comments

On 08/26/14 15:03, Ard Biesheuvel wrote:
> This adds support for retaining UEFI environment variables in the second
> emulated NOR flash which resides at phys address 0x0400 (64 MB).
> 
> Note that this requires booting QEMU with two -pflash arguments, each of which
> points to a NOR image file of exactly 64 MB in size. The second one will be 
> used
> as the variable store.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  .../AArch64Virtualization-KVM.dsc  | 16 +-
>  .../AArch64Virtualization-KVM.fdf  |  4 +-
>  .../Include/Platform/KVM/ArmPlatform.h |  6 +++
>  .../Library/NorFlashKVM/NorFlashKVM.c  | 63 
> ++
>  .../Library/NorFlashKVM/NorFlashKVM.inf| 35 
>  5 files changed, 122 insertions(+), 2 deletions(-)
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.c
>  create mode 100644 
> ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
> 
> diff --git 
> a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
> b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> index e0817fca927e..78e83e92be2d 100644
> --- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
> @@ -117,6 +117,16 @@
>#
>gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
>  
> +  #
> +  # NV Storage PCDs. Use base of 0x0400 for NOR1
> +  #
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
> +

Hrmpf. These look strange. I'll explain why.

The promise of this patch is to set up a 64 MB flash chip (which is
absolutely huge, at least for varstore purposes). Then, supposedly,
looking at the definition and the use of the QEMU_NOR_BSIZE macro
(SIZE_256KB, NOR_FLASH_DESCRIPTION.BlockSize), this 64MB flash chip
would be handled in blocks of 256KB.

Which I could imagine, in theory, but the above PCDs mean different
things. These PCD's control the "Fault Tolerant Write" driver
(MdeModulePkg/Universal/FaultTolerantWriteDxe).

The FTW driver (no, it doesn't mean "for the win", not by far :)),
implements a kind of "journaled storage" in the flash, the point being
that at no point during flash writes should a power loss cause data
corruption.

Let me quote the PCD descriptions from "MdeModulePkg/MdeModulePkg.dec",
in the above order, rewrapping the descriptions:

(1)
  PcdFlashNvStorageVariableBase --> 0x0400

  ## Base address of the NV variable range in flash device

Okay.

(2)
  PcdFlashNvStorageVariableSize --> 0x0004 (256 kilobytes)

  ## Size of the NV variable range. Note that this value should less
  ## than or equal to PcdFlashNvStorageFtwSpareSize
  #  The root cause is that variable driver will use FTW protocol to
  #  reclaim variable region. If the length of variable region is larger
  #  than FTW spare size, it means the whole variable region can not be
  #  reflushed through the manner of fault tolerant write.

I'll try to explain this "reclaim" thing in a minute (in a quite
hand-wavy manner), but first, let's just realize that this PCD controls
the *complete size* of the *live data* in the varstore.

Then,

(3)
  PcdFlashNvStorageFtwWorkingBase --> 0x0404

  ## Base address of the FTW working block range in flash device.

This does make sense. The working block is tacked to the end of the raw
varstore blocks. Fine.

(4)
  PcdFlashNvStorageFtwWorkingSize --> 0x0004 (256 KB again)

  ## Size of the FTW working block range.

This seems valid, but I'm not sure why it is so large.

(5)
  PcdFlashNvStorageFtwSpareBase --> 0x0408

  ## Base address of the FTW spare block range in flash device. Note
  ## that this value should be block size aligned.

The spare area starts after the end of the working area, good.

(6)
  PcdFlashNvStorageFtwSpareSize --> 0x0004 (256 KB)

  ## Size of the FTW spare block range. Note that this value should
  ## larger than PcdFlashNvStorageVariableSize and block size aligned.
  # The root cause is that variable driver will use FTW protocol to
  # reclaim variable region. If the length of variable region is larger
  # than FTW spare size, it means the whole variable region can not be
  # reflushed through the manner of fault tolerant write.


So, the first 768 KB of the flash drive in question will look like:

65536 KB +++
 | live data, 256 KB  | working block area, 256 KB |
66048 KB +--

Re: [edk2] [Patch RFC] Fix formatting of four more c-based tool's --version option

[Gao, Liming]

Larry:
  The patch is good. Reviewed-by: Gao, Liming 

From: Hauch, Larry
Sent: Wednesday, August 27, 2014 4:44 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: [Patch RFC] Fix formatting of four more c-based tool's --version option

Liming,
Please review the attached patch.

Updated GenBootSector, GenCrc32 and GenPage to remove duplicate "Build" word in 
the version output, updated the minor number and copyright as needed.
Updated the VolInfo version output to remove the tool description from the 
--version output string.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch mailto:larry.ha...@intel.com>>
Reviewed-by:

This should complete all changes to existing tool --version option output.

Larry Hauch
Intel Corporation
SSG, STO, Platform Software Infrastructure
2800 Center Dr.
DuPont, WA 98327
Work: (253) 371-8550

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE

[Zeng, Star]

Hi Alexei,

Thanks for your finding, attach the patch for your review.

MdePkg Acpi51.h: Correct the declaration of 
EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Star Zeng mailto:star.z...@intel.com>>

Thanks,
Star
From: Alexei Fedorov [mailto:alexei.fedo...@arm.com]
Sent: Wednesday, August 27, 2014 9:35 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE


EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE declaration in 
\edk2\MdePkg\Include\IndustryStandard\Acpi51.h has wrong field lengths:



///

/// SBSA Generic Watchdog Structure

///

typedef struct {

  UINT8   Type;

  UINT8   Length;

  UINT16  Reserved;

...



This should be



typedef struct {

  UINT8   Type;

  UINT16  Length;

  UINT8   Reserved;

...



According to Table 5-123 SBSA Generic Watchdog Structure Format of ACPI 5.1 
Specification on p.197:



FieldByte Length Byte Offset Description

Type 1   0   0x1 Watchdog GT

Length   2   1   28

Reserved 1   3   Must be zero



Alexei.



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782


Acpi51.h.patch
Description: Acpi51.h.patch
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 10/10] AArch64-KVM: add support for non-volatile variable store

[Ard Biesheuvel]

This adds support for retaining UEFI environment variables in the second
emulated NOR flash which resides at phys address 0x0400 (64 MB).

Note that this requires booting QEMU with two -pflash arguments, each of which
points to a NOR image file of exactly 64 MB in size. The second one will be used
as the variable store.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 .../AArch64Virtualization-KVM.dsc  | 16 +-
 .../AArch64Virtualization-KVM.fdf  |  4 +-
 .../Include/Platform/KVM/ArmPlatform.h |  6 +++
 .../Library/NorFlashKVM/NorFlashKVM.c  | 63 ++
 .../Library/NorFlashKVM/NorFlashKVM.inf| 35 
 5 files changed, 122 insertions(+), 2 deletions(-)
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf

diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
index 89c5ff134b41..31d3cb19628c 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
@@ -113,6 +113,16 @@
   #
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
 
+  #
+  # NV Storage PCDs. Use base of 0x0400 for NOR1
+  #
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0400
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0404
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0408
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
+
 [PcdsDynamicDefault.common]
   # System Memory -- 1 MB initially, actual size will be fetched from DT
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x4000
@@ -178,7 +188,7 @@
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
@@ -196,6 +206,10 @@
 
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf {
+
+
NorFlashPlatformLib|ArmPlatformPkg/AArch64VirtualizationPkg/Library/NorFlashKVM/NorFlashKVM.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
index 78efb8dbb100..1495ebb31c6c 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
@@ -109,8 +109,8 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
   INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
@@ -128,6 +128,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+  INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
@@ -185,6 +186,7 @@ READ_LOCK_STATUS   = TRUE
   INF ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
   INF ArmPkg/Drivers/CpuPei/CpuPei.inf
   INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
+  INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
   INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
   INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h 
b/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
index 5a74456d123e..77c3b37487d4 100644
--- a/ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/Include/P

[edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Ard Biesheuvel]

This adds support for executing UEFI in a QEMU/mach-virt emulated environment.
The following assumptions are made about the target:
- ARM architected timer
- PL011 UART at 0x900
- at least 1 MB of DRAM at 0x4000, containing the device tree blob

The following information is retrieved from the device tree:
- GIC base addresses
- virtual timer interrupt
- RTC base address
- system memory base and size
- virtio MMIO transports

The DTB image is relocated and installed as a configuration table so an
EFI stub enabled kernel can be booted directly without the need for a
bootloader.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall 
Signed-off-by: Ard Biesheuvel 
---
 .../AArch64Virtualization-KVM.dsc  | 222 ++
 .../AArch64Virtualization-KVM.fdf  | 307 +++
 .../AArch64Virtualization.dsc.inc  | 336 +
 .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  61 
 .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 249 +++
 .../Include/Platform/KVM/ArmPlatform.h |  27 ++
 .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  57 
 .../Library/AArch64VirtualizationLibKVM/KVM.c  | 143 +
 .../AArch64VirtualizationLibKVM/KVMHelper.S|  86 ++
 .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 102 +++
 .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
 .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 +++
 .../Library/PlatformPei/PlatformPeiLib.c   |  47 +++
 .../Library/PlatformPei/PlatformPeiLib.inf |  58 
 .../Library/ResetSystemLib/ResetSystemLib.c|  97 ++
 .../Library/ResetSystemLib/ResetSystemLib.inf  |  36 +++
 .../Library/ResetSystemLib/ResetSystemPsci.S   |  40 +++
 17 files changed, 1998 insertions(+)
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
 create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
 create mode 100644 ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMHelper.S
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMMem.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.inf
 create mode 100755 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPeiLib.c
 create mode 100755 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/PlatformPei/PlatformPeiLib.inf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.inf
 create mode 100644 
ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemPsci.S

diff --git 
a/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc 
b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
new file mode 100644
index ..89c5ff134b41
--- /dev/null
+++ b/ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
@@ -0,0 +1,222 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2014, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = AArch64Virtualization-KVM
+  PLATFORM_GUID  = 37d7e986-f7e9-45c2-8067-e371421a626c
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION 

[edk2] [PATCH v3 08/10] ArmPlatformPkg: separate PlatformPei and PlatformPeiLib

[Ard Biesheuvel]

This separates PlatformPei and PlatformPeiLib so the latter can be
overridden by a specific platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/PlatformPei/PlatformPeim.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf 
b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
index 8ed44e7e395f..3822b093503b 100755
--- a/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
+++ b/ArmPlatformPkg/PlatformPei/PlatformPeim.inf
@@ -29,7 +29,6 @@
 
 [Sources]
   PlatformPeim.c
-  PlatformPeiLib.c
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -43,6 +42,7 @@
   DebugLib
   HobLib
   ArmPlatformLib
+  PlatformPeiLib
 
 [Ppis]
   gEfiPeiMasterBootModePpiGuid  # PPI ALWAYS_PRODUCED
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 06/10] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

This changes the definition and a bunch of references to
gArmTokenSpaceGuid.PcdSystemMemoryBase and
gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic PCDs
by the platform. Also, move the non-SEC call to
ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to set
these PCDs before they are first referenced.

The purpose is allowing dynamically instantiated virtual machines to declare
the system memory by passing a device tree.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec| 12 ++--
 ArmPkg/Library/BdsLib/BdsLib.inf |  3 ++-
 .../PrePi/PrePiArmPlatformGlobalVariableLib.inf  |  7 ---
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf|  6 --
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c| 16 
 ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf  |  6 --
 ArmPlatformPkg/PrePi/PeiUniCore.inf  |  6 --
 7 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index e5ed445ca367..43eff6641294 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -116,12 +116,6 @@
   gArmTokenSpaceGuid.PcdHypFvBaseAddress|0|UINT32|0x003C
   gArmTokenSpaceGuid.PcdHypFvSize|0|UINT32|0x003D
 
-  # System Memory (DRAM): These PCDs define the region of in-built system 
memory
-  # Some platforms can get DRAM extensions, these additional regions will be 
declared
-  # to UEFI by ArmPlatformLib
-  gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
-  gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
-
   # Use ClusterId + CoreId to identify the PrimaryCore
   gArmTokenSpaceGuid.PcdArmPrimaryCoreMask|0xF03|UINT32|0x0031
   # The Primary Core is ClusterId[0] & CoreId[0]
@@ -143,6 +137,12 @@
 
 
 [PcdsFixedAtBuild.common,PcdsDynamic.common]
+  # System Memory (DRAM): These PCDs define the region of in-built system 
memory
+  # Some platforms can get DRAM extensions, these additional regions will be 
declared
+  # to UEFI by ArmPlatformLib
+  gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
+  gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
+
   #
   # ARM Architectural Timer
   #
diff --git a/ArmPkg/Library/BdsLib/BdsLib.inf b/ArmPkg/Library/BdsLib/BdsLib.inf
index 3e1ae8914abf..7302d6ab1b1c 100644
--- a/ArmPkg/Library/BdsLib/BdsLib.inf
+++ b/ArmPkg/Library/BdsLib/BdsLib.inf
@@ -77,10 +77,11 @@
 [FeaturePcd]
   gArmTokenSpaceGuid.PcdArmLinuxSpinTable
 
-[FixedPcd]
+[Pcd]
   gArmTokenSpaceGuid.PcdSystemMemoryBase
   gArmTokenSpaceGuid.PcdSystemMemorySize
 
+[FixedPcd]
   gArmTokenSpaceGuid.PcdArmMachineType
   gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset
   gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
 
b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
index 5d3a93fb7207..596f5595412e 100644
--- 
a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
+++ 
b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/PrePi/PrePiArmPlatformGlobalVariableLib.inf
@@ -37,9 +37,10 @@
   gArmTokenSpaceGuid.PcdFdBaseAddress
   gArmTokenSpaceGuid.PcdFdSize
 
-  gArmTokenSpaceGuid.PcdSystemMemoryBase
-  gArmTokenSpaceGuid.PcdSystemMemorySize
-
   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
 
+[Pcd]
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+  gArmTokenSpaceGuid.PcdSystemMemorySize
+
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf 
b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
index 4b21caa0279e..441f8848e7d9 100755
--- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
+++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
@@ -48,8 +48,6 @@
   gArmTokenSpaceGuid.PcdFdBaseAddress
   gArmTokenSpaceGuid.PcdFdSize
 
-  gArmTokenSpaceGuid.PcdSystemMemoryBase
-  gArmTokenSpaceGuid.PcdSystemMemorySize
   gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize
 
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
@@ -62,5 +60,9 @@
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData
 
+[Pcd]
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+  gArmTokenSpaceGuid.PcdSystemMemorySize
+   
 [depex]
   TRUE
diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c 
b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
index 4821fdc2fa89..587c4b5ce3a3 100755
--- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
+++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c
@@ -103,14 +103,6 @@ InitializeMemory (
 
   DEBUG ((EFI_D_ERROR, "Memory Init PEIM Loaded\n"));
 
-  // Ensure PcdSystemMemorySize has been set
-  ASSERT (FixedPcdGet64 (PcdSystemMemorySize) != 0);
-
-  SystemMemoryBase = (UINTN)F

[edk2] [PATCH v3 04/10] ArmPlatformPkg/PrePeiCore: remove GIC related PCDs from unicore

[Ard Biesheuvel]

Remove the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase from PrePeiCoreUniCore.inf,
as they are not in fact used by the module.

Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf 
b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
index ecef43231df3..d677f150e990 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
@@ -72,6 +72,3 @@
   gArmPlatformTokenSpaceGuid.PcdCPUCoreSecondaryStackSize
 
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
-
-  gArmTokenSpaceGuid.PcdGicDistributorBase
-  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 02/10] ArmPkg: allow dynamically discovered virtual timer interrupt

[Ard Biesheuvel]

To support booting on virtual machines whose interrupt routing is
discovered from the device tree, allow the interrupt numbers to
be redeclared as PcdsDynamic by the platform .dsc

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec  | 2 ++
 ArmPkg/Drivers/TimerDxe/TimerDxe.c | 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index c2551d7c3307..0392af52758f 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -140,6 +140,8 @@
   # Maximum file size for TFTP servers that do not support 'tsize' extension
   gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x
 
+
+[PcdsFixedAtBuild.common,PcdsDynamic.common]
   #
   # ARM Architectural Timer
   #
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index 9227be8326b0..2787f05c62be 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -36,6 +36,8 @@ EFI_EVENT EfiExitBootServicesEvent = 
(EFI_EVENT)NULL;
 // The current period of the timer interrupt
 UINT64 mTimerPeriod = 0;
 
+UINTN mArmArchTimerTimerFreq = 0;
+
 // Cached copy of the Hardware Interrupt protocol instance
 EFI_HARDWARE_INTERRUPT_PROTOCOL *gInterrupt = NULL;
 
@@ -144,7 +146,7 @@ TimerDriverSetTimerPeriod (
 // Convert TimerPeriod to micro sec units
 TimerTicks = DivU64x32 (TimerPeriod, 10);
 
-TimerTicks = MultU64x32 (TimerTicks, 
(PcdGet32(PcdArmArchTimerFreqInHz)/100));
+TimerTicks = MultU64x32 (TimerTicks, mArmArchTimerTimerFreq);
 
 ArmArchTimerSetTimerVal((UINTN)TimerTicks);
 
@@ -343,6 +345,8 @@ TimerInitialize (
   Status = TimerDriverSetTimerPeriod (&gTimer, 0);
   ASSERT_EFI_ERROR (Status);
 
+  mArmArchTimerTimerFreq = ArmArchTimerGetTimerFreq () / 100;
+
   // Install secure and Non-secure interrupt handlers
   // Note: Because it is not possible to determine the security state of the
   // CPU dynamically, we just install interrupt handler for both sec and 
non-sec
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 05/10] ArmPlatformPkg: allow dynamically discovered PL031 RTC

[Ard Biesheuvel]

Allow the PCDs gArmPlatformTokenSpaceGuid.PcdPL031RtcBase and
gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy PCDs to be
declared as PcdsDynamic by the platform so they can be overridden
during boot.

Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek 
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 555c9284bc1b..755e8762f666 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -109,10 +109,6 @@
   gArmPlatformTokenSpaceGuid.PL011UartInteger|0|UINT32|0x0020
   gArmPlatformTokenSpaceGuid.PL011UartFractional|0|UINT32|0x002D
 
-  ## PL031 RealTimeClock
-  gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
-  gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy|3|UINT32|0x0022
-
   ## PL061 GPIO
   gArmPlatformTokenSpaceGuid.PcdPL061GpioBase|0x0|UINT32|0x0025
 
@@ -146,6 +142,11 @@
   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L""|VOID*|0x001B
   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L""|VOID*|0x001C
 
+[PcdsFixedAtBuild.common,PcdsDynamic.common]
+  ## PL031 RealTimeClock
+  gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
+  gArmPlatformTokenSpaceGuid.PcdPL031RtcPpmAccuracy|3|UINT32|0x0022
+
 [PcdsFixedAtBuild.ARM]
   # Stack for CPU Cores in Secure Monitor Mode
   gArmPlatformTokenSpaceGuid.PcdCPUCoresSecMonStackBase|0|UINT32|0x0007
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 00/10] add support for AArch64 QEMU/KVM

[Ard Biesheuvel]

This is v3 of the series that adds a platform config to support QEMU based
virtual machines, either in TCG or KVM mode. These virtual machines declare
their platform  configuration by passing a device tree which needs to be parsed
by Tianocore rather than relying on hardcoded peripherals.

Currently, the only assumptions made with respect to the platform config are:
- at least 1 MB of DRAM at 0x4000_
- NOR flash at 0x0
- PL011 UART at 0x900_

Peripherals detected at runtime:
- GIC interrupt controller
- timer interrupt line
- PL031 RTC
- system memory base and size
- virtio MMIO transports

There are some dependencies on QEMU and KVM changes that are not yet upstream:
- QEMU: 'hw/arm/virt: Provide flash devices for boot ROMs'
- QEMU: copy DTB to base of DRAM if no -kernel option is passed
- KVM: 'arm/arm64: KVM: Support KVM_CAP_READONLY_MEM'
- KVM: 'arm/arm64: KVM: Complete WFI/WFE instructions'

Note that most of the patches are minor ones that make certain peripherals
configurable at runtime. The patch 'ArmPlatformPkg: add support for a
QEMU/mach-virt target' is the primary patch that implements most of the QEMU/KVM
interface logic, most notably parsing of the device tree to set PCDs containing
base addresses etc.

The code was tested in TCG mode on x64_64 and in TCG and KVM mode on a ARMv8
Foundation Model (software emulator)

Changes since v2:
- fixed *lots* of EDK2 Style Guide violations
- use EFI_D_ERROR only where appropriate
- use ASSERT()s to ensure we are running with at least 128 MB and not executing
  from shadowed NOR flash, and relocate the DTB device tree image earlier so
  we can be confident it does not get clobbered inadvertently
- handle 32-bit PCDs that may get initialized from 64-bit DT nodes more
  consistently, and don't abort the DT traversal if virtio transports fail to
  install

Changes since v1:
- rebased onto upstream GitHub tianocore/edk2.git (421ccda307)
- moved primary FV 0x1000 bytes into flash image, and added jump to it at 0x0
- dropped patch to allow FVs at physical offset 0x0
- dropped patch introducing device config table GUID, and used the upstream one
  instead (EmbeddedPkg/Include/Guid/Fdt.h)
- added 'Contributed-under:' lines to commit logs
- style fixes: remove redundant '== TRUE', add space between function and (
- updated/removed comments related to arch timer PCD and arch timer imask
- use feature PCD to define whether to use the virtual timer

*** BLURB HERE ***

Ard Biesheuvel (9):
  ArmPkg: allow dynamically discovered virtual timer interrupt
  ArmPkg: allow dynamic GIC base addresses
  ArmPlatformPkg/PrePeiCore: remove GIC related PCDs from unicore
  ArmPlatformPkg: allow dynamically discovered PL031 RTC
  ArmPkg,ArmPlatformPkg: allow dynamic PCDs for memory base and size
  ArmPkg: introduce PCD gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress
  ArmPlatformPkg: separate PlatformPei and PlatformPeiLib
  ArmPlatformPkg: add support for a QEMU/mach-virt target
  AArch64-KVM: add support for non-volatile variable store

Michael Casadevall (1):
  ArmPkg/TimerDxe: allow virtual timer to be selected

 ArmPkg/ArmPkg.dec  |  34 ++-
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf|   4 +-
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c  |  37 ++-
 ArmPkg/Drivers/TimerDxe/TimerDxe.c |  12 +-
 ArmPkg/Drivers/TimerDxe/TimerDxe.inf   |   4 +-
 ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c   |  74 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf   |   4 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf  |   3 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf|   3 +
 ArmPkg/Library/BdsLib/BdsLib.inf   |   5 +-
 .../AArch64Virtualization-KVM.dsc  | 236 +++
 .../AArch64Virtualization-KVM.fdf  | 309 +++
 .../AArch64Virtualization.dsc.inc  | 336 +
 .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  61 
 .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 249 +++
 .../Include/Platform/KVM/ArmPlatform.h |  33 ++
 .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  57 
 .../Library/AArch64VirtualizationLibKVM/KVM.c  | 143 +
 .../AArch64VirtualizationLibKVM/KVMHelper.S|  86 ++
 .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 102 +++
 .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
 .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 +++
 .../Library/NorFlashKVM/NorFlashKVM.c  |  63 
 .../Library/NorFlashKVM/NorFlashKVM.inf|  35 +++
 .../Library/PlatformPei/PlatformPeiLib.c   |  47 +++
 .../Library/PlatformPei/PlatformPeiLib.inf |  58 
 .../Library/ResetSystemLib/ResetSystemLib.c|  97 ++
 .../Library/ResetSystemLib/ResetSystemLib.inf  |  36 +++
 .../Library/ResetSystemLib/ResetSystemPsci.S   |  40 +++
 ArmPlatformPkg/ArmPlatform

[edk2] [PATCH v3 07/10] ArmPkg: introduce PCD gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress

[Ard Biesheuvel]

Introduce gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress, which will be used by
virtual machine ports that discover the system configuration from a flattened
device tree DTB image.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 43eff6641294..9408b321d45e 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -154,6 +154,8 @@
   gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum|26|UINT32|0x0040
   gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|27|UINT32|0x0041
 
+  gArmTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x0|UINT64|0x0042
+
 [PcdsFixedAtBuild.ARM]
   #
   # ARM Security Extension
-- 
1.8.3.2


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 03/10] ArmPkg: allow dynamic GIC base addresses

[Ard Biesheuvel]

Allow the PCDs gArmTokenSpaceGuid.PcdGicDistributorBase and
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase to be redeclared
as PcdsDynamic by the platform, so virtual machines can set these
properties during boot. As the PcdGet32() calls now call into the
PCD database, cache the values that are required during the handling
of interrupts.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec | 15 +++--
 ArmPkg/Drivers/ArmGic/ArmGicDxe.inf   |  4 +++-
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 37 ++-
 ArmPkg/Library/BdsLib/BdsLib.inf  |  2 +-
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 0392af52758f..e5ed445ca367 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -72,6 +72,14 @@
   # Whether to use the virtual rather than the physical architected timer
   gArmTokenSpaceGuid.PcdArmArchTimerUseVirtual|FALSE|BOOLEAN|0x003F
 
+[PcdsFixedAtBuild.common,PcdsDynamic.common]
+  #
+  # ARM Generic Interrupt Controller
+  #
+  gArmTokenSpaceGuid.PcdGicDistributorBase|0|UINT32|0x000C
+  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0|UINT32|0x000D
+  gArmTokenSpaceGuid.PcdGicSgiIntId|0|UINT32|0x0025
+
 [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdTrustzoneSupport|FALSE|BOOLEAN|0x0006
 
@@ -85,13 +93,6 @@
   gArmTokenSpaceGuid.PcdCpuResetAddress|0x|UINT32|0x0005
 
   #
-  # ARM Generic Interrupt Controller
-  #
-  gArmTokenSpaceGuid.PcdGicDistributorBase|0|UINT32|0x000C
-  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0|UINT32|0x000D
-  gArmTokenSpaceGuid.PcdGicSgiIntId|0|UINT32|0x0025
-
-  #
   # ARM Secure Firmware PCDs
   #
   gArmTokenSpaceGuid.PcdSecureFdBaseAddress|0|UINT32|0x0015
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
index 7dc14b34ec48..522b5a842dfd 100644
--- a/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+++ b/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
@@ -43,15 +43,17 @@
   MemoryAllocationLib
   UefiDriverEntryPoint
   IoLib
+  PcdLib
 
 [Protocols]
   gHardwareInterruptProtocolGuid
   gEfiCpuArchProtocolGuid
 
-[FixedPcd.common]
+[Pcd.common]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
 
+[FixedPcd.common]
   gArmTokenSpaceGuid.PcdArmPrimaryCore
 
 [Depex]
diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
index 5561de630d6e..3f9e37b5f2d8 100644
--- a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
@@ -29,6 +29,9 @@ Abstract:
 
 extern EFI_HARDWARE_INTERRUPT_PROTOCOL gHardwareInterruptV2Protocol;
 
+UINT32 mGicInterruptInterfaceBase;
+UINT32 mGicDistributorBase;
+
 /**
   Enable interrupt source Source.
 
@@ -51,7 +54,7 @@ GicV2EnableInterruptSource (
 return EFI_UNSUPPORTED;
   }
 
-  ArmGicEnableInterrupt (FixedPcdGet32 (PcdGicDistributorBase), Source);
+  ArmGicEnableInterrupt (mGicDistributorBase, Source);
 
   return EFI_SUCCESS;
 }
@@ -78,7 +81,7 @@ GicV2DisableInterruptSource (
 return EFI_UNSUPPORTED;
   }
 
-  ArmGicDisableInterrupt (FixedPcdGet32 (PcdGicDistributorBase), Source);
+  ArmGicDisableInterrupt (mGicDistributorBase, Source);
 
   return EFI_SUCCESS;
 }
@@ -107,7 +110,7 @@ GicV2GetInterruptSourceState (
 return EFI_UNSUPPORTED;
   }
 
-  *InterruptState = ArmGicIsInterruptEnabled (FixedPcdGet32 
(PcdGicDistributorBase), Source);
+  *InterruptState = ArmGicIsInterruptEnabled (mGicDistributorBase, Source);
 
   return EFI_SUCCESS;
 }
@@ -135,7 +138,7 @@ GicV2EndOfInterrupt (
 return EFI_UNSUPPORTED;
   }
 
-  ArmGicV2EndOfInterrupt (FixedPcdGet32 (PcdGicInterruptInterfaceBase), 
Source);
+  ArmGicV2EndOfInterrupt (mGicInterruptInterfaceBase, Source);
   return EFI_SUCCESS;
 }
 
@@ -160,7 +163,7 @@ GicV2IrqInterruptHandler (
   UINT32  GicInterrupt;
   HARDWARE_INTERRUPT_HANDLER  InterruptHandler;
 
-  GicInterrupt = ArmGicV2AcknowledgeInterrupt (FixedPcdGet32 
(PcdGicInterruptInterfaceBase));
+  GicInterrupt = ArmGicV2AcknowledgeInterrupt (mGicInterruptInterfaceBase);
 
   // Special Interrupts (ID1020-ID1023) have an Interrupt ID greater than the 
number of interrupt (ie: Spurious interrupt).
   if ((GicInterrupt & ARM_GIC_ICCIAR_ACKINTID) >= mGicNumInterrupts) {
@@ -216,7 +219,7 @@ GicV2ExitBootServicesEvent (
 
   // Acknowledge all pending interrupts
   do {
-GicInterrupt = ArmGicV2AcknowledgeInterrupt (FixedPcdGet32 
(PcdGicInterruptInterfaceBase));
+GicInterrupt = ArmGicV2AcknowledgeInterrupt (mGicInterruptInterfaceBase);
 
 if ((GicInterrupt & ARM_GIC_ICCIAR_ACKINTID) < mGicNumInterrupts) {
   GicV2EndOfInterrupt (&gHardwareInterruptV2Protocol, GicInterrupt);
@@ -224,10 +227,10 @@ GicV2ExitBootServicesEvent (
   } while (!ARM_GIC_IS_SPECIAL_INTERRUPTS (GicInterrupt));
 
   // Disable Gic Interface
-  Ar

[edk2] [PATCH v3 01/10] ArmPkg/TimerDxe: allow virtual timer to be selected

[Ard Biesheuvel]

From: Michael Casadevall 

For virtual machines, the physical architected timer may not be available,
so we need to allow the virtual timer to be used instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Casadevall 
Acked-by: Laszlo Ersek 
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec |  3 +
 ArmPkg/Drivers/TimerDxe/TimerDxe.c|  6 ++
 ArmPkg/Drivers/TimerDxe/TimerDxe.inf  |  4 +-
 ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c  | 74 +++
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf  |  4 ++
 ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf |  3 +
 ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf   |  3 +
 7 files changed, 84 insertions(+), 13 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index a8ca28fccc82..c2551d7c3307 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -69,6 +69,9 @@
   # Linux (instead of PSCI)
   gArmTokenSpaceGuid.PcdArmLinuxSpinTable|FALSE|BOOLEAN|0x0033
 
+  # Whether to use the virtual rather than the physical architected timer
+  gArmTokenSpaceGuid.PcdArmArchTimerUseVirtual|FALSE|BOOLEAN|0x003F
+
 [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdTrustzoneSupport|FALSE|BOOLEAN|0x0006
 
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
index 633876bea6bd..9227be8326b0 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
@@ -347,6 +347,12 @@ TimerInitialize (
   // Note: Because it is not possible to determine the security state of the
   // CPU dynamically, we just install interrupt handler for both sec and 
non-sec
   // timer PPI
+  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
+  ASSERT_EFI_ERROR (Status);
+
+  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
+  ASSERT_EFI_ERROR (Status);
+
   Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
   ASSERT_EFI_ERROR (Status);
 
diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.inf 
b/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
index 50477ba42a7a..98b09ba8d203 100644
--- a/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.inf
@@ -52,7 +52,9 @@
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod
   gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
   gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz
+  gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz  
 
 [Depex]
   gHardwareInterruptProtocolGuid
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
index fa4f7c741b15..f7ef69d5d4c1 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c
@@ -175,9 +175,25 @@ ArmArchTimerEnableTimer (
 {
   UINTN TimerCtrlReg;
 
-  ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
-  TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
-  ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  if (FeaturePcdGet (PcdArmArchTimerUseVirtual)) {
+ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
+
+/*
+ * When running under KVM, we need to unmask the interrupt on the timer 
side
+ * as KVM will mask it when servicing the interrupt at the hypervisor level
+ * and delivering the virtual timer interrupt to the guest. Otherwise, the
+ * interrupt will fire again, trapping into the hypervisor again, etc. etc.
+ * This is scheduled to be fixed on the KVM side, but there is no harm in
+ * leaving this in once KVM gets fixed.
+ */
+TimerCtrlReg &= ~ARM_ARCH_TIMER_IMASK;
+ArmArchTimerWriteReg (CntvCtl, (VOID *)&TimerCtrlReg);
+  } else {
+ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  }
 }
 
 VOID
@@ -188,9 +204,15 @@ ArmArchTimerDisableTimer (
 {
   UINTN TimerCtrlReg;
 
-  ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
-  TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
-  ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  if (FeaturePcdGet (PcdArmArchTimerUseVirtual)) {
+ArmArchTimerReadReg (CntvCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntvCtl, (VOID *)&TimerCtrlReg);
+  } else {
+ArmArchTimerReadReg (CntpCtl, (VOID *)&TimerCtrlReg);
+TimerCtrlReg &= ~ARM_ARCH_TIMER_ENABLE;
+ArmArchTimerWriteReg (CntpCtl, (VOID *)&TimerCtrlReg);
+  }
 }
 
 VOID
@@ -220,7 +242,12 @@ ArmArchTimerGetTimerVal (
 )
 {
   UINTN ArchTimerVal;
-  ArmArchTimerReadReg (CntpTval, (VOID *)&ArchTimerVal);
+  if (Fea

[edk2] Bug in EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE

[Alexei Fedorov]

EFI_ACPI_5_1_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE declaration in 
\edk2\MdePkg\Include\IndustryStandard\Acpi51.h has wrong field lengths:



///

/// SBSA Generic Watchdog Structure

///

typedef struct {

  UINT8   Type;

  UINT8   Length;

  UINT16  Reserved;

...



This should be



typedef struct {

  UINT8   Type;

  UINT16  Length;

  UINT8   Reserved;

...



According to Table 5-123 SBSA Generic Watchdog Structure Format of ACPI 5.1 
Specification on p.197:



FieldByte Length Byte Offset Description

Type 1   0   0x1 Watchdog GT

Length   2   1   28

Reserved 1   3   Must be zero



Alexei.



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/8] NASM: Object files; Thunk16; Require for non-MSVC

[Sergey Isakov]

Hi sirs,
I tested Thunk16.nasm too. For x86_64 there is no issue.
For ia32 compilation disasm shows not good codes
-
 :
   0:   00 00   add%al,(%eax)
   2:   00 00   add%al,(%eax)
...

0006 <_BackFromUserCode>:
   6:   16  push   %ss
   7:   0e  push   %cs
   8:   67 e8 00 00 66 9c   addr16 call 9c66000e 


000c <_BackFromUserCode.Base>:
   c:   66 9c   pushfw 
   e:   fa  cli

-
to compare gcc-4.9.1 cvompilation
-
 :
   0:   00 00   add%al,(%eax)
   2:   00 00   add%al,(%eax)
...

0006 :
   6:   16  push   %ss
   7:   0e  push   %cs
   8:   66 e8 00 00 callw  c 
...

000e :
   e:   66 9c   pushfw 
  10:   fa  cli

--
May be change a32 prefix to o32 in the line:
"a32 call.Base   ; push eip"
?

Wishes,
Sergey

On 27.08.2014, at 9:50, Jordan Justen wrote:

> On Tue, Aug 19, 2014 at 4:57 PM, Jordan Justen
>  wrote:
>> This series:
>> * Adds support for creating object files from .nasm source files to
>>   allow NASM source files to be linked into libraries and images
>> * Adds NASM source files for Thunk16 on IA32 and X64
>> * Convert BaseLib to use NASM Source Files for Thunk16 rather than
>>   GNU Assembler (.S) files
>>   - This will make NASM a build requirement for MdePkg with IA32 &
>> X64 on all toolchains except MSVC and ICC.
>> 
>> Thanks for Liming Gao for the tools_def changes for MSVC. (But, these
>> have not been tested very well yet.)
>> 
>> This series is available in this git branch:
>> https://github.com/jljusten/edk2.git nasm-v1
> 
> I update my nasm branch based on the feedback.
> 
> The differences vs. v1 are in the attached patch.
> 
> Is anyone interested in seeing a v2 posted to the list?
> 
> Liming, in patch 1, I mentioned I only tested with GCC49. Did you have
> any testing to add to that?
> 
> -Jordan
> 
>> Jordan Justen (8):
>>  BaseTools/tools_def: Add NASM_FLAGS
>>  BaseTools/build_rule: Add .nasm => .obj build rule
>>  MdePkg/Base.h: Always define ASM_PFX
>>  MdePkg/BaseLib Thunk16: Replace IA32 GAS Thunk16 with NASM version
>>  MdePkg/BaseLib Thunk16: Replace X64 GAS Thunk16 with NASM version
>>  MdePkg/BaseLib NASM Thunk16: Use NASM local labels
>>  MdePkg/BaseLib NASM Thunk16: Use bits 16 for 16-bit code
>>  MdePkg/BaseLib NASM Thunk16: Remove remaining 'DB' code
>> 
>> BaseTools/Conf/build_rule.template   |  15 ++
>> BaseTools/Conf/tools_def.template| 287 ++-
>> MdePkg/Include/AArch64/ProcessorBind.h   |   4 +
>> MdePkg/Include/Arm/ProcessorBind.h   |   4 +
>> MdePkg/Include/Base.h|  25 ++-
>> MdePkg/Include/Ebc/ProcessorBind.h   |   4 +
>> MdePkg/Include/Ia32/ProcessorBind.h  |   4 +
>> MdePkg/Include/Ipf/ProcessorBind.h   |   4 +
>> MdePkg/Include/X64/ProcessorBind.h   |   4 +
>> MdePkg/Library/BaseLib/BaseLib.inf   |   4 +-
>> MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 260 +
>> MdePkg/Library/BaseLib/X64/Thunk16.nasm  | 321 
>> +++
>> 12 files changed, 914 insertions(+), 22 deletions(-)
>> create mode 100644 MdePkg/Library/BaseLib/Ia32/Thunk16.nasm
>> create mode 100644 MdePkg/Library/BaseLib/X64/Thunk16.nasm
>> 
>> --
>> 2.1.0
>> 
>> 
>> --
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> --
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

On 27 August 2014 13:53, Laszlo Ersek  wrote:
> On 08/27/14 13:12, Ard Biesheuvel wrote:
>> On 27 August 2014 12:36, Laszlo Ersek  wrote:
>>> On 08/27/14 11:35, Ard Biesheuvel wrote:
 On 27 August 2014 11:07, Laszlo Ersek  wrote:
> On 08/27/14 09:10, Ard Biesheuvel wrote:
>> On 27 August 2014 00:24, Laszlo Ersek  wrote:
>>>
>>> (b) Predictably, my second question is about the second world. The
>>> permanent PEI memory must be distinct from the DTB.
>>>
>>> InitializeMemory() calculates where to place the permanent PEI memory.
>>> The permanent PEI memory does not cover the entire system RAM. It's
>>> (calculated) base address is UefiMemoryBase, and it's size comes from
>>> PcdSystemMemoryUefiRegionSize (64MB, see the next patch).
>>>
>>
>> Yes, so running with 64 MB will result in this region colliding with the 
>> DTB.
>
> Right.
>
> Note that this question can be short-circuited by a list of guarantees,
> for example:
> - the firmware volume will always (or never) be shadowed from flash to
>   system RAM (--> because this helps us see which outer branch in
>   InitializeMemory() will be taken),
> - and we'll never boot a guest with less than 128 MB RAM (--> this
>   determines the inner branch, and given the size of the firmware
>   volume, allows deducing the exact location of the permanent PEI RAM)
>
> If we can guarantee such things, I'm completely fine with that as an 
> answer.
>

 OK, so by shadowing in this context, you mean invoking QEMU in such a
 way that the UEFI image is preloaded into DRAM?
>>>
>>> No. What I mean is the following. In edk2 you can build flash images (FD
>>> files) that contain various firmware volumes. A firmware volume's FFS
>>> (firmware volume file system) may contain an LZMA compressed file that
>>> is itself a firmware volume, after decompression.
>>>
>>> When your platform starts up, the reset vector and SEC run from flash.
>>> On some platforms, SEC locates these compressed FFS files in the initial
>>> boot firmware volume (mapped into flash), and decompresses them to
>>> system RAM. Thereby creating "shadowed" firmware volumes.
>>>
>>> I have no clue how this looks on the ARM platforms, but it's not
>>> something that changes from run to run. It's a design choice that is
>>> reflected in the FDF file, and the SEC code. If you just instrument
>>> these branches in question with a few DEBUG() calls, you'll see what the
>>> case is for this new platform.
>>>
>>> We "agreed" that PcdSystemMemoryInitializeInSec would be FALSE in our
>>> case. Given that SEC doesn't initialize the system memory, it's hard to
>>> imagine it would decompress firmware volumes to it. Hence I expect your
>>> debug messages should prove that there's no shadowing here. (Actually
>>> you might be able to deduce that statically, by tracking down
>>> PcdFdBaseAddress.)
>>>
>>
>> Looking the the logs, the first module that executed from DRAM is
>> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll,
>> everything before that is executed in place from NOR.
>>
>> So something like this should do the trick then?
>>
>> in ArmPlatformInitialize():
>>   ASSERT (!FeaturePcdGet (PcdSystemMemoryInitializeInSec));
>
> I can't immediately see where ArmPlatformInitialize() is called. If this
> ASSERT() runs before we enter InitializeMemory(), then it's fine.
>

It is called from CEntryPoint () in
ArmPlatformPkg/PrePeiCore/PrePeiCore.c, so that should be ok.

>>
>> and in ArmPlatformInitializeSystemMemory():
>>   ASSERT (NewSize >= SIZE_128MB);
>
> Seems OK.
>
>>   ASSERT (PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) < NewBase ||
>>   PcdGet32 (PcdFdBaseAddress) > NewBase + NewSize);
>>
>> (with comments describing the rationale, of course)
>
> Ah okay, these would assert that the FV and the system DRAM do not overlap.
>
> Seems good, but equality should be allowed in both expressions. You
> compare exclusive high limits against inclusive low limits, *plus*
> PcdFdSize is nonzero.
>
> If the first expression holds (with the proposed <=):
>
>   PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) <= NewBase
>
> Then that implies
>
>   PcdGet32 (PcdFdBaseAddress)<  NewBase
>
> which is exactly the negative of InitializeMemory()'s
>
>   FdBase >= SystemMemoryBase
>
>
> Similarly, if the second one holds (with the proposed >=):
>
>   PcdGet32 (PcdFdBaseAddress) >= NewBase + NewSize
>
> then that implies
>
>  PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize)
>   >  PcdGet32 (PcdFdBaseAddress)
>   >= NewBase + NewSize
>
> ie.
>
>   PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) > NewBase + NewSize
>
> which is exactly the negative of InitializeMemory()'s
>
>   FdTop  <= SystemMemoryTop
>
>
> So, yes these are 

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Laszlo Ersek]

On 08/27/14 13:12, Ard Biesheuvel wrote:
> On 27 August 2014 12:36, Laszlo Ersek  wrote:
>> On 08/27/14 11:35, Ard Biesheuvel wrote:
>>> On 27 August 2014 11:07, Laszlo Ersek  wrote:
 On 08/27/14 09:10, Ard Biesheuvel wrote:
> On 27 August 2014 00:24, Laszlo Ersek  wrote:
>>
>> (b) Predictably, my second question is about the second world. The
>> permanent PEI memory must be distinct from the DTB.
>>
>> InitializeMemory() calculates where to place the permanent PEI memory.
>> The permanent PEI memory does not cover the entire system RAM. It's
>> (calculated) base address is UefiMemoryBase, and it's size comes from
>> PcdSystemMemoryUefiRegionSize (64MB, see the next patch).
>>
>
> Yes, so running with 64 MB will result in this region colliding with the 
> DTB.

 Right.

 Note that this question can be short-circuited by a list of guarantees,
 for example:
 - the firmware volume will always (or never) be shadowed from flash to
   system RAM (--> because this helps us see which outer branch in
   InitializeMemory() will be taken),
 - and we'll never boot a guest with less than 128 MB RAM (--> this
   determines the inner branch, and given the size of the firmware
   volume, allows deducing the exact location of the permanent PEI RAM)

 If we can guarantee such things, I'm completely fine with that as an 
 answer.

>>>
>>> OK, so by shadowing in this context, you mean invoking QEMU in such a
>>> way that the UEFI image is preloaded into DRAM?
>>
>> No. What I mean is the following. In edk2 you can build flash images (FD
>> files) that contain various firmware volumes. A firmware volume's FFS
>> (firmware volume file system) may contain an LZMA compressed file that
>> is itself a firmware volume, after decompression.
>>
>> When your platform starts up, the reset vector and SEC run from flash.
>> On some platforms, SEC locates these compressed FFS files in the initial
>> boot firmware volume (mapped into flash), and decompresses them to
>> system RAM. Thereby creating "shadowed" firmware volumes.
>>
>> I have no clue how this looks on the ARM platforms, but it's not
>> something that changes from run to run. It's a design choice that is
>> reflected in the FDF file, and the SEC code. If you just instrument
>> these branches in question with a few DEBUG() calls, you'll see what the
>> case is for this new platform.
>>
>> We "agreed" that PcdSystemMemoryInitializeInSec would be FALSE in our
>> case. Given that SEC doesn't initialize the system memory, it's hard to
>> imagine it would decompress firmware volumes to it. Hence I expect your
>> debug messages should prove that there's no shadowing here. (Actually
>> you might be able to deduce that statically, by tracking down
>> PcdFdBaseAddress.)
>>
> 
> Looking the the logs, the first module that executed from DRAM is
> Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll,
> everything before that is executed in place from NOR.
> 
> So something like this should do the trick then?
> 
> in ArmPlatformInitialize():
>   ASSERT (!FeaturePcdGet (PcdSystemMemoryInitializeInSec));

I can't immediately see where ArmPlatformInitialize() is called. If this
ASSERT() runs before we enter InitializeMemory(), then it's fine.

> 
> and in ArmPlatformInitializeSystemMemory():
>   ASSERT (NewSize >= SIZE_128MB);

Seems OK.

>   ASSERT (PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) < NewBase ||
>   PcdGet32 (PcdFdBaseAddress) > NewBase + NewSize);
> 
> (with comments describing the rationale, of course)

Ah okay, these would assert that the FV and the system DRAM do not overlap.

Seems good, but equality should be allowed in both expressions. You
compare exclusive high limits against inclusive low limits, *plus*
PcdFdSize is nonzero.

If the first expression holds (with the proposed <=):

  PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) <= NewBase

Then that implies

  PcdGet32 (PcdFdBaseAddress)<  NewBase

which is exactly the negative of InitializeMemory()'s

  FdBase >= SystemMemoryBase


Similarly, if the second one holds (with the proposed >=):

  PcdGet32 (PcdFdBaseAddress) >= NewBase + NewSize

then that implies

 PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize)
  >  PcdGet32 (PcdFdBaseAddress)
  >= NewBase + NewSize

ie.

  PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) > NewBase + NewSize

which is exactly the negative of InitializeMemory()'s

  FdTop  <= SystemMemoryTop


So, yes these are good, but you should also allow equality.

The comments would be appreciated.

> The only thing that still needs some consideration is whether to allow
> NewBase to be different from 0x4000_. It kind of complicates the
> logic, and for no obvious gain, so I should probably add an asse

Re: [edk2] [PATCH v2 7/8] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Laszlo Ersek]

On 08/27/14 10:27, Ard Biesheuvel wrote:
> On 27 August 2014 01:36, Laszlo Ersek  wrote:
>> On 08/26/14 15:03, Ard Biesheuvel wrote:

>>> +#pragma pack (1)
>>> +typedef struct {
>>> +  VENDOR_DEVICE_PATH  Vendor;
>>> +  UINT32  Instance;
>>> +  EFI_DEVICE_PATH_PROTOCOLEnd;
>>> +} VIRTIO_BLK_DEVICE_PATH;
>>> +#pragma pack ()
>>
>> Ugh. :)
>>
>> Have you seen my earlier patches where the vendor device path node
>> corresponding to a virtio-mmio transport actually included the base
>> address of the MMIO register block? I think such a hwvendor devpath node
>> is much more useful; it can actually help you debug.
>>
> 
> I will just stick a EFI_PHYSICAL_ADDRESS in there instead, or would
> you prefer UINT64?

UINT64 sounds good.

>>> +  FdtImageData = AllocatePages (EFI_SIZE_TO_PAGES (fdt_totalsize 
>>> (MemoryBase)));
>>
>> What's wrong with AllocatePool()? Does the EFI stub require full pages,
>> and page alignment?
>>
> 
> No, AllocatePool() should be fine.

OK.

Tying back to the other patch's discussion, I've already mentioned
AllocateCopyPool(). It's a nice convenience function that can save you a
separate call to CopyMem().

(Independently, we should be very clear that the
AllocatePages()/AllocatePool() calls discussed here, vs. the one that
you'll add to the platform PEI, are *very* different. They are from the
same MemoryAllocationLib library class, but the library instances in
question are specific to the UEFI phase:

- MdePkg/Library/PeiMemoryAllocationLib/
- MdePkg/Library/UefiMemoryAllocationLib/

The former is ultimately backed by HOB creation, while the latter is
backed by a UEFI boot service.

So, you'll remove this DTB relocation from DXE completely, and do it in
the platform PEIM instead (either with in-place coverage, or real
relocation to permanent PEI RAM, with AllocateCopyPool()).)

> I will check the logic carefully. What should happen is that the
> traversal of the device tree should proceed, so other peripherals are
> detected and installed even if the virtio transports are not.

Sounds great. Actually, I think we should keep whatever virtio-mmio
transports we managed to install as well; it's not like there's some
inter-dependency between virtio devices. Whatever works is likely useful
in isolation too.

>>> +  break;
>>> +
>>> +case GIC:
>>> +  ASSERT (Len == 32);
>>> +
>>> +  DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
>>> +  CpuBase = fdt64_to_cpu (((UINT64 *)RegProp)[2]);
>>> +  PcdSet32 (PcdGicDistributorBase, DistBase);
>>> +  PcdSet32 (PcdGicInterruptInterfaceBase, CpuBase);
>>
>> DistBase and CpuBase are UINT32s, matching the PCDs, but they don't
>> match the FDT (UINT64). Is that okay?
>>
> 
> Well, it is highly unlikely that peripherals like GIC would be moved
> beyond 4 GB in the physical address space, and the device tree just
> uses 64-bit addresses in this instantiation, so for now, I think this
> is fine. Otherwise, we should update the GIC driver to use UINT64
> instead.

Alright. Please either add an assert, or just a small comment, for the
uninitiated like me :)

[snip]

Thanks
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

On 27 August 2014 12:36, Laszlo Ersek  wrote:
> On 08/27/14 11:35, Ard Biesheuvel wrote:
>> On 27 August 2014 11:07, Laszlo Ersek  wrote:
>>> On 08/27/14 09:10, Ard Biesheuvel wrote:
 On 27 August 2014 00:24, Laszlo Ersek  wrote:
>
> (b) Predictably, my second question is about the second world. The
> permanent PEI memory must be distinct from the DTB.
>
> InitializeMemory() calculates where to place the permanent PEI memory.
> The permanent PEI memory does not cover the entire system RAM. It's
> (calculated) base address is UefiMemoryBase, and it's size comes from
> PcdSystemMemoryUefiRegionSize (64MB, see the next patch).
>

 Yes, so running with 64 MB will result in this region colliding with the 
 DTB.
>>>
>>> Right.
>>>
>>> Note that this question can be short-circuited by a list of guarantees,
>>> for example:
>>> - the firmware volume will always (or never) be shadowed from flash to
>>>   system RAM (--> because this helps us see which outer branch in
>>>   InitializeMemory() will be taken),
>>> - and we'll never boot a guest with less than 128 MB RAM (--> this
>>>   determines the inner branch, and given the size of the firmware
>>>   volume, allows deducing the exact location of the permanent PEI RAM)
>>>
>>> If we can guarantee such things, I'm completely fine with that as an answer.
>>>
>>
>> OK, so by shadowing in this context, you mean invoking QEMU in such a
>> way that the UEFI image is preloaded into DRAM?
>
> No. What I mean is the following. In edk2 you can build flash images (FD
> files) that contain various firmware volumes. A firmware volume's FFS
> (firmware volume file system) may contain an LZMA compressed file that
> is itself a firmware volume, after decompression.
>
> When your platform starts up, the reset vector and SEC run from flash.
> On some platforms, SEC locates these compressed FFS files in the initial
> boot firmware volume (mapped into flash), and decompresses them to
> system RAM. Thereby creating "shadowed" firmware volumes.
>
> I have no clue how this looks on the ARM platforms, but it's not
> something that changes from run to run. It's a design choice that is
> reflected in the FDF file, and the SEC code. If you just instrument
> these branches in question with a few DEBUG() calls, you'll see what the
> case is for this new platform.
>
> We "agreed" that PcdSystemMemoryInitializeInSec would be FALSE in our
> case. Given that SEC doesn't initialize the system memory, it's hard to
> imagine it would decompress firmware volumes to it. Hence I expect your
> debug messages should prove that there's no shadowing here. (Actually
> you might be able to deduce that statically, by tracking down
> PcdFdBaseAddress.)
>

Looking the the logs, the first module that executed from DRAM is
Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll,
everything before that is executed in place from NOR.

So something like this should do the trick then?

in ArmPlatformInitialize():
  ASSERT (!FeaturePcdGet (PcdSystemMemoryInitializeInSec));

and in ArmPlatformInitializeSystemMemory():
  ASSERT (NewSize >= SIZE_128MB);
  ASSERT (PcdGet32 (PcdFdBaseAddress) + PcdGet32 (PcdFdSize) < NewBase ||
  PcdGet32 (PcdFdBaseAddress) > NewBase + NewSize);

(with comments describing the rationale, of course)

The only thing that still needs some consideration is whether to allow
NewBase to be different from 0x4000_. It kind of complicates the
logic, and for no obvious gain, so I should probably add an assert for
that as well.

>> I don't think there is
>> any point at all in doing that, so I don't see why we should support
>> it. And having at least 128 MB of DRAM is reasonable as well.
s
> I agree that requiring at least 128 MB of DRAM is reasonable.
>
>> So I could perhaps enforce these rules in the same place the system
>> DRAM is discovered from the DTB?
>
> You mean your implementation of ArmPlatformInitializeSystemMemory().
>
> Yes, that would be reasonable. You can assert there that the size of the
> system DRAM is at least 128 MB.
>
> The idea is that by controlling all of the circumstances (system DRAM
> size, PcdFdBaseAddress, PcdFdSize, PcdSystemMemoryInitializeInSec), you
> would *force* InitializeMemory() to a pre-determined path.
>
> This would then protect the DTB.
>

As above

> (c) Third, before we enter DXE (and after we installed permanent PEI
> memory), we must ensure that DXE won't trample on the DTB.
>
> This is possible in two ways. First, don't install a memory resource
> descriptor HOB in MemoryPeim() that would cover the DTB. (This is very
> unlikely to work if the DTB's range is otherwise covered by the full
> system memory, as reported in the DTB's own self.)
>
> Second (the canonical way), create a memory allocation HOB (with the
> BuildMemoryAllocationHob() function of HobLib) that covers the DTB. This
> way, DXE will cr

Re: [edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on SataController

[Zeng, Star]

DUET platform is a emulate platform that has chipset and platform specific 
initialization done before its boot. SataControllerDxe was introduced for it to 
support AHCI mode. Now OVMF is a virtual platform that wants to leverage the 
SataControllerDxe in DuetPkg. And sharing code is a good point in EDK2 and 
other projects I think.

But the real hardware platforms all I worked and am working on have their own 
SataControllerDxe driver with some chipset specific policies or platform 
configurations, for example, policy to control how many ports to be exposed, 
specific timing configurations, only support specific vendor's controllers, and 
etc.

If for only sharing between DUET and OVMF, the SataControllerDxe is to be into 
PcAtChipsetPkg that is a common package, but all the real platform code bases 
will have an unused SataControllerDxe since they have their own. I don't think 
it is good. I agree Feng's suggestion to have a SataController copy in OVMF, at 
least for now. If more and more emulate and virtual platforms or even real 
platforms are going to share the SataControllerDxe implementation in future, 
then we can have discussion to move it into a common package.


Thanks,
Star
-Original Message-
From: Reza Jelveh [mailto:reza.jel...@tuhh.de] 
Sent: Thursday, August 21, 2014 12:10 AM
To: Tian, Feng
Cc: edk2-devel@lists.sourceforge.net; ag...@suse.de
Subject: Re: [edk2] [PATCH 4/6] MdeModulePkg: IdeMode should not depend on 
SataController


On 18/08/14 00:25, Tian, Feng wrote:
> Hi, Reza
> 
> I don't get your meaning about " the ChannelCount is initialized too early ". 
> These drivers are UEFI driver binding drivers, which means they get 
> initialized by pre-assigned order.
I fixed the IDE issue. ChannelCount too early means the following(unless I 
misunderstanding something):

The controller Start is called after AtaAtapiPassThruSupported opens the 
ideinit protocol.

SataController is an extremely misleading name. SataController and 
IdeController are just implementing the init protocol.

For ide the channel count is not detected, but defined inside of idecontroller 
or satacontroller. Currently to IdeMax which is 2.

The channelcount for ahci however is loaded from the cap register. The cap 
register needs ahci to be initialized. If AhciMode is not initialized the cap 
register read in SataController->Start returns 0. If you initialize AhciMode in 
the start of SataController ahcimode initialization will subsequently fail.

I have addressed the issue you had with removing the IdeInit.ChannelCount and 
will post a new patch, but I can frankly not imagine a single instance where 
the ide controller would actually define that to be 1.

When I say loaded too early I'm saying that, because SataControllerStart does 
memory allocations which are later used as an optimization to reduce hardware 
ops. But those memory allocations are based on ChannelCount which is only known 
after ahcimode is initialized.

> 
> Why we did put SataController Driver at DuetPkg before rather than at 
> PcAtChipsetPkg is because it's a platform driver and may vary at different 
> platforms with different configurations. 
> 
> So I don't think moving SataController driver from Duet to PcAtChipsetPkg is 
> a good idea. If you want to enable Ovmf, I would like to suggest you 
> implement a similar on in Ovmf platform package.

I completely disagree. SataController implements so basic a functionality that 
I don't see why it was duetpkg only to begin with. I see different projects 
using SataController for different hardware. Why would we copy the exact same 
over to Ovmf?

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Laszlo Ersek]

On 08/27/14 11:35, Ard Biesheuvel wrote:
> On 27 August 2014 11:07, Laszlo Ersek  wrote:
>> On 08/27/14 09:10, Ard Biesheuvel wrote:
>>> On 27 August 2014 00:24, Laszlo Ersek  wrote:

 (b) Predictably, my second question is about the second world. The
 permanent PEI memory must be distinct from the DTB.

 InitializeMemory() calculates where to place the permanent PEI memory.
 The permanent PEI memory does not cover the entire system RAM. It's
 (calculated) base address is UefiMemoryBase, and it's size comes from
 PcdSystemMemoryUefiRegionSize (64MB, see the next patch).

>>>
>>> Yes, so running with 64 MB will result in this region colliding with the 
>>> DTB.
>>
>> Right.
>>
>> Note that this question can be short-circuited by a list of guarantees,
>> for example:
>> - the firmware volume will always (or never) be shadowed from flash to
>>   system RAM (--> because this helps us see which outer branch in
>>   InitializeMemory() will be taken),
>> - and we'll never boot a guest with less than 128 MB RAM (--> this
>>   determines the inner branch, and given the size of the firmware
>>   volume, allows deducing the exact location of the permanent PEI RAM)
>>
>> If we can guarantee such things, I'm completely fine with that as an answer.
>>
> 
> OK, so by shadowing in this context, you mean invoking QEMU in such a
> way that the UEFI image is preloaded into DRAM?

No. What I mean is the following. In edk2 you can build flash images (FD
files) that contain various firmware volumes. A firmware volume's FFS
(firmware volume file system) may contain an LZMA compressed file that
is itself a firmware volume, after decompression.

When your platform starts up, the reset vector and SEC run from flash.
On some platforms, SEC locates these compressed FFS files in the initial
boot firmware volume (mapped into flash), and decompresses them to
system RAM. Thereby creating "shadowed" firmware volumes.

I have no clue how this looks on the ARM platforms, but it's not
something that changes from run to run. It's a design choice that is
reflected in the FDF file, and the SEC code. If you just instrument
these branches in question with a few DEBUG() calls, you'll see what the
case is for this new platform.

We "agreed" that PcdSystemMemoryInitializeInSec would be FALSE in our
case. Given that SEC doesn't initialize the system memory, it's hard to
imagine it would decompress firmware volumes to it. Hence I expect your
debug messages should prove that there's no shadowing here. (Actually
you might be able to deduce that statically, by tracking down
PcdFdBaseAddress.)

> I don't think there is
> any point at all in doing that, so I don't see why we should support
> it. And having at least 128 MB of DRAM is reasonable as well.

I agree that requiring at least 128 MB of DRAM is reasonable.

> So I could perhaps enforce these rules in the same place the system
> DRAM is discovered from the DTB?

You mean your implementation of ArmPlatformInitializeSystemMemory().

Yes, that would be reasonable. You can assert there that the size of the
system DRAM is at least 128 MB.

The idea is that by controlling all of the circumstances (system DRAM
size, PcdFdBaseAddress, PcdFdSize, PcdSystemMemoryInitializeInSec), you
would *force* InitializeMemory() to a pre-determined path.

This would then protect the DTB.

 (c) Third, before we enter DXE (and after we installed permanent PEI
 memory), we must ensure that DXE won't trample on the DTB.

 This is possible in two ways. First, don't install a memory resource
 descriptor HOB in MemoryPeim() that would cover the DTB. (This is very
 unlikely to work if the DTB's range is otherwise covered by the full
 system memory, as reported in the DTB's own self.)

 Second (the canonical way), create a memory allocation HOB (with the
 BuildMemoryAllocationHob() function of HobLib) that covers the DTB. This
 way, DXE will create a memory *space* map (== hw properties map), based
 on MemoryPeim()'s memory resource descriptor HOBs, that covers the DTB;
 but seeing the memory allocation HOB, DXE will also start with a UEFI
 memory map (== sw properties map) that already lists the DTB as covered.
 This way DXE will steer clear of that memory range.

>> In short,
>>
>>   EFI_PHYSICAL_ADDRESS Base;
>>   UINTNFdtSize;
>>
>>   Base = PcdGet64 (PcdSystemMemoryBase);
>>   FdtSize = fdt_totalsize ((VOID *)(UINTN)Base);
>>
>>   BuildMemoryAllocationHob (
>> Base,
>> EFI_PAGES_TO_SIZE (EFI_SIZE_TO_PAGES (FdtSize)),
>> EfiBootServicesData
>> );
>>
>> would be correct. No need for relocation or for a later AllocatePages()
>> call. This would answer the third question, and you could link the DTB
>> at 0x4000_ into the config table directly.
>>
> 
> Indeed.
> 
> The only problem is the following: the EFI stub relocates the DTB to
> somewhere higher up in memory (it needs to add and modify entries, and

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

[Paolo Bonzini]

Il 26/08/2014 18:49, Laszlo Ersek ha scritto:
> The problem is that a number of tables are not linked into the RSDT,
> they are referenced by other tables. Basically, all the pointer fields
> in all tables that are updated (relocated / absolutized) by AddPointer
> commands, point *potentially* to further ACPI tables.

Right, the FADT's pointers to FACS and DSDT are an exception.  But are
there others?  And you don't really care about _where_ the tables are,
just if they are there, and you know that FACS+DSDT are always provided
by QEMU.

> 
> The above would mean two things at the same time:
> - precisely the ACPI knowledge that the linker/loader interface is
> supposed to obviate in the firmware,
> - precisely the ACPI knowledge that the current implementation of
> EFI_ACPI_TABLE_PROTOCOL encodes, and updates from time to time, when
> some new table is standardized (or when something already standardized
> breaks simply due to bugs).

Yes, this is unfortunate.  But I still believe that all you need to know
is the format of the RSDT/XSDT.

Is it possible to at least provide a *dummy* implementation of the ACPI
table protocol, that returns an error?  This would avoid weird
situations where booting from iSCSI breaks CPU hotplug or something like
that.

Paolo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

On 27 August 2014 11:07, Laszlo Ersek  wrote:
> On 08/27/14 09:10, Ard Biesheuvel wrote:
>> On 27 August 2014 00:24, Laszlo Ersek  wrote:
>>> On 08/26/14 15:03, Ard Biesheuvel wrote:
 This changes the definition and a bunch of references to
 gArmTokenSpaceGuid.PcdSystemMemoryBase and
 gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic 
 PCDs
 by the platform. Also, move the non-SEC call to
 ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to 
 set
 these PCDs before they are first referenced.

 The purpose is allowing dynamically instantiated virtual machines to 
 declare
 the system memory by passing a device tree.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel 
 ---
>> [...]
>>>
>>> I spent several hours pondering this patch (and the next one).
>>>
>>> The most important question (for me) concerns the lifecycle of the DTB,
>>> which has been placed by QEMU at 0x4000_. In the following I'll
>>> first try to gather a few impressions, then I'll ask my questions.
>>>
>>
>> First of all, let me clarify that I was aware that this range needed
>> some protection in some way, and I was currently getting away with the
>> DTB surviving by luck.
>
> Alright, good to know that you knew, thanks!
>
>> Ideally, the install configuration table should be performed as early
>> as possible, and the subsequent references of the device tree should
>> find it using the config table GUID.
>> But before that, we need something else, indeed.
>
> Right. InstallConfigurationTable() is a UEFI boot service, you can't use
> it before DXE. In addition, that service really only adds a (GUID,
> pointer) pair to the list of config tables, so the pointed-to area must
> be preserved / secured even in DXE by separate means.
>
>> So you mention that passing it in DRAM is perhaps not the best way to
>> go about this. Could you elaborate a bit
>
> Sure. Peter didn't like this (for ARM / mach virt), but the fw_cfg
> mechanism seen on the x86_64 target would be one alternative. Basically
> you have two ioports, one for writing selector values into, and another
> to read data from. ARM doesn't have ioports, but this could be done with
> MIIO registers as well. (The guest code would do volatile reads and writes.)
>
> Since this would "host" the DTB in something different than emulated
> system RAM, the DTB could not, by nature, overlap with any part of the
> system RAM.
>
> The current approach is workable as well (ie. DTB copied by QEMU into
> guest RAM upfront), it just needs more protection in the guest fw code.
>

OK, let's keep that as a working assumption then, at least for now ...

> [snip]
>
>>> (a) My first question is what protects the DTB *before*
>>> PeiServicesInstallPeiMemory() is called; that is, in the "first world".
>>>
>>> Before PeiServicesInstallPeiMemory() is called,
>>> - the code runs directly from flash,
>>> - the stack and the heap that the firmware uses are "temporary" (and
>>>   reside likely at some fixed RAM range).
>>>
>>> Where is the temporary RAM range located? It must be distinct from the
>>> range the DTB occupies, starting at 0x4000_.
>>>
>>
>> The presence of at least 1 MB of DRAM at 0x4000_ is assumed,
>
> Okay.
>
>> and
>> it is divided into a lower range for the DTB, and an upper range for
>> the temporary stack and heap.
>>
>> I.e., ArmPlatformPkg/PrePeiCore/MainUniCore.c references the following PCDs:
>>
>>   gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0x4007c000
>>   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x4000
>>
>> which it uses for a temp stack at the top and a temp heap at the
>> bottom. This leaves plenty of room for the DTB.
>
> Good answer, this is what I was looking for, thanks. In
> ArmPlatformPkg/PrePeiCore/, there are two INF files,
> PrePeiCoreMPCore.inf and PrePeiCoreUniCore.inf, they are both of module
> type SEC, and indeed the above PCDs are used for determining the
> temporary RAM range (in PrimaryMain(), SecCoreData.). OK.
>
>>
>>> (b) Predictably, my second question is about the second world. The
>>> permanent PEI memory must be distinct from the DTB.
>>>
>>> InitializeMemory() calculates where to place the permanent PEI memory.
>>> The permanent PEI memory does not cover the entire system RAM. It's
>>> (calculated) base address is UefiMemoryBase, and it's size comes from
>>> PcdSystemMemoryUefiRegionSize (64MB, see the next patch).
>>>
>>
>> Yes, so running with 64 MB will result in this region colliding with the DTB.
>
> Right.
>
> Note that this question can be short-circuited by a list of guarantees,
> for example:
> - the firmware volume will always (or never) be shadowed from flash to
>   system RAM (--> because this helps us see which outer branch in
>   InitializeMemory() will be taken),
> - and we'll never boot a guest with less than 128 MB RAM (--> this
>   determines the inner branch, and gi

[edk2] BuildMemoryAllocationHob() vs. gEfiPeiMemoryDiscoveredPpiGuid

[Laszlo Ersek]

Hi All,

based on Chapter 11, PEI Physical Memory Usage, in the PI spec, I think
that any PEIM that wants to call BuildMemoryAllocationHob() must make
sure that it runs on permanent PEI RAM.

In other words, it seems like BuildMemoryAllocationHob() is restricted
to PEI code that runs after permanent PEI RAM installation.

One way a PEIM can conform to this requirement is apparently a Depex on
gEfiPeiMemoryDiscoveredPpiGuid.

Questions:
- Is BuildMemoryAllocationHob() in fact restricted this way?
- If so, is a gEfiPeiMemoryDiscoveredPpiGuid Depex a good way to comply
  with this restriction in a PEIM (that doesn't itself install the
  permanent PEI RAM)?

In practice, this question has no consequences for OvmfPkg, because
there we already conform to the (apparent) requirement, and we ensure
the ordering simply by installing the permanent PEI RAM in the *same*
PEIM that later on calls BuildMemoryAllocationHob().

However, in ArmPlatformPkg/AArch64VirtualizationPkg, we might call
BuildMemoryAllocationHob() in a PEIM that is *separate* from the PEIM
that installs the permantent PEI RAM. Hence I think that this dependency
should be spelled out explicitly in the dependent PEIM's depex.

Thanks!
Laszlo

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Laszlo Ersek]

On 08/27/14 09:10, Ard Biesheuvel wrote:
> On 27 August 2014 00:24, Laszlo Ersek  wrote:
>> On 08/26/14 15:03, Ard Biesheuvel wrote:
>>> This changes the definition and a bunch of references to
>>> gArmTokenSpaceGuid.PcdSystemMemoryBase and
>>> gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic 
>>> PCDs
>>> by the platform. Also, move the non-SEC call to
>>> ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to 
>>> set
>>> these PCDs before they are first referenced.
>>>
>>> The purpose is allowing dynamically instantiated virtual machines to declare
>>> the system memory by passing a device tree.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
> [...]
>>
>> I spent several hours pondering this patch (and the next one).
>>
>> The most important question (for me) concerns the lifecycle of the DTB,
>> which has been placed by QEMU at 0x4000_. In the following I'll
>> first try to gather a few impressions, then I'll ask my questions.
>>
> 
> First of all, let me clarify that I was aware that this range needed
> some protection in some way, and I was currently getting away with the
> DTB surviving by luck.

Alright, good to know that you knew, thanks!

> Ideally, the install configuration table should be performed as early
> as possible, and the subsequent references of the device tree should
> find it using the config table GUID.
> But before that, we need something else, indeed.

Right. InstallConfigurationTable() is a UEFI boot service, you can't use
it before DXE. In addition, that service really only adds a (GUID,
pointer) pair to the list of config tables, so the pointed-to area must
be preserved / secured even in DXE by separate means.

> So you mention that passing it in DRAM is perhaps not the best way to
> go about this. Could you elaborate a bit

Sure. Peter didn't like this (for ARM / mach virt), but the fw_cfg
mechanism seen on the x86_64 target would be one alternative. Basically
you have two ioports, one for writing selector values into, and another
to read data from. ARM doesn't have ioports, but this could be done with
MIIO registers as well. (The guest code would do volatile reads and writes.)

Since this would "host" the DTB in something different than emulated
system RAM, the DTB could not, by nature, overlap with any part of the
system RAM.

The current approach is workable as well (ie. DTB copied by QEMU into
guest RAM upfront), it just needs more protection in the guest fw code.

[snip]

>> (a) My first question is what protects the DTB *before*
>> PeiServicesInstallPeiMemory() is called; that is, in the "first world".
>>
>> Before PeiServicesInstallPeiMemory() is called,
>> - the code runs directly from flash,
>> - the stack and the heap that the firmware uses are "temporary" (and
>>   reside likely at some fixed RAM range).
>>
>> Where is the temporary RAM range located? It must be distinct from the
>> range the DTB occupies, starting at 0x4000_.
>>
> 
> The presence of at least 1 MB of DRAM at 0x4000_ is assumed,

Okay.

> and
> it is divided into a lower range for the DTB, and an upper range for
> the temporary stack and heap.
> 
> I.e., ArmPlatformPkg/PrePeiCore/MainUniCore.c references the following PCDs:
> 
>   gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0x4007c000
>   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x4000
> 
> which it uses for a temp stack at the top and a temp heap at the
> bottom. This leaves plenty of room for the DTB.

Good answer, this is what I was looking for, thanks. In
ArmPlatformPkg/PrePeiCore/, there are two INF files,
PrePeiCoreMPCore.inf and PrePeiCoreUniCore.inf, they are both of module
type SEC, and indeed the above PCDs are used for determining the
temporary RAM range (in PrimaryMain(), SecCoreData.). OK.

> 
>> (b) Predictably, my second question is about the second world. The
>> permanent PEI memory must be distinct from the DTB.
>>
>> InitializeMemory() calculates where to place the permanent PEI memory.
>> The permanent PEI memory does not cover the entire system RAM. It's
>> (calculated) base address is UefiMemoryBase, and it's size comes from
>> PcdSystemMemoryUefiRegionSize (64MB, see the next patch).
>>
> 
> Yes, so running with 64 MB will result in this region colliding with the DTB.

Right.

Note that this question can be short-circuited by a list of guarantees,
for example:
- the firmware volume will always (or never) be shadowed from flash to
  system RAM (--> because this helps us see which outer branch in
  InitializeMemory() will be taken),
- and we'll never boot a guest with less than 128 MB RAM (--> this
  determines the inner branch, and given the size of the firmware
  volume, allows deducing the exact location of the permanent PEI RAM)

If we can guarantee such things, I'm completely fine with that as an answer.

>> InitializeMemory() takes care to place the permanent PEI memory at one
>> of three 

Re: [edk2] [PATCH v2 7/8] ArmPlatformPkg: add support for a QEMU/mach-virt target

[Ard Biesheuvel]

On 27 August 2014 01:36, Laszlo Ersek  wrote:
> I'll skip the DSC, FDF and INF files; I assume those are customized
> copies from existing platform files. I'll also skip the INF files for now.
>
> On 08/26/14 15:03, Ard Biesheuvel wrote:
>> This adds support for executing UEFI in a QEMU/mach-virt emulated 
>> environment.
>> The following assumptions are made about the target:
>> - ARM architected timer
>> - PL011 UART at 0x900
>> - at least 1 MB of DRAM at 0x4000, containing the device tree blob
>>
>> The following information is retrieved from the device tree:
>> - GIC base addresses
>> - virtual timer interrupt
>> - RTC base address
>> - system memory base and size
>> - virtio MMIO transports
>>
>> The DTB image is relocated and installed as a configuration table so an
>> EFI stub enabled kernel can be booted directly without the need for a
>> bootloader.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Casadevall 
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  .../AArch64Virtualization-KVM.dsc  | 223 +
>>  .../AArch64Virtualization-KVM.fdf  | 307 ++
>>  .../AArch64Virtualization.dsc.inc  | 354 
>> +
>>  .../AArch64VirtualizationPkg/Driver/VirtFdt.inf|  60 
>>  .../AArch64VirtualizationPkg/Driver/VirtFdtDxe.c   | 229 +
>>  .../Include/Platform/KVM/ArmPlatform.h |  32 ++
>>  .../AArch64VirtualizationLibKVM/AArch64KVMLib.inf  |  53 +++
>>  .../Library/AArch64VirtualizationLibKVM/KVM.c  | 127 
>>  .../AArch64VirtualizationLibKVM/KVMHelper.S|  70 
>>  .../Library/AArch64VirtualizationLibKVM/KVMMem.c   | 106 ++
>>  .../AArch64VirtualizationSysConfigLibKVM.c |  95 ++
>>  .../AArch64VirtualizationSysConfigLibKVM.inf   |  35 ++
>>  .../Library/ResetSystemLib/ResetSystemLib.c|  96 ++
>>  .../Library/ResetSystemLib/ResetSystemLib.inf  |  33 ++
>>  14 files changed, 1820 insertions(+)
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.dsc
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization-KVM.fdf
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/AArch64Virtualization.dsc.inc
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdt.inf
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Include/Platform/KVM/ArmPlatform.h
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/AArch64KVMLib.inf
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVM.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMHelper.S
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVMMem.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationSysConfigLibKVM/AArch64VirtualizationSysConfigLibKVM.inf
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.c
>>  create mode 100644 
>> ArmPlatformPkg/AArch64VirtualizationPkg/Library/ResetSystemLib/ResetSystemLib.inf
>
> [snip]
>
>> diff --git a/ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c 
>> b/ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
>> new file mode 100644
>> index ..04840e5d1a57
>> --- /dev/null
>> +++ b/ArmPlatformPkg/AArch64VirtualizationPkg/Driver/VirtFdtDxe.c
>> @@ -0,0 +1,229 @@
>> +/** @file
>> +*  Device tree enumeration DXE driver for AArch64 VMs
>> +*
>> +*  Copyright (c) 2014, Linaro Ltd. All rights reserved.
>> +*  This program and the accompanying materials are
>> +*  licensed and made available under the terms and conditions of the BSD 
>> License
>> +*  which accompanies this distribution.  The full text of the license may 
>> be found at
>> +*  http://opensource.org/licenses/bsd-license.php
>> +*
>> +*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> +*
>> +**/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#pragma pack (1)
>> +typedef struct {
>> +  VENDOR_DEVICE_PATH  Vendor;
>> +  UINT32  Instance;
>> +  EFI_DEVICE_PATH_PROTOCOLEnd;
>> +} VIRTIO_BLK_DEVICE_PATH;
>> +#pragma pack ()
>
> Ugh. :)
>
> Have you seen my earlie

Re: [edk2] [PATCH v2 6/8] ArmPkg, ArmPlatformPkg: allow dynamic PCDs for memory base and size

[Ard Biesheuvel]

On 27 August 2014 00:24, Laszlo Ersek  wrote:
> On 08/26/14 15:03, Ard Biesheuvel wrote:
>> This changes the definition and a bunch of references to
>> gArmTokenSpaceGuid.PcdSystemMemoryBase and
>> gArmTokenSpaceGuid.PcdSystemMemorySize so they can be declared as dynamic 
>> PCDs
>> by the platform. Also, move the non-SEC call to
>> ArmPlatformInitializeSystemMemory() earlier, so a platform has a chance to 
>> set
>> these PCDs before they are first referenced.
>>
>> The purpose is allowing dynamically instantiated virtual machines to declare
>> the system memory by passing a device tree.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
[...]
>
> I spent several hours pondering this patch (and the next one).
>
> The most important question (for me) concerns the lifecycle of the DTB,
> which has been placed by QEMU at 0x4000_. In the following I'll
> first try to gather a few impressions, then I'll ask my questions.
>

First of all, let me clarify that I was aware that this range needed
some protection in some way, and I was currently getting away with the
DTB surviving by luck.
Ideally, the install configuration table should be performed as early
as possible, and the subsequent references of the device tree should
find it using the config table GUID.
But before that, we need something else, indeed.

So you mention that passing it in DRAM is perhaps not the best way to
go about this. Could you elaborate a bit
> Impression 1: I peeked forward to v2 7/8 and the virt-specific
> ArmPlatformInitializeSystemMemory() seems to set the PCDs, based on the
> DTB. Okay.
>
> Impression 2: This series follows "porting case 1" from here:
>
>   http://tianocore.sourceforge.net/wiki/ArmPlatformPkg
>
> and I agree that that choice is correct. We'll use PrePeiCore, not
> PrePi.
>
> Impression 3: Also, PcdSystemMemoryInitializeInSec will be FALSE in our
> case.
>
> Impression 4: on our platform, the
> "ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c" source file will only
> be built into the PEIM called "MemoryInit".
>
> Namely, there are two source files in the directory, and two INF files:
>
> - MemoryInitPeiLib.c
> - MemoryInitPeiLib.inf
> - MemoryInitPeim.c
> - MemoryInitPeim.inf
>
> "MemoryInitPeiLib.inf" only uses "MemoryInitPeiLib.c", and builds a
> library.
>
> Only the following modules seem to depend on MemoryInitPeiLib:
>
> - ArmPlatformPkg/PrePi/PeiMPCore.inf
> - ArmPlatformPkg/PrePi/PeiUniCore.inf
>
> We won't use PrePi. The librarized build of this source directory is
> irrelevant for us, which is good.
>
> The PEIM build of this source directory, MemoryInitPeim.inf, depends on
> both C files, and we'll include this PEIM, along with PrePeiCore, in our
> platform DSC and FDF files in the next patch. Good.
>

Check.

> These impressions now allow me to formulate my question about the
> lifecycle of the DTB.
>
> There are three "worlds" that we need to investigate wrt. the protection
> of the DTB at address 0x4000_. I'm using the word "world" and not
> "phase", because these world boundaries do not coincide with the UEFI
> phase boundaries.
>
> - The first world covers startup (in SEC) and the first half of PEI,
>   until permanent PEI memory is installed.
> - The second world covers PEI *after* permanent RAM has been installed.
> - The third world is DXE and later.
>
> Let's where these worlds border on each other.
>
> At some point during the PEI phase, the PEIM that is the subject of this
> patch will be loaded & executed, and then the following happens:
>
> InitializeMemory()
> [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
>   ArmPlatformInitializeSystemMemory() 
> [ArmPlatformPkg/AArch64VirtualizationPkg/Library/AArch64VirtualizationLibKVM/KVM.c]
> # set PCDs based on DTB
>   PeiServicesInstallPeiMemory()   
> [MdePkg/Library/PeiServicesLib/PeiServicesLib.c]
> PeiInstallPeiMemory() 
> [MdeModulePkg/Core/Pei/Memory/MemoryServices.c]
>   # SwitchStackSignal = TRUE
>   MemoryPeim()
> [ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c]
> # create memory resource
> #   descriptor HOBs
>
> PeiInstallPeiMemory() is the boundary between worlds (1) and (2). (Once
> PeiInstallPeiMemory() is called, registering the PEI permanent RAM, the
> PEI dispatcher will migrate the temporary heap and stack contents to
> permanent RAM. (See the leading comment on PeiInstallPeiMemory(), and
> grep the tree for SwitchStackSignal.) ArmPlatformPkg's PrePeiCore does
> support temporary RAM migration (see gEfiTemporaryRamSupportPpiGuid in
> ArmPlatformPkg/PrePeiCore/PrePeiCore.c). But I digress.)
>
> The boundary between worlds (2) and (3) is not visible here, but the way
> DXE (and later) phases will work, wrt. the UEFI memory *space* map, is
> controlled by the memory resource descriptor HOBs that MemoryPeim()
> installs.
>
> (a) My first question is what protects the DTB *before*
> PeiServicesInst