Re: [edk2] [PATCH v2 1/6] ShellPkg: TAB logic incorrectly chops out fs0: when typing fs0:

This v2 patch fixed VS2012 build failure. Thanks/Ray > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ruiyu Ni > Sent: Tuesday, August 9, 2016 1:44 PM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben > Subject:

[edk2] [PATCH v2 1/6] ShellPkg: TAB logic incorrectly chops out fs0: when typing fs0:

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey --- ShellPkg/Application/Shell/FileHandleWrappers.c | 312 ++-- 1 file changed, 185 insertions(+), 127 deletions(-) diff --git

Re: [edk2] Toolchain question

Hi, I assume that you are using linux because you're talking about ELF files. MinGW may be able to compile PE images in Linux but tbh there's no reason for that and the "freaking" translation is actually a pretty good implementation and works very well. As for the kind of toolchain to use:

Re: [edk2] [PATCH 0/2] BaseTools ARM/AARCH64: improve XIP support

Reviewed-by: Liming Gao > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, August 08, 2016 6:40 PM > To: leif.lindh...@linaro.org; Zhu, Yonghong ; > Gao, Liming ;

Re: [edk2] SATA AHCI issue

Hi, Shaveta No, we will create multiple PRDs if the transfer length is larger than 4M. each PRD could represent a 4M transfer request and the maximum number of PRD for each command is 65535. How do you access the HDD? At block level or file level? It happens at all HDDs or only one specific

Re: [edk2] [MdeModulePkg] SetVirtualAddressMap() crashed due to DxeReportStatusCodeLib assuming the state of the BootService Memory at runtime.

> On Aug 8, 2016, at 6:21 PM, Zeng, Star wrote: > > Andrew, > > Should MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib be used for your > case if there are really runtime status code reporting needed? > Star, If the Library instance does not fully support

[edk2] [PATCH v2 0/2] Share default value if some default value are not specified

Add a new implementation policy of get default value in HiiDatabaseDxe and SetupBrowserDxe. The new policy is only for the situation that a question has default value but doesn't have default value for all supported default type. In this case, we will choose the smallest default id from the

[edk2] [PATCH v2 2/2] MdeModulePkg/Browser: Share default if some default value are not specified

Add a new implementation policy of getting default value in SetupBrowser. The new policy is only for the situation that a question has default value but doesn't have default value for all supported default type. In this case, we will choose the smallest default id from the existing defaults, and

Re: [edk2] [MdeModulePkg] SetVirtualAddressMap() crashed due to DxeReportStatusCodeLib assuming the state of the BootService Memory at runtime.

Andrew, Should MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib be used for your case if there are really runtime status code reporting needed? Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew Fish Sent: Tuesday, August 9,

[edk2] Toolchain question

Sorry for the really dumb question, but I wanted to ask you. What compilers/tools you are using for building your UEFI/PI implementation on arm (both aarch32 (armv7) and aarch64)? And generally, is there a toolchain (available for downloading (not necessarily free) in binary form) for the arm

[edk2] [MdeModulePkg] SetVirtualAddressMap() crashed due to DxeReportStatusCodeLib assuming the state of the BootService Memory at runtime.

