Re: [edk2] [PATCH v2] ArmPlatformPkg: convert VExpress ResetSystemLib to ResetSystemLib

[Ryan Harkin]

On 4 July 2017 at 18:27, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 4 July 2017 at 18:11, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> Since we're in the process of migrating all of the VExpress platforms
>> to MdeModulePkg ResetSystemRuntimeDxe, convert VExpress ResetSystemLib
>> from EfiResetSystemLib interface to the ResetSystemLib one.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

After popping commit e4129b0e5897d76885170bec9da996b266f185f9 off the
top of edk2, and adding this, I also applied patch "Platforms/ARM:
move ARM platforms to generic ResetSystemRuntimeDxe" to
OpenPlatformPkg and tested on TC2, FVP Foundation and AEMv8 models and
Juno R0/1/2.

I checked that reset and shutdown both still work as expected. Reset
was triggered from BDS, grub and EFI Shell. Shutdown (reset -s) was
trigger from EFI Shell.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

>
>> ---
>>  .../Library/ResetSystemLib/ResetSystemLib.c| 117 
>> -
>>  .../Library/ResetSystemLib/ResetSystemLib.inf  |   6 +-
>>  2 files changed, 73 insertions(+), 50 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.c 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.c
>> index bafb6f8093..d2bc4a88fa 100644
>> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.c
>> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.c
>> @@ -5,6 +5,7 @@
>>
>>Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>>Copyright (c) 2013, ARM Ltd. All rights reserved.
>> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
>>
>>This program and the accompanying materials
>>are licensed and made available under the terms and conditions of the BSD 
>> License
>> @@ -16,73 +17,95 @@
>>
>>  **/
>>
>> -#include 
>> +#include 
>>
>> -#include 
>> -#include 
>> -#include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  #include 
>>
>>  /**
>> -  Resets the entire platform.
>> +  This function causes a system-wide reset (cold reset), in which
>> +  all circuitry within the system returns to its initial state. This type of
>> +  reset is asynchronous to system operation and operates without regard to
>> +  cycle boundaries.
>>
>> -  @param  ResetType The type of reset to perform.
>> -  @param  ResetStatus   The status code for the reset.
>> -  @param  DataSize  The size, in bytes, of WatchdogData.
>> -  @param  ResetData For a ResetType of EfiResetCold, 
>> EfiResetWarm, or
>> -EfiResetShutdown the data buffer starts 
>> with a Null-terminated
>> -Unicode string, optionally followed by 
>> additional binary data.
>> +  If this function returns, it means that the system does not support cold
>> +  reset.
>> +**/
>> +VOID
>> +EFIAPI
>> +ResetCold (
>> +  VOID
>> +  )
>> +{
>> +  ArmPlatformSysConfigSet (SYS_CFG_REBOOT, 0);
>> +}
>> +
>> +/**
>> +  This function causes a system-wide initialization (warm reset), in which 
>> all
>> +  processors are set to their initial state. Pending cycles are not 
>> corrupted.
>>
>> +  If this function returns, it means that the system does not support warm
>> +  reset.
>>  **/
>> -EFI_STATUS
>> +VOID
>>  EFIAPI
>> -LibResetSystem (
>> -  IN EFI_RESET_TYPE   ResetType,
>> -  IN EFI_STATUS   ResetStatus,
>> -  IN UINTNDataSize,
>> -  IN CHAR16   *ResetData OPTIONAL
>> +ResetWarm (
>> +  VOID
>>)
>>  {
>> -  switch (ResetType) {
>> -  case EfiResetPlatformSpecific:
>> -// Map the platform specific reset as reboot
>> -  case EfiResetWarm:
>> -// Map a warm reset into a cold reset
>> -  case EfiResetCold:
>> -// Send the REBOOT function to the platform microcontroller
>> -ArmPlatformSysConfigSet (SYS_CFG_REBOOT, 0);
>> -
>> -// We should never be here
>> -while(1);
>> -  case EfiResetShutdown:
>> -// Send the SHUTDOWN function to the platform microcontroller
>> -ArmPlatformSysConfigSet (SYS_CFG_SHUTDOWN, 0);
>> -
>> -// We should never be here
>> - 

Re: [edk2] [PATCH] ArmPlatformPkg: eliminate Juno gcc build warning

[Ryan Harkin]

On 20 June 2017 at 12:28, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> (+ Laszlo)
>
> On 20 June 2017 at 13:00, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> When building without LTO, gcc incorrectly resolves the hazards for
>> 'PciRegBase’ when inlining, leading to "may be used uninitialized"
>> warnings (and hence build failure with -Werror).
>> Eliminate this warning by explicitly initializing the variable to 0.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org>
>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>

>
>> ---
>>
>> For those who have heard me mentioning this before but arguing against
>> upstreaming this patch: I only just tweaked that this warning doesn't
>> go away with more recent toolchains, but simply when switching to GCC5
>> build profile, and hence LTO. Build failure still reproducible with
>> gcc 6.3.1 and GCC49.
>>
>
> /me annoyed
>
> We keep hitting this with GCC, and I profoundly dislike having to add
> redundant initialization sequences. Is there any other solution
> possible, e.g., disable this warning for certain builds?
>
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> index da93eb5829..18491c7378 100644
>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> @@ -343,6 +343,7 @@ ArmJunoSetNicMacAddress ()
>>  return Status;
>>}
>>
>> +  PciRegBase = 0;
>>Status = InitPciDev (PciIo, , );
>>if (EFI_ERROR (Status)) {
>>  return Status;
>> --
>> 2.11.0
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/3] ArmPlatformPkg: FVP spring cleaning -- EDK2 edition

[Ryan Harkin]

On 10 April 2017 at 17:33, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Mon, Apr 10, 2017 at 05:21:49PM +0100, Ard Biesheuvel wrote:
>> This v3 of the ArmPlatformPkg now only contains FVP changes. TC2 and Juno
>> will receive a similar treatment once we have sorted out how the loading of
>> the DTB image from the NOR flash will be implemented.
>>
>> So what remains here is two somewhat unrelated cleanup patches, and the
>> meat in #3 which removes the functionality that interoperates with the
>> FdtPlatformDxe that we are trying to get rid of.
>>
>
> For the series:
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>

This deletes some seriously nasty code!

Tested on FVP Foundation & AEMv8, TC2 and Juno R0/1/2.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


>> Ard Biesheuvel (3):
>>   ArmPlatformPkg/ArmVExpressDxe: remove ARM support
>>   ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe
>>   ArmPlatformPkg/ArmVExpressDxe: remove FDT handling from ArmFvpDxe
>>
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c | 
>> 113 
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c |  
>> 84 
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c| 
>> 137 +---
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf  |  
>> 42 --
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c |  
>> 43 +-
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf   |   
>> 3 -
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c|  
>> 48 ---
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h  |  
>> 99 --
>>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec|  
>> 28 
>>  9 files changed, 6 insertions(+), 591 deletions(-)
>>  delete mode 100644 
>> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h
>>
>> --
>> 2.9.3
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics

[Ryan Harkin]

On 6 April 2017 at 14:15, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> As reported by Jeremy, the recently introduced accelerated memcpy/memset
> routines are causing problems when used on framebuffer memory. While
> framebuffers are arguably right on the blurry line between MMIO (with
> side effects that are sensitive to ordering) and memory, mapping VRAM
> as device memory is unnecessary to begin with, and so we can improve
> our situation by using memory semantics for the VRAM mappings. (Whether
> we end up reverting to the unaccelerated memcpy/memset routines is a
> separate matter)
>
> So fix both the FVP case, which has a separate VRAM region, and TC2, which
> allocates VRAM from normal memory and changes the mapping attributes.
>
> Note to Ryan: this fixes FVP Base model for me, but not the Foundation model
> (whose PL111 support I never saw working to begin with, so I am not sure what
> is going on there)
>

With the fix to remove the duplicate VRAM_MOTHERBOARD_BASE, this
series is tested on Juno R0/1/2 to make sure they didn't break for
inexplicable reasons, on TC2 and FVP Base AEMv8 models.

FVP Foundation has never been verified with CLCD and it doesn't work
with or without this change, so I'm happy with that.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


> Ard Biesheuvel (5):
>   ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory
>   ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call
>   ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM
>   ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for
> VRAM
>
>  ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h
>| 10 ++
>  ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c   
>|  8 +++-
>  ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
>| 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
>|  3 ++-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>   | 14 +-
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
>  |  3 ++-
>  6 files changed, 27 insertions(+), 25 deletions(-)
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 6 April 2017 at 12:32, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 6 April 2017 at 12:14, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> On 5 April 2017 at 21:38, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>>> Replace the uncached memory mapping of the framebuffer with a write-
>>> combining one. This improves performance, and avoids issues with
>>> unaligned accesses and DC ZVA instructions performed by the accelerated
>>> memcpy/memset routines.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>
>> Well, ... PL111 isn't usually enabled for me. And if I enable it,
>> neither Foundation nor AEMv8 models boot with or without this patch.
>>
>> So it's no worse than before
>>
>
> Not even foundation model? That is strange ...
>

The reason we created a config without PL111 was because Foundation
didn't originally have a PL111. And I wanted a single binary to run on
Foundation and AEMv8. But ARM added it to Foundation about a year ago
and I've never tried it.

I'm happy for you to submit the patch if it works for you.


>>
>>> ---
>>>  
>>> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>>  | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>>  
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> index 2000c9bdf436..d18d6b3e1665 100644
>>> --- 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> +++ 
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>>> @@ -192,7 +192,7 @@ LcdPlatformGetVram (
>>>  ASSERT_EFI_ERROR(Status);
>>>
>>>  // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
>>> cachable.
>>> -Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_UC);
>>> +Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_WC);
>>>  ASSERT_EFI_ERROR(Status);
>>>  if (EFI_ERROR(Status)) {
>>>gBS->FreePool(VramBaseAddress);
>>> --
>>> 2.7.4
>>>
>>> ___
>>> 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 1/2] ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 6 April 2017 at 11:40, Ard Biesheuvel  wrote:
> On 6 April 2017 at 10:37, Leif Lindholm  wrote:
>> On Wed, Apr 05, 2017 at 09:38:32PM +0100, Ard Biesheuvel wrote:
>>> Replace the uncached memory mapping of the framebuffer with a write-
>>> combining one. This improves performance, and avoids issues with
>>> unaligned accesses and DC ZVA instructions performed by the accelerated
>>> memcpy/memset routines.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>
>> If you can get a nod each from Ryan and Evan, for the series:
>> Reviewed-by: Leif Lindholm 
>>
>>> ---
>>>  
>>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>>  | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>>  
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> index a57846715ed7..d6d47545c824 100644
>>> --- 
>>> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> +++ 
>>> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>>> @@ -143,7 +143,7 @@ LcdPlatformGetVram (
>>>ASSERT_EFI_ERROR(Status);
>>>
>>>// Mark the VRAM as un-cacheable. The VRAM is inside the DRAM, which is 
>>> cacheable.
>>> -  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_UC);
>>> +  Status = Cpu->SetMemoryAttributes (Cpu, *VramBaseAddress, *VramSize, 
>>> EFI_MEMORY_WC);
>>>ASSERT_EFI_ERROR(Status);
>>>if (EFI_ERROR(Status)) {
>>>  gBS->FreePool (VramBaseAddress);
>
> Actually, it would be more appropriate for this code to use DXE services, 
> i.e.,
>
> gDS->SetMemorySpaceAttributes (xxx)
>
> which internally calls Cpu->SetMemoryAttributes(), but also checks the
> validity of the request against the capabilities of the region

Ach! I've just tested this patch :-)

Anyway, it works fine on TC2.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM

[Ryan Harkin]

On 5 April 2017 at 21:38, Ard Biesheuvel  wrote:
> Replace the uncached memory mapping of the framebuffer with a write-
> combining one. This improves performance, and avoids issues with
> unaligned accesses and DC ZVA instructions performed by the accelerated
> memcpy/memset routines.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Well, ... PL111 isn't usually enabled for me. And if I enable it,
neither Foundation nor AEMv8 models boot with or without this patch.

So it's no worse than before


> ---
>  
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
>  
> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> index 2000c9bdf436..d18d6b3e1665 100644
> --- 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> +++ 
> b/ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
> @@ -192,7 +192,7 @@ LcdPlatformGetVram (
>  ASSERT_EFI_ERROR(Status);
>
>  // Mark the VRAM as un-cachable. The VRAM is inside the DRAM, which is 
> cachable.
> -Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_UC);
> +Status = Cpu->SetMemoryAttributes(Cpu, *VramBaseAddress, *VramSize, 
> EFI_MEMORY_WC);
>  ASSERT_EFI_ERROR(Status);
>  if (EFI_ERROR(Status)) {
>gBS->FreePool(VramBaseAddress);
> --
> 2.7.4
>
> ___
> 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 v4 0/4] Juno cleanup -- OpenPlatformPkg edition

[Ryan Harkin]

On 5 April 2017 at 15:00, Ard Biesheuvel  wrote:
> Counterpart to the EDK2 series switching Juno to the generic non-discoverable
> device driver and generic PCI host bridge driver.
>
> v4: fixed a number of non-functional issues -- include ordering, incorrect
> BASE_NAME, commit log clarifications
> add RBs and TBs

I don't see my TBs in there, is gmail messing me about or are they not there?

>
> Ard Biesheuvel (4):
>   Platforms/Juno: add non-discoverable device driver and library
>   Platforms/Juno: add PciHostBridgeLib implementation
>   Platforms/Juno: switch to generic PCI host bridge driver
>   Platforms/Juno: remove BdsLib dependency
>
>  Platforms/ARM/Juno/ArmJuno.dsc   |  
> 24 ++-
>  Platforms/ARM/Juno/ArmJuno.fdf   |  
> 11 +-
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c   | 
> 199 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |  
> 77 
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c| 
> 182 ++
>  Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h| 
> 107 +++
>  6 files changed, 585 insertions(+), 15 deletions(-)
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.c
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.c
>  create mode 100644 
> Platforms/ARM/Juno/Library/JunoPciHostBridgeLib/XPressRich3.h
>
> --
> 2.9.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/6] Juno cleanup -- EDK2 edition

[Ryan Harkin]

On 4 April 2017 at 16:47, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 4 April 2017 at 13:30, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> This is tagged as v3 because these patches have been isolated from a
>> ArmPlatformPkg cleanup series that is mostly about ACPI vs DT.
>>
>> This series is specific to Juno; it replaces the cargo culted and ancient
>> PCI 'emulation' code with calls into the new non-discoverable device API,
>> and removes the Juno specific PCI host bridge driver in favor of the generic
>> one.
>>
>> Ard Biesheuvel (6):
>>   ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
>>   ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency
>>   ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device
>> support
>>   ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0
>>   ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver
>>   ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation
>>
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c   
>>  | 110 ++-
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
>>  |   4 +-
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h   
>>  |   5 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c 
>>  | 596 
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h 
>>  | 284 
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c  
>>  | 299 
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c  
>>  | 199 --
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h  
>>  | 324 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf 
>>  |  76 --
>>  
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>>  | 642 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c  
>>  | 748 
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>>  | 170 -
>>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h
>>  | 111 ---
>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf  
>>  |   1 -
>>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c   
>>  |  58 +-
>>  15 files changed, 104 insertions(+), 3523 deletions(-)
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>>  delete mode 100644 
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h
>>
>> --
>> 2.9.3
>>
>
> I tested the whole series in conjunction with the OpenPlatformPkg
> series and it works fine on Juno R0/1/2, TC2 and FVP Foundation and
> AEMv8 models.
>
> I tested PCIe ethernet and SATA HDD on R1 and R2, and a USB memory
> stick on R0/1/2.

Missed the actual Tested-by tag...

Tested-by: Ryan Harkin <ryan.har...@linaro.org>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/6] Juno cleanup -- EDK2 edition

[Ryan Harkin]

On 4 April 2017 at 13:30, Ard Biesheuvel  wrote:
> This is tagged as v3 because these patches have been isolated from a
> ArmPlatformPkg cleanup series that is mostly about ACPI vs DT.
>
> This series is specific to Juno; it replaces the cargo culted and ancient
> PCI 'emulation' code with calls into the new non-discoverable device API,
> and removes the Juno specific PCI host bridge driver in favor of the generic
> one.
>
> Ard Biesheuvel (6):
>   ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
>   ArmPlatformPkg/ArmJunoDxe: remove BdsLib dependency
>   ArmPlatformPkg/ArmJunoDxe: use the generic non-discoverable device
> support
>   ArmPlatformPkg/ArmJunoDxe: don't register OnEndOfDxe event on rev R0
>   ArmPlatformPkg/ArmJunoPkg: remove PCI host bridge driver
>   ArmPlatformPkg/ArmJunoDxe: simplify ACPI table installation
>
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> | 110 ++-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf  
> |   4 +-
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
> |   5 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c  
> | 596 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h  
> | 284 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c   
> | 299 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c   
> | 199 --
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h   
> | 324 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf  
> |  76 --
>  
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  | 642 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c   
> | 748 
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
> | 170 -
>  ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h 
> | 111 ---
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf   
> |   1 -
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c
> |  58 +-
>  15 files changed, 104 insertions(+), 3523 deletions(-)
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.h
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciRootBridgeIo.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridge.h
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeResourceAllocation.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>  delete mode 100644 
> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.h
>
> --
> 2.9.3
>

I tested the whole series in conjunction with the OpenPlatformPkg
series and it works fine on Juno R0/1/2, TC2 and FVP Foundation and
AEMv8 models.

I tested PCIe ethernet and SATA HDD on R1 and R2, and a USB memory
stick on R0/1/2.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/UncachedMemoryAllocationLib: set XP bit via CPU arch protocol

[Ryan Harkin]

Hi Ard,

Thanks for the quick turnaround as always.

On 14 March 2017 at 20:20, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Tue, Mar 14, 2017 at 07:58:15PM +, Ard Biesheuvel wrote:
>> Commit e7b24ec9785d ("ArmPkg/UncachedMemoryAllocationLib: map uncached
>> allocations non-executable") adds code that manipulates the GCD memory
>> space attributes of a newly allocated uncached region without checking
>> whether this region expose these attributes in its capabilities mask.
>>
>> Given that the intent is to remove executable permissions from the region,
>> this is a fairly pointless exercise to begin with, regardless of whether
>> it is correct or not. The reason is that RO/XP memory attributes in the
>> GCD memory space map or the UEFI memory map are completely disconnected
>> from the actual mapping permissions used in the page tables.
>>
>> So instead, invoke the CPU arch protocol directly, and add the non-exec
>> attributes in the page tables directly.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

FVPs and TC2 worked before this change, Juno was hanging on boot as
per an earlier email thread.

I tested this change on FVP Foundation & AEMv8, TC2 and Juno R0/1/2
and they all work fine after it's applied to the current HEAD of EDK2
(commit 8057622).


>> ---
>>  ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c   
>> | 36 
>>  ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf 
>> |  8 -
>>  2 files changed, 36 insertions(+), 8 deletions(-)
>>
>> diff --git 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> index b4fbfbcb362b..2530175bab7a 100644
>> --- 
>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> +++ 
>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>> @@ -27,6 +27,10 @@
>>  #include 
>>  #include 
>>
>> +#include 
>> +
>> +STATIC EFI_CPU_ARCH_PROTOCOL*mCpu;
>> +
>>  VOID *
>>  UncachedInternalAllocatePages (
>>IN EFI_MEMORY_TYPE  MemoryType,
>> @@ -150,15 +154,19 @@ AllocatePagesFromList (
>>
>>Status = gDS->GetMemorySpaceDescriptor (Memory, );
>>if (EFI_ERROR (Status)) {
>> -gBS->FreePages (Memory, Pages);
>> -return Status;
>> +goto FreePages;
>>}
>>
>>Status = gDS->SetMemorySpaceAttributes (Memory, EFI_PAGES_TO_SIZE (Pages),
>> -  EFI_MEMORY_WC | EFI_MEMORY_XP);
>> +  EFI_MEMORY_WC);
>>if (EFI_ERROR (Status)) {
>> -gBS->FreePages (Memory, Pages);
>> -return Status;
>> +goto FreePages;
>> +  }
>> +
>> +  Status = mCpu->SetMemoryAttributes (mCpu, Memory, EFI_PAGES_TO_SIZE 
>> (Pages),
>> +   EFI_MEMORY_XP);
>
> So, all other changes here are straightforward, but this one relies on
> the fact that we don't care about EFI_MEMORY_RO being cleared when we
> flip to _XP. As discussed on irc, if you can add a small note on that
> (and wait for Ryan's Tested-by):
>
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>
>> +  if (EFI_ERROR (Status)) {
>> +goto FreePages;
>>}
>>
>>InvalidateDataCacheRange ((VOID *)(UINTN)Memory, EFI_PAGES_TO_SIZE 
>> (Pages));
>> @@ -166,8 +174,8 @@ AllocatePagesFromList (
>>NewNode = AllocatePool (sizeof (FREE_PAGE_NODE));
>>if (NewNode == NULL) {
>>  ASSERT (FALSE);
>> -gBS->FreePages (Memory, Pages);
>> -return EFI_OUT_OF_RESOURCES;
>> +Status = EFI_OUT_OF_RESOURCES;
>> +goto FreePages;
>>}
>>
>>NewNode->Base   = Memory;
>> @@ -181,6 +189,10 @@ AllocatePagesFromList (
>>
>>*Allocation = NewNode->Allocation;
>>return EFI_SUCCESS;
>> +
>> +FreePages:
>> +  gBS->FreePages (Memory, Pages);
>> +  return Status;
>>  }
>>
>>  /**
>> @@ -238,6 +250,16 @@ FreePagesFromList (
>>   */
>>  EFI_STATUS
>>  EFIAPI
>> +UncachedMemoryAllocationLibConstructor (
>> +  IN EFI_HANDLEImageHandle,
>> +  IN EFI_SYSTEM_TABLE  *SystemTable
>> +  )
>> +{
>> +  return gBS->LocateProtocol (, NULL, (VOID 
>> **));
>> +}
>> +
>> +EFI_ST

Re: [edk2] [PATCH v2] EmbeddedPkg/PrePiLib: allocate code pages for DxeCore

[Ryan Harkin]

Hi Ard,

On 14 March 2017 at 08:01, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> The recently introduced memory protection features inadvertently broke
> the boot on all PrePi platforms, because the changes to explicitly use
> EfiBootServicesCode for loading the DxeCore PE/COFF image need to be
> applied in a different way for PrePi. So add a simple helper function
> that sets the type of an allocation to EfiBootServicesCode, and invoke
> it to allocate the space for DxeCore.
>

I'm not quite sure which issue this patch is supposed to fix.

EDK2 is broken on Juno for me right now. I see this output at boot:

EhcDriverBindingStart: failed to enable 64-bit DMA on 64-bit capable
controller @ FD41B898 (Unsupported)

ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT [ArmJunoDxe]
/linaro/platforms/uefi/edk2/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c(361):
!EFI_ERROR (Status)

Bisecting tells me this patch is to blame:

$ git bisect bad
e7b24ec9785d206f1d3faf8f646e63a1b540d6a5 is the first bad commit
commit e7b24ec9785d206f1d3faf8f646e63a1b540d6a5
Author: Ard Biesheuvel <ard.biesheu...@linaro.org>
Date:   Tue Feb 28 12:13:12 2017 +

ArmPkg/UncachedMemoryAllocationLib: map uncached allocations non-executable

The primary use case for UncachedMemoryAllocationLib is non-coherent DMA,
which implies that such regions are not used to fetch instructions from.

So let's map them as non-executable, to avoid creating a security hole
when the rest of the platform may be enforcing strict memory permissions
on ordinary allocations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>

:04 04 6310e6a81c3b1e9eda315a9f4cad2bc918f74b25
12b11759ebd83f91a127c1f016b8e41cbfd097d4 MArmPkg

Applying the patch from $subject and "[PATCH] Platforms/ARM: enable
memory protection features" does not resolve the issue.

AFAICT, only reverting e7b24ec9785d206f1d3faf8f646e63a1b540d6a5 makes
things work again. I suspect there are further Juno specific changes
that could be applied instead of reverting the problematic patch.

So, Juno and TC2 boot fine if my edk2 tree looks like this:

50e5735  2017-03-14  Revert "ArmPkg/UncachedMemoryAllocationLib: map
uncached allocations non-executable"   [Ryan Harkin]
7e9c1b0  2017-03-14  EmbeddedPkg/PrePiLib: allocate code pages for
DxeCore  [Ard Biesheuvel]
c03f5b2  2017-03-10  BaseTools/UPT: Fix an issue in subst command
 [Hess Chen]

And OpenPlatformPkg looks like this:

d6a743d  2017-03-07  Platforms/ARM: enable memory protection features
 [Ard Biesheuvel]
408d600  2016-01-29  HACK: Platforms/ARM: TC2: set
gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride TRUE  [Ryan
Harkin]
17dbc2a  2017-02-24  Treewide: remove references to
VirtualUncachedPages libraries and PCDs [Ard Biesheuvel]

If I go on to drop $subject patch, Juno and TC2 no longer boot, so I
presume that it's supposed to fix the issue where OpenPlatformPkg has
enabled the memory protection features. And that the upstream Juno
problems are different.

Cheers,
Ryan.


> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Tested-by: Michael Zimmermann <sigmaepsilo...@gmail.com>
> ---
> v2: add missing MemoryAllocationLib.h include
> add Michael's T/b
>
>  EmbeddedPkg/Library/PrePiLib/PrePi.h|  1 +
>  EmbeddedPkg/Library/PrePiLib/PrePiLib.c | 34 +++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/EmbeddedPkg/Library/PrePiLib/PrePi.h 
> b/EmbeddedPkg/Library/PrePiLib/PrePi.h
> index 607561cd2496..84eca23ec8a6 100644
> --- a/EmbeddedPkg/Library/PrePiLib/PrePi.h
> +++ b/EmbeddedPkg/Library/PrePiLib/PrePi.h
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> diff --git a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c 
> b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
> index 9a1ef344df6e..bba8e7384edc 100644
> --- a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
> +++ b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c
> @@ -28,6 +28,38 @@ SecWinNtPeiLoadFile (
>IN  EFI_PHYSICAL_ADDRESS*EntryPoint
>);
>
> +STATIC
> +VOID*
> +EFIAPI
> +AllocateCodePages (
> +  IN  UINTN Pages
> +  )
> +{
> +  VOID*Alloc;
> +  EFI_PEI_HOB_POINTERSHob;
> +
> +  Alloc = AllocatePages (Pages);
> +  if (Alloc == NULL) {
> +return NULL;
> +  }
> +
> +  // find the HOB we just created, and change the type to EfiBootServicesCode
> +  Hob.Raw = GetFirstHob (EFI_HOB_TYPE_MEMORY_ALLOCATION);
> +  while (Hob.Raw != NULL) {
> +if (Hob.MemoryAllocation-&

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

[Ryan Harkin]

On 17 February 2017 at 12:06, Evan Lloyd <evan.ll...@arm.com> wrote:
> Hi Ryan.
>
>
>
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: 16 February 2017 20:42
> To: Evan Lloyd
> Cc: ard.biesheu...@linaro.org; Leif Lindholm; edk2-de...@ml01.01.org
> Subject: RE: [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType
> functions
>
>
>
>
> On 16 Feb 2017 20:27, "Evan Lloyd" <evan.ll...@arm.com> wrote:
>>
>> Hi Leif.
>> We accept all the comments except that about ternaries.
>> Response inline.
>>
> …
>
>> >> +
>> >> +  *TriggerType = (MmioBitFieldRead32 (RegAddress, BitNumber,
>> >BitNumber) == 0)
>> >> + ?  EFI_HARDWARE_INTERRUPT2_TRIGGER_LEVEL_HIGH
>> >> + :  EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_RISING;
>> >> +
>> >
>> >Ternaries are excellent when they increase code readability.
>> >I am not convinced that is the case here.
>> >
>> >Consider:
>> >
>> >  if (MmioBitFieldRead32 (RegAddress, BitNumber, BitNumber) == 0) {
>> >*TriggerType = EFI_HARDWARE_INTERRUPT2_TRIGGER_LEVEL_HIGH;
>> >  } else {
>> >*TriggerType = EFI_HARDWARE_INTERRUPT2_TRIGGER_EDGE_RISING;
>> >  }
>> >
>> >?
>> >
>> >The versions generate identical code with gcc at -O1 and above.
>>
>> Firstly, I'm not sure why 5 lines of code is more readable than 3.
>> My main point though  is that the ternary expression clearly indicates
>> that all we are doing is setting *TriggerType.
>> The multiple assignment "if" requires examination to determine that there
>> is nothing else going on. (Because otherwise why wouldn't you use a
>> ternary?)
>> I'm about to submit v2 without this, in the hope that I've made the case.
>>
>
> I find your argument unconvincing and would prefer an "if" clause.
>
> That is fine,  lots of people have irrational prejudices.  ;-)
>
> Do you have a counter argument though?
>

I don't think I need a 3rd argument. Like Leif, I don't think that
ternary adds clarity and think an '"if" statement would be easier to
decipher.


> Leif points out that “Ternaries are excellent when they increase code
> readability.”
>
> The debate would thus seem to be a subjective assessment of “readability”.
>

Indeed it is.


> What criteria should we use to identify when a ternary is more readable, and
> when not?
>
> And how do we ensure consistency across all EDK2 maintainers?
>

None of that is down to me.

Cheers,
Ryan.

> Evan
>
>
>
> …
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions

[Ryan Harkin]

On 16 Feb 2017 20:27, "Evan Lloyd"  wrote:
>
> Hi Leif.
> We accept all the comments except that about ternaries.
> Response inline.
>
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: 13 February 2017 12:16
> >To: Evan Lloyd
> >Cc: edk2-de...@ml01.01.org; ard.biesheu...@linaro.org;
> >ryan.har...@linaro.org
> >Subject: Re: [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType
> >functions
> >
> >On Thu, Feb 09, 2017 at 07:26:23PM +, evan.ll...@arm.com wrote:
> >> From: Girish Pathak 
> >>
> >> This change implements GetTriggerType and SetTriggerType functions
> >> in ArmGicV2Dxe (GicV2GetTriggerType/GicV2SetTriggerType)
> >> and ArmGicV3Dxe (GicV3GetTriggerType/GicV3SetTriggerType)
> >>
> >> SetTriggerType configures the interrupt mode of an interrupt
> >> as edge sensitive or level sensitive.
> >>
> >> GetTriggerType function returns the mode of an interrupt.
> >>
> >> The requirement for this change derives from a problem detected on
> >ARM
> >> Juno boards, but the change is of generic relevance.
> >>
> >> NOTE: At this point the GICv3 code is not tested.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Girish Pathak 
> >> Signed-off-by: Evan Lloyd 
> >> Tested-by: Girish Pathak 
> >
> >(Tested-by: is usually considered to be implicit from the code author
> >- its value comes when added by someone else.)
> >
> >> ---
> >>  ArmPkg/Include/Library/ArmGicLib.h|   4 +
> >>  ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 165
> >++--
> >>  ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 159
> >+--
> >>  3 files changed, 308 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/ArmPkg/Include/Library/ArmGicLib.h
> >b/ArmPkg/Include/Library/ArmGicLib.h
> >> index
> >4364f3ffef464596f64cf59881d703cf54cf0ddd..6610f356c20e73d84ff3ba51995
> >6b426d97ef1eb 100644
> >> --- a/ArmPkg/Include/Library/ArmGicLib.h
> >> +++ b/ArmPkg/Include/Library/ArmGicLib.h
> >> @@ -51,6 +51,10 @@
> >>  #define ARM_GIC_ICDDCR_ARE  (1 << 4) // Affinity Routing Enable
> >(ARE)
> >>  #define ARM_GIC_ICDDCR_DS   (1 << 6) // Disable Security (DS)
> >>
> >> +// GICD_ICDICFR bits
> >> +#define ARM_GIC_ICDICFR_LEVEL_TRIGGERED  0x0 // Level triggered
> >interrupt
> >> +#define ARM_GIC_ICDICFR_EDGE_TRIGGERED   0x1 // Edge triggered
> >interrupt
> >> +
> >>  //
> >>  // GIC Redistributor
> >>  //
> >> diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
> >b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
> >> index
> >8c4d66125e2e8c7af9898f336ee742ed0aebf058..1f47403c6cdc7e8c0f6ac65d3
> >b95a562da6a2d32 100644
> >> --- a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
> >> +++ b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
> >> @@ -29,6 +29,7 @@ Abstract:
> >>  #define ARM_GIC_DEFAULT_PRIORITY  0x80
> >>
> >>  extern EFI_HARDWARE_INTERRUPT_PROTOCOL
> >gHardwareInterruptV2Protocol;
> >> +extern EFI_HARDWARE_INTERRUPT2_PROTOCOL
> >gHardwareInterrupt2V2Protocol;
> >>
> >>  STATIC UINT32 mGicInterruptInterfaceBase;
> >>  STATIC UINT32 mGicDistributorBase;
> >> @@ -193,19 +194,95 @@ EFI_HARDWARE_INTERRUPT_PROTOCOL
> >gHardwareInterruptV2Protocol = {
> >>GicV2EndOfInterrupt
> >>  };
> >>
> >> +/**
> >> +  Calculate GICD_ICFGRn base address and corresponding bit
> >> +  field Int_config[1] of the GIC distributor register.
> >> +
> >> +  @param Source   Hardware source of the interrupt.
> >> +  @param RegAddress   Corresponding GICD_ICFGRn base address.
> >> +  @param BitNumberBit number in the register to set/reset.
> >> +
> >> +  @retval EFI_SUCCESS   Source interrupt supported.
> >> +  @retval EFI_UNSUPPORTED   Source interrupt is not supported.
> >> +**/
> >>  STATIC
> >>  EFI_STATUS
> >> +GicGetDistributorIntrCfgBaseAndBitField (
> >
> >I don't see Interrupt generally truncated to Intr in this driver.
> >Since what is being looked for is the the ICFG, why not just call it
> >GicGetDistributorICfgBaseAndBitField?
> >
> >> +  IN HARDWARE_INTERRUPT_SOURCE Source,
> >> +  OUT UINTN   *RegAddress,
> >> +  OUT UINTN   *BitNumber
> >> +  )
> >> +{
> >> +  UINTN  RegOffset;
> >> +  UINTN  Field;
> >> +
> >> +  if (Source >= mGicNumInterrupts) {
> >> +ASSERT(Source < mGicNumInterrupts);
> >> +return EFI_UNSUPPORTED;
> >> +  }
> >> +
> >> +  RegOffset = Source / 16;
> >> +  Field = Source % 16;
> >> +  *RegAddress = PcdGet64 (PcdGicDistributorBase)
> >> +  + ARM_GIC_ICDICFR
> >> +  + (4 * RegOffset);
> >> +  *BitNumber = (Field * 2) + 1;
> >
> >A lot of magic values above - can this be improved with some added
> >#defines in ArmGicLib.h?
> >
> >> +
> >> +  return EFI_SUCCESS;
> >> +}
> >> +
> >> +/**
> >> +  Get interrupt trigger type of an interrupt
> >> +
> >> +  @param This  

Re: [edk2] [PATCH V3 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Ryan Harkin]

On 31 January 2017 at 11:44, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Tue, Jan 31, 2017 at 09:48:11AM +0000, Ryan Harkin wrote:
>> On 26 January 2017 at 14:36, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> > On Fri, Jan 20, 2017 at 05:10:45PM +0530, Bhupesh Sharma wrote:
>> >> ARM TZASC-380 IP provides a mechanism to split memory regions being
>> >> protected via it into eight equal-sized sub-regions. A bit-setting
>> >> allows the corresponding subregion to be disabled.
>> >>
>> >> Several NXP/FSL SoCs support the TZASC-380 IP block and allow
>> >> the DDR connected via the TZASC to be partitioned into regions
>> >> having different security settings and also allow subregions
>> >> to be disabled.
>> >>
>> >> This patch enables this support and can be used for SoCs which
>> >> support such a partition of DDR regions.
>> >>
>> >> Details of the 'subregion_disable' register can be viewed here:
>> >> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html
>> >>
>> >> Cc: Leif Lindholm <leif.lindh...@linaro.org>
>> >> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> >> Contributed-under: TianoCore Contribution Agreement 1.0
>> >> Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
>> >> [bhupesh.li...@gmail.com : Added my gmail ID as the NXP one is no longer 
>> >> valid]
>> >> Signed-off-by: Bhupesh Sharma <bhupesh.li...@gmail.com>
>> >
>> > Thanks for the cleanup.
>> > I may actually delete that CTA9x4 lib once your platform gets in...
>> >
>> Probably a good idea. I suspect it's not used or tested any more,
>> unless QEMU is using it?
>
> It's unused.

Good. Maybe it's u-boot that uses CTA9 for qemu testing...


> And if we do ever resurrect the CTA9 port, it'll be using
> ARM Trusted Firmware,

Gulp!


> so this code will still be irrelevant.
>
Exterminate!

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

Re: [edk2] [PATCH V3 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Ryan Harkin]

On 26 January 2017 at 14:36, Leif Lindholm  wrote:
> On Fri, Jan 20, 2017 at 05:10:45PM +0530, Bhupesh Sharma wrote:
>> ARM TZASC-380 IP provides a mechanism to split memory regions being
>> protected via it into eight equal-sized sub-regions. A bit-setting
>> allows the corresponding subregion to be disabled.
>>
>> Several NXP/FSL SoCs support the TZASC-380 IP block and allow
>> the DDR connected via the TZASC to be partitioned into regions
>> having different security settings and also allow subregions
>> to be disabled.
>>
>> This patch enables this support and can be used for SoCs which
>> support such a partition of DDR regions.
>>
>> Details of the 'subregion_disable' register can be viewed here:
>> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html
>>
>> Cc: Leif Lindholm 
>> Cc: Ard Biesheuvel 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Bhupesh Sharma 
>> [bhupesh.li...@gmail.com : Added my gmail ID as the NXP one is no longer 
>> valid]
>> Signed-off-by: Bhupesh Sharma 
>
> Thanks for the cleanup.
> I may actually delete that CTA9x4 lib once your platform gets in...
>
Probably a good idea. I suspect it's not used or tested any more,
unless QEMU is using it?

> Reviewed-by: Leif Lindholm 
>
> Pushed as 465663e.
>
>> ---
>> Changes from v2:
>>  - Added more descriptive arrays as suggested by Leif
>>
>>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c   | 14 +++---
>>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c| 13 ++---
>>  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h | 19 
>> ++-
>>  3 files changed, 35 insertions(+), 11 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> index 6fa0774f59f8..42d731ea98c9 100644
>> --- 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> +++ 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> @@ -72,18 +72,18 @@ ArmPlatformSecTrustzoneInit (
>>// NOR Flash 0 non secure (BootMon)
>>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_NOR0_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
>> secure firmware (sec_uefi.bin)
>>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE,0,
>> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Base of SRAM. Only half of SRAM in Non Secure world
>> @@ -92,22 +92,22 @@ ArmPlatformSecTrustzoneInit (
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Memory Mapped Peripherals. All in non secure world
>>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_PERIPH_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// MotherBoard Peripherals and On-chip peripherals.
>>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
>> -  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW, 0);
>>  }
>>
>>  /**
>> diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
>> b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
>> index 070c0dcb5d4d..1f002198e552 100644
>> --- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
>> +++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
>> @@ -87,20 +87,27 @@ TZASCSetRegion (
>>IN  UINTN LowAddress,
>>  

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 24 January 2017 at 11:05, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 24 January 2017 at 02:19, Daniil Egranov <daniil.egra...@arm.com> wrote:
>> Hi Ryan,
>>
>>
>>
>> On 01/23/2017 06:56 AM, Ryan Harkin wrote:
>>>
>>> On 20 January 2017 at 20:57, Daniil Egranov <daniil.egra...@arm.com>
>>> wrote:
>>>>
>>>> Hi Ryan,
>>>>
>>>>
>>>> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>>>>
>>>> On 20 January 2017 at 01:34, Daniil Egranov <daniil.egra...@arm.com>
>>>> wrote:
>>>>
>>>> Hi Leif, Ryan
>>>>
>>>>
>>>> On 01/19/2017 09:13 AM, Leif Lindholm wrote:
>>>>
>>>> On Thu, Jan 19, 2017 at 01:49:04PM +, Ryan Harkin wrote:
>>>>
>>>> On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com>
>>>> wrote:
>>>>
>>>> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
>>>> It disabled for Juno R0 due to PCI issues on this board.
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>>> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>>>>
>>>> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>>>>
>>>> ---
>>>>   ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>>>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>>> index 47ff587..e9e6990 100644
>>>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>>> @@ -378,6 +378,7 @@ OnEndOfDxe (
>>>> EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>>>> EFI_HANDLEHandle;
>>>> EFI_STATUSStatus;
>>>> +  UINT32JunoRevision;
>>>>
>>>> //
>>>> // PCI Root Complex initialization
>>>> @@ -393,8 +394,12 @@ OnEndOfDxe (
>>>> Status = gBS->ConnectController (Handle, NULL,
>>>> PciRootComplexDevicePath,
>>>> FALSE);
>>>> ASSERT_EFI_ERROR (Status);
>>>>
>>>> -  Status = ArmJunoSetNicMacAddress ();
>>>> -  ASSERT_EFI_ERROR (Status);
>>>> +  GetJunoRevision (JunoRevision);
>>>> +
>>>> +  if (JunoRevision != JUNO_REVISION_R0) {
>>>> +Status = ArmJunoSetNicMacAddress ();
>>>> +ASSERT_EFI_ERROR (Status);
>>>>
>>>> This is just an FYI, but I stacked your patch on top of mainline, like
>>>> this:
>>>>
>>>> 5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
>>>> Fixed crash on Juno R0   [Daniil Egranov]
>>>> 19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
>>>>   [Thomas Huth]
>>>>
>>>> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
>>>> assert triggered:
>>>>
>>>> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
>>>> [snip]
>>>> ASSERT_EFI_ERROR (Status = Not Found)
>>>> ASSERT [ArmJunoDxe]
>>>>
>>>> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
>>>> !EFI_ERROR (Status)
>>>>
>>>> I worked out what is happening. And it's not to do with this patch.
>>>> It's another fall-out from the re-work you did to the previous patch.
>>>> It's also ultimately due to a bug the firmware.
>>>>
>>>> With the initial version of your "Set Marvell Yukon MAC address"
>>>> patch, this hang didn't happen. I suspect that was because your error
>>>> checking was weaker and certain PCIe failures didn't trigger the
>>>> assert.
>>>>
>>>> To reproduce the error with this commit:
>>>> 1) power on and boot R1 or R2 into Shell
>>>>I do this by interrupting the boot by pressing ESCAPE and using the
>>>> boot
>>>> menu
>>>> 2) At the Shell prompt, run "reset -s" to shutdown
>>>> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
>>>> 4) the board will hang w

Re: [edk2] [PATCH v2] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 24 January 2017 at 02:01, Daniil Egranov <daniil.egra...@arm.com> wrote:
> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
> It disabled for Juno R0 due to PCI issues on this board.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
> Changelog:
>
> v2
> Replaced ASSERT with the error message in case Marvell MAC address
> set has failed
>

^ Thanks for doing that, it's much more usable in my setup now.


>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 47ff587..0193b98 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -378,6 +378,7 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> +  UINT32JunoRevision;
>
>//
>// PCI Root Complex initialization
> @@ -393,8 +394,14 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath, 
> FALSE);
>ASSERT_EFI_ERROR (Status);
>
> -  Status = ArmJunoSetNicMacAddress ();
> -  ASSERT_EFI_ERROR (Status);
> +  GetJunoRevision (JunoRevision);
> +
> +  if (JunoRevision != JUNO_REVISION_R0) {
> +Status = ArmJunoSetNicMacAddress ();
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "ArmJunoDxe: Failed to set Marvell Yukon NIC MAC 
> address\n"));
> +}
> +  }
>  }
>
>  STATIC
> --
> 2.7.4
>
> ___
> 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] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 24 January 2017 at 02:19, Daniil Egranov <daniil.egra...@arm.com> wrote:
> Hi Ryan,
>
>
>
> On 01/23/2017 06:56 AM, Ryan Harkin wrote:
>>
>> On 20 January 2017 at 20:57, Daniil Egranov <daniil.egra...@arm.com>
>> wrote:
>>>
>>> Hi Ryan,
>>>
>>>
>>> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>>>
>>> On 20 January 2017 at 01:34, Daniil Egranov <daniil.egra...@arm.com>
>>> wrote:
>>>
>>> Hi Leif, Ryan
>>>
>>>
>>> On 01/19/2017 09:13 AM, Leif Lindholm wrote:
>>>
>>> On Thu, Jan 19, 2017 at 01:49:04PM +, Ryan Harkin wrote:
>>>
>>> On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com>
>>> wrote:
>>>
>>> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
>>> It disabled for Juno R0 due to PCI issues on this board.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>>>
>>> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>>>
>>> ---
>>>   ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> index 47ff587..e9e6990 100644
>>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> @@ -378,6 +378,7 @@ OnEndOfDxe (
>>> EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>>> EFI_HANDLEHandle;
>>> EFI_STATUSStatus;
>>> +  UINT32JunoRevision;
>>>
>>> //
>>> // PCI Root Complex initialization
>>> @@ -393,8 +394,12 @@ OnEndOfDxe (
>>> Status = gBS->ConnectController (Handle, NULL,
>>> PciRootComplexDevicePath,
>>> FALSE);
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> -  Status = ArmJunoSetNicMacAddress ();
>>> -  ASSERT_EFI_ERROR (Status);
>>> +  GetJunoRevision (JunoRevision);
>>> +
>>> +  if (JunoRevision != JUNO_REVISION_R0) {
>>> +Status = ArmJunoSetNicMacAddress ();
>>> +ASSERT_EFI_ERROR (Status);
>>>
>>> This is just an FYI, but I stacked your patch on top of mainline, like
>>> this:
>>>
>>> 5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
>>> Fixed crash on Juno R0   [Daniil Egranov]
>>> 19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
>>>   [Thomas Huth]
>>>
>>> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
>>> assert triggered:
>>>
>>> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
>>> [snip]
>>> ASSERT_EFI_ERROR (Status = Not Found)
>>> ASSERT [ArmJunoDxe]
>>>
>>> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
>>> !EFI_ERROR (Status)
>>>
>>> I worked out what is happening. And it's not to do with this patch.
>>> It's another fall-out from the re-work you did to the previous patch.
>>> It's also ultimately due to a bug the firmware.
>>>
>>> With the initial version of your "Set Marvell Yukon MAC address"
>>> patch, this hang didn't happen. I suspect that was because your error
>>> checking was weaker and certain PCIe failures didn't trigger the
>>> assert.
>>>
>>> To reproduce the error with this commit:
>>> 1) power on and boot R1 or R2 into Shell
>>>I do this by interrupting the boot by pressing ESCAPE and using the
>>> boot
>>> menu
>>> 2) At the Shell prompt, run "reset -s" to shutdown
>>> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
>>> 4) the board will hang while booting UEFI, assuming the board firmware
>>> doesn't die with constant messages like this:
>>>
>>>  ERROR: PCIe CSR read failed to respond
>>>  ERROR: SMBus transaction not claimed
>>>
>>> Assuming the problem is firmware, not EDK2, what should we do about it?
>>>
>>> OK, so instinctively, my reaction was that "the reset -s bug is a
>>> system controller firmware bug and 

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 20 January 2017 at 20:57, Daniil Egranov <daniil.egra...@arm.com> wrote:
> Hi Ryan,
>
>
> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>
> On 20 January 2017 at 01:34, Daniil Egranov <daniil.egra...@arm.com> wrote:
>
> Hi Leif, Ryan
>
>
> On 01/19/2017 09:13 AM, Leif Lindholm wrote:
>
> On Thu, Jan 19, 2017 at 01:49:04PM +, Ryan Harkin wrote:
>
> On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com> wrote:
>
> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
> It disabled for Juno R0 due to PCI issues on this board.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 47ff587..e9e6990 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -378,6 +378,7 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> +  UINT32JunoRevision;
>
>//
>// PCI Root Complex initialization
> @@ -393,8 +394,12 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath,
> FALSE);
>ASSERT_EFI_ERROR (Status);
>
> -  Status = ArmJunoSetNicMacAddress ();
> -  ASSERT_EFI_ERROR (Status);
> +  GetJunoRevision (JunoRevision);
> +
> +  if (JunoRevision != JUNO_REVISION_R0) {
> +Status = ArmJunoSetNicMacAddress ();
> +ASSERT_EFI_ERROR (Status);
>
> This is just an FYI, but I stacked your patch on top of mainline, like this:
>
> 5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
> Fixed crash on Juno R0   [Daniil Egranov]
> 19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
>  [Thomas Huth]
>
> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
> assert triggered:
>
> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
> [snip]
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT [ArmJunoDxe]
> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
> !EFI_ERROR (Status)
>
> I worked out what is happening. And it's not to do with this patch.
> It's another fall-out from the re-work you did to the previous patch.
> It's also ultimately due to a bug the firmware.
>
> With the initial version of your "Set Marvell Yukon MAC address"
> patch, this hang didn't happen. I suspect that was because your error
> checking was weaker and certain PCIe failures didn't trigger the
> assert.
>
> To reproduce the error with this commit:
> 1) power on and boot R1 or R2 into Shell
>   I do this by interrupting the boot by pressing ESCAPE and using the boot
> menu
> 2) At the Shell prompt, run "reset -s" to shutdown
> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
> 4) the board will hang while booting UEFI, assuming the board firmware
> doesn't die with constant messages like this:
>
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
>
> Assuming the problem is firmware, not EDK2, what should we do about it?
>
> OK, so instinctively, my reaction was that "the reset -s bug is a
> system controller firmware bug and we shouldn't work around
> it". However, since it is actually disrupting Ryan's workflow, which
> frequently doesn't touch PCI at all, I think downgrading the ASSERT to
> an error message is a good idea short-term.
>
> Daniil - could you make that change please?
>
> /
> Leif
>
>
> I've been able to reproduce "PCIe CSR read failed to respond" and "SMBus
> transaction not claimed" errors on my Juno R2. I disabled Marvell Yukon
> driver (.dsc/.fdf) and removed ArmJunoDxe patch but still see the same error
> messages during the initial boot.
>
> Testing motherboard interfaces (FPGA build 118)...
> SRAM 32MB test: PASSED
> LAN9118   test: PASSED
> KMI1/2test: PASSED
> MMC   test: PASSED
> PB/LEDs   test: PASSED
> FPGA UART test: PASSED
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
> ERROR: PCIe CSR read failed to respond
> ...
>
> Once it went through reporting these errors, the UEFI starts loading but
> still

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 20 January 2017 at 20:57, Daniil Egranov <daniil.egra...@arm.com> wrote:
> Hi Ryan,
>
>
> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>
> On 20 January 2017 at 01:34, Daniil Egranov <daniil.egra...@arm.com> wrote:
>
> Hi Leif, Ryan
>
>
> On 01/19/2017 09:13 AM, Leif Lindholm wrote:
>
> On Thu, Jan 19, 2017 at 01:49:04PM +, Ryan Harkin wrote:
>
> On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com> wrote:
>
> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
> It disabled for Juno R0 due to PCI issues on this board.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 47ff587..e9e6990 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -378,6 +378,7 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> +  UINT32JunoRevision;
>
>//
>// PCI Root Complex initialization
> @@ -393,8 +394,12 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath,
> FALSE);
>ASSERT_EFI_ERROR (Status);
>
> -  Status = ArmJunoSetNicMacAddress ();
> -  ASSERT_EFI_ERROR (Status);
> +  GetJunoRevision (JunoRevision);
> +
> +  if (JunoRevision != JUNO_REVISION_R0) {
> +Status = ArmJunoSetNicMacAddress ();
> +ASSERT_EFI_ERROR (Status);
>
> This is just an FYI, but I stacked your patch on top of mainline, like this:
>
> 5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
> Fixed crash on Juno R0   [Daniil Egranov]
> 19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
>  [Thomas Huth]
>
> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
> assert triggered:
>
> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
> [snip]
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT [ArmJunoDxe]
> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
> !EFI_ERROR (Status)
>
> I worked out what is happening. And it's not to do with this patch.
> It's another fall-out from the re-work you did to the previous patch.
> It's also ultimately due to a bug the firmware.
>
> With the initial version of your "Set Marvell Yukon MAC address"
> patch, this hang didn't happen. I suspect that was because your error
> checking was weaker and certain PCIe failures didn't trigger the
> assert.
>
> To reproduce the error with this commit:
> 1) power on and boot R1 or R2 into Shell
>   I do this by interrupting the boot by pressing ESCAPE and using the boot
> menu
> 2) At the Shell prompt, run "reset -s" to shutdown
> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
> 4) the board will hang while booting UEFI, assuming the board firmware
> doesn't die with constant messages like this:
>
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
>
> Assuming the problem is firmware, not EDK2, what should we do about it?
>
> OK, so instinctively, my reaction was that "the reset -s bug is a
> system controller firmware bug and we shouldn't work around
> it". However, since it is actually disrupting Ryan's workflow, which
> frequently doesn't touch PCI at all, I think downgrading the ASSERT to
> an error message is a good idea short-term.
>
> Daniil - could you make that change please?
>
> /
> Leif
>
>
> I've been able to reproduce "PCIe CSR read failed to respond" and "SMBus
> transaction not claimed" errors on my Juno R2. I disabled Marvell Yukon
> driver (.dsc/.fdf) and removed ArmJunoDxe patch but still see the same error
> messages during the initial boot.
>
> Testing motherboard interfaces (FPGA build 118)...
> SRAM 32MB test: PASSED
> LAN9118   test: PASSED
> KMI1/2test: PASSED
> MMC   test: PASSED
> PB/LEDs   test: PASSED
> FPGA UART test: PASSED
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
> ERROR: PCIe CSR read failed to respond
> ...
>
> Once it went through reporting these errors, the UEFI starts loading but
> still

Re: [edk2] [PATCH] ArmPkg/ArmLib: remove indirection layer from timer register accessors

[Ryan Harkin]

On 20 January 2017 at 14:35, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 20 January 2017 at 14:32, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> Hi Ard,
>>
>> On 20 January 2017 at 12:06, Ard Biesheuvel <ard.biesheu...@linaro.org> 
>> wrote:
>>> The generic timer support libraries call the actual system register
>>> accessor function via a single pair of functions ArmArchTimerReadReg()
>>> and ArmArchTimerWriteReg(), which take an enum to argument to identify
>>> the register, and return output values by pointer reference.
>>>
>>> Since these functions are never called with a non-immediate argument,
>>> we can simply replace each invocation with the underlying system register
>>> accessor instead. This is mostly functionally equivalent, with the
>>> exception of the bounds check for the enum (which is pointless given the
>>> fact that we never pass a variable), the check for the presence of the
>>> architected timer (which only makes sense for ARMv7, but is highly unlikely
>>> to vary between platforms that are similar enough to run the same firmware
>>> image), and a check for enum values that refer to the HYP view of the timer,
>>> which we never referred to anywhere in the code in the first place.
>>>
>>> So get rid of the middle man, and update the ArmGenericTimerPhyCounterLib
>>> and ArmGenericTimerVirtCounterLib implementations to call the system
>>> register accessors directly.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>
>> Are there any other patches needed to get this working?
>>
>> I've just applied it to the head of EDK2 [1] and I get this error when
>> building for TC2, FVP and Juno:
>>
>> Building ... 
>> /linaro/platforms/uefi/edk2/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>> [AARCH64]
>> /linaro/platforms/uefi/edk2/ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.c:
>> In function 'ArmGenericTimerSetTimerFreq':
>> /linaro/platforms/uefi/edk2/ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.c:51:19:
>> error: 'CntFrq' undeclared (first use in this function)
>>ArmWriteCntFrq (CntFrq);
>>^
>> /linaro/platforms/uefi/edk2/ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.c:51:19:
>> note: each undeclared identifier is reported only once for each
>> function it appears in
>> GNUmakefile:304: recipe for target
>> '/linaro/platforms/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib/OUTPUT/ArmGenericTimerPhyCounterLib.obj'
>> failed
>> make: *** 
>> [/linaro/platforms/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib/OUTPUT/ArmGenericTimerPhyCounterLib.obj]
>> Error 1
>>
>
>
> Oops! Poor testing on my part: that should be FreqInHz not CntFrq

Naughty! ;-)

Okay, so with that change, it works on TC2, FVP Foundation & AEMv8 and
Juno R0/R1/R2:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 20 January 2017 at 01:34, Daniil Egranov <daniil.egra...@arm.com> wrote:
> Hi Leif, Ryan
>
>
> On 01/19/2017 09:13 AM, Leif Lindholm wrote:
>
> On Thu, Jan 19, 2017 at 01:49:04PM +, Ryan Harkin wrote:
>
> On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com> wrote:
>
> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
> It disabled for Juno R0 due to PCI issues on this board.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 47ff587..e9e6990 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -378,6 +378,7 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> +  UINT32JunoRevision;
>
>//
>// PCI Root Complex initialization
> @@ -393,8 +394,12 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath,
> FALSE);
>ASSERT_EFI_ERROR (Status);
>
> -  Status = ArmJunoSetNicMacAddress ();
> -  ASSERT_EFI_ERROR (Status);
> +  GetJunoRevision (JunoRevision);
> +
> +  if (JunoRevision != JUNO_REVISION_R0) {
> +Status = ArmJunoSetNicMacAddress ();
> +ASSERT_EFI_ERROR (Status);
>
> This is just an FYI, but I stacked your patch on top of mainline, like this:
>
> 5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
> Fixed crash on Juno R0   [Daniil Egranov]
> 19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
>  [Thomas Huth]
>
> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
> assert triggered:
>
> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
> [snip]
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT [ArmJunoDxe]
> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
> !EFI_ERROR (Status)
>
> I worked out what is happening. And it's not to do with this patch.
> It's another fall-out from the re-work you did to the previous patch.
> It's also ultimately due to a bug the firmware.
>
> With the initial version of your "Set Marvell Yukon MAC address"
> patch, this hang didn't happen. I suspect that was because your error
> checking was weaker and certain PCIe failures didn't trigger the
> assert.
>
> To reproduce the error with this commit:
> 1) power on and boot R1 or R2 into Shell
>   I do this by interrupting the boot by pressing ESCAPE and using the boot
> menu
> 2) At the Shell prompt, run "reset -s" to shutdown
> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
> 4) the board will hang while booting UEFI, assuming the board firmware
> doesn't die with constant messages like this:
>
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
>
> Assuming the problem is firmware, not EDK2, what should we do about it?
>
> OK, so instinctively, my reaction was that "the reset -s bug is a
> system controller firmware bug and we shouldn't work around
> it". However, since it is actually disrupting Ryan's workflow, which
> frequently doesn't touch PCI at all, I think downgrading the ASSERT to
> an error message is a good idea short-term.
>
> Daniil - could you make that change please?
>
> /
> Leif
>
>
> I've been able to reproduce "PCIe CSR read failed to respond" and "SMBus
> transaction not claimed" errors on my Juno R2. I disabled Marvell Yukon
> driver (.dsc/.fdf) and removed ArmJunoDxe patch but still see the same error
> messages during the initial boot.
>
> Testing motherboard interfaces (FPGA build 118)...
> SRAM 32MB test: PASSED
> LAN9118   test: PASSED
> KMI1/2test: PASSED
> MMC   test: PASSED
> PB/LEDs   test: PASSED
> FPGA UART test: PASSED
> ERROR: PCIe CSR read failed to respond
> ERROR: SMBus transaction not claimed
> ERROR: PCIe CSR read failed to respond
> ...
>
> Once it went through reporting these errors, the UEFI starts loading but
> still fails in OnEndOfDxe():
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT [ArmJunoDxe]
> /home/user/workspace/juno/uefi/edk2/ArmPlatformPkg/Arm

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0

[Ryan Harkin]

On 18 January 2017 at 23:27, Daniil Egranov <daniil.egra...@arm.com> wrote:
> The Marvell Yukon MAC address load supported only on Juno R1 and R2.
> It disabled for Juno R0 due to PCI issues on this board.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
>  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index 47ff587..e9e6990 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -378,6 +378,7 @@ OnEndOfDxe (
>EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath;
>EFI_HANDLEHandle;
>EFI_STATUSStatus;
> +  UINT32JunoRevision;
>
>//
>// PCI Root Complex initialization
> @@ -393,8 +394,12 @@ OnEndOfDxe (
>Status = gBS->ConnectController (Handle, NULL, PciRootComplexDevicePath, 
> FALSE);
>ASSERT_EFI_ERROR (Status);
>
> -  Status = ArmJunoSetNicMacAddress ();
> -  ASSERT_EFI_ERROR (Status);
> +  GetJunoRevision (JunoRevision);
> +
> +  if (JunoRevision != JUNO_REVISION_R0) {
> +Status = ArmJunoSetNicMacAddress ();
> +ASSERT_EFI_ERROR (Status);

This is just an FYI, but I stacked your patch on top of mainline, like this:

5f81f61  2017-01-18  ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe:
Fixed crash on Juno R0   [Daniil Egranov]
19ca06b  2017-01-19  OvmfPkg: Remove superfluous return statements.
 [Thomas Huth]

The first time I ran this, Juno R0 worked fine, but on R1 and R2, the
assert triggered:

UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017)
[snip]
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT [ArmJunoDxe]
/linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401):
!EFI_ERROR (Status)

I worked out what is happening. And it's not to do with this patch.
It's another fall-out from the re-work you did to the previous patch.
It's also ultimately due to a bug the firmware.

With the initial version of your "Set Marvell Yukon MAC address"
patch, this hang didn't happen. I suspect that was because your error
checking was weaker and certain PCIe failures didn't trigger the
assert.

To reproduce the error with this commit:
1) power on and boot R1 or R2 into Shell
  I do this by interrupting the boot by pressing ESCAPE and using the boot menu
2) At the Shell prompt, run "reset -s" to shutdown
3) At the ARM Boot Loader "Cmd>" prompt, run "reboot"
4) the board will hang while booting UEFI, assuming the board firmware
doesn't die with constant messages like this:

ERROR: PCIe CSR read failed to respond
ERROR: SMBus transaction not claimed

Assuming the problem is firmware, not EDK2, what should we do about it?

Prior to your "Set Marvell Yukon MAC address" patch, or with the
earlier version, the board would boot anyway, but the Yukon device
would be missing.

Now it dies.

I don't know which is worse, but I think hanging is worse than an
ethernet port dropping out. Although hanging is a bit more obvious
that there's a problem...


> +  }
>  }
>
>  STATIC
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Set Marvell Yukon MAC address

[Ryan Harkin]

On 11 January 2017 at 11:45, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 10 January 2017 at 22:36, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> On Mon, Jan 09, 2017 at 03:20:51PM -0600, Daniil Egranov wrote:
>>> From: Daniil Egranov <daniil.egra...@linaro.org>
>>>
>>> The patch reads a valid MAC address form the Juno IOFPGA registers
>>> and pushes it into onboard Marvell Yukon NIC.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Daniil Egranov <daniil.egra...@linaro.org>
>>
>> Thanks for sticking with it.
>>
>> I fixed a typo in commit message an shortened the subject line
>> slightly, but:
>> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>> Pushed as a8675a1
>>
>
> Excellent, another patch in my fork that can go.
>

Unfortunately, while this works on Juno R1 and R2, it hangs R0 every time:

ASSERT [ArmJunoDxe]
/linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(397):
!EFI_ERROR (Status)

I guess that before the refactor, it would return EFI_SUCCESS on R0
when the MAC configuration failed...

> Daniil,
>
> When you originally posted this, you posted it along with
> "EmbeddedPkg: Added device configuration protocol". As Leif is happy
> with this patch as-is, I assume it isn't needed any more. You haven't
> chased it, you didn't respond to my ping about it and it's currently
> in my tree.
>
> Unless you get back to me about it, I'll drop it next time I rebase.
>

And I tested with this patch removed and everything still seemed to
work, so I'm assuming it's not needed and leaving it out unless you
explain otherwise.

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

Re: [edk2] [PATCH v4] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Set Marvell Yukon MAC address

[Ryan Harkin]

On 10 January 2017 at 22:36, Leif Lindholm  wrote:
> On Mon, Jan 09, 2017 at 03:20:51PM -0600, Daniil Egranov wrote:
>> From: Daniil Egranov 
>>
>> The patch reads a valid MAC address form the Juno IOFPGA registers
>> and pushes it into onboard Marvell Yukon NIC.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Daniil Egranov 
>
> Thanks for sticking with it.
>
> I fixed a typo in commit message an shortened the subject line
> slightly, but:
> Reviewed-by: Leif Lindholm 
> Pushed as a8675a1
>

Excellent, another patch in my fork that can go.

Daniil,

When you originally posted this, you posted it along with
"EmbeddedPkg: Added device configuration protocol". As Leif is happy
with this patch as-is, I assume it isn't needed any more. You haven't
chased it, you didn't respond to my ping about it and it's currently
in my tree.

Unless you get back to me about it, I'll drop it next time I rebase.

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

Re: [edk2] How to silence a build?

[Ryan Harkin]

Thanks both.

I think Andrew's idea is what I'm really looking for.  But in the
meantime, adding "-s" as Michael suggested is working quite well.

On 12 December 2016 at 18:58, Michael Zimmermann
<sigmaepsilo...@gmail.com> wrote:
> these build command options are probably what you want:
>
>   -s, --silent  Make use of silent mode of (n)make.
>   -q, --quiet   Disable all messages except FATAL ERRORS.
>   -v, --verbose Turn on verbose output with informational messages
> printed, including library instances selected, final
> dependency expression, and warning messages, etc.
>   -d DEBUG, --debug=DEBUG
> Enable debug messages at specified level.
>
> Thanks,
> Michael
>
> On Mon, Dec 12, 2016 at 7:34 PM, Andrew Fish <af...@apple.com> wrote:
>>
>>> On Dec 12, 2016, at 10:27 AM, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>>
>>> Hello all,
>>>
>>> Perhaps someone here can save me trying to decrypt the EDK2 build system.
>>>
>>> When I build EDK2, I get lots of output like this single line
>>> generated for compiling a single source file:
>>>
>>> "/linaro/extra-data/ci/workspace-lsk/tools/gcc/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc"
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/ArmPlatformPkg/ArmVExpressPkg/Include
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM
>>> -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds
>>> -ffunction-sections -fdata-sections -include AutoGen.h -fno-common
>>> -DSTRING_ARRAY_NAME=UiAppStrings -g -Os -fshort-wchar
>>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include
>>> AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm
>>> -funsigned-char -ffunction-sections -fdata-sections -fno-builtin
>>> -Wno-address -fno-asynchronous-unwind-tables -save-temps -O0
>>> -mcmodel=small -c -o
>>> /linaro/extra-data/ci/workspace-lsk/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/OUTPUT/./String.obj
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Application/UiApp
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg/Include
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg/Include/AArch64
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg
>>> -I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Include
>>> /linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Application/UiApp/String.c
>>>
>>> When I build the linux kernel, I see output like this:
>>>
>>>  CC  kernel/nsproxy.o
>>>  OBJCOPY arch/arm64/kernel/efi-entry.stub.o
>>>
>>> Is there an option to make EDK2 do something like this?
>>>
>>> Or can someone point me where I might look so I can think about
>>> implementing it?
>>
>> Ryan,
>>
>> The content of Conf/build_rule.txt is used to construct the makefiles. The 
>> rules under  will get translated into the generated makefiles. 
>> If you prepend an @ that makefile line should no longer echo.
>>
>> The Conf/build_rule.txt will get copied from the 
>> BaseTools/Conf//build_rule.template if it does not exist when you run 
>> edksetup.sh.
>>
>> You can always add an @print line to print out anything you want.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>>  I've had a look around and wasn't able to work out
>>> what was generating the output.  I guess that means my chances of
>>> changing the behaviour are slim too...
>>>
>>> Thanks,
>>> Ryan.
>>> ___
>>> 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] How to silence a build?

[Ryan Harkin]

Hello all,

Perhaps someone here can save me trying to decrypt the EDK2 build system.

When I build EDK2, I get lots of output like this single line
generated for compiling a single source file:

"/linaro/extra-data/ci/workspace-lsk/tools/gcc/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc"
 
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/ArmPlatformPkg/ArmVExpressPkg/Include
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM
-g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds
-ffunction-sections -fdata-sections -include AutoGen.h -fno-common
-DSTRING_ARRAY_NAME=UiAppStrings -g -Os -fshort-wchar
-fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include
AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm
-funsigned-char -ffunction-sections -fdata-sections -fno-builtin
-Wno-address -fno-asynchronous-unwind-tables -save-temps -O0
-mcmodel=small -c -o
/linaro/extra-data/ci/workspace-lsk/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/OUTPUT/./String.obj
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Application/UiApp
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg/Include
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdePkg/Include/AArch64
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg
-I/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Include
/linaro/extra-data/ci/workspace-lsk/uefi/edk2/MdeModulePkg/Application/UiApp/String.c

When I build the linux kernel, I see output like this:

  CC  kernel/nsproxy.o
  OBJCOPY arch/arm64/kernel/efi-entry.stub.o

Is there an option to make EDK2 do something like this?

Or can someone point me where I might look so I can think about
implementing it?  I've had a look around and wasn't able to work out
what was generating the output.  I guess that means my chances of
changing the behaviour are slim too...

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

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Set Marvell Yukon MAC address

[Ryan Harkin]

Hi Leif,

On 2 November 2016 at 11:55, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 1 November 2016 at 21:05, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> On Tue, Nov 01, 2016 at 05:55:11PM +, Ryan Harkin wrote:
>>> Hi Daniil,
>>>
>>> While looking for another patch, I found this on the maillist...
>>>
>>> On 6 October 2016 at 02:42, Daniil Egranov <daniil.egra...@arm.com> wrote:
>>> > The patch reads a valid MAC address form the Juno IOFPGA registers
>>> > and pushes it into onboard Marvell Yukon NIC.
>>> >
>>> > Contributed-under: TianoCore Contribution Agreement 1.0
>>> > Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>
> Tested on Juno R0/1/2.
>
> Tested-by; Ryan Harkin <ryan.har...@linaro.org>
>
>
>>> > ---
>>> >  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 141 
>>> > +
>>> >  .../Drivers/ArmJunoDxe/ArmJunoDxeInternal.h|  12 ++
>>> >  2 files changed, 153 insertions(+)
>>> >
>>> > diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
>>> > b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> > index b97f044..0c5fbd0 100644
>>> > --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> > +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>>> > @@ -17,6 +17,8 @@
>>> >
>>> >  #include 
>>> >  #include 
>>> > +#include 
>>> > +#include 
>>> >
>>> >  #include 
>>> >  #include 
>>> > @@ -68,6 +70,142 @@ STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
>>> > mPciRootComplexDevicePath = {
>>> >
>>> >  EFI_EVENT mAcpiRegistration = NULL;
>>> >
>>> > +UINT32 SwapUINT32(UINT32 value)
>>> > +{
>>> > +  value = ((value << 8) & 0xFF00FF00 ) | ((value >> 8) & 0xFF00FF );
>>> > +  return (value << 16) | (value >> 16);
>>> > +}
>>> > +
>>> > +/**
>>> > +  The function reads MAC address from Juno IOFPGA registers and writes it
>>> > +  into Marvell Yukon NIC.
>>> > +**/
>>> > +STATIC
>>> > +EFI_STATUS
>>> > +ArmJunoSetNetworkMAC()
>>> > +{
>>> > +
>>> > +  EFI_STATUS  Status;
>>> > +  UINTN   HandleCount;
>>> > +  EFI_HANDLE  *HandleBuffer;
>>> > +  UINTN   HIndex;
>>> > +  EFI_PCI_IO_PROTOCOL*PciIo;
>>> > +  UINT64  PciID;
>>> > +  UINT32  MacHigh;
>>> > +  UINT32  MacLow;
>>> > +  UINT32  PciRegBase;
>>> > +  UINT64  OldPciAttributes;
>>> > +  UINT64  AttrSupports;
>>> > +  UINT8   *PciBarAttributes;
>>> > +
>>> > +  Status = gBS->LocateHandleBuffer (ByProtocol,
>>> > +,
>>> > +NULL, , );
>>> > +
>>> > +  if (!EFI_ERROR (Status)) {
>>> > +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
>>> > +  Status = gBS->OpenProtocol (
>>> > +  HandleBuffer[HIndex],
>>> > +  ,
>>> > +  (VOID **) ,
>>> > +  NULL,
>>> > +  NULL,
>>> > +  EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>>> > +
>>> > +  if (EFI_ERROR (Status)) {
>>> > +continue;
>>> > +  }
>>> > +
>>> > +  Status = PciIo->Pci.Read (
>>> > +PciIo,
>>> > +EfiPciIoWidthUint32,
>>> > +PCI_VENDOR_ID_OFFSET,
>>> > +1,
>>> > +
>>> > +);
>>> > +
>>> > +  if (EFI_ERROR (Status)) {
>>> > +continue;
>>> > +  }
>>> > +
>>> > +  if ((PciID & 0x) == JUNO_MARVELL_YUKON_ID) {
>>> > +
>>>

Re: [edk2] [PATCH v8 0/4] enhance MMC

[Ryan Harkin]

On 24 Nov 2016 16:31, "Ard Biesheuvel"  wrote:
>
> On 23 November 2016 at 13:36, Haojian Zhuang 
wrote:
> > v8:
> >   * Avoid to update revision number twice.
> >   * Move IsMultiBlock() interface from patch #4 to #1.
> >   * Replace 24MHz with 26MHz since 26MHz is specified by spec.
> >
>
> Hi all,
>
> I have pushed this series as follows:
>
> a28b9aef6769 EmbeddedPkg/Protocol/MmcHost: add new methods for I/O
> width and multiblock
> 1df2fe1433b2 ArmPlatformPkg/PL180MciDxe: update for identifying SD
> 752ae80514cc EmbeddedPkg/MmcDxe: invoke SetIos() protocol method to
> set speed and width
> e06253ba80d9 EmbeddedPkg/MmcDxe: set I/O speed and bus width in SD stack
> 339c6e905a15 EmbeddedPkg/MmcDxe: expand to support multiple blocks
>
> where the first patch contains all changes to the protocol
> definitions, and the second patch was pulled forward to maintain
> bisectability.
>
> Thanks a lot to Haojian for the hard work!
>

I just wanted to say "YAY"! :-)

> Regards,
> Ard.
>
>
> > v7:
> >   * Add revision checking.
> >
> > v6:
> >   * Reformat the last 5 patches after 4 MMC patches of this series
merged.
> >   * Squash original #5 and #6 patches together.
> >   * Fix according comments.
> >
> > v5:
> >   * Remove patch on MediaId.
> >   * Squash two PL180 patches together.
> >
> > v4:
> >   * Fix PL180 hang in some cases. Since the proper variable length
> > isn't set for CMD6 & ACMD51.
> >
> > v3:
> >   * Fix PL180 hang because of CMD6 & ACMD51 not supported.
> >
> > v2:
> >   * Fix print error with missing parameter.
> >   * Change CMD51 to ACMD51.
> >   * Add the protection after CMD55 for SD. If there's no
> > response of CMD55, skip to send ACMD51.
> >
> > v1:
> >   * Wait OCR busy bit free according to eMMC spec.
> >   * Define ECSD structure.
> >   * Add interface to set IO bus width and speed.
> >   * Support to access multiple blocks.
> >
> > Haojian Zhuang (4):
> >   MmcDxe: add interface in mmc host protocol
> >   MmcDxe: set iospeed and bus width in SD stack
> >   PL180: update for indentifying SD
> >   MmcDxe: expand to support multiple blocks
> >
> >  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c|  29 ++-
> >  EmbeddedPkg/Include/Protocol/MmcHost.h   |  35 ++-
> >  EmbeddedPkg/Universal/MmcDxe/Mmc.h   |  25 ++
> >  EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c| 176 +-
> >  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 291
++-
> >  5 files changed, 486 insertions(+), 70 deletions(-)
> >
> > --
> > 2.7.4
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] Remove the ArmPkg LinuxLoader

[Ryan Harkin]

On 21 November 2016 at 17:28, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 21 November 2016 at 12:29, Ard Biesheuvel <ard.biesheu...@linaro.org> 
> wrote:
>> On 21 November 2016 at 12:28, Ard Biesheuvel <ard.biesheu...@linaro.org> 
>> wrote:
>>> The LinuxLoader application is a deprecated development tool that allowed
>>> Linux kernels to be booted on ARM or arm64 before proper OS loader 
>>> functionality
>>> had been implemented. Now that this is the case, both in GRUB and in the
>>> respective kernel trees, we should no longer be using the LinuxLoader, which
>>> means it certainly does not belong in a reference code base such as 
>>> Tiancore.
>>> So replace or remove existing references (#1, #2) before deleting the code
>>> altogether (#3)
>>>
>>> Ard Biesheuvel (3):
>>>   EmbeddedPkg/AndroidFastboot: drop dependency on the LinuxLoader
>>>   BeagleBoardPkg/BeagleBoardPkg.dsc: remove the LinuxLoader application
>>>   ArmPkg: remove the LinuxLoader application
>>>
>>
>> Code can be found here:
>> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/log/?h=kill-bill
>
> Series tested on FVP, TC2 and Juno R0/1/2.
>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
> I can review tomorrow if you want a Reviewed-by too.

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] EmbeddedPkg/AndroidFastboot: drop dependency on the LinuxLoader

[Ryan Harkin]

On 21 November 2016 at 12:28, Ard Biesheuvel  wrote:
> When booting the kernel via Fastboot, invoke the kernel image directly
> rather than passing it to the LinuxLoader app. This requires the kernel
> image to be built with UEFI stub support.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
> Build tested only.
>
>  EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c | 70 
> ++--
>  1 file changed, 22 insertions(+), 48 deletions(-)
>
> diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
> b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> index acedd3e0e3cd..46a7ceb3a41c 100644
> --- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> +++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> @@ -21,11 +21,6 @@
>  #include 
>  #include 
>
> -#define LINUX_LOADER_COMMAND_LINE   L"%s -f %s -c %s"
> -
> -// This GUID is defined in the INGF file of ArmPkg/Application/LinuxLoader
> -CONST EFI_GUID mLinuxLoaderAppGuid = { 0x701f54f2, 0x0d70, 0x4b89, { 0xbc, 
> 0x0a, 0xd9, 0xca, 0x25, 0x37, 0x90, 0x59 }};
> -
>  // Device Path representing an image in memory
>  #pragma pack(1)
>  typedef struct {
> @@ -68,11 +63,7 @@ BootAndroidBootImg (
>VOID   *Ramdisk;
>UINTN   RamdiskSize;
>MEMORY_DEVICE_PATH  KernelDevicePath;
> -  MEMORY_DEVICE_PATH* RamdiskDevicePath;
> -  CHAR16* KernelDevicePathTxt;
> -  CHAR16* RamdiskDevicePathTxt;
> -  EFI_DEVICE_PATH*LinuxLoaderDevicePath;
> -  CHAR16* LoadOptions;
> +  CHAR16  *LoadOptions, *NewLoadOptions;
>
>Status = ParseAndroidBootImg (
>  Buffer,
> @@ -93,55 +84,38 @@ BootAndroidBootImg (
>KernelDevicePath.Node1.StartingAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) 
> Kernel;
>KernelDevicePath.Node1.EndingAddress   = (EFI_PHYSICAL_ADDRESS)(UINTN) 
> Kernel + KernelSize;
>
> -  RamdiskDevicePath = NULL;
> -  if (RamdiskSize != 0) {
> -RamdiskDevicePath = (MEMORY_DEVICE_PATH*)DuplicateDevicePath 
> ((EFI_DEVICE_PATH_PROTOCOL*) );
> -
> -RamdiskDevicePath->Node1.StartingAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) 
> Ramdisk;
> -RamdiskDevicePath->Node1.EndingAddress   = 
> ((EFI_PHYSICAL_ADDRESS)(UINTN) Ramdisk) + RamdiskSize;
> -  }
> -
> -  //
> -  // Boot Linux using the Legacy Linux Loader
> -  //
> -
> -  Status = LocateEfiApplicationInFvByGuid (, 
> );
> -  if (EFI_ERROR (Status)) {
> -Print (L"Couldn't Boot Linux: %d\n", Status);
> -return EFI_DEVICE_ERROR;
> -  }
> -
> -  KernelDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL 
> *) , FALSE, FALSE);
> -  if (KernelDevicePathTxt == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> -  }
> -
> -  RamdiskDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL 
> *) RamdiskDevicePath, FALSE, FALSE);
> -  if (RamdiskDevicePathTxt == NULL) {
> +  // Initialize Linux command line
> +  LoadOptions = CatSPrint (NULL, L"%a", KernelArgs);
> +  if (LoadOptions == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
>
> -  // Initialize Legacy Linux loader command line
> -  LoadOptions = CatSPrint (NULL, LINUX_LOADER_COMMAND_LINE, 
> KernelDevicePathTxt, RamdiskDevicePathTxt, KernelArgs);
> -  if (LoadOptions == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> +  if (RamdiskSize != 0) {
> +NewLoadOptions = CatSPrint (LoadOptions, L" initrd=0x%x,0x%x",
> +   (UINTN)Ramdisk, RamdiskSize);
> +FreePool (LoadOptions);
> +if (NewLoadOptions == NULL) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +LoadOptions = NewLoadOptions;
>}
>
> -  Status = BdsStartEfiApplication (gImageHandle, LinuxLoaderDevicePath, 
> StrSize (LoadOptions), LoadOptions);
> +  Status = BdsStartEfiApplication (gImageHandle,
> + (EFI_DEVICE_PATH_PROTOCOL *) ,
> + StrSize (LoadOptions),
> + LoadOptions);
>if (EFI_ERROR (Status)) {
>  DEBUG ((EFI_D_ERROR, "Couldn't Boot Linux: %d\n", Status));
> -return EFI_DEVICE_ERROR;
> -  }
> -
> -  if (RamdiskDevicePath) {
> -FreePool (RamdiskDevicePathTxt);
> -FreePool (RamdiskDevicePath);
> +Status = EFI_DEVICE_ERROR;
> +goto FreeLoadOptions;
>}
>
> -  FreePool (KernelDevicePathTxt);
> -
>// If we got here we do a confused face because BootLinuxFdt returned,
>// reporting success.
>DEBUG ((EFI_D_ERROR, "WARNING: BdsBootLinuxFdt returned EFI_SUCCESS.\n"));

This comment has nothing to do with your change, but this DEBUG
message hasn't been true since commit
bd9a5182a59696870690b54aaa63632c80694000 removed the call to
BdsBootLinuxFdt :-/


>return EFI_SUCCESS;
> +
> +FreeLoadOptions:
> +  FreePool (LoadOptions);
> +  

Re: [edk2] [PATCH 0/3] Remove the ArmPkg LinuxLoader

[Ryan Harkin]

On 21 November 2016 at 12:29, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 21 November 2016 at 12:28, Ard Biesheuvel <ard.biesheu...@linaro.org> 
> wrote:
>> The LinuxLoader application is a deprecated development tool that allowed
>> Linux kernels to be booted on ARM or arm64 before proper OS loader 
>> functionality
>> had been implemented. Now that this is the case, both in GRUB and in the
>> respective kernel trees, we should no longer be using the LinuxLoader, which
>> means it certainly does not belong in a reference code base such as Tiancore.
>> So replace or remove existing references (#1, #2) before deleting the code
>> altogether (#3)
>>
>> Ard Biesheuvel (3):
>>   EmbeddedPkg/AndroidFastboot: drop dependency on the LinuxLoader
>>   BeagleBoardPkg/BeagleBoardPkg.dsc: remove the LinuxLoader application
>>   ArmPkg: remove the LinuxLoader application
>>
>
> Code can be found here:
> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/log/?h=kill-bill

Series tested on FVP, TC2 and Juno R0/1/2.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

I can review tomorrow if you want a Reviewed-by too.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/7] EmbeddedPkg: SiI3132: Add SCSI protocol support to header

[Ryan Harkin]

Hi Jeremy,

On 14 November 2016 at 21:09, Jeremy Linton  wrote:
> Add EXT_SCSI_PASS_THRU structures to SI3132_PORT structure,
> along with helpers and new entry points.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton 
> ---
>  EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 89 
> +++-
>  1 file changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h 
> b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> index f23446a..91f9448 100644
> --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
> @@ -20,6 +20,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -57,6 +58,7 @@
>  #define SII3132_PORT_SLOTSTATUS_REG 0x1800
>  #define SII3132_PORT_CMDACTIV_REG   0x1C00
>  #define SII3132_PORT_SSTATUS_REG0x1F04
> +#define SII3132_PORT_SERROR_REG 0x1F08
>
>  #define SII3132_PORT_CONTROL_RESET  (1 << 0)
>  #define SII3132_PORT_DEVICE_RESET   (1 << 1)
> @@ -81,6 +83,7 @@
>  #define PRB_CTRL_INT_MASK   0x40
>  #define PRB_CTRL_SRST   0x80
>
> +#define PRB_PROT_DEFAULT0x00
>  #define PRB_PROT_PACKET 0x01
>  #define PRB_PROT_LEGACY_QUEUE   0x02
>  #define PRB_PROT_NATIVE_QUEUE   0x04
> @@ -88,6 +91,9 @@
>  #define PRB_PROT_WRITE  0x10
>  #define PRB_PROT_TRANSPARENT0x20
>
> +#define SII_FIS_REGISTER_H2D0x27  //Register FIS - Host to Device
> +#define SII_FIS_CONTROL_CMD (1 << 7)  //Indicate FIS is a command
> +
>  #define SGE_XCF (1 << 28)
>  #define SGE_DRD (1 << 29)
>  #define SGE_LNK (1 << 30)
> @@ -95,7 +101,7 @@
>
>  #define SI_MAX_CDB 12  //MAX supported CDB
>  #define SI_MAX_SENSE   256
> -#define SI_DEFAULT_TIMEOUT 2
> +#define SI_DEFAULT_TIMEOUT 5
>

This hunk doesn't apply.  The line being removed doesn't exist in the
upstream version of the file.  Have I missed something?

>
>  typedef struct _SATA_SI3132_SGE {
> @@ -126,6 +132,8 @@ typedef struct _SATA_SI3132_DEVICE {
>  UINTN   Index;
>  struct _SATA_SI3132_PORT*Port;  //Parent Port
>  UINT32  BlockSize;
> +BOOLEAN Atapi; //ATAPI device
> +BOOLEAN Cdb16; //Uses 16byte CDB transfers (or 12)
>  } SATA_SI3132_DEVICE;
>
>  typedef struct _SATA_SI3132_PORT {
> @@ -146,13 +154,18 @@ typedef struct _SATA_SI3132_INSTANCE {
>
>  SATA_SI3132_PORTPorts[SATA_SII3132_MAXPORT];
>
> -EFI_ATA_PASS_THRU_PROTOCOL  AtaPassThruProtocol;
> +EFI_ATA_PASS_THRU_MODEAtaPassThruMode;
> +EFI_ATA_PASS_THRU_PROTOCOLAtaPassThruProtocol;
> +EFI_EXT_SCSI_PASS_THRU_MODE   ExtScsiPassThruMode;
> +EFI_EXT_SCSI_PASS_THRU_PROTOCOL   ExtScsiPassThru;
> +
>
>  EFI_PCI_IO_PROTOCOL *PciIo;
>  } SATA_SI3132_INSTANCE;
>
>  #define SATA_SII3132_SIGNATURE  SIGNATURE_32('s', 'i', '3', '2')
>  #define INSTANCE_FROM_ATAPASSTHRU_THIS(a)   CR(a, SATA_SI3132_INSTANCE, 
> AtaPassThruProtocol, SATA_SII3132_SIGNATURE)
> +#define INSTANCE_FROM_SCSIPASSTHRU_THIS(a)  CR(a, SATA_SI3132_INSTANCE, 
> ExtScsiPassThru, SATA_SII3132_SIGNATURE)
>
>  #define SATA_GLOBAL_READ32(Offset, Value)  PciIo->Mem.Read (PciIo, 
> EfiPciIoWidthUint32, 0, Offset, 1, Value)
>  #define SATA_GLOBAL_WRITE32(Offset, Value) { UINT32 Value32 = Value; 
> PciIo->Mem.Write (PciIo, EfiPciIoWidthUint32, 0, Offset, 1, ); }
> @@ -271,4 +284,76 @@ EFI_STATUS SiI3132ResetDevice (
>IN UINT16 PortMultiplierPort
>);
>
> +/**
> + * EFI ATA Pass Thru Entry points for SCSI Protocol
> + */
> +SATA_SI3132_DEVICE* GetSataDevice (
> +  IN  SATA_SI3132_INSTANCE *SataInstance,
> +  IN  UINT16Port,
> +  IN  UINT16PortMultiplierPort
> +  );
> +
> +
> +EFI_STATUS SiI3132IssueCommand(
> +  IN SATA_SI3132_PORT *SataPort,
> +  EFI_PCI_IO_PROTOCOL *PciIo,
> +  IN UINT32Timeout,
> +  VOID*StatusBlock
> +  );
> +
> +
> +
> +/**
> + * EFI SCSI Pass Thru Protocol
> + */
> +EFI_STATUS SiI3132ScsiPassThru(
> +  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
> +  IN UINT8 *Target,
> +  IN UINT64 Lun,
> +  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
> +  IN EFI_EVENT  Event OPTIONAL
> +  );
> +
> +EFI_STATUS SiI3132GetNextTargetLun(
> +  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
> +  IN OUT UINT8 **Target,
> +  IN OUT UINT64 *Lun
> +);
> +
> +EFI_STATUS SiI3132GetNextTargetLun2(
> +  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL *This,
> +  IN UINT8 *Target,
> +  IN UINT64 Lun,
> +  IN OUT EFI_DEVICE_PATH_PROTOCOL **DevicePath
> +  );
> +
> +EFI_STATUS SiI3132ScsiBuildDevicePath(
> +  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This,
> +  IN UINT8 *Target,
> 

Re: [edk2] [PATCH v2 3/4] ArmPkg/ArmDmaLib: clean up abuse of device address

[Ryan Harkin]

On 15 November 2016 at 09:19, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 14 November 2016 at 16:16, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> On Sat, Nov 12, 2016 at 02:02:27PM +0100, Ard Biesheuvel wrote:
>>> In preparation of adding support to ArmDmalib for DMA bus masters whose
>>> view of memory is offset by a constant compared to the CPU's view, clean
>>> up some abuse of the device address.
>>>
>>> The device address is not defined in terms of the CPU's address space,
>>> and so it should not be used in CopyMem () or cache maintenance operations
>>> that require a valid mapping. This not only applies to the above use case,
>>> but also to the DebugUncachedMemoryAllocationLib that unmaps the
>>> primary, cached mapping of an allocation, and returns a host address
>>> which is an uncached alias offset by a constant.
>>>
>>> Since we should never access the device address from the CPU, there is
>>> no need to record it in the MAPINFO struct. Instead, record the buffer
>>> address in case of double buffering, since we do need to copy the contents
>>> (in case of a bus master write) and free the buffer (in all cases) when
>>> DmaUnmap() is called.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>
>> For the fix itself:
>> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>>
>> However, can we wait for a few Tested-by:s to ensure this fix does not
>> reveal any companion bugs?
>>
>
> Perhaps, yes.
>
> In case anyone is up to doing that, please find the branch here
> https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/log/?h=armdmalib-offset
>

I tested your branch on the usual victims (R0/1/2, FVP Foundation &
AEMv8 and TC2) and they all work fine for me.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


> However, given that the split CPU/bus master view is introduced in the
> next patch, the only use case where the device address differs from
> the host address is when using the DebugUncachedMemoryAllocationLib,
> which is currently broken AFAICT (it attempts to unmap the linear
> mapping of the allocation by setting the memory attributes to '0',
> which triggers an assert in the ArmPkg MMU code)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 00/11] enhance MMC

[Ryan Harkin]

Hi Haojian,

I've tested your v4 series.

On 8 November 2016 at 15:21, Haojian Zhuang  wrote:
> v4:
>   * Fix PL180 hang in some cases. Since the proper variable length
> isn't set for CMD6 & ACMD51.
>
> v3:
>   * Fix PL180 hang because of CMD6 & ACMD51 not supported.
>
> v2:
>   * Fix print error with missing parameter.
>   * Change CMD51 to ACMD51.
>   * Add the protection after CMD55 for SD. If there's no
> response of CMD55, skip to send ACMD51.
>
> v1:
>   * Wait OCR busy bit free according to eMMC spec.
>   * Define ECSD structure.
>   * Add interface to set IO bus width and speed.
>   * Support to access multiple blocks.
>
> Haojian Zhuang (11):
>   MmcDxe: wait OCR busy bit free
>   MmcDxe: move ECSD into CardInfo structure
>   MmcDxe: add SPEC_VERS field in CSD structure
>   MmcDxe: add interface to change io width and speed
>   MmcDxe: declare ECSD structure
>   MmcDxe: set io bus width before reading EXTCSD
>   MmcDxe: Fix uninitialized mediaid for SD
>   MmcDxe: set iospeed and bus width in SD stack

After this patch is applied, TC2 no longer boots.

I can see this patch add support for MMC_ACMD51

>   MmcDxe: expand to support multiple blocks
>   PL180: update for indentifying SD
>   PL180: set variable length for CMD6 and ACMD51

I can see this patch is fixing the data size for ACMD51. And it is
only when this patch is applied that it starts to boot again.

So I think they still need to be stacked or squashed differently so
they are bisect-able, sorry.


>
>  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c|  29 +-
>  EmbeddedPkg/Include/Protocol/MmcHost.h   |  29 ++
>  EmbeddedPkg/Universal/MmcDxe/Mmc.h   | 176 ++-
>  EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c| 175 +++
>  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 354 
> +--
>  5 files changed, 669 insertions(+), 94 deletions(-)
>
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] PL180: set variable length for CMD6 and ACMD51

[Ryan Harkin]

Hi Haojian,

On 7 November 2016 at 15:49, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
> Since CMD6 & ACMD51 needs to read data size less than 512, proper
> variable length should be set.
>

Yay!  Thanks for working out what the problem was with TC2.  I've
tested this patch on top of your v3 series of your MMC patches and
everything seems to be working now.

I tested in release and debug builds too.


> Signed-off-by: Haojian Zhuang <haojian.zhu...@linaro.org>

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

However, I have a minor comment about this patch below...

I would like to see a series pushed that includes this patch in the
correct place so that TC2 does not break at all during the series.  At
the moment, TC2 will not be bisect-able if this patch is pushed after
the series.


> ---
>  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c 
> b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
> index 4d839e7..c3e8830 100644
> --- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
> +++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
> @@ -63,7 +63,7 @@ MciIsReadOnly (
>return (MmioRead32 (FixedPcdGet32 (PcdPL180SysMciRegAddress)) & 
> SYS_MCI_WPROT);
>  }
>
> -#if 0
> +#if 1

I think it would be better to remove the "#if 0" rather than change it
to 1.  Leif, do you have a stronger opinion about it either way?


>  //Note: This function has been commented out because it is not used yet.

This comment is no longer correct and should be removed.


>  //  This function could be used to remove the hardcoded BlockLen used
>  //  in MciPrepareDataPath
> @@ -129,12 +129,20 @@ MciSendCommand (
>} else if (MmcCmd == MMC_CMD6) {
>  MmioWrite32 (MCI_DATA_TIMER_REG, 0xFFF);
>  MmioWrite32 (MCI_DATA_LENGTH_REG, 64);
> +#ifndef USE_STREAM

Seeing this #ifdef made me look at other uses of USE_STREAM in the
file.  If you are going to enable a variable size BlockLen, do you
need to do it in the other places where the USE_STREAM occurs?

But I guess these lines make the whole USE_STREAM thing look like a
bad idea anyway:

// Untested ...
//#define USE_STREAM

;-)


> +MmioWrite32 (MCI_DATA_CTL_REG, MCI_DATACTL_ENABLE | 
> MCI_DATACTL_CARD_TO_CONT | GetPow2BlockLen (64));
> +#else
>  MmioWrite32 (MCI_DATA_CTL_REG, MCI_DATACTL_ENABLE | 
> MCI_DATACTL_CARD_TO_CONT | MCI_DATACTL_STREAM_TRANS);
> +#endif
>} else if (MmcCmd == MMC_ACMD51) {
>  MmioWrite32 (MCI_DATA_TIMER_REG, 0xFFF);
>  /* SCR register is 8 bytes long. */
>  MmioWrite32 (MCI_DATA_LENGTH_REG, 8);
> +#ifndef USE_STREAM
> +MmioWrite32 (MCI_DATA_CTL_REG, MCI_DATACTL_ENABLE | 
> MCI_DATACTL_CARD_TO_CONT | GetPow2BlockLen (8));
> +#else
>  MmioWrite32 (MCI_DATA_CTL_REG, MCI_DATACTL_ENABLE | 
> MCI_DATACTL_CARD_TO_CONT | MCI_DATACTL_STREAM_TRANS);
> +#endif
>}
>
>// Create Command for PL180
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SMBIOS/DMI data creation

[Ryan Harkin]

On 4 November 2016 at 07:22, Shaveta Leekha  wrote:
> Hi,
>
> I was adding SMBIOS DMI data in UEFI for our ARM64 platform.
> One patch that I referred is of ARM JUNO platform:
> ArmPlatformPkg/ArmJunoPkg: Create SMBIOS/DMI data   for Juno
>
> In it, almost all SMBIOS table entries/structures are populated statically 
> with information.
> Is it preliminary support?

I think so.


> can we fill most of the information like:
> Memory module information
> Cache related info etc by reading from registers or from system at 
> run time instead of filling it statically?
>

I think that would be the nicest way to do it.  Static configuration
isn't ideal, IMO.  But on a board like Juno, where the config isn't
likely to change, I think it's acceptable to hard code it; or at
least, it's better than doing nothing.

> Any views?
>
> Thanks and Regards,
> Shaveta
>
> ___
> 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] ArmPkg/Library/ArmDmaLib: Deallocate Map buffer in case of error

[Ryan Harkin]

On 1 November 2016 at 17:58, Ryan Harkin <ryan.har...@linaro.org> wrote:
> Hi Leif,
>
> Is this waiting for a Tested-by or something else?
>

Either way, I tested it on Juno R0/1/2 while I was testing the MAC
address change...


> Cheers,
> Ryan.
>
> On 23 September 2016 at 09:00, Ard Biesheuvel <ard.biesheu...@linaro.org> 
> wrote:
>> On 22 September 2016 at 23:37, Daniil Egranov <daniil.egra...@arm.com> wrote:
>>> The patch is fixing memory leak in case of errors.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>>
>> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>

Tested-by; Ryan Harkin <ryan.har...@linaro.org>

>>> ---
>>>  ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
>>> b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>>> index d48d6ff..e0006c0 100644
>>> --- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>>> +++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>>> @@ -90,14 +90,13 @@ DmaMap (
>>>  return  EFI_OUT_OF_RESOURCES;
>>>}
>>>
>>> -  *Mapping = Map;
>>> -
>>>if UINTN)HostAddress & (gCacheAlignment - 1)) != 0) ||
>>>((*NumberOfBytes & (gCacheAlignment - 1)) != 0)) {
>>>
>>>  // Get the cacheability of the region
>>>  Status = gDS->GetMemorySpaceDescriptor (*DeviceAddress, 
>>> );
>>>  if (EFI_ERROR(Status)) {
>>> +  FreePool(Map);
>>>return Status;
>>>  }
>>>
>>> @@ -112,6 +111,7 @@ DmaMap (
>>>"%a: Operation type 'MapOperationBusMasterCommonBuffer' is only 
>>> supported\n"
>>>"on memory regions that were allocated using DmaAllocateBuffer 
>>> ()\n",
>>>__FUNCTION__));
>>> +FreePool(Map);
>>>  return EFI_UNSUPPORTED;
>>>}
>>>
>>> @@ -122,6 +122,7 @@ DmaMap (
>>>Map->DoubleBuffer  = TRUE;
>>>Status = DmaAllocateBuffer (EfiBootServicesData, EFI_SIZE_TO_PAGES 
>>> (*NumberOfBytes), );
>>>if (EFI_ERROR (Status)) {
>>> +FreePool(Map);
>>>  return Status;
>>>}
>>>
>>> @@ -162,6 +163,8 @@ DmaMap (
>>>Map->NumberOfBytes = *NumberOfBytes;
>>>Map->Operation = Operation;
>>>
>>> +  *Mapping = Map;
>>> +
>>>return EFI_SUCCESS;
>>>  }
>>>
>>> --
>>> 2.7.4
>>>
>>> ___
>>> 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] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Set Marvell Yukon MAC address

[Ryan Harkin]

On 1 November 2016 at 21:05, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Tue, Nov 01, 2016 at 05:55:11PM +0000, Ryan Harkin wrote:
>> Hi Daniil,
>>
>> While looking for another patch, I found this on the maillist...
>>
>> On 6 October 2016 at 02:42, Daniil Egranov <daniil.egra...@arm.com> wrote:
>> > The patch reads a valid MAC address form the Juno IOFPGA registers
>> > and pushes it into onboard Marvell Yukon NIC.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>

Tested on Juno R0/1/2.

Tested-by; Ryan Harkin <ryan.har...@linaro.org>


>> > ---
>> >  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 141 
>> > +
>> >  .../Drivers/ArmJunoDxe/ArmJunoDxeInternal.h|  12 ++
>> >  2 files changed, 153 insertions(+)
>> >
>> > diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
>> > b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> > index b97f044..0c5fbd0 100644
>> > --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> > +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
>> > @@ -17,6 +17,8 @@
>> >
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> >
>> >  #include 
>> >  #include 
>> > @@ -68,6 +70,142 @@ STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
>> > mPciRootComplexDevicePath = {
>> >
>> >  EFI_EVENT mAcpiRegistration = NULL;
>> >
>> > +UINT32 SwapUINT32(UINT32 value)
>> > +{
>> > +  value = ((value << 8) & 0xFF00FF00 ) | ((value >> 8) & 0xFF00FF );
>> > +  return (value << 16) | (value >> 16);
>> > +}
>> > +
>> > +/**
>> > +  The function reads MAC address from Juno IOFPGA registers and writes it
>> > +  into Marvell Yukon NIC.
>> > +**/
>> > +STATIC
>> > +EFI_STATUS
>> > +ArmJunoSetNetworkMAC()
>> > +{
>> > +
>> > +  EFI_STATUS  Status;
>> > +  UINTN   HandleCount;
>> > +  EFI_HANDLE  *HandleBuffer;
>> > +  UINTN   HIndex;
>> > +  EFI_PCI_IO_PROTOCOL*PciIo;
>> > +  UINT64  PciID;
>> > +  UINT32  MacHigh;
>> > +  UINT32  MacLow;
>> > +  UINT32  PciRegBase;
>> > +  UINT64  OldPciAttributes;
>> > +  UINT64  AttrSupports;
>> > +  UINT8   *PciBarAttributes;
>> > +
>> > +  Status = gBS->LocateHandleBuffer (ByProtocol,
>> > +,
>> > +NULL, , );
>> > +
>> > +  if (!EFI_ERROR (Status)) {
>> > +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
>> > +  Status = gBS->OpenProtocol (
>> > +  HandleBuffer[HIndex],
>> > +  ,
>> > +  (VOID **) ,
>> > +  NULL,
>> > +  NULL,
>> > +  EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>> > +
>> > +  if (EFI_ERROR (Status)) {
>> > +continue;
>> > +  }
>> > +
>> > +  Status = PciIo->Pci.Read (
>> > +PciIo,
>> > +EfiPciIoWidthUint32,
>> > +PCI_VENDOR_ID_OFFSET,
>> > +1,
>> > +
>> > +);
>> > +
>> > +  if (EFI_ERROR (Status)) {
>> > +continue;
>> > +  }
>> > +
>> > +  if ((PciID & 0x) == JUNO_MARVELL_YUKON_ID) {
>> > +
>> > +// Read MAC address from IOFPGA
>> > +MacHigh= MmioRead32 (ARM_JUNO_SYS_PCIGBE_H);
>> > +MacLow = MmioRead32 (ARM_JUNO_SYS_PCIGBE_L);
>> > +
>> > +Status = PciIo->Attributes (
>> > +  PciIo,
>> > +  EfiPciIoAttributeOperationGet,
>> > +  0,
>> > +  
>> > +  );
>> > +
>> > +if (EFI_ERROR (Status)) {
>> > +  conti

Re: [edk2] [PATCH] ArmPkg/Library/ArmDmaLib: Deallocate Map buffer in case of error

[Ryan Harkin]

Hi Leif,

Is this waiting for a Tested-by or something else?

Cheers,
Ryan.

On 23 September 2016 at 09:00, Ard Biesheuvel  wrote:
> On 22 September 2016 at 23:37, Daniil Egranov  wrote:
>> The patch is fixing memory leak in case of errors.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Daniil Egranov 
>
> Reviewed-by: Ard Biesheuvel 
>
>> ---
>>  ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
>> b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>> index d48d6ff..e0006c0 100644
>> --- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>> +++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
>> @@ -90,14 +90,13 @@ DmaMap (
>>  return  EFI_OUT_OF_RESOURCES;
>>}
>>
>> -  *Mapping = Map;
>> -
>>if UINTN)HostAddress & (gCacheAlignment - 1)) != 0) ||
>>((*NumberOfBytes & (gCacheAlignment - 1)) != 0)) {
>>
>>  // Get the cacheability of the region
>>  Status = gDS->GetMemorySpaceDescriptor (*DeviceAddress, );
>>  if (EFI_ERROR(Status)) {
>> +  FreePool(Map);
>>return Status;
>>  }
>>
>> @@ -112,6 +111,7 @@ DmaMap (
>>"%a: Operation type 'MapOperationBusMasterCommonBuffer' is only 
>> supported\n"
>>"on memory regions that were allocated using DmaAllocateBuffer 
>> ()\n",
>>__FUNCTION__));
>> +FreePool(Map);
>>  return EFI_UNSUPPORTED;
>>}
>>
>> @@ -122,6 +122,7 @@ DmaMap (
>>Map->DoubleBuffer  = TRUE;
>>Status = DmaAllocateBuffer (EfiBootServicesData, EFI_SIZE_TO_PAGES 
>> (*NumberOfBytes), );
>>if (EFI_ERROR (Status)) {
>> +FreePool(Map);
>>  return Status;
>>}
>>
>> @@ -162,6 +163,8 @@ DmaMap (
>>Map->NumberOfBytes = *NumberOfBytes;
>>Map->Operation = Operation;
>>
>> +  *Mapping = Map;
>> +
>>return EFI_SUCCESS;
>>  }
>>
>> --
>> 2.7.4
>>
>> ___
>> 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] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Set Marvell Yukon MAC address

[Ryan Harkin]

Hi Daniil,

While looking for another patch, I found this on the maillist...

On 6 October 2016 at 02:42, Daniil Egranov  wrote:
> The patch reads a valid MAC address form the Juno IOFPGA registers
> and pushes it into onboard Marvell Yukon NIC.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daniil Egranov 
> ---
>  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 141 
> +
>  .../Drivers/ArmJunoDxe/ArmJunoDxeInternal.h|  12 ++
>  2 files changed, 153 insertions(+)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> index b97f044..0c5fbd0 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> @@ -17,6 +17,8 @@
>
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> @@ -68,6 +70,142 @@ STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
> mPciRootComplexDevicePath = {
>
>  EFI_EVENT mAcpiRegistration = NULL;
>
> +UINT32 SwapUINT32(UINT32 value)
> +{
> +  value = ((value << 8) & 0xFF00FF00 ) | ((value >> 8) & 0xFF00FF );
> +  return (value << 16) | (value >> 16);
> +}
> +
> +/**
> +  The function reads MAC address from Juno IOFPGA registers and writes it
> +  into Marvell Yukon NIC.
> +**/
> +STATIC
> +EFI_STATUS
> +ArmJunoSetNetworkMAC()
> +{
> +
> +  EFI_STATUS  Status;
> +  UINTN   HandleCount;
> +  EFI_HANDLE  *HandleBuffer;
> +  UINTN   HIndex;
> +  EFI_PCI_IO_PROTOCOL*PciIo;
> +  UINT64  PciID;
> +  UINT32  MacHigh;
> +  UINT32  MacLow;
> +  UINT32  PciRegBase;
> +  UINT64  OldPciAttributes;
> +  UINT64  AttrSupports;
> +  UINT8   *PciBarAttributes;
> +
> +  Status = gBS->LocateHandleBuffer (ByProtocol,
> +,
> +NULL, , );
> +
> +  if (!EFI_ERROR (Status)) {
> +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
> +  Status = gBS->OpenProtocol (
> +  HandleBuffer[HIndex],
> +  ,
> +  (VOID **) ,
> +  NULL,
> +  NULL,
> +  EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> +
> +  if (EFI_ERROR (Status)) {
> +continue;
> +  }
> +
> +  Status = PciIo->Pci.Read (
> +PciIo,
> +EfiPciIoWidthUint32,
> +PCI_VENDOR_ID_OFFSET,
> +1,
> +
> +);
> +
> +  if (EFI_ERROR (Status)) {
> +continue;
> +  }
> +
> +  if ((PciID & 0x) == JUNO_MARVELL_YUKON_ID) {
> +
> +// Read MAC address from IOFPGA
> +MacHigh= MmioRead32 (ARM_JUNO_SYS_PCIGBE_H);
> +MacLow = MmioRead32 (ARM_JUNO_SYS_PCIGBE_L);
> +
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationGet,
> +  0,
> +  
> +  );
> +
> +if (EFI_ERROR (Status)) {
> +  continue;
> +}
> +
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationSupported,
> +  0,
> +  
> +  );
> +
> +if (!EFI_ERROR (Status)) {
> +  AttrSupports &= EFI_PCI_DEVICE_ENABLE;
> +  Status = PciIo->Attributes (
> +PciIo,
> +EfiPciIoAttributeOperationEnable,
> +AttrSupports,
> +NULL
> +);
> +
> +  Status = PciIo->GetBarAttributes (PciIo, 0, , 
> (VOID**));
> +  if (!EFI_ERROR (Status) && (((EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR 
> *)PciBarAttributes)->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR)) {
> +if (((EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR 
> *)PciBarAttributes)->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) {
> +  if (!(((EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR 
> *)PciBarAttributes)->SpecificFlag & ACPI_SPECFLAG_PREFETCHABLE)) {
> +PciRegBase = ((EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR 
> *)PciBarAttributes)->AddrRangeMin;
> +
> +// Clear Software Reset
> +MmioWrite16 (PciRegBase + R_CONTROL_STATUS, CS_RESET_CLR);
> +
> +// Convert to Marvell MAC Address register format
> +MacHigh = SwapUINT32 ((MacHigh & 0x) << 16 |
> + (MacLow & 0x) >> 16);
> +MacLow = SwapUINT32 (MacLow) >> 16;
> +
> +// Set MAC Address
> +MmioWrite8 (PciRegBase + R_TST_CTRL_1, TST_CFG_WRITE_ENABLE);
> +

Re: [edk2] [PATCH v2 0/6] ArmPkg: eliminate calls to deprecated functions

[Ryan Harkin]

On 26 October 2016 at 13:21, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 26 October 2016 at 13:13, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> On 26 October 2016 at 13:11, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>> Hi Ard,
>>>
>>> You don't have my Tested-by tags in all of the v2 patches.  Do I need
>>> to retest?  I thought they changes were trivial, but I'm happy to
>>> retest if it helps.
>>>
>>
>> If you don't mind, yes please. Given that they are changes that look
>> trivial on the face of it but could potentially cause hard to diagnose
>> problems if implemented incorrectly, I thought keeping the T-b was
>> perhaps not appropriate in this case.
>
> No problem, I'll do it now before I forget.
>

As before, tested on Juno R0/1/2, TC2 and FVP AEMv8 and Foundation models.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


>
>> ___
>> 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] ArmPlatformPkg: remove ARM BDS

[Ryan Harkin]

On 25 October 2016 at 18:16, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> This is no longer used, and does not belong in a reference code base,
> so remove it.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>

I tested this along with the series to move to the generic BDS and the
additional Juno patch.  Tested on Juno R0/1/2, TC2 and FVP AEMv8 and
Foundation models.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

And it's simple enough that I can understand what it does:

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
>
> Note that the OpenPlatformPkg version of Beagle will still need to be
> brought in line with the EDK2 version (after switching to the generic
> BDS)
>
>  ArmPlatformPkg/Bds/Bds.c   |  561 -
>  ArmPlatformPkg/Bds/Bds.inf |   90 --
>  ArmPlatformPkg/Bds/BdsHelper.c |  465 
>  ArmPlatformPkg/Bds/BdsInternal.h   |  277 -
>  ArmPlatformPkg/Bds/BootLinux.c |  124 --
>  ArmPlatformPkg/Bds/BootMenu.c  | 1101 --
>  ArmPlatformPkg/Bds/BootOption.c|  316 --
>  ArmPlatformPkg/Bds/BootOptionSupport.c | 1195 
>  8 files changed, 4129 deletions(-)
>
> diff --git a/ArmPlatformPkg/Bds/Bds.c b/ArmPlatformPkg/Bds/Bds.c
> deleted file mode 100644
> index 4cea3cd531bb..
> --- a/ArmPlatformPkg/Bds/Bds.c
> +++ /dev/null
> @@ -1,561 +0,0 @@
> -/** @file
> -*
> -*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
> -*
> -*  This program and the accompanying materials
> -*  are licensed and made available under the terms and conditions of the BSD 
> License
> -*  which accompanies this distribution.  The full text of the license may be 
> found at
> -*  http://opensource.org/licenses/bsd-license.php
> -*
> -*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -*
> -**/
> -
> -#include "BdsInternal.h"
> -
> -#include 
> -#include 
> -
> -#include 
> -
> -#include 
> -
> -#define EFI_SET_TIMER_TO_SECOND   1000
> -
> -STATIC
> -EFI_STATUS
> -GetConsoleDevicePathFromVariable (
> -  IN  CHAR16* ConsoleVarName,
> -  IN  CHAR16* DefaultConsolePaths,
> -  OUT EFI_DEVICE_PATH**   DevicePaths
> -  )
> -{
> -  EFI_STATUSStatus;
> -  UINTN Size;
> -  EFI_DEVICE_PATH_PROTOCOL* DevicePathInstances;
> -  EFI_DEVICE_PATH_PROTOCOL* DevicePathInstance;
> -  CHAR16*   DevicePathStr;
> -  CHAR16*   NextDevicePathStr;
> -  EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL  *EfiDevicePathFromTextProtocol;
> -
> -  Status = GetGlobalEnvironmentVariable (ConsoleVarName, NULL, NULL, 
> (VOID**));
> -  if (EFI_ERROR(Status)) {
> -// In case no default console device path has been defined we assume a 
> driver handles the console (eg: SimpleTextInOutSerial)
> -if ((DefaultConsolePaths == NULL) || (DefaultConsolePaths[0] == L'\0')) {
> -  *DevicePaths = NULL;
> -  return EFI_SUCCESS;
> -}
> -
> -Status = gBS->LocateProtocol (, NULL, 
> (VOID **));
> -ASSERT_EFI_ERROR(Status);
> -
> -DevicePathInstances = NULL;
> -
> -// Extract the Device Path instances from the multi-device path string
> -while ((DefaultConsolePaths != NULL) && (DefaultConsolePaths[0] != 
> L'\0')) {
> -  NextDevicePathStr = StrStr (DefaultConsolePaths, L";");
> -  if (NextDevicePathStr == NULL) {
> -DevicePathStr = DefaultConsolePaths;
> -DefaultConsolePaths = NULL;
> -  } else {
> -DevicePathStr = (CHAR16*)AllocateCopyPool ((NextDevicePathStr - 
> DefaultConsolePaths + 1) * sizeof(CHAR16), DefaultConsolePaths);
> -*(DevicePathStr + (NextDevicePathStr - DefaultConsolePaths)) = L'\0';
> -DefaultConsolePaths = NextDevicePathStr;
> -if (DefaultConsolePaths[0] == L';') {
> -  DefaultConsolePaths++;
> -}
> -  }
> -
> -  DevicePathInstance = 
> EfiDevicePathFromTextProtocol->ConvertTextToDevicePath (DevicePathStr);
> -  ASSERT(DevicePathInstance != NULL);
> -  DevicePathInstances = AppendDevicePathInstance (DevicePathInstances, 
> DevicePathInstance);
> -
> -  if (NextDevicePathStr != NULL) {
> -FreePool (DevicePathStr);
> -  }
> -  FreePool (DevicePathInstance);
> -}
> -
> -// Set the environment variable with this device path multi-instances
> -Size = GetDevicePathSiz

Re: [edk2] [PATCH v2 4/6] ArmPkg/SemihostFs: eliminate calls to deprecated string functions

[Ryan Harkin]

On 26 October 2016 at 12:55, Laszlo Ersek  wrote:
> On 10/26/16 10:17, Ard Biesheuvel wrote:
>> Remove calls to deprecated string functions like AsciiStrCpy() and
>> UnicodeStrToAsciiStr()
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c | 20 
>>  1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c 
>> b/ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c
>> index 6efdad9ebcce..cf94ecd5d56f 100644
>> --- a/ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c
>> +++ b/ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c
>> @@ -207,11 +207,12 @@ FileOpen (
>>  return EFI_WRITE_PROTECTED;
>>}
>>
>> -  AsciiFileName = AllocatePool (StrLen (FileName) + 1);
>> +  Length = StrLen (FileName) + 1;
>> +  AsciiFileName = AllocatePool (Length);
>>if (AsciiFileName == NULL) {
>>  return EFI_OUT_OF_RESOURCES;
>>}
>> -  UnicodeStrToAsciiStr (FileName, AsciiFileName);
>> +  UnicodeStrToAsciiStrS (FileName, AsciiFileName, Length);
>>
>>// Opening '/', '\', '.', or the NULL pathname is trying to open the root 
>> directory
>>if ((AsciiStrCmp (AsciiFileName, "\\") == 0) ||
>> @@ -463,7 +464,7 @@ FileDelete (
>>  NameSize = AsciiStrLen (Fcb->FileName);
>>  FileName = AllocatePool (NameSize + 1);
>>
>> -AsciiStrCpy (FileName, Fcb->FileName);
>> +AsciiStrCpyS (FileName, NameSize + 1, Fcb->FileName);
>>
>>  // Close the file if it's open.  Disregard return status,
>>  // since it might give an error if the file isn't open.
>> @@ -828,8 +829,10 @@ GetFilesystemInfo (
>>EFI_FILE_SYSTEM_INFO  *Info;
>>EFI_STATUSStatus;
>>UINTN ResultSize;
>> +  UINTN StringSize;
>>
>> -  ResultSize = SIZE_OF_EFI_FILE_SYSTEM_INFO + StrSize (mSemihostFsLabel);
>> +  StringSize = StrSize (mSemihostFsLabel);
>> +  ResultSize = SIZE_OF_EFI_FILE_SYSTEM_INFO + StringSize;
>>
>>if (*BufferSize >= ResultSize) {
>>  ZeroMem (Buffer, ResultSize);
>> @@ -843,7 +846,7 @@ GetFilesystemInfo (
>>  Info->FreeSpace  = 0;
>>  Info->BlockSize  = 0;
>>
>> -StrCpy (Info->VolumeLabel, mSemihostFsLabel);
>> +CopyMem (Info->VolumeLabel, mSemihostFsLabel, StringSize);
>>} else {
>>  Status = EFI_BUFFER_TOO_SMALL;
>>}
>> @@ -903,7 +906,7 @@ FileGetInfo (
>>  ResultSize = StrSize (mSemihostFsLabel);
>>
>>  if (*BufferSize >= ResultSize) {
>> -  StrCpy (Buffer, mSemihostFsLabel);
>> +  CopyMem (Buffer, mSemihostFsLabel, *BufferSize);
>
> This is still wrong; here *BufferSize is the size of the recipient
> buffer, passed in from the caller. As written, the code can overrun the
> *source* buffer. Please use
>
>   CopyMem (Buffer, mSemihostFsLabel, ResultSize);
>
> instead.
>
> With that update:
>
> Reviewed-by: Laszlo Ersek 
>

I'll apply this update locally before I test the v2 series.


> Thanks
> Laszlo
>
>>Status = EFI_SUCCESS;
>>  } else {
>>Status = EFI_BUFFER_TOO_SMALL;
>> @@ -963,11 +966,12 @@ SetFileInfo (
>>  return EFI_ACCESS_DENIED;
>>}
>>
>> -  AsciiFileName = AllocatePool (StrLen (Info->FileName) + 1);
>> +  Length = StrLen (Info->FileName) + 1;
>> +  AsciiFileName = AllocatePool (Length);
>>if (AsciiFileName == NULL) {
>>  return EFI_OUT_OF_RESOURCES;
>>}
>> -  UnicodeStrToAsciiStr (Info->FileName, AsciiFileName);
>> +  UnicodeStrToAsciiStrS (Info->FileName, AsciiFileName, Length);
>>
>>FileSizeIsDifferent = (Info->FileSize != Fcb->Info.FileSize);
>>FileNameIsDifferent = (AsciiStrCmp (AsciiFileName, Fcb->FileName) != 0);
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/6] ArmPkg: eliminate calls to deprecated functions

[Ryan Harkin]

On 26 October 2016 at 13:13, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 26 October 2016 at 13:11, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> Hi Ard,
>>
>> You don't have my Tested-by tags in all of the v2 patches.  Do I need
>> to retest?  I thought they changes were trivial, but I'm happy to
>> retest if it helps.
>>
>
> If you don't mind, yes please. Given that they are changes that look
> trivial on the face of it but could potentially cause hard to diagnose
> problems if implemented incorrectly, I thought keeping the T-b was
> perhaps not appropriate in this case.

No problem, I'll do it now before I forget.


> ___
> 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 v2 0/6] ArmPkg: eliminate calls to deprecated functions

[Ryan Harkin]

Hi Ard,

You don't have my Tested-by tags in all of the v2 patches.  Do I need
to retest?  I thought they changes were trivial, but I'm happy to
retest if it helps.

Cheers,
Ryan.

On 26 October 2016 at 09:17, Ard Biesheuvel  wrote:
> This series prepares ArmPkg for building with the preprocess symbol
> DISABLE_NEW_DEPRECATED_INTERFACES defined, by adding missing components
> to ArmPkg (#1), fixing broken code or code that relies on deprecated
> functionality (#2 - #5), and finally adds -DDISABLE_NEW_DEPRECATED_INTERFACES
> to the CC flags for all build types, toolchains and architectures.
>
> v2:
> - incorporate feedback from Laszlo
> - add tags from Ryan, Leif and Laszlo
>
> Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=164
>
> Ard Biesheuvel (6):
>   ArmPkg: add missing components
>   ArmPkg/ArmCortexA9Lib RVCT: remove incompatible GCC include
>   ArmPkg/LinuxLoader: eliminate calls to deprecated string functions
>   ArmPkg/SemihostFs: eliminate calls to deprecated string functions
>   ArmPkg/BdsLib: eliminate calls to deprecated string functions
>   ArmPkg: enable -DDISABLE_NEW_DEPRECATED_INTERFACES
>
>  ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c|  2 +-
>  ArmPkg/Application/LinuxLoader/LinuxLoader.c  |  6 --
>  ArmPkg/ArmPkg.dsc | 13 
> +
>  ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm |  4 
>  ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c | 20 
> 
>  ArmPkg/Library/BdsLib/BdsFilePath.c   |  8 +---
>  6 files changed, 35 insertions(+), 18 deletions(-)
>
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/6] ArmPkg: eliminate calls to deprecated functions

[Ryan Harkin]

On 24 October 2016 at 17:06, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> This series prepares ArmPkg for building with the preprocess symbol
> DISABLE_NEW_DEPRECATED_INTERFACES defined, by adding missing components
> to ArmPkg (#1), fixing broken code or code that relies on deprecated
> functionality (#2 - #5), and finally adds -DDISABLE_NEW_DEPRECATED_INTERFACES
> to the CC flags for all build types, toolchains and architectures.
>
> Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=164
>
> Ard Biesheuvel (6):
>   ArmPkg: add missing components
>   ArmPkg/ArmCortexA9Lib RVCT: remove incompatible GCC include
>   ArmPkg/LinuxLoader: eliminate calls to deprecated string functions
>   ArmPkg/SemihostFs: eliminate calls to deprecated string functions
>   ArmPkg/BdsLib: eliminate calls to deprecated string functions
>   ArmPkg: enable -DDISABLE_NEW_DEPRECATED_INTERFACES
>

I tested the series on FVP AEMv8 & Foundation, TC2 and Juno R0/1/2:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


>  ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c|  2 +-
>  ArmPkg/Application/LinuxLoader/LinuxLoader.c  |  6 --
>  ArmPkg/ArmPkg.dsc | 13 
> +
>  ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm |  4 
>  ArmPkg/Filesystem/SemihostFs/Arm/SemihostFs.c | 20 
> 
>  ArmPkg/Library/BdsLib/BdsFilePath.c   |  8 +---
>  6 files changed, 35 insertions(+), 18 deletions(-)
>
> --
> 2.7.4
>
> ___
> 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 3/6] ArmPkg/LinuxLoader: eliminate calls to deprecated string functions

[Ryan Harkin]

On 25 October 2016 at 11:56, Ard Biesheuvel  wrote:
> On 25 October 2016 at 11:53, Laszlo Ersek  wrote:
>> On 10/24/16 18:06, Ard Biesheuvel wrote:
>>> Remove calls to deprecated string functions like AsciiStrCpy() and
>>> UnicodeStrToAsciiStr()
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c | 2 +-
>>>  ArmPkg/Application/LinuxLoader/LinuxLoader.c   | 6 --
>>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c 
>>> b/ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c
>>> index fd7ee9c8624d..0b3e2489c758 100644
>>> --- a/ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c
>>> +++ b/ArmPkg/Application/LinuxLoader/Arm/LinuxAtag.c
>>> @@ -72,7 +72,7 @@ SetupCmdlineTag (
>>>  mLinuxKernelCurrentAtag->header.type = ATAG_CMDLINE;
>>>
>>>  /* place CommandLine into tag */
>>> -AsciiStrCpy (mLinuxKernelCurrentAtag->body.cmdline_tag.cmdline, 
>>> CmdLine);
>>> +AsciiStrCpyS (mLinuxKernelCurrentAtag->body.cmdline_tag.cmdline, 
>>> LineLength, CmdLine);
>>>
>>>  // move pointer to next tag
>>>  mLinuxKernelCurrentAtag = next_tag_address (mLinuxKernelCurrentAtag);
>>
>> Apparently nothing in this file checks if the tags being added still
>> actually fit in the preallocated space (which is EFI_SIZE_TO_PAGES
>> (ATAG_MAX_SIZE)). The change does preserve the previous behavior ("copy
>> the full string").
>>
>
> The LinuxLoader is an unmaintained piece of junk, and will be removed
> as soon as we can.

Who still uses it? Hikey?


> I did notice that none of these ATAG functions
> check whether the allocation as a whole is not overrun, but fixing
> /that/ goes way beyond what we're willing to do in terms of
> maintenance on deprecated code.
>
>>> diff --git a/ArmPkg/Application/LinuxLoader/LinuxLoader.c 
>>> b/ArmPkg/Application/LinuxLoader/LinuxLoader.c
>>> index 70b960b66f0e..76697c3a8c9d 100644
>>> --- a/ArmPkg/Application/LinuxLoader/LinuxLoader.c
>>> +++ b/ArmPkg/Application/LinuxLoader/LinuxLoader.c
>>> @@ -61,6 +61,7 @@ LinuxLoaderEntryPoint (
>>>LIST_ENTRY  *ResourceLink;
>>>SYSTEM_MEMORY_RESOURCE  *Resource;
>>>EFI_PHYSICAL_ADDRESSSystemMemoryBase;
>>> +  UINTN   Length;
>>>
>>>Status = gBS->LocateProtocol (
>>>,
>>> @@ -182,12 +183,13 @@ LinuxLoaderEntryPoint (
>>>}
>>>
>>>if (LinuxCommandLine != NULL) {
>>> -AsciiLinuxCommandLine = AllocatePool ((StrLen (LinuxCommandLine) + 1) 
>>> * sizeof (CHAR8));
>>> +Length = StrLen (LinuxCommandLine) + 1;
>>> +AsciiLinuxCommandLine = AllocatePool (Length);
>>>  if (AsciiLinuxCommandLine == NULL) {
>>>Status = EFI_OUT_OF_RESOURCES;
>>>goto Error;
>>>  }
>>> -UnicodeStrToAsciiStr (LinuxCommandLine, AsciiLinuxCommandLine);
>>> +UnicodeStrToAsciiStrS (LinuxCommandLine, AsciiLinuxCommandLine, 
>>> Length);
>>>}
>>>
>>>//
>>>
>>
>> I prefer to call character counts without the terminating NUL "Length",
>> and character counts with the terminating NUL "Size", but that's just a
>> personal preference. (And the rest of this code uses Length differently
>> already, for example in "LineLength" itself, near the top.)
>>
>> Reviewed-by: Laszlo Ersek 
>>
>
> Thanks,
> Ard.
> ___
> 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] ArmPlatformPkg/NorFlashDxe: eliminate void pointer arithmetic

[Ryan Harkin]

On 24 October 2016 at 14:05, Laszlo Ersek <ler...@redhat.com> wrote:
> On 10/24/16 15:01, Ard Biesheuvel wrote:
>> While most compilers happily allow arithmetic on void pointer,
>> the RVCT compiler does not, and throws the following warning for
>> NorFlashDxe:
>>
>>   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c(894,48) :
>>   error  #1254-D: arithmetic on pointer to void or function type
>>
>> Since the expression in question involves a cast from UINTN to VOID*,
>> simply add some parentheses to eliminate this warning.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>>  ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c 
>> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
>> index ca61ac5e1983..1098d9501cc7 100644
>> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
>> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
>> @@ -891,7 +891,7 @@ NorFlashRead (
>>SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY);
>>
>>// Readout the data
>> -  AlignedCopyMem (Buffer, (VOID *)StartAddress + Offset, BufferSizeInBytes);
>> +  AlignedCopyMem (Buffer, (VOID *)(StartAddress + Offset), 
>> BufferSizeInBytes);
>>
>>return EFI_SUCCESS;
>>  }
>>
>
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>

> ___
> 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] ARMPkg: Unified the GIC base address variables as 64-bit width

[Ryan Harkin]

On 24 October 2016 at 04:04, Dennis Chen  wrote:
> Since ACPI spec defines the GIC base addresses (CPU interface,
> Distributor and Redistributor*GICv3 only*) as 64-bit, so we should
> define these corresponding base address variables as 64-bit instead of
> 32-bit. This patch redefines them according to the ACPI spec.
>

Following on with Ard's comment on the earlier version, what happens
if you want to use GICv3 on a 32bit system, eg the Cortex-A32 FVP
models, which I believe [1] has GICv3?

[1] Go here and search for "gicv3"
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0834i/Chunk1955773768.html


> Contributed-under: TianoCore Contribution Agreement 1.0
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Laszlo Ersek 
> Signed-off-by: Dennis Chen 
> ---
>  ArmPkg/Drivers/ArmGic/ArmGicLib.c   | 64 ++--
>  ArmPkg/Drivers/ArmGic/ArmGicNonSecLib.c |  2 +-
>  ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c   |  4 +-
>  ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Lib.c   |  6 +-
>  ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2NonSecLib.c |  4 +-
>  ArmPkg/Include/Library/ArmGicLib.h  | 78 
> -
>  6 files changed, 79 insertions(+), 79 deletions(-)
>
> diff --git a/ArmPkg/Drivers/ArmGic/ArmGicLib.c 
> b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> index e658e9b..733488c 100644
> --- a/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> +++ b/ArmPkg/Drivers/ArmGic/ArmGicLib.c
> @@ -41,18 +41,18 @@ SourceIsSpi (
>   * @retval Base address of the associated GIC Redistributor
>   */
>  STATIC
> -UINTN
> +UINT64
>  GicGetCpuRedistributorBase (
> -  IN UINTN GicRedistributorBase,
> -  IN ARM_GIC_ARCH_REVISION Revision
> +  IN UINT64 GicRedistributorBase,
> +  IN ARM_GIC_ARCH_REVISION  Revision
>)
>  {
> -  UINTN Index;
> -  UINTN MpId;
> -  UINTN CpuAffinity;
> -  UINTN Affinity;
> -  UINTN GicRedistributorGranularity;
> -  UINTN GicCpuRedistributorBase;
> +  UINTN  Index;
> +  UINTN  MpId;
> +  UINTN  CpuAffinity;
> +  UINTN  Affinity;
> +  UINTN  GicRedistributorGranularity;
> +  UINT64 GicCpuRedistributorBase;
>
>MpId = ArmReadMpidr ();
>// Define CPU affinity as Affinity0[0:8], Affinity1[9:15], 
> Affinity2[16:23], Affinity3[24:32]
> @@ -87,7 +87,7 @@ GicGetCpuRedistributorBase (
>  UINTN
>  EFIAPI
>  ArmGicGetInterfaceIdentification (
> -  IN  INTN  GicInterruptInterfaceBase
> +  IN  UINT64 GicInterruptInterfaceBase
>)
>  {
>// Read the GIC Identification Register
> @@ -97,7 +97,7 @@ ArmGicGetInterfaceIdentification (
>  UINTN
>  EFIAPI
>  ArmGicGetMaxNumInterrupts (
> -  IN  INTN  GicDistributorBase
> +  IN  UINT64 GicDistributorBase
>)
>  {
>return 32 * ((MmioRead32 (GicDistributorBase + ARM_GIC_ICDICTR) & 0x1F) + 
> 1);
> @@ -106,10 +106,10 @@ ArmGicGetMaxNumInterrupts (
>  VOID
>  EFIAPI
>  ArmGicSendSgiTo (
> -  IN  INTN  GicDistributorBase,
> -  IN  INTN  TargetListFilter,
> -  IN  INTN  CPUTargetList,
> -  IN  INTN  SgiId
> +  IN  UINT64  GicDistributorBase,
> +  IN  UINTN   TargetListFilter,
> +  IN  UINTN   CPUTargetList,
> +  IN  UINTN   SgiId
>)
>  {
>MmioWrite32 (GicDistributorBase + ARM_GIC_ICDSGIR, ((TargetListFilter & 
> 0x3) << 24) | ((CPUTargetList & 0xFF) << 16) | SgiId);
> @@ -131,8 +131,8 @@ ArmGicSendSgiTo (
>  UINTN
>  EFIAPI
>  ArmGicAcknowledgeInterrupt (
> -  IN  UINTN  GicInterruptInterfaceBase,
> -  OUT UINTN  *InterruptId
> +  IN  UINT64  GicInterruptInterfaceBase,
> +  OUT UINTN   *InterruptId
>)
>  {
>UINTN Value;
> @@ -162,8 +162,8 @@ ArmGicAcknowledgeInterrupt (
>  VOID
>  EFIAPI
>  ArmGicEndOfInterrupt (
> -  IN  UINTN GicInterruptInterfaceBase,
> -  IN UINTN  Source
> +  IN  UINT64 GicInterruptInterfaceBase,
> +  IN  UINTN  Source
>)
>  {
>ARM_GIC_ARCH_REVISION Revision;
> @@ -181,9 +181,9 @@ ArmGicEndOfInterrupt (
>  VOID
>  EFIAPI
>  ArmGicEnableInterrupt (
> -  IN UINTN  GicDistributorBase,
> -  IN UINTN  GicRedistributorBase,
> -  IN UINTN  Source
> +  IN UINT64  GicDistributorBase,
> +  IN UINT64  GicRedistributorBase,
> +  IN UINTN   Source
>)
>  {
>UINT32RegOffset;
> @@ -216,9 +216,9 @@ ArmGicEnableInterrupt (
>  VOID
>  EFIAPI
>  ArmGicDisableInterrupt (
> -  IN UINTN  GicDistributorBase,
> -  IN UINTN  GicRedistributorBase,
> -  IN UINTN  Source
> +  IN UINT64  GicDistributorBase,
> +  IN UINT64  GicRedistributorBase,
> +  IN UINTN   Source
>)
>  {
>UINT32RegOffset;
> @@ -250,15 +250,15 @@ 

Re: [edk2] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData

[Ryan Harkin]

On 12 October 2016 at 12:39, Evan Lloyd <evan.ll...@arm.com> wrote:
> Hi Ryan.
> No, this is dead.
> Ard's rebuttal was spot on, and unarguable.   The problem needs fixing, but 
> not in UEFI.
> Please disregard this patch.
>

Thanks, yes, it's ignored.


> Regards,
> Evan
>
>
>>-Original Message-
>>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>Sent: 11 October 2016 20:17
>>To: ryan.har...@linaro.org
>>Cc: Evan Lloyd; edk2-devel@lists.01.org; Leif Lindholm
>>Subject: Re: [edk2] ArmPlatformPkg: Allocate VRAM as
>>RuntimeServicesData
>>
>>On 11 October 2016 at 18:44, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>> Hi Evan,
>>>
>>> This was sent to the list with no subject line and I wasn't on CC, so
>>> I didn't see it.
>>>
>>> Are you still using this patch and want it in, i.e. does it need
>>> review and test?
>>>
>>
>>I'm sure it works, but I don't think we should take it.
>>RuntimeServicesData can never be released to the OS, so taking an 8MB
>>chunk just in case the OS may decide to drive the framebuffer using
>>the firmware's protocol rather than via a native driver is not
>>something we should have in reference code.
>>
>>The GOP protocol is arguably a hack anyway, since the entire protocol
>>database and driver tree are torn down after ExitBootServices(), while
>>the GOP leaves a live memory range in place that happens to keep
>>operating as a framebuffer. If the OS wants to use this protocol
>>during normal operation, it should take care to reserve this memory
>>region itself.
>>
>>I am aware that not all OSes may behave correctly in this regard. This
>>is mainly due to the fact that GOP is usually implemented by a PCI
>>device, which exposes the framebuffer via a PCI BAR rather than via a
>>system memory range.
>>
>>
>>
>>> On 4 March 2016 at 15:57,  <evan.ll...@arm.com> wrote:
>>>> Code at: https://github.com/EvanLloyd/tianocore/commit/
>>>> From: Sami Mujawar <sami.muja...@arm.com>
>>>> Date: Thu, 25 Feb 2016 15:07:40 +
>>>> Subject: [PATCH] ArmPlatformPkg: Allocate VRAM as
>>RuntimeServicesData
>>>>
>>>> The UEFI specification allows the operating system (OS) to use the
>>>> Graphics Output Protocol (GOP) in the following scenarios:
>>>>  a. as part of the startup process and
>>>>  b. prior to loading of a high performance OS graphics driver
>>>>
>>>> If the VRAM is allocated as BootServicesData, then it is unmapped on
>>>> exit boot services. This prevents GOP usage by the OS post exit boot
>>>> services (the second scenario); as it results in a crash when the VRAM
>>>> is accessed.
>>>>
>>>> This patch fixes the issue by allocating VRAM as RuntimeServicesData.
>>>>
>>>> Code at:
>>https://github.com/EvanLloyd/tianocore/commit/18fab16a63c59c84c71cd81
>>089a55a4081ebe253
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>>> Signed-off-by: Alexei Fedorov <alexei.fedo...@arm.com>
>>>> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
>>>> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
>>>> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
>>>> ---
>>>>
>>ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
>>mVExpress.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git
>>a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>>ArmVExpress.c
>>b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>>ArmVExpress.c
>>>> index a578467..4ab8862 100644
>>>> ---
>>a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>>ArmVExpress.c
>>>> +++
>>b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
>>ArmVExpress.c
>>>> @@ -133,7 +133,7 @@ LcdPlatformGetVram (
>>>>} else {
>>>>  AllocationType = AllocateAddress;
>>>>}
>>>> -  Status = gBS->AllocatePages (AllocationType, EfiBootServicesData,
>>EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
>>>> +  Status = gBS->AllocatePages (AllocationType, EfiRuntimeServicesData,
>>EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
>>>>if (EFI_ERROR(Status)) {
>>>>  return Status;
>>>>}
>>>> --
>>>> 2.7.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
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe: Fix for PCI Dual Address Cycle

[Ryan Harkin]

On 23 September 2016 at 08:58, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 22 September 2016 at 23:33, Daniil Egranov <daniil.egra...@arm.com> wrote:
>> The fix handles the PCI Dual Address Cycle Attribute case. It allows
>> drivers using PCI DAC run on Juno.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Daniil Egranov <daniil.egra...@arm.com>
>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>

Tested on Juno R0/1/2, where R0 doesn't use the Marvell ethernet
controller, but the SMC ethernet still works.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

>> ---
>>  .../ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c  | 9 
>> ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c 
>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>> index 10a4575..72d0915 100644
>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c
>> @@ -518,11 +518,14 @@ PciRbMap (
>>
>>PCI_TRACE ("PciRbMap()");
>>
>> -  if (Operation == EfiPciOperationBusMasterRead) {
>> +  if (Operation == EfiPciOperationBusMasterRead ||
>> +  Operation == EfiPciOperationBusMasterRead64) {
>>  DmaOperation = MapOperationBusMasterRead;
>> -  } else if (Operation == EfiPciOperationBusMasterWrite) {
>> +  } else if (Operation == EfiPciOperationBusMasterWrite ||
>> + Operation == EfiPciOperationBusMasterWrite64) {
>>  DmaOperation = MapOperationBusMasterWrite;
>> -  } else if (Operation == EfiPciOperationBusMasterCommonBuffer) {
>> +  } else if (Operation == EfiPciOperationBusMasterCommonBuffer ||
>> + Operation == EfiPciOperationBusMasterCommonBuffer64) {
>>  DmaOperation = MapOperationBusMasterCommonBuffer;
>>} else {
>>  return EFI_INVALID_PARAMETER;
>> --
>> 2.7.4
>>
>> ___
>> 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] [PATCH 0/3] MdeModulePkg/TerminalDxe: TtyTerm improvements

[Ryan Harkin]

On 7 October 2016 at 16:59, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> Roy can now be found at Roy Franz <roy.fr...@hpe.com> (cc:d).
>
> On Fri, Oct 07, 2016 at 05:56:26PM +0200, Laszlo Ersek wrote:
>> Roy, Ryan,
>>
>> On 10/07/16 16:53, Brian J. Johnson wrote:
>> > This patch series implements some improvements to the TtyTerm terminal
>> > type in the TerminalDxe driver.  It fixes an end case with cursor
>> > position tracking, and uses that to optimize cursor motion escape
>> > sequences.  It also adds support for the page up, page down, insert,
>> > home, and end keys on some additional common terminal emulators.
>> >
>> > The result is improved performance, especially at the shell prompt,
>> > and better compatibility with common terminal emulators.  In
>> > particular, as a side effect of the optimized cursor motion, terminal
>> > windows which are taller than the current mode setting (eg. 25 lines)
>> > work much better than before.
>> >
>> > Most of these fixes have been in production in some form on SGI's
>> > servers for years.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Brian Johnson <bjohn...@sgi.com>
>> > Cc: Feng Tian <feng.t...@intel.com>
>> > Cc: Star Zeng <star.z...@intel.com>
>> >
>> > Brian J. Johnson (3):
>> >   MdeModulePkg/TerminalDxe: Improve TtyTerm cursor position tracking
>> >   MdeModulePkg/TerminalDxe: Optimize TtyTerm cursor motion
>> >   MdeModulePkg/TerminalDxe: Handle more keys with TtyTerm
>> >
>> >  .../Universal/Console/TerminalDxe/Terminal.h   |  2 +
>> >  .../Universal/Console/TerminalDxe/TerminalConIn.c  | 24 +++--
>> >  .../Universal/Console/TerminalDxe/TerminalConOut.c | 61 
>> > --
>> >  3 files changed, 79 insertions(+), 8 deletions(-)
>> >
>>
>> can you please provide feedback (testing or otherwise) on this series?
>>

Well, they "work" for me and I'd be happy with them being submitted.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

The only curious effect I can see is the Print(L"xxx"); lines that
expect the \n to be missing will no longer "work".  For example, I
carry a patch by Daniil Egranov titled
"IntelFrameworkModulePkg/BdsDxe: Show boot timeout message" and it no
longer displays the countdown on the same line each time, it prints
each message on a new line.

However, I don't see that as a blocking point, Daniil's patch could be
changed easily and there are other advantages to this series that make
it worthwhile, IMO, eg, Shell commands with lots of output (like
"help" or "dir fs0:") no longer create an awful mess on the serial
console.


>> 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 0/3] PL011 updates.

[Ryan Harkin]

On 21 September 2016 at 21:33,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> This patchset comprises two very minor fixes to the PL011 UART related
> code, and some comment updates.
> The FIFO fix amounts to a performance improvement in limited circumstaces,
> where some older platforms might not used the FIFO.
> The UINTN cast fix preempts errors on future 32-bit platforms.
>
> The code can be inspected at: 
> https://github.com/EvanLloyd/tianocore/tree/pl011a_v1
>
>
> Alexei (2):
>   ArmPlatformPkg: Correct mendacious comments.
>   ArmPlatformPkg: Remove UINTN cast when setting BaudRate.
>
> Evan Lloyd (1):
>   ArmPlatformPkg: Fix PL011 FIFO size test
>
>  ArmPlatformPkg/Include/Drivers/PL011Uart.h |  5 ++---
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c   | 16 
> +++
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 21 
> +---
>  3 files changed, 19 insertions(+), 23 deletions(-)
>
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
>

For the whole series:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

[Tested on Juno R0/1/2, TC2, FVP Foundation and AEMv8 models.]
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData

[Ryan Harkin]

On 11 Oct 2016 20:17, "Ard Biesheuvel" <ard.biesheu...@linaro.org> wrote:
>
> On 11 October 2016 at 18:44, Ryan Harkin <ryan.har...@linaro.org> wrote:
> > Hi Evan,
> >
> > This was sent to the list with no subject line and I wasn't on CC, so
> > I didn't see it.
> >
> > Are you still using this patch and want it in, i.e. does it need
> > review and test?
> >
>
> I'm sure it works, but I don't think we should take it.
> RuntimeServicesData can never be released to the OS, so taking an 8MB
> chunk just in case the OS may decide to drive the framebuffer using
> the firmware's protocol rather than via a native driver is not
> something we should have in reference code.
>
> The GOP protocol is arguably a hack anyway, since the entire protocol
> database and driver tree are torn down after ExitBootServices(), while
> the GOP leaves a live memory range in place that happens to keep
> operating as a framebuffer. If the OS wants to use this protocol
> during normal operation, it should take care to reserve this memory
> region itself.
>
> I am aware that not all OSes may behave correctly in this regard. This
> is mainly due to the fact that GOP is usually implemented by a PCI
> device, which exposes the framebuffer via a PCI BAR rather than via a
> system memory range.
>

Fair enough, I'll leave it!

>
>
> > On 4 March 2016 at 15:57,  <evan.ll...@arm.com> wrote:
> >> Code at: https://github.com/EvanLloyd/tianocore/commit/
> >> From: Sami Mujawar <sami.muja...@arm.com>
> >> Date: Thu, 25 Feb 2016 15:07:40 +
> >> Subject: [PATCH] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData
> >>
> >> The UEFI specification allows the operating system (OS) to use the
> >> Graphics Output Protocol (GOP) in the following scenarios:
> >>  a. as part of the startup process and
> >>  b. prior to loading of a high performance OS graphics driver
> >>
> >> If the VRAM is allocated as BootServicesData, then it is unmapped on
> >> exit boot services. This prevents GOP usage by the OS post exit boot
> >> services (the second scenario); as it results in a crash when the VRAM
> >> is accessed.
> >>
> >> This patch fixes the issue by allocating VRAM as RuntimeServicesData.
> >>
> >> Code at:
https://github.com/EvanLloyd/tianocore/commit/18fab16a63c59c84c71cd81089a55a4081ebe253
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Alexei Fedorov <alexei.fedo...@arm.com>
> >> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> >> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >> ---
> >>
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> >> index a578467..4ab8862 100644
> >> ---
a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> >> +++
b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> >> @@ -133,7 +133,7 @@ LcdPlatformGetVram (
> >>} else {
> >>  AllocationType = AllocateAddress;
> >>}
> >> -  Status = gBS->AllocatePages (AllocationType, EfiBootServicesData,
EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
> >> +  Status = gBS->AllocatePages (AllocationType,
EfiRuntimeServicesData, EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)),
VramBaseAddress);
> >>if (EFI_ERROR(Status)) {
> >>  return Status;
> >>}
> >> --
> >> 2.7.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 00/10] enhance mmc

[Ryan Harkin]

On 12 Oct 2016 00:33, "Haojian Zhuang" <haojian.zhu...@linaro.org> wrote:
>
> On 12 October 2016 at 01:03, Ryan Harkin <ryan.har...@linaro.org> wrote:
> > On 11 October 2016 at 17:28, Ard Biesheuvel <ard.biesheu...@linaro.org>
wrote:
> >> On 11 October 2016 at 17:27, Ryan Harkin <ryan.har...@linaro.org>
wrote:
> >>> On 11 October 2016 at 17:24, Ard Biesheuvel <ard.biesheu...@linaro.org>
wrote:
> >>>> Hi Ryan,
> >>>>
> >>>> On 11 October 2016 at 17:22, Ryan Harkin <ryan.har...@linaro.org>
wrote:
> >>>> [...]
> >>>>> And OpenPlatformPkg was taken from my repo, which only carries one
> >>>>> patch essential for TC2 booting:
> >>>>>   c22a665  2016-01-29  HACK: Platforms/ARM: TC2: set
> >>>>> gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride TRUE  [Ryan
> >>>>> Harkin]
> >>>>
> >>>> Shouldn't we simply merge that patch?
> >>>
> >>> I think Leif said no, back when TC2 broken in mainline.
> >>>
> >>> The commit that broke it was 0c9a522f28772049ae37c85b8ae589a98d2d3b81
> >>> "ArmPkg/ArmLib: mark all cached mappings as (inner) shareable".  IIRC
> >>> Leif said there is something wrong with the TC2 setup code meaning
> >>> that we need to set the PCD, even though we shouldn't need to.
> >>>
> >>> And I've never had time to work it out, so I've just carried the
patch.
> >>
> >> Ah right, I remember now.
> >
> > And if I'd looked further down my HACK commit, I'd have seen this text
> > explaining what happened:
> >
> >However, the topic was discussed on the mailing list:
> >
> >   https://www.mail-archive.com/edk2-devel@lists.01.org/msg03974.html
> >
> > The correct solution for platforms that wish to revert this
behaviour
> > is to set the following PCD to TRUE:
> >
> >   gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride
> >
> > However, for TC2 should not need to do this.  Work continues to
> > ascertain why TC2 breaks with shareable mappings.  Current thinking
is
> > that CCI-400 needs configuring before shareable mappings will work.
> >
> > :-)
>
> Hi Ryan,
>
> Does it mean that you'll give the fix configuration of CCI-400 on TC2
> in upstream?
>
It means I *should* configure it, but I've not looked at it at all and have
no plans to look at it in the near future.

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

Re: [edk2] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData

[Ryan Harkin]

Hi Evan,

This was sent to the list with no subject line and I wasn't on CC, so
I didn't see it.

Are you still using this patch and want it in, i.e. does it need
review and test?

Cheers,
Ryan.

On 4 March 2016 at 15:57,   wrote:
> Code at: https://github.com/EvanLloyd/tianocore/commit/
> From: Sami Mujawar 
> Date: Thu, 25 Feb 2016 15:07:40 +
> Subject: [PATCH] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData
>
> The UEFI specification allows the operating system (OS) to use the
> Graphics Output Protocol (GOP) in the following scenarios:
>  a. as part of the startup process and
>  b. prior to loading of a high performance OS graphics driver
>
> If the VRAM is allocated as BootServicesData, then it is unmapped on
> exit boot services. This prevents GOP usage by the OS post exit boot
> services (the second scenario); as it results in a crash when the VRAM
> is accessed.
>
> This patch fixes the issue by allocating VRAM as RuntimeServicesData.
>
> Code at: 
> https://github.com/EvanLloyd/tianocore/commit/18fab16a63c59c84c71cd81089a55a4081ebe253
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Alexei Fedorov 
> Signed-off-by: Girish Pathak 
> Signed-off-by: Sami Mujawar 
> Signed-off-by: Evan Lloyd 
> ---
>  ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
> | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>  
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> index a578467..4ab8862 100644
> --- 
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> +++ 
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
> @@ -133,7 +133,7 @@ LcdPlatformGetVram (
>} else {
>  AllocationType = AllocateAddress;
>}
> -  Status = gBS->AllocatePages (AllocationType, EfiBootServicesData, 
> EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
> +  Status = gBS->AllocatePages (AllocationType, EfiRuntimeServicesData, 
> EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
>if (EFI_ERROR(Status)) {
>  return Status;
>}
> --
> 2.7.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 v3 00/10] enhance mmc

[Ryan Harkin]

On 11 October 2016 at 17:28, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 11 October 2016 at 17:27, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> On 11 October 2016 at 17:24, Ard Biesheuvel <ard.biesheu...@linaro.org> 
>> wrote:
>>> Hi Ryan,
>>>
>>> On 11 October 2016 at 17:22, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>> [...]
>>>> And OpenPlatformPkg was taken from my repo, which only carries one
>>>> patch essential for TC2 booting:
>>>>   c22a665  2016-01-29  HACK: Platforms/ARM: TC2: set
>>>> gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride TRUE  [Ryan
>>>> Harkin]
>>>
>>> Shouldn't we simply merge that patch?
>>
>> I think Leif said no, back when TC2 broken in mainline.
>>
>> The commit that broke it was 0c9a522f28772049ae37c85b8ae589a98d2d3b81
>> "ArmPkg/ArmLib: mark all cached mappings as (inner) shareable".  IIRC
>> Leif said there is something wrong with the TC2 setup code meaning
>> that we need to set the PCD, even though we shouldn't need to.
>>
>> And I've never had time to work it out, so I've just carried the patch.
>
> Ah right, I remember now.

And if I'd looked further down my HACK commit, I'd have seen this text
explaining what happened:

   However, the topic was discussed on the mailing list:

  https://www.mail-archive.com/edk2-devel@lists.01.org/msg03974.html

The correct solution for platforms that wish to revert this behaviour
is to set the following PCD to TRUE:

  gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride

However, for TC2 should not need to do this.  Work continues to
ascertain why TC2 breaks with shareable mappings.  Current thinking is
that CCI-400 needs configuring before shareable mappings will work.

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

Re: [edk2] [PATCH v3 00/10] enhance mmc

[Ryan Harkin]

On 11 October 2016 at 17:24, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> Hi Ryan,
>
> On 11 October 2016 at 17:22, Ryan Harkin <ryan.har...@linaro.org> wrote:
> [...]
>> And OpenPlatformPkg was taken from my repo, which only carries one
>> patch essential for TC2 booting:
>>   c22a665  2016-01-29  HACK: Platforms/ARM: TC2: set
>> gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride TRUE  [Ryan
>> Harkin]
>
> Shouldn't we simply merge that patch?

I think Leif said no, back when TC2 broken in mainline.

The commit that broke it was 0c9a522f28772049ae37c85b8ae589a98d2d3b81
"ArmPkg/ArmLib: mark all cached mappings as (inner) shareable".  IIRC
Leif said there is something wrong with the TC2 setup code meaning
that we need to set the PCD, even though we shouldn't need to.

And I've never had time to work it out, so I've just carried the patch.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 00/10] enhance mmc

[Ryan Harkin]

Hi Haojian,

So I've tested this v3 patchset and while it's much improved, I still
get hangs on TC2.

The good news, MMC identification and driver initialisation succeeds
in this version and the board boots a bit further.

Unfortunately, with a RELEASE build, the board hangs at a later point:
when the BDS starts, I think.  But only with RELEASE builds; DEBUG is
OK.

I can repeatedly add/revert your patchset and the board will either
hang/boot each time.

I based my work on pure upstream EDK2 and added your patches:
  da936c2  2016-09-21  PL180: update for indentifying SD  [Haojian Zhuang]
  242542a  2016-09-21  MmcDxe: expand to support multiple blocks
[Haojian Zhuang]
  73636cc  2016-09-21  MmcDxe: set iospeed and bus width in SD stack
   [Haojian Zhuang]
  7f54eea  2016-09-21  MmcDxe: Fix uninitialized mediaid for SD
[Haojian Zhuang]
  ef46f04  2016-09-21  MmcDxe: set io bus width before reading EXTCSD
   [Haojian Zhuang]
  e21926e  2016-09-21  MmcDxe: declare ECSD structure [Haojian Zhuang]
  f0e0fd9  2016-09-21  MmcDxe: add interface to change io width and
speed [Haojian Zhuang]
  09ef3f1  2016-09-21  MmcDxe: add SPEC_VERS field in CSD structure
   [Haojian Zhuang]
  4677114  2016-09-21  MmcDxe: move ECSD into CardInfo structure
[Haojian Zhuang]
  7e1d256  2016-09-21  MmcDxe: wait OCR busy bit free [Haojian Zhuang]
  b3b58d4  2016-09-28  PcAtChipsetPkg AcpiTimerLib: Clear bits [31:24]
after reading by IoRead32()[Star Zeng]

And OpenPlatformPkg was taken from my repo, which only carries one
patch essential for TC2 booting:
  c22a665  2016-01-29  HACK: Platforms/ARM: TC2: set
gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride TRUE  [Ryan
Harkin]
  ad932f0  2016-08-25  Platforms/ARM/Juno: Add support for ACPI 6.0
LPI(Low Power Idle) states[Sudeep Holla]

I've pushed both to my repos with the tag "mmc-v3-001"

https://git.linaro.org/landing-teams/working/arm/edk2.git/shortlog/refs/tags/mmc-v3-001
https://git.linaro.org/landing-teams/working/arm/OpenPlatformPkg.git/shortlog/refs/tags/mmc-v3-001

If I use pure upstream tianocore at commit b3b58d4 along with my
OpenPlatformPkg at the "mmc-v3-001" tag, then the board doesn't hang
on boot in a RELEASE build.

Cheers,
Ryan.

On 21 September 2016 at 16:02, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
> v3:
>   * Fix PL180 hang because of CMD6 & ACMD51 not supported.
>
> v2:
>   * Fix print error with missing parameter.
>   * Change CMD51 to ACMD51.
>   * Add the protection after CMD55 for SD. If there's no
> response of CMD55, skip to send ACMD51.
>
> v1:
>   * Wait OCR busy bit free according to eMMC spec.
>   * Define ECSD structure.
>   * Add interface to set IO bus width and speed.
>   * Support to access multiple blocks.
>
> Haojian Zhuang (10):
>   MmcDxe: wait OCR busy bit free
>   MmcDxe: move ECSD into CardInfo structure
>   MmcDxe: add SPEC_VERS field in CSD structure
>   MmcDxe: add interface to change io width and speed
>   MmcDxe: declare ECSD structure
>   MmcDxe: set io bus width before reading EXTCSD
>   MmcDxe: Fix uninitialized mediaid for SD
>   MmcDxe: set iospeed and bus width in SD stack
>   MmcDxe: expand to support multiple blocks
>   PL180: update for indentifying SD
>
>  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c|  15 +-
>  EmbeddedPkg/Include/Protocol/MmcHost.h   |  29 ++
>  EmbeddedPkg/Universal/MmcDxe/Mmc.h   | 176 +++-
>  EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c| 175 
>  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 350 
> +--
>  5 files changed, 659 insertions(+), 86 deletions(-)
>
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg/PrePi: fix secondary stack base

[Ryan Harkin]

On 7 September 2016 at 13:17, Ard Biesheuvel  wrote:
> On 7 September 2016 at 13:06, Michael Zimmermann
>  wrote:
>> this bug was introduced by:
>> d2fa09a ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: M1cha 
>> ---
>>  ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>> b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>> index b7127ce..39030da 100644
>> --- a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>> +++ b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>> @@ -101,7 +101,7 @@ _GetStackBase:
>>sub   r10, r1, r2
>>
>>// Stack for the secondary core = Number of Cores - 1
>> -  MOV32 (r0, (FixedPcdGet32(PcdCoreCount) - 1) *
>> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
>> +  MOV32 (r1, (FixedPcdGet32(PcdCoreCount) - 1) *
>> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
>>sub   r10, r10, r1
>>
>>// r10 = The base of the MpCore Stacks (primary stack & secondary stacks)
>> --
>> 2.9.3
>>
>
> Pushed, thanks

Excellent!  Thanks both :-)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro

[Ryan Harkin]

On 7 September 2016 at 12:59, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 7 September 2016 at 12:10, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> On 31 August 2016 at 05:33, Michael Zimmermann <sigmaepsilo...@gmail.com> 
>> wrote:
>>> reviewed should mean tested ;)
>>>
>>> took me some time to find out why my system currently doesn't boot anymore
>>
>> I have just bisected my TC2 boot failure down to this patch too.
>>
>>> but here's the fix for this commit:
>>>
>>> diff --git a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>>> b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>>> index b7127ce..39030da 100644
>>> --- a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>>> +++ b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
>>> @@ -101,7 +101,7 @@ _GetStackBase:
>>>sub   r10, r1, r2
>>>
>>>// Stack for the secondary core = Number of Cores - 1
>>> -  MOV32 (r0, (FixedPcdGet32(PcdCoreCount) - 1) *
>>> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
>>> +  MOV32 (r1, (FixedPcdGet32(PcdCoreCount) - 1) *
>>> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))^M
>>>sub   r10, r10, r1
>>>
>>>    // r10 = The base of the MpCore Stacks (primary stack & secondary stacks)
>>
>> And this fix works for me on TC2 also.
>>
>
> May we take that as a tested-by?
>

Oh yes! :-)

You can even have some tested text too:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

But I'll be happy to report that if Michael (or someone else) posts a patch.

>> Michael/Ard, has one of you already or does one of you intend to
>> submit the fix for this?
>>
>
> Michael: care to send it as a proper patch, please?
>
>
>>
>>>
>>> On Thu, Aug 11, 2016 at 10:38 AM, Leif Lindholm <leif.lindh...@linaro.org>
>>> wrote:
>>>
>>>> On Wed, Aug 10, 2016 at 05:17:58PM +0200, Ard Biesheuvel wrote:
>>>> > Annotate functions with ASM_FUNC() so that they are emitted into
>>>> > separate sections.
>>>>
>>>> Also replacing LoadConstantToReg. Add that to commit message and:
>>>> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>>>>
>>>> > Contributed-under: TianoCore Contribution Agreement 1.0
>>>> > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>>> > ---
>>>> >  ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 49
>>>> ++-
>>>> >  ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 50
>>>> ++--
>>>> >  2 files changed, 29 insertions(+), 70 deletions(-)
>>>> >
>>>> > diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>>>> b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>>>> > index 9538c70a237c..d0530a874726 100644
>>>> > --- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>>>> > +++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>>>> > @@ -12,24 +12,10 @@
>>>> >  //
>>>> >
>>>> >  #include 
>>>> > -#include 
>>>> > -#include 
>>>> > -#include 
>>>> > -
>>>> > -.text
>>>> > -.align 3
>>>> > -
>>>> > -GCC_ASM_IMPORT(ArmPlatformIsPrimaryCore)
>>>> > -GCC_ASM_IMPORT(ArmReadMpidr)
>>>> > -GCC_ASM_IMPORT(ArmPlatformPeiBootAction)
>>>> > -GCC_ASM_IMPORT(ArmPlatformStackSet)
>>>> > -GCC_ASM_EXPORT(_ModuleEntryPoint)
>>>> > -ASM_GLOBAL ASM_PFX(mSystemMemoryEnd)
>>>> >
>>>> > -StartupAddr:  .8byte ASM_PFX(CEntryPoint)
>>>> > -ASM_PFX(mSystemMemoryEnd):.8byte 0
>>>> > +ASM_GLOBAL ASM_PFX(mSystemMemoryEnd)
>>>> >
>>>> > -ASM_PFX(_ModuleEntryPoint):
>>>> > +ASM_FUNC(_ModuleEntryPoint)
>>>> >// Do early platform specific actions
>>>> >blASM_PFX(ArmPlatformPeiBootAction)
>>>> >
>>>> > @@ -49,10 +35,8 @@ _SystemMemoryEndInit:
>>>> >cmp   x1, #0
>>>> >bne   _SetupStackPosition
>>>> >
>>>> > -  LoadConstantToReg (FixedPcdGet64(PcdSystemMemoryBase), x1)
>>>> > -  LoadConstantToReg (FixedPcdGet64(PcdSystemMemorySize), x2)
>>>> > -  sub   x2, x2, #1
>>>> > -  add   x1, x1, x2
>>>> > +  MOV64 (x1, Fixe

Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro

[Ryan Harkin]

On 31 August 2016 at 05:33, Michael Zimmermann  wrote:
> reviewed should mean tested ;)
>
> took me some time to find out why my system currently doesn't boot anymore

I have just bisected my TC2 boot failure down to this patch too.

> but here's the fix for this commit:
>
> diff --git a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
> b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
> index b7127ce..39030da 100644
> --- a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
> +++ b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S
> @@ -101,7 +101,7 @@ _GetStackBase:
>sub   r10, r1, r2
>
>// Stack for the secondary core = Number of Cores - 1
> -  MOV32 (r0, (FixedPcdGet32(PcdCoreCount) - 1) *
> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
> +  MOV32 (r1, (FixedPcdGet32(PcdCoreCount) - 1) *
> FixedPcdGet32(PcdCPUCoreSecondaryStackSize))^M
>sub   r10, r10, r1
>
>// r10 = The base of the MpCore Stacks (primary stack & secondary stacks)

And this fix works for me on TC2 also.

Michael/Ard, has one of you already or does one of you intend to
submit the fix for this?


>
> On Thu, Aug 11, 2016 at 10:38 AM, Leif Lindholm 
> wrote:
>
>> On Wed, Aug 10, 2016 at 05:17:58PM +0200, Ard Biesheuvel wrote:
>> > Annotate functions with ASM_FUNC() so that they are emitted into
>> > separate sections.
>>
>> Also replacing LoadConstantToReg. Add that to commit message and:
>> Reviewed-by: Leif Lindholm 
>>
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Ard Biesheuvel 
>> > ---
>> >  ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 49
>> ++-
>> >  ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 50
>> ++--
>> >  2 files changed, 29 insertions(+), 70 deletions(-)
>> >
>> > diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>> b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>> > index 9538c70a237c..d0530a874726 100644
>> > --- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>> > +++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
>> > @@ -12,24 +12,10 @@
>> >  //
>> >
>> >  #include 
>> > -#include 
>> > -#include 
>> > -#include 
>> > -
>> > -.text
>> > -.align 3
>> > -
>> > -GCC_ASM_IMPORT(ArmPlatformIsPrimaryCore)
>> > -GCC_ASM_IMPORT(ArmReadMpidr)
>> > -GCC_ASM_IMPORT(ArmPlatformPeiBootAction)
>> > -GCC_ASM_IMPORT(ArmPlatformStackSet)
>> > -GCC_ASM_EXPORT(_ModuleEntryPoint)
>> > -ASM_GLOBAL ASM_PFX(mSystemMemoryEnd)
>> >
>> > -StartupAddr:  .8byte ASM_PFX(CEntryPoint)
>> > -ASM_PFX(mSystemMemoryEnd):.8byte 0
>> > +ASM_GLOBAL ASM_PFX(mSystemMemoryEnd)
>> >
>> > -ASM_PFX(_ModuleEntryPoint):
>> > +ASM_FUNC(_ModuleEntryPoint)
>> >// Do early platform specific actions
>> >blASM_PFX(ArmPlatformPeiBootAction)
>> >
>> > @@ -49,10 +35,8 @@ _SystemMemoryEndInit:
>> >cmp   x1, #0
>> >bne   _SetupStackPosition
>> >
>> > -  LoadConstantToReg (FixedPcdGet64(PcdSystemMemoryBase), x1)
>> > -  LoadConstantToReg (FixedPcdGet64(PcdSystemMemorySize), x2)
>> > -  sub   x2, x2, #1
>> > -  add   x1, x1, x2
>> > +  MOV64 (x1, FixedPcdGet64(PcdSystemMemoryBase) + 
>> > FixedPcdGet64(PcdSystemMemorySize)
>> - 1)
>> > +
>> >// Update the global variable
>> >adr   x2, mSystemMemoryEnd
>> >str   x1, [x2]
>> > @@ -61,13 +45,13 @@ _SetupStackPosition:
>> >// r1 = SystemMemoryTop
>> >
>> >// Calculate Top of the Firmware Device
>> > -  LoadConstantToReg (FixedPcdGet64(PcdFdBaseAddress), x2)
>> > -  LoadConstantToReg (FixedPcdGet32(PcdFdSize), x3)
>> > +  MOV64 (x2, FixedPcdGet64(PcdFdBaseAddress))
>> > +  MOV32 (x3, FixedPcdGet32(PcdFdSize) - 1)
>> >sub   x3, x3, #1
>> >add   x3, x3, x2  // x3 = FdTop = PcdFdBaseAddress + PcdFdSize
>> >
>> >// UEFI Memory Size (stacks are allocated in this region)
>> > -  LoadConstantToReg (FixedPcdGet32(PcdSystemMemoryUefiRegionSize), x4)
>> > +  MOV32 (x4, FixedPcdGet32(PcdSystemMemoryUefiRegionSize))
>> >
>> >//
>> >// Reserve the memory for the UEFI region (contain stacks on its top)
>> > @@ -98,9 +82,7 @@ _SetupAlignedStack:
>> >  _SetupOverflowStack:
>> >// Case memory at the top of the address space. Ensure the top of the
>> stack is EFI_PAGE_SIZE
>> >// aligned (4KB)
>> > -  LoadConstantToReg (EFI_PAGE_MASK, x11)
>> > -  and   x11, x11, x1
>> > -  sub   x1, x1, x11
>> > +  and   x1, x1, ~EFI_PAGE_MASK
>> >
>> >  _GetBaseUefiMemory:
>> >// Calculate the Base of the UEFI Memory
>> > @@ -109,22 +91,19 @@ _GetBaseUefiMemory:
>> >  _GetStackBase:
>> >// r1 = The top of the Mpcore Stacks
>> >// Stack for the primary core = PrimaryCoreStack
>> > -  LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
>> > +  MOV32 (x2, FixedPcdGet32(PcdCPUCorePrimaryStackSize))
>> >sub   x12, x1, x2
>> >
>> >// Stack for the secondary core = Number of Cores - 1
>> > -  LoadConstantToReg (FixedPcdGet32(PcdCoreCount), x0)
>> > -  sub  

Re: [edk2] [PATCH v5] Platforms/ARM/Juno: Create SMBIOS/DMI data for Juno

[Ryan Harkin]

On 28 July 2016 at 15:41, Jeremy Linton <jeremy.lin...@arm.com> wrote:
> SMBIOS data is consumed by a wide range of enterprise applications.
>
> Fill in the basic requirements of the SMBIOS specification by hardcoding
> the minimum required structures and data using Juno information. Only the
> juno revision, memory ranges and CPU types are dynamic.
>
> Add the resulting Juno SmbiosPlatformDxe and MdeModulePkg/SmbiosDxe to the
> build and firmware image. With these changes, the EFI BDS, EFI shell,
> and Linux dmidecode command return useful information.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton <jeremy.lin...@arm.com>

Acked-by: Ryan Harkin <ryan.har...@linaro.org>


> ---
>  Platforms/ARM/Juno/ArmJuno.dsc |  12 +
>  Platforms/ARM/Juno/ArmJuno.fdf |   6 +
>  .../ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 865 
> +
>  .../Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |  68 ++
>  4 files changed, 951 insertions(+)
>  create mode 100644 Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.c
>  create mode 100644 Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>
> diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
> index 84c2441..c51d8f2 100644
> --- a/Platforms/ARM/Juno/ArmJuno.dsc
> +++ b/Platforms/ARM/Juno/ArmJuno.dsc
> @@ -178,6 +178,12 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
>
> +  #
> +  # SMBIOS entry point version
> +  #
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
> +
>  [PcdsPatchableInModule]
># Console Resolution (Full HD)
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920
> @@ -312,6 +318,12 @@
>}
>
>#
> +  # SMBIOS/DMI
> +  #
> +  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> +  OpenPlatformPkg/Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
> +
> +  #
># Bds
>#
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/Platforms/ARM/Juno/ArmJuno.fdf b/Platforms/ARM/Juno/ArmJuno.fdf
> index a01db20..04d9a3c 100644
> --- a/Platforms/ARM/Juno/ArmJuno.fdf
> +++ b/Platforms/ARM/Juno/ArmJuno.fdf
> @@ -202,6 +202,12 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092
>INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
>
>#
> +  # SMBIOS/DMI
> +  #
> +  INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> +  INF 
> OpenPlatformPkg/Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
> +
> +  #
># Bds
>#
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> b/Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> new file mode 100644
> index 000..fe5498e
> --- /dev/null
> +++ b/Platforms/ARM/Juno/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> @@ -0,0 +1,865 @@
> +/** @file
> +  This driver installs SMBIOS information for ARM Juno platforms
> +
> +  Copyright (c) 2015, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TYPE0_STRINGS\
> +  "EFI Development Kit II / ARM LTD\0" /* Vendor */  \
> +  "EDK II\0"   /* BiosVersion */ \
> +  __DATE__"\0" /* BiosReleaseDate */
> +
> +#define TYPE1_STRINGS   \
> +  "ARM LTD\0"/* Manufacturer */ \
> +  "ARM Juno Development Platform\0"  /* Product Name */ \
> +  "None\0"   /* Version */  \
> +  "\0"   /* 20 character buffer */
> +
> +#define TYPE2_STRINGS

Re: [edk2] [PATCH v3 0/4] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

[Ryan Harkin]

On 25 July 2016 at 17:36, Jeremy Linton <jeremy.lin...@arm.com> wrote:
> On 07/22/2016 11:38 AM, Ryan Harkin wrote:
>>
>> Hi Jeremy,
>>
>> Can I give you a kick re: this patch series?
>>
>> It's been sitting in my landing team tree for months and hasn't been
>> resubmitted to reflect the move of Juno to OpenPlatformPkg.
>
>
> I will resubmit it, I wasn't sure if it was "wanted" given all the
> hard-coded tables. Although, now that there is something of a random number
> generator, maybe it's worth the effort to generate some of the serial
> numbers/etc dynamically.
>

Well, it was you that wanted it ;-)  If you don't want it any more,
that's fine too; instead of reworking the series, I can just drop it
from my tree.

But it seemed like it's something worth having rather than not, even
with the hard coding.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/4] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

[Ryan Harkin]

Hi Jeremy,

Can I give you a kick re: this patch series?

It's been sitting in my landing team tree for months and hasn't been
resubmitted to reflect the move of Juno to OpenPlatformPkg.

Cheers,
Ryan.

On 5 February 2016 at 20:35, Jeremy Linton  wrote:
> V3 of this patch, adds support for JunoR2, and cleans up the board
> revision detection logic futher over V2.
>
> SMBIOS data is consumed by a wide range of enterprise applications.
>
> This patch adds basic SMBIOS data for the ARM Juno. Most of the
> data is static. The system memory layout and juno revision
> are updated depending on the platform. To accomplish the juno revision
> detection the Juno revision code in ArmJunoDxe was hoisted into the
> platform.h file on the recommendation of others (to avoid a AFTER
> dependency).
>
> With this patch, both the EFI shell and linux dmidecode commands
> return useful information.
>
> Jeremy Linton (4):
>   ArmPlatformPkg: Add A72 CPU type
>   Code to detect what juno revision we are running on.
>   Convert ArmJunoDxe to use common juno revision code
>   ArmPlatformPkg/ArmJunoPkg: Create SMBIOS/DMI data for Juno
>
>  ArmPkg/Include/Chipset/AArch64.h   |   1 +
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc  |  12 +
>  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf  |   6 +
>  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c |  66 +-
>  ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h|  31 +-
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.c  | 864 
> +
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf|  68 ++
>  7 files changed, 1002 insertions(+), 46 deletions(-)
>  create mode 100644 
> ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
>  create mode 100644 
> ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>
> --
> 2.4.3
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCHv4 0/2] ArmJuno: Correct AXI<->PCI translations

[Ryan Harkin]

On 14 July 2016 at 15:09, Leif Lindholm  wrote:
> Thanks Jeremy.
>
> If Ryan's happy with this change, I'm happy to push it.
>

Yep, fine.  I tested v3 (I think) and it worked fine.


> Regards,
>
> Leif
>
> On 14 July 2016 at 14:58, Jeremy Linton  wrote:
>> The PCIe PIO translation is incorrect on the Juno, correct that.
>> While we are updating that module correct the comments to more
>> accurately reflect the code and what is actually happening.
>>
>> Jeremy Linton (2):
>>   ArmJuno: fix Juno PIO host bridge mapping
>>   ArmJuno: Correct AXI->PCIe translation comments
>>
>>  .../ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c   | 13 
>> -
>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> --
>> 2.4.11
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmJuno: fix Juno PIO host bridge mapping

[Ryan Harkin]

On 11 July 2016 at 17:27, Leif Lindholm  wrote:
> On Mon, Jul 11, 2016 at 11:17:09AM -0500, Jeremy Linton wrote:
>> The Juno PIO mapping is 8M, so it should be using 32-bit
>> PIO address translation. Futher,

"Futher" -> "Further"?

>> PIO addresses should start
>> at 0 and be translated to/from the ARM MMIO region.
>>
>
> Needs:
> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jeremy Linton 
>> ---
>>  .../ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c | 11 
>> +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c 
>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>> index 06de6d5..1774e7d 100644
>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/XPressRich3.c
>> @@ -72,7 +72,9 @@ HWPciRbInit (
>>
>>PCI_TRACE ("PCIe Setting up Address Translation");
>>
>> -  PCIE_ROOTPORT_WRITE32 (PCIE_BAR_WIN, PCIE_BAR_WIN_SUPPORT_IO | 
>> PCIE_BAR_WIN_SUPPORT_MEM | PCIE_BAR_WIN_SUPPORT_MEM64);
>> +  // The Juno PIO window is 8M, so we need full 32-bit PIO decoding.
>> +  PCIE_ROOTPORT_WRITE32 (PCIE_BAR_WIN, PCIE_BAR_WIN_SUPPORT_IO | 
>> PCIE_BAR_WIN_SUPPORT_IO32 |
>> + PCIE_BAR_WIN_SUPPORT_MEM | 
>> PCIE_BAR_WIN_SUPPORT_MEM64);
>>

So it should be IO32 *and* MEM64 at the same time?


>>// Setup the PCI Configuration Registers
>>// Offset 0a: SubClass   04 PCI-PCI Bridge
>> @@ -82,7 +84,7 @@ HWPciRbInit (
>>PCIE_ROOTPORT_WRITE32 (PCIE_PCI_IDS + PCIE_PCI_IDS_CLASSCODE_OFFSET, 
>> ((PLDA_BRIDGE_CCR << 8) | PCI_BRIDGE_REVISION_ID));
>>
>>//
>> -  // PCIE Window 0 -> AXI4 Slave 0 Address Translations
>> +  // PCIE Window 0 -> AXI4 Master 0 Address Translations
>
> So, this looks like a change unrelated to the overall fix.
> It also looks like a sufficiantly spectacular fix (if only of a
> comment) that it merits its own commit message.
> Could you break it out into a separate patch please?
>
>>//
>>TranslationTable = VEXPRESS_ATR_PCIE_WIN0;
>>
>> @@ -107,9 +109,9 @@ HWPciRbInit (
>>SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_ECAM_BASE, 
>> PCI_ECAM_BASE, PCI_ECAM_SIZE, PCI_ATR_TRSLID_PCIE_CONF);
>>TranslationTable += PCI_ATR_ENTRY_SIZE;
>>
>> -  // PCI IO Support
>> -  SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_IO_BASE, 
>> PCI_IO_BASE, PCI_IO_SIZE, PCI_ATR_TRSLID_PCIE_IO);
>> +  // PCI IO Support, the PIO space is translated from the ARM MMIO 
>> PCI_IO_BASE address to the PIO base address of 0
>> +  // AKA, PIO addresses used by endpoints are generally in the range of 
>> 0-64K.
>> +  SetTranslationAddressEntry (CpuIo, TranslationTable, PCI_IO_BASE, 0, 
>> PCI_IO_SIZE, PCI_ATR_TRSLID_PCIE_IO);
>>TranslationTable += PCI_ATR_ENTRY_SIZE;
>>
>>// PCI MEM32 Support
>> --
>> 2.4.11
>
> Looks like a clear fix to me - but I'd appreciate Ryan's review as
> well.

I have no clue if the change is correct or not, but it looks like it
might do what Jeremy says it does, if that helps??

> Apart from that - with the standalone comment change dropped
> from this one, and the contributed-under added:
> Reviewed-by: Leif Lindholm 
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Criteria for header inclusion order

[Ryan Harkin]

Hi Evan,

On 11 July 2016 at 14:41, Evan Lloyd  wrote:
> Hi Ryan.
> You made a "style comment" on a recent patch (and tested it, thank you)
> You said:
>>> @@ -18,6 +18,7 @@
>>>  #include 
>>>
>>>  #include 
>>> +#include 
>>
>> Is there an ordering requirement for the include file?
>> If not, I would prefer it before the Library includes in order to keep
>> the sort order.
>>
>> I can do this before pushing if someone tells me it's OK.
>

That was Leif's comment, not mine.

> There is nothing very clear in the CSS about #include ordering, and I thought 
> it would be useful to clearly understand the criteria.
> I infer that, in the absence of any dependency, you advise alphabetic sorting 
> on the full include path.
> Is that correct?

I have no clue if there's a specific criteria for EDK2, but I've seen
comments on many projects that alphabetical ordering is nicest where
possible.

But I'll let Leif chip in as it was his comment.

Cheers,
Ryan.


> Are there any other ideas we could bear in mind as helpful for includes?
>
> Regards,
> Evan
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg: Set Juno debug serial port defaults

[Ryan Harkin]

On 7 July 2016 at 17:01, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 7 July 2016 at 16:59, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> On Fri, Jul 01, 2016 at 12:52:06PM +0100, evan.ll...@arm.com wrote:
>>> From: Evan Lloyd <evan.ll...@arm.com>
>>>
>>> Juno has several serial ports, one of which may be used for a remote
>>> debug interface (e.g. gdb, WinDbg).  The debug serial port needs to
>>> be distinct from that used for UEFI trace to prevent corruption of
>>> debugger protocol messaging.
>>> The UEFI spec requires that serial devices be initialised to default
>>> settings. (11.8 Serial I/O Protocol - "The default attributes for all
>>> UART-style serial device interfaces are: 115,200 baud, ..."
>>> and 17.3.3 EFI Debugport Variable - "These defaults must be used in the
>>> absence of a DEBUGPORT variable...")
>>>
>>> This change adds initialization of the serial device reported in the
>>> ACPI DBG2 table.  The initialisation is done early in the boot to allow
>>> the possibility of remote debug of UEFI itself.
>>>
>>> NOTE: This is functionally dependent on the DBG2 table being updated in
>>> OpenPlatformPkg, but is required as a precursor to that change.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
>>> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
>>
>> I'd like a nod from Ryan on this one.
>
> As it happens, I've just finished testing it (on R0, R1 and R2):
>
> Tested-by: Ryan Harkin <ryan.har...@linaro.org>
>
>
>> One style comment below.
>>
>>> ---
>>>
>>> Notes:
>>> v2
>>> - No code change.
>>> - Clarified commit message in response to comments [Ard Bieshevel]
>>>   Specific points include clarity that change is not OS specific,
>>>   and pertains to any debugger use, and justification for doing it
>>>   at an early point in the process.
>>>   Confirmed with Leif that update here (not OpenPlatformPkg) is
>>>   appropriate.
>>>
>>>  ArmPlatformPkg/ArmPlatformPkg.dec   |  5 +++
>>>  ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf | 15 -
>>>  ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c  | 35 
>>> ++--
>>>  3 files changed, 52 insertions(+), 3 deletions(-)
>>>
>>> Code available at:
>>> https://github.com/EvanLloyd/tianocore/tree/debug_serial_v2
>>>
>>> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
>>> b/ArmPlatformPkg/ArmPlatformPkg.dec
>>> index 
>>> 1c05132cd625be75b0d9d1cd09950af983d1f049..5864d9835989382b79b1e6db6486fe67082df6a0
>>>  100644
>>> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
>>> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
>>> @@ -98,6 +98,11 @@ [PcdsFixedAtBuild.common]
>>>gArmPlatformTokenSpaceGuid.PL011UartFractional|0|UINT32|0x002D
>>>
>>> gArmPlatformTokenSpaceGuid.PL011UartInterrupt|0x|UINT32|0x002F
>>>
>>> +  ## PL011 Serial Debug UART
>>> +  
>>> gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x|UINT64|0x0030
>>> +  
>>> gArmPlatformTokenSpaceGuid.PcdSerialDbgUartBaudRate|0x|UINT64|0x0031
>>> +  
>>> gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|0x|UINT32|0x0032
>>> +
>>>## PL061 GPIO
>>>gArmPlatformTokenSpaceGuid.PcdPL061GpioBase|0x0|UINT32|0x0025
>>>
>>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
>>> b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>>> index 
>>> 8c8b141c35a2693b618c1515cb665b9b1e81cc4e..77d18f855a833fff0d38518436ef331dfab2d7e1
>>>  100644
>>> --- a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>>> +++ b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>>> @@ -1,5 +1,5 @@
>>>  #
>>> -#  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
>>> +#  Copyright (c) 2013-2016, ARM Limited. All rights reserved.
>>>  #
>>>  #  This program and the accompanying materials
>>>  #  are licensed and made available under the terms and conditions of the 
>>> BSD License
>>> @@ -57,6 +57,19 @@ [FixedPcd]
>>>gArmJunoTokenSpaceGuid.PcdPciConfigurationSpaceBaseAddress
>>>

Re: [edk2] [PATCH] ArmPlatformPkg: Set Juno debug serial port defaults

[Ryan Harkin]

On 7 July 2016 at 16:59, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Fri, Jul 01, 2016 at 12:52:06PM +0100, evan.ll...@arm.com wrote:
>> From: Evan Lloyd <evan.ll...@arm.com>
>>
>> Juno has several serial ports, one of which may be used for a remote
>> debug interface (e.g. gdb, WinDbg).  The debug serial port needs to
>> be distinct from that used for UEFI trace to prevent corruption of
>> debugger protocol messaging.
>> The UEFI spec requires that serial devices be initialised to default
>> settings. (11.8 Serial I/O Protocol - "The default attributes for all
>> UART-style serial device interfaces are: 115,200 baud, ..."
>> and 17.3.3 EFI Debugport Variable - "These defaults must be used in the
>> absence of a DEBUGPORT variable...")
>>
>> This change adds initialization of the serial device reported in the
>> ACPI DBG2 table.  The initialisation is done early in the boot to allow
>> the possibility of remote debug of UEFI itself.
>>
>> NOTE: This is functionally dependent on the DBG2 table being updated in
>> OpenPlatformPkg, but is required as a precursor to that change.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
>> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
>
> I'd like a nod from Ryan on this one.

As it happens, I've just finished testing it (on R0, R1 and R2):

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


> One style comment below.
>
>> ---
>>
>> Notes:
>> v2
>> - No code change.
>> - Clarified commit message in response to comments [Ard Bieshevel]
>>   Specific points include clarity that change is not OS specific,
>>   and pertains to any debugger use, and justification for doing it
>>   at an early point in the process.
>>   Confirmed with Leif that update here (not OpenPlatformPkg) is
>>   appropriate.
>>
>>  ArmPlatformPkg/ArmPlatformPkg.dec   |  5 +++
>>  ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf | 15 -
>>  ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c  | 35 
>> ++--
>>  3 files changed, 52 insertions(+), 3 deletions(-)
>>
>> Code available at:
>> https://github.com/EvanLloyd/tianocore/tree/debug_serial_v2
>>
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
>> b/ArmPlatformPkg/ArmPlatformPkg.dec
>> index 
>> 1c05132cd625be75b0d9d1cd09950af983d1f049..5864d9835989382b79b1e6db6486fe67082df6a0
>>  100644
>> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
>> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
>> @@ -98,6 +98,11 @@ [PcdsFixedAtBuild.common]
>>gArmPlatformTokenSpaceGuid.PL011UartFractional|0|UINT32|0x002D
>>gArmPlatformTokenSpaceGuid.PL011UartInterrupt|0x|UINT32|0x002F
>>
>> +  ## PL011 Serial Debug UART
>> +  
>> gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x|UINT64|0x0030
>> +  
>> gArmPlatformTokenSpaceGuid.PcdSerialDbgUartBaudRate|0x|UINT64|0x0031
>> +  
>> gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|0x|UINT32|0x0032
>> +
>>## PL061 GPIO
>>gArmPlatformTokenSpaceGuid.PcdPL061GpioBase|0x0|UINT32|0x0025
>>
>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
>> b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>> index 
>> 8c8b141c35a2693b618c1515cb665b9b1e81cc4e..77d18f855a833fff0d38518436ef331dfab2d7e1
>>  100644
>> --- a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>> +++ b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
>> @@ -1,5 +1,5 @@
>>  #
>> -#  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
>> +#  Copyright (c) 2013-2016, ARM Limited. All rights reserved.
>>  #
>>  #  This program and the accompanying materials
>>  #  are licensed and made available under the terms and conditions of the 
>> BSD License
>> @@ -57,6 +57,19 @@ [FixedPcd]
>>gArmJunoTokenSpaceGuid.PcdPciConfigurationSpaceBaseAddress
>>gArmJunoTokenSpaceGuid.PcdPciConfigurationSpaceSize
>>
>> +
>> +  #
>> +  # PL011 Serial Debug UART
>> +  #
>> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase
>> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgUartBaudRate
>> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz
>> +
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
>> +  gEfiM

Re: [edk2] [RFC V3.1] Proposal to organize packages into directories

[Ryan Harkin]

On 26 June 2016 at 16:44, Leif Lindholm  wrote:
> So, I managed to miss this thread for the longest time ... sorry about
> the late comments.
>
> On Fri, Jun 17, 2016 at 10:51:47PM +, Kinney, Michael D wrote:
>> Hello,
>>
>> Please review this one.  I missed a few updates to the dir changes
>> in edk2/master near the bottom.
>>
>> I have looked through all the feedback from the mail threads below
>> and updated this RFC to V3.
>>
>>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/12364
>>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/12754
>>
>> Please let me know if I missed any feedback and if there is new
>> feedback on this revised proposal for the directory structure or the
>> directory names.
>>
>> I have setup a branch with this directory structure in this proposal to help
>> with the review.  I have verified that I can build some platforms in this
>> branch using the PACKAGES_PATH settings shown below.
>>
>> https://github.com/mdkinney/edk2/tree/NewDirStruct_V3
>>
>> ==
>>
>> Updates in V3:
>>
>> ==
>>
>> * IntelFspPkg   -> Silicon/Intel
>> * IntelFspWrapperPkg-> Silicon/Intel
>> * IntelFsp2Pkg  -> Silicon/Intel
>> * IntelFsp2WrapperPkg   -> Silicon/Intel
>> * CorebootModulePkg -> Driver
>> * EmulatorPkg   -> Platform/Common
>> * Nt32Pkg   -> Platform/Common
>>Merge into EmulatorPkg in future
>> * UnixPkg   -> Deprecated
>>Next step is a request to delete
>> * BeagleBoardPkg-> Platform/BeagleBoard
>> * Omap35xxPkg   -> Silicon/TexasInstruments
>> * IntelSiliconPkg   -> Silicon/Intel
>>
>> ==
>>
>>
>>
>> ==
>>
>> Updates in V2:
>>
>> ==
>>
>> * IntelFrameworkModulePkg   -> Deprecated
>> * IntelFrameworkPkg -> Deprecated
>> * IntelFspPkg   -> Deprecated
>> * IntelFspWrapperPkg-> Deprecated
>> * PerformancePkg-> Deprecated
>> * CorebootPayloadPkg-> Platform
>> * EmbeddedPkg   -> Driver
>> * ArmPlatformPkg/ArmJunoPkg -> Silicon/Arm/ArmJunoPkg
>> * ArmPlatformPkg/ArmVExpressPkg -> Silicon/Arm/ ArmVExpressPkg
>> * Change Drivers to Driver so no top level directories are plural.
>> * Remove Vendor directory from Silicon and Platform to reduce directory depth
>> * Add Platform/Common directory for non-vendor specific platform packages
>> * Add Silicon/Common directory for non-vendor specific packages of
>>   CPU/Chipset/SoC drivers
>> * Keep Vendor directory in Driver.
>>   Non-vendor specific packages of drivers are flat just below Driver.
>>   Provides area to migrate non-vendor specific drivers from Core over time
>>
>> ==
>>
>>
>>
>> 
>>
>> # EDK II - Proposal to organize packages into directories
>>
>> There have been some discussions about organizing packages into directories.
>> Below is a proposal for a top level directory structure and a mapping of the
>> packages from edk2/master.  Where applicable, vendor specific directories
>> can be added.
>>
>> The PACKAGES_PATH feature documented in the link below is used to support
>> this proposed directory structure with no source file changes.  An example
>> of setting PACKAGES_PATH in a windows environment is also shown below and
>> I have verified that platforms can be built using this proposal.
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace
>>
>> # Top Level Directory Structure (Listed Alphabetically)
>>
>> ```
>>
>> edk2
>>   Application Applications and application support libraries
>>   BaseTools   EDK II build tools/scripts
>>   ConfEDK II build configuration files
>>   CorePlatform agnostic packages for core FW services
>>   Deprecated  Packages that may be removed from edk2/master
>>   Driver  EDK II Drivers (no platform assumptions)
>> Non-Vendor specific EDK II drivers
>> Non-Vendor specific EDK II drivers
>> . . .
>> VendorVendor specific EDK II drivers
>>   
>>   
>
> Following on to the previous discussions, I still like the idea of
> separate platform (PEI) drivers and UEFI drivers directories. The
> former could be the Vendor portion.
> However, I also agree with Jordan that for UEFI drivers, the
> Linux-style functional organisation makes more sense. (You are more
> likely to want maintainers/reviewers to pay attention to all devices
> of one type rather than all devices from one manufacturer.)
>
>>   PlatformPlatforms used to validate edk2/master features
>> Arm   ARM specific platform packages
>> BeagleBoard   Beagle Board specific platform packages
>
> If this refers to BeagleBoard as in BeagleBoard.org, as 

Re: [edk2] [Linaro-uefi] [PATCH 0/2] Marvell Yukon MAC address configuration on Juno platform

[Ryan Harkin]

On 7 June 2016 at 01:22, Daniil Egranov <daniil.egra...@arm.com> wrote:
> The patches add a new device configuration protocol and use it to configure
> a Marvell Yukon controller on the Juno platform with a valid MAC address.
>
> The device configuration protocol will enable a driver to reconfigure device
> specific settings before driver is started. As an example, the Juno Marvell
> Yukon NIC MAC address which has to be configured before the driver bound to
> the controller. The device configuration protocol defined as generic and
> supports multiple controllers per driver and multiple types of configuration
> per controller. Depending on the driver's protocol implementation, the
> configuration can be defined as "read/write" or "read only" and set to or
> get from a driver based on specified controller and its supported
> configuration type.
>
> Daniil Egranov (2):
>   ArmPlatformPkg/ArmJunoDxe: Configure Marvell Yukon MAC address on Juno
>   EmbeddedPkg: Added device configure protocol
>
>  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 100 +++-
>  .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf   |   1 +
>  .../Drivers/ArmJunoDxe/ArmJunoDxeInternal.h|   3 +
>  EmbeddedPkg/EmbeddedPkg.dec|   1 +
>  .../Include/Protocol/EmbeddedDeviceConfig.h| 127 
> +
>  5 files changed, 229 insertions(+), 3 deletions(-)
>  create mode 100644 EmbeddedPkg/Include/Protocol/EmbeddedDeviceConfig.h
>

For the series:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

I tested this in conjunction with the driver that Daniil has posted to
the OpenPlatformPkg tree.  I used Juno R0, R1 and R2 to run the code,
where only R1 and R2 have the Marvell device.



> --
> 2.7.4
>
> ___
> Linaro-uefi mailing list
> linaro-u...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-uefi
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg: Fix the wrong IpSb->State update

[Ryan Harkin]

On 22 June 2016 at 12:14, Jiaxin Wu <jiaxin...@intel.com> wrote:
> This patch is used to fix the wrong IpSb->State update issue.
>
> Issue reproduce steps:
> 1 .First PXE boot, then boot to shell;
> 2. ifconfig -s eth0 dhcp (Success);
> 3. Reboot and do PXE, then boot to shell;
> 4. ifconfig -s eth0 dhcp (Platform failed to get IP address no matter
>how many times retried.)
>
> Root cause:
> On step3 reboot, policy is DHCP (Changed by step2). So, Ip4Dxe driver
> will try to get one IP address from DHCP server automatically. Before
> it get the IP address successfully, the IpSb->State will be always in
> IP4_SERVICE_STARTED status until the Instance->Dhcp4Event is triggered,
> then it can be changed to IP4_SERVICE_CONFIGED. But the DHCP process
> will be interrupted by PXE boot, which will change the policy to static,
> and the Instance->Dhcp4Event will be also closed directly. However,
> current implementation doesn't update the IpSb->State to
> IP4_SERVICE_UNSTARTED status in such case. So, failure happened.
>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Cc: Ryan Harkin <ryan.har...@linaro.org>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>

I tested this on Juno ARM Development Platform and it now works as expected.

I still have a problem with Versatile Express TC2 that is fixed by
reverting commit 7648748e99eeeadec38fda7568adb260c4acc861, however it
is a different problem than the one fixed in this patch.  I'll
investigate that further and report back if/when I find out more.

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>
Tested-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> index d0fa132..10d7181 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> @@ -140,11 +140,11 @@ Ip4Config2OnPolicyChanged (
>IpSb->DefaultInterface  = IpIf;
>InsertHeadList (>Interfaces, >Link);
>IpSb->DefaultRouteTable = RouteTable;
>Ip4ReceiveFrame (IpIf, NULL, Ip4AccpetFrame, IpSb);
>
> -  if (IpSb->State == IP4_SERVICE_CONFIGED) {
> +  if (IpSb->State == IP4_SERVICE_CONFIGED || IpSb->State == 
> IP4_SERVICE_STARTED) {
>  IpSb->State = IP4_SERVICE_UNSTARTED;
>}
>
>//
>// Start the dhcp configuration.
> --
> 1.9.5.msysgit.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

On 22 June 2016 at 09:45, Wu, Jiaxin <jiaxin...@intel.com> wrote:
> Hi Ryan,
> I have root cause the issue:
>

Wow!  You found it!  I'm very pleased about that :-)


> Let me analyze this problem for you according below steps:
> 1 .First PXE boot, then boot to shell;
> 2. ifconfig -s eth0 dhcp (Success);
> 3. Reboot and do PXE, then boot to shell;> The issue is enrolled by 
> here
>
> On this reboot, policy is DHCP (Changed by step2). So, Ip4Dxe driver will try 
> to get one IP address from DHCP server automatically. Before it get the IP 
> address successfully, the IpSb->State will be always in IP4_SERVICE_STARTED 
> status until the Instance->Dhcp4Event is triggered, then it can be changed to 
> IP4_SERVICE_CONFIGED. But the DHCP process will be interrupted by PXE boot, 
> which will change the policy to static, and the Instance->Dhcp4Event will be 
> also closed directly. However, current implementation doesn't update the 
> IpSb->State to IP4_SERVICE_UNSTARTED status in such case. So, failure 
> happened!
>

That makes perfect sense.


> Why not happened in simulator platform? Because Ip4Dxe driver finished the 
> DHCP process (DORA) and the IpSb->State has been changed to 
> IP4_SERVICE_CONFIGED before PXE set the policy to DHCP.
>

Ah, a timing problem!


> 4. ifconfig -s eth0 dhcp (Platform failed to get IP address no matter how 
> many times retried.)
>
>
> The corresponding patch will be send out later to fix this issue, so, please 
> help to verify it.
>

Thanks a lot for looking at this.  I'm happy to test a fix.

Perhaps you could also consider adding this diff into your fix?  It's
slightly more efficient in the case with no error, but I think it's a
little bit easier to follow the flow and intention of the code with my
diff.

But it's ok if you don't like it, it's your code.

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index d0fa132..7757718 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -940,22 +940,21 @@ Ip4StartAutoConfig (
  >Dhcp4Handle
  );

-  if (Status == EFI_UNSUPPORTED) {
-//
-// No DHCPv4 Service Binding protocol, register a notify.
-//
-if (Instance->Dhcp4SbNotifyEvent == NULL) {
-  Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (
-   ,
-   TPL_CALLBACK,
-   Ip4Config2OnDhcp4SbInstalled,
-   (VOID *) Instance,
-   >Registration
-   );
-}
-  }
-
   if (EFI_ERROR (Status)) {
+if (Status == EFI_UNSUPPORTED) {^M
+  //^M
+  // No DHCPv4 Service Binding protocol, register a notify.^M
+  //^M
+  if (Instance->Dhcp4SbNotifyEvent == NULL) {^M
+Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (^M
+
,^M
+ TPL_CALLBACK,^M
+ Ip4Config2OnDhcp4SbInstalled,^M
+ (VOID *) Instance,^M
+ >Registration^M
+ );^M
+  }^M
+}^M
 return Status;
   }


Regards,
Ryan.





>
> Thanks and Best Regard!
> Jiaxin
>
>
>> -Original Message-
>> From: Wu, Jiaxin
>> Sent: Wednesday, June 22, 2016 11:35 AM
>> To: 'Ryan Harkin' <ryan.har...@linaro.org>
>> Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; 'edk2-
>> devel-01' <edk2-devel@lists.01.org>
>> Subject: RE: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4
>> config policy
>>
>> Hi Ryan,
>> I can reproduce the issue on my real platform now, thank you for your
>> reporting. I will find the root cause and fix it. If have any process, I 
>> will inform
>> you.
>>
>> Thanks again.
>> Jiaxin
>>
>> > -Original Message-
>> > From: Wu, Jiaxin
>> > Sent: Wednesday, June 22, 2016 10:41 AM
>> > To: Ryan Harkin <ryan.har...@linaro.org>
>> > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>;
>> > edk2-
>> > devel-01 <edk2-devel@lists.01.org>
>> > Subject: RE: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4
>> > config policy
>> >
>> > Ryan,
>> >
>> > > There could be a bug here, I suppose.  Why is
>> > > NetLibCreateServiceChild returning EFI_UNSUPPORTED?  I guess I need
&

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

Hi Jiaxin,

On 21 June 2016 at 12:20, Ryan Harkin <ryan.har...@linaro.org> wrote:
> Hi Jiaxin,
>
> On 21 June 2016 at 12:10, Wu, Jiaxin <jiaxin...@intel.com> wrote:
>> Hi Ryan,
>>
>> I can't reproduce your issue on NT32, I will try it in a real platform later.
>>
>
> I am unable to reproduce the problem on my "FVP models" (a type of
> emulator) either.  The models use a different ethernet device than my
> hardware.
>
>
>>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s
>>> eth0 dhcp" works.   On reboot, policy is dhcp, PXE changes it a couple
>>> of times, then drops to the shell with is set to static again.
>>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot.
>>
>> First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then PXE --> 
>> ifconfig -s eth0 dhcp (Your platform failed here, but my parts is always in 
>> a success no matter how many times I tried.)
>>
>>> It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0 
>>> dhcp" that
>>> DHCP obtains an IP address again.
>>>
>>> It could easily be a bug in the LAN9118 driver too, but there's a bug
>>> somewhere, because it isn't working as we expect  :-O
>>
>> So, to help us analyze problem, could you sent me one wireshark packet for 
>> the above steps?
>>
>
> I don't have wireshark set up, but I'll try to get it working and send
> you a trace.
>
> However, I suspect that DHCP service (Is that the DORA you mentioned?)
> is not being restarted for some reason, so in that case, no packets
> would be sent out.
>
> I don't know how the DHCP service is handled or started, but I'll try
> and find the points in the code where it's started and stopped and add
> some trace to see if there are any errors.  Any suggestions of where
> to place some DEBUG would be welcome.
>

I decided to add DEBUG statements to function Ip4StartAutoConfig in
Ip4Config2Impl.c.  I appended my DEBUG to the end of each line, so I
didn't change the line numbering when compared to the upstream
version, currently last modified here:
364f4efa444150df3f074f563374dce1e153adc6

The debug code I added to each branch in the function looks like this:

DEBUG ((EFI_D_ERROR, "%a:%d Instance->Policy=%d\n", __FUNCTION__,
__LINE__, Instance->Policy));

Therefore, I can trace which branches the code is taking.

On first boot, as expected, I can see that Ip4StartAutoConfig is not
called at all.  The default policy is static, so I'd expect that.

Then, when I configure DHCP from Shell, I see the following debug:

Ip4StartAutoConfig:921 Instance->Policy=0
Ip4StartAutoConfig:1032 Instance->Policy=0

This tells me that NetLibCreateServiceChild, gBS->OpenProtocol and
Dhcp4->Configure succeeded and the DHCP process was started.

That all looks good.  So I reset the board and see this debug on boot:

Warning: LAN9118 Driver in stopped state
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:943 Instance->Policy=1
Ip4StartAutoConfig:947 Instance->Policy=1
Ip4StartAutoConfig:958 Instance->Policy=1
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:943 Instance->Policy=1
Ip4StartAutoConfig:958 Instance->Policy=1
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:962 Instance->Policy=1
Ip4StartAutoConfig:1032 Instance->Policy=1
EhcExecTransfer: transfer failed with 2
EhcControlTransfer: error - Device Error, transfer - 2
Press ENTER to boot now or any other key to show the Boot Menu in 8 seconds

Booting EFI USB Device
Booting EFI Misc Device
Booting EFI Misc Device 1
Booting EFI Network
..PXE-E99: Unexpected network error.
Booting EFI Internal Shell
add-symbol-file
/working/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
0xF86C4000
Loading driver at 0x000F86C3000 EntryPoint=0x000F86C4000 Shell.efi

Shell> ifconfig -s eth0 dhcp
Ip4StartAutoConfig:921 Instance->Policy=0
Ip4StartAutoConfig:924 Instance->Policy=0


So I can see that on boot, because the saved policy is DHCP, the code
taking a few error branches.

First off "NetLibCreateServiceChild" returns EFI_UNSUPPORTED.  The
comments say this means "No DHCPv4 Service Binding protocol, register
a notify.".  Dhcp4SbNotifyEvent is NULL, so we create a notify event.

There could be a bug here, I suppose.  Why is NetLibCreateServiceChild
returning EFI_UNSUPPORTED?  I guess I need to investigate this some
more.

Continuing, at this point Status is still EFI_UNSUPPORTED, so this is
caught line 958 and we return from the function.  That looks like a
bug.  If not, it could do with a comment explaining why we've just
handled the EFI_UNSUPP

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

Hi Jiaxin,

On 21 June 2016 at 12:10, Wu, Jiaxin <jiaxin...@intel.com> wrote:
> Hi Ryan,
>
> I can't reproduce your issue on NT32, I will try it in a real platform later.
>

I am unable to reproduce the problem on my "FVP models" (a type of
emulator) either.  The models use a different ethernet device than my
hardware.


>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s
>> eth0 dhcp" works.   On reboot, policy is dhcp, PXE changes it a couple
>> of times, then drops to the shell with is set to static again.
>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot.
>
> First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then PXE --> 
> ifconfig -s eth0 dhcp (Your platform failed here, but my parts is always in a 
> success no matter how many times I tried.)
>
>> It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0 dhcp" 
>> that
>> DHCP obtains an IP address again.
>>
>> It could easily be a bug in the LAN9118 driver too, but there's a bug
>> somewhere, because it isn't working as we expect  :-O
>
> So, to help us analyze problem, could you sent me one wireshark packet for 
> the above steps?
>

I don't have wireshark set up, but I'll try to get it working and send
you a trace.

However, I suspect that DHCP service (Is that the DORA you mentioned?)
is not being restarted for some reason, so in that case, no packets
would be sent out.

I don't know how the DHCP service is handled or started, but I'll try
and find the points in the code where it's started and stopped and add
some trace to see if there are any errors.  Any suggestions of where
to place some DEBUG would be welcome.

Thanks,
Ryan.


> Thanks and Best Regards!
> Jiaxin
>
>
>
>
>
>
>
>> -Original Message-
>> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
>> Sent: Tuesday, June 21, 2016 5:32 PM
>> To: Wu, Jiaxin <jiaxin...@intel.com>
>> Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; edk2-
>> devel-01 <edk2-devel@lists.01.org>
>> Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4
>> config policy
>>
>> Hi Jiaxin,
>>
>> Thanks for spending time investigating this, I appreciate it.
>>
>>
>> On 21 June 2016 at 09:46, Wu, Jiaxin <jiaxin...@intel.com> wrote:
>> > Hi Ryan,
>> >
>> > First, I want confirm with you that which version code do you used? Edk2
>> latest one? If not, I strongly recommend to update it.
>> > https://github.com/tianocore/edk2.git
>> >
>>
>> I'm using recent code, this is the commit I'm based on:
>>
>> d8d217c  2016-06-16  MdePkg: MTftp6: Correct #define value in Mtfp6.h
>> [hegdenag]
>>
>> I see there are a few more recent commits, some of them in NetworkPkg, so
>> I'll rebase to the very latest again, although I don't expect it will solve 
>> my
>> problem.
>>
>>
>> > Based on the latest edk2 code, the IPv4 address used in PXE (got from
>> DHCP process) won't be assigned to NIC interface after PXE boot.
>>
>> Yes, that's what I expected.
>>
>>
>>
>> > So, there is no IP address assigned to eth0. But with the command of
>> "ifconfig -s eth0 dhcp" in shell, there should be a temporary IPv4 address
>> assigned to eth0 and the policy change to DHCP.
>> >
>>
>> That's what is failing after the first boot.
>>
>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s
>> eth0 dhcp" works.   On reboot, policy is dhcp, PXE changes it a couple
>> of times, then drops to the shell with is set to static again.
>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot.
>>
>> It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0 dhcp" 
>> that
>> DHCP obtains an IP address again.
>>
>> It could easily be a bug in the LAN9118 driver too, but there's a bug
>> somewhere, because it isn't working as we expect  :-O
>>
>>
>> > After you retry the PXE boot, the policy will change to static again (PXE 
>> > set it
>> to static) and no IP address assigned to eth0. This is an expected behavior.
>> >
>>
>> Yes, I see that.
>>
>>
>> > Now, below are the steps and the result I tried according your description:
>> > 1. Stop the PXE server;
>> > 2. Boot PXE option failed ,then boot to shell;> ifconfig -l 
>> > eth0, no IP
>> address, policy is static.

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

Hi Jiaxin,

Thanks for spending time investigating this, I appreciate it.


On 21 June 2016 at 09:46, Wu, Jiaxin <jiaxin...@intel.com> wrote:
> Hi Ryan,
>
> First, I want confirm with you that which version code do you used? Edk2 
> latest one? If not, I strongly recommend to update it.
> https://github.com/tianocore/edk2.git
>

I'm using recent code, this is the commit I'm based on:

d8d217c  2016-06-16  MdePkg: MTftp6: Correct #define value in Mtfp6.h
 [hegdenag]

I see there are a few more recent commits, some of them in NetworkPkg,
so I'll rebase to the very latest again, although I don't expect it
will solve my problem.


> Based on the latest edk2 code, the IPv4 address used in PXE (got from DHCP 
> process) won't be assigned to NIC interface after PXE boot.

Yes, that's what I expected.



> So, there is no IP address assigned to eth0. But with the command of 
> "ifconfig -s eth0 dhcp" in shell, there should be a temporary IPv4 address 
> assigned to eth0 and the policy change to DHCP.
>

That's what is failing after the first boot.

On first boot, policy is static, it gets changed to DHCP, "ifconfig -s
eth0 dhcp" works.   On reboot, policy is dhcp, PXE changes it a couple
of times, then drops to the shell with is set to static again.
"ifconfig -s eth0 dhcp" fails no matter how many times I reboot.

It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0
dhcp" that DHCP obtains an IP address again.

It could easily be a bug in the LAN9118 driver too, but there's a bug
somewhere, because it isn't working as we expect  :-O


> After you retry the PXE boot, the policy will change to static again (PXE set 
> it to static) and no IP address assigned to eth0. This is an expected 
> behavior.
>

Yes, I see that.


> Now, below are the steps and the result I tried according your description:
> 1. Stop the PXE server;
> 2. Boot PXE option failed ,then boot to shell;> ifconfig -l eth0, 
> no IP address, policy is static.
> 3. In shell, Enter the command "ifconfig -s eth0 dhcp" to set the policy to 
> DHCP> ifconfig -l eth0, have an IP address, policy is dhcp.

Yes, this works for me on first boot.


> 4. Enter the command "ifconfig -s eth0 static 192.168.1.31 255.255.255.0 
> 192.168.1.1" to change the policy to static;> ifconfig -l eth0, 
> have an IP address 192.168.1.31, policy is static.
> 5. Try PXE boot failed again ,then boot to shell;> ifconfig -l 
> eth0, have an IP address 192.168.1.31, policy is static.

I haven't tried PXE boot without rebooting, I should try that also...


> 6. Enter the command "ifconfig -s eth0 dhcp" to set the policy to DHCP
> > ifconfig -l eth0, have an IP address, policy is dhcp.
>
>
> Thanks.
> Jiaxin
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ryan Harkin
>> Sent: Tuesday, June 21, 2016 2:33 PM
>> To: Wu, Jiaxin <jiaxin...@intel.com>
>> Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; edk2-
>> devel-01 <edk2-devel@lists.01.org>
>> Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4
>> config policy
>>
>> On 21 Jun 2016 04:43, "Wu, Jiaxin" <jiaxin...@intel.com> wrote:
>> >
>> > Hi Ryan,
>> >
>> > Feedback see below:
>> >
>> > Thanks and Best Regards!
>> > Jiaxin
>> >
>> > > -Original Message-
>> > > From: Ryan Harkin [mailto:ryan.har...@linaro.org]
>> > > Sent: Tuesday, June 21, 2016 2:09 AM
>> > > To: Wu, Jiaxin <jiaxin...@intel.com>
>> > > Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Ye, Ting
>> > > <ting...@intel.com
>> >;
>> > > Fu, Siyuan <siyuan...@intel.com>
>> > > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default
>> > > IPv4 config policy
>> > >
>> > > Hi Jiaxin,
>> > >
>> > > Ever since this patch (below), I've been having problems with DHCP
>> > > on my boards.
>> > >
>> > > I've isolated the problem and can reproduce it every time now.
>> > >
>> > > If I allow the board to auto boot, it tries to PXE boot, fails (I've
>> stopped my
>> > > TFTP server on purpose to trigger the failure), drops to shell.
>> >
>> > Since you stop the TFTP server, I suppose this failure is expected.
>> >
>> >
>>
>> Correct, I did it on purpose so I could reproduce this bug.
>>
>> >

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

On 21 Jun 2016 04:43, "Wu, Jiaxin" <jiaxin...@intel.com> wrote:
>
> Hi Ryan,
>
> Feedback see below:
>
> Thanks and Best Regards!
> Jiaxin
>
> > -----Original Message-
> > From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> > Sent: Tuesday, June 21, 2016 2:09 AM
> > To: Wu, Jiaxin <jiaxin...@intel.com>
> > Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Ye, Ting <ting...@intel.com
>;
> > Fu, Siyuan <siyuan...@intel.com>
> > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4
> > config policy
> >
> > Hi Jiaxin,
> >
> > Ever since this patch (below), I've been having problems with DHCP on my
> > boards.
> >
> > I've isolated the problem and can reproduce it every time now.
> >
> > If I allow the board to auto boot, it tries to PXE boot, fails (I've
stopped my
> > TFTP server on purpose to trigger the failure), drops to shell.
>
> Since you stop the TFTP server, I suppose this failure is expected.
>
>

Correct, I did it on purpose so I could reproduce this bug.

>
> >
> >   Booting EFI Network
> >   ..PXE-E99: Unexpected network error.
> >   Booting EFI Internal Shell
> >
> > Then I use this command to configure eth0 as dhcp:
> >
> >   Shell> ifconfig -s eth0 dhcp
> >
> > I am also using this command to set eth0 as static:
> >
> >   Shell> ifconfig -s eth0 static 192.168.1.31 255.255.255.0 192.168.1.1
> >
> > On first boot, DHCP works from the shell.  (First boot == empty var
store) On
> > second and subsequent boots, DHCP fails.
>
> What does this failure mean? DHCP DORA is not triggered?

I don't know what DORA means, sorry.

But I meant that on boot, there is no IP address assigned to eth0 and
running "ifconfig -s eth0 dhcp" fails to get an IP address.

> If so, I think it's normal because you have gotten an IP address by
previous DHCP.

No, I only got an IP address on the previous boot, not on this boot.

> If you want to reset this IP address, you can use the command of "
ifconfig -r eth0 ".
>
>

I'll try that, but I don't expect it to work because I DHCP doesn't appear
to be working at all.

>From what I can tell, PXE Boot in Intel BDS is setting the IPv4 policy to
static and that appears to cause some problems.  I assume it sets the port
back to DHCP again, or else it wouldn't work, but I haven't successfully
traced that.

>
> > If I use configure eth0 static, then DHCP, it works again.
>
> Yes,  static->DHCP will trigger a new DHCP process(DORA).
>
>
>
> >
> > If I interrupt the boot sequence so that it doesn't attempt to PXE boot
and
> > simply run the shell, DHCP works every time.
>
> Yes, DHCP should work due to the policy has been changed to DHCP
(ifconfig -s eth0 dhcp). Once with DHCP policy, the platform will try to
get the IP by DHCP after you reset the platform.
>
>
>
> >
> > I don't believe this is the solution to the problem, but working out
what part
> > of the patch causes the problem for me show that if I remove the SetData
> > call from IpDriver.c, ln 592, then DHCP works every time.
> >
> > PXE boot works for me with or without the SetData call in place.
>
> Here, SetData can't be removed because the default IP configure data need
to be set after IP driver started (This default data can be changed by
other drivers).  You remove it, then DHCP works every time because the
default DHCP policy is not set in IP driver but you set it manually through
ifconfig tool. This is not the behavior we want.
>
> Current design rules is that once the DHCP successed, it won't try to
obtain a new address from DHCP(This is why "ifconfig -s eth0 dhcp" not
work). But you can refresh it though " ifconfig -r eth0 ".
>
> >
> > I've been trying to debug the problem and review the code to work out
why
> > it's failing, but I'm not getting very far.
> >
> > Are you (or is anyone else) able to explain why this is going wrong in
such a
> > predictable way?  Can you reproduce the behaviour on your systems?
> >
> > Is there anything you'd like me to try to isolate the real problem?
> >
> > Thanks,
> > Ryan.
> >
> >
> > On 25 February 2016 at 04:22, Jiaxin Wu <jiaxin...@intel.com> wrote:
> > > Git version '3d0a49ad' commit provided a scenario to resolve the
> > > performance issue for IPv4, but it's not workable for IPv6. To avoid
> > > IPv4 and IPv6 inconsistency, we decided to revert that version fix.
> > >
> > > If so, the default policy for Ip4Config2 is Ip4Config2PolicyDhcp,
> > > which results in all NIC

Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy

[Ryan Harkin]

Hi Jiaxin,

Ever since this patch (below), I've been having problems with DHCP on my boards.

I've isolated the problem and can reproduce it every time now.

If I allow the board to auto boot, it tries to PXE boot, fails (I've
stopped my TFTP server on purpose to trigger the failure), drops to
shell.

  Booting EFI Network
  ..PXE-E99: Unexpected network error.
  Booting EFI Internal Shell

Then I use this command to configure eth0 as dhcp:

  Shell> ifconfig -s eth0 dhcp

I am also using this command to set eth0 as static:

  Shell> ifconfig -s eth0 static 192.168.1.31 255.255.255.0 192.168.1.1

On first boot, DHCP works from the shell.  (First boot == empty var store)
On second and subsequent boots, DHCP fails.
If I use configure eth0 static, then DHCP, it works again.

If I interrupt the boot sequence so that it doesn't attempt to PXE
boot and simply run the shell, DHCP works every time.

I don't believe this is the solution to the problem, but working out
what part of the patch causes the problem for me show that if I remove
the SetData call from IpDriver.c, ln 592, then DHCP works every time.

PXE boot works for me with or without the SetData call in place.

I've been trying to debug the problem and review the code to work out
why it's failing, but I'm not getting very far.

Are you (or is anyone else) able to explain why this is going wrong in
such a predictable way?  Can you reproduce the behaviour on your
systems?

Is there anything you'd like me to try to isolate the real problem?

Thanks,
Ryan.


On 25 February 2016 at 04:22, Jiaxin Wu  wrote:
> Git version '3d0a49ad' commit provided a scenario to resolve the
> performance issue for IPv4, but it's not workable for IPv6. To
> avoid IPv4 and IPv6 inconsistency, we decided to revert that version
> fix.
>
> If so, the default policy for Ip4Config2 is Ip4Config2PolicyDhcp,
> which results in all NIC ports attempting DHCP. So, this patch is
> used to changes the the default IPv4 config policy to
> Ip4Config2PolicyStatic and also defer the SetData operation after
> Ip4Config2Protocol installed. This update let the other platform
> drivers have chance to change the default config data by consume
> Ip4Config2Protocol.
>
> Cc: Subramanian Sriram 
> Cc: El-Haj-Mahmoud Samer 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c  | 76 +-
>  .../Universal/Network/Ip4Dxe/Ip4Config2Impl.h  | 36 -
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c  | 57 +-
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf   |  2 +-
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 90 
> ++
>  5 files changed, 155 insertions(+), 106 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> index edbddba..1f763b6 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> @@ -1,9 +1,9 @@
>  /** @file
>The implementation of EFI IPv4 Configuration II Protocol.
>
> -  Copyright (c) 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
>(C) Copyright 2015 Hewlett Packard Enterprise Development LP
>
>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
> @@ -1142,11 +1142,13 @@ Ip4Config2SetPolicy (
>if (NewPolicy >= Ip4Config2PolicyMax) {
>  return EFI_INVALID_PARAMETER;
>}
>
>if (NewPolicy == Instance->Policy) {
> - return EFI_ABORTED;
> +if (NewPolicy != Ip4Config2PolicyDhcp || Instance->DhcpSuccess) {
> +  return EFI_ABORTED;
> +}
>} else {
>  if (NewPolicy == Ip4Config2PolicyDhcp) {
>//
>// The policy is changed from static to dhcp:
>// Clean the ManualAddress, Gateway and DnsServers, shrink the variable
> @@ -1906,11 +1908,11 @@ Ip4Config2InitInstance (
>
>DataItem   = >DataItem[Ip4Config2DataTypePolicy];
>DataItem->SetData  = Ip4Config2SetPolicy;
>DataItem->Data.Ptr = >Policy;
>DataItem->DataSize = sizeof (Instance->Policy);
> -  Instance->Policy   = Ip4Config2PolicyDhcp;
> +  Instance->Policy   = Ip4Config2PolicyStatic;
>SET_DATA_ATTRIB (DataItem->Attribute, DATA_ATTRIB_SIZE_FIXED);
>
>DataItem   = >DataItem[Ip4Config2DataTypeManualAddress];
>DataItem->SetData  = Ip4Config2SetMaunualAddress;
>DataItem->Status   = EFI_NOT_FOUND;
> @@ -1937,34 +1939,22 @@ Ip4Config2InitInstance (
>
>Instance->Configured  = TRUE;
>
>//
>// Try to read 

Re: [edk2] [PATCH 4/6] ArmPlatformPkg: Add support to configure PL011 UART clock

[Ryan Harkin]

On 28 May 2016 at 14:54,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> On some platforms the UART clock is not the same for all the serial
> ports. The PL011 driver must be capable of handling serial ports with
> different clock rates, so must not rely on a PCD for the clock rate.
>
> This patch allows the UART clock rate to be passed as a parameter
> to PL011UartInitializePort(), which is called from the serial port
> library. This patch also contains the corresponding changes in the
> serial port library.
>
> The PCD in Drivers/PL011Uart is replaced by an extra parameter for
> PL011UartInitializePort.  The PCD is moved to Library/PL011SerialPortLib
> to supply the value to pass.
>
> A corresponding patch to ArmVirtPkg is included in the same bundle to
> align that with these changes.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>

Minor comment below.  But I tested it on Juno R2 and FVP Foundation
and AEMV8 models anyway as it won't effect functionality.

I saw a hang on R2 that I know to be unrelated to this patch, but
thought I'd report it as I've not seen this specific hang before:


Installation of the FDT using the device path
<VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb> completed.
PCI: The size 0x7F00 of the region 0x8000 has been increased
to be a power of two for the AXI translation table.
PCI: The size 0x18000 of the region 0x88000 has been increased
to be a power of two for the AXI translation table.


Synchronous Exception at 0xFDFAFDCC
/working/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe/DEBUG/CpuIo2Dxe.dll
loaded at 0xFDFAE000

  X0 0x57F0   X1 0xFDFB4030   X2
0x57F0   X3 0x001A
  X4 0xFD5ACD98   X5 0xFDFAF4B4   X6
0x0008   X7 0x0020
  X8 0xFE113010   X9 0x0041  X10
0x0004  X11 0x
 X12 0x707FE07A  X13 0x  X14
0x  X15 0x
 X16 0xFEFFFBF0  X17 0x  X18
0x  X19 0xFE0C0018
 X20 0x  X21 0x  X22
0x  X23 0x
 X24 0x  X25 0x  X26
0x  X27 0x
 X28 0x   FP 0x   LR 0xFDFAF550

  V0 0x3C83709547545153 BC990E9F897D4FA8   V1 0xBEBEF297C5EC0578
E1D99AE8C2B92607
  V2 0x13242833C5F05BAB 101C24C521387481   V3 0x0A50ABCAD0BDDA12
996865483E880969
  V4 0x840084842863 08000538   V5 0x00010110001A4001
8E0202A1
  V6 0xA010290482010102 4042000A02400100   V7 0x8CC7020884C87814
78A5636F748F82EE
  V8 0x A4506CEB90BEFFFA   V9 0x
88C1883495C7F76F
 V10 0x 3DB8D233CF470963  V11 0x
4416D9F479B08221
 V12 0x 55B8AE51435C1A1A  V13 0x
C95B757DA62B3A12
 V14 0x E08479A1B557DFA8  V15 0x
927A0019CDEC1A76
 V16 0x21081A2640C0F178 0084C0048EC80F21  V17 0x1902182018B00C04
0001080284828304
 V18 0x00108004000C 590010803800  V19 0x8001804051402A9B
80480405
 V20 0x00980800104D 82000C000282  V21 0x01B0A5880048
38A0047001808220
 V22 0x8200024108502200 1200252080001002  V23 0x000F0080006290A2
B1601010040BA110
 V24 0x8401100100804000 0020010200812008  V25 0x280008A00108
200100E00C24
 V26 0x084020668104 4810C1178400  V27 0x90E2
A6201000C0028C04
 V28 0x802281000200 890080400880A022  V29 0x60850136
800489A520006304
 V30 0x080120008220 0384E25502959220  V31 0x4064084112940202
1000459804200800

  SP 0xFEFFF3F0  ELR 0xFDFAFDCC  SPSR 0x6309  FPSR
0x
 ESR 0x96000210  FAR 0x57F0

 ESR : EC 0x25  IL 0x1  ISS 0x0210

Data abort: Synchronous external abort
ASSERT [ArmCpuDxe]
/working/platforms/uefi/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(194):
((BOOLEAN)(0==1))


I reverted the patch and the problem still happens.  I reverted the
whole series and I can still reproduce the problem.  Ho hum.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>
> ---
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf   |  1 -
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf |  1 +
>  ArmPlatformPkg/Include/Drivers/PL011Uart.h   | 43 
> 
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c | 22 
> 

Re: [edk2] [PATCH 3/6] ArmPlatformPkg: Remove double write in PL011

[Ryan Harkin]

On 28 May 2016 at 14:54,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> The variable LineControl was initialised to zero, then updated in a
> condition.  This change converts that to a write in each branch of the
> condition, removing the Write/Read/Modify/Write sequence.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>

Tested on Juno R2 and FVP Foundation and AEMv8.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>
Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>


> ---
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c 
> b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> index 
> cd2cccad6295544b0b4d4c0aa4ceb7ac7b56a8e7..dd5f88d3d629d345a50af468ed394a269b35f52a
>  100644
> --- a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> +++ b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> @@ -73,20 +73,19 @@ PL011UartInitializePort (
>UINT32  LineControl;
>UINT32  Divisor;
>
> -  LineControl = 0;
> -
>// The PL011 supports a buffer of 1, 16 or 32 chars. Therefore we can 
> accept
>// 1 char buffer as the minimum FIFO size. Because everything can be 
> rounded
>// down, there is no maximum FIFO size.
>if ((*ReceiveFifoDepth == 0) || (*ReceiveFifoDepth >= 32)) {
>  // Enable FIFO
> -LineControl |= PL011_UARTLCR_H_FEN;
> +LineControl = PL011_UARTLCR_H_FEN;
>  if (PL011_UARTPID2_VER (MmioRead32 (UartBase + UARTPID2)) > 
> PL011_VER_R1P4)
>*ReceiveFifoDepth = 32;
>  else
>*ReceiveFifoDepth = 16;
>} else {
> -ASSERT (*ReceiveFifoDepth < 32);
> +// Disable FIFO
> +LineControl = 0;
>  // Nothing else to do. 1 byte FIFO is default.
>  *ReceiveFifoDepth = 1;
>}
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
>
> ___
> 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 2/6] ArmPlatformPkg: Update PL011 Serial PCDs to Fixed PCDs

[Ryan Harkin]

On 28 May 2016 at 14:54,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> The PCDs used in the PL011 UART Driver and Serial Port Library are
> inherently "fixed at build".  This change updates the source to use
> Fixed PCDs for these values.  This improves clarity and efficiency.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>

This introduces a few lines > 80 columns, but then also highlights
that the previous patch didn't fix some lines that were also over 80
columns wide too.

But otherwise, it looks fine and works fine too.

Tested on Juno R2 and FVP Foundation and AEMv8 models.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>
Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf   |  4 ++--
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf |  4 ++--
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c | 10 
> -
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c   | 22 
> ++--
>  4 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf 
> b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
> index 
> 18df7c9fb94431ffa1d2e8b4c06dfb82e53181e5..5afce36d3935e7fd79c25c46360d72328b2a571f
>  100644
> --- a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
> +++ b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
> @@ -2,7 +2,7 @@
>  #
>  #  Component description file for PL011Uart module
>  #
> -#  Copyright (c) 2011-2013, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011-2016, ARM Ltd. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -34,7 +34,7 @@ [Packages]
>MdeModulePkg/MdeModulePkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
>
> -[Pcd]
> +[FixedPcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate
>
>gArmPlatformTokenSpaceGuid.PL011UartClkInHz
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf 
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> index 
> 3a950d0788d481ab73408af41343dfcfa2378a6e..653c0b2dfc147f1d82155e4150812f0cb4c59e12
>  100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> @@ -2,7 +2,7 @@
>  #
>  #  Component description file for PL011SerialPortLib module
>  #
> -#  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011-2016, ARM Ltd. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -35,7 +35,7 @@ [Packages]
>MdeModulePkg/MdeModulePkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
>
> -[Pcd]
> +[FixedPcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
> diff --git a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c 
> b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> index 
> 006feab72e82f9735d11b471e031f8b149026ccf..cd2cccad6295544b0b4d4c0aa4ceb7ac7b56a8e7
>  100644
> --- a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> +++ b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> @@ -168,17 +168,17 @@ PL011UartInitializePort (
>//
>
>// If PL011 Integer value has been defined then always ignore the BAUD rate
> -  if (PcdGet32 (PL011UartInteger) != 0) {
> -  MmioWrite32 (UartBase + UARTIBRD, PcdGet32 (PL011UartInteger));
> -  MmioWrite32 (UartBase + UARTFBRD, PcdGet32 (PL011UartFractional));
> +  if (FixedPcdGet32 (PL011UartInteger) != 0) {
> +  MmioWrite32 (UartBase + UARTIBRD, FixedPcdGet32 (PL011UartInteger));
> +  MmioWrite32 (UartBase + UARTFBRD, FixedPcdGet32 (PL011UartFractional));
>} else {
>  // If BAUD rate is zero then replace it with the system default value
>  if (*BaudRate == 0) {
> -  *BaudRate = PcdGet32 (PcdSerialBaudRate);
> +  *BaudRate = FixedPcdGet32 (PcdSerialBaudRate);
>ASSERT (*BaudRate != 0);
>  }
>
> -Divisor = (PcdGet32 (PL011UartClkInHz) * 4) / *BaudRate;
> +Divisor = (FixedPcdGet32 (PL011UartClkInHz) * 4) / *BaudRate;
>  MmioWrite32 (UartBase + UARTIBRD, Divisor >> FRACTION_PART_SIZE_IN_BITS);
>  MmioWrite32 (UartBase + UARTFBRD, Divisor & FRACTION_PART_MASK);
>}
> diff -

Re: [edk2] [PATCH 1/6] ArmPlatformPkg: Tidy PL011 UART driver

[Ryan Harkin]

On 28 May 2016 at 14:54,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> This cosmetic change only tidies things up in preparation for actual
> updates. (This reflects responses to a previously submitted patch,
> which has been split into several discrete changes.)
> There are no functional changes in this commit.
> Changes comprise:
>   Minor corrections to comment typos.
>   Minor formatting mods (80 columns).
>   Expansion of function comments.
>   Remove OUT from UartBase parameter.
>   Addition of #define for "magic mumbers".
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>

A minor comment below, but otherwise, this looks fine.

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>

> ---
>  ArmPlatformPkg/Include/Drivers/PL011Uart.h | 21 -
>  ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c   | 99 
> +---
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 24 +++--
>  3 files changed, 99 insertions(+), 45 deletions(-)
>
> diff --git a/ArmPlatformPkg/Include/Drivers/PL011Uart.h 
> b/ArmPlatformPkg/Include/Drivers/PL011Uart.h
> index 
> 2fe796f9e42e663ae838a9559c16e237bf3db28b..8c2616ede4131b7504088d656160ce184dadf914
>  100644
> --- a/ArmPlatformPkg/Include/Drivers/PL011Uart.h
> +++ b/ArmPlatformPkg/Include/Drivers/PL011Uart.h
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
> +*  Copyright (c) 2011-2016, ARM Limited. All rights reserved.
>  *
>  *  This program and the accompanying materials
>  *  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -91,15 +91,30 @@
>
>  /*
>
> +  Initialise the serial port to the specified settings.
>Programmed hardware of Serial port.
> +  @param  UartBaseThe base address of the serial device.
> +  @param  BaudRateThe baud rate of the serial device. If the 
> baud rate is not supported,
> +  the speed will be reduced down to the 
> nearest supported one and the
> +  variable's value will be updated 
> accordingly.
> +  @param  ReceiveFifoDepthThe number of characters the device will 
> buffer on input.
> +  ReceiveFifoDepth value of 0 will use the 
> device's default FIFO depth.
> +  @param  Parity  If applicable, this is the EFI_PARITY_TYPE 
> that is computed or checked
> +  as each character is transmitted or 
> received. If the device does not
> +  support parity, the value is the default 
> parity value.
> +  @param  DataBitsThe number of data bits in each character
> +  @param  StopBitsIf applicable, the EFI_STOP_BITS_TYPE 
> number of stop bits per character.
> +  If the device does not support stop bits, 
> the value is the default stop
> +  bit value.
>
> -  @returnAlways return EFI_UNSUPPORTED.
> +  @retval RETURN_SUCCESSAll attributes were set correctly on the 
> serial device.
> +  @retval RETURN_INVALID_PARAMETER  One or more of the attributes has an 
> unsupported value.
>

This whole section blows the 80 column limit.  I'm not sure it matter
for comments.  Or at least, I don't mind comments running over the 80
column mark.  But the patch states that it's limiting things to 80
columns, so I thought I'd point it out.


>  **/
>  RETURN_STATUS
>  EFIAPI
>  PL011UartInitializePort (
> -  IN OUT UINTN   UartBase,
> +  IN UINTN   UartBase,
>IN OUT UINT64  *BaudRate,
>IN OUT UINT32  *ReceiveFifoDepth,
>IN OUT EFI_PARITY_TYPE *Parity,
> diff --git a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c 
> b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> index 
> 8b256de945d2115bf98de16e890bf944afc470a6..006feab72e82f9735d11b471e031f8b149026ccf
>  100644
> --- a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> +++ b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> @@ -2,7 +2,7 @@
>Serial I/O Port library functions with no library constructor/destructor
>
>Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
> -  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
> +  Copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -20,6 +20,9 @@
>
&g

Re: [edk2] [RFC] Proposal to organize packages into directories

[Ryan Harkin]

On 19 May 2016 at 14:35, Paolo Bonzini  wrote:
>
>
> On 18/05/2016 01:57, Kinney, Michael D wrote:
>>   Core
>> CorebootModulePkg
>> CorebootPayloadPkg
>
> I think that anything with a .fdf file should be under Platform.
> CorebootPayloadPkg is the only outlier in your proposal.
>
>> Emulated
>>   DuetPkg
>>   EmulatorPkg
>>   Nt32Pkg
>>   OvmfPkg
>
> I think OvmfPkg is not emulated; certainly not in the same sense as
> EmulatorPkg, Nt32 or UnixPkg.  DuetPkg also seems more similar to
> OvmfPkg than to EmulatorPkg (and definitely most similar to
> CorebootPayloadPkg, which should be under Platform according to the rule
> I proposed above).
>
> In addition, I think that separation by architecture is more useful than
> separation by vendor.  This yields the following:
>
> Platform
>   Arm
> ArmPlatformPkg
> ArmVirtPkg
> BeagleBoardPkg
>   Emulated
> EmulatorPkg
> Nt32Pkg
> UnixPkg
>   IA32X64
> CorebootPayloadPkg
> DuetPkg
> Intel
>   QuarkPlatformPkg
>   Vlv2TbltDevicePkg
> OvmfPkg
>
> IA32X64 is not a great name, but neither is Intel.  X86 suggests 32-bit
> only.
>

I prefer the idea of separating by vendor.  One vendor may have
multiple architectures, for example.

But I'm also not keen on the "Vendor" sub-dir itself, it seems redundant:

  Platform/Vendor/ARM
vs
  Platform/ARM

OK, so the emulated platforms don't have a "vendor" as such, but
"Emulated" could be as good a name as any.


> In addition, I am not sure about the separation between "Drivers" and
> "Silicon".  My proposal here is to unify them as follows:
>
> Drivers
>   FatPkg
>   NetworkPkg
>   OptionRomPkg
>   Arm
> ArmPkg
> Omap35xxPkg
>   IA32X64
> PcAtChipsetPkg
> QuarkSocPkg
> UefiCpuPkg
> Vlv2DeviceRefCodePkg
>
> or alternatively Omap35xxPkg, QuarkSocPkg and Vlv2DeviceRefCode could
> move under Drivers/Vendor/{Arm,Intel}.
>
> Thanks,
>
> Paolo
> ___
> 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 v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot timeout message

[Ryan Harkin]

On 5 May 2016 at 06:09, Ni, Ruiyu  wrote:
>
>
> Regards,
> Ray
>
>>-Original Message-
>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil 
>>Egranov
>>Sent: Thursday, May 5, 2016 8:07 AM
>>To: Ni, Ruiyu ; edk2-devel@lists.01.org
>>Cc: Fan, Jeff 
>>Subject: Re: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot 
>>timeout message
>>
>>Hi Ray,
>>
>>Thanks for the review. My answers below.
>>
>>Thanks,
>>Daniil
>>
>>On 05/04/2016 12:07 AM, Ni, Ruiyu wrote:
>>> 2 comments below.
>>>
>>> Regards,
>>> Ray
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Daniil Egranov
 Sent: Wednesday, May 4, 2016 9:34 AM
 To: edk2-devel@lists.01.org
 Cc: Fan, Jeff 
 Subject: [edk2] [PATCH v2 3/3] IntelFrameworkModulePkg/BdsDxe: Show boot 
 timeout message

 The PlatformBdsShowProgress() supports graphics mode only, which is not
 applicable for RS-232 serial console. Show the progress message as a 
 console
 text message in case PlatformBdsShowProgress() fails.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Daniil Egranov 
 ---
 IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 index 6958979..d1a5c05 100644
 --- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 +++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
 @@ -925,7 +925,7 @@ ShowProgress (
  // Show progress
  //
  if (TmpStr != NULL) {
 -  PlatformBdsShowProgress (
 +  Status = PlatformBdsShowProgress (
  Foreground,
  Background,
  TmpStr,
 @@ -933,12 +933,19 @@ ShowProgress (
  ((TimeoutDefault - TimeoutRemain) * 100 / TimeoutDefault),
  0
  );
 +  if (EFI_ERROR(Status)) {
 +//if graphics mode is not supported (serial console) show 
 text progress message
 +AsciiPrint ("\rPress any key to enter Boot Menu in %d seconds 
 ", TimeoutRemain);

When I was testing this patch, I noticed that if I press "enter", it
immediately continues to boot the configured boot entry.  If I press
any other key (in reality I only tried a few like 'x' and ESC) then it
goes to the Boot Menu.

I didn't see another revision yet in response to Ruiyu's comments, so
I figured I was in time for a quick mod.

I was thinking the message could get very complex, but thought
something like this might be better:

"Press ENTER to boot now or any other key to show the Boot Menu in %d
seconds "

 +  }
>>> 1. Why use AsciiPrint but not Print(L"")?
>>> I agree they are the same but normally we use Print().
>>>
>>
>>I was not sure which one to use. I'll correct it.
>>
> Thanks!
>
>
  }
}
  }

  if (TmpStr != NULL) {
gBS->FreePool (TmpStr);
 +if (EFI_ERROR(Status)) {
 +  AsciiPrint ("\n");
 +}
>>> 2. What's the purpose of the EOL here?
>>>
>>
>>The AsciiPrint above uses cartridge return without a new line so this
>>EOL preserves last message from being erased by other console outputs.
>>
> I see. Thanks! I agree!
>
  }

  //
 --
 2.7.4

 ___
 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] EmbeddedPkg/Lan9118Dxe MMIO fixes

[Ryan Harkin]

On 9 May 2016 at 11:07, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 9 May 2016 at 10:22, Mark Rutland <mark.rutl...@arm.com> wrote:
>> On Sat, May 07, 2016 at 10:43:45AM +0200, Ard Biesheuvel wrote:
>>> On 6 May 2016 at 19:19, Mark Rutland <mark.rutl...@arm.com> wrote:
>>> > The LAN9118 driver uses memory fences in a novel but erroneous fashion, 
>>> > due to
>>> > a misunderstanding of some under-commented code. This series fixes these
>>> > erroneous uses, documenting the unusual requirements of the LAN9118 chip 
>>> > that
>>> > lead us to this situation, and introduces new helpers to handle this in a 
>>> > more
>>> > consistent fashion.
>>> >
>>> > The LAN9118 datasheet is publicly available at:
>>> >
>>> > http://www.microchip.com/wwwproducts/en/LAN9118
>>> >
>>>
>>> Thanks a lot for getting to the bottom of this! I particularly like
>>> the way how you folded the required delays into the MMIO read/write
>>> functions, which makes the top level code a lot cleaner.
>>>
>>> I can't test this, but the code looks fine to me.
>>>
>
> I'll test it later today on TC2 and Juno R0/1/2.  But I like the look
> of it, it seems like a huge improvement.
>

This seems to work on TC2 and Juno R0, R1 and R2, although I'm not
100% sure it's reliable, so I need to do more testing.

When attempting to install debian over the network, my Juno R1 has
just reported:

LAN9118: There was an error transmitting. TxStatus=0x8401:- No carrier
- Packet tx was deferred

The 2nd attempt seems to be working fine.  Juno R0 and R2 seem happy enough.


>>> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>
>> Cheers!
>>
>> FWIW, I've tested each patch on Juno R1, and I haven't seen any
>> regression as a result of this. That said, I haven't been able to
>> trigger issues even without this series.
>>
>
> That'll be the problem I have too - it works fine for me as it is.  I
> guess Sudeep (CC'd) should give it a test too.
>
>
>> There's another latent bug that this doesn't solve, in that if the PHY
>> negotiates full-duplex operation (at 100Mb/s or 10Mb/s), but that
>> appears to be unrelated.
>>
>> Thanks,
>> Mark.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/ArmDmaLib: assert that consistent mappings are uncached

[Ryan Harkin]

On 20 April 2016 at 09:40, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> DmaMap () only allows uncached mappings to be used for creating consistent
> mappings with operation type MapOperationBusMasterCommonBuffer. However,
> if the buffer passed to DmaMap () happens to be aligned to the CWG, there
> is no need for a bounce buffer, and we perform the cache maintenance
> directly without ever checking if the memory attributes of the buffer
> adhere to the API.
>
> So add some debug code that asserts that the operation type and the memory
> attributes are consistent.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Tested-by: Ryan Harkin <ryan.har...@linaro.org>

Tested on TC2, Juno R0, R1 and R2, FVP Base AEMv8 and FVP Foundation models.

On FVP models, I just checked that they still booted.  On my Juno
boards, I checked that the USB disks were still readable and that I
could read my SATA drive.  On TC2, I made sure I could read an MMC
card; there is USB support on TC2.  I'm not even sure if the MMC card
driver uses DMA, but I thought I'd give it a spin anyway.


> ---
>
> This applies on top of the ArmDmaLib patches that I sent out yesterday.
> Based on the original code which contained some dodgy looking workarounds,
> I expect this to actually break something, but Olivier is not around anymore
> to tell me what he was trying to fix (and the broken 'promote cache
> mainantenance by VA to set/way above a certain threshold' may well have been
> the culprit here)
>
> Since the PCI emulation for non-coherent devices relies on this DMA code,
> any non-coherent real platform that uses the SATA or EHCI/UCHI code could
> be used to test this, but I don't have access to any of those. Suggestions
> are welcome, as are donations of a Juno or a TC2.
>
> Thanks.
>
>  ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
> b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> index 83f4d38a8a60..329756efc268 100644
> --- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> +++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> @@ -135,6 +135,23 @@ DmaMap (
>} else {
>  Map->DoubleBuffer  = FALSE;
>
> +DEBUG_CODE_BEGIN ();
> +
> +//
> +// The operation type check above only executes if the buffer happens to 
> be
> +// misaligned with respect to CWG, but even if it is aligned, we should 
> not
> +// allow arbitrary buffers to be used for creating consistent mappings.
> +// So duplicate the check here when running in DEBUG mode, just to assert
> +// that we are not trying to create a consistent mapping for cached 
> memory.
> +//
> +Status = gDS->GetMemorySpaceDescriptor (*DeviceAddress, );
> +ASSERT_EFI_ERROR(Status);
> +
> +ASSERT (Operation != MapOperationBusMasterCommonBuffer ||
> +(GcdDescriptor.Attributes & (EFI_MEMORY_WB | EFI_MEMORY_WT)) == 
> 0);
> +
> +DEBUG_CODE_END ();
> +
>  // Flush the Data Cache (should not have any effect if the memory region 
> is uncached)
>  gCpu->FlushDataCache (gCpu, *DeviceAddress, *NumberOfBytes, 
> EfiCpuFlushTypeWriteBackInvalidate);
>}
> --
> 2.5.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/9] MmcDxe: set iospeed and bus width in SD stack

[Ryan Harkin]

On 5 April 2016 at 11:18, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
> On 5 April 2016 at 17:49, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> On 5 April 2016 at 09:37, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>> On 5 April 2016 at 03:57, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
>>>> On 5 April 2016 at 01:17, Ryan Harkin <ryan.har...@linaro.org> wrote:
>>>>> Hi Haojian,
>>>>>
>>>>> I've had time to investigate where TC2 is hanging with your patches
>>>>> applied and narrowed it down to the single line of code marked below.
>>>>>
>>>>> I'm going to read the code now and see if I can work out what it's
>>>>> trying to do, but I thought I'd tell you sooner because you might have
>>>>> a better idea.
>>>>>
>>>>> On 22 March 2016 at 12:48, Haojian Zhuang <haojian.zhu...@linaro.org> 
>>>>> wrote:
>>>>>> Add more SD commands to support 4-bit bus width & iospeed. It's not
>>>>>> formal code. And it needs to be updated later.
>>>>>>
>>>>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>>>>> Signed-off-by: Haojian Zhuang <haojian.zhu...@linaro.org>
>>>>>> ---
>>>>>>  EmbeddedPkg/Include/Protocol/MmcHost.h   |   3 +
>>>>>>  EmbeddedPkg/Universal/MmcDxe/Mmc.h   |  17 +++
>>>>>>  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 138 
>>>>>> ---
>>>>>>  3 files changed, 142 insertions(+), 16 deletions(-)
>>>>>>
>>>>>> diff --git a/EmbeddedPkg/Include/Protocol/MmcHost.h 
>>>>>> b/EmbeddedPkg/Include/Protocol/MmcHost.h
>>>>>> index 5e3a2b7..e9a74f0 100644
>>>>>> --- a/EmbeddedPkg/Include/Protocol/MmcHost.h
>>>>>> +++ b/EmbeddedPkg/Include/Protocol/MmcHost.h
>
>>>>>> +
>>>>>> +  /* SCR */
>>>>>> +  Status = MmcHost->SendCommand (MmcHost, MMC_ACMD51, 0);
>>>>>> +  if (EFI_ERROR (Status)) {
>>>>>> +DEBUG ((EFI_D_ERROR, "%a(MMC_ACMD51): Error and Status = %r\n", 
>>>>>> __func__, Status));
>>>>>> +return Status;
>>>>>> +  } else {
>>>>>> +Status = MmcHost->ReadBlockData (MmcHost, 0, 8, Buffer);
>>>>>
>>>>> ^^ TC2 hangs at this line
>>>>>
>>>>
>>>> Ryan,
>>>>
>>>> Could you help to check where it hangs in
>>>> ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c?
>>>>
>>>
>>> I guess you mean, "where in function MciReadBlockData does it hang?".
>>>
>>> I'll have a look this asap.
>>>
>>
>> I made this mod to the code to add DEBUG:
>>
>> diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
>> b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
>> index 5526aac..7ddcf46 100644
>> --- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
>> +++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
>> @@ -231,6 +231,7 @@ MciReadBlockData (
>>do {
>>  // Read the Status flags
>>  Status = MmioRead32 (MCI_STATUS_REG);
>> +DEBUG ((EFI_D_ERROR, "RMH: MciReadBlockData(%d): 0x%x\n", __LINE__, 
>> Status));^M
>>
>>  // Do eight reads if possible else a single read
>>  if (Status & MCI_STATUS_CMD_RXFIFOHALFFULL) {
>>
>>
>> And after the InitializeSdMmcDevice debug, I see this output continuously:
>>
>> RMH: MciReadBlockData(234): 0x40
>>
>> If I add an MmioWrite32 to clear the flags at the start of the read
>> block function, I see the same behaviour, except it reads 0x00
>> continuously instead of 0x40.
>>
>
> There's a loop count in MciReadBlockData(). Could you print the value
> of variable Loop and
> variable Finish? Then I could know whether it reads any data from FIFO.
>

Sorry for the delay.  I added those two variables to the output and
they never change; no data is read:

RMH: MciReadBlockData(237): Status 0x0 Loop 0 Finish 128


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

Re: [edk2] [PATCH v2 8/9] MmcDxe: set iospeed and bus width in SD stack

[Ryan Harkin]

On 5 April 2016 at 03:57, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
> On 5 April 2016 at 01:17, Ryan Harkin <ryan.har...@linaro.org> wrote:
>> Hi Haojian,
>>
>> I've had time to investigate where TC2 is hanging with your patches
>> applied and narrowed it down to the single line of code marked below.
>>
>> I'm going to read the code now and see if I can work out what it's
>> trying to do, but I thought I'd tell you sooner because you might have
>> a better idea.
>>
>> On 22 March 2016 at 12:48, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
>>> Add more SD commands to support 4-bit bus width & iospeed. It's not
>>> formal code. And it needs to be updated later.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Haojian Zhuang <haojian.zhu...@linaro.org>
>>> ---
>>>  EmbeddedPkg/Include/Protocol/MmcHost.h   |   3 +
>>>  EmbeddedPkg/Universal/MmcDxe/Mmc.h   |  17 +++
>>>  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 138 
>>> ---
>>>  3 files changed, 142 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/EmbeddedPkg/Include/Protocol/MmcHost.h 
>>> b/EmbeddedPkg/Include/Protocol/MmcHost.h
>>> index 5e3a2b7..e9a74f0 100644
>>> --- a/EmbeddedPkg/Include/Protocol/MmcHost.h
>>> +++ b/EmbeddedPkg/Include/Protocol/MmcHost.h
>>> @@ -64,11 +64,14 @@ typedef UINT32 MMC_CMD;
>>>  #define MMC_CMD24 (MMC_INDX(24) | MMC_CMD_WAIT_RESPONSE)
>>>  #define MMC_CMD55 (MMC_INDX(55) | MMC_CMD_WAIT_RESPONSE)
>>>  #define MMC_ACMD41(MMC_INDX(41) | MMC_CMD_WAIT_RESPONSE | 
>>> MMC_CMD_NO_CRC_RESPONSE)
>>> +#define MMC_ACMD51(MMC_INDX(51) | MMC_CMD_WAIT_RESPONSE)
>>>
>>>  // Valid responses for CMD1 in eMMC
>>>  #define EMMC_CMD1_CAPACITY_LESS_THAN_2GB 0x00FF8080 // Capacity <= 2GB, 
>>> byte addressing used
>>>  #define EMMC_CMD1_CAPACITY_GREATER_THAN_2GB 0x40FF8080 // Capacity > 2GB, 
>>> 512-byte sector addressing used
>>>
>>> +#define MMC_STATUS_APP_CMD(1 << 5)
>>> +
>>>  typedef enum _MMC_STATE {
>>>  MmcInvalidState = 0,
>>>  MmcHwInitializationState,
>>> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h 
>>> b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>>> index 0ccbc80..a62ba32 100644
>>> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>>> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
>>> @@ -75,6 +75,23 @@ typedef struct {
>>>UINT32  PowerUp: 1; // This bit is set to LOW if the card has not 
>>> finished the power up routine
>>>  } OCR;
>>>
>>> +/* For little endian CPU */
>>> +typedef struct {
>>> +  UINT8   SD_SPEC:   4; // SD Memory Card - Spec. Version 
>>> [59:56]
>>> +  UINT8   SCR_STRUCTURE: 4; // SCR Structure [63:60]
>>> +  UINT8   SD_BUS_WIDTHS: 4; // DAT Bus widths supported [51:48]
>>> +  UINT8   DATA_STAT_AFTER_ERASE: 1; // Data Status after erases [55]
>>> +  UINT8   SD_SECURITY:   3; // CPRM Security Support [54:52]
>>> +  UINT8   EX_SECURITY_1: 1; // Extended Security Support [43]
>>> +  UINT8   SD_SPEC4:  1; // Spec. Version 4.00 or higher [42]
>>> +  UINT8   RESERVED_1:2; // Reserved [41:40]
>>> +  UINT8   SD_SPEC3:  1; // Spec. Version 3.00 or higher [47]
>>> +  UINT8   EX_SECURITY_2: 3; // Extended Security Support [46:44]
>>> +  UINT8   CMD_SUPPORT:   4; // Command Support bits [35:32]
>>> +  UINT8   RESERVED_2:4; // Reserved [39:36]
>>> +  UINT32  RESERVED_3;   // Manufacturer Usage [31:0]
>>> +} SCR;
>>> +
>>>  typedef struct {
>>>UINT32  NOT_USED;   // 1 [0:0]
>>>UINT32  CRC;// CRC7 checksum [7:1]
>>> diff --git a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c 
>>> b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
>>> index f806bfc..125d3f9 100644
>>> --- a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
>>> +++ b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
>>> @@ -12,6 +12,9 @@
>>>  *
>>>  **/
>>>
>>> +#include 
>>> +#include 
>>> +
>>>  #include "Mmc.h"
>>>
>>>  typedef union {
>>> @@ -41,6 +44,11 @@ typedef union {
>>>
>>>  #define EMMC_SWITCH_ERROR

Re: [edk2] [PATCH v2 8/9] MmcDxe: set iospeed and bus width in SD stack

[Ryan Harkin]

Hi Haojian,

I've had time to investigate where TC2 is hanging with your patches
applied and narrowed it down to the single line of code marked below.

I'm going to read the code now and see if I can work out what it's
trying to do, but I thought I'd tell you sooner because you might have
a better idea.

On 22 March 2016 at 12:48, Haojian Zhuang  wrote:
> Add more SD commands to support 4-bit bus width & iospeed. It's not
> formal code. And it needs to be updated later.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Haojian Zhuang 
> ---
>  EmbeddedPkg/Include/Protocol/MmcHost.h   |   3 +
>  EmbeddedPkg/Universal/MmcDxe/Mmc.h   |  17 +++
>  EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 138 
> ---
>  3 files changed, 142 insertions(+), 16 deletions(-)
>
> diff --git a/EmbeddedPkg/Include/Protocol/MmcHost.h 
> b/EmbeddedPkg/Include/Protocol/MmcHost.h
> index 5e3a2b7..e9a74f0 100644
> --- a/EmbeddedPkg/Include/Protocol/MmcHost.h
> +++ b/EmbeddedPkg/Include/Protocol/MmcHost.h
> @@ -64,11 +64,14 @@ typedef UINT32 MMC_CMD;
>  #define MMC_CMD24 (MMC_INDX(24) | MMC_CMD_WAIT_RESPONSE)
>  #define MMC_CMD55 (MMC_INDX(55) | MMC_CMD_WAIT_RESPONSE)
>  #define MMC_ACMD41(MMC_INDX(41) | MMC_CMD_WAIT_RESPONSE | 
> MMC_CMD_NO_CRC_RESPONSE)
> +#define MMC_ACMD51(MMC_INDX(51) | MMC_CMD_WAIT_RESPONSE)
>
>  // Valid responses for CMD1 in eMMC
>  #define EMMC_CMD1_CAPACITY_LESS_THAN_2GB 0x00FF8080 // Capacity <= 2GB, byte 
> addressing used
>  #define EMMC_CMD1_CAPACITY_GREATER_THAN_2GB 0x40FF8080 // Capacity > 2GB, 
> 512-byte sector addressing used
>
> +#define MMC_STATUS_APP_CMD(1 << 5)
> +
>  typedef enum _MMC_STATE {
>  MmcInvalidState = 0,
>  MmcHwInitializationState,
> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h 
> b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> index 0ccbc80..a62ba32 100644
> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> @@ -75,6 +75,23 @@ typedef struct {
>UINT32  PowerUp: 1; // This bit is set to LOW if the card has not 
> finished the power up routine
>  } OCR;
>
> +/* For little endian CPU */
> +typedef struct {
> +  UINT8   SD_SPEC:   4; // SD Memory Card - Spec. Version [59:56]
> +  UINT8   SCR_STRUCTURE: 4; // SCR Structure [63:60]
> +  UINT8   SD_BUS_WIDTHS: 4; // DAT Bus widths supported [51:48]
> +  UINT8   DATA_STAT_AFTER_ERASE: 1; // Data Status after erases [55]
> +  UINT8   SD_SECURITY:   3; // CPRM Security Support [54:52]
> +  UINT8   EX_SECURITY_1: 1; // Extended Security Support [43]
> +  UINT8   SD_SPEC4:  1; // Spec. Version 4.00 or higher [42]
> +  UINT8   RESERVED_1:2; // Reserved [41:40]
> +  UINT8   SD_SPEC3:  1; // Spec. Version 3.00 or higher [47]
> +  UINT8   EX_SECURITY_2: 3; // Extended Security Support [46:44]
> +  UINT8   CMD_SUPPORT:   4; // Command Support bits [35:32]
> +  UINT8   RESERVED_2:4; // Reserved [39:36]
> +  UINT32  RESERVED_3;   // Manufacturer Usage [31:0]
> +} SCR;
> +
>  typedef struct {
>UINT32  NOT_USED;   // 1 [0:0]
>UINT32  CRC;// CRC7 checksum [7:1]
> diff --git a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c 
> b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
> index f806bfc..125d3f9 100644
> --- a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
> +++ b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
> @@ -12,6 +12,9 @@
>  *
>  **/
>
> +#include 
> +#include 
> +
>  #include "Mmc.h"
>
>  typedef union {
> @@ -41,6 +44,11 @@ typedef union {
>
>  #define EMMC_SWITCH_ERROR   (1 << 7)
>
> +#define SD_BUS_WIDTH_1BIT   (1 << 0)
> +#define SD_BUS_WIDTH_4BIT   (1 << 2)
> +
> +#define SD_CCC_SWITCH   (1 << 10)
> +
>  #define DEVICE_STATE(x) (((x) >> 9) & 0xf)
>  typedef enum _EMMC_DEVICE_STATE {
>EMMC_IDLE_STATE = 0,
> @@ -69,28 +77,30 @@ EmmcGetDeviceState (
>  {
>EFI_MMC_HOST_PROTOCOL *Host;
>EFI_STATUS Status;
> -  UINT32 Data, RCA;
> +  UINT32 Rsp[4], RCA;
>
>if (State == NULL)
>  return EFI_INVALID_PARAMETER;
>
>Host  = MmcHostInstance->MmcHost;
>RCA = MmcHostInstance->CardInfo.RCA << RCA_SHIFT_OFFSET;
> -  Status = Host->SendCommand (Host, MMC_CMD13, RCA);
> -  if (EFI_ERROR (Status)) {
> -DEBUG ((EFI_D_ERROR, "EmmcGetDeviceState(): Failed to get card status, 
> Status=%r.\n", Status));
> -return Status;
> -  }
> -  Status = Host->ReceiveResponse (Host, MMC_RESPONSE_TYPE_R1, );
> -  if (EFI_ERROR (Status)) {
> -DEBUG ((EFI_D_ERROR, "EmmcGetDeviceState(): Failed to get response of 
> CMD13, Status=%r.\n", Status));
> -return Status;
> -  }
> -  if (Data & EMMC_SWITCH_ERROR) {
> -DEBUG ((EFI_D_ERROR, "EmmcGetDeviceState(): Failed to switch expected 
> mode, Status=%r.\n", Status));
> -return 

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

[Ryan Harkin]

On 31 March 2016 at 13:30, Laszlo Ersek <ler...@redhat.com> wrote:
> On 03/31/16 02:48, Ruiyu Ni wrote:
>> This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413.
>> Changing the receive FIFO depth in Terminal driver Start() is not
>> recommended.
>> A new PCD PcdUartDefaultReceiveFifoDepth was added and
>> MdeModulePkg/SerialDxe driver uses the PCD as the default receive
>> FIFO depth.
>>
>> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Cc: Heyi Guo <heyi@linaro.org>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> ---
>>  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c  | 2 +-
>>  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c 
>> b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> index 5adaa97..6fde3b2 100644
>> --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> @@ -806,7 +806,7 @@ TerminalDriverBindingStart (
>>  Status = TerminalDevice->SerialIo->SetAttributes (
>>  TerminalDevice->SerialIo,
>>  Mode->BaudRate,
>> -0, // the device's default FIFO 
>> depth
>> +Mode->ReceiveFifoDepth,
>>  (UINT32) SerialInTimeOut,
>>  (EFI_PARITY_TYPE) (Mode->Parity),
>>  (UINT8) Mode->DataBits,
>> diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c 
>> b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> index 2215df6..3be877b 100644
>> --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> @@ -547,7 +547,7 @@ TerminalConInTimerHandler (
>>  Status = SerialIo->SetAttributes (
>>  SerialIo,
>>  Mode->BaudRate,
>> -0, // the device's default FIFO depth
>> +Mode->ReceiveFifoDepth,
>>  (UINT32) SerialInTimeOut,
>>  (EFI_PARITY_TYPE) (Mode->Parity),
>>  (UINT8) Mode->DataBits,
>>
>
> Based on Ard's feedback here:
> <https://lists.linaro.org/pipermail/linaro-uefi/2016-March/001591.html>
>
> Acked-by: Laszlo Ersek <ler...@redhat.com>

I checked out 45e675f2d0eeda0511b5d6e0ed54f62f94c3826f, applied this
revert and tested on FVP, TC2 and Juno with the patch applied to
OpenPlatformPkg [1] to add the PCD.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>

[1] 
https://git.linaro.org/uefi/OpenPlatformPkg.git/commitdiff/1b31976a928898e29dd01ee498bc4e4736222870

> ___
> 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] Revert "TerminalDxe: select the UART's default receive FIFO depth"

[Ryan Harkin]

On 30 March 2016 at 09:22, Ryan Harkin <ryan.har...@linaro.org> wrote:
>
> On 29 Mar 2016 18:30, "Laszlo Ersek" <ler...@redhat.com> wrote:
>>
>> On 03/29/16 09:31, Ruiyu Ni wrote:
>> > This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413.
>> > Changing the receive FIFO depth in Terminal driver Start() is not
>> > recommended.
>> > A new PCD PcdDefaultUartReceiveFifoDepth was added and

By the way, please update the commit message:  the PCD is called
"PcdUartDefaultReceiveFifoDepth".

>> > MdeModulePkg/SerialDxe driver uses the PCD as the default receive
>> > FIFO depth.
>> >
>> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
>> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> > Cc: Heyi Guo <heyi@linaro.org>
>> > Cc: Laszlo Ersek <ler...@redhat.com>
>> > ---
>> >  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c  | 2 +-
>> >  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 2 +-
>> >  2 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> > b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> > index 5adaa97..6fde3b2 100644
>> > --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> > +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
>> > @@ -806,7 +806,7 @@ TerminalDriverBindingStart (
>> >  Status = TerminalDevice->SerialIo->SetAttributes (
>> >  TerminalDevice->SerialIo,
>> >  Mode->BaudRate,
>> > -0, // the device's default FIFO
>> > depth
>> > +Mode->ReceiveFifoDepth,
>> >  (UINT32) SerialInTimeOut,
>> >  (EFI_PARITY_TYPE)
>> > (Mode->Parity),
>> >  (UINT8) Mode->DataBits,
>> > diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> > b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> > index 2215df6..3be877b 100644
>> > --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> > +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
>> > @@ -547,7 +547,7 @@ TerminalConInTimerHandler (
>> >  Status = SerialIo->SetAttributes (
>> >  SerialIo,
>> >  Mode->BaudRate,
>> > -0, // the device's default FIFO depth
>> > +Mode->ReceiveFifoDepth,
>> >  (UINT32) SerialInTimeOut,
>> >  (EFI_PARITY_TYPE) (Mode->Parity),
>> >  (UINT8) Mode->DataBits,
>> >
>>
>> I think this patch is safe to commit only after the TC2 and Juno
>> platforms (?) are patched to set the new PcdDefaultUartReceiveFifoDepth
>> to whatever value they need. Ryan / Leif / Ard, can you please provide
>> feedback? Are those platforms now maintained outside of edk2?
>>
>
> Yeah, they are maintained outside EDK2 in Leif's OpenPlatformPkg tree.
>
> I'll take care of them today and ping back when it's submitted to the list.
> If I get a couple of good acks, I can push it myself while Leif is on
> holiday. He probably won't mind...
>
>> Thanks
>> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Revert "TerminalDxe: select the UART's default receive FIFO depth"

[Ryan Harkin]

On 29 Mar 2016 18:30, "Laszlo Ersek"  wrote:
>
> On 03/29/16 09:31, Ruiyu Ni wrote:
> > This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413.
> > Changing the receive FIFO depth in Terminal driver Start() is not
> > recommended.
> > A new PCD PcdDefaultUartReceiveFifoDepth was added and
> > MdeModulePkg/SerialDxe driver uses the PCD as the default receive
> > FIFO depth.
> >
> > Signed-off-by: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Heyi Guo 
> > Cc: Laszlo Ersek 
> > ---
> >  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c  | 2 +-
> >  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> > index 5adaa97..6fde3b2 100644
> > --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> > +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
> > @@ -806,7 +806,7 @@ TerminalDriverBindingStart (
> >  Status = TerminalDevice->SerialIo->SetAttributes (
> >  TerminalDevice->SerialIo,
> >  Mode->BaudRate,
> > -0, // the device's default
FIFO depth
> > +Mode->ReceiveFifoDepth,
> >  (UINT32) SerialInTimeOut,
> >  (EFI_PARITY_TYPE)
(Mode->Parity),
> >  (UINT8) Mode->DataBits,
> > diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> > index 2215df6..3be877b 100644
> > --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> > +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
> > @@ -547,7 +547,7 @@ TerminalConInTimerHandler (
> >  Status = SerialIo->SetAttributes (
> >  SerialIo,
> >  Mode->BaudRate,
> > -0, // the device's default FIFO depth
> > +Mode->ReceiveFifoDepth,
> >  (UINT32) SerialInTimeOut,
> >  (EFI_PARITY_TYPE) (Mode->Parity),
> >  (UINT8) Mode->DataBits,
> >
>
> I think this patch is safe to commit only after the TC2 and Juno
> platforms (?) are patched to set the new PcdDefaultUartReceiveFifoDepth
> to whatever value they need. Ryan / Leif / Ard, can you please provide
> feedback? Are those platforms now maintained outside of edk2?
>

Yeah, they are maintained outside EDK2 in Leif's OpenPlatformPkg tree.

I'll take care of them today and ping back when it's submitted to the
list.  If I get a couple of good acks, I can push it myself while Leif is
on holiday. He probably won't mind...

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

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ryan Harkin]

On 23 March 2016 at 16:24, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 23 March 2016 at 08:53, Laszlo Ersek <ler...@redhat.com> wrote:
>> On 03/23/16 09:33, Ni, Ruiyu wrote:
>>> Laszlo,
>>> Since the patch below lets SerialDxe driver use the new introduced
>>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>>> Would you mind to revert the check in @ 31ae446b
>>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>>
>> If I understand correctly, this series increases the terminal polling
>> rate, so that cursor movement escape sequences (and other burst-like
>> sequences) can be processed even with a receive fifo depth of 1. Hence
>> 31ae446b should become unnecessary.
>>
>> If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
>> your revert of 31ae446b -- on top of this series from Heyi --, and the
>> cursor keys work with 31ae446b reverted, then I don't mind, sure.
>>
>
> Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
> these 3 patches from the series applied.

I'm sure you would all work it out ok, but that should have been:

"Unfortunately TC2 and Juno no longer work with 31ae446b reverted and
these 3 patches from the series applied."


>
> It's a shame, because it works on FVP models and copy/paste then works.
>
> I haven't made any investigations on what's going wrong.  But regular
> ASCII keys work, control codes like cursor keys don't.  So it looks
> like the old FIFO setting problem we discussed a few weeks ago.
>
>
>> Thanks
>> Laszlo
>>
>>>
>>> Regards,
>>> Ray
>>>
>>>
>>>> -Original Message-
>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>>> Heyi Guo
>>>> Sent: Thursday, March 17, 2016 10:37 PM
>>>> To: edk2-devel@lists.01.org
>>>> Cc: Heyi Guo <heyi@linaro.org>; Tian, Feng <feng.t...@intel.com>; 
>>>> Zeng, Star <star.z...@intel.com>
>>>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>>>> PCD
>>>>
>>>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>>>> The default value of PCD is also 1, so it makes no difference for
>>>> platforms which do not explicitly set this PCD.
>>>>
>>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>>> Signed-off-by: Heyi Guo <heyi@linaro.org>
>>>> Cc: Feng Tian <feng.t...@intel.com>
>>>> Cc: Star Zeng <star.z...@intel.com>
>>>> ---
>>>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>>>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>>>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>>> index 164060b..a1453bd 100644
>>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>>> @@ -41,10 +41,11 @@
>>>>   gEfiDevicePathProtocolGuid## PRODUCES
>>>>
>>>> [Pcd]
>>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>>>
>>>> [Depex]
>>>>   TRUE
>>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>>>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>>> index f5b3064..d2383e5 100644
>>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>>> @@ -236,7 +236,7 @@ SerialReset (
>>>>   //
>>>>   // Set the Serial I/O mode
>>>>   //
>>>> -  This->Mode->ReceiveFifoDepth  = 1;
>>>> +  This->Mode->

Re: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with PCD

[Ryan Harkin]

On 23 March 2016 at 08:53, Laszlo Ersek  wrote:
> On 03/23/16 09:33, Ni, Ruiyu wrote:
>> Laszlo,
>> Since the patch below lets SerialDxe driver use the new introduced
>> PCD gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth.
>> Would you mind to revert the check in @ 31ae446b
>> --> MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth?
>
> If I understand correctly, this series increases the terminal polling
> rate, so that cursor movement escape sequences (and other burst-like
> sequences) can be processed even with a receive fifo depth of 1. Hence
> 31ae446b should become unnecessary.
>
> If Ryan and Ard (CC'd), who tested 31ae446b originally, can also test
> your revert of 31ae446b -- on top of this series from Heyi --, and the
> cursor keys work with 31ae446b reverted, then I don't mind, sure.
>

Unfortunately TC2 and Juno no longer with with 31ae446b reverted and
these 3 patches from the series applied.

It's a shame, because it works on FVP models and copy/paste then works.

I haven't made any investigations on what's going wrong.  But regular
ASCII keys work, control codes like cursor keys don't.  So it looks
like the old FIFO setting problem we discussed a few weeks ago.


> Thanks
> Laszlo
>
>>
>> Regards,
>> Ray
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
>>> Guo
>>> Sent: Thursday, March 17, 2016 10:37 PM
>>> To: edk2-devel@lists.01.org
>>> Cc: Heyi Guo ; Tian, Feng ; Zeng, 
>>> Star 
>>> Subject: [edk2] [PATCH v2 2/3] MdeModulePkg/SerialDxe: Set FIFO depth with 
>>> PCD
>>>
>>> Set UART receive FIFO depth with PCD instead of fixed number "1".
>>> The default value of PCD is also 1, so it makes no difference for
>>> platforms which do not explicitly set this PCD.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Heyi Guo 
>>> Cc: Feng Tian 
>>> Cc: Star Zeng 
>>> ---
>>> MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 9 +
>>> MdeModulePkg/Universal/SerialDxe/SerialIo.c| 3 ++-
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> index 164060b..a1453bd 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>> @@ -41,10 +41,11 @@
>>>   gEfiDevicePathProtocolGuid## PRODUCES
>>>
>>> [Pcd]
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth ## CONSUMES
>>>
>>> [Depex]
>>>   TRUE
>>> diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
>>> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> index f5b3064..d2383e5 100644
>>> --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
>>> @@ -236,7 +236,7 @@ SerialReset (
>>>   //
>>>   // Set the Serial I/O mode
>>>   //
>>> -  This->Mode->ReceiveFifoDepth  = 1;
>>> +  This->Mode->ReceiveFifoDepth  = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   This->Mode->Timeout   = 1000 * 1000;
>>>   This->Mode->BaudRate  = PcdGet64 (PcdUartDefaultBaudRate);
>>>   This->Mode->DataBits  = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>> @@ -508,6 +508,7 @@ SerialDxeInitialize (
>>>   mSerialIoMode.DataBits = (UINT32) PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialIoMode.Parity   = (UINT32) PcdGet8 (PcdUartDefaultParity);
>>>   mSerialIoMode.StopBits = (UINT32) PcdGet8 (PcdUartDefaultStopBits);
>>> +  mSerialIoMode.ReceiveFifoDepth = PcdGet16 
>>> (PcdUartDefaultReceiveFifoDepth);
>>>   mSerialDevicePath.Uart.BaudRate = PcdGet64 (PcdUartDefaultBaudRate);
>>>   mSerialDevicePath.Uart.DataBits = PcdGet8 (PcdUartDefaultDataBits);
>>>   mSerialDevicePath.Uart.Parity   = PcdGet8 (PcdUartDefaultParity);
>>> --
>>> 2.7.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
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] [PATCH 3/3] ArmPkg: Correct typos in ArmArchTimerLib.c.

[Ryan Harkin]

On 3 March 2016 at 11:55,  <evan.ll...@arm.com> wrote:
> From: Evan Lloyd <evan.ll...@arm.com>
>
> SOme minor typographical problems were noticed during previous commits.

Minor typographical problem in commit message :-)


> This change corrects those, and contains no functional modifications.
> The changes are in comments, and one diagnostic message.
>
> Code at: 
> https://github.com/EvanLloyd/tianocore/commit/6de873f7e3fd63b045adf994e1c8289a7da66531
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>

Comments below are merely that, nothing to stop me OKing this patch.

Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>


> ---
>  ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c 
> b/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
> index 2384b40..c97b1e5 100644
> --- a/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
> +++ b/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c
> @@ -50,7 +50,7 @@ TimerConstructor (
>  if (PcdGet32 (PcdArmArchTimerFreqInHz) != 0) {
>//
>// Check if ticks/uS is not 0. The Architectural timer runs at constant
> -  // frequency, irrespective of CPU frequency. According to General Timer
> +  // frequency, irrespective of CPU frequency. According to Generic Timer
>// Ref manual, lower bound of the frequency is in the range of 1-10MHz.
>//
>ASSERT (TICKS_PER_MICRO_SEC);
> @@ -69,14 +69,14 @@ TimerConstructor (
>  }
>
>  //
> -// Architectural Timer Frequency must be set in the Secure privileged
> +// Architectural Timer Frequency must be set in Secure privileged
>  // mode (if secure extension is supported).
>  // If the reset value (0) is returned, just ASSERT.
>  //
>  ASSERT (ArmGenericTimerGetTimerFreq () != 0);
>
>} else {
> -DEBUG ((EFI_D_ERROR, "ARM Architectural Timer is not available in the 
> CPU, hence this library can not be used.\n"));
> +DEBUG ((EFI_D_ERROR, "ARM Architectural Timer is not available in the 
> CPU, hence this library cannot be used.\n"));
>  ASSERT (0);
>}
>
> @@ -89,7 +89,7 @@ TimerConstructor (
>
>@param  MicroSeconds  The minimum number of microseconds to delay.
>
> -  @return The value of MicroSeconds inputted.
> +  @return The value of MicroSeconds input.

Not a problem with the patch, but I wonder what the point of that
return value is?!


>
>  **/
>  UINTN
> @@ -107,7 +107,7 @@ MicroSecondDelay (
>  TimerFreq = ArmGenericTimerGetTimerFreq ();
>}
>
> -  // Calculate counter ticks that can represent requested delay:
> +  // Calculate counter ticks that represent requested delay:
>//  = MicroSeconds x TICKS_PER_MICRO_SEC
>//  = MicroSeconds x Frequency.10^-6
>TimerTicks64 = DivU64x32 (
> @@ -123,7 +123,7 @@ MicroSecondDelay (
>
>TimerTicks64 += SystemCounterVal;
>
> -  // Wait until delay count is expired.
> +  // Wait until delay count expires.
>while (SystemCounterVal < TimerTicks64) {
>  SystemCounterVal = ArmGenericTimerGetSystemCount ();
>}
> @@ -214,12 +214,12 @@ GetPerformanceCounterProperties (
>)
>  {
>if (StartValue != NULL) {
> -// Timer starts with the reload value
> +// Timer starts at 0

Whilst the comment change is correct, does it really tell us anything
the code doesn't??  I'm happy enough with the change, but I think I'd
have just deleted it!


>  *StartValue = (UINT64)0ULL ;
>}
>
>if (EndValue != NULL) {
> -// Timer counts down to 0x0
> +// Timer counts up.

This one made me spit my tea out.  I'm sure it's not funny :-)


>  *EndValue = 0xUL;
>}
>
> --
> 2.7.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 0/9] enhance mmc

[Ryan Harkin]

On 1 March 2016 at 18:46, Ryan Harkin <ryan.har...@linaro.org> wrote:
> On 29 February 2016 at 15:36, Leif Lindholm <leif.lindh...@linaro.org> wrote:
>> On Mon, Feb 29, 2016 at 01:46:42PM +, Ryan Harkin wrote:
>>> >> This is a substantial contribution, and on inspection it looks fine.
>>> >> However, it does change bits of MmcDxe substantially - so I would
>>> >> really like to see some Tested-by:s for existing platforms.
>>> >>
>>> >> Ryan?
>>>
>>> I'd love to, but the only platform I have with an MMC card slot is
>>> TC2.  And MMC support as been broken in EDK2 on TC2 for some time.
>>>
>>> The last time I saw it working was at this point:
>>>
>>> 203bead  2015-07-01  There needs to be a space between the output
>>> section name and the colon, i.e., [Ard Biesheuvel]
>>>
>>> But that point doesn't boot on TC2 unless you revert this patch:
>>>
>>> d340ef7  2014-08-26  ArmPkg/ArmArchTimerLib: Remove non required
>>> [depex] and IoLib  [Olivier Martin]
>>>
>>> I'll add it to my list of other things someone else broke that I have to 
>>> fix.
>>
>> Evan, you mentioned you still use TC2 from time to time?
>>
>> Ryan: Other than that - does this break MMC on the virtual platforms you
>> look after?
>>
>
> Now that TC2 is working again, I'll test this series tomorrow.  I'll
> check FVP while I'm at it.

Ha! I remembered I'd already started this before I found that TC2 was broken.

I'm afraid these patches don't work for me.  I've not done any
investigation at all, just stacked them on top of my tree with my
PL180 fixes already included via the latest tiancore/master branch.

TC2 hangs after this output:

add-symbol-file
/working/platforms/uefi/edk2/Build/ArmVExpress-CTA15-A7/DEBUG_GCC49/ARM/ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe/DEBUG/PL180MciDxe.dll
0xBF6D7220
Loading driver at 0x000BF6D7000 EntryPoint=0x000BF6D7251 PL180MciDxe.efi
Probing ID registers at 0x11C050FE0 for a PL180
Card is SD2.0 => Supports high capacity
- PrintOCR Ocr (0x80FF8000)
- Card operating voltage: 2.7 to 3.6
- AccessMode: Byte Mode
- PowerUp
- PrintCID
- Manufacturing date: 7/11
- Product serial number: 0x4000CCD2
- Product revision: 128
- OEM ID: DS
- PrintRCA: 0xE6240520
- Status: 0x520
- RCA: 0xE624
- PrintCSD Version 2.00/High Capacity
- Supported card command class: 0x5F5
- Speed: 3.0 10Mbit/s
- Maximum Read Data Block: 1024
- Maximum Write Data Block: 1024
- Format (0): Hard disk-like file system with partition table


And FVP was fine before I added these patches, but crashes with them:

Loading driver at 0x000FAE97000 EntryPoint=0x000FAE97280 PL180MciDxe.efi
Probing ID registers at 0x1C050FE0 for a PL180
Not a SD2.0 Card
- PrintOCR Ocr (0x8000)
- Card operating voltage: 3.6 to 2.0
- AccessMode: Byte Mode
- PowerUp
- PrintCID
- Manufacturing date: 11/17
- Product serial number: 0x1CA4D0
- Product revision: 99
- OEM ID:
- PrintRCA: 0x0
- Status: 0x0
- RCA: 0x0
- PrintCSD Version 1.01-1.10/Version 2.00/Standard Capacity
- Supported card command class: 0x35
- Speed: 1.2 1Mbit/s
- Maximum Read Data Block: 2048
- Maximum Write Data Block: 2048
- Format (0): Hard disk-like file system with partition table


Synchronous Exception at 0xFAEE1BC8
/working/platforms/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC49/AARCH64/EmbeddedPkg/Universal/MmcDxe/MmcDxe/DEBUG/MmcDxe.dll
loaded at 0xFAED9000

  X0 0x8012   X1 0x8012   X2
0xFFD8   X3 0xFAEE3280
  X4 0xFEFFF4A0   X5 0x   X6
0xFAEE3D48   X7 0x0003
  X8 0xFA8A4CD8   X9 0x0009  X10
0x0003  X11 0x
 X12 0x703FE07A  X13 0x  X14
0x  X15 0x
 X16 0xFEFFFBF0  X17 0x  X18
0x  X19 0xFEFFF4A0
 X20 0x  X21 0x  X22
0x  X23 0x
 X24 0x  X25 0x  X26
0x  X27 0x
 X28 0x   FP 0x   LR 0xFAEE0BAC

  V0 0x    V1 0x

  V2 0x    V3 0x

  V4 0x    V5 0x

  V6 0x    V7 0x

  V8 0x    V9 0x

 V10 0x   V11 0x000

Re: [edk2] [PATCH 0/9] enhance mmc

[Ryan Harkin]

On 29 February 2016 at 15:36, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Mon, Feb 29, 2016 at 01:46:42PM +0000, Ryan Harkin wrote:
>> >> This is a substantial contribution, and on inspection it looks fine.
>> >> However, it does change bits of MmcDxe substantially - so I would
>> >> really like to see some Tested-by:s for existing platforms.
>> >>
>> >> Ryan?
>>
>> I'd love to, but the only platform I have with an MMC card slot is
>> TC2.  And MMC support as been broken in EDK2 on TC2 for some time.
>>
>> The last time I saw it working was at this point:
>>
>> 203bead  2015-07-01  There needs to be a space between the output
>> section name and the colon, i.e., [Ard Biesheuvel]
>>
>> But that point doesn't boot on TC2 unless you revert this patch:
>>
>> d340ef7  2014-08-26  ArmPkg/ArmArchTimerLib: Remove non required
>> [depex] and IoLib  [Olivier Martin]
>>
>> I'll add it to my list of other things someone else broke that I have to fix.
>
> Evan, you mentioned you still use TC2 from time to time?
>
> Ryan: Other than that - does this break MMC on the virtual platforms you
> look after?
>

Now that TC2 is working again, I'll test this series tomorrow.  I'll
check FVP while I'm at it.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel