Re: [edk2] [PATCH] BaseTools/BuildReport: fix report for platforms/arches without struct PCDs
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
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
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 ( >> >>>>>> >> >>>>>> &MemoryMapSize, >> >>>>>> MemoryMap, >> >>>>>> &MapKey, >> >>>>>> &DescriptorSize, >> >>>>>> &DescriptorVersion >> >>>>>> ); >> >>>>>> >> >>>>>> if (Status == EFI_BUFFER_TOO_SMALL) { >> >>>>>> >> >>>>>> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; >> >>>>>> MemoryMap = AllocatePages (Pages); >> >>>>>> >> >>>>>> // >> >>>>>> // Get System MemoryMap >> >>>>>> // >> >>>>>> Status = gBS->GetMemoryMap ( >> >>>>>> >> >>>>>> &MemoryMapSize, >> >>>>>> MemoryMap, >> >>>>>> &MapKey, >> >>>>>> &DescriptorSize, >> >>>>>> &DescriptorVersion >> >>>>>> ); >> >>>>>> >> >>>>>> } >> >>>>>> >> >>>>>> // 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); >> >>>>>> Me
Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform
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 ( > > > >> > > > >>&MemoryMapSize, > > > >>MemoryMap, > > > >>&MapKey, > > > >>&DescriptorSize, > > > >>&DescriptorVersion > > > >>); > > > >> > > > >>if (Status == EFI_BUFFER_TOO_SMALL) { > > > >> > > > >> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; > > > >> MemoryMap = AllocatePages (Pages); > > > >> > > > >> // > > > >> // Get System MemoryMap > > > >> // > > > >> Status = gBS->GetMemoryMap ( > > > >> > > > >> &MemoryMapSize, > > > >> MemoryMap, > > > >> &MapKey, > > > >> &DescriptorSize, > > > >> &DescriptorVersion > > > >> ); > > > >> > > > >>} > > > >> > > > >>// 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
Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform
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 ( > > >> > > >>&MemoryMapSize, > > >>MemoryMap, > > >>&MapKey, > > >>&DescriptorSize, > > >>&DescriptorVersion > > >>); > > >> > > >>if (Status == EFI_BUFFER_TOO_SMALL) { > > >> > > >> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; > > >> MemoryMap = AllocatePages (Pages); > > >> > > >> // > > >> // Get System MemoryMap > > >> // > > >> Status = gBS->GetMemoryMap ( > > >> > > >> &MemoryMapSize, > > >> MemoryMap, > > >> &MapKey, > > >> &DescriptorSize, > > >> &DescriptorVersion > > >> ); > > >> > > >>} > > >> > > >>// 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
Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform
>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 ( >>&MemoryMapSize, >>MemoryMap, >>&MapKey, >>&DescriptorSize, >>&DescriptorVersion >>); >>if (Status == EFI_BUFFER_TOO_SMALL) { >> >> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; >> MemoryMap = AllocatePages (Pages); >> >> // >> // Get System MemoryMap >> // >> Status = gBS->GetMemoryMap ( >> &MemoryMapSize, >> MemoryMap, >> &MapKey, >> &DescriptorSize, >> &DescriptorVersion >> ); >>} >> >>// 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
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 ( &MemoryMapSize, MemoryMap, &MapKey, &DescriptorSize, &DescriptorVersion ); if (Status == EFI_BUFFER_TOO_SMALL) { Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; MemoryMap = AllocatePages (Pages); // // Get System MemoryMap // Status = gBS->GetMemoryMap ( &MemoryMapSize, MemoryMap, &MapKey, &DescriptorSize, &DescriptorVersion ); } // 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 2/3] EmbeddedPkg/CoherentDmaLib: Add missing checks to DmaMap
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 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add missing validation
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 1/3] EmbeddedPkg/CoherentDmaLib: Fix typo in DmaAlignedBuffer
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
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, &FileSize, &FileBuffer); 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
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
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
> -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 HOB > + NextHob.Re
Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory
> -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 > > 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 > > > 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", &DelayStr, > > > &DelayVarSize, NULL); > > > + if (!EFI_ERROR (Status)) { > > > +ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn > > > (DelayStr); > > > + } > > > +} > > > + > > > +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) { > > > + Status = ShellFindEnvVarInList(L"silentstart", &NoMapStr, > > > &NoMapVarSize, 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 (!ShellInfoO
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 > 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 > > 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", &DelayStr, > > &DelayVarSize, NULL); > > + if (!EFI_ERROR (Status)) { > > +ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn > > (DelayStr); > > + } > > +} > > + > > +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) { > > + Status = ShellFindEnvVarInList(L"silentstart", &NoMapStr, > > &NoMapVarSize, 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
Re: [edk2] [PATCH 5/7] ArmPlatformPkg/MemoryInitPeiLib: don't reserve primary FV in memory
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", &DelayStr, &DelayVarSize, NULL); + if (!EFI_ERROR (Status)) { +ShellInfoObject.ShellInitSettings.Delay = ShellStrToUintn (DelayStr); + } +} + +if (!ShellInfoObject.ShellInitSettings.BitUnion.Bits.NoMap) { + Status = ShellFindEnvVarInList(L"silentstart", &NoMapStr, &NoMapVarSize, 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 8C0A1B18 InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0
Re: [edk2] Storing Non volatile variables on SD/NAND
> -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
> -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
> -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
> -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
> -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 > > > > > > 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 bridge to
Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform
> -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 > 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
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
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
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" 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 ; 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
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
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
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(&ImagePath); if (MapName != NULL) { -FileStringPath = NULL; NewSize = 0; FileStringPath = StrnCatGrow(&FileStringPath, &NewSize, MapName, 0); if (FileStringPath == NULL) { @@ -1242,10 +1242,10 @@ DoStartupScript( PathRemoveLastItem(FileStringPath); FileStringPath = StrnCatGrow(&FileStringPath, &NewSize, mStartupScript, 0); Status = ShellInfoObject.NewEfiShellProtocol->OpenFileByName(FileStringPath, &FileHandle, 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, &FileHandle, 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)
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
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Vladimir Olovyannikov 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; ClusterSizeTable32[Index].Sectors
Re: [edk2] [PATCH] GPT Shell Application/Library
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 ; Shah, > Tapan ; Michael Zimmermann > > Cc: Ni, Ruiyu ; Arshi, Shala ; > edk2-devel@lists.01.org ; Laszlo Ersek > ; Carsey, Jaben > 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 ; Carsey, Jaben > > ; Michael Zimmermann > > > > Cc: Ni, Ruiyu ; Arshi, Shala > > ; edk2-devel@lists.01.org > > ; Laszlo Ersek > > 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 ; > > Michael Zimmermann > > Cc: Ni, Ruiyu ; Arshi, Shala > > ; edk2-devel@lists.01.org > > ; Carsey, Jaben ; > > Laszlo Ersek > > 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 > > Cc: Laszlo Ersek ; Carsey, Jaben > > ; Ni, Ruiyu ; > > edk2-devel@lists.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 ev
Re: [edk2] [PATCH] GPT Shell Application/Library
> -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 ; > > Michael Zimmermann > > Cc: Ni, Ruiyu ; Arshi, Shala > > ; edk2-devel@lists.01.org > > ; Carsey, Jaben ; > > Laszlo Ersek > > 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 > > Cc: Laszlo Ersek ; Carsey, Jaben > > ; Ni, Ruiyu ; > > edk2-devel@lists.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; > > ed
Re: [edk2] [PATCH] GPT Shell Application/Library
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 ; Michael Zimmermann Cc: Ni, Ruiyu ; Arshi, Shala ; edk2-devel@lists.01.org ; Carsey, Jaben ; Laszlo Ersek 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 Cc: Laszlo Ersek ; Carsey, Jaben ; Ni, Ruiyu ; edk2-devel@lists.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 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" 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 > > .../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 &g
Re: [edk2] [PATCH] GPT Shell Application/Library
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" 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
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" 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()
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 Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Vladimir Olovyannikov --- 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 (&gEfiUnicodeCollation2ProtocolGuid, NULL, (VOID**)&mUnicodeCollationProtocol); -- 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()
-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 -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 ; jaben.car...@intel.com Cc: Vladimir Olovyannikov ; Vladimir Olovyannikov Subject: [PATCH] ShellPkg: Fix erroneous Status returned by ShellOpenFileByName() From: 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 Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Vladimir Olovyannikov --- 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 (&gEfiUnicodeCollation2ProtocolGuid, NULL, (VOID**)&mUnicodeCollationProtocol); -- 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()
From: 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 Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Vladimir Olovyannikov --- 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 (&gEfiUnicodeCollation2ProtocolGuid, NULL, (VOID**)&mUnicodeCollationProtocol); -- 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
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 ; Shah, Tapan ; 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 > -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 (&gEfiUnicodeCollation2ProtocolGuid, NULL, > (VOID**)&mUnicodeCollationProtocol); > -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 > + (&gEfiUnicodeCollation2ProtocolGuid, > NULL, (VOID**)&mUnicodeCollationProtocol); > + 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
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 (&gEfiUnicodeCollation2ProtocolGuid, NULL, > (VOID**)&mUnicodeCollationProtocol); > -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 (&gEfiUnicodeCollation2ProtocolGuid, > NULL, (VOID**)&mUnicodeCollationProtocol); > + 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
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 *Cc:* edk2-devel@lists.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" 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 AARC
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" 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
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
> -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 > 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 > >> 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 > >>>> 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, > >>>>> &MyAddress); // 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 > >> suc
Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND
> -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 > 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 > >> 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, > >>> &MyAddress); // 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 8000-84FF 5000 > >
Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND
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 > 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, > > &MyAddress); // 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 000F Available
[edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND
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, &MyAddress); // 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)
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 > wrote: > > On 30 March 2016 at 02:06, Vladimir Olovyannikov > > 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 > >>> 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 > >>>
Re: [edk2] Error while loading a symbol file (No Debug Directory)
> -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 > 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 while loading a symbol file (EfiFi
Re: [edk2] Error while loading a symbol file (No Debug Directory)
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 wou
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 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 UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoin
Re: [edk2] Error while loading a symbol file (No Debug Directory)
Hi Ard, Thank you for the hint. Here is the result of git bisection (first bad): Author: Cohen, Eugene 2016-03-07 07:16:35 Committer: Ard Biesheuvel 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 Reviewed-by: Ard Biesheuvel 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 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] Error while loading a symbol file (No Debug Directory)
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 Thank you, Vladimir ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)
Hi Eugene, This commit: Author: Cohen, Eugene 2016-03-07 07:16:38 Committer: Ard Biesheuvel 2016-03-17 01:15:14 Parent: 8a47a6cb9e77e4cc4bf42391f7f970173bcead27 (Omap35xxPkg: drop CpuExceptionHandlerLib library class resolution) Branch: remotes/origin/master Follows: Precedes: ArmPkg: update CpuDxe to use CpuExceptionHandlerLib Use the new ARM/AArch64 implementation of the base CpuExceptionHandlerLib library from CpuDxe to centralize exception handling. makes UEFI to hang on my v8 board. The latest log lines are: InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BB7F2300 add-symbol-file /home/volovyan/work/stingray/uefi-orig/Build/NS2Pkg/DEBUG_GCC49/AARCH64/In telFrameworkModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll 0xBBE29240 Loading driver at 0x000BBE29000 EntryPoint=0x000BBE29280 BdsDxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BB7F2558 InstallProtocolInterface: 665E3FF6-46CC-11D4-9A38-0090273FC14D BBE67780 Loading driver 49EA041E-6752-42CA-B0B1-7344FE2546B7 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BB7F1180 add-symbol-file /home/volovyan/work/stingray/uefi-orig/Build/NS2Pkg/DEBUG_GCC49/AARCH64/Ar mPkg/Drivers/TimerDxe/TimerDxe/DEBUG/ArmTimerDxe.dll 0xBBE23240 Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280 ArmTimerDxe.efi InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBE28B28 Loading driver E660EA85-058E-4B55-A54B-F02F83A24 The last one is "DisplayEngine", but it is not the culprit. JTAG debug shows that the CPU is looping in IrqSpx: EL2:0x85008A80 : BIrqSPx ; 0x85008A80 As soon as I revert the patch, everything returns to "normal" (no issues on boot, etc.). Please let me know if I am missing anything here. Thank you, Vladimir ___ 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)
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 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
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 > wrote: > > > > On 24 November 2015 at 00:38, Vladimir Olovyannikov > > 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 > >>> 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 > >>>> 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 > >>>>> > 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 st
Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi
> -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 > 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 > > 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 > >> > 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
> -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 > 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] Armv8 64bit: System error booting linux from the UEFI
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, November 17, 2015 11:03 PM > To: Mark Rutland > Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org > Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI > > On 17 November 2015 at 12:22, Mark Rutland > wrote: > [...] > >> Did that. Regardless of ArmInstructionSycnhronizationBarrier() and > subsequent enabling of the async abort > >> SError happens right in the ArmWriteVBar. > > > > Ok. > > > > Two theories: > > > > * When we take an exception, SError is masked. So perhaps we take > > another exception immediately after writing to VBAR_EL2, and that > > exception handler triggers the SError. I imagine that must be an > > asynchronous exception (i.e. one we can mask with DAIF). > > > > We should be able to see if that's the case if we change the > > ArmWriteVbar logic for EL2 to something like: > > > > mrs x1, daif > > msr daifset, #(0xb << 6) // D_IF masked After this instruction DAIF is 0x2C0 (bit A is not masked) > > mrs vbar_el2, x0 After msr vbar_el2, x0, isb+nop, and msr DAIFClr,#4 no SError - bit A was not masked. > > isb > > nop > > mrs daif, x1 > > nop > > > > If that is the case, I'd expect to take the SError immediately after > > the write back to daif. Mark, I tried this and made some other experiments with DAIF masked. It looks like the x0 address is not accepted by msr vbar_el2,x0. I tried to write vector in the very beginning, like this: mov x0, #0800 movk x0, #8500 lsl 16 msr vbar_el2, x0 isb nop and hit SError on the first msr DAIFClr,#4 I run UEFI from within the u-boot. Probably better would be just flash the UEFI and run UEFI only, and boot that way. Anyway when I setup vbar_el2 with u-boot exception vector address, at least no SError happens. If I setup u-boot vector with the UEFI vector address, it hits SError right away. (Boot into u-boot, load UEFI, then load u-boot and start execution with 0x85008800 vector address) 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. > > > > Ard, do we ever expect to take (non-fatal) synchronous exceptions? > > > > Never this early, since this version of the vector table is installed > very early, and deadloops on any exception that it takes. > > Only after CpuDxe is initialized, we can handle dispatch exceptions > and interrupts normally, but this is typically only used for the > timer interrupt. I could not find any invocations of > RegisterInterruptHandler() that installs a handler for synchronous > exceptions. > > > * As Ard originally suggested, the VBAR_EL2 address is close to some > > memory region we shouldn't speculatively fetch from, but for some > > reason do. > > > > Can you take a look at the new VBAR_EL2 value and your memory map, > and > > see if it's close to anything that shouldn't be fetched from? > > > > 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? -- 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
> -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 > 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
> -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
> -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
> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: Friday, November 13, 2015 5:18 PM > To: Vladimir Olovyannikov > Cc: Ard Biesheuvel; edk2-devel@lists.01.org > Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI > > On Fri, Nov 13, 2015 at 10:39:34PM +0000, Vladimir Olovyannikov wrote: > > > > > > > -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. > > This implies that either code very early in EDK2, or code prior to EDK2 is the > problem, given that when masked, SError will pend until it is unmasked > (whereupon it should be taken). > > 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. 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 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. > > > 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? > > It is possible that some initialisation is missing at an early stage in the > boot sequence, and that this contributes ot the SError. > > As an asynchronous exception, SError pends until it is unmasked, and should > trigger as soon as it is unmasked. The DAIFClr itself is vanishingly unlikely > to be the root cause of the SError, but rather makes it apparent. > > The earlier you are able to unmask SError, the closer you will be able to get > to the root cause. Are you able to capture it were it earlier in the boot > sequence (e.g. can you register a handler earlier, or capture the exception > with a hardware debugger)? > > Thanks, > Mark. 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
> -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
> -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 > 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+0x260/0x5b4 > > >
[edk2] Armv8 64bit: System error booting linux from the UEFI
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
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 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 > > 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(" 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_of_data = self.base_pe64 + > sel
Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi
-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 > 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("> 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
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 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
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