Re: [edk2] [PATCH] BaseTools/BuildReport: fix report for platforms/arches without struct PCDs

[Vladimir Olovyannikov via edk2-devel]

Laszlo,
Thanks a lot for the prompt fix. Works now.

Tested-by: Vladimir Olovyannikov 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, February 5, 2019 3:22 AM
To: edk2-devel@lists.01.org
Cc: Bob Feng; Liming Gao; Vladimir Olovyannikov; Yonghong Zhu
Subject: [PATCH] BaseTools/BuildReport: fix report for platforms/arches
without struct PCDs

The goal of commit 97c8f5b9e7d3 ("BaseTools:StructurePCD value display
incorrect in "Not used" section.", 2019-02-02) was to display the full
contents of such structure PCDs in the build report that were set in the
platform DSC or the FDF, but not used in any module INFs. The listings
would appear in the

  PCDs not used by modules or in conditional directives

section of the build report.

Commit 97c8f5b9e7d3 assumed that any (platform, architecture) combination
would have a (possibly empty) set of structure PCD (and so the set of the
structure PCDs could be filtered for set-but-unused ones).

This is not the case: in "DscBuildData.py", in method
UpdateStructuredPcds(), if "S_pcd_set" remains an empty OrderedDict(),
then it is not added to "GlobalData.gStructurePcd" *at all*, for the
current (platform, architecture) combination.

As a result, when the PCD report tries to fetch the set of structure PCDs
for the current (platform, architecture), "GlobalData.gStructurePcd" does
not return an empty OrderedDict(); instead, it raises a KeyError. Fix it
by defaulting to an empty OrderedDict(), with the get() method.

Reported-by: Vladimir Olovyannikov 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1513
Fixes: 97c8f5b9e7d3136b6051a05cf056ce5ca9e79893
Cc: Bob Feng 
Cc: Liming Gao 
Cc: Vladimir Olovyannikov 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: report_without_struct_pcds

 BaseTools/Source/Python/build/BuildReport.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py
b/BaseTools/Source/Python/build/BuildReport.py
index e457660fcef3..0b98d62cb6aa 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -780,7 +780,7 @@ class PcdReport(object):
 # Collect the PCD defined in DSC/FDF file, but not used in
module
 #
 UnusedPcdFullList = []
-StructPcdDict = GlobalData.gStructurePcd[self.Arch]
+StructPcdDict = GlobalData.gStructurePcd.get(self.Arch,
collections.OrderedDict())
 for Name, Guid in StructPcdDict:
 if (Name, Guid) not in Pa.Platform.Pcds:
 Pcd = StructPcdDict[(Name, Guid)]
-- 
2.19.1.3.g30247aa5d201
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg/TftpDynamicCommand: Return proper status

[Vladimir Olovyannikov via edk2-devel]

Tftp command always returned "SHELL_NOT_FOUND" which is treated as an
error by callers. Add missing line to clean the ShellStatus on
successful operation. If operation has failed, return the error status
if available.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov 
---
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c 
b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
index ba753a279b00..88e3988a554e 100644
--- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
+++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
@@ -548,6 +548,8 @@ RunTftp (
   goto NextHandle;
 }
 
+ShellStatus = SHELL_SUCCESS;
+
 NextHandle:
 
 CloseProtocolAndDestroyServiceChild (
@@ -575,6 +577,10 @@ RunTftp (
 FreePool (Handles);
   }
 
+  if ((ShellStatus != SHELL_SUCCESS) && (EFI_ERROR(Status))) {
+ShellStatus = Status & ~MAX_BIT;
+  }
+
   return ShellStatus;
 }
 
-- 
2.20.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform

[Vladimir Olovyannikov]

On Fri, Sep 21, 2018 at 5:14 PM Ard Biesheuvel
 wrote:
>
>
>
> On Fri 21 Sep 2018 at 16:57, Andrew Fish  wrote:
>>
>>
>>
>> > On Sep 21, 2018, at 4:24 PM, Vladimir Olovyannikov 
>> >  wrote:
>> >
>> > On Thu, Sep 20, 2018 at 2:52 PM Vladimir Olovyannikov
>> >  wrote:
>> >>
>> >> On Wed, Sep 19, 2018 at 5:21 PM Bill Paul  wrote:
>> >>>
>> >>> Of all the gin joints in all the towns in all the world, Vladimir
>> >>> Olovyannikov
>> >>> had to walk into mine at 16:58 on Wednesday 19 September 2018 and say:
>> >>>
>> >>>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> >>>>> Sent: Wednesday, September 19, 2018 4:38 PM
>> >>>>> To: Vladimir Olovyannikov
>> >>>>> Cc: edk2-devel@lists.01.org
>> >>>>> Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an
>> >>>>> Armv8 platform
>> >>>>>
>> >>>>>
>> >>>>> On 19 September 2018 at 15:55, Vladimir Olovyannikov
>> >>>>>
>> >>>>>  wrote:
>> >>>>>> Hi All,
>> >>>>>>
>> >>>>>> I need UEFI experts help on the problem with Armv8 board on warm UEFI
>> >>>>>> reset.
>> >>>>>> Cold reset works fine.
>> >>>>>>
>> >>>>>> Here is how I set up a warm reset:
>> >>>>>>
>> >>>>>> STATIC
>> >>>>>> EFI_STATUS
>> >>>>>> ShutdownUefiBootServices (
>> >>>>>>
>> >>>>>> VOID
>> >>>>>> )
>> >>>>>>
>> >>>>>> {
>> >>>>>>
>> >>>>>> EFI_STATUS  Status;
>> >>>>>> UINTN   MemoryMapSize;
>> >>>>>> EFI_MEMORY_DESCRIPTOR   *MemoryMap;
>> >>>>>> UINTN   MapKey;
>> >>>>>> UINTN   DescriptorSize;
>> >>>>>> UINT32  DescriptorVersion;
>> >>>>>> UINTN   Pages;
>> >>>>>>
>> >>>>>> MemoryMap = NULL;
>> >>>>>> MemoryMapSize = 0;
>> >>>>>> Pages = 0;
>> >>>>>>
>> >>>>>> do {
>> >>>>>>
>> >>>>>>   Status = gBS->GetMemoryMap (
>> >>>>>>
>> >>>>>>   ,
>> >>>>>>   MemoryMap,
>> >>>>>>   ,
>> >>>>>>   ,
>> >>>>>>   
>> >>>>>>   );
>> >>>>>>
>> >>>>>>   if (Status == EFI_BUFFER_TOO_SMALL) {
>> >>>>>>
>> >>>>>> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
>> >>>>>> MemoryMap = AllocatePages (Pages);
>> >>>>>>
>> >>>>>> //
>> >>>>>> // Get System MemoryMap
>> >>>>>> //
>> >>>>>> Status = gBS->GetMemoryMap (
>> >>>>>>
>> >>>>>> ,
>> >>>>>> MemoryMap,
>> >>>>>> ,
>> >>>>>> ,
>> >>>>>> 
>> >>>>>> );
>> >>>>>>
>> >>>>>>   }
>> >>>>>>
>> >>>>>>   // Don't do anything between the GetMemoryMap() and
>> >>>>>>   ExitBootServices() if (!EFI_ERROR(Status)) {
>> >>>>>>
>> >>>>>> Status = gBS->ExitBootServices (gImageHandle, MapKey);
>> >>>>>> if (EFI_ERROR(Status)) {
>> >>>>>>
>> >>>>>>   FreePages (MemoryMap, Pages);
>> >>>>>>   MemoryMap = NULL;
>> >>>>>>   MemoryMapSize = 0;
>> >>>>>>
>> >>>>>>

Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform

[Vladimir Olovyannikov]

On Thu, Sep 20, 2018 at 2:52 PM Vladimir Olovyannikov
 wrote:
>
> On Wed, Sep 19, 2018 at 5:21 PM Bill Paul  wrote:
> >
> > Of all the gin joints in all the towns in all the world, Vladimir
> > Olovyannikov
> > had to walk into mine at 16:58 on Wednesday 19 September 2018 and say:
> >
> > > >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > >Sent: Wednesday, September 19, 2018 4:38 PM
> > > >To: Vladimir Olovyannikov
> > > >Cc: edk2-devel@lists.01.org
> > > >Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an
> > > >Armv8 platform
> > > >
> > > >
> > > >On 19 September 2018 at 15:55, Vladimir Olovyannikov
> > > >
> > > > wrote:
> > > >>Hi All,
> > > >>
> > > >>I need UEFI experts help on the problem with Armv8 board on warm UEFI
> > > >>reset.
> > > >>Cold reset works fine.
> > > >>
> > > >>Here is how I set up a warm reset:
> > > >>
> > > >>STATIC
> > > >>EFI_STATUS
> > > >>ShutdownUefiBootServices (
> > > >>
> > > >>  VOID
> > > >>  )
> > > >>
> > > >>{
> > > >>
> > > >>  EFI_STATUS  Status;
> > > >>  UINTN   MemoryMapSize;
> > > >>  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
> > > >>  UINTN   MapKey;
> > > >>  UINTN   DescriptorSize;
> > > >>  UINT32  DescriptorVersion;
> > > >>  UINTN   Pages;
> > > >>
> > > >>  MemoryMap = NULL;
> > > >>  MemoryMapSize = 0;
> > > >>  Pages = 0;
> > > >>
> > > >>  do {
> > > >>
> > > >>Status = gBS->GetMemoryMap (
> > > >>
> > > >>,
> > > >>MemoryMap,
> > > >>,
> > > >>,
> > > >>
> > > >>);
> > > >>
> > > >>if (Status == EFI_BUFFER_TOO_SMALL) {
> > > >>
> > > >>  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
> > > >>  MemoryMap = AllocatePages (Pages);
> > > >>
> > > >>  //
> > > >>  // Get System MemoryMap
> > > >>  //
> > > >>  Status = gBS->GetMemoryMap (
> > > >>
> > > >>  ,
> > > >>  MemoryMap,
> > > >>  ,
> > > >>  ,
> > > >>  
> > > >>  );
> > > >>
> > > >>}
> > > >>
> > > >>// Don't do anything between the GetMemoryMap() and
> > > >>ExitBootServices() if (!EFI_ERROR(Status)) {
> > > >>
> > > >>  Status = gBS->ExitBootServices (gImageHandle, MapKey);
> > > >>  if (EFI_ERROR(Status)) {
> > > >>
> > > >>FreePages (MemoryMap, Pages);
> > > >>MemoryMap = NULL;
> > > >>MemoryMapSize = 0;
> > > >>
> > > >>  }
> > > >>
> > > >>}
> > > >>
> > > >>  } while (EFI_ERROR(Status));
> > > >>
> > > >>  return Status;
> > > >>
> > > >>}
> > > >>
> > > >>Then perform
> > > >>ArmCleanDataCache ();
> > > >>ArmInvalidateDataCache ();
> > > >>ArmDisableInstructionCache ();
> > > >>ArmInvalidateInstructionCache ();
> > > >
> > > >These don't do anything useful on ARM. You can only reliably perform
> > > >cache
> > > >maintenance by virtual address.
> > >
> > > So, should I just remove them altogether?
> > >
> > > >>ArmDisableMmu ();
> > > >
> > > >... so after this call returns, all bets are off with regards to
> > > >whether
> > > >what is popped from the stack is actually what we pushed when we
> > > >entered
> > > >the function.
> > >
> > > OK, tha

Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform

[Vladimir Olovyannikov]

On Wed, Sep 19, 2018 at 5:21 PM Bill Paul  wrote:
>
> Of all the gin joints in all the towns in all the world, Vladimir
> Olovyannikov
> had to walk into mine at 16:58 on Wednesday 19 September 2018 and say:
>
> > >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > >Sent: Wednesday, September 19, 2018 4:38 PM
> > >To: Vladimir Olovyannikov
> > >Cc: edk2-devel@lists.01.org
> > >Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an
> > >Armv8 platform
> > >
> > >
> > >On 19 September 2018 at 15:55, Vladimir Olovyannikov
> > >
> > > wrote:
> > >>Hi All,
> > >>
> > >>I need UEFI experts help on the problem with Armv8 board on warm UEFI
> > >>reset.
> > >>Cold reset works fine.
> > >>
> > >>Here is how I set up a warm reset:
> > >>
> > >>STATIC
> > >>EFI_STATUS
> > >>ShutdownUefiBootServices (
> > >>
> > >>  VOID
> > >>  )
> > >>
> > >>{
> > >>
> > >>  EFI_STATUS  Status;
> > >>  UINTN   MemoryMapSize;
> > >>  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
> > >>  UINTN   MapKey;
> > >>  UINTN   DescriptorSize;
> > >>  UINT32  DescriptorVersion;
> > >>  UINTN   Pages;
> > >>
> > >>  MemoryMap = NULL;
> > >>  MemoryMapSize = 0;
> > >>  Pages = 0;
> > >>
> > >>  do {
> > >>
> > >>Status = gBS->GetMemoryMap (
> > >>
> > >>,
> > >>MemoryMap,
> > >>,
> > >>,
> > >>
> > >>);
> > >>
> > >>if (Status == EFI_BUFFER_TOO_SMALL) {
> > >>
> > >>  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
> > >>  MemoryMap = AllocatePages (Pages);
> > >>
> > >>  //
> > >>  // Get System MemoryMap
> > >>  //
> > >>  Status = gBS->GetMemoryMap (
> > >>
> > >>  ,
> > >>  MemoryMap,
> > >>  ,
> > >>  ,
> > >>  
> > >>  );
> > >>
> > >>}
> > >>
> > >>// Don't do anything between the GetMemoryMap() and
> > >>ExitBootServices() if (!EFI_ERROR(Status)) {
> > >>
> > >>  Status = gBS->ExitBootServices (gImageHandle, MapKey);
> > >>  if (EFI_ERROR(Status)) {
> > >>
> > >>FreePages (MemoryMap, Pages);
> > >>MemoryMap = NULL;
> > >>MemoryMapSize = 0;
> > >>
> > >>  }
> > >>
> > >>}
> > >>
> > >>  } while (EFI_ERROR(Status));
> > >>
> > >>  return Status;
> > >>
> > >>}
> > >>
> > >>Then perform
> > >>ArmCleanDataCache ();
> > >>ArmInvalidateDataCache ();
> > >>ArmDisableInstructionCache ();
> > >>ArmInvalidateInstructionCache ();
> > >
> > >These don't do anything useful on ARM. You can only reliably perform
> > >cache
> > >maintenance by virtual address.
> >
> > So, should I just remove them altogether?
> >
> > >>ArmDisableMmu ();
> > >
> > >... so after this call returns, all bets are off with regards to
> > >whether
> > >what is popped from the stack is actually what we pushed when we
> > >entered
> > >the function.
> >
> > OK, thank you for explanation.
> > But this call returns back into ResetLib implementation as it should,
> > and
> > then there is a direct jump to the start of FV.
> > Am I doing anything wrong here?
> > Then, up to the point of enabling of MMU the stack is OK. But right
> > after
> > enabling MMU it points at _ModuleEntryPoint end of function in
> > DxeCoreEntryPoint.c
> > Am I missing anything? Maybe some stack cleanup before jumping to the
> > start
> > of FV?
>
> When the MMU is enabled, does the mapping for the stack pages change? That
> is,
> could the stack now be mapped to diffe

Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform

[Vladimir Olovyannikov]

>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>Sent: Wednesday, September 19, 2018 4:38 PM
>To: Vladimir Olovyannikov
>Cc: edk2-devel@lists.01.org
>Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an Armv8
>platform


>On 19 September 2018 at 15:55, Vladimir Olovyannikov
> wrote:
>>Hi All,

>>I need UEFI experts help on the problem with Armv8 board on warm UEFI
>>reset.
>>Cold reset works fine.

>>Here is how I set up a warm reset:

>>STATIC
>>EFI_STATUS
>>ShutdownUefiBootServices (
>>  VOID
>>  )
>>{
>>  EFI_STATUS  Status;
>>  UINTN   MemoryMapSize;
>>  EFI_MEMORY_DESCRIPTOR   *MemoryMap;
>>  UINTN   MapKey;
>>  UINTN   DescriptorSize;
>>  UINT32  DescriptorVersion;
>>  UINTN   Pages;

>>  MemoryMap = NULL;
>>  MemoryMapSize = 0;
>>  Pages = 0;
>>
>>  do {
>>Status = gBS->GetMemoryMap (
>>,
>>MemoryMap,
>>,
>>,
>>
>>);
>>if (Status == EFI_BUFFER_TOO_SMALL) {
>>
>>  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
>>  MemoryMap = AllocatePages (Pages);
>>
>>  //
>>  // Get System MemoryMap
>>  //
>>  Status = gBS->GetMemoryMap (
>>  ,
>>  MemoryMap,
>>  ,
>>  ,
>>  
>>  );
>>}
>>
>>// Don't do anything between the GetMemoryMap() and ExitBootServices()
>>if (!EFI_ERROR(Status)) {
>>  Status = gBS->ExitBootServices (gImageHandle, MapKey);
>>  if (EFI_ERROR(Status)) {
>>FreePages (MemoryMap, Pages);
>>MemoryMap = NULL;
>>MemoryMapSize = 0;
>>  }
>>}
>>  } while (EFI_ERROR(Status));
>>
>>  return Status;
>>}
>>
>>Then perform
>>ArmCleanDataCache ();
>>ArmInvalidateDataCache ();
>>ArmDisableInstructionCache ();
>>ArmInvalidateInstructionCache ();

>These don't do anything useful on ARM. You can only reliably perform cache
>maintenance by virtual address.
So, should I just remove them altogether?

>>ArmDisableMmu ();

>... so after this call returns, all bets are off with regards to whether
>what is popped from the stack is actually what we pushed when we entered
>the function.
OK, thank you for explanation.
But this call returns back into ResetLib implementation as it should, and
then there is a direct jump to the start of FV.
Am I doing anything wrong here?
Then, up to the point of enabling of MMU the stack is OK. But right after
enabling MMU it points at _ModuleEntryPoint end of function in
DxeCoreEntryPoint.c
Am I missing anything? Maybe some stack cleanup before jumping to the start
of FV?

>>Then jump to start of FV:

>>typedef
>>VOID
>> (EFIAPI *START_FV)(
>>  VOID
>>);
>>StartOfFv = (START_FV)(UINTN)PcdGet64(PcdFvBaseAddress);
>>StartOfFv ();
>>
>>Now this is what happens on warm reset:
>>reset -c warm
>>1. Until ArmEnableMmu() gets called, everything works as expected.
>>Here is the stack right before ArmEnableMmu() is called:
>> ArmConfigureMmu+0x4f8
>> InitMmu+0x24
>> MemoryPeim+0x440
>> PrePiMain+0x114
>> PrimaryMain+0x68
>> CEntryPoint+0xC4
>> EL2:0x88BC
>> -  End of stack info -
>>
>>2. Here is the stack as soon as Mmu is enabled with ArmEnableMmu() :
>>ArmConfigureMmu+0x4fc <-- This one is correct, at line 745 in
>> ArmConfigureMmu() in ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
>> (return EFI_SUCCESS)
>>   _ModuleEntryPoint+0x24 <-- Wrong. This points directly to
>> ASSERT(FALSE); and to CpuDeadLoop() in DxeCoreEntryPoint.c, lines 59-60.
>>   El2:0x8E5E8300 <-- Absolutely bogus
>>--- End of stack info ---
>>
>>So, as soon as ArmEnableMmu() exits, execution jumps directly to
>>CpuDeadLoop() in DxeCoreEntryPoint of _ModuleEntryPoint().
>>
>>Would be grateful for any advice.
>>
>>Thank you,
>>Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform

[Vladimir Olovyannikov]

Hi All,



I need UEFI experts help on the problem with Armv8 board on warm UEFI reset.

Cold reset works fine.



Here is how I set up a warm reset:



STATIC

EFI_STATUS

ShutdownUefiBootServices (

  VOID

  )

{

  EFI_STATUS  Status;

  UINTN   MemoryMapSize;

  EFI_MEMORY_DESCRIPTOR   *MemoryMap;

  UINTN   MapKey;

  UINTN   DescriptorSize;

  UINT32  DescriptorVersion;

  UINTN   Pages;



  MemoryMap = NULL;

  MemoryMapSize = 0;

  Pages = 0;



  do {

Status = gBS->GetMemoryMap (

,

MemoryMap,

,

,



);

if (Status == EFI_BUFFER_TOO_SMALL) {



  Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;

  MemoryMap = AllocatePages (Pages);



  //

  // Get System MemoryMap

  //

  Status = gBS->GetMemoryMap (

  ,

  MemoryMap,

  ,

  ,

  

  );

}



// Don't do anything between the GetMemoryMap() and ExitBootServices()

if (!EFI_ERROR(Status)) {

  Status = gBS->ExitBootServices (gImageHandle, MapKey);

  if (EFI_ERROR(Status)) {

FreePages (MemoryMap, Pages);

MemoryMap = NULL;

MemoryMapSize = 0;

  }

}

  } while (EFI_ERROR(Status));



  return Status;

}



Then perform

ArmCleanDataCache ();

ArmInvalidateDataCache ();

ArmDisableInstructionCache ();

ArmInvalidateInstructionCache ();

ArmDisableMmu ();



Then jump to start of FV:



typedef

VOID

(EFIAPI *START_FV)(

  VOID

);

StartOfFv = (START_FV)(UINTN)PcdGet64(PcdFvBaseAddress);

StartOfFv ();



Now this is what happens on warm reset:

reset -c warm

1. Until ArmEnableMmu() gets called, everything works as expected.

Here is the stack right before ArmEnableMmu() is called:

 ArmConfigureMmu+0x4f8

 InitMmu+0x24

 MemoryPeim+0x440

 PrePiMain+0x114

 PrimaryMain+0x68

 CEntryPoint+0xC4

 EL2:0x88BC

 -  End of stack info -



2. Here is the stack as soon as Mmu is enabled with ArmEnableMmu() :

ArmConfigureMmu+0x4fc <-- This one is correct, at line 745 in
ArmConfigureMmu() in ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
(return EFI_SUCCESS)

   _ModuleEntryPoint+0x24 <-- Wrong. This points directly to ASSERT(FALSE);
and to CpuDeadLoop() in DxeCoreEntryPoint.c, lines 59-60.

   El2:0x8E5E8300 <-- Absolutely bogus

--- End of stack info ---



So, as soon as ArmEnableMmu() exits, execution jumps directly to
CpuDeadLoop() in DxeCoreEntryPoint of _ModuleEntryPoint().



Would be grateful for any advice.



Thank you,

Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add missing validation

[Vladimir Olovyannikov]

UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
required checks were not performed. Perform parameters validation in
NonDiscoverablePciDeviceDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov 
---
 .../NonDiscoverablePciDeviceIo.c  | 50 ++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c 
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
index 0e42ae4bf6ec..07118d59fd68 100644
--- 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
+++ 
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
@@ -52,6 +52,10 @@ GetBarResource (
 
   BarIndex -= (UINT8)Dev->BarOffset;
 
+  if (BarIndex >= Dev->BarCount) {
+return EFI_UNSUPPORTED;
+  }
+
   for (Desc = Dev->Device->Resources;
Desc->Desc != ACPI_END_TAG_DESCRIPTOR;
Desc = (VOID *)((UINT8 *)Desc + Desc->Len + 3)) {
@@ -597,6 +601,19 @@ CoherentPciIoMap (
   EFI_STATUSStatus;
   NON_DISCOVERABLE_PCI_DEVICE_MAP_INFO  *MapInfo;
 
+  if (Operation != EfiPciIoOperationBusMasterRead &&
+  Operation != EfiPciIoOperationBusMasterWrite &&
+  Operation != EfiPciIoOperationBusMasterCommonBuffer) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (HostAddress   == NULL ||
+  NumberOfBytes == NULL ||
+  DeviceAddress == NULL ||
+  Mapping   == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
   //
   // If HostAddress exceeds 4 GB, and this device does not support 64-bit DMA
   // addressing, we need to allocate a bounce buffer and copy over the data.
@@ -720,6 +737,11 @@ CoherentPciIoAllocateBuffer (
 return EFI_UNSUPPORTED;
   }
 
+  if ((MemoryType != EfiBootServicesData) &&
+  (MemoryType != EfiRuntimeServicesData)) {
+return EFI_INVALID_PARAMETER;
+  }
+
   //
   // Allocate below 4 GB if the dual address cycle attribute has not
   // been set. If the system has no memory available below 4 GB, there
@@ -877,6 +899,10 @@ NonCoherentPciIoAllocateBuffer (
   NON_DISCOVERABLE_DEVICE_UNCACHED_ALLOCATION *Alloc;
   VOID*AllocAddress;
 
+  if (HostAddress == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
   Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
 
   Status = CoherentPciIoAllocateBuffer (This, Type, MemoryType, Pages,
@@ -995,6 +1021,19 @@ NonCoherentPciIoMap (
   EFI_GCD_MEMORY_SPACE_DESCRIPTOR   GcdDescriptor;
   BOOLEAN   Bounce;
 
+  if (HostAddress   == NULL ||
+  NumberOfBytes == NULL ||
+  DeviceAddress == NULL ||
+  Mapping   == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (Operation != EfiPciIoOperationBusMasterRead &&
+  Operation != EfiPciIoOperationBusMasterWrite &&
+  Operation != EfiPciIoOperationBusMasterCommonBuffer) {
+return EFI_INVALID_PARAMETER;
+  }
+
   MapInfo = AllocatePool (sizeof *MapInfo);
   if (MapInfo == NULL) {
 return EFI_OUT_OF_RESOURCES;
@@ -1228,8 +1267,17 @@ PciIoAttributes (
   NON_DISCOVERABLE_PCI_DEVICE   *Dev;
   BOOLEAN   Enable;
 
+  #define DEV_SUPPORTED_ATTRIBUTES \
+(EFI_PCI_DEVICE_ENABLE | EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE)
+
   Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
 
+  if (Attributes) {
+  if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) {
+return EFI_UNSUPPORTED;
+  }
+}
+
   Enable = FALSE;
   switch (Operation) {
   case EfiPciIoAttributeOperationGet:
@@ -1243,7 +1291,7 @@ PciIoAttributes (
 if (Result == NULL) {
   return EFI_INVALID_PARAMETER;
 }
-*Result = EFI_PCI_DEVICE_ENABLE | EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE;
+*Result = DEV_SUPPORTED_ATTRIBUTES;
 break;
 
   case EfiPciIoAttributeOperationEnable:
-- 
2.18.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/3] EmbeddedPkg/CoherentDmaLib: Add missing checks to DmaMap

[Vladimir Olovyannikov]

UEFI Sct validates Dma mapping. For CoherentDmaLib it always failed
because there were no required checks present in DmaMap.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov 
---
 EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c 
b/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
index 8ca9e6aa5b1b..eb88fa288a99 100644
--- a/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
+++ b/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
@@ -58,6 +58,12 @@ DmaMap (
   OUTVOID   **Mapping
   )
 {
+  if (HostAddress == NULL ||
+  NumberOfBytes == NULL ||
+  DeviceAddress == NULL ||
+  Mapping == NULL ) {
+return EFI_INVALID_PARAMETER;
+  }
   *DeviceAddress = HostToDeviceAddress (HostAddress);
   *Mapping = NULL;
   return EFI_SUCCESS;
-- 
2.18.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/3] EmbeddedPkg/CoherentDmaLib: Fix typo in DmaAlignedBuffer

[Vladimir Olovyannikov]

The only valid memory types for DmaAlignedBuffer should be
EfiBootServicesData and EfiRuntimeServicesData. However due to the typo,
there is no way to allocate runtime pages, and INVALID_PARAMETER is
always returned. Fix the typo.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov 
---
 EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c 
b/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
index 564db83c901c..8ca9e6aa5b1b 100644
--- a/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
+++ b/EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.c
@@ -154,7 +154,7 @@ DmaAllocateAlignedBuffer (
   //
   if (MemoryType == EfiBootServicesData) {
 *HostAddress = AllocateAlignedPages (Pages, Alignment);
-  } else if (MemoryType != EfiRuntimeServicesData) {
+  } else if (MemoryType == EfiRuntimeServicesData) {
 *HostAddress = AllocateAlignedRuntimePages (Pages, Alignment);
   } else {
 return EFI_INVALID_PARAMETER;
-- 
2.18.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1] MdeModulePkg: Fix memory leak in FvSimpleFileSystem driver

[Vladimir Olovyannikov]

FvSimpleFileSystem on read always allocates a FileBuffer, and never frees
it. This causes memory leaks. It is especially bad for reading scripts
line-by-line. In some cases memory leak can exceed 1GB.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikiov 
---
 .../Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c   | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c 
b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
index 746f2ced708a..fde208594737 100644
--- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
+++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
@@ -704,6 +704,7 @@ FvSimpleFileSystemRead (
 
 Status = FvFsReadFile (File->Instance->FvProtocol, File->FvFileInfo, 
, );
 if (EFI_ERROR (Status)) {
+  FreePool (FileBuffer);
   return EFI_DEVICE_ERROR;
 }
 
@@ -714,6 +715,8 @@ FvSimpleFileSystemRead (
 CopyMem (Buffer, (UINT8*)FileBuffer + File->Position, *BufferSize);
 File->Position += *BufferSize;
 
+FreePool (FileBuffer);
+
 return EFI_SUCCESS;
   }
 }
-- 
2.18.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using PcdSet32S for gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize

[Vladimir Olovyannikov]

Thanks a lot Liming,
This works.

Vladimir
-Original Message-
From: Gao, Liming [mailto:liming@intel.com]
Sent: Thursday, March 15, 2018 6:16 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org
Subject: RE: [edk2] Using PcdSet32S for
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize

You need to configure PCD in [PcdsDynamicDefault.common.DEFAULT] of
platform DSC file, and remove it from platform FDF file.

You can refer to Nt32Pkg\Nt32Pkg.dsc, it configure
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase as Dynamic,
and set it at boot time.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Vladimir Olovyannikov
> Sent: Friday, March 16, 2018 9:13 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Using PcdSet32S for
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>
> Hi,
>
> I would like  to overwrite
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> From an Fvb runtime driver.
> For that purpose I try to do it like this:
> PcdStatus = PcdSet32S(PcdFlashNvStorageVariableBase,
> (UINT32)(UINTN)Instance->VariableBase);
>
> My .inf file for the driver contains
> [Packages]
>   MdePkg/MdePkg.dec
>   MdeModulePkg/MdeModulePkg.dec
>   MyTestPlatformPkg/MytestPlatformPkg.dec
>
> and
> [Pcd]
>   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>
> When I build the image, I am getting
> /uefi/MdePkg/Include/Library/PcdLib.h:630:45: error: implicit
> declaration of function
> `_PCD_SET_MODE_32_S_PcdFlashNvStorageVariableBase`
> [-Werror=implicit-function-declaration]
> #define PcdSet32S(TokenName, Value)
_PCD_SET_MODE_32_S_##TokenName
> ((Value))
>  ^
> /uefi/BroadcomPlatformPkg/Drivers/FvbDxe/FvbImpl.c:1090:19: note: in
> expansion of macro `PcdSet32S`
>PcdStatus = PcdSet32S(PcdFlashNvStorageVariableBase,
> (UINT32)(UINTN)Instance->VariableBase);
>^
> in Autogen.h for the driver:
> extern const  UINT32
> _gPcd_FixedAtBuild_PcdFlashNvStorageVariableBase;
> #define _PCD_GET_MODE_SIZE_PcdFlashNvStorageVariableBase
> _PCD_SIZE_PcdFlashNvStorageVariableBase
> //#define _PCD_SET_MODE_32_PcdFlashNvStorageVariableBase
> ASSERT(FALSE)  // It is not allowed to set value for a FIXED_AT_BUILD
> PCD
>
> Similarly there are no definitions for other Pcds for PcdSet32 (for
> instance PcdFlashNvStorageFtwWorkingBase); they are all set as
> "FixedAtBuild".
>
> I can see the PcdFlashNvStorageVariableBase is declared in
> MdeModulePkg as [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx] ...
> ## Base address of the NV variable range in flash device.
>   # @Prompt Base address of flash NV variable range.
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0|UINT3
> 2|0x3001
>
> Why is it set as "FixedAtBuild", and how can I change it to be writable?
> I can see that some platforms (for instance, OvmfPkg) overwrite these
> variables via PcdSet32S/PcdSet64S.
>
> What am I missing here?
>
> Thank you,
> Vladimir
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Using PcdSet32S for gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize

[Vladimir Olovyannikov]

Hi,

I would like  to overwrite
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>From an Fvb runtime driver.
For that purpose I try to do it like this:
PcdStatus = PcdSet32S(PcdFlashNvStorageVariableBase,
(UINT32)(UINTN)Instance->VariableBase);

My .inf file for the driver contains
[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
  MyTestPlatformPkg/MytestPlatformPkg.dec

and
[Pcd]
  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize

When I build the image, I am getting
/uefi/MdePkg/Include/Library/PcdLib.h:630:45: error: implicit declaration of
function `_PCD_SET_MODE_32_S_PcdFlashNvStorageVariableBase`
[-Werror=implicit-function-declaration]
#define PcdSet32S(TokenName, Value) _PCD_SET_MODE_32_S_##TokenName
((Value))
 ^
/uefi/BroadcomPlatformPkg/Drivers/FvbDxe/FvbImpl.c:1090:19: note: in
expansion of macro `PcdSet32S`
   PcdStatus = PcdSet32S(PcdFlashNvStorageVariableBase,
(UINT32)(UINTN)Instance->VariableBase);
   ^
in Autogen.h for the driver:
extern const  UINT32  _gPcd_FixedAtBuild_PcdFlashNvStorageVariableBase;
#define _PCD_GET_MODE_SIZE_PcdFlashNvStorageVariableBase
_PCD_SIZE_PcdFlashNvStorageVariableBase
//#define _PCD_SET_MODE_32_PcdFlashNvStorageVariableBase  ASSERT(FALSE)  //
It is not allowed to set value for a FIXED_AT_BUILD PCD

Similarly there are no definitions for other Pcds for PcdSet32 (for instance
PcdFlashNvStorageFtwWorkingBase);
they are all set as "FixedAtBuild".

I can see the PcdFlashNvStorageVariableBase is declared in MdeModulePkg as
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
...
## Base address of the NV variable range in flash device.
  # @Prompt Base address of flash NV variable range.
  
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0|UINT32|0x3001

Why is it set as "FixedAtBuild", and how can I change it to be writable?
I can see that some platforms (for instance, OvmfPkg) overwrite these
variables via PcdSet32S/PcdSet64S.

What am I missing here?

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg/MemoryInitPeiLib: mark primary FV region as boot services data

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, January 2, 2018 7:51 AM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; vladimir.olovyanni...@broadcom.com;
> udit.ku...@nxp.com; meenakshi.aggar...@nxp.com; Ard Biesheuvel
> Subject: [PATCH] ArmPlatformPkg/MemoryInitPeiLib: mark primary FV
> region as boot services data
>
> Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
> primary FV in memory") deleted the code that removes the memory
> covering the primary firmware volume from the memory map. The
> assumption was that this is no longer necessary now that we no longer
> expose compression and PE/COFF loader library code from the PrePi module
> to DXE core.
>
> However, the FV is still declared, and so code may attempt to access it
> anyway, which may cause unexpected results depending on whether the
> memory has been reused for other purposes in the mean time.
>
> So reinstate the code that splits off the resource descriptor HOB that
> describes the firmware device, but this time, don't mark the memory as
> unusable, but create a memory allocation HOB that marks the region as
boot
> services data.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> Vladimir, Udit, Meenakshi: please confirm whether this code works for
you.
Thanks Ard,
Works for me.

Vladimir
>
>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 74
> 
>  1 file changed, 74 insertions(+)
>
> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> index d03214b5df66..d1b5c0be9497 100644
> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> @@ -70,7 +70,11 @@ MemoryPeim (
>  {
>ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
>EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> +  UINT64   ResourceLength;
>EFI_PEI_HOB_POINTERS NextHob;
> +  EFI_PHYSICAL_ADDRESS FdTop;
> +  EFI_PHYSICAL_ADDRESS SystemMemoryTop;
> +  EFI_PHYSICAL_ADDRESS ResourceTop;
>BOOLEAN  Found;
>
>// Get Virtual Memory Map from the Platform Library @@ -117,6 +121,76
> @@ MemoryPeim (
>  );
>}
>
> +  //
> +  // Reserve the memory space occupied by the firmware volume  //
> +
> +  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> + (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> + (PcdSystemMemorySize);  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> + (PcdFdBaseAddress) + (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> +
> +  // EDK2 does not have the concept of boot firmware copied into DRAM.
> + To avoid the DXE  // core to overwrite this area we must create a
> + memory allocation HOB for the region,  // but this only works if we
split off
> the underlying resource descriptor as well.
> +  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64
> (PcdSystemMemoryBase)) && (FdTop <= SystemMemoryTop)) {
> +Found = FALSE;
> +
> +// Search for System Memory Hob that contains the firmware
> +NextHob.Raw = GetHobList ();
> +while ((NextHob.Raw = GetNextHob
> (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, NextHob.Raw)) != NULL) {
> +  if ((NextHob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> +  (PcdGet64 (PcdFdBaseAddress) >= NextHob.ResourceDescriptor-
> >PhysicalStart) &&
> +  (FdTop <= NextHob.ResourceDescriptor->PhysicalStart +
> NextHob.ResourceDescriptor->ResourceLength))
> +  {
> +ResourceAttributes = NextHob.ResourceDescriptor-
> >ResourceAttribute;
> +ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> +ResourceTop = NextHob.ResourceDescriptor->PhysicalStart +
> + ResourceLength;
> +
> +if (PcdGet64 (PcdFdBaseAddress) == NextHob.ResourceDescriptor-
> >PhysicalStart) {
> +  if (SystemMemoryTop != FdTop) {
> +// Create the System Memory HOB for the firmware with the
non-
> present attribute
> +BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> +ResourceAttributes,
> +PcdGet64 (PcdFdBaseAddress),
> +PcdGet32 (PcdFdSize));
> +
> +// Top of the FD is system memory available for UEFI
> +NextHob.ResourceDescriptor->PhysicalStart +=
PcdGet32(PcdFdSize);
> +NextHob.ResourceDescriptor->ResourceLength -=
> PcdGet32(PcdFdSize);
> +  }
> +} else {
> +  // Create the System Memory HOB for the firmware
> +  BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> +  ResourceAttributes,
> +  PcdGet64 (PcdFdBaseAddress),
> +  PcdGet32 (PcdFdSize));
> +
> +  // Update the 

Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory

[Vladimir Olovyannikov]

> -Original Message-
> From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
> Sent: Tuesday, December 26, 2017 5:59 PM
> To: 'Ard Biesheuvel'
> Cc: 'edk2-devel@lists.01.org'; 'Leif Lindholm'
> Subject: RE: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't
> reserve primary FV in memory
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Tuesday, December 26, 2017 3:07 PM
> > To: Vladimir Olovyannikov
> > Cc: edk2-devel@lists.01.org; Leif Lindholm
> > Subject: Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't
> > reserve primary FV in memory
> >
> > On 26 December 2017 at 21:52, Vladimir Olovyannikov
> > <vladimir.olovyanni...@broadcom.com> wrote:
> > > Hi Ard, Meenakshi,
> > >
> > > I am having a problem I cannot explain the reason for, with this
> > > commit on an ARM64 platform.
> > >
> > >ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in
> > > memory
> > >
> > > Now that PrePi no longer exposes its internal code via special
> > > HOBs,
> > > we can remove the special handling of the primary FV, which needed
> > > to
> > > be reserved so that DXE core could call into the PE/COFF and LZMA
> > > libraries in the PrePi module.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Udit Kumar <udit.ku...@nxp.com>
> > > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > > [ardb: updated commit log]
> > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > > Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
> > >
> > > If a Shell is built "as is" from the source tree, there are no issues.
> > > However, if I slightly modify Shell.c like in the following patch:
> > >
> > > diff --git a/ShellPkg/Application/Shell/Shell.c
> > > b/ShellPkg/Application/Shell/Shell.c
> > > index 577e17311bea..bbbdde8ced96 100644
> > > --- a/ShellPkg/Application/Shell/Shell.c
> > > +++ b/ShellPkg/Application/Shell/Shell.c
> > > @@ -339,6 +339,11 @@ UefiMain (
> > >EFI_HANDLE  ConInHandle;
> > >EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
> > >SPLIT_LIST  *Split;
> > > +  CHAR16  *DelayStr;
> > > +  CHAR16  *NoMapStr;
> > > +  UINTN   DelayVarSize;
> > > +  UINTN   NoMapVarSize;
> > > +  BOOLEAN SilentStart;
> > >
> > >if (PcdGet8(PcdShellSupportLevel) > 3) {
> > >  return (EFI_UNSUPPORTED);
> > > @@ -360,6 +365,7 @@ UefiMain (
> > >ShellInfoObject.PageBreakEnabled=
> > > PcdGetBool(PcdShellPageBreakDefault);
> > >ShellInfoObject.ViewingSettings.InsertMode  =
> > > PcdGetBool(PcdShellInsertModeDefault);
> > >ShellInfoObject.LogScreenCount  = PcdGet8
> > > (PcdShellScreenLogCount  );
> > > +  SilentStart = FALSE;
> > >
> > >//
> > >// verify we dont allow for spec violation @@ -452,6 +458,21 @@
> > > UefiMain (
> > >goto FreeResources;
> > >  }
> > >
> > > +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.Delay) {
> > > +  // Command line has priority over the variable
> > > +  Status = ShellFindEnvVarInList(L"startupdelay", ,
> > > , NULL);
> > > +  if (!EFI_ERROR (Status)) {
> > > +ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn
> > > (DelayStr);
> > > +  }
> > > +}
> > > +
> > > +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) {
> > > +  Status = ShellFindEnvVarInList(L"silentstart", ,
> > > , NULL);
> > > +  if (!EFI_ERROR (Status)) {
> > > +SilentStart = (BOOLEAN)ShellStrToUintn (NoMapStr);
> > > +  }
> > > +}
> > > +
> > >  //
> > >  // If shell support level is >= 1 create the mappings and paths
> > >  //
> > > @@ -492,7 +513,7 @@ UefiMain (
> > >  //
> > >  // Display the version
> > >  //
> > > -if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoVers

Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory

[Vladimir Olovyannikov]

Hi Ard, Meenakshi,

I am having a problem I cannot explain the reason for, with this commit on
an ARM64 platform.

   ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory

Now that PrePi no longer exposes its internal code via special HOBs,
we can remove the special handling of the primary FV, which needed to
be reserved so that DXE core could call into the PE/COFF and LZMA
libraries in the PrePi module.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Udit Kumar 
Signed-off-by: Meenakshi Aggarwal 
[ardb: updated commit log]
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

If a Shell is built "as is" from the source tree, there are no issues.
However, if I slightly modify Shell.c like in the following patch:

diff --git a/ShellPkg/Application/Shell/Shell.c
b/ShellPkg/Application/Shell/Shell.c
index 577e17311bea..bbbdde8ced96 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -339,6 +339,11 @@ UefiMain (
   EFI_HANDLE  ConInHandle;
   EFI_SIMPLE_TEXT_INPUT_PROTOCOL  *OldConIn;
   SPLIT_LIST  *Split;
+  CHAR16  *DelayStr;
+  CHAR16  *NoMapStr;
+  UINTN   DelayVarSize;
+  UINTN   NoMapVarSize;
+  BOOLEAN SilentStart;

   if (PcdGet8(PcdShellSupportLevel) > 3) {
 return (EFI_UNSUPPORTED);
@@ -360,6 +365,7 @@ UefiMain (
   ShellInfoObject.PageBreakEnabled=
PcdGetBool(PcdShellPageBreakDefault);
   ShellInfoObject.ViewingSettings.InsertMode  =
PcdGetBool(PcdShellInsertModeDefault);
   ShellInfoObject.LogScreenCount  = PcdGet8
(PcdShellScreenLogCount  );
+  SilentStart = FALSE;

   //
   // verify we dont allow for spec violation
@@ -452,6 +458,21 @@ UefiMain (
   goto FreeResources;
 }

+if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.Delay) {
+  // Command line has priority over the variable
+  Status = ShellFindEnvVarInList(L"startupdelay", ,
, NULL);
+  if (!EFI_ERROR (Status)) {
+ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn
(DelayStr);
+  }
+}
+
+if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) {
+  Status = ShellFindEnvVarInList(L"silentstart", ,
, NULL);
+  if (!EFI_ERROR (Status)) {
+SilentStart = (BOOLEAN)ShellStrToUintn (NoMapStr);
+  }
+}
+
 //
 // If shell support level is >= 1 create the mappings and paths
 //
@@ -492,7 +513,7 @@ UefiMain (
 //
 // Display the version
 //
-if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoVersion) {
+if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoVersion &&
!SilentStart) {
 ShellPrintHiiEx (
   0,
   gST->ConOut->Mode->CursorRow,
@@ -529,7 +550,7 @@ UefiMain (
 //
 // Display the mapping
 //
-if (PcdGet8(PcdShellSupportLevel) >= 2 &&
!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) {
+if (PcdGet8(PcdShellSupportLevel) >= 2 &&
!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap && !SilentStart) {
   Status = RunCommand(L"map");
   ASSERT_EFI_ERROR(Status);
 }

Shell fails to load.
Here is an excerpt from the debug log:

add-symbol-file
/uefi/Build/StingrayPkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shel
l/DEBUG/Shell.dll 0x8848
Loading driver at 0x0008847F000 EntryPoint=0x0008848 Shell.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8D095118
ProtectUefiImageCommon - 0x8D08ED40
  - 0x8847F000 - 0x00152000
SetUefiImageMemoryAttributes - 0x8847F000 - 0x1000
(0x4008)
SetUefiImageMemoryAttributes - 0x8848 - 0x000E6000
(0x00020008)
SetUefiImageMemoryAttributes - 0x88566000 - 0x0006B000
(0x4008)
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 8D088920
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 8C71AF98
InstallProtocolInterface: 6302D008-7F9B-4F30-87AC-60C9FEF5DA4E 88566710
--- Blank lines -
3h
--- Blank lines -

InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 8C0A1B18
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B A3ABE6B398
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 8C0A1B18
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B A3ABE6B398
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 8C0A1B18
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B A3ABE6B398
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 8C0A1B18
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B A3ABE6B398
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 

Re: [edk2] Storing Non volatile variables on SD/NAND

[Vladimir Olovyannikov]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Monday, September 18, 2017 8:43 AM
> To: Udit Kumar
> Cc: grant.lik...@linaro.org.; edk2-devel@lists.01.org;
> olivier.mar...@arm.com
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
>
> On 18 September 2017 at 06:52, Udit Kumar  wrote:
> > Hi EDK-2 Experts,
> > I am looking to store NV variables on SD/NAND device.
> >
> > While browsing, I came across some old post at link,
> > http://feishare.com/efimail/messages/20130319-1700-
> Re__edk2__Regarding
> > _storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html
> >
> > Looks like, this is possible easily.
>
> That's a bold statement dude :-)
>
> >>> What you need to support Non-Volatile UEFI variables is a
Non-Volatile
> Memory. And also a driver that implements the EFI Firmware Volume Block
> protocol for this NVM device.
> >
> > But MdeModulePkg does Copymem from NV variable start memory to
> some
> > allocated buffers.  With SD/NAND Copymem is not possible, Is this
> > something changes since 2013 or there are some other way to use
> > SD/NAND
> >
>
> No, SD/MMC cannot currently be used as the backing store for the EFI
> variable store. The problem is that the variable protocols are
architectural
> protocols in PI that need to be present before any driver model drivers
are
> dispatched, and so putting the variable store on block devices is not
> something that the PI software architecture currently supports (unless
you
> reimplement the whole driver stack as DXE drivers).
>
> On top of that, it is almost impossible to share a block device that
sits behind
> a controller between the firmware and the OS at runtime (i.e., for
> SetVariable() calls made by efibootmgr under Linux), because only a
single
> agent can take ownership of the controller at any given time. (You
/could/
> dedicate the SD/MMC to the firmware entirely, and boot from SATA or USB,
> but this is out of the question on most platforms that need to use
SD/MMC
> for that variable backing store, i.e., mobile platforms)
>
> The best thing would be for you to convince the hardware architects in
your
> company to design and implement dual-ported SD/MMC controllers that
> allow a single SD/MMC to have two logical views that are independent
> (although I'm unsure if that is even possible in the context of the
SD/MMC
> specifications)
>
> Thanks,
> Ard.
Udit,
Ard is absolutely right.

Following design I had to implement variable store on the EMMC boot
partition 1 (not exactly SD card, but close; the same is applied to NAND I
guess).
To do that I forked VariableRuntime driver and changed it to do cache
writes into the store (just modifying store memory) at runtime.
This is because you cannot share eMMC store between OS (Linux)  and the
UEFI service at the same time, and you cannot predict when OS writes/reads
to/from the EMMC device.
So I do cache writes at runtime (just modifying store in memory), and
flush the store on reboot/shutdown.
For this purpose my ResetSystemLib calls into the Variable service and
forces flush. Variable service reinitiates eMMC controller
and really writes into the store on the eMMC. Real flush is also performed
on ExitBootServices().

As a big drawback an OS should either reset or shutdown (get into UEFI
ResetSystemLib) in order for variable store to be updated physically;
Physical flush is also forced on ExitBootServices - be it a reset command,
or booting an OS.
Just pressing a reset button (example: Linux Kernel panic with no reset)
would cause variable changes for this session to get lost.

Thank you,
Vladimir
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Format SD card while on UEFI shell

[Vladimir Olovyannikov]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Shubham Mittal
> Sent: June-03-17 10:28 PM
> To: Andrew Fish; Blibbet
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Format SD card while on UEFI shell
>
> Thanks Blibbet for your suggestions, i am trying to go through the links
you
> provided..
>
> Thanks Andrew but i think i need to format the sd card as i am making an
> application which tests the block i/o devices and sd card when tested,
gets
> corrupted.
I implemented gpt partitioning tool capable to format partitions/devices
and submitted that to the UEFI community a while ago
(I am away from my PC until next Monday, so you need to search for it
(UefiShellGptCommandLib) if it is urgent for you).
With that one you format your SD card with
gpt fatformat YOUR_SD_SHELL_BLK_ALIAS from within the UEFI Shell.

Thank you,
Vladimir
>
>
> Thanks,
>
> Shubham
>
>
> 
> From: edk2-devel  on behalf of Andrew
> Fish 
> Sent: Friday, June 2, 2017 11:30 PM
> To: Blibbet
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Format SD card while on UEFI shell
>
> The SD spec calls out MBR with a single partition and FAT32 or exFAT
file
> system based on size.  You need to follow those rules if you want to use
it
> with embedded devices. A general purpose OS will treat the SD card like
a
> disk and the format does not really matter.
>
> Thanks,
>
> Andrew Fish
>
> > On Jun 2, 2017, at 10:30 AM, Blibbet  wrote:
> >
> > On 06/02/2017 12:23 AM, Shubham Mittal wrote:
> >> Hi all,
> >>
> >> Is there any utility/tool by which i can format sd card(connected to
> > board) using UEFI shell.
> >>
> >> As of now, i have to detach it and format it and attach it again..
> >
> > I'm not sure this answers your question or not, but Intel has some
> > UEFI disk utilities, but they're pre-EDK2 and non-BSD licensed. So you
> > can fdisk/format from within the UEFI Shell, for FAT volumes. Brian of
> > Intel says that there is work underway to revise these tools, unclear
> > of what (perhaps relicense these tools, make them work with current
> > toolchain, and perhaps transfer them from Intel to UEFI Forum) and
> > when. See this
> > message:
> >
> > https://lists.01.org/pipermail/edk2-devel/2016-October/002734.html
> >
> > Hmm, it looks like URL has changed:
> > https://firmware.intel.com/content/uefidiskutilitiesagreement
> > And the zip is no longer password-protected, thanks Intel lawyers!
> > But the contents appear to be still last-updated in 2011.
> >
> > HTH,
> > Lee Fisher
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: May-30-17 1:17 PM
> To: Vladimir Olovyannikov; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-
> domain platform
>
> On 05/30/17 21:04, Vladimir Olovyannikov wrote:
>
> > So basically my PciHostBridgeLib should treat hostbridges as
> > rootbridges with different segments in this case?
>
> In my opinion, yes.
>
> I would actually put it as
>
>   treat the set of sole root bridges on all the host bridges as multiple
>   root bridges on a single host bridge, just with different segment
>   numbers
>
> The separate segment numbers should be mapped to the separate ECAM
> windows in your PciSegmentLib instance, in my opinion.
OK, got it. Thanks a lot for your help!
>
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: May-30-17 11:50 AM
> To: Vladimir Olovyannikov; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-
> domain platform
>
> On 05/30/17 20:32, Laszlo Ersek wrote:
> > On 05/30/17 18:23, Vladimir Olovyannikov wrote:
> >> Hi,
> >>
> >> I've started PCIe stack implementation design for an armv8 aarch64
> >> platform.
> >> The platform's PCIe represents several host bridges, and each
> >> hostbridge has one rootbridge.
> >> They do not share any resources between each other.
> >> Looking into the PciHostBridgeDxe implementation I can see that it
> >> supports only one hostbridge, and there is a comment:
> >> // Most systems in the world including complex servers have only one
> >> Host Bridge.
> >>
> >> So in my case should I create my own PciHostBridgeDxe driver
> >> supporting multiple hostbridges and do not use the Industry standard
> driver?
> >> I am very new to it, and will appreciate any help or idea.
> >
> > I think you can use PciHostBridgeDxe on this platform:
> >
> > - Implement a PciHostBridgeLib instance (see
> > ) that returns
> > PCI_ROOT_BRIDGE objects with different Segment fields, from
> > PciHostBridgeGetRootBridges().
> >
> > - Implement a PciSegmentLib instance (see
> > ) that routes the config space
> > addresses, encoded by the PCI_SEGMENT_LIB_ADDRESS() macro,
> according
> > to your platform.
> >
> > PciHostBridgeDxe and PciBusDxe should "just work" atop. To my
> > understanding, PciBusDxe delegates all config space accesses to
> > PciHostBridgeDxe, via EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. And
> > PciHostBridgeDxe delegates all config space accesses to the platform's
> > PciSegmentLib.
>
> A small addition. Assuming the general case, i.e. when you have a
> different
> number of root bridges on each of several host bridges, you still have to
> number all those root bridges incrementally, in a curious, flat address
> space.
> And that address space is the PcieRoot(N) device path node that is
> supposed
> to start the "DevicePath" member of each PCI_ROOT_BRIDGE object that
> you return from PciHostBridgeGetRootBridges().
>
> You can read about the PcieRoot() devpath node in the UEFI 2.6 spec.
> Basically, you have
>
> ACPI_HID_DEVICE_PATH.Header = ;
> ACPI_HID_DEVICE_PATH.HID = EFI_PNP_ID (0x0a08);
> ACPI_HID_DEVICE_PATH.UID = ;
>
> The UID values used in these devpath nodes should preferably match the
> UID values of the corresponding PCI Express Root Bridge objects
> (=PNP0A08) that you expose in your ACPI tables (DSDT and/or SSDT).
Thanks for explanation Laszlo,
In my case every hostbridge has exactly one rootbridge. I will follow your
advice and will create
SegmentPciLib and platform's PciHostBridgeLib.
So basically my PciHostBridgeLib should treat hostbridges as rootbridges
with different segments in this case?
>
> Thanks
> Laszlo

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Bill Paul [mailto:wp...@windriver.com]
> Sent: May-30-17 10:34 AM
> To: edk2-de...@ml01.01.org
> Cc: Vladimir Olovyannikov; Ard Biesheuvel; edk2-de...@ml01.01.org
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
multi-PCIe-
> domain platform
>
> Of all the gin joints in all the towns in all the world, Vladimir
Olovyannikov had
> to walk into mine at 09:49:16 on Tuesday 30 May 2017 and say:
>
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: May-30-17 9:35 AM
> > > To: Vladimir Olovyannikov
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: Using a generic PciHostBridgeDxe driver for a
> > > multi-PCIe-domain platform
> > >
> > > On 30 May 2017 at 16:23, Vladimir Olovyannikov
> > >
> > > <vladimir.olovyanni...@broadcom.com> wrote:
> > > > Hi,
> > > >
> > > > I've started PCIe stack implementation design for an armv8 aarch64
> > > > platform.
> > > > The platform's PCIe represents several host bridges, and each
> > > > hostbridge has one rootbridge.
> > > > They do not share any resources between each other.
> > > > Looking into the PciHostBridgeDxe implementation I can see that it
> > > > supports only one hostbridge, and there is a comment:
> > > > // Most systems in the world including complex servers have only
> > > > one Host Bridge.
> > > >
> > > > So in my case should I create my own PciHostBridgeDxe driver
> > > > supporting multiple hostbridges and do not use the Industry
> > > > standard
> > >
> > > driver?
> > >
> > > > I am very new to it, and will appreciate any help or idea.
> > >
> > > As far as I can tell, PciHostBridgeLib allows you to return an
> > > arbitrary number of PCI host bridges, each with their own segment
> > > number. I haven't tried it myself, but it is worth a try whether
> > > returning an array of all host bridges on your platform works as
> > > expected.
> >
> > Thank you Ard,
> > Right, but PciHostBridgeDxe seems to work with one hostbridge.
> > I am confused that
> >
> > // Make sure all root bridges share the same ResourceAssigned value
> >
> > The rootbridges are independent on the platform, and should not share
> > anything. Or am I missing anything?
> > Anyway, I will try to return multiple hostbridges in the
PciHostBridgeLib.
>
> This may be an Intel-ism.
>
> Note that for PCIe, I typically refer to "host bridges" as root
complexes.
>
> On PowerPC SoCs that I've worked with (e.g. Freescale/NXP MPC8548,
> P2020, P4080, T4240) there are often several root complexes. A typical
board
> design may have several PCIe slots where each slot is connected to one
root
> complex in the SoC. Each root complex is therefore the parent of a
separate
> "segment"
> which has its own unique bus/dev/func space. Each root complex has its
own
> bank of registers to control it, including a separate set of
configuration space
> access registers. This means you can have multiple PCIe trees each with
its
> own bus0/dev0/func0 root. There can therefore be several devices with
the
> same bus/dev/func tuple, but which reside on separate segments.
>
> The ARMv8 board you're working with is probably set up the same way.
I've
> only worked with ARM Cortex-A boards and those have all had just one
PCIe
> root complex, but it stands to reason those that have multiple root
> complexes would follow the same pattern as the PPC devices.
>
> Intel systems can (and often do) also have multiple PCIe root complexes,
> however for the sake of backwards compatibility, they all end up sharing
the
> same configuration space access registers (0xCF8/0xCFC or memory mapped
> extended config space) and share a single unified bus/dev/func tree.
I see. Thanks for comprehensive explanation.
In my case root complexes do not share (there is no need for backward
compatibility).
So the question is - can I use PciRootBridgeDxe from MdeModulePkg, which
operates with "rootbridges" and one rootcomplex(?),
or I need to look into the way of creating my own for the platform (say
the way Juno driver was designed initially before switching to the generic
one)?
>
> Note that the tree is not always contiguous. For example, I've seen one
Intel
> board where there was a special PCIe device on bus 128. In the ACPI
tables,
> there were two PCI "segments" described, the second of which
> corresponded to bus 128. There was no switch or br

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: May-30-17 9:35 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-domain
> platform
>
> On 30 May 2017 at 16:23, Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com> wrote:
> > Hi,
> >
> > I've started PCIe stack implementation design for an armv8 aarch64
> > platform.
> > The platform's PCIe represents several host bridges, and each
> > hostbridge has one rootbridge.
> > They do not share any resources between each other.
> > Looking into the PciHostBridgeDxe implementation I can see that it
> > supports only one hostbridge, and there is a comment:
> > // Most systems in the world including complex servers have only one
> > Host Bridge.
> >
> > So in my case should I create my own PciHostBridgeDxe driver
> > supporting multiple hostbridges and do not use the Industry standard
> driver?
> > I am very new to it, and will appreciate any help or idea.
> >
>
> As far as I can tell, PciHostBridgeLib allows you to return an arbitrary
> number
> of PCI host bridges, each with their own segment number. I haven't tried
> it
> myself, but it is worth a try whether returning an array of all host
> bridges on
> your platform works as expected.

Thank you Ard,
Right, but PciHostBridgeDxe seems to work with one hostbridge.
I am confused that

// Make sure all root bridges share the same ResourceAssigned value

The rootbridges are independent on the platform, and should not share
anything. Or am I missing anything?
Anyway, I will try to return multiple hostbridges in the PciHostBridgeLib.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

Hi,

I've started PCIe stack implementation design for an armv8 aarch64
platform.
The platform's PCIe represents several host bridges, and each hostbridge
has one rootbridge.
They do not share any resources between each other.
Looking into the PciHostBridgeDxe implementation I can see that it
supports only one hostbridge, and there is a comment:
// Most systems in the world including complex servers have only one Host
Bridge.

So in my case should I create my own PciHostBridgeDxe driver supporting
multiple hostbridges and do not use the Industry standard driver?
I am very new to it, and will appreciate any help or idea.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Creating of a memory hole in System memory

[Vladimir Olovyannikov]

Hello,

I need to reserve an area in the System memory, which should be
write-protected, so that neither UEFI nor Linux could write anything into
it.
If it matters, the platform is ARMv8 64-bit.
I have DDR RAM starting from 0x8000 with size 0x8000, and need to
carve out an area of 0x10 at address 0x8f00 which UEFI should not
touch.
What is the proper way of doing that? I tried creating of a reserved memory
HOB using this:
BuildResourceDescriptorHob (
  MemType,
  ResourceAttributes,
  Address,
  MemSize);
Where ResourceAttributes are
EFI_RESOURCE_ATTRIBUTE_PRESENT| \
EFI_RESOURCE_ATTRIBUTE_INITIALIZED| \
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE| \
EFI_RESOURCE_ATTRIBUTE_WRITE_PROTECTABLE  | \
EFI_RESOURCE_ATTRIBUTE_WRITE_PROTECTED| \
EFI_RESOURCE_ATTRIBUTE_TESTED

Before that, I declared System memory 0x8000 with size 0x8000 with
DDR_ATTRIBUTES_CACHED for ARM Virtual memory map.
MemoryInitPei (ArmPlatformPkg)  builds a Memory HOB for region 0x8000,
with size 0x8000.
Eventually in the DxeCore in CoreInitializeGcdService() I run into an
ASSERT:

ASSERT [DxeCore] /uefi/MdeModulePkg/Core/Dxe/Gcd/Gcd.c(2467):
(Descriptor.GcdMemoryType == EfiGcdMemoryTypeSystemMemory) ||
(Descriptor.GcdMemoryType == EfiGcdMemoryTypeMoreReliable)

ASSERT ((Descriptor.GcdMemoryType == EfiGcdMemoryTypeSystemMemory) ||
(Descriptor.GcdMemoryType == EfiGcdMemoryTypeMoreReliable));

with GcdMemoryType EfiGcdMemoryTypeNonExistent for Descriptor (BaseAddress:
0x8f10, length 0x7f0f0).

Please help me to figure out what I am doing wrong.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

[Vladimir Olovyannikov]

I see. Thank you for your input.
I wish I could use Realtek device, but they have only x86 based binaries
available, whereas I need arm64...
Anyway, I can port Linux driver to the Uefi.

Thank you,
Vladimir

On Apr 10, 2017 6:53 PM, "Tian, Feng" <feng.t...@intel.com> wrote:

Ax88772b driver's quality is better than Ax88772. But all of them aren't
handled no-data case without latency. So if possible, I would suggest you
to not use Ax88772x device. Realtek usb2lan is a good choice but the
disadvantage of it is there looks like has no corresponding open-source
UEFI driver for use.

Thanks
Feng

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Tuesday, April 11, 2017 12:14 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel@lists.01.org
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi Feng,

Thank you for your explanation.
I have Cisco 300M AX88772A-based adapter, so AX88772 (with no "b") driver
was picked up.
I had to modify it with circular buffer to get ping and tftp going. Also I
had to receive packets in GetStatus rather than in SN_Receive (otherwise I
could never get into the Shell).
This way I have ping with response time of approx. 200ms, and tftp working,
albeit it is slow.
So do you suggest me to use Ax88772b driver for AX88772A/AX88772
usb-ethernet adapter?
Also maybe you know if there are UEFI drivers for other USB-ethernet
adapters (maybe 1G?) available somewhere?

Thank you,
Vladimir
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: April-09-17 9:49 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi, Vladimir,

Which usb2lan driver you are using for AX88772 adpater? The one in
OptionRomPkg\Bus\Usb\UsbNetworking has bug on the polling performance. The
one in OptionRomPkg\Bus\Usb\UsbNetworking\Ax88772b is better but if there
is no data received, the polling operation still wastes some time.

The root cause about the low performance of polling is because USB spec
doesn't clearly define which value should be returned if user requests Bulk
Read operation but there is no data. Some data-streaming usb devices, such
as Realtek usb2lan, return success with data length setting to 0, but
others, such as AX88772, just keep active and wait for data always. From
BIOS view, we have to return EFI_TIMEOUT for latter case to avoid system
hang. That's why you see the low performance for polling operation in
no-data case.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Vladimir Olovyannikov
Sent: Saturday, April 8, 2017 3:06 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi,

I would like to enable Ethernet using USB-Ethernet AX88772 adapter in the
UEFI on an armv8 arm64 platform.
Ethernet polling is done by MnpPoll() periodically. This creates a burden
on the system so that UEFI boots in 1 minute to the Shell due to receive
polling.
The USB operation is very resource expensive which causes UEFI to choke up.
There is DisableBackgroundPolling option in the EFI_MANAGED_NETWORK_CONFIG_DATA
structure, but it is turned off by all other drivers (DNSDxe, Ip4Dxe,
ArpDxe...).
Can anybody advise what I could do?
Mass storage/keyboard/etc. all work fine...

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

[Vladimir Olovyannikov]

Hi Feng,

Thank you for your explanation.
I have Cisco 300M AX88772A-based adapter, so AX88772 (with no "b") driver
was picked up.
I had to modify it with circular buffer to get ping and tftp going. Also I
had to receive packets in GetStatus rather than in SN_Receive (otherwise I
could never get into the Shell).
This way I have ping with response time of approx. 200ms, and tftp
working, albeit it is slow.
So do you suggest me to use Ax88772b driver for AX88772A/AX88772
usb-ethernet adapter?
Also maybe you know if there are UEFI drivers for other USB-ethernet
adapters (maybe 1G?) available somewhere?

Thank you,
Vladimir
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: April-09-17 9:49 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: [edk2] Using USB-Ethernet adapter in UEFI on an arm64
platform

Hi, Vladimir,

Which usb2lan driver you are using for AX88772 adpater? The one in
OptionRomPkg\Bus\Usb\UsbNetworking has bug on the polling performance. The
one in OptionRomPkg\Bus\Usb\UsbNetworking\Ax88772b is better but if there
is no data received, the polling operation still wastes some time.

The root cause about the low performance of polling is because USB spec
doesn't clearly define which value should be returned if user requests
Bulk Read operation but there is no data. Some data-streaming usb devices,
such as Realtek usb2lan, return success with data length setting to 0, but
others, such as AX88772, just keep active and wait for data always. From
BIOS view, we have to return EFI_TIMEOUT for latter case to avoid system
hang. That's why you see the low performance for polling operation in
no-data case.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Vladimir Olovyannikov
Sent: Saturday, April 8, 2017 3:06 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

Hi,

I would like to enable Ethernet using USB-Ethernet AX88772 adapter in the
UEFI on an armv8 arm64 platform.
Ethernet polling is done by MnpPoll() periodically. This creates a burden
on the system so that UEFI boots in 1 minute to the Shell due to receive
polling.
The USB operation is very resource expensive which causes UEFI to choke
up.
There is DisableBackgroundPolling option in the
EFI_MANAGED_NETWORK_CONFIG_DATA structure, but it is turned off by all
other drivers (DNSDxe, Ip4Dxe, ArpDxe...).
Can anybody advise what I could do?
Mass storage/keyboard/etc. all work fine...

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Using USB-Ethernet adapter in UEFI on an arm64 platform

[Vladimir Olovyannikov]

Hi,

I would like to enable Ethernet using USB-Ethernet AX88772 adapter in the
UEFI on an armv8 arm64 platform.
Ethernet polling is done by MnpPoll() periodically. This creates a burden
on the system so that UEFI boots in 1 minute to the Shell due to receive
polling.
The USB operation is very resource expensive which causes UEFI to choke
up.
There is DisableBackgroundPolling option in the
EFI_MANAGED_NETWORK_CONFIG_DATA structure, but it is turned off by all
other drivers (DNSDxe, Ip4Dxe, ArpDxe...).
Can anybody advise what I could do?
Mass storage/keyboard/etc. all work fine...

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Fix Shell not able to run startup.nsh from first location

[Vladimir Olovyannikov]

If startup.nsh is placed into first location (embedded into the firmware 
image), 
and the current directory has not been set (Internal Shell has just started), 
Shell cannot execute startup because of the bug in the DoStartupScript: 
after finding the correct path of the startup.nsh from the "First location" 
and opening the file, and getting of the file handle, the correct path is 
forgotten, and then RunScriptFile() receives just the name of the file 
(from mStartupScript ariable). 
It then attempts to check if this is a file with ShellIsFile() which fails 
with "EFI_INVALID_PARAMETER" (current directory is NULL, so it cannot get 
fully qualified file name), which causes Shell to exit and unload. 
This patch fixes the issue.
---
 ShellPkg/Application/Shell/Shell.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/ShellPkg/Application/Shell/Shell.c 
b/ShellPkg/Application/Shell/Shell.c
index 731ba187e4d9..4967fe598448 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -1162,6 +1162,7 @@ DoStartupScript(
   Key.UnicodeChar = CHAR_NULL;
   Key.ScanCode= 0;
   FileHandle  = NULL;
+  FileStringPath = NULL;
 
   if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.Startup && 
ShellInfoObject.ShellInitSettings.FileName != NULL) {
 //
@@ -1228,7 +1229,6 @@ DoStartupScript(
   //
   MapName = 
ShellInfoObject.NewEfiShellProtocol->GetMapFromDevicePath();
   if (MapName != NULL) {
-FileStringPath = NULL;
 NewSize = 0;
 FileStringPath = StrnCatGrow(, , MapName, 0);
 if (FileStringPath == NULL) {
@@ -1242,10 +1242,10 @@ DoStartupScript(
   PathRemoveLastItem(FileStringPath);
   FileStringPath = StrnCatGrow(, , mStartupScript, 
0);
   Status = 
ShellInfoObject.NewEfiShellProtocol->OpenFileByName(FileStringPath, 
, EFI_FILE_MODE_READ);
-  FreePool(FileStringPath);
 }
   }
   if (EFI_ERROR(Status)) {
+SHELL_FREE_NON_NULL (FileStringPath);
 NamePath = FileDevicePath (NULL, mStartupScript);
 NewPath = AppendDevicePathNode (ImagePath, NamePath);
 FreePool(NamePath);
@@ -1254,15 +1254,21 @@ DoStartupScript(
 // Try the location
 //
 Status = InternalOpenFileDevicePath(NewPath, , 
EFI_FILE_MODE_READ, 0);
-FreePool(NewPath);
+if (!EFI_ERROR (Status)) {
+  FileStringPath = gEfiShellProtocol->GetFilePathFromDevicePath(NewPath);
+  if (FileStringPath == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+  }
+}
+FreePool (NewPath);
   }
   //
   // If we got a file, run it
   //
   if (!EFI_ERROR(Status) && FileHandle != NULL) {
-Status = RunScriptFile (mStartupScript, FileHandle, L"", 
ShellInfoObject.NewShellParametersProtocol);
-ShellInfoObject.NewEfiShellProtocol->CloseFile(FileHandle);
+Status = RunScriptFile (FileStringPath, FileHandle, L"", 
ShellInfoObject.NewShellParametersProtocol);
   } else {
+SHELL_FREE_NON_NULL (FileStringPath);
 FileStringPath = ShellFindFilePath(mStartupScript);
 if (FileStringPath == NULL) {
   //
@@ -1272,10 +1278,13 @@ DoStartupScript(
   ASSERT(FileHandle == NULL);
 } else {
   Status = RunScriptFile(FileStringPath, NULL, L"", 
ShellInfoObject.NewShellParametersProtocol);
-  FreePool(FileStringPath);
 }
   }
 
+  SHELL_FREE_NON_NULL (FileStringPath);
+  if (FileHandle != NULL) {
+ShellInfoObject.NewEfiShellProtocol->CloseFile(FileHandle);
+  }
 
   return (Status);
 }
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Minimum RAM requirements for UEFI (AARCH64)

[Vladimir Olovyannikov]

Hello,

I could not find this in the spec, but what is the minimum RAM required
for the UEFI?
We are at the very early stage right now, and DDR will not be available
for a while. The platform is AARCH64-based.
Can I fit UEFI into 8MB of RAM (actually I might get 64MB, so can I fit it
into 64MB)?

Because the target platform is not yet available,  I experimented with an
ref. platform (also AARCH64, slightly older)
shrinking SystemMemorySize.
I tried to cut off as many things as possible (no Shell, very limited set
of drivers),
tried to replace real libraries with NULL "stubs", yet  I cannot get UEFI
running with less than 128MB of RAM...

I would appreciate any  advice...

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Added GPT Shell Application/Library

[Vladimir Olovyannikov]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>

This tool allows managing (create, delete, modify, fat format) of GPT
partitions from within UEFI Shell. See usage examples in the .uni file

Hope that this tool can be useful for anybody wishing to manipulate GPT
partitions from within the UEFI Shell.
I am planning to create a shared library for GPT-related activities.
But because of time shortage this could happen much later than planned.

This is the final version of the tool which we are going to use.
If anybody wants to use this tool and create a separate library please
by all means go ahead.
---
 .../Library/UefiShellGptCommandLib/FatFormat.c |  693 +++
 .../Library/UefiShellGptCommandLib/FatFormat.h |  115 ++
 .../Library/UefiShellGptCommandLib/GptWorker.c | 1922 
 .../Library/UefiShellGptCommandLib/GptWorker.h |  188 ++
 .../UefiShellGptCommandLib.c   | 1267 +
 .../UefiShellGptCommandLib.inf |   74 +
 .../UefiShellGptCommandLib.uni |  113 ++
 ShellPkg/ShellPkg.dec  |1 +
 ShellPkg/ShellPkg.dsc  |4 +
 9 files changed, 4377 insertions(+)
 create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c
 create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.h
 create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.c
 create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.h
 create mode 100644 
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.c
 create mode 100644 
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.inf
 create mode 100644 
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.uni

diff --git a/ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c 
b/ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c
new file mode 100644
index ..dea8505c49ff
--- /dev/null
+++ b/ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c
@@ -0,0 +1,693 @@
+/** @file
+
+  Copyright (c) 2003 - 2012, Rob Riglar, Ultra-Embedded.com. All rights 
reserved
+  Copyright (c) 2016, Broadcom. 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 "FatFormat.h"
+
+//-
+// Tables
+//-
+typedef struct
+{
+  UINT64  Sectors;
+  UINT8   SectorsPerCluster;
+} SectorsPerClusterTable;
+
+STATIC SectorsPerClusterTable ClusterSizeTable16[] =
+{
+  { 32680, 2 }, // 16MB - 1K
+  { 262144, 4 },// 128MB - 2K
+  { 524288, 8 },// 256MB - 4K
+  { 1048576, 16 },  // 512MB - 8K
+  { 2097152, 32 },  // 1GB - 16K
+  { 4194304, 64 },  // 2GB - 32K
+  { 8388608, 128 }, // 2GB - 64K [Warning only supported by Windows XP onwards]
+  { 0, 0 }  // Invalid
+};
+
+STATIC SectorsPerClusterTable ClusterSizeTable32[] =
+{
+  { 532480, 1 },  // 260MB - 512b
+  { 16777216, 8 },// 8GB - 4K
+  { 33554432, 16 },   // 16GB - 8K
+  { 67108864, 32 },   // 32GB - 16K
+  { 0x, 64 }, // >32GB - 32K
+  { 0, 0 }// Invalid
+};
+
+/**
+  Calculates LBA corresponding to the cluster number.
+
+  @param  FS Pointer to the FAT_FS structure
+  @param  ClusterNumber  Cluster number to get LBA for
+
+  @return EFI_LBALBA corresponding to the given cluster number
+**/
+STATIC
+EFI_LBA LbaOfCluster (
+  IN FATFS  *Fs,
+  IN UINT64 ClusterNumber
+  )
+{
+  if (Fs->FatType == FAT_TYPE_16)
+return (Fs->ClusterBeginLba +
+(Fs->RootEntryCount * 32 / FAT_SECTOR_SIZE) +
+((ClusterNumber - 2) * Fs->SectorsPerCluster));
+  else
+return ((Fs->ClusterBeginLba +
+ ((ClusterNumber - 2) * Fs->SectorsPerCluster)));
+}
+
+/**
+  Calculates the cluster size to be used.
+
+  @param  SectorsRequested number of sectors
+  @param  IsFat32Whether FAT32 is to be used
+
+  @return UINT8  Cluster size from the table
+
+**/
+STATIC
+UINT8 CalcClusterSize (
+  IN UINTN   Sectors,
+  IN BOOLEAN IsFat32)
+{
+  UINTN Index;
+
+  if (!IsFat32) {
+for (Index = 0; ClusterSizeTable16[Index].SectorsPerCluster != 0; Index++)
+  if (Sectors <= ClusterSizeTable16[Index].Sectors)
+return ClusterSizeTable16[Index].SectorsPerCluster;
+  } else {
+for (Index = 0; Clust

Re: [edk2] [PATCH] GPT Shell Application/Library

[Vladimir Olovyannikov]

OK,
Thank you for advice.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Shah, Tapan
> Sent: October-18-16 11:04 AM
> To: Carsey, Jaben; Vladimir Olovyannikov; Michael Zimmermann
> Cc: Ni, Ruiyu; Arshi, Shala; edk2-devel@lists.01.org; Laszlo Ersek
> Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
>
> 1. Create this new shared library in MdeModulePkg.
> 2. For parameters: Other than standard parameters defined in Shell
> specification I would suggest to follow single character flag where it
> makes
> sense (example: -d to delete, -l to list, -c to create etc.) and if more
> than one
> operation can be tied with one flag, then add individual value as a flag
> value.
> There are plenty of ShellPkg commands you can use as a reference.
>
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Tuesday, October 18, 2016 12:04 PM
> To: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>; Shah,
> Tapan <tapands...@hpe.com>; Michael Zimmermann
> <sigmaepsilo...@gmail.com>
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Arshi, Shala <shala.ar...@intel.com>;
> edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Laszlo Ersek
> <ler...@redhat.com>; Carsey, Jaben <jaben.car...@intel.com>
> Subject: RE: [edk2] [PATCH] GPT Shell Application/Library
>
> For the standards, I would try to use the UEFI Shell Spec for some
> parameters.  For Example:
> -v for verbose
> -h for help
> -sfo for standard format output
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Vladimir Olovyannikov
> > Sent: Tuesday, October 18, 2016 9:58 AM
> > To: Shah, Tapan <tapands...@hpe.com>; Carsey, Jaben
> > <jaben.car...@intel.com>; Michael Zimmermann
> > <sigmaepsilo...@gmail.com>
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Arshi, Shala
> > <shala.ar...@intel.com>; edk2-devel@lists.01.org
> > <edk2-de...@ml01.01.org>; Laszlo Ersek <ler...@redhat.com>
> > Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
> > Importance: High
> >
> > Thank you all for comments,
> >
> > So to summarize the discussion:
> >
> > 1. I will create a Shell library which would perform all GPT operations.
> >  Part of PartitionDxe will also be in that library so PartitionDxe
> > will be using it.
> >  The gpt Shell tool will also be using it.
> > 2.  Refactor the parameters of the gpt utility to make it similar to
> > other existing Shell commands.
> >   BTW Is there any document describing Shell utility parameters'
> > standards?
> >
> > Please let me know if you have other suggestions.
> >
> > Thank you,
> > Vladimir
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Shah, Tapan
> > Sent: October-18-16 6:59 AM
> > To: Carsey, Jaben; Vladimir Olovyannikov; Michael Zimmermann
> > Cc: Ni, Ruiyu; Arshi, Shala; edk2-devel@lists.01.org; Laszlo Ersek
> > Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
> >
> > Thanks for the contribution Vladimir!
> >
> > Few comments:
> > 1. It's better to refactor the code now before commit and move GPT
> > related code outside ShellPkg and create a shared library.
> > 2. CLI parameters of this utility are too complex and need to be
> > refactored to make it similar to other existing Shell commands.
> >
> > Thanks,
> > Tapan
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Carsey, Jaben
> > Sent: Monday, October 17, 2016 12:56 PM
> > To: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>;
> > Michael Zimmermann <sigmaepsilo...@gmail.com>
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Arshi, Shala
> > <shala.ar...@intel.com>; edk2-devel@lists.01.org
> > <edk2-de...@ml01.01.org>; Carsey, Jaben <jaben.car...@intel.com>;
> > Laszlo Ersek <ler...@redhat.com>
> > Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
> >
> > To the old question about license: I asked our people to check and was
> > told that the license is compatible with our BSD and ok by Intel.
> >
> > To the technical content – I really like this idea of a shared library.
> > That would be a great way to share code and not have as much duplicate.
> >
> > -Jaben
> >
> > From: Vladimir Olovyannikov
> >

Re: [edk2] [PATCH] GPT Shell Application/Library

[Vladimir Olovyannikov]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: October-18-16 10:24 AM
> To: Vladimir Olovyannikov; Shah, Tapan; Carsey, Jaben; Michael Zimmermann
> Cc: Ni, Ruiyu; Arshi, Shala; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
>
> On 10/18/16 18:58, Vladimir Olovyannikov wrote:
> > Thank you all for comments,
> >
> > So to summarize the discussion:
> >
> > 1. I will create a Shell library which would perform all GPT operations.
> >  Part of PartitionDxe will also be in that library so PartitionDxe
> > will be using it.
> >  The gpt Shell tool will also be using it.
>
> I think you might want to place the library class header file, and the
> library
> instance, under MdeModulePkg. It's okay for the shell application (or
> shell
> libraries) to depend on library classes / library instances from
> MdeModulePkg, but -- I think -- it's not okay for a driver in
> MdeModulePkg,
> such as PartitionDxe, to depend on a class + instance from under ShellPkg.
Laszlo,
I think PartitionDxe will depend on the GPT shared library (which will have
nothing to do to the ShellPkg),
as well as gpt tool (Shell library/application) will depend on that shared
library as well to get information regarding partitions and
to perform GPT management.

Thank you,
Vladimir
>
> Thanks!
> Laszlo
>
> > 2.  Refactor the parameters of the gpt utility to make it similar to
> > other existing Shell commands.
> >   BTW Is there any document describing Shell utility parameters'
> > standards?
> >
> > Please let me know if you have other suggestions.
> >
> > Thank you,
> > Vladimir
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Shah, Tapan
> > Sent: October-18-16 6:59 AM
> > To: Carsey, Jaben; Vladimir Olovyannikov; Michael Zimmermann
> > Cc: Ni, Ruiyu; Arshi, Shala; edk2-devel@lists.01.org; Laszlo Ersek
> > Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
> >
> > Thanks for the contribution Vladimir!
> >
> > Few comments:
> > 1. It's better to refactor the code now before commit and move GPT
> > related code outside ShellPkg and create a shared library.
> > 2. CLI parameters of this utility are too complex and need to be
> > refactored to make it similar to other existing Shell commands.
> >
> > Thanks,
> > Tapan
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Carsey, Jaben
> > Sent: Monday, October 17, 2016 12:56 PM
> > To: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>;
> > Michael Zimmermann <sigmaepsilo...@gmail.com>
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Arshi, Shala
> > <shala.ar...@intel.com>; edk2-devel@lists.01.org
> > <edk2-de...@ml01.01.org>; Carsey, Jaben <jaben.car...@intel.com>;
> > Laszlo Ersek <ler...@redhat.com>
> > Subject: Re: [edk2] [PATCH] GPT Shell Application/Library
> >
> > To the old question about license: I asked our people to check and was
> > told that the license is compatible with our BSD and ok by Intel.
> >
> > To the technical content – I really like this idea of a shared library.
> > That would be a great way to share code and not have as much duplicate.
> >
> > -Jaben
> >
> > From: Vladimir Olovyannikov
> > [mailto:vladimir.olovyanni...@broadcom.com]
> > Sent: Monday, October 17, 2016 10:52 AM
> > To: Michael Zimmermann <sigmaepsilo...@gmail.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>; Carsey, Jaben
> > <jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> > edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
> > Subject: RE: [edk2] [PATCH] GPT Shell Application/Library
> > Importance: High
> >
> > Hi Michael,
> > I am absolutely agree with your proposal.
> >
> > In the gpt Shell library/application I had to “borrow” some stuff from
> > PartitionDxe.c to not reinvent a  wheel.
> > If the PartitionDxe maintainer agrees to have a separate library
> > available for everybody, I would move all the GPT-related stuff from
> > the GptWorker (and partially from the PartitionDxe itself) to that
> independent library.
> > This could be a longer-term task.
> > Right now I just wanted to share the tool which could be useful for
> > anybody who would wish to manage GPT partitions (and/or do a FAT32
> > format of either a disk or a GPT partition) from within the Shell. What
> &g

Re: [edk2] [PATCH] GPT Shell Application/Library

[Vladimir Olovyannikov]

Thank you all for comments,

So to summarize the discussion:

1. I will create a Shell library which would perform all GPT operations.
 Part of PartitionDxe will also be in that library so PartitionDxe will
be using it.
 The gpt Shell tool will also be using it.
2.  Refactor the parameters of the gpt utility to make it similar to other
existing Shell commands.
  BTW Is there any document describing Shell utility parameters'
standards?

Please let me know if you have other suggestions.

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shah,
Tapan
Sent: October-18-16 6:59 AM
To: Carsey, Jaben; Vladimir Olovyannikov; Michael Zimmermann
Cc: Ni, Ruiyu; Arshi, Shala; edk2-devel@lists.01.org; Laszlo Ersek
Subject: Re: [edk2] [PATCH] GPT Shell Application/Library

Thanks for the contribution Vladimir!

Few comments:
1. It's better to refactor the code now before commit and move GPT related
code outside ShellPkg and create a shared library.
2. CLI parameters of this utility are too complex and need to be refactored
to make it similar to other existing Shell commands.

Thanks,
Tapan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Monday, October 17, 2016 12:56 PM
To: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>; Michael
Zimmermann <sigmaepsilo...@gmail.com>
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Arshi, Shala <shala.ar...@intel.com>;
edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Carsey, Jaben
<jaben.car...@intel.com>; Laszlo Ersek <ler...@redhat.com>
Subject: Re: [edk2] [PATCH] GPT Shell Application/Library

To the old question about license: I asked our people to check and was told
that the license is compatible with our BSD and ok by Intel.

To the technical content – I really like this idea of a shared library.
That would be a great way to share code and not have as much duplicate.

-Jaben

From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Monday, October 17, 2016 10:52 AM
To: Michael Zimmermann <sigmaepsilo...@gmail.com>
Cc: Laszlo Ersek <ler...@redhat.com>; Carsey, Jaben
<jaben.car...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
Subject: RE: [edk2] [PATCH] GPT Shell Application/Library
Importance: High

Hi Michael,
I am absolutely agree with your proposal.

In the gpt Shell library/application I had to “borrow” some stuff from
PartitionDxe.c to not reinvent a  wheel.
If the PartitionDxe maintainer agrees to have a separate library available
for everybody, I would move all the GPT-related stuff from the GptWorker
(and partially from the PartitionDxe itself) to that independent library.
This could be a longer-term task.
Right now I just wanted to share the tool which could be useful for anybody
who would wish to manage GPT partitions (and/or do a FAT32 format of either
a disk or a GPT partition) from within the Shell. What do you think?

Thank you,
Vladimir
From: Michael Zimmermann
[mailto:sigmaepsilo...@gmail.com<mailto:sigmaepsilo...@gmail.com>]
Sent: October-17-16 12:25 AM
To: Vladimir Olovyannikov
Cc: Laszlo Ersek; Jaben Carsey; Ni, Ruiyu;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: Re: [edk2] [PATCH] GPT Shell Application/Library

Hi,

wouldn't it be better to make a generic gpt parsing library which is
independent of the shell so both the shell and PartitionDxe can use it?
It may also be useful for other applications which need additional
information like the gpt partition names.

Thanks
Michael

On Mon, Oct 17, 2016 at 8:49 AM, Vladimir Olovyannikov
<vladimir.olovyanni...@broadcom.com<mailto:vladimir.olovyanni...@broadcom.com>>
wrote:
Thank you Laszlo,

Sorry, I missed the fields; it is my first contribution, I will add the
required lines, review the source according to your comments and will
resubmit the patch.
So do you think the command should be _gpt instead of gpt? I was following
TFTP and SF commands as a template.

Thank you,
Vladimir

On Oct 16, 2016 1:05 PM, "Laszlo Ersek"
<ler...@redhat.com<mailto:ler...@redhat.com>> wrote:
>
> On 10/16/16 07:23, Vladimir Olovyannikov wrote:
> > This allows managing (create, delete, modify, fat format) of GPT
> > partitions from within UEFI Shell.
> > Syntax:
> > gpt  [device_mapped_name] [parameters...] See usage
> > examples in the .uni file
> > ---
> >  .../Library/UefiShellGptCommandLib/FatFormat.c |  611 +++
> >  .../Library/UefiShellGptCommandLib/FatFormat.h |  111 ++
> >  .../Library/UefiShellGptCommandLib/GptWorker.c | 1902

> >  .../Library/UefiShellGptCommandLib/GptWorker.h |  186 ++
> >  .../UefiShellGptCommandLib.c   | 1135 
>

Re: [edk2] [PATCH] GPT Shell Application/Library

[Vladimir Olovyannikov]

Hi Michael,

I am absolutely agree with your proposal.



In the gpt Shell library/application I had to “borrow” some stuff from
PartitionDxe.c to not reinvent a  wheel.

If the PartitionDxe maintainer agrees to have a separate library available
for everybody,
I would move all the GPT-related stuff from the GptWorker (and partially
from the PartitionDxe itself) to that independent library.
This could be a longer-term task.

Right now I just wanted to share the tool which could be useful for anybody
who would wish to manage
GPT partitions (and/or do a FAT32 format of either a disk or a GPT
partition) from within the Shell. What do you think?



Thank you,

Vladimir

*From:* Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
*Sent:* October-17-16 12:25 AM
*To:* Vladimir Olovyannikov
*Cc:* Laszlo Ersek; Jaben Carsey; Ni, Ruiyu; edk2-devel@lists.01.org
*Subject:* Re: [edk2] [PATCH] GPT Shell Application/Library



Hi,



wouldn't it be better to make a generic gpt parsing library which is
independent of the shell so both the shell and PartitionDxe can use it?

It may also be useful for other applications which need additional
information like the gpt partition names.



Thanks

Michael



On Mon, Oct 17, 2016 at 8:49 AM, Vladimir Olovyannikov <
vladimir.olovyanni...@broadcom.com> wrote:

Thank you Laszlo,

Sorry, I missed the fields; it is my first contribution, I will add the
required lines, review the source according to your comments and will
resubmit the patch.
So do you think the command should be _gpt instead of gpt? I was following
TFTP and SF commands as a template.

Thank you,
Vladimir


On Oct 16, 2016 1:05 PM, "Laszlo Ersek" <ler...@redhat.com> wrote:
>
> On 10/16/16 07:23, Vladimir Olovyannikov wrote:
> > This allows managing (create, delete, modify, fat format) of GPT
> > partitions from within UEFI Shell.
> > Syntax:
> > gpt  [device_mapped_name] [parameters...]
> > See usage examples in the .uni file
> > ---
> >  .../Library/UefiShellGptCommandLib/FatFormat.c |  611 +++
> >  .../Library/UefiShellGptCommandLib/FatFormat.h |  111 ++
> >  .../Library/UefiShellGptCommandLib/GptWorker.c | 1902

> >  .../Library/UefiShellGptCommandLib/GptWorker.h |  186 ++
> >  .../UefiShellGptCommandLib.c   | 1135 
> >  .../UefiShellGptCommandLib.inf |   79 +
> >  .../UefiShellGptCommandLib.uni |  117 ++
> >  ShellPkg/ShellPkg.dec  |1 +
> >  ShellPkg/ShellPkg.dsc  |4 +
> >  9 files changed, 4146 insertions(+)
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.h
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.c
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.h
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.c
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.inf
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.uni
>
> This looks like a supremely welcome, long-awaited addition (latest
> request:
> <https://lists.01.org/pipermail/edk2-devel/2016-October/002667.html>),
> but it really needs your Signed-off-by, and the Contributed-under line
> above it:
>
> ShellPkg/Contributions.txt
>
> I would also suggest (simply based on what I've seen elsewhere in edk2)
> to keep the copyright notices tightly collected in the file headings.
>
> Someone will have to go over all the licenses too -- does the "Marvell
> BSD License Option" for example correspond to the 3-clause BSDL?
>
> On the technical side, I believe that as long as a shell command (or a
> command option) is not standardized (in the shell spec), it usually
> starts with an underscore (_), so as to prevent future name collisions.
> (I could be wrong about this -- I now recall the TFTP command, which is
> also not in the 2.2 spec.)
>
> Just my two cents.
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] GPT Shell Application/Library

[Vladimir Olovyannikov]

Thank you Laszlo,

Sorry, I missed the fields; it is my first contribution, I will add the
required lines, review the source according to your comments and will
resubmit the patch.
So do you think the command should be _gpt instead of gpt? I was following
TFTP and SF commands as a template.

Thank you,
Vladimir

On Oct 16, 2016 1:05 PM, "Laszlo Ersek" <ler...@redhat.com> wrote:
>
> On 10/16/16 07:23, Vladimir Olovyannikov wrote:
> > This allows managing (create, delete, modify, fat format) of GPT
> > partitions from within UEFI Shell.
> > Syntax:
> > gpt  [device_mapped_name] [parameters...]
> > See usage examples in the .uni file
> > ---
> >  .../Library/UefiShellGptCommandLib/FatFormat.c |  611 +++
> >  .../Library/UefiShellGptCommandLib/FatFormat.h |  111 ++
> >  .../Library/UefiShellGptCommandLib/GptWorker.c | 1902

> >  .../Library/UefiShellGptCommandLib/GptWorker.h |  186 ++
> >  .../UefiShellGptCommandLib.c   | 1135 
> >  .../UefiShellGptCommandLib.inf |   79 +
> >  .../UefiShellGptCommandLib.uni |  117 ++
> >  ShellPkg/ShellPkg.dec  |1 +
> >  ShellPkg/ShellPkg.dsc  |4 +
> >  9 files changed, 4146 insertions(+)
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.c
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/FatFormat.h
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.c
> >  create mode 100644 ShellPkg/Library/UefiShellGptCommandLib/GptWorker.h
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.c
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.inf
> >  create mode 100644
ShellPkg/Library/UefiShellGptCommandLib/UefiShellGptCommandLib.uni
>
> This looks like a supremely welcome, long-awaited addition (latest
> request:
> <https://lists.01.org/pipermail/edk2-devel/2016-October/002667.html>),
> but it really needs your Signed-off-by, and the Contributed-under line
> above it:
>
> ShellPkg/Contributions.txt
>
> I would also suggest (simply based on what I've seen elsewhere in edk2)
> to keep the copyright notices tightly collected in the file headings.
>
> Someone will have to go over all the licenses too -- does the "Marvell
> BSD License Option" for example correspond to the 3-clause BSDL?
>
> On the technical side, I believe that as long as a shell command (or a
> command option) is not standardized (in the shell spec), it usually
> starts with an underscore (_), so as to prevent future name collisions.
> (I could be wrong about this -- I now recall the TFTP command, which is
> also not in the 2.2 spec.)
>
> Just my two cents.
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

[Vladimir Olovyannikov]

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah <tapands...@hpe.com>
Cc: Jaben Carsey <jaben.car...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..8db18b3b210f 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,9 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
+}
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (, NULL, 
(VOID**));
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

[Vladimir Olovyannikov]

-Original Message-
From: Shah, Tapan [mailto:tapands...@hpe.com]
Sent: Thursday, October 06, 2016 2:52 PM
To: Vladimir Olovyannikov; edk2-devel@lists.01.org; jaben.car...@intel.com
Cc: Vladimir Olovyannikov
Subject: RE: [PATCH] ShellPkg: Fix erroneous Status returned by
ShellOpenFileByName()

+if (EFI_ERROR(Status)) {
+  return Status;
+} <<<<<<<<<<<< Missing closing brace


Right. Please disregard this, will resubmit.

Reviewed-by: Tapan Shah <tapands...@hpe.com>

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Thursday, October 06, 2016 4:40 PM
To: edk2-devel@lists.01.org; Shah, Tapan <tapands...@hpe.com>;
jaben.car...@intel.com
Cc: Vladimir Olovyannikov <volov...@broadcom.com>; Vladimir Olovyannikov
<vladimir.olovyanni...@broadcom.com>
Subject: [PATCH] ShellPkg: Fix erroneous Status returned by
ShellOpenFileByName()

From: Vladimir Olovyannikov <volov...@broadcom.com>

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function should
return that error immediately. However, this return was missing, and if
UnicodeCollationProtocol has not been located by this time, the Status
gets overwritten with LocateProtocol() call result, which eventually
erroneously returns EFI_SUCCESS to the Shell.c, and this leads to attempt
to execute a non-existent startup script, which fails, and which in turn
leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah <tapands...@hpe.com>
Cc: Jaben Carsey <jaben.car...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..6fa67a3e751c 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,8 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;

 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (,
NULL, (VOID**));
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName()

[Vladimir Olovyannikov]

From: Vladimir Olovyannikov <volov...@broadcom.com>

In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.

Cc: Tapan Shah <tapands...@hpe.com>
Cc: Jaben Carsey <jaben.car...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyanni...@broadcom.com>
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 53f54e1746d4..6fa67a3e751c 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -723,6 +723,8 @@ ShellOpenFileByName(
 Status = gEfiShellProtocol->OpenFileByName(FileName,
FileHandle,
OpenMode);
+if (EFI_ERROR(Status)) {
+  return Status;
 
 if (mUnicodeCollationProtocol == NULL) {
   Status = gBS->LocateProtocol (, NULL, 
(VOID**));
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib constructor

[Vladimir Olovyannikov]

OK, will do

-Original Message-
From: Shah, Tapan [mailto:tapands...@hpe.com]
Sent: Thursday, October 06, 2016 1:05 PM
To: Vladimir Olovyannikov; Carsey, Jaben; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

Can you send a patch file with this error check added @726 ?

-Original Message-
From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
Sent: Thursday, October 06, 2016 2:58 PM
To: Carsey, Jaben <jaben.car...@intel.com>; Shah, Tapan
<tapands...@hpe.com>; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

Hi Carsey, Tapan,

This change breaks our platform's UEFI Shell at runtime (no asserts) :

...
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Error: Image at 000B97CF000 start failed: Invalid Parameter

remove-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEB
UG/Shell.dll 0xB97CF000

Image Return Status = Invalid Parameter


UnicodeCollation protocol is present.
Attempt to open fs1:startup.nsh which is not present.

There is a bug in UefiShellLib.c ShellOpenFileByName() which has nothing to
do to this commit.

723 Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);

If there is no file available, the status is EFI_NOT_FOUND.
Line 726 (or 727) of the UefiShellLib.c must be

if (EFI_ERROR(Status)) {
  return Status;
}

But it is missing, and therefore EFI_SUCCESS is returned to the Shell.c from
ShellFindFilePath() (line 1228 of Shell.c), which leads to an attempt to run
a non-existent script which fails, and this leads to Shell unloading with
"Invalid parameter".

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Wednesday, October 05, 2016 3:20 PM
To: Tapan Shah; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate
out of UefiShellLib constructor

And pushed.
Reviewed-by: Jaben Carsey <jaben.car...@intel.com>

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Tapan Shah
> <tapands...@hpe.com>
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out
> of UefiShellLib constructor
> Importance: High
>
> Move gEfiUnicodeCollation2ProtocolGuid protocol outside of
> UefiShellLib constructor function.
> Locate gEfiUnicodeCollation2ProtocolGuid protocol in
> ShellOpenFileByName() which
> consumes this protocol API.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah <tapands...@hpe.com>
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index e47d535..53f54e1 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -292,18 +292,12 @@ ShellLibConstructor (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUS  Status;
> -
>mEfiShellEnvironment2   = NULL;
>gEfiShellProtocol   = NULL;
>gEfiShellParametersProtocol = NULL;
>mEfiShellInterface  = NULL;
>mEfiShellEnvironment2Handle = NULL;
> -
> -  if (mUnicodeCollationProtocol == NULL) {
> -Status = gBS->LocateProtocol (,
NULL,
> (VOID**));
> -ASSERT_EFI_ERROR (Status);
> -  }
> +  mUnicodeCollationProtocol   = NULL;
>
>//
>// verify that auto initialize is not set false @@ -730,6 +724,14
> @@ ShellOpenFileByName(
> FileHandle,
> OpenMode);
>
> +if (mUnicodeCollationProtocol == NULL) {
> +  Status = gBS->LocateProtocol
> + (,
> NULL, (VOID**));
> +  if (EFI_ERROR (Status)) {
> +gEfiShellProtocol->CloseFile (*FileHandle);
> +return Status;
> +  }
> +}
> +
>  if ((mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NUL") != 0) &&
>  (mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NULL") != 0) &&
>   !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) !=
0)){
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib constructor

[Vladimir Olovyannikov]

Hi Carsey, Tapan,

This change breaks our platform's UEFI Shell at runtime (no asserts) :

...
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.

Error: Image at 000B97CF000 start failed: Invalid Parameter

remove-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC5/AARCH64/ShellPkg/Application/Shell/Shell/DEB
UG/Shell.dll 0xB97CF000

Image Return Status = Invalid Parameter


UnicodeCollation protocol is present.
Attempt to open fs1:startup.nsh which is not present.

There is a bug in UefiShellLib.c ShellOpenFileByName() which has nothing
to do to this commit.

723 Status = gEfiShellProtocol->OpenFileByName(FileName,
   FileHandle,
   OpenMode);

If there is no file available, the status is EFI_NOT_FOUND.
Line 726 (or 727) of the UefiShellLib.c must be

if (EFI_ERROR(Status)) {
  return Status;
}

But it is missing, and therefore EFI_SUCCESS is returned to the Shell.c
from ShellFindFilePath() (line 1228 of Shell.c),
which leads to an attempt to run a non-existent script which fails, and
this leads to Shell unloading with "Invalid parameter".

Thank you,
Vladimir

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Carsey, Jaben
Sent: Wednesday, October 05, 2016 3:20 PM
To: Tapan Shah; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: Re: [edk2] [PATCH] ShellPkg: Move UnicodeCollation2 Protcol
locate out of UefiShellLib constructor

And pushed.
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Tapan Shah [mailto:tapands...@hpe.com]
> Sent: Wednesday, October 05, 2016 1:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Tapan Shah
> 
> Subject: [PATCH] ShellPkg: Move UnicodeCollation2 Protcol locate out of
> UefiShellLib constructor
> Importance: High
>
> Move gEfiUnicodeCollation2ProtocolGuid protocol outside of UefiShellLib
> constructor
> function.
> Locate gEfiUnicodeCollation2ProtocolGuid protocol in
> ShellOpenFileByName() which
> consumes this protocol API.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Tapan Shah 
> ---
>  ShellPkg/Library/UefiShellLib/UefiShellLib.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> index e47d535..53f54e1 100644
> --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
> @@ -292,18 +292,12 @@ ShellLibConstructor (
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
> -  EFI_STATUS  Status;
> -
>mEfiShellEnvironment2   = NULL;
>gEfiShellProtocol   = NULL;
>gEfiShellParametersProtocol = NULL;
>mEfiShellInterface  = NULL;
>mEfiShellEnvironment2Handle = NULL;
> -
> -  if (mUnicodeCollationProtocol == NULL) {
> -Status = gBS->LocateProtocol (,
NULL,
> (VOID**));
> -ASSERT_EFI_ERROR (Status);
> -  }
> +  mUnicodeCollationProtocol   = NULL;
>
>//
>// verify that auto initialize is not set false
> @@ -730,6 +724,14 @@ ShellOpenFileByName(
> FileHandle,
> OpenMode);
>
> +if (mUnicodeCollationProtocol == NULL) {
> +  Status = gBS->LocateProtocol (,
> NULL, (VOID**));
> +  if (EFI_ERROR (Status)) {
> +gEfiShellProtocol->CloseFile (*FileHandle);
> +return Status;
> +  }
> +}
> +
>  if ((mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NUL") != 0) &&
>  (mUnicodeCollationProtocol->StriColl
(mUnicodeCollationProtocol,
> (CHAR16*)FileName, L"NULL") != 0) &&
>   !EFI_ERROR(Status) && ((OpenMode & EFI_FILE_MODE_CREATE) !=
0)){
> --
> 1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] GenFds.py error CODE: Tools code failure

[Vladimir Olovyannikov]

Hi Liming,



Exactly.

I added the .inf file for the shell application I worked on, thinking that
it would be an .efi file, and only later
I recognized it should actually be a Shell library (I derived from tftp
command source as an example)…



Thank you,

Vladimir



*From:* Gao, Liming [mailto:liming@intel.com]
*Sent:* Tuesday, September 13, 2016 8:23 PM
*To:* Vladimir Olovyannikov
*Cc:* edk2-devel@lists.01.org
*Subject:* RE: [edk2] GenFds.py error CODE: Tools code failure



Vladimir:

  You add one library INF into FDF file, then cause this issue?



Thanks

Liming

*From:* Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
*Sent:* Wednesday, September 14, 2016 11:20 AM
*To:* Gao, Liming <liming@intel.com>
*Cc:* edk2-devel@lists.01.org <edk2-de...@ml01.01.org>
*Subject:* RE: [edk2] GenFds.py error CODE: Tools code failure



Hi,
Thanks for reply. I found the reason: I should have add the Shell
application (which is actually a library) to the ShellPkg instead of trying
to add it in the .fdf.

Thank you,
Vladimir



On Sep 13, 2016 8:17 PM, "Gao, Liming" <liming@intel.com> wrote:

Hi,
  The below message is caused by the missing map file of the driver. In
build output directory /uefi/Build/NS2Pkg/DEBUG_GCC5,  please check whether
the map file is generated for each driver.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Vladimir Olovyannikov
> Sent: Wednesday, September 14, 2016 3:51 AM
> To: edk2-de...@ml01.01.org
> Subject: [edk2] GenFds.py error CODE: Tools code failure
>
> Hello,
>
> I have just got this error building UEFI for AARCH64.
>
> Here is an excerpt from the output:
>
> Fd File Name:BL33_AP_UEFI
>
> Generate Region at Offset 0x0
>Region Size = 0xF
>Region Name = FV
>
> Generating FVMAIN_COMPACT FV
> 
> Generating FVMAIN FV
> 
> 
> 
>
>
> GenFds.py...
>  : error C0DE: Tools code failure
> Please send email to edk2-devel@lists.01.org for help, attaching
> following call stack trace!
>
> Traceback (most recent call last):
>   File
> "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> ds.p
> y", line 307, in main
> GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
>   File
> "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> ds.p
> y", line 553, in GenFd
> FdObj.GenFd()
>   File "/uefi/BaseTools/Source/Python/GenFds/Fd.py", line 93, in GenFd
> RegionObj.AddToBuffer (TempFdBuffer, self.BaseAddress,
> self.BlockSizeList, self.ErasePolarity, GenFds.ImageBinDict,
> self.vtfRawDict, self.DefineVarDict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Region.py", line 127, in
> AddToBuffer
> FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum,
> ErasePolarity, vtfDict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> AddToBuffer
> FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsFileStatement.py", line
> 156, in GenFfs
> sectList, align = section.GenSection(OutputDir, self.NameGuid,
> SecIndex, self.KeyStringList, None, Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/GuidSection.py", line 97, in
> GenSection
> ReturnSectList, align = Sect.GenSection(OutputPath, ModuleName,
> SecIndex, KeyStringList, FfsInf, Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/FvImageSection.py", line 101,
> in GenSection
> FvFileName = Fv.AddToBuffer(Buffer, self.FvAddr, MacroDict = Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> AddToBuffer
> FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 480, in GenFfs
> InputSectList, InputSectAlignments =
> self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 948, in __GenComplexFileSection__
> self.__GenUniVfrOffsetFile (VfrUniOffsetList, UniVfrOffsetFileName)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 1052, in __GenUniVfrOffsetFile
> for Item in VfrUniOffsetList:
> TypeError: 'NoneType' object is not iterable
>
> #
>
>
> build.py...
>  : error 7000: Failed to execute command
> GenFds -f /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.fdf
> --conf=/uefi/Conf -o /uefi/Build/NS2Pkg/DEBUG_GCC5 -t GC

Re: [edk2] GenFds.py error CODE: Tools code failure

[Vladimir Olovyannikov]

Hi,
Thanks for reply. I found the reason: I should have add the Shell
application (which is actually a library) to the ShellPkg instead of trying
to add it in the .fdf.

Thank you,
Vladimir

On Sep 13, 2016 8:17 PM, "Gao, Liming" <liming@intel.com> wrote:

> Hi,
>   The below message is caused by the missing map file of the driver. In
> build output directory /uefi/Build/NS2Pkg/DEBUG_GCC5,  please check whether
> the map file is generated for each driver.
>
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Vladimir Olovyannikov
> > Sent: Wednesday, September 14, 2016 3:51 AM
> > To: edk2-de...@ml01.01.org
> > Subject: [edk2] GenFds.py error CODE: Tools code failure
> >
> > Hello,
> >
> > I have just got this error building UEFI for AARCH64.
> >
> > Here is an excerpt from the output:
> >
> > Fd File Name:BL33_AP_UEFI
> >
> > Generate Region at Offset 0x0
> >Region Size = 0xF
> >Region Name = FV
> >
> > Generating FVMAIN_COMPACT FV
> > 
> > Generating FVMAIN FV
> > 
> > 
> > 
> >
> >
> > GenFds.py...
> >  : error C0DE: Tools code failure
> > Please send email to edk2-devel@lists.01.org for help, attaching
> > following call stack trace!
> >
> > Traceback (most recent call last):
> >   File
> > "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> > ds.p
> > y", line 307, in main
> > GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
> >   File
> > "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> > ds.p
> > y", line 553, in GenFd
> > FdObj.GenFd()
> >   File "/uefi/BaseTools/Source/Python/GenFds/Fd.py", line 93, in GenFd
> > RegionObj.AddToBuffer (TempFdBuffer, self.BaseAddress,
> > self.BlockSizeList, self.ErasePolarity, GenFds.ImageBinDict,
> > self.vtfRawDict, self.DefineVarDict)
> >   File "/uefi/BaseTools/Source/Python/GenFds/Region.py", line 127, in
> > AddToBuffer
> > FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum,
> > ErasePolarity, vtfDict)
> >   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> > AddToBuffer
> > FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
> >   File "/uefi/BaseTools/Source/Python/GenFds/FfsFileStatement.py", line
> > 156, in GenFfs
> > sectList, align = section.GenSection(OutputDir, self.NameGuid,
> > SecIndex, self.KeyStringList, None, Dict)
> >   File "/uefi/BaseTools/Source/Python/GenFds/GuidSection.py", line 97,
> in
> > GenSection
> > ReturnSectList, align = Sect.GenSection(OutputPath, ModuleName,
> > SecIndex, KeyStringList, FfsInf, Dict)
> >   File "/uefi/BaseTools/Source/Python/GenFds/FvImageSection.py", line
> 101,
> > in GenSection
> > FvFileName = Fv.AddToBuffer(Buffer, self.FvAddr, MacroDict = Dict)
> >   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> > AddToBuffer
> > FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
> >   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> > 480, in GenFfs
> > InputSectList, InputSectAlignments =
> > self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr)
> >   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> > 948, in __GenComplexFileSection__
> > self.__GenUniVfrOffsetFile (VfrUniOffsetList, UniVfrOffsetFileName)
> >   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> > 1052, in __GenUniVfrOffsetFile
> > for Item in VfrUniOffsetList:
> > TypeError: 'NoneType' object is not iterable
> >
> > #
> >
> >
> > build.py...
> >  : error 7000: Failed to execute command
> > GenFds -f /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.fdf
> > --conf=/uefi/Conf -o /uefi/Build/NS2Pkg/DEBUG_GCC5 -t GCC5 -b DEBUG -p
> > /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.dsc -a AARCH64 -D
> > "EFI_SOURCE=/uefi/EdkCompatibilityPkg" -D
> > "EDK_SOURCE=/uefi/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D
> > "TOOLCHAIN=GCC5" -D "TARGET=DEBUG" -D "FAMILY=GCC" -D
> > "WORKSPACE=/uefi" -D
> > "EDK_TOOLS_PATH=/uefi/BaseTools" -D "ARCH=AARCH64" -D
> > "ECP_SOURCE=/uefi/EdkCompatibilityPkg" [/uefi]
> >
> > - Failed -
> >
> > Please let me know if any other information is needed to identify the
> > reason of the error.
> >
> > Thank you,
> > Vladimir
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] GenFds.py error CODE: Tools code failure

[Vladimir Olovyannikov]

Hello,

I have just got this error building UEFI for AARCH64.

Here is an excerpt from the output:

Fd File Name:BL33_AP_UEFI

Generate Region at Offset 0x0
   Region Size = 0xF
   Region Name = FV

Generating FVMAIN_COMPACT FV

Generating FVMAIN FV





GenFds.py...
 : error C0DE: Tools code failure
Please send email to edk2-devel@lists.01.org for help, attaching
following call stack trace!

Traceback (most recent call last):
  File
"/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenFds.p
y", line 307, in main
GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
  File
"/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenFds.p
y", line 553, in GenFd
FdObj.GenFd()
  File "/uefi/BaseTools/Source/Python/GenFds/Fd.py", line 93, in GenFd
RegionObj.AddToBuffer (TempFdBuffer, self.BaseAddress,
self.BlockSizeList, self.ErasePolarity, GenFds.ImageBinDict,
self.vtfRawDict, self.DefineVarDict)
  File "/uefi/BaseTools/Source/Python/GenFds/Region.py", line 127, in
AddToBuffer
FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum,
ErasePolarity, vtfDict)
  File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
AddToBuffer
FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
  File "/uefi/BaseTools/Source/Python/GenFds/FfsFileStatement.py", line
156, in GenFfs
sectList, align = section.GenSection(OutputDir, self.NameGuid,
SecIndex, self.KeyStringList, None, Dict)
  File "/uefi/BaseTools/Source/Python/GenFds/GuidSection.py", line 97, in
GenSection
ReturnSectList, align = Sect.GenSection(OutputPath, ModuleName,
SecIndex, KeyStringList, FfsInf, Dict)
  File "/uefi/BaseTools/Source/Python/GenFds/FvImageSection.py", line 101,
in GenSection
FvFileName = Fv.AddToBuffer(Buffer, self.FvAddr, MacroDict = Dict)
  File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
AddToBuffer
FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
  File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
480, in GenFfs
InputSectList, InputSectAlignments =
self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr)
  File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
948, in __GenComplexFileSection__
self.__GenUniVfrOffsetFile (VfrUniOffsetList, UniVfrOffsetFileName)
  File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
1052, in __GenUniVfrOffsetFile
for Item in VfrUniOffsetList:
TypeError: 'NoneType' object is not iterable

#


build.py...
 : error 7000: Failed to execute command
GenFds -f /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.fdf
--conf=/uefi/Conf -o /uefi/Build/NS2Pkg/DEBUG_GCC5 -t GCC5 -b DEBUG -p
/uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.dsc -a AARCH64 -D
"EFI_SOURCE=/uefi/EdkCompatibilityPkg" -D
"EDK_SOURCE=/uefi/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D
"TOOLCHAIN=GCC5" -D "TARGET=DEBUG" -D "FAMILY=GCC" -D "WORKSPACE=/uefi" -D
"EDK_TOOLS_PATH=/uefi/BaseTools" -D "ARCH=AARCH64" -D
"ECP_SOURCE=/uefi/EdkCompatibilityPkg" [/uefi]

- Failed -

Please let me know if any other information is needed to identify the
reason of the error.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

[Vladimir Olovyannikov]

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, May 30, 2016 1:14 PM
> To: Vladimir Olovyannikov
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
return
> EFI_NOT FOUND
>
>
> > On May 30, 2016, at 12:29 PM, Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com> wrote:
> >
> >> -Original Message-
> >> From: af...@apple.com [mailto:af...@apple.com]
> >> Sent: Monday, May 30, 2016 11:53 AM
> >> To: Vladimir Olovyannikov
> >> Cc: edk2-de...@ml01.01.org
> >> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
> > return
> >> EFI_NOT FOUND
> >>
> >>
> >>> On May 30, 2016, at 11:38 AM, Vladimir Olovyannikov
> >> <vladimir.olovyanni...@broadcom.com> wrote:
> >>>
> >>> Hi Andrew,
> >>> Please see below.
> >>> The region of interest is marked as "Reserved".
> >>>
> >>> Thanks,
> >>> Vladimir
> >>>
> >>>> -Original Message-
> >>>> From: af...@apple.com [mailto:af...@apple.com]
> >>>> Sent: Monday, May 30, 2016 11:32 AM
> >>>> To: Vladimir Olovyannikov
> >>>> Cc: edk2-de...@ml01.01.org
> >>>> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
> >>> return
> >>>> EFI_NOT FOUND
> >>>>
> >>>>
> >>>>> On May 30, 2016, at 10:37 AM, Vladimir Olovyannikov
> >>>> <vladimir.olovyanni...@broadcom.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hello All,
> >>>>>
> >>>>> I faced an issue with my UEFI implementation (Armv8 64 bit
> > platform).
> >>>>> I need to convert a device physical address to the virtual on
> >>>>> VirtualAddressChange event.
> >>>>> EfiConvertPointer always returns EFI_NOT_FOUND.
> >>>>>
> >>>>> I tried to allocate just an address:
> >>>>> gBS->AllocatePages(AllocateAddress, EfiRuntimeServicesCode, 1,
> >>>>> ); // Allocate one page
> >>>>> where MyAddress is 0x65042000.
> >>>>> Which also returns  EFI_NOT_FOUND.
> >>>>>
> >>>>> I declared this device's memory in the Platform memory lib as
> >>>>>
> >>>>> // Mydevice
> >>>>> // 1MB @0x6500 (0x6500 - 0x650f)
> >>>>> MMUTable[++Index].PhysicalBase= MY_DEV_BASE;
> >>>>> MMUTable[Index].VirtualBase= MY_DEV_BASE;
> >>>>> MMUTable[Index].Length = MY_DEV_SZ; //
SIZE_1MB
> >>>>> MMUTable[Index].Attributes  =
> >>>>> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >>>>>
> >>>>> I can access this device perfectly from BootServices (read/write)
> > with
> >>> MMU
> >>>>> (1:1) on.
> >>>>> But it is nowhere in virtual table map which
> >>>>> AllocatePages()/EfiConvertPointer() eventually use.
> >>>>>
> >>>>> Please let me know what I am missing here?
> >>>>> I have declared this memory as a Runtime with
> >>>>>
> >>>>> Status = gDS->AddMemorySpace (
> >>>>>  EfiGcdMemoryTypeMemoryMappedIo,
> >>>>>  AlignedAddr, SIZE_64KB,
> >>>>>  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >>>>>);
> >>>>> if (!EFI_ERROR (Status)) {
> >>>>>Status = gDS->SetMemorySpaceAttributes (
> >>>>>  AlignedAddr,
> >>>>>  SIZE_64KB,
> >>>>>  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >>>>>);
> >>>>> }
> >>>>>
> >>>>
> >>>> If you boot to the UEFI shell and dump the memory map what to do
> you
> >>> see?
> >>>
> >>
> >> The attribute is wrong, so it was not allocate correctly.
> >>
> >> #define EFI_MEMORY_RUNTIME   0x8000
> >>
> >> Did you check all the return Status from your gDS calls? You can read
up
> >> about them in the PI spec from the UEF Forum website.
> >>
> &g

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

[Vladimir Olovyannikov]

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, May 30, 2016 11:53 AM
> To: Vladimir Olovyannikov
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
return
> EFI_NOT FOUND
>
>
> > On May 30, 2016, at 11:38 AM, Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com> wrote:
> >
> > Hi Andrew,
> > Please see below.
> > The region of interest is marked as "Reserved".
> >
> > Thanks,
> > Vladimir
> >
> >> -Original Message-
> >> From: af...@apple.com [mailto:af...@apple.com]
> >> Sent: Monday, May 30, 2016 11:32 AM
> >> To: Vladimir Olovyannikov
> >> Cc: edk2-de...@ml01.01.org
> >> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
> > return
> >> EFI_NOT FOUND
> >>
> >>
> >>> On May 30, 2016, at 10:37 AM, Vladimir Olovyannikov
> >> <vladimir.olovyanni...@broadcom.com> wrote:
> >>>
> >>>
> >>> Hello All,
> >>>
> >>> I faced an issue with my UEFI implementation (Armv8 64 bit
platform).
> >>> I need to convert a device physical address to the virtual on
> >>> VirtualAddressChange event.
> >>> EfiConvertPointer always returns EFI_NOT_FOUND.
> >>>
> >>> I tried to allocate just an address:
> >>> gBS->AllocatePages(AllocateAddress, EfiRuntimeServicesCode, 1,
> >>> ); // Allocate one page
> >>> where MyAddress is 0x65042000.
> >>> Which also returns  EFI_NOT_FOUND.
> >>>
> >>> I declared this device's memory in the Platform memory lib as
> >>>
> >>> // Mydevice
> >>> // 1MB @0x6500 (0x6500 - 0x650f)
> >>> MMUTable[++Index].PhysicalBase= MY_DEV_BASE;
> >>> MMUTable[Index].VirtualBase= MY_DEV_BASE;
> >>> MMUTable[Index].Length = MY_DEV_SZ; // SIZE_1MB
> >>> MMUTable[Index].Attributes  =
> >>> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >>>
> >>> I can access this device perfectly from BootServices (read/write)
with
> > MMU
> >>> (1:1) on.
> >>> But it is nowhere in virtual table map which
> >>> AllocatePages()/EfiConvertPointer() eventually use.
> >>>
> >>> Please let me know what I am missing here?
> >>> I have declared this memory as a Runtime with
> >>>
> >>> Status = gDS->AddMemorySpace (
> >>>   EfiGcdMemoryTypeMemoryMappedIo,
> >>>   AlignedAddr, SIZE_64KB,
> >>>   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >>> );
> >>> if (!EFI_ERROR (Status)) {
> >>> Status = gDS->SetMemorySpaceAttributes (
> >>>   AlignedAddr,
> >>>   SIZE_64KB,
> >>>   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >>> );
> >>> }
> >>>
> >>
> >> If you boot to the UEFI shell and dump the memory map what to do you
> > see?
> >
>
> The attribute is wrong, so it was not allocate correctly.
>
> #define EFI_MEMORY_RUNTIME   0x8000
>
> Did you check all the return Status from your gDS calls? You can read up
> about them in the PI spec from the UEF Forum website.
>
> If you do a gDS->GetMemorySpaceDescriptor() for the  AlignedAddr does it
> succeed? If yes I think you want to get the descriptor and then set the
> memory space attribute.
OK. I think my attempt to build a resource descriptor hob for this device
was wrong.
ResourceAttributes = (
EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE );
BuildResourceDescriptorHob (EFI_RESOURCE_MEMORY_MAPPED_IO_PORT,
  ResourceAttributes,
  PcdGet32(PcdPlatformResetAddr) &
~(SIZE_64KB - 1),
  SIZE_64KB);
This is what provided the "Reserved".

When I removed it memmap gave me 65002000 as "Mmio" and ConvertPointer
succeeded.

One thing which is not quite clear to me:
Should I not declare this device in the Viirtual memory table for the
platform and just use AddMemorySpace instead ?

Thank you,
Vladimir
>
> Thanks,
>
> Andrew Fish
>
> > Shell> memmap
> > Type   StartEnd  # Pages
Attributes
> > Available  8

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

[Vladimir Olovyannikov]

Hi Andrew,
Please see below.
The region of interest is marked as "Reserved".

Thanks,
Vladimir

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, May 30, 2016 11:32 AM
> To: Vladimir Olovyannikov
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address
return
> EFI_NOT FOUND
>
>
> > On May 30, 2016, at 10:37 AM, Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com> wrote:
> >
> >
> > Hello All,
> >
> > I faced an issue with my UEFI implementation (Armv8 64 bit platform).
> > I need to convert a device physical address to the virtual on
> > VirtualAddressChange event.
> > EfiConvertPointer always returns EFI_NOT_FOUND.
> >
> > I tried to allocate just an address:
> > gBS->AllocatePages(AllocateAddress, EfiRuntimeServicesCode, 1,
> > ); // Allocate one page
> > where MyAddress is 0x65042000.
> > Which also returns  EFI_NOT_FOUND.
> >
> > I declared this device's memory in the Platform memory lib as
> >
> >  // Mydevice
> >  // 1MB @0x6500 (0x6500 - 0x650f)
> >  MMUTable[++Index].PhysicalBase= MY_DEV_BASE;
> >  MMUTable[Index].VirtualBase= MY_DEV_BASE;
> >  MMUTable[Index].Length = MY_DEV_SZ; // SIZE_1MB
> >  MMUTable[Index].Attributes  =
> > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >
> > I can access this device perfectly from BootServices (read/write) with
MMU
> > (1:1) on.
> > But it is nowhere in virtual table map which
> > AllocatePages()/EfiConvertPointer() eventually use.
> >
> > Please let me know what I am missing here?
> > I have declared this memory as a Runtime with
> >
> >  Status = gDS->AddMemorySpace (
> >EfiGcdMemoryTypeMemoryMappedIo,
> >AlignedAddr, SIZE_64KB,
> >EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >  );
> >  if (!EFI_ERROR (Status)) {
> >  Status = gDS->SetMemorySpaceAttributes (
> >AlignedAddr,
> >SIZE_64KB,
> >EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
> >  );
> >  }
> >
>
> If you boot to the UEFI shell and dump the memory map what to do you
see?

Shell> memmap
Type   StartEnd  # Pages  Attributes
Available  8000-84FF 5000
000F
Available  850F-B986 00034780
000F
RT_DataB987-B98D 0070
800F
Available  B98E-B98E5FFF 0006
000F
LoaderCode B98E6000-B9A12FFF 012D
000F
BS_CodeB9A13000-B9B8 017D
000F
RT_DataB9B9-B9BD 0050
800F
RT_CodeB9BE-B9C2 0050
800F
RT_DataB9C3-B9C7 0050
800F
RT_CodeB9C8-B9CC 0050
800F
RT_DataB9CD-B9D1 0050
800F
RT_CodeB9D2-B9D7 0060
800F
ACPI_Recl  B9D8-B9D9 0020
000F
RT_DataB9DA-B9DE 0050
800F
RT_CodeB9DF-B9E3 0050
800F
RT_DataB9E4-B9E8 0050
800F
RT_CodeB9E9-B9ED 0050
800F
RT_DataB9EE-B9F2 0050
800F
RT_CodeB9F3-B9F7 0050
800F
Available  B9F8-B9F80FFF 0001
000F

Reserved   B9F81000-B9F84FFF 0004
000F

BS_CodeB9F85000-B9F8BFFF 0007
000F

Available  B9F8C000-BCA7AFFF 2AEF
000F

BS_DataBCA7B000-BEDB 2345
000F

Available  BEDC-BEDC5FFF 0006
000F

BS_CodeBEDC6000-BEF4 018A
000F

Available  BEF5-BEFB 0070
000F

RT_DataBEFC-BEFE 0030
800F

Available  BEFF-BEFFEFFF 000F
000F

BS_DataBEFFF000-BEFF 0001
00

[edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

[Vladimir Olovyannikov]

Hello All,

I faced an issue with my UEFI implementation (Armv8 64 bit platform).
I need to convert a device physical address to the virtual on
VirtualAddressChange event.
EfiConvertPointer always returns EFI_NOT_FOUND.

I tried to allocate just an address:
gBS->AllocatePages(AllocateAddress, EfiRuntimeServicesCode, 1,
); // Allocate one page
where MyAddress is 0x65042000.
Which also returns  EFI_NOT_FOUND.

I declared this device's memory in the Platform memory lib as

  // Mydevice
  // 1MB @0x6500 (0x6500 - 0x650f)
  MMUTable[++Index].PhysicalBase= MY_DEV_BASE;
  MMUTable[Index].VirtualBase= MY_DEV_BASE;
  MMUTable[Index].Length = MY_DEV_SZ; // SIZE_1MB
  MMUTable[Index].Attributes  =
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;

I can access this device perfectly from BootServices (read/write) with MMU
(1:1) on.
But it is nowhere in virtual table map which
AllocatePages()/EfiConvertPointer() eventually use.

Please let me know what I am missing here?
I have declared this memory as a Runtime with

  Status = gDS->AddMemorySpace (
EfiGcdMemoryTypeMemoryMappedIo,
AlignedAddr, SIZE_64KB,
EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
  );
  if (!EFI_ERROR (Status)) {
  Status = gDS->SetMemorySpaceAttributes (
AlignedAddr,
SIZE_64KB,
EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
  );
  }

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Vladimir Olovyannikov]

Ard,
Many thanks.
The script works fine now, no single issue adding symbols or source-level
debugging.

Vladimir

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, March 30, 2016 3:50 AM
> To: Vladimir Olovyannikov
> Cc: af...@apple.com; Eugene Cohen; edk2-devel@lists.01.org
> Subject: Re: [edk2] Error while loading a symbol file (No Debug Directory)
>
> On 30 March 2016 at 12:30, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> > On 30 March 2016 at 02:06, Vladimir Olovyannikov
> > <vladimir.olovyanni...@broadcom.com> wrote:
> >>> -Original Message-
> >>> From: af...@apple.com [mailto:af...@apple.com]
> >>> Sent: Tuesday, March 29, 2016 4:09 PM
> >>> To: Vladimir Olovyannikov
> >>> Cc: Eugene Cohen; Ard Biesheuvel; edk2-devel@lists.01.org
> >>> Subject: Re: [edk2] Error while loading a symbol file (No Debug
> >> Directory)
> >>>
> >>>
> >>> > On Mar 29, 2016, at 3:18 PM, Vladimir Olovyannikov
> >>> <vladimir.olovyanni...@broadcom.com> wrote:
> >>> >
> >>> > A quick update on the issue (I am using the latest master branch
> >> tree).
> >>> >
> >>> > Eugene is right in that excluding ImageContext->SizeOfHeaders gives
> >>> > correct address, and using
> >>> > "add-symbol-file" I can do source level debugging in the DS-5
> >>> > debugger.
> >>> > So it was sufficient to change
> >>> >
> ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> >>> > (around line 94)
> >>> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> >>> > DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
> >>> > (Temp)),
> >>> > (UINTN)(ImageContext->ImageAddress +
> >>> > ImageContext->SizeOfHeaders)));
> >>> > to
> >>> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> >>> > DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
> >>> > (Temp)),
> >>> >  (UINTN)(ImageContext->ImageAddress)));
> >>> >
> >>> > as well as around line 131 (which is optional)
> >>> > ("remove-symbol-file").
> >>> > It is probably a dirty hack but works fine for me.
> >>>
> >>> Vladimir,
> >>>
> >>> I'm not sure what is happening in your case but in general we run into
> >> issues
> >>> when converting other executable formats (ELF, Mach-O) into PE/COFF
> as
> >>> PE/COFF has the concept of the COFF header being loaded into system
> >>> memory and other formats do not. So adding in ImageContext-
> >>> >SizeOfHeaders is adjusting for the difference between how the ELF
> was
> >>> constructed prior to conversion to PE/COFF. In some cases the ELF is
> >> linked
> >>> with an adjustment for the PE/COFF header and in this case you tend to
> >> use
> >>> the start of the image. If the ELF image was just linked at zero then
> >> you need
> >>> to adjust for the size of the PE/COFF header.
> >>>
> >>> It looks like the GCC linker script BaseTools/Scripts/GccBase.lds does
> >> some
> >>> link time adjustment to leave size for the PE/COFF header. Thus these
> >>> toolchains would probably need to use ImageContext->ImageAddress
> vs.
> >>> ImageContext->ImageAddress + ImageContext->SizeOfHeaders. It also
> looks
> >>> like the RVCT has a linker script that reservers 0x220 bytes for a
> >> PE/COFF
> >>> header.
> >>>
> >>> The, slightly mangled, comment right before the GCC add-symbol-file
> >> DEBUG
> >>> print is pointing out the + ImageContext->SizeOfHeaders could be
> >> optional. I
> >>> would think if you are linking the ELF to include space for the
> >>> PE/COFF
> >> header
> >>> then you should fall into the no + ImageContext->SizeOfHeaders is
> >> required.
> >>>
> >>> // This may not work correctly if you generate PE/COFF directlyas
> >> then the
> >>> Offset would not be required
> >>>
> >>> So I wonder if these DEBUG prints are out of sync with the current
> >> linker
> >>> flags? If I thought  

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Vladimir Olovyannikov]

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, March 29, 2016 4:09 PM
> To: Vladimir Olovyannikov
> Cc: Eugene Cohen; Ard Biesheuvel; edk2-devel@lists.01.org
> Subject: Re: [edk2] Error while loading a symbol file (No Debug
Directory)
>
>
> > On Mar 29, 2016, at 3:18 PM, Vladimir Olovyannikov
> <vladimir.olovyanni...@broadcom.com> wrote:
> >
> > A quick update on the issue (I am using the latest master branch
tree).
> >
> > Eugene is right in that excluding ImageContext->SizeOfHeaders gives
> > correct address, and using
> > "add-symbol-file" I can do source level debugging in the DS-5
> > debugger.
> > So it was sufficient to change
> > ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> > (around line 94)
> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> > DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
> > (Temp)),
> > (UINTN)(ImageContext->ImageAddress +
> > ImageContext->SizeOfHeaders)));
> > to
> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> > DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
> > (Temp)),
> >  (UINTN)(ImageContext->ImageAddress)));
> >
> > as well as around line 131 (which is optional) ("remove-symbol-file").
> > It is probably a dirty hack but works fine for me.
>
> Vladimir,
>
> I'm not sure what is happening in your case but in general we run into
issues
> when converting other executable formats (ELF, Mach-O) into PE/COFF as
> PE/COFF has the concept of the COFF header being loaded into system
> memory and other formats do not. So adding in ImageContext-
> >SizeOfHeaders is adjusting for the difference between how the ELF was
> constructed prior to conversion to PE/COFF. In some cases the ELF is
linked
> with an adjustment for the PE/COFF header and in this case you tend to
use
> the start of the image. If the ELF image was just linked at zero then
you need
> to adjust for the size of the PE/COFF header.
>
> It looks like the GCC linker script BaseTools/Scripts/GccBase.lds does
some
> link time adjustment to leave size for the PE/COFF header. Thus these
> toolchains would probably need to use ImageContext->ImageAddress vs.
> ImageContext->ImageAddress + ImageContext->SizeOfHeaders. It also looks
> like the RVCT has a linker script that reservers 0x220 bytes for a
PE/COFF
> header.
>
> The, slightly mangled, comment right before the GCC add-symbol-file
DEBUG
> print is pointing out the + ImageContext->SizeOfHeaders could be
optional. I
> would think if you are linking the ELF to include space for the PE/COFF
header
> then you should fall into the no + ImageContext->SizeOfHeaders is
required.
>
> // This may not work correctly if you generate PE/COFF directlyas
then the
> Offset would not be required
>
> So I wonder if these DEBUG prints are out of sync with the current
linker
> flags? If I thought  the add-symbol-file address was always the start of
the
> image. Adding in the PE/COFF SizeOfHeaders would only bee needed if the
> ELF was constructed without adjustment for the PE/COFF header. Looks
like
> most of the targets do this adjustment?
>
> Thanks,
>
> Andrew Fish
Thanks for the input Andrew,
For me it all started only after applying of commit
2939c778a3a3f5463d97339f4f3dbf5afb572a5e,
ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib,
though I do not see how this commit could affect (SizeOfHeaders + Base)
address...

As soon as I checkout the previous
(d2bb61a2328d512c0aeb201ab8a5a6497f415afb,
ArmPkg/ArmLib: add ArmReadHcr to enable read-modify-write of HCR),
everything is fine.

The commit f37d891c1b870b294964adf65f619a661700fcab,
BaseTools AARCH64: move DEBUG GCC49 to the small code model,
causes this when I run cmd_load_symbols.py script in DS-5 debugger:
Add symbols of
/uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBU
G/ArmPlatformPrePiMPCore.dll at 0x8500
Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
...Same line 30 times...
Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
Add symbols of
/work/jenkins/workspace/ap-uefi-bin/EDK2_ARCH/ARM/EDK2_BINARY/FatPkg/label
/sas-sw/Build/Fat/RELEASE_GCC49/AARCH64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fa
t.dll at 0xb9f85000
Warning: not possible to load symbols from
/work/jenkins/workspace/ap-uefi-bin/EDK2_ARCH/ARM/EDK2_BINARY/FatPkg/label
/sas-sw/Build/Fat/RELEASE_GCC49/AARCH64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fa
t.dll at 0xb9f85000
Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)
...Same line 12 times
Error 

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Vladimir Olovyannikov]

A quick update on the issue (I am using the latest master branch tree).

Eugene is right in that excluding ImageContext->SizeOfHeaders gives
correct address, and using
"add-symbol-file" I can do source level debugging in the DS-5
debugger.
So it was sufficient to change
ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
(around line 94)
DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
(Temp)),
(UINTN)(ImageContext->ImageAddress +
ImageContext->SizeOfHeaders)));
to
DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
(Temp)),
 (UINTN)(ImageContext->ImageAddress)));

as well as around line 131 (which is optional) ("remove-symbol-file").
It is probably a dirty hack but works fine for me.
However ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py script is useless
because it does not load the symbols properly.
Anyway at least I have an ability to do source level debug now using
"add-symbol-file" lines.

Thank you,
Vladimir
> -Original Message-
> From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
> Sent: Friday, March 25, 2016 7:17 PM
> To: 'Cohen, Eugene'; 'Ard Biesheuvel'
> Cc: 'edk2-devel@lists.01.org'
> Subject: RE: [edk2] Error while loading a symbol file (No Debug
Directory)
>
> > > This is very odd. The commit in question introduces two new
> > > implementations of CpuExceptionHandlerLib, but does not yet use them
> > > anywhere. The next patch updates CpuDxe to start using the default
> > > (non-copying) one. What are your resolutions for
> CpuExceptionHandlerLib
> > in
> > > your .DSC, and do any of them refer to the libraries added in this
patch?
> >
> > Agreed - from a CpuDxe point of view the change should be transparent
-
> > it's the same exception handling implemented in a library.  It should
have
> > the same alignment characteristics as before.  If there was a bug that
> > existing in debug scripts for scanning modules or PE-coff extra
actions - I
> > would not expect this patch to worsen (or improve) the situation.
> I totally agree with you. However, I re-verified one more time, and this
is the
> patch
> after which no source level debugging is available for me.
> >
> > > > If I do "add-symbol-file.." in the DS-5 Debug console as the
exception
> > > > handler reports, I have an ability to debug (so the address is
shifted
> > > > +0x1 comparing to the proper address) Do you know if  anybody
> else
> > > > had this issue on an armv8 64 bit platform after this patch was
> > > > applied?
> > > > Please advise what I could be missing...
> > > >
> > >
> > > Hmm, that looks like a separate issue. Due to the padding required
for
> > > runtime drivers, which have a 64k section alignment, the start of
the file
> > and
> > > the start of the text section are 64k apart, so that output is not
> > unexpected.
> > > In GDB, add-symbol-file takes the start of the .text section, not
the start
> of
> > > the image.
> >
> > Are you saying this also started happening with the commit in question
or is
> > that something independent?
> Eugene, I think there is actually one issue.
> It looks like "No debug directory" message was from day 1 (last year,
> sometime Jul) for me,
> but it did not affect debugging in any way, so I simply ignored it.
> With this commit the source level debugging (we use DS-5) is unavailable
for
> me, even though debugger says
> that symbols were loaded successfully. For the driver of interest (say
> RuntimeClock...) I manually shift  -0x1, and
> then the source-level debugging is available again.
>
>  As Ard says if the debugger needs the start of
> > .text then this address may not be correct since the output is
generated as
> > follows:
> >
> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> > DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof
> (Temp)),
> > (UINTN)(ImageContext->ImageAddress + ImageContext-
> >SizeOfHeaders)));
> >
> > With our debugger (TRACE32) we only emit ImageAddress and don't add
> > SizeOfHeaders:
> >
> >DEBUG((EFI_D_ERROR, "data.load.elf %a a:0x%08x /NOCODE
> /NOCLEAR\n",
> > ImageContext->PdbPointer, ImageAddress));
> >
> > The adding of SizeOfHeaders used to be required when the PE-COFF
> > conversion would shift the .text section to make room 

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Vladimir Olovyannikov]

> > This is very odd. The commit in question introduces two new
> > implementations of CpuExceptionHandlerLib, but does not yet use them
> > anywhere. The next patch updates CpuDxe to start using the default
> > (non-copying) one. What are your resolutions for
CpuExceptionHandlerLib
> in
> > your .DSC, and do any of them refer to the libraries added in this
patch?
>
> Agreed - from a CpuDxe point of view the change should be transparent -
> it's the same exception handling implemented in a library.  It should
have
> the same alignment characteristics as before.  If there was a bug that
> existing in debug scripts for scanning modules or PE-coff extra actions
- I
> would not expect this patch to worsen (or improve) the situation.
I totally agree with you. However, I re-verified one more time, and this
is the patch
after which no source level debugging is available for me.
>
> > > If I do "add-symbol-file.." in the DS-5 Debug console as the
exception
> > > handler reports, I have an ability to debug (so the address is
shifted
> > > +0x1 comparing to the proper address) Do you know if  anybody
else
> > > had this issue on an armv8 64 bit platform after this patch was
> > > applied?
> > > Please advise what I could be missing...
> > >
> >
> > Hmm, that looks like a separate issue. Due to the padding required for
> > runtime drivers, which have a 64k section alignment, the start of the
file
> and
> > the start of the text section are 64k apart, so that output is not
> unexpected.
> > In GDB, add-symbol-file takes the start of the .text section, not the
start of
> > the image.
>
> Are you saying this also started happening with the commit in question
or is
> that something independent?
Eugene, I think there is actually one issue.
It looks like "No debug directory" message was from day 1 (last year,
sometime Jul) for me,
but it did not affect debugging in any way, so I simply ignored it.
With this commit the source level debugging (we use DS-5) is unavailable
for me, even though debugger says
that symbols were loaded successfully. For the driver of interest (say
RuntimeClock...) I manually shift  -0x1, and
then the source-level debugging is available again.

 As Ard says if the debugger needs the start of
> .text then this address may not be correct since the output is generated
as
> follows:
>
> DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",
> DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof (Temp)),
> (UINTN)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders)));
>
> With our debugger (TRACE32) we only emit ImageAddress and don't add
> SizeOfHeaders:
>
>DEBUG((EFI_D_ERROR, "data.load.elf %a a:0x%08x /NOCODE /NOCLEAR\n",
> ImageContext->PdbPointer, ImageAddress));
>
> The adding of SizeOfHeaders used to be required when the PE-COFF
> conversion would shift the .text section to make room for the PE-COFF
> header but recent changes made the ELF and PE-COFF layout align so that
> this offset was no longer necessary.
>
> Eugene

Ard, Eugene,
Here is the section from the dsc.
I am building a DEBUG version,
ARM_BDS is not used,
SECURE BOOT is disabled.

If you spot anything suspicious or need additional info please let me
know.

-- Starts here
[LibraryClasses.common]
!if $(TARGET) == RELEASE
  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf

UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocationLib/Unc
achedMemoryAllocationLib.inf
!else

DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf

UncachedMemoryAllocationLib|ArmPkg/Library/UncachedMemoryAllocationLib/Unc
achedMemoryAllocationLib.inf
#
UncachedMemoryAllocationLib|ArmPkg/Library/DebugUncachedMemoryAllocationLi
b/DebugUncachedMemoryAllocationLib.inf
!endif

DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDeb
ugPrintErrorLevelLib.inf

  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf

SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizati
onLib.inf

PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNul
l.inf
  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf

PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCof
fGetEntryPointLib.inf
  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf

UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressL
ib.inf
  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf

  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf

UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/Uef
iRuntimeServicesTableLib.inf
  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf

UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootS
ervicesTableLib.inf

DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib
.inf

Re: [edk2] Error while loading a symbol file (No Debug Directory)

[Vladimir Olovyannikov]

Hi Ard,

Thank you for the hint.
Here is the result of git bisection (first bad):

Author: Cohen, Eugene <eug...@hp.com>  2016-03-07 07:16:35
Committer: Ard Biesheuvel <ard.biesheu...@linaro.org>  2016-03-16 04:19:58
Parent: d2bb61a2328d512c0aeb201ab8a5a6497f415afb (ArmPkg/ArmLib: add
ArmReadHcr to enable read-modify-write of HCR)
Child:  25896aa391d04efecbee65bdf41a2de3660da440 (MdeModulePkg:
ConSplitterDxe: use U64 mult/div wrappers in AbsPtr scaling)
Branches: master, remotes/origin/master
Follows:
Precedes:

ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib

Introduce ARM and AArch64 instances of the CpuExceptionHandlerLib
which
provides exception handling and registration of handlers regardless of
execution phase.

Two variants of the ArmExceptionLib are provided: one where exception
handlers reside within the module (meeting appropriate architectural
alignment requirements for the vector table) and another one that will
relocate a copy of thee xception handlers to an address specified by
PcdCpuVectorBaseAddress. The ArmRelocateExceptionLib is intended for
use
in cases where ArmExceptionLib is too large for the application
(uncompressed XIP images) as driven by the vector table alignment
padding.

The AArch64 build of this library supports execution at EL1, EL2, and
EL3
exception levels.

Tested on ARM, and AArch64 with SEC, DXE Core, and CpuDxe modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eug...@hp.com>
Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

As soon as I apply this commit, I lose an opportunity for source level
debugging.
This is a pretty recent commit, so maybe I am still missing something in
my dsc?

Note:
When intentionally made one of the modules to crash, I found that the arm
exception handler showed that the module was loaded at 0xB6D5
Wheresa "add-symbol-file" line on the console showed:
add-symbol-file
/uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/EmbeddedPkg/RealTimeClockRuntimeDxe
/RealTimeClockRuntimeDxe/DEBUG/RealTimeClock.dll 0xB6D6

If I do "add-symbol-file.." in the DS-5 Debug console as the exception
handler reports,
I have an ability to debug (so the address is shifted +0x1 comparing
to the proper address)
Do you know if  anybody else had this issue on an armv8 64 bit platform
after this patch was applied?
Please advise what I could be missing...

Thank you,
Vladimir

 -Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, March 23, 2016 2:36 AM
To: Vladimir Olovyannikov
Cc: edk2-devel@lists.01.org
Subject: Re: Error while loading a symbol file (No Debug Directory)

On 22 March 2016 at 19:19, Vladimir Olovyannikov
<vladimir.olovyanni...@broadcom.com> wrote:
> Sorry for the spam,
> Sending to the proper list now
>
> -Original Message-
> From: Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
> Sent: Tuesday, March 22, 2016 11:15 AM
> To: 'edk2-de...@lists.sourceforge.net'
> Cc: 'Ard Biesheuvel'
> Subject: Error while loading a symbol file (No Debug Directory)
>
> Hi All,
>
> After been away from the UEFI development and bring-up, I noticed that I
> could not DS-5 debug some of the UEFI modules anymore (some are OK)
> after returning back to the UEFI (ARMv8 64 bit platform).
>
> I am using the cmd_load_symbols.py to load symbols via this line:
> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -v -f
> (0x8500, 0x000F) -m (0x8000,0x4000) -a
>
> From .fdf:
> [FD.BL33_AP_UEFI]
> BaseAddress   = 0x8500|gArmTokenSpaceGuid.PcdFdBaseAddress
> Size  = 0x000F|gArmTokenSpaceGuid.PcdFdSize
>
> From .dsc:
> gArmTokenSpaceGuid.PcdSystemMemoryBase|0x8000
> gArmTokenSpaceGuid.PcdSystemMemorySize|0x4000
>
> When I run the cmd_load_symbols.py script I am getting
>
> Error while loading a symbol file (EfiFileSectionPE64: No Debug
Directory)
> Add symbols of /
>
uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/MdeModulePkg/Universal/PCD/Dxe/Pcd/D
> EBUG/PcdDxe.dll at 0xbbf44000
> Error while loading a symbol file (EfiFileSectionPE64: No Debug
Directory)
> Error while loading a symbol file (EfiFileSectionPE64: No Debug
Directory)
> Add symbols of
>
/uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/MdeModulePkg/Universal/SecurityStub
> Dxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll at 0xbbf2f000
> Error while loading a symbol file (EfiFileSectionPE64: No Debug
Directory)
>
> And only assembly is available for debug.
> I did not have this problem earlier (well, much earlier, in Oct 2015)
>
> Please let me know what I am doing wrong, and/or what I need to do to
> enable source level debugging; I was following
> https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg-Ds5
>

Any chance you could bisect this?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Vladimir Olovyannikov]

Hi Ard, Eugene,

Thanks a lot for your help.
You were absolutely right: I forgot to switch from
CpuExceptionhandlerLibNull to ArmExceptionLib in my platform dsc file.

Everything is OK now.

Eugene, please let me know if you still want to do some testing on the
platform.

Thank you,
Vladimir
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, March 18, 2016 7:00 AM
To: Cohen, Eugene
Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org
Subject: Re: Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65
causes UEFI boot freeze (armv8 platform)

On 18 March 2016 at 14:34, Cohen, Eugene <eug...@hp.com> wrote:
> Vladimir,
>
>> Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280
>> ArmTimerDxe.efi
>
> This is the point where the Timer driver will register with the interrupt
> controller driver and enable timer tick interrupts so the first IRQ
> interrupt will fire shortly thereafter.
>
>> JTAG debug shows that the CPU is looping in IrqSpx:
>> EL2:0x85008A80 : BIrqSPx ; 0x85008A80
>
> This instruction does not correspond to the new exception handling code
> (ArmExceptionLib).  Based on my searching the only place I see a construct
> like this is in DebugAgentException.S
> (ArmPkg\Library\DebugAgentSymbolsBaseLib).
>
> I haven't used this library but understand that it (the library class, at
> least) intended to assist with source level debugging (GDB agent over
> serial port or equivalent).  This particular instance doesn't actually
> appear to be a debug agent nor does it implement the
> SaveAndSetDebugTimerInterrupt.   This instance is installing exception
> handlers that just spin but now that's overlapping with the
> responsibilities of CpuExceptionHandlerLib (and the
> DefaultExceptionHandlerLib which provides more useful output than a
> spinloop).  We don't want yet another copy of exception handlers floating
> around (which is the whole point behind ArmExceptionLib), instead we need
> to find a way to make them work together or at least rip out the exception
> vector init from this driver.
>
> Regardless, when CpuDxe initializes exceptions it should be taking over
> exception vectors including the IRQ handler.  Since I don't have a
> platform to test this with at the moment, can you help debug it by
> stepping through  InitializeExceptions in CpuDxe and see what is happening
> with regard to the exception table (VBAR programming, and the contents at
> that address)?
>
> Also please help me duplicate your setup - can you confirm which libraries
> you are using (are you using the ArmPkg DebugAgentSymbolsBaseLib?) and
> which components (SEC or otherwise) are using it?
>

You need to change the resolution for CpuExceptionHandlerLib in your
platform definition:

-
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

Thank you Andrew, Ard.

The problem was my wrong interpretation of the offset in DS-5 for the ShellPkg,
and therefore wrong entry point arithmetic.

Vladimir

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, November 30, 2015 10:02 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with
> step-by-step debugging in uefi
> 
> 
> > On Nov 23, 2015, at 11:31 PM, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >
> > On 24 November 2015 at 00:38, Vladimir Olovyannikov
> > <volov...@broadcom.com> wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>> Sent: Tuesday, November 10, 2015 10:04 AM
> >>> To: Vladimir Olovyannikov
> >>> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> >>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64
> with
> >>> step-by-step debugging in uefi
> >>>
> >>> On 10 November 2015 at 18:41, Vladimir Olovyannikov
> >>> <volov...@broadcom.com> wrote:
> >>>> Ard,
> >>>> Many thanks for your help. It works.
> >>>>
> >>>
> >>> Great! Thanks for reporting back.
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>>> Sent: Monday, November 09, 2015 10:31 PM
> >>>> To: Vladimir Olovyannikov
> >>>> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> >>>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64
> >>> with step-by-step debugging in uefi
> >>>>
> >>>> On 9 November 2015 at 19:01, Vladimir Olovyannikov
> >>>> <volov...@broadcom.com> wrote:
> >>>>> -Original Message-
> >>>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>>>> Sent: Sunday, November 08, 2015 10:52 PM
> >>>>> To: Vladimir Olovyannikov
> >>>>> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> >>>>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on
> AARCH64
> >>> with step-by-step debugging in uefi
> >>>>>
> >>>>> On 6 November 2015 at 21:32, Vladimir Olovyannikov
> >>>>> <volov...@broadcom.com>> wrote:
> >>>>>>> Hello Ard, Eugene,
> >>>>>>> Thank you for explanation.
> >>>>>>>
> >>>>>>> Ard, I tried the patch, but it cannot be applied to the latest 
> >>>>>>> (pulled a
> >>> minute ago, git-svn-id:
> >>> https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 6f19259b-
> 4bc3-
> >>> 4df7-8a09-765794883524)
> >>>>>>> tree: all 3 hunks failed. Which commit should I be based on to apply
> the
> >>> patch?
> >>>>>>>
> >>>>>>> Anyway I found the lines manually and changed them. However,
> when
> >>> I try to
> >>>>>>>
> >>>>>>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f
> >>> (0x8500,0x0028) -m (0x8000,0x4000) -a
> >>>>>>> I am getting
> >>>>>>>
> >>>>>>> ERROR(?): ValueError: need more than 1 value to unpack
> >>>>>>>  File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py",
> line
> >>> 94, in >
> >>>>>>>armplatform_debugger.load_all_symbols()
> >>>>>>> ERROR(CMD656):
> >>>>>>> # in
> /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2
> >>> while executing: source
> >>> /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f
> >>> (0x8500,0x0028) -m (0x8000,0x4000) -a
> >>>>>>> ! The script
> /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py
> >>> failed to complete due to an error during execution of the script
> >>>>>>>
> >> [...]
> >> Ard, I got a pretty much the same issue when I tried to do some
> debugging in the ShellPkg.
> >> Except Shell I can perfectly debug everything.
> >>
> >> 1. source / uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f
> (0

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 18, 2015 11:32 PM
> To: Vladimir Olovyannikov
> Cc: Mark Rutland; edk2-devel@lists.01.org
> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
> 
> On 19 November 2015 at 05:48, Vladimir Olovyannikov
> <volov...@broadcom.com> wrote:
> >
> >
[...]
> > A side note: I got the u-boot source for that board and there are several
> hacks made to avoid SError (writing 0x20 to the HCR register (reroute SError
> to EL2), and
> > just ERET from SError exception handler, and then write 0x0 to HCR before
> Linux boots), so it could be an HW issue I am not aware of as of yet.
> 
> OK, that would explain it. Note that the kernel will replace the EL2
> vector table if booted at EL2, so this is definitely not a workaround
> that you would want to reuse in UEFI.
[...]

[...]
> >>
> >> I'd still like to double check the value of VBAR_EL2 as it is written,
> >> it should be a multiple of 2 KB
> > It is always at 0x85008800 which is a multiple of 2K
> > Any other things to verify?
> >
> 
> No, that looks fine. You need to get in touch with the authors of the
> U-Boot code to figure out what it is they are working around. Simply
> ignoring SErrors is obviously not a long term solution.
> 
Thanks a lot for your help Ard, Mark,
It is the ATF which has an issue. I will post additional information if there 
is still a problem after ATF implementation is fixed

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 10, 2015 10:04 AM
> To: Vladimir Olovyannikov
> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with
> step-by-step debugging in uefi
> 
> On 10 November 2015 at 18:41, Vladimir Olovyannikov
> <volov...@broadcom.com> wrote:
> > Ard,
> > Many thanks for your help. It works.
> >
> 
> Great! Thanks for reporting back.
> 
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Monday, November 09, 2015 10:31 PM
> > To: Vladimir Olovyannikov
> > Cc: Cohen, Eugene; edk2-devel@lists.01.org
> > Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64
> with step-by-step debugging in uefi
> >
> > On 9 November 2015 at 19:01, Vladimir Olovyannikov
> > <volov...@broadcom.com> wrote:
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Sunday, November 08, 2015 10:52 PM
> >> To: Vladimir Olovyannikov
> >> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> >> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64
> with step-by-step debugging in uefi
> >>
> >> On 6 November 2015 at 21:32, Vladimir Olovyannikov
> >> <volov...@broadcom.com>> wrote:
> >>>> Hello Ard, Eugene,
> >>>> Thank you for explanation.
> >>>>
> >>>> Ard, I tried the patch, but it cannot be applied to the latest (pulled a
> minute ago, git-svn-id:
> https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 6f19259b-4bc3-
> 4df7-8a09-765794883524)
> >>>> tree: all 3 hunks failed. Which commit should I be based on to apply the
> patch?
> >>>>
> >>>> Anyway I found the lines manually and changed them. However, when
> I try to
> >>>>
> >>>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f
> (0x8500,0x0028) -m (0x8000,0x4000) -a
> >>>> I am getting
> >>>>
> >>>> ERROR(?): ValueError: need more than 1 value to unpack
> >>>>   File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line
> 94, in >
> >>>> armplatform_debugger.load_all_symbols()
> >>>> ERROR(CMD656):
> >>>> # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2
> while executing: source
> /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f
> (0x8500,0x0028) -m (0x8000,0x4000) -a
> >>>> ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py
> failed to complete due to an error during execution of the script
> >>>>
[...]
Ard, I got a pretty much the same issue when I tried to do some debugging in 
the ShellPkg.
Except Shell I can perfectly debug everything. 

1. source / uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
(0x8500,0x0028) -m (0x8000,0x4000) -a
 loads symbols fine, but does not recognize any module matching the current 
PC if stopped in the shell.
2. Loading symbols with "add-symbol-file 
/uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
 0xB6926000"
"recognizes" modules (wrong ones though) but the source code does not match 
disassembly.

So with Shell debug using DS-5 the code does not match the source. 
Is there a special linker setting I am missing or a technique? 
I am using the latest UEFI code from
https://github.com/tianocore/edk2.git

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, November 16, 2015 10:28 AM
> To: Vladimir Olovyannikov
> Cc: Mark Rutland; edk2-devel@lists.01.org
> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
> 
[...]
> >
> > Async abort occurs in ArmWriteVBar() called by InitializeDebugAgent(),
> DebugAgentSymbolsBaseLib.c.
> > Prior to this call I can easily enable async aborts with no "bad"
> consequences.
> >
> > Here is the exact instruction causing the SError in the ArmWriteVBar():
> > 2: msr   vbar_el2, x0// Set the Address of the EL2 Vector Table 
> > in the
> VBAR register
> 
> Are you using a release build? If so, you should check whether x0 is
> correctly aligned to 2 KB. The ASSERT() tries to establish that, but
> it is only active in DEBUG builds.
> 
Ard, it is a DEBUG build.
> 
> > Could it mean that I do not have enough privileges in the UEFI for this
> operation?
> > What would you advise?
> >>
> >> > The boot sequence is BL2->BL3.1->UEFI (plus grub.efi app)->Linux
> >>
> >> I take it per the naming that you are running ARM Trusted Firmware.
> >>
> >> Are you able to unmask SError during BL2 or BL3.1, and if so, does it fire
> >> prior to entering EDK2?
> >>
> >> [...]
> > It fires in the ArmWriteVBar as I mentioned above.
> >>
[...]

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, November 16, 2015 11:08 AM
> To: Vladimir Olovyannikov
> Cc: Mark Rutland; edk2-devel@lists.01.org
> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
> 
> On 16 November 2015 at 19:41, Vladimir Olovyannikov
> <volov...@broadcom.com> wrote:
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Monday, November 16, 2015 10:28 AM
> >> To: Vladimir Olovyannikov
> >> Cc: Mark Rutland; edk2-devel@lists.01.org
> >> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
> >>
> > [...]
> >> >
> >> > Async abort occurs in ArmWriteVBar() called by InitializeDebugAgent(),
> >> DebugAgentSymbolsBaseLib.c.
> >> > Prior to this call I can easily enable async aborts with no "bad"
> >> consequences.
> >> >
> >> > Here is the exact instruction causing the SError in the ArmWriteVBar():
> >> > 2: msr   vbar_el2, x0// Set the Address of the EL2 Vector 
> >> > Table in
> the
> >> VBAR register
> >>
> >> Are you using a release build? If so, you should check whether x0 is
> >> correctly aligned to 2 KB. The ASSERT() tries to establish that, but
> >> it is only active in DEBUG builds.
> >>
> > Ard, it is a DEBUG build.
> 
> OK. So that should confirm that x0 is aligned to 2 KB.
> 
> Perhaps the write to VBAR_EL2 enables the delivery in some way. Could
> you check the A bit in ESR_EL1 before and after?
Ard, ESR_EL1 is all 0x0 before and after.
> 

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Monday, November 16, 2015 11:11 AM
> To: Vladimir Olovyannikov
> Cc: Ard Biesheuvel; edk2-devel@lists.01.org
> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
> 
> On Mon, Nov 16, 2015 at 06:23:20PM +0000, Vladimir Olovyannikov wrote:
> > > -Original Message-
> > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> 
> [...]
> 
> > > What is the earliest point in EDK2 that you have unmasked SError?
> > >
> > > Are you doing this in PrePeiCoreEntryPoint.S, or later?
> > Thanks for the pointers Mark.
> >
> > Async abort occurs in ArmWriteVBar() called by InitializeDebugAgent(),
> DebugAgentSymbolsBaseLib.c.
> 
> Interesting.
> 
> Is the SError taken directly to EL2? I understood from your previous
> reply that the EDK2 exception handler was invoked at this point, so is
> there anything at EL3 which is trying to catch exceptions and then
> re-inject them down to EL2?
None that I would be aware of.
> 
> The fact that we're clearly able to take the SError via the table
> confuses me; it makes it sound like the table is fine.
> 
> Is that exception taken via the old vector table, or the new one we're
> trying to install with this write to VBAR_EL2?
The exception is taken from the NEW vector table.
> 
> > Prior to this call I can easily enable async aborts with no "bad"
> consequences.
> >
> > Here is the exact instruction causing the SError in the ArmWriteVBar():
> > 2: msr   vbar_el2, x0// Set the Address of the EL2 Vector Table 
> > in the
> VBAR register
> 
> As SError is asynchronous, it's not necessarily the case that the write
> to VBAR_EL2 is the trigger.
> 
> I note that in ArmPkg/Library/ArmLib/AArch64/AArch64Support.S, there is
> an ISB at the end of ArmWriteVBar(). That might happen to "flush" a
> pending SError on the CPU and cause it to be taken.
> 
> > Could it mean that I do not have enough privileges in the UEFI for this
> operation?
> 
> There are no traps or enables affecting VBAR_EL2. So long as EDK2 is
> running at EL2 or higher it should be sufficiently privileged to read or
> write VBAR_EL2.

I see. UEFI is running at EL2.
> 
> > What would you advise?
> 
> My hunch is that we have a pending SError that gets "flushed" by an ISB.
> 
> You should be able to add ArmInstructionSynchronizationBarrier() calls
> in the general vicinity of InitializeDebugAgent() (e.g. before the call
> to ArmWriteVBar(), in the caller of InitializeDebugAgent(), before it
> and the previous few functions are called).
> 
> That may cause the SError to be taken closer to its trigger, and if so
> it would be possible to bisect down to the trigger.
Did that. Regardless of ArmInstructionSycnhronizationBarrier() and subsequent 
enabling of the async abort
SError happens right in the ArmWriteVBar.

Thank you,
Vladimir 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, November 13, 2015 3:00 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: Armv8 64bit: System error booting linux from the UEFI
> 
(removed extra text)

> >> This is a firmware problem, not a kernel problem. The kernel is
> >> entered with an pending asynchronous external abort, which may have
> >> several causes. You need to instrument the firmware (i.e., unmask the
> >> aborts earlier and run in the debugger) to get a feeling for what is
> >> going on there. It could be something like speculative accesses to
> >> unassigned physical ranges that are mapped cacheable inadvertently,
> >> but it could be lots of other things as well.
> >
> >
> 
> FYI http://article.gmane.org/gmane.comp.bios.edk2.devel/4246
> 
> This fixes a bug that could potentially result in speculative reads to
> device regions. We have also made some other changes regarding
> cacheability and shareability recently (and the patch above will
> likely go in today) so it is probably worthwhile to make sure you are
> based on the latest upstream.

Thank you Ard, I got the latest upstream. Same issue... It is not related to 
the cache.

I investigated and found that as soon as I do
msr DAIFClr, #4 (or call ArmEnableAsynchronousAbort()) anywhere in the UEFI, 
I immediately get this exception.

Here is slightly modified efi_entry.S (immediately on ENTRY):

ENTRY(efi_stub_entry)
0x995a440   msr DAIFClr, #4 <-- crashes here right away
/*
 * Create a stack frame to save FP/LR with extra space
 * for image_addr variable passed to efi_entry().
 */
0x995a444 stp   x29, x30, [sp, #-32]!
...

So for me just performing this instruction causes SError immediately.
Here is the excerpt from the UEFI exception handler on this command:

SError Exception at 0xA995A444

  X0 0xBEDB8798   X1 0xBEFE0018   X2 0xA995A440   X3 
0x00B0
  X4 0xBEDB8598   X5 0xBF4BDE8C   X6 0x005C   X7 
0x
  X8 0xB986DF9C   X9 0xB9F8  X10 0x  X11 
0xD800
 X12 0xDC00  X13 0x200C  X14 0x0003  X15 
0x001D
 X16 0xB5B0  X17 0x0A880C885C60448A  X18 0x0A880C88  X19 
0xBF4D0780
 X20 0x00B8  X21 0xB986DF9B  X22 0xBE31A040  X23 
0xB98E727A
 X24 0xB98E7274  X25 0xB998D7A4  X26 0x  X27 
0x
 X28 0x   FP 0xB630   LR 0xBF4A36C0  
...


  
 SP 0xB5B0  ELR 0xA995A444  SPSR 0x6209  FPSR 
0x  
   
 ESR 0xBF00  FAR 0x 

  


  
 ESR : EC 0x2F  IL 0x1  ISS 0x0100  

  
ASSERT  
/uefi/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(186):
 ((BOOLEAN)(0==1))

The boot sequence is BL2->BL3.1->UEFI (plus grub.efi app)->Linux
UEFI is running in EL2.
Maybe I am missing some initialization in the UEFI and that is the reason any 
msr DAIFClr,#4 causes this SError exception?

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 11, 2015 1:08 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: Armv8 64bit: System error booting linux from the UEFI
> 
> On 11 November 2015 at 01:20, Vladimir Olovyannikov
> <volov...@broadcom.com> wrote:
> > Hello,
> >
> > I am not sure this is the right forum to ask this question, so I am sorry in
> > advance if this is an offtopic here (please point me to the proper one).
> >
> > I brought up UEFI on the device and am trying to load linux from the SD
> card
> > (loading from the network using GRUB is a topic for another message).
> >
> > Linux kernel starts and shortly after that (as soon as local_async is
> > enabled which is simple “MSR DAIfclr,4”) there is a kernel crash with
> >
> > “Bad mode in Error handler detected, code 0xbf00 -- SError”
> > Here is the log:
> >
> >
> >
> > The default boot selection will start in  10 seconds
> >
> 
> Unrelated note: *please* get rid of the ARM BDS and use the Intel BDS
> instead. The ARM BDS violates the UEFI spec, (i.e., you cannot boot
> installer images from it without a lot of hassle) and does not allow
> you to enable UEFI secure boot.
> 
> Look at the development history of ArmVExpress-FVP-AArch64.dsc for
> hints how to do this.
Thank you for the hint. I will follow your advice to get rid of the ARM BDS.
> 
> > [1] Linux Kernel from SD Card
> >
> > - SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
> >
> > - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8
> > earlycon=uart8250,mmio32,0x6613,maxcpus=1
> >
> > [2] GRUB
> >
> > - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
> >
> > - Arguments:
> >
> > [3] Shell
> >
> > [4] Boot Manager
> >
> > Start: 1
> >
> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
> BEDB9DA0
> >
> > BlockSize : 512
> >
> > LastBlock : 3A9FFF
> >
> > InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B
> BEDB9798
> >
> > InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B
> BEDB9670
> >
> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
> BEDB95A0
> >
> > InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B
> BEDAF030
> >
> > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B
> BE2E6040
> >
> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> >
> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> >
> > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
> BEDB0718
> >
> > EFI stub: Booting Linux Kernel...
> >
> > ConvertPages: Incompatible memory types
> >
> > EFI stub: Using DTB from command line
> >
> > EFI stub: Exiting boot services and installing virtual address map...
> >
> > MmcHost: ExitBootServicesEvent+
> >
> > Marked card brcm-SDIO1 as removed
> >
> > Resetting Card brcm-SDIO1
> >
> > brcm-SDIO1 Card reset done.
> >
> > MmcHost: ExitBootServicesEvent-
> >
> > MmcHost: ExitBootServicesEvent+
> >
> > Marked card brcm-SDIO0 as removed
> >
> > Resetting Card brcm-SDIO0
> >
> > brcm-SDIO0 Card reset done.
> >
> > MmcHost: ExitBootServicesEvent-
> >
> > [0.00] Booting Linux on physical CPU 0x0
> >
> > [0.00] Initializing cgroup subsys cpu
> >
> > [0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc
> version
> > 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro
> > GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
> >
> > [0.00] CPU: AArch64 Processor [411fd073] revision 3
> >
> > [0.00] Detected PIPT I-cache on CPU0
> >
> > [0.00] earlycon: Early serial console at MMIO32 0x6613 (options
> > 'maxcpus=1')
> >
> > [0.00] bootconsole [uart0] enabled
> >
> > [0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
> >
> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
> >
> > [0.00] Hardware name: SVK proto (DT)
> >
> > [0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti:
> > ffc00074c000
> >
> > [0.00] PC is at setup_arch+0x2

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

Ard,
Many thanks for your help. It works.

Vladimir

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Monday, November 09, 2015 10:31 PM
To: Vladimir Olovyannikov
Cc: Cohen, Eugene; edk2-devel@lists.01.org
Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
step-by-step debugging in uefi

On 9 November 2015 at 19:01, Vladimir Olovyannikov
<volov...@broadcom.com> wrote:
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, November 08, 2015 10:52 PM
> To: Vladimir Olovyannikov
> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
> step-by-step debugging in uefi
>
> On 6 November 2015 at 21:32, Vladimir Olovyannikov
> <volov...@broadcom.com>> wrote:
>>> Hello Ard, Eugene,
>>> Thank you for explanation.
>>>
>>> Ard, I tried the patch, but it cannot be applied to the latest (pulled a 
>>> minute ago, git-svn-id: 
>>> https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 
>>> 6f19259b-4bc3-4df7-8a09-765794883524)
>>> tree: all 3 hunks failed. Which commit should I be based on to apply the 
>>> patch?
>>>
>>> Anyway I found the lines manually and changed them. However, when I try to
>>>
>>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>>> I am getting
>>>
>>> ERROR(?): ValueError: need more than 1 value to unpack
>>>   File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line 94, in 
>>> >
>>> armplatform_debugger.load_all_symbols()
>>> ERROR(CMD656):
>>> # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 while 
>>> executing: source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>>> ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py failed to 
>>> complete due to an error during execution of the script
>>>
>>> Replacing the script with the older version makes it work as before, but 
>>> again the debugger is useless.
>>>
>>> Any idea what is wrong?
>>>
>
>>No, not a clue. But could you please share the diff between the
>>version of the script that works for you and the version that doesn't?
>>I don't think the patch I sent could trigger the error you are seeing,
>>so it must be something else that changed.
> Here is the diff.
>
> --- firmware_volume_old.py  2015-06-24 15:15:37.0 -0700
> +++ firmware_volume_new.py  2015-11-06 11:49:24.321730539 -0800
> @@ -91,12 +91,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -stripped_size = struct.unpack("<H", 
> self.ec.getMemoryService().read(self.base_te + 0x6, 2, 32))[0]
> -stripped_size -= EfiSectionTE.SIZEOF_EFI_TE_IMAGE_HEADER
> -
> -base_of_code = self.ec.getMemoryService().readMemory32(self.base_te 
> + 0xC)
> -
> -return self.base_te + base_of_code - stripped_size
> +return self.base_pe32
>

This hunk is incorrect. Could you please try the patch instead?
(attached, this time, so it should apply more easily)

Thanks,
Ard.

>  class EfiSectionPE32:
>  def __init__(self, ec, base_pe32):
> @@ -131,17 +126,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(self.base_pe32 + 0x3C)
> -
> -base_of_code = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_of_data = self.base_pe32 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
> -
> -if (base_of_code < base_of_data) and (base_of_code != 0):
> -return base_of_code
> -else:
> -return base_of_data
> -
> +return self.base_pe32
>  class EfiSectionPE64:
>  def __init__(self, ec, base_pe64):
>  self.ec = ec
> @@ -176,16 +161,7 @@
>  return filename[0:string.find(filename,'\0')]
>
>  def get_debug_elfbase(self):
> -# Offset from dos hdr to PE file hdr
> -pe_file_header = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
> -
> -base_of_code = self.base_pe64 + 
> self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
> -base_

[edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

Hello,

I am not sure this is the right forum to ask this question, so I am sorry in 
advance if this is an offtopic here (please point me to the proper one).

I brought up UEFI on the device and am trying to load linux from the SD card 
(loading from the network using GRUB is a topic for another message).

Linux kernel starts and shortly after that (as soon as local_async is enabled 
which is simple "MSR DAIfclr,4") there is a kernel crash with
"Bad mode in Error handler detected, code 0xbf00 -- SError"

Here is the log:

The default boot selection will start in  10 seconds
[1] Linux Kernel from SD Card
- SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
- Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8 
earlycon=uart8250,mmio32,0x6613,maxcpus=1
[2] GRUB
- MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
- Arguments:
[3] Shell
[4] Boot Manager
Start: 1
InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB9DA0
BlockSize : 512
LastBlock : 3A9FFF
InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B BEDB9798
InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B BEDB9670
InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB95A0
InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B BEDAF030
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BE2E6040
Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEDB0718
EFI stub: Booting Linux Kernel...
ConvertPages: Incompatible memory types
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
MmcHost: ExitBootServicesEvent+
Marked card brcm-SDIO1 as removed
Resetting Card brcm-SDIO1
brcm-SDIO1 Card reset done.
MmcHost: ExitBootServicesEvent-
MmcHost: ExitBootServicesEvent+
Marked card brcm-SDIO0 as removed
Resetting Card brcm-SDIO0
brcm-SDIO0 Card reset done.
MmcHost: ExitBootServicesEvent-
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc version 
4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro 
GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
[0.00] CPU: AArch64 Processor [411fd073] revision 3
[0.00] Detected PIPT I-cache on CPU0
[0.00] earlycon: Early serial console at MMIO32 0x6613 (options 
'maxcpus=1')
[0.00] bootconsole [uart0] enabled
[0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
[0.00] Hardware name: SVK proto (DT)
[0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
ffc00074c000
[0.00] PC is at setup_arch+0x260/0x5b4
[0.00] LR is at setup_arch+0x25c/0x5b4
[0.00] pc : [] lr : [] pstate: 
02c5
[0.00] sp : ffc00074ff20
[0.00] x29: ffc00074ff20 x28: 
[0.00] x27: ffc81198 x26: 807cd000
[0.00] x25: 807ca000 x24: 8000
[0.00] x23:  x22: ffc000752000
[0.00] x21: ffc000752610 x20: ffbffa80
[0.00] x19: ffc8 x18: 
[0.00] x17: 05e3 x16: 1000
[0.00] x15: 1c00 x14: 0ffe
[0.00] x13: 0020 x12: 0028
[0.00] x11: 0007 x10: 0101010101010101
[0.00] x9 : fffb x8 : 0008
[0.00] x7 : 0003 x6 : 0080
[0.00] x5 : 005f x4 : 
[0.00] x3 :  x2 : 0065
[0.00] x1 :  x0 : 0001
[0.00]
[0.00] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
[0.00] Hardware name: SVK proto (DT)
[0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti: 
ffc00074c000
[0.00] PC is at setup_arch+0x260/0x5b4
[0.00] LR is at setup_arch+0x25c/0x5b4
[0.00] pc : [] lr : [] pstate: 
02c5
[0.00] sp : ffc00074ff20
[0.00] x29: ffc00074ff20 x28: 
[0.00] x27: ffc81198 x26: 807cd000
[0.00] x25: 807ca000 x24: 8000
[0.00] x23:  x22: ffc000752000
[0.00] x21: ffc000752610 x20: ffbffa80
[0.00] x19: ffc8 x18: 
[0.00] x17: 05e3 x16: 1000
[0.00] x15: 1c00 x14: 0ffe
[0.00] x13: 0020 

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Sunday, November 08, 2015 10:52 PM
To: Vladimir Olovyannikov
Cc: Cohen, Eugene; edk2-devel@lists.01.org
Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
step-by-step debugging in uefi

On 6 November 2015 at 21:32, Vladimir Olovyannikov
<volov...@broadcom.com>> wrote:
>> Hello Ard, Eugene,
>> Thank you for explanation.
>>
>> Ard, I tried the patch, but it cannot be applied to the latest (pulled a 
>> minute ago, git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 
>> 6f19259b-4bc3-4df7-8a09-765794883524)
>> tree: all 3 hunks failed. Which commit should I be based on to apply the 
>> patch?
>>
>> Anyway I found the lines manually and changed them. However, when I try to
>>
>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>> I am getting
>>
>> ERROR(?): ValueError: need more than 1 value to unpack
>>   File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line 94, in 
>> >
>> armplatform_debugger.load_all_symbols()
>> ERROR(CMD656):
>> # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 while 
>> executing: source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
>> (0x8500,0x0028) -m (0x8000,0x4000) -a
>> ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py failed to 
>> complete due to an error during execution of the script
>>
>> Replacing the script with the older version makes it work as before, but 
>> again the debugger is useless.
>>
>> Any idea what is wrong?
>>

>No, not a clue. But could you please share the diff between the
>version of the script that works for you and the version that doesn't?
>I don't think the patch I sent could trigger the error you are seeing,
>so it must be something else that changed.
Here is the diff.

--- firmware_volume_old.py  2015-06-24 15:15:37.0 -0700
+++ firmware_volume_new.py  2015-11-06 11:49:24.321730539 -0800
@@ -91,12 +91,7 @@
 return filename[0:string.find(filename,'\0')]
 
 def get_debug_elfbase(self):
-stripped_size = struct.unpack("<H", 
self.ec.getMemoryService().read(self.base_te + 0x6, 2, 32))[0]
-stripped_size -= EfiSectionTE.SIZEOF_EFI_TE_IMAGE_HEADER
-
-base_of_code = self.ec.getMemoryService().readMemory32(self.base_te + 
0xC)
-
-return self.base_te + base_of_code - stripped_size
+return self.base_pe32
 
 class EfiSectionPE32:
 def __init__(self, ec, base_pe32):
@@ -131,17 +126,7 @@
 return filename[0:string.find(filename,'\0')]
 
 def get_debug_elfbase(self):
-# Offset from dos hdr to PE file hdr
-pe_file_header = self.base_pe32 + 
self.ec.getMemoryService().readMemory32(self.base_pe32 + 0x3C)
-
-base_of_code = self.base_pe32 + 
self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
-base_of_data = self.base_pe32 + 
self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
-
-if (base_of_code < base_of_data) and (base_of_code != 0):
-return base_of_code
-else:
-return base_of_data
-
+return self.base_pe32
 class EfiSectionPE64:
 def __init__(self, ec, base_pe64):
 self.ec = ec
@@ -176,16 +161,7 @@
 return filename[0:string.find(filename,'\0')]
 
 def get_debug_elfbase(self):
-# Offset from dos hdr to PE file hdr
-pe_file_header = self.base_pe64 + 
self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
-
-base_of_code = self.base_pe64 + 
self.ec.getMemoryService().readMemory32(pe_file_header + 0x28)
-base_of_data = self.base_pe64 + 
self.ec.getMemoryService().readMemory32(pe_file_header + 0x2C)
-
-if (base_of_code < base_of_data) and (base_of_code != 0):
-return base_of_code
-else:
-return base_of_data
+return self.base_pe64
 
 class FirmwareFile:
 EFI_FV_FILETYPE_RAW   = 0x01

>> Eugene, so you do not use the so convenient cmd_load_symbols.py script to 
>> load all symbols?
>> I dumped efi and dll as you suggested. The .text and .data sections in 
>> PE-COFF and ELF match 1:1 for me. Still the debugger is useless as it points 
>> to non-relevant code.
>>

>Indeed, this is expected. The PE/COFF and ELF versions of the binary
>should look entirely the same, it's only the DS-5 scripts that needs
>to have the hack removed to deal with the difference.
OK, I see.

Thank you,

Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

Hello Ard, Eugene,
Thank you for explanation.

Ard, I tried the patch, but it cannot be applied to the latest (pulled a minute 
ago, git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 
6f19259b-4bc3-4df7-8a09-765794883524)
tree: all 3 hunks failed. Which commit should I be based on to apply the patch?

Anyway I found the lines manually and changed them. However, when I try to 

source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
(0x8500,0x0028) -m (0x8000,0x4000) -a
I am getting

ERROR(?): ValueError: need more than 1 value to unpack
  File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line 94, in 

armplatform_debugger.load_all_symbols()
ERROR(CMD656): 
# in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 while executing: 
source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f 
(0x8500,0x0028) -m (0x8000,0x4000) -a
! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py failed to 
complete due to an error during execution of the script

Replacing the script with the older version makes it work as before, but again 
the debugger is useless.

Any idea what is wrong?

Eugene, so you do not use the so convenient cmd_load_symbols.py script to load 
all symbols? 
I dumped efi and dll as you suggested. The .text and .data sections in PE-COFF 
and ELF match 1:1 for me. Still the debugger is useless as it points to 
non-relevant code.

Please help me to get back on track with debugger...

Thank you,
Vladimir

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Friday, November 06, 2015 5:36 AM
To: Cohen, Eugene
Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org
Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
step-by-step debugging in uefi

On 6 November 2015 at 14:27, Cohen, Eugene <eug...@hp.com> wrote:
> Vladimir,
>
> Since the UEFI images are PE-COFF but DS-5 builds ELF there is a conversion 
> process in the edk2 build.  This can result in a couple of issues with debug 
> if not handled correctly:
>
> 1. The start of the image for debugger load purposes must be adjusted to 
> reflect the PE/TE header in the image.  If this isn't done correctly the code 
> and data will be shifted and the debugger is useless.
>
> 2. The relative position of .text and .data must be consistent across ELF and 
> PE-COFF.  If this isn't done correctly you may be able to get correlated 
> source code but all references to data (like dumping global variables) are 
> messed up.
>
> The way I go about debugging this is to dump the PE-COFF image (.efi) with 
> dumpbin (from Visual Studio) and dump the ELF image (.dll) with fromelf (from 
> RVCT) and compare the positions of the .text and .data sections.
>
> Based on Ard's response I think you are hitting issue #1.
>

Indeed. I made some changes to the GCC linker scripts recently to
ensure that the PE/COFF and ELF layouts are identical in memory. The
primary reason for doing so was the recent introduction of a security
feature in UEFI that requires the PE/COFF sections to be page aligned,
making it more likely that you would hit #2 in Eugene's list above.

-- 
Ard.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Vladimir Olovyannikov
> Sent: Thursday, November 05, 2015 3:52 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with 
> step-by-step debugging in uefi
>
> Hello All,
>
> I faced a very strange behavior of the DS-5 debugger when I debug AARCH64  
> UEFI with the latest (well, the one which contains
> DEFINE GCC_DLINK2_FLAGS_COMMON = 
> --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
> )
> tools_def.template.
> Whenever I step in the debugger it never matches the source where the 
> execution point currently is.
> It is impossible to step-by-step debug with this...
> If I switch to the older tools_def.template, I don't have those issues, and 
> can debug with no problem.
> However, the ShellPkg cannot be built with older tools_def.template if I want 
> to have ShellPkg (New Shell) instead of ShellBinPkg.
>
> Please advise if I am doing anything wrong?
>
> This is how I debug if step-by-step debug is needed:
>
> I place a while(1) in a place of interest. Build UEFI, and then reboot the 
> board and run the uefi; then when it reaches the point of while1, I connect 
> DS-5 to the device and execute ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py 
> -f (0x8500,0x0028) -m (0x8000,0x4000) -a
>
> And expect to be at the (while1 line). With the latest tools_def.tempalte the 
> source point is weird; with the previous ones - OK.
> Any advice would be appreciated.
>
> Thank you,
> Vladimir
>
> ___

[edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

[Vladimir Olovyannikov]

Hello All,

I faced a very strange behavior of the DS-5 debugger when I debug AARCH64  UEFI 
with the latest
(well, the one which contains
DEFINE GCC_DLINK2_FLAGS_COMMON = 
--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds
)
tools_def.template.
Whenever I step in the debugger it never matches the source where the execution 
point currently is.
It is impossible to step-by-step debug with this...
If I switch to the older tools_def.template, I don't have those issues, and can 
debug with no problem.
However, the ShellPkg cannot be built with older tools_def.template if I want 
to have ShellPkg (New Shell) instead of ShellBinPkg.

Please advise if I am doing anything wrong?

This is how I debug if step-by-step debug is needed:

I place a while(1) in a place of interest. Build UEFI, and then reboot the 
board and run the uefi; then when it reaches the point of while1,
I connect DS-5 to the device and execute
ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f (0x8500,0x0028) -m 
(0x8000,0x4000) -a

And expect to be at the (while1 line). With the latest tools_def.tempalte the 
source point is weird; with the previous ones - OK.
Any advice would be appreciated.

Thank you,
Vladimir

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel