Re: [edk2] [PATCH v2] ArmPlatformPkg: convert VExpress ResetSystemLib to ResetSystemLib
On 4 July 2017 at 18:27, Ard Biesheuvel wrote:
> On 4 July 2017 at 18:11, Leif Lindholm 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
>
> Reviewed-by: Ard Biesheuvel
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
>
>> ---
>> .../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
>> -while(1);
>> - }
>> -
>> - ASSERT(FALSE);
>> - return EFI_UNSUPPORTED;
>> + ResetCold ();
>> }
>>
>> /
Re: [edk2] [PATCH] ArmPlatformPkg: eliminate Juno gcc build warning
On 20 June 2017 at 12:28, Ard Biesheuvel wrote:
> (+ Laszlo)
>
> On 20 June 2017 at 13:00, Leif Lindholm 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
>
> Reviewed-by: Ard Biesheuvel
Reviewed-by: Ryan Harkin
>
>> ---
>>
>> 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, &PciRegBase, &OldPciAttr);
>>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
On 10 April 2017 at 17:33, Leif Lindholm 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 > This deletes some seriously nasty code! Tested on FVP Foundation & AEMv8, TC2 and Juno R0/1/2. Tested-by: Ryan Harkin >> 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
On 6 April 2017 at 14:15, Ard Biesheuvel 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 > 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
On 6 April 2017 at 12:32, Ard Biesheuvel wrote:
> On 6 April 2017 at 12:14, Ryan Harkin wrote:
>> 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
>>
>
> 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
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
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
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
On 4 April 2017 at 16:47, Ryan Harkin wrote: > 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. Missed the actual Tested-by tag... Tested-by: Ryan Harkin ___ 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
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
Hi Ard,
Thanks for the quick turnaround as always.
On 14 March 2017 at 20:20, Leif Lindholm 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
Tested-by: Ryan Harkin
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, &Descriptor);
>>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
>
>> + 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 (&gEfiCpuArchProtocolGuid, NULL, (VOID
>> **)&mCpu);
>> +}
>> +
>> +EFI_STATUS
>> +EFIAP
Re: [edk2] [PATCH v2] EmbeddedPkg/PrePiLib: allocate code pages for DxeCore
Hi Ard,
On 14 March 2017 at 08:01, Ard Biesheuvel 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
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
Reviewed-by: Leif Lindholm
: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
> Tested-by: Michael Zimmermann
> ---
> 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->AllocDescriptor.MemoryBaseAddress ==
> (UINTN)Alloc) {
> + Hob.MemoryAllocation->AllocDescriptor.MemoryType = EfiBootServicesCode;
> + return Alloc;
> +}
> +
Re: [edk2] [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType functions
On 17 February 2017 at 12:06, Evan Lloyd 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" 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
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 Instance pointer for this protocol
> >> + @param SourceHardware source of the interrupt.
> >> +
Re: [edk2] [PATCH V3 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled
On 31 January 2017 at 11:44, Leif Lindholm wrote: > On Tue, Jan 31, 2017 at 09:48:11AM +0000, Ryan Harkin wrote: >> 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? > > 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
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,
>>IN UINTN HighAddress,
>>IN UINTN Size,
>> - IN UINTN Security
>> + IN UINTN Security,
>> + IN UINTN SubregionDisableMask
>>)
>> {
>>
Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 24 January 2017 at 11:05, Ryan Harkin wrote:
> On 24 January 2017 at 02:19, Daniil Egranov wrote:
>> Hi Ryan,
>>
>>
>>
>> On 01/23/2017 06:56 AM, Ryan Harkin wrote:
>>>
>>> On 20 January 2017 at 20:57, Daniil Egranov
>>> wrote:
>>>>
>>>> Hi Ryan,
>>>>
>>>>
>>>> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>>>>
>>>> On 20 January 2017 at 01:34, Daniil Egranov
>>>> 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
>>>> 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
>>>>
>>>> Tested-by: Ryan Harkin
>>>>
>>>> ---
>>>> 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
Re: [edk2] [PATCH v2] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 24 January 2017 at 02:01, Daniil Egranov 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
Tested-by: Ryan Harkin
> ---
> 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
On 24 January 2017 at 02:19, Daniil Egranov wrote:
> Hi Ryan,
>
>
>
> On 01/23/2017 06:56 AM, Ryan Harkin wrote:
>>
>> On 20 January 2017 at 20:57, Daniil Egranov
>> wrote:
>>>
>>> Hi Ryan,
>>>
>>>
>>> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>>>
>>> On 20 January 2017 at 01:34, Daniil Egranov
>>> 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
>>> 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
>>>
>>> Tested-by: Ryan Harkin
>>>
>>> ---
>>> 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
Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 20 January 2017 at 20:57, Daniil Egranov wrote:
> Hi Ryan,
>
>
> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>
> On 20 January 2017 at 01:34, Daniil Egranov 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 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
>
> Tested-by: Ryan Harkin
>
> ---
> 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]
> /h
Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 20 January 2017 at 20:57, Daniil Egranov wrote:
> Hi Ryan,
>
>
> On 01/20/2017 04:30 AM, Ryan Harkin wrote:
>
> On 20 January 2017 at 01:34, Daniil Egranov 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 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
>
> Tested-by: Ryan Harkin
>
> ---
> 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]
> /h
Re: [edk2] [PATCH] ArmPkg/ArmLib: remove indirection layer from timer register accessors
On 20 January 2017 at 14:35, Ard Biesheuvel wrote: > On 20 January 2017 at 14:32, Ryan Harkin wrote: >> Hi Ard, >> >> On 20 January 2017 at 12:06, Ard Biesheuvel >> 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 >> >> 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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg/ArmLib: remove indirection layer from timer register accessors
Hi Ard, On 20 January 2017 at 12:06, Ard Biesheuvel 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 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 Cheers, Ryan. > --- > ArmPkg/Drivers/TimerDxe/TimerDxe.c > | 1 - > ArmPkg/Include/Chipset/AArch64.h > | 1 - > ArmPkg/Include/Chipset/ArmArchTimer.h > | 139 > ArmPkg/Include/Chipset/ArmV7.h > | 1 - > ArmPkg/Include/Library/ArmArchTimer.h > | 55 --- > ArmPkg/Include/Library/ArmLib.h > | 128 +++ > ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.c > | 42 ++--- > ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c > | 42 ++--- > ArmPkg/Library/ArmLib/AArch64/AArch64ArchTimer.c > | 167 > ArmPkg/Library/ArmLib/Arm/ArmV7ArchTimer.c > | 167 > ArmPkg/Library/ArmLib/ArmBaseLib.inf > | 2 - > 11 files changed, 156 insertions(+), 589 deletions(-) > > diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c > b/ArmPkg/Drivers/TimerDxe/TimerDxe.c > index 1169d426b255..2416c90f5545 100644 > --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c > +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c > @@ -25,7 +25,6 @@ > #include > #include > #include > -#include > > #include > #include > diff --git a/ArmPkg/Include/Chipset/AArch64.h > b/ArmPkg/Include/Chipset/AArch64.h > index e94c9290c582..9aecb1df81e0 100644 > --- a/ArmPkg/Include/Chipset/AArch64.h > +++ b/ArmPkg/Include/Chipset/AArch64.h > @@ -17,7 +17,6 @@ > #define __AARCH64_H__ > > #include > -#include > > // ARM Interrupt ID in Exception Table > #define ARM_ARCH_EXCEPTION_IRQEXCEPT_AARCH64_IRQ > diff --git a/ArmPkg/Include/Chipset/ArmArchTimer.h > b/ArmPkg/Include/Chipset/ArmArchTimer.h > deleted file mode 100644 > index 1caad3d3367a.. > --- a/ArmPkg/Include/Chipset/ArmArchTimer.h > +++ /dev/null > @@ -1,139 +0,0 @@ > -/** @file > -* > -* Copyright (c) 2011-2013, 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:/
Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 20 January 2017 at 01:34, Daniil Egranov 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 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
>
> Tested-by: Ryan Harkin
>
> ---
> 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/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(110):
> !EFI_ERROR (Status)
>
> This is
Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0
On 18 January 2017 at 23:27, Daniil Egranov 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
Tested-by: Ryan Harkin
> ---
> 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
On 11 January 2017 at 11:45, Ryan Harkin wrote: > 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. > 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
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?
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 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 wrote: >> >>> On Dec 12, 2016, at 10:27 AM, Ryan Harkin 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?
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
Hi Leif,
On 2 November 2016 at 11:55, Ryan Harkin wrote:
> On 1 November 2016 at 21:05, Leif Lindholm 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 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
>
> Tested on Juno R0/1/2.
>
> Tested-by; Ryan Harkin
>
>
>>> > ---
>>> > .../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,
>>> > +&gEfiPciIoProtocolGuid,
>>> > +NULL, &HandleCount, &HandleBuffer);
>>> > +
>>> > + if (!EFI_ERROR (Status)) {
>>> > +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
>>> > + Status = gBS->OpenProtocol (
>>> > + HandleBuffer[HIndex],
>>> > + &gEfiPciIoProtocolGuid,
>>> > + (VOID **) &PciIo,
>>> > + NULL,
>>> > + NULL,
>>> > + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>>> > +
>>> > + if (EFI_ERROR (Status)) {
>>> > +continue;
>>> > + }
>>> > +
>>> > + Status = PciIo->Pci.Read (
>>> > +PciIo,
>>> > +EfiPciIoWidthUint32,
>>> > +PCI_VENDOR_ID_OFFSET,
>>> > +1,
>>> > +&PciID
>>> > +);
>>> > +
>>> > + if (EFI_ERROR (Status)) {
>>> > +continue;
>>> > + }
>>> > +
>>> > + if ((PciID & 0x) == JUNO_MARVELL_YUKON_ID) {
>>> > +
>>> > +// Read MAC address from IOFPGA
>>> > +MacHigh= MmioRead3
Re: [edk2] [PATCH v8 0/4] enhance MMC
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
On 21 November 2016 at 17:28, Ryan Harkin wrote: > On 21 November 2016 at 12:29, Ard Biesheuvel > wrote: >> On 21 November 2016 at 12:28, Ard Biesheuvel >> 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 > > I can review tomorrow if you want a Reviewed-by too. Reviewed-by: Ryan Harkin ___ 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
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*) &MemoryDevicePathTemplate);
> -
> -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 (&mLinuxLoaderAppGuid,
> &LinuxLoaderDevicePath);
> - if (EFI_ERROR (Status)) {
> -Print (L"Couldn't Boot Linux: %d\n", Status);
> -return EFI_DEVICE_ERROR;
> - }
> -
> - KernelDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL
> *) &KernelDevicePath, 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 *) &KernelDevicePath,
> + 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;
> +
> +FreeLoad
Re: [edk2] [PATCH 0/3] Remove the ArmPkg LinuxLoader
On 21 November 2016 at 12:29, Ard Biesheuvel wrote: > On 21 November 2016 at 12:28, Ard Biesheuvel > 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 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
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, &Value32); }
> @@ -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,
> + IN UINT64
Re: [edk2] [PATCH v2 3/4] ArmPkg/ArmDmaLib: clean up abuse of device address
On 15 November 2016 at 09:19, Ard Biesheuvel wrote: > On 14 November 2016 at 16:16, Leif Lindholm 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 >> >> For the fix itself: >> Reviewed-by: Leif Lindholm >> >> 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 > 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
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
Hi Haojian,
On 7 November 2016 at 15:49, Haojian Zhuang 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
Tested-by: Ryan Harkin
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
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
On 1 November 2016 at 17:58, Ryan Harkin 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
> 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
>>
Tested-by; Ryan Harkin
>>> ---
>>> 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,
>>> &GcdDescriptor);
>>> 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), &Buffer);
>>>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
On 1 November 2016 at 21:05, Leif Lindholm 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 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
Tested on Juno R0/1/2.
Tested-by; Ryan Harkin
>> > ---
>> > .../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,
>> > +&gEfiPciIoProtocolGuid,
>> > +NULL, &HandleCount, &HandleBuffer);
>> > +
>> > + if (!EFI_ERROR (Status)) {
>> > +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
>> > + Status = gBS->OpenProtocol (
>> > + HandleBuffer[HIndex],
>> > + &gEfiPciIoProtocolGuid,
>> > + (VOID **) &PciIo,
>> > + NULL,
>> > + NULL,
>> > + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>> > +
>> > + if (EFI_ERROR (Status)) {
>> > +continue;
>> > + }
>> > +
>> > + Status = PciIo->Pci.Read (
>> > +PciIo,
>> > +EfiPciIoWidthUint32,
>> > +PCI_VENDOR_ID_OFFSET,
>> > +1,
>> > +&PciID
>> > +);
>> > +
>> > + 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,
>> > + &OldPciAttributes
>> > + );
>> > +
>> > +if (EFI_ERROR (Status)) {
>> > + continue;
>&
Re: [edk2] [PATCH] ArmPkg/Library/ArmDmaLib: Deallocate Map buffer in case of error
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, &GcdDescriptor);
>> 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), &Buffer);
>>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
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,
> +&gEfiPciIoProtocolGuid,
> +NULL, &HandleCount, &HandleBuffer);
> +
> + if (!EFI_ERROR (Status)) {
> +for (HIndex = 0; HIndex < HandleCount; ++HIndex) {
> + Status = gBS->OpenProtocol (
> + HandleBuffer[HIndex],
> + &gEfiPciIoProtocolGuid,
> + (VOID **) &PciIo,
> + NULL,
> + NULL,
> + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> +
> + if (EFI_ERROR (Status)) {
> +continue;
> + }
> +
> + Status = PciIo->Pci.Read (
> +PciIo,
> +EfiPciIoWidthUint32,
> +PCI_VENDOR_ID_OFFSET,
> +1,
> +&PciID
> +);
> +
> + 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,
> + &OldPciAttributes
> + );
> +
> +if (EFI_ERROR (Status)) {
> + continue;
> +}
> +
> +Status = PciIo->Attributes (
> + PciIo,
> + EfiPciIoAttributeOperationSupported,
> + 0,
> + &AttrSupports
> + );
> +
> +if (!EFI_ERROR (Status)) {
> + AttrSupports &= EFI_PCI_DEVICE_ENABLE;
> + Status = PciIo->Attributes (
> +PciIo,
> +EfiPciIoAttributeOperationEnable,
> +AttrSupports,
> +NULL
> +);
> +
> + Status = PciIo->GetBarAttributes (PciIo, 0, &AttrSupports,
> (VOID**)&PciBarAttributes);
> + 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
> +
Re: [edk2] [PATCH v2 0/6] ArmPkg: eliminate calls to deprecated functions
On 26 October 2016 at 13:21, Ryan Harkin wrote: > On 26 October 2016 at 13:13, Ard Biesheuvel wrote: >> On 26 October 2016 at 13:11, Ryan Harkin 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 > >> ___ >> 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
On 25 October 2016 at 18:16, Ard Biesheuvel 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
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
And it's simple enough that I can understand what it does:
Reviewed-by: Ryan Harkin
> ---
>
> 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**)&DevicePathInstances);
> - 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 (&gEfiDevicePathFromTextProtocolGuid, NULL,
> (VOID **)&EfiDevicePathFromTextProtocol);
> -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 = GetDev
Re: [edk2] [PATCH v2 4/6] ArmPkg/SemihostFs: eliminate calls to deprecated string functions
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
On 26 October 2016 at 13:13, Ard Biesheuvel wrote: > On 26 October 2016 at 13:11, Ryan Harkin 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
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
On 24 October 2016 at 17:06, 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. > > 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 > 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
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 (
>>>&gEfiDevicePathFromTextProtocolGuid,
>>> @@ -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
On 24 October 2016 at 14:05, Laszlo Ersek 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 >> --- >> 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 Reviewed-by: Ryan Harkin > ___ > 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/2] ArmPlatformPkg/PrePi: avoid global variable write to mSystemMemoryEnd
On 24 October 2016 at 09:57, Ard Biesheuvel wrote: > The global variable mSystemMemoryEnd is initialized by PrePi only if > it has not been initialized by ArmPlatformPeiBootAction(). This allows > platforms executing under, e.g., ARM Trusted Firmware to dynamically > reserve a window at the top of memory that will be used by the secure > firmware. > > However, PrePi is a SEC module, and writing to a global variable > violates the SEC constraints, since SEC and PEI may execute from NOR > flash. > > So instead, initialize mSystemMemoryEnd statically. This will ensure > it holds the correct value for all implementations where the value > is not overridden, but still allows it to be overridden during the > call to ArmPlatformPeiBootAction(). > > Note that this patch also fixes a latent bug on 32-bit platforms where > a value of mSystemMemoryEnd exceeding 4 GB would be truncated to 32-bits > rather than limited to (4 GB - 1) > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel I tested this successfully on FVP Foundation & AEMv8 models, Juno R0/1/2 and TC2. Tested-by: Ryan Harkin > --- > > Build tested only. > > ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 14 - > ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 20 +-- > ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.asm | 21 ++-- > ArmPlatformPkg/PrePi/PrePi.c| 3 +++ > 4 files changed, 14 insertions(+), 44 deletions(-) > > diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S > b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S > index d0530a874726..a81709d5d12d 100644 > --- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S > +++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S > @@ -13,8 +13,6 @@ > > #include > > -ASM_GLOBAL ASM_PFX(mSystemMemoryEnd) > - > ASM_FUNC(_ModuleEntryPoint) >// Do early platform specific actions >blASM_PFX(ArmPlatformPeiBootAction) > @@ -31,16 +29,6 @@ _SetSVCMode: > _SystemMemoryEndInit: >ldr x1, mSystemMemoryEnd > > - // Is mSystemMemoryEnd initialized? > - cmp x1, #0 > - bne _SetupStackPosition > - > - MOV64 (x1, FixedPcdGet64(PcdSystemMemoryBase) + > FixedPcdGet64(PcdSystemMemorySize) - 1) > - > - // Update the global variable > - adr x2, mSystemMemoryEnd > - str x1, [x2] > - > _SetupStackPosition: >// r1 = SystemMemoryTop > > @@ -129,5 +117,3 @@ _PrepareArguments: > > _NeverReturn: >b _NeverReturn > - > -ASM_PFX(mSystemMemoryEnd):.8byte 0 > diff --git a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S > b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S > index 39030da5f2c3..212cab62d44b 100644 > --- a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S > +++ b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S > @@ -15,8 +15,6 @@ > > #include > > -GCC_ASM_EXPORT(mSystemMemoryEnd) > - > ASM_FUNC(_ModuleEntryPoint) >// Do early platform specific actions >blASM_PFX(ArmPlatformPeiBootAction) > @@ -35,17 +33,11 @@ _SetSVCMode: > // to install the stacks at the bottom of the Firmware Device (case the FD > is located > // at the top of the DRAM) > _SystemMemoryEndInit: > - ldr r1, mSystemMemoryEnd > - > - // Is mSystemMemoryEnd initialized? > - cmp r1, #0 > - bne _SetupStackPosition > - > - MOV32 (r1, FixedPcdGet32(PcdSystemMemoryBase) + > FixedPcdGet32(PcdSystemMemorySize) - 1) > - > - // Update the global variable > - adr r2, mSystemMemoryEnd > - str r1, [r2] > + ADRL (r1, mSystemMemoryEnd) > + ldrd r2, r3, [r1] > + teq r3, #0 > + moveq r1, r2 > + mvnne r1, #0 > > _SetupStackPosition: >// r1 = SystemMemoryTop > @@ -136,5 +128,3 @@ _PrepareArguments: > > _NeverReturn: >b _NeverReturn > - > -ASM_PFX(mSystemMemoryEnd): .8byte 0 > diff --git a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.asm > b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.asm > index 023339841f75..1e9daf563bb6 100644 > --- a/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.asm > +++ b/ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.asm > @@ -21,15 +21,14 @@ >IMPORT ArmReadMpidr >IMPORT ArmPlatformPeiBootAction >IMPORT ArmPlatformStackSet > + IMPORT mSystemMemoryEnd > >EXPORT _ModuleEntryPoint > - EXPORT mSystemMemoryEnd > >PRESERVE8 >AREAPrePiCoreEntryPoint, CODE, READONLY > > StartupAddrDCD CEntryPoint > -mSystemMemoryEnd DCQ 0 > > _ModuleEntryPoint >// Do early platform specific actions > @@ -49,19 +48,11 @@ _SetSVCMode > // to install the stacks at the bottom of the Firmware Device (case the FD >
Re: [edk2] [PATCH] ARMPkg: Unified the GIC base address variables as 64-bit width
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 @@ ArmGicDisableInterrupt (
> BOOLEAN
> EFIAPI
> ArmGicIsInterruptEnabled (
> - IN UINTN GicDistributorBase,
> -
Re: [edk2] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData
On 12 October 2016 at 12:39, Evan Lloyd 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 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, 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/18fab16a63c59c84c71cd81
>>089a55a4081ebe253
>>>>
>>>> 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/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
On 23 September 2016 at 08:58, Ard Biesheuvel wrote:
> On 22 September 2016 at 23:33, Daniil Egranov 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
>
> Reviewed-by: Ard Biesheuvel
>
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
>> ---
>> .../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
On 7 October 2016 at 16:59, Leif Lindholm wrote: > Roy can now be found at Roy Franz (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 >> > Cc: Feng Tian >> > Cc: Star Zeng >> > >> > 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 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.
On 21 September 2016 at 21:33, wrote:
> From: Evan Lloyd
>
> 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
[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
On 11 Oct 2016 20:17, "Ard Biesheuvel" wrote:
>
> On 11 October 2016 at 18:44, Ryan Harkin 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, 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
___
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
On 12 Oct 2016 00:33, "Haojian Zhuang" wrote: > > On 12 October 2016 at 01:03, Ryan Harkin wrote: > > On 11 October 2016 at 17:28, Ard Biesheuvel wrote: > >> On 11 October 2016 at 17:27, Ryan Harkin wrote: > >>> On 11 October 2016 at 17:24, Ard Biesheuvel wrote: > >>>> Hi Ryan, > >>>> > >>>> On 11 October 2016 at 17:22, Ryan Harkin 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
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
On 11 October 2016 at 17:28, Ard Biesheuvel wrote: > On 11 October 2016 at 17:27, Ryan Harkin wrote: >> On 11 October 2016 at 17:24, Ard Biesheuvel >> wrote: >>> Hi Ryan, >>> >>> On 11 October 2016 at 17:22, Ryan Harkin 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
On 11 October 2016 at 17:24, Ard Biesheuvel wrote: > Hi Ryan, > > On 11 October 2016 at 17:22, Ryan Harkin 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
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 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
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
On 7 September 2016 at 12:59, Ard Biesheuvel wrote: > On 7 September 2016 at 12:10, Ryan Harkin wrote: >> 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. >> > > May we take that as a tested-by? > Oh yes! :-) You can even have some tested text too: Tested-by: Ryan Harkin 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 >>> 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 >>>>
Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro
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 x0, x0, #1 >> > - LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), x1) >> > - mul x1,
Re: [edk2] [PATCH v5] Platforms/ARM/Juno: Create SMBIOS/DMI data for Juno
On 28 July 2016 at 15:41, Jeremy Linton 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
Acked-by: Ryan Harkin
> ---
> 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 \
> + "ARM LTD\0"/* Manufacturer
Re: [edk2] [PATCH v3 0/4] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno
On 25 July 2016 at 17:36, Jeremy Linton 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
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
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
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
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
On 7 July 2016 at 17:01, Ryan Harkin wrote: > On 7 July 2016 at 16:59, Leif Lindholm wrote: >> On Fri, Jul 01, 2016 at 12:52:06PM +0100, evan.ll...@arm.com wrote: >>> From: Evan Lloyd >>> >>> 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 >>> Signed-off-by: Evan Lloyd >> >> 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 > > >> 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 >>> + # >>>
Re: [edk2] [PATCH] ArmPlatformPkg: Set Juno debug serial port defaults
On 7 July 2016 at 16:59, Leif Lindholm wrote: > On Fri, Jul 01, 2016 at 12:52:06PM +0100, evan.ll...@arm.com wrote: >> From: Evan Lloyd >> >> 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 >> Signed-off-by: Evan Lloyd > > 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 > 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 >> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity >> + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits >> + >> [Pcd] >&g
Re: [edk2] [RFC V3.1] Proposal to organize packages into directories
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 opposed to > just being where
Re: [edk2] [Linaro-uefi] [PATCH 0/2] Marvell Yukon MAC address configuration on Juno platform
On 7 June 2016 at 01:22, Daniil Egranov 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 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
On 22 June 2016 at 12:14, Jiaxin Wu 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
> Cc: Fu Siyuan
> Cc: Ryan Harkin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
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
Tested-by: Ryan Harkin
> ---
> 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 (&IpSb->Interfaces, &IpIf->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
On 22 June 2016 at 09:45, Wu, Jiaxin 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 (
&Instance->Dhcp4Handle
);
- if (Status == EFI_UNSUPPORTED) {
-//
-// No DHCPv4 Service Binding protocol, register a notify.
-//
-if (Instance->Dhcp4SbNotifyEvent == NULL) {
- Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (
- &gEfiDhcp4ServiceBindingProtocolGuid,
- TPL_CALLBACK,
- Ip4Config2OnDhcp4SbInstalled,
- (VOID *) Instance,
- &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
+
&gEfiDhcp4ServiceBindingProtocolGuid,^M
+ TPL_CALLBACK,^M
+ Ip4Config2OnDhcp4SbInstalled,^M
+ (VOID *) Instance,^M
+ &Instance->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'
>> Cc: Ye, Ting ; Fu, Siyuan ; 'edk2-
>> devel-01'
>> 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
>> > Cc: Ye, Ting ; Fu, Siyuan ;
>> > edk2-
>> > devel-01
>> > 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
>> > > to investigate this some
>> > more.
>> > >
>&
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Jiaxin, On 21 June 2016 at 12:20, Ryan Harkin wrote: > Hi Jiaxin, > > On 21 June 2016 at 12:10, Wu, Jiaxin 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 han
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Jiaxin, On 21 June 2016 at 12:10, Wu, Jiaxin 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 >> Cc: Ye, Ting ; Fu, Siyuan ; edk2- >> devel-01 >> 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 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 "ifconfi
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 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 >> Cc: Ye, Ting ; Fu, Siyuan ; edk2- >> devel-01 >> Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 >> config policy >> >> On 21 Jun 2016 04:43, "Wu, Jiaxin" 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 >> > > Cc: edk2-devel-01 ; Ye, Ting >> > > > >; >> > > Fu, Siyuan >> > > 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 u
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
On 21 Jun 2016 04:43, "Wu, Jiaxin" 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 > > Cc: edk2-devel-01 ; Ye, Ting ; > > Fu, Siyuan > > 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 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 pa
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.
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 = &Instance->DataItem[Ip4Config2DataTypePolicy];
>DataItem->SetData = Ip4Config2SetPolicy;
>DataItem->Data.Ptr = &Instance->Policy;
>DataItem->DataSize = sizeof (Instance->Policy);
> - Instance->Policy = Ip4Config2PolicyDhcp;
> + Instance->Policy = Ip4Config2PolicyStatic;
>SET_DATA_ATTRIB (DataItem->Attribute, DATA_ATTRIB_SIZE_FIXED);
>
>DataItem = &Instance->DataItem[Ip4Config2DataTypeManualAddress];
>DataItem->SetData = Ip4Config2SetMaunualAddress;
>DataItem->Status = EFI_NOT_FOUND;
> @@ -1937,34 +1939,22 @@ Ip4Config2InitInstance (
>
>Instance->Configured = TRUE;
>
>//
>// Try to read the config data from NV variable.
> + // If not found, write initialized config data into NV variable
Re: [edk2] [PATCH 6/6] ArmPlatformPkg: Fix PL011 Glitches.
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> This change corrects 3 problems in the PL011 driver.
> 1. The TRM states "The UARTLCR_H, UARTIBRD, and UARTFBRD registers must
>not be changed:...when the UART is enabled"
> 2. The TRM (3.3.8) describes logic requiring the UART to be disabled and
>flushed before adjusting UARTCR.
> 3. Several redundant calls get made to PL011UartInitializePort, where
>the characteristics do not change, but updating the registers can
>cause glitches in the output stream.
>
> The parameters are compared to the current state and no action taken if
> no change of state is required.
> Where an update is required, the specified logic is followed, and the
> register updates only made when the UART is disabled.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Sami Mujawar
> Signed-off-by: Evan Lloyd
Tested on Juno R2 and FVP Foundation and AEMv8 models.
Tested-by: Ryan Harkin
Reviewed-by: Ryan Harkin
> ---
> ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> index
> 61b122a67ab7354714adb429e401126973ab6c8d..ec1abdd10c4ab2fdf59576af6eb3c92b8728d81a
> 100644
> --- a/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> +++ b/ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c
> @@ -29,9 +29,11 @@
> //
> STATIC CONST UINT32 mInvalidControlBits =
> EFI_SERIAL_SOFTWARE_LOOPBACK_ENABLE;
>
> -/*
> +/**
>
>Initialise the serial port to the specified settings.
> + The serial port is re-configured only if the specified settings
> + are different from the current settings.
>All unspecified settings will be set to the default values.
>
>@param UartBaseThe base address of the serial device.
> @@ -188,6 +190,26 @@ PL011UartInitializePort (
> Integer = Divisor >> FRACTION_PART_SIZE_IN_BITS;
> Fractional = Divisor & FRACTION_PART_MASK;
>}
> +
> + //
> + // If PL011 is already initialized, check the current settings
> + // and re-initialize only if the settings are different.
> + //
> + if (((MmioRead32 (UartBase + UARTCR) & PL011_UARTCR_UARTEN) != 0) &&
> + (MmioRead32 (UartBase + UARTLCR_H) == LineControl) &&
> + (MmioRead32 (UartBase + UARTIBRD) == Integer) &&
> + (MmioRead32 (UartBase + UARTFBRD) == Fractional)) {
> +// Nothing to do - already initialized with correct attributes
> +return RETURN_SUCCESS;
> + }
> +
> + // Wait for the end of transmission
> + while ((MmioRead32 (UartBase + UARTFR) & PL011_UARTFR_TXFE) == 0);
> +
> + // Disable UART: "The UARTLCR_H, UARTIBRD, and UARTFBRD registers must not
> be changed
> + // when the UART is enabled"
> + MmioWrite32 (UartBase + UARTCR, 0);
> +
>// Set Baud Rate Registers
>MmioWrite32 (UartBase + UARTIBRD, Integer);
>MmioWrite32 (UartBase + UARTFBRD, Fractional);
> --
> 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 4/6] ArmPlatformPkg: Add support to configure PL011 UART clock
On 28 May 2016 at 14:54, wrote: > From: Evan Lloyd > > 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 > Signed-off-by: Evan Lloyd 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 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 > --- > ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf | 1 - > ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 1 + > ArmPlatformPkg/Include/Drivers/PL011Uart.h | 43 > > ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.c | 22 > +++--- > ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 30 > +++--- > 5 files changed, 60 insertions(+), 37 deletions(-) > > diff
Re: [edk2] [PATCH 3/6] ArmPlatformPkg: Remove double write in PL011
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> 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
> Signed-off-by: Evan Lloyd
Tested on Juno R2 and FVP Foundation and AEMv8.
Tested-by: Ryan Harkin
Reviewed-by: Ryan Harkin
> ---
> 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
On 28 May 2016 at 14:54, wrote:
> From: Evan Lloyd
>
> 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
> Signed-off-by: Evan Lloyd
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
Reviewed-by: Ryan Harkin
> ---
> 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 --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> index
>
Re: [edk2] [PATCH 1/6] ArmPlatformPkg: Tidy PL011 UART driver
On 28 May 2016 at 14:54, wrote: > From: Evan Lloyd > > 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 A minor comment below, but otherwise, this looks fine. Reviewed-by: Ryan Harkin > --- > 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 @@ > > #include > > +#define FRACTION_PART_SIZE_IN_BITS 6 > +#define FRACTIO
Re: [edk2] [RFC] Proposal to organize packages into directories
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
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
[edk2] [PATCH 1/2] EmbeddedPkg/Lan9118Dxe: PcdLan9118NegotiationFeatureMask
Add a PCD to allow the platform to mask in/out specific features of the LAN9118 device advertised during auto-negotiation. For example, the Juno ARM Development Platform doesn't support full duplex mode. This PCD will allow the platform developer to prevent the full duplex modes from being advertised. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin --- EmbeddedPkg/EmbeddedPkg.dec | 1 + EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.inf | 1 + EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeUtil.c | 1 + 3 files changed, 3 insertions(+) diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec index 7bcb133..73f7ee6 100644 --- a/EmbeddedPkg/EmbeddedPkg.dec +++ b/EmbeddedPkg/EmbeddedPkg.dec @@ -147,6 +147,7 @@ [PcdsFixedAtBuild.common] gEmbeddedTokenSpaceGuid.PcdLan9118DxeBaseAddress|0x0|UINT32|0x0025 gEmbeddedTokenSpaceGuid.PcdLan9118DefaultMacAddress|0x0|UINT64|0x0026 gEmbeddedTokenSpaceGuid.PcdLan9118DefaultNegotiationTimeout|4000|UINT32|0x0027 + gEmbeddedTokenSpaceGuid.PcdLan9118NegotiationFeatureMask|0x|UINT32|0x0028 # # Android FastBoot diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.inf b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.inf index 3c2246f..055a055 100644 --- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.inf +++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.inf @@ -52,6 +52,7 @@ [FixedPcd] gEmbeddedTokenSpaceGuid.PcdLan9118DxeBaseAddress gEmbeddedTokenSpaceGuid.PcdLan9118DefaultMacAddress gEmbeddedTokenSpaceGuid.PcdLan9118DefaultNegotiationTimeout + gEmbeddedTokenSpaceGuid.PcdLan9118NegotiationFeatureMask [Depex] TRUE diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeUtil.c b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeUtil.c index 8491396..5ce658c 100644 --- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeUtil.c +++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeUtil.c @@ -648,6 +648,7 @@ AutoNegotiate ( Features &= ~(PHYANA_PAUSE_OP_MASK); Features |= 3 << 10; } + Features &= FixedPcdGet32 (PcdLan9118NegotiationFeatureMask); // Write the features IndirectPHYWrite32 (PHY_INDEX_AUTO_NEG_ADVERT, Features); -- 2.1.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/2] Platforms/ARM: Add PcdLan9118NegotiationFeatureMask
The LAN9118 features mask us used to enable/disable certain features advertised by the device during auto-negotiation. Juno and TC2 do not support full duplex communication properly, causing intermittent failures, so we disable them using the mask. The feature mask used is effectively: ~(PHYANA_10BASETFD | PHYANA_100BASETXFD); The constants for the bit masks are defined here: EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118DxeHw.h Signed-off-by: Ryan Harkin --- Platforms/ARM/Juno/ArmJuno.dsc | 1 + Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc | 1 + 2 files changed, 2 insertions(+) diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc index e3a675e..4a1fe10 100644 --- a/Platforms/ARM/Juno/ArmJuno.dsc +++ b/Platforms/ARM/Juno/ArmJuno.dsc @@ -132,6 +132,7 @@ gEmbeddedTokenSpaceGuid.PcdLan9118DxeBaseAddress|0x1800 gEmbeddedTokenSpaceGuid.PcdLan9118DefaultMacAddress|0x1215161822242628 gEmbeddedTokenSpaceGuid.PcdLan9118DefaultNegotiationTimeout|4 + gEmbeddedTokenSpaceGuid.PcdLan9118NegotiationFeatureMask|0xFEBF # # ARM General Interrupt Controller diff --git a/Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc b/Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc index c6d0b13..c4e437f 100644 --- a/Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc +++ b/Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc @@ -170,6 +170,7 @@ # Ethernet (SMSC LAN9118) gEmbeddedTokenSpaceGuid.PcdLan9118DxeBaseAddress|0x1A00 gEmbeddedTokenSpaceGuid.PcdLan9118DefaultNegotiationTimeout|40 + gEmbeddedTokenSpaceGuid.PcdLan9118NegotiationFeatureMask|0xFEBF # # Define the device path to the FDT for the platform -- 2.1.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/2] LAN9118 Auto-Negotiation Feature Mask
These two patches are destined for both EDK2 and OpenPlatformPkg. The EDK2 patch should be merged first. LAN9118 investigations by Mark Rutland has shown that the Juno ARM Development Platform does not work well when LAN9118 auto-negotiates in full duplex mode. It was suggested that a PCD could be added to control the advertised features. One way of implementing the PCDi, as implemented here, is to provide a mask, where the platform developer can enable/disable features. [PATCH 1/2] EmbeddedPkg/Lan9118Dxe: PcdLan9118NegotiationFeatureMask [PATCH 2/2] Platforms/ARM: Add PcdLan9118NegotiationFeatureMask ~ ~ ___ 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
On 9 May 2016 at 11:07, Ryan Harkin wrote: > On 9 May 2016 at 10:22, Mark Rutland wrote: >> On Sat, May 07, 2016 at 10:43:45AM +0200, Ard Biesheuvel wrote: >>> On 6 May 2016 at 19:19, Mark Rutland 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 >> >> 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 0/4] EmbeddedPkg/Lan9118Dxe MMIO fixes
On 9 May 2016 at 10:22, Mark Rutland wrote: > On Sat, May 07, 2016 at 10:43:45AM +0200, Ard Biesheuvel wrote: >> On 6 May 2016 at 19:19, Mark Rutland 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. >> Reviewed-by: Ard Biesheuvel > > 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
On 20 April 2016 at 09:40, Ard Biesheuvel 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
Tested-by: Ryan Harkin
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, &GcdDescriptor);
> +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
On 5 April 2016 at 11:18, Haojian Zhuang wrote:
> On 5 April 2016 at 17:49, Ryan Harkin wrote:
>> On 5 April 2016 at 09:37, Ryan Harkin wrote:
>>> On 5 April 2016 at 03:57, Haojian Zhuang wrote:
>>>> On 5 April 2016 at 01:17, Ryan Harkin 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
>>>>> 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
>
>>>>>> +
>>>>>> + /* 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
On 5 April 2016 at 09:37, Ryan Harkin wrote:
> On 5 April 2016 at 03:57, Haojian Zhuang wrote:
>> On 5 April 2016 at 01:17, Ryan Harkin 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 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 @@
>>>> *
>>&
Re: [edk2] [PATCH v2 8/9] MmcDxe: set iospeed and bus width in SD stack
On 5 April 2016 at 03:57, Haojian Zhuang wrote:
> On 5 April 2016 at 01:17, Ryan Harkin 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 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)
>>> +#de
Re: [edk2] [PATCH v2 8/9] MmcDxe: set iospeed and bus width in SD stack
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, &Data);
> - 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 EFI_DEVICE_ERROR;
> - }
> - *State = DEVICE_STATE(Data);
