[edk2-devel] On RPi4 and Juno, gBS->Stall(1) takes 10us and 100us respectively
Rebecca Cran
quic_rcran at quicinc.com
Tue Nov 29 01:03:40 UTC 2022
Thanks. RPi4 and Juno use EmbeddedPkg/MetronomeDxe
(https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/MetronomeDxe/Metronome.c#L54)
which uses the PCD PcdMetronomeTickPeriod.
JunoPkg overrides that to 1000, while RPi4 uses the default of 100.
Given that the clocks run at 50MHz and 54MHz, I think the tick period
should be 1 (1 100-ns unit, giving a clock frequency of 10MHz)?
--
Rebecca Cran
On 11/28/22 12:51, Andrew Fish via groups.io wrote:
> Rebecca,
>
> gBS->Stall() is built on top [1] of the Metronome Architectural Protocol
> [2]. You should look at how the platform implements the Metronome
> Architectural Protocol.
>
> It looks like most platform implement a generic Metronome Driver[3] that
> just sits on top of the platforms TimerLib [4] implementation.
>
> You can find the TimerLib implementations via:
>
> $ git grep TimerLib -- \*.inf | grep LIBRARY_CLASS
>
> ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf:14: LIBRARY_CLASS
> = TimerLib
>
> EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf:19: LIBRARY_CLASS = DebugAgentTimerLib|SEC BASE DXE_CORE
>
> EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf:22:
> LIBRARY_CLASS = TimerLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER UEFI_DRIVER UEFI_APPLICATION
>
> EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf:22: LIBRARY_CLASS
> = TimerLib|DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_DRIVER
> UEFI_APPLICATION
>
> EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf:22: LIBRARY_CLASS
> = TimerLib|PEIM PEI_CORE SEC
>
> MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf:23: LIBRARY_CLASS = TimerLib
>
> MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf:30:
> LIBRARY_CLASS = TimerLib
>
> OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:17: LIBRARY_CLASS =
> TimerLib|PEI_CORE PEIM DXE_CORE
>
> OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf:18:
> LIBRARY_CLASS = TimerLib
>
> OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf:16: LIBRARY_CLASS
> = TimerLib|SEC
>
> OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:17: LIBRARY_CLASS =
> TimerLib|DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_DRIVER
> UEFI_APPLICATION SMM_CORE
>
> PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:21:
> LIBRARY_CLASS = TimerLib|SEC PEI_CORE PEIM
>
> PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:21:
> LIBRARY_CLASS = TimerLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER SMM_CORE
>
> PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf:21:
> LIBRARY_CLASS = TimerLib|PEI_CORE PEIM
>
> PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf:23:
> LIBRARY_CLASS = TimerLib|MM_CORE_STANDALONE MM_STANDALONE
>
> UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf:18: LIBRARY_CLASS
> = TimerLib
>
> UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf:30: LIBRARY_CLASS = TimerLib
>
> UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf:15: LIBRARY_CLASS
> = TimerLib
>
>
> So I’d guess your platform is using the ArmArchTimerLi [5]. If that is
> the case I’d look at the value of PcdArmArchTimerFreqInHz if it is zero
> then I think you are running on the default ARM timer value.
>
> If you are using the stock stuff and all your TimerLib instances are the
> same in all your drivers then the TimerLib is also abstraction the
> performance measure.
>
> This is probably not helpful but the UEFI Spec defines that Stall()
> delays for at least the requested amount of time, with no upper bound on
> how long it can take.
>
> [1]
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/Stall.c#L49 <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/Stall.c#L49>
> [2]
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Metronome.h#L25 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Metronome.h#L25>
> [3]
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Metronome/Metronome.c#L61 <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Metronome/Metronome.c#L61>
> [4]
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/TimerLib.h <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/TimerLib.h>
> [5]
> https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c#L18 <https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c#L18>
>
> Thanks,
>
> Andrew Fish
>
>
>> On Nov 28, 2022, at 11:02 AM, Rebecca Cran <quic_rcran at quicinc.com> wrote:
>>
>> I've been doing some work on USB and ended up realizing that
>> gBS->Stall(1) is taking much longer than it should: on my Juno R2 it's
>> stalling for 100 us, while on my Raspberry Pi 4 it's 10 us.
>>
>> This appears to be causing a USB bulk transfer request that asks for a
>> 1ms timeout taking 100ms on the Juno.
>>
>> I'm measuring the delay with the following code:
>>
>>
>> UINT64 First = GetPerformanceCounter ();
>>
>> gBS->Stall (XHC_1_MICROSECOND);
>>
>> UINT64 Second = GetPerformanceCounter ();
>>
>> UINT64 FirstNs = GetTimeInNanoSecond (First);
>> UINT64 SecondNs = GetTimeInNanoSecond (Second);
>>
>> DEBUG ((DEBUG_INFO, "Stalled for %llu ns (%llu ms)\n", (SecondNs -
>> FirstNs), (SecondNs - FirstNs) / 1024 / 1024));
>>
>>
>>
>> I see output such as:
>>
>> Stalled for 10500 ns (0 ms)
>>
>>
>> --
>> Rebecca Cran
>>
>>
>>
>>
>>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96665): https://edk2.groups.io/g/devel/message/96665
Mute This Topic: https://groups.io/mt/95317735/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list