I was messing about with an ExitBootServices test that fills boot services memory with 0xAFAFAFAFAFAFAFAF (It was Vincent's idea to use my Initials but it has the handy property of being a non-cononical address and causes on GP fault on X64) and SetVirtualAddressMap() started crashing. It

Re: [edk2] [PATCH] [staging/HTTPS-TLS] Delete extra TlsCipherMappingTable entries

Reviewed-by: Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud SESM - OS / SW Architect Systems Management Development, Data Center Group Lenovo United States +1.919.908.5833 +1.512.659.1523 smahm...@lenovo.com   Lenovo.com /us  Twitter | Facebook | Instagram | Blogs | Forums

Re: [edk2] [PATCH 1/2] StdLib/LibC: avoid LTO code for compiler intrinsics

Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Michael Zimmermann > Sent: Monday, August 08, 2016 4:24 AM > To: Ard Biesheuvel > Cc: Carsey, Jaben

Re: [edk2] [PATCH 2/2] StdLib/LibC ARM AARCH64: do not redefine compiler intrinsics

Reviewed-by: Jaben Carsey > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, August 08, 2016 4:12 AM > To: edk2-devel@lists.01.org; edk2-li...@mc2research.org; Carsey, Jaben > > Cc:

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 15:42, Ard Biesheuvel wrote: > On 8 August 2016 at 15:22, Cohen, Eugene wrote: >> Guys, sorry to join so late, something about timezones... Let me try to >> provide some context and history. >> >>> > it does change the contract we

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 15:22, Cohen, Eugene wrote: > Guys, sorry to join so late, something about timezones... Let me try to > provide some context and history. > >> > it does change the contract we have with registered interrupt handlers >> >> Looks like it does not: >> From

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

Guys, sorry to join so late, something about timezones... Let me try to provide some context and history. > > it does change the contract we have with registered interrupt handlers > > Looks like it does not: > From edk2\EmbeddedPkg\Include\Protocol\HardwareInterrupt.h: > > " Abstraction for

Re: [edk2] SATA AHCI issue

Hi, As per the spec and the code in "AhciMode.c" // According to AHCI 1.3 spec, a PRDT entry can point to a maximum 4MB data block. Does it mean, only one PRD entry is getting transferred successfully? But as the data I am writing onto SATA HDD is 30MB big, what about the rest of PRDs? What

[edk2] SATA AHCI issue

Hi, I am facing one Timeout issue while writing big file over my SATA HDD. It in the code of "AhciDmaTransfer " from file AhciMode.c // // Wait for command compelte // FisBaseAddr = (UINTN)AhciRegisters->AhciRFis + Port * sizeof (EFI_AHCI_RECEIVED_FIS); Offset = FisBaseAddr +

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 13:08, Ard Biesheuvel wrote: > On 8 August 2016 at 13:06, Alexei Fedorov wrote: >> Timer's pending interrupt is cleared HARDWARE_INTERRUPT_HANDLER >> TimerInterruptHandler() in when timer is re-programmed for the next

Re: [edk2] ARM PrePI Memory setup recommendations

While that can be a problem in general it's definitely not a problem in my case because the "MinimalMemorySizeNeeded" check is done after a ResourceHob is found which contains the PHIT Hob.(this is the part which broke). And since at that point I've already registered resourcehob's for all

Re: [edk2] [PATCH 1/2] StdLib/LibC: avoid LTO code for compiler intrinsics

Reviewed-by: Michael Zimmermann On Mon, Aug 8, 2016 at 1:12 PM, Ard Biesheuvel wrote: > The softfloat routines and some other routines supplied by LibC > will satisfy references to compiler intrinsics that are emitted > by the compiler

[edk2] [PATCH 2/2] StdLib/LibC ARM AARCH64: do not redefine compiler intrinsics

The memset() function is a compiler intrinsics on AARCH64 and ARM, and so is memmove() on ARM. Usually, redefining them as LibC currently does is not a problem since only one version will be selected at link time from the various static libraries that provide implementations. However, under LTO,

[edk2] [PATCH 1/2] StdLib/LibC: avoid LTO code for compiler intrinsics

The softfloat routines and some other routines supplied by LibC will satisfy references to compiler intrinsics that are emitted by the compiler backend, which under LTO means that the link-time code generation may emit references to symbols that have been optimized away already. Work around this

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 13:06, Alexei Fedorov wrote: > Timer's pending interrupt is cleared HARDWARE_INTERRUPT_HANDLER > TimerInterruptHandler() in when timer is re-programmed for the next shot. Yes, that is the timer side. > Does it mean that TimerDxe driver is part

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

Timer's pending interrupt is cleared HARDWARE_INTERRUPT_HANDLER TimerInterruptHandler() in when timer is re-programmed for the next shot. Does it mean that TimerDxe driver is part EFI_HARDWARE_INTERRUPT_PROTOCOL? -Original Message- From: Ard Biesheuvel

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 12:56, Alexei Fedorov wrote: > I quoted: > > "The HARDWARE_INTERRUPT_HANDLER is responsible for clearing interrupt sources > from individual devices". > Are reading this as " spec clearly states that it is the GIC driver that > should be doing it"? >

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

I quoted: "The HARDWARE_INTERRUPT_HANDLER is responsible for clearing interrupt sources from individual devices". Are reading this as " spec clearly states that it is the GIC driver that should be doing it"? TimerInterruptHandler() is HARDWARE_INTERRUPT_HANDLER and it clears its interrupt by

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 12:48, Alexei Fedorov wrote: > Please provide the link to the spec which "clearly states that it is the GIC > driver that should be doing it." > it is not in the spec, but in the comment that you quoted yourself: >>> Looks like it does not: >>> From

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

Please provide the link to the spec which "clearly states that it is the GIC driver that should be doing it." -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 08 August 2016 11:45 To: Alexei Fedorov Cc: Evan Lloyd; Cohen, Eugene; edk2-devel@lists.01.org;

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 12:40, Alexei Fedorov wrote: > The interrupt is cleared in TimerInterruptHandler() > (ArmPkg\Drivers\TimerDxe\TimerDxe.c) which is HARDWARE_INTERRUPT_HANDLER > parameter passed to gInterrupt->RegisterInterruptSource(). Indeed. So now, the

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

The interrupt is cleared in TimerInterruptHandler() (ArmPkg\Drivers\TimerDxe\TimerDxe.c) which is HARDWARE_INTERRUPT_HANDLER parameter passed to gInterrupt->RegisterInterruptSource(). Spurious interrupts which don't have registered interrupt handlers are cleared in

[edk2] [PATCH 2/2] BaseTools ARM: impose strict alignment only for XIP modules

Given that we only support ARMv7 and up in Tianocore (due to the fact that the PI spec mandates that the PEI services table pointer be stored in the TPIDRURW register, which is not available on earlier CPUs), we can assume that any code executing with the MMU on may perform unaligned accesses

[edk2] [PATCH 0/2] BaseTools ARM/AARCH64: improve XIP support

Patch #1 adds the missing XIP flags to CLANG35, to prevent code to be generated that performs unaligned accesses before the MMU is on. Patch #2 extends the XIP CC flags support to ARM. Ard Biesheuvel (2): BaseTools CLANG35: add missing XIP flags for AARCH64 BaseTools ARM: impose strict

[edk2] [PATCH 1/2] BaseTools CLANG35: add missing XIP flags for AARCH64

When building for AARCH64, code that may execute with the MMU off should not perform unaligned accesses, which is why we set -mstrict-align for BASE, SEC, PEI_CORE and PEIM modules when building with GCCx. However, this setting is missing from CLANG35 so set it there as well. Contributed-under:

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

On 8 August 2016 at 12:25, Alexei Fedorov wrote: > >> it does change the contract we have with registered interrupt handlers > > Looks like it does not: > From edk2\EmbeddedPkg\Include\Protocol\HardwareInterrupt.h: > > " Abstraction for hardware based interrupt routine > >

[edk2] [PATCH 4/6] MdePkg: Enhance PathRemoveLastItem() to support "FS0:File.txt"

The original implementation only looks for very last backslash and removes the string after that. But when the path is like "FS0:File.txt" which doesn't contain backslash, the function cannot work well. The patch enhances the code to look for very last backslash or colon to support the path which

[edk2] [PATCH 5/6] ShellPkg/ls: Fix to support "ls fs0:File.txt"

“ls fs0:\File.txt" can list the file correctly but when the backslash is removed from colon, the file cannot be listed. The patch fixes this issue. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey ---

[edk2] [PATCH 6/6] ShellPkg/ls: Display the correct directory path

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey --- ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c

[edk2] [PATCH 3/6] ShellPkg: Fix FindFiles() to handle "fsx:EFI\BOOT" path

When the FilePattern is similar to "fsx:EFI\BOOT", FindFiles() cannot handle it correctly because it always assumes there is "\\" after "fsx:". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey ---

[edk2] [PATCH 0/6] Fix shell TAB completion issue and bugs in LS command

The patches fix shell TAB completion issue and several issues in LS command. Ruiyu Ni (6): ShellPkg: TAB logic incorrectly chops out fs0: when typing fs0: ShellPkg: TAB logic incorrectly shows files in CWD when typing \ ShellPkg: Fix FindFiles() to handle "fsx:EFI\BOOT" path MdePkg:

[edk2] [PATCH 2/6] ShellPkg: TAB logic incorrectly shows files in CWD when typing \

It should shows files in root directory of current map. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey --- ShellPkg/Application/Shell/FileHandleWrappers.c | 15 +-- 1 file changed, 13

[edk2] [PATCH 1/6] ShellPkg: TAB logic incorrectly chops out fs0: when typing fs0:

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jaben Carsey --- ShellPkg/Application/Shell/FileHandleWrappers.c | 312 ++-- 1 file changed, 185 insertions(+), 127 deletions(-) diff --git

Re: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

> it does change the contract we have with registered interrupt handlers Looks like it does not: >From edk2\EmbeddedPkg\Include\Protocol\HardwareInterrupt.h: " Abstraction for hardware based interrupt routine ...The driver implementing this protocol is responsible for clearing the pending

Re: [edk2] ARM PrePI Memory setup recommendations

On 8 August 2016 at 11:18, Michael Zimmermann wrote: > I'm using the defaults from the (now deleted) 2ndstage sample dsc: > gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0 > gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0 >

Re: [edk2] ARM PrePI Memory setup recommendations

I'm using the defaults from the (now deleted) 2ndstage sample dsc: gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0

Re: [edk2] [patch] BaseTools/UPT: Fix a install issue

Reviewed-by: Yonghong Zhu I will push this patch if no more comment from community. Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Monday, August 08, 2016 11:28 AM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong

Re: [edk2] ARM PrePI Memory setup recommendations

On 6 August 2016 at 13:05, Michael Zimmermann wrote: > Hi, > > I have some problems with my current setup and would like to ask you for the > best way to configure the following setup: > - I'm using PrePi, I don't need relocations because the loading address is >