> On Jun 14, 2015, at 2:35 AM, Sharma Bhupesh <[email protected]>
> wrote:
>
>> From: Andrew Fish
>>> On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh
>> <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> Can some ARM expert help me with my queries below.
>>>
>>> The overall context is that I cannot get the 'ArmPlatformPkg/Bds/Bds.c'
>> auto-timeout to trigger.
>>>
>>> The following snippet of code shows how the timeout is created as a
>> event using the CreateEvent and SetTimer APIs.
>>>
>>> However I cannot the SetTimer API triggering a call to the
>> corresponding TimerDriverSetTimerPeriod API inside
>> 'ArmPkg/Drivers/TimerDxe/TimerDxe.c’
>>>
>>
>> It does not work that way. The DXE Core has a periodic timer at a fixed
>> interval. The event based timers are implemented on top of the periodic
>> tick in software.
>>
>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Even
>> t/Timer.c
>> <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Eve
>> <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Eve>
>> nt/Timer.c>
>> The DXE Core registers CoreTimerTick() with the gEfiTimerArchProtocolGuid
>>
>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/DxeM
>> <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/DxeM>
>> ain/DxeProtocolNotify.c
>> <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Dxe
>> <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Dxe>
>> Main/DxeProtocolNotify.c>
>> if (CompareGuid (Entry->ProtocolGuid, &gEfiTimerArchProtocolGuid)) {
>> //
>> // Register the Core timer tick handler with the Timer AP
>> //
>> gTimer->RegisterHandler (gTimer, CoreTimerTick);
>> }
>>
>
> Exactly. So I can see via a debugger that the SetTimer API indeed calls the
> DXE Core's
> CoreTimerXXXX() APIs. However I cannot see the auto-timeout working.
>
> So in the following loop:
>
> // Start the timer
> WaitIndex = 0;
> Print(L"The default boot selection will start in ");
> while ((Timeout > 0) && (WaitIndex == 0)) {
> Print(L"%3d seconds",Timeout);
> gBS->WaitForEvent (2, WaitList, &WaitIndex);
> if (WaitIndex == 0) {
> Print(L"\b\b\b\b\b\b\b\b\b\b\b");
> Timeout--;
> }
> }
>
> I never see the WaitIndex == 0, which would cause Timeout to auto-decrement
> and prints of "\b\b\b\b\b\b\b\b\b\b\b" to appear on the serial console.
>
> So it seems like I might be missing something related to registering the Core
> timer tick handler with the Timer AP in my .dsc
>
> Any pointers?
>
Try error checking the gBS->WaitForEvent() call, and the other calls that
create the event, and set the timer.
Thanks,
Andrew Fish
> Regards,
> Bhupesh
>
>>> if (Timeout != 0xFFFF) {
>>> if (Timeout > 0) {
>>> // Create the waiting events (keystroke and 1sec timer)
>>> gBS->CreateEvent (EVT_TIMER, 0, NULL, NULL, &WaitList[0]);
>>> gBS->SetTimer (WaitList[0], TimerPeriodic,
>> EFI_SET_TIMER_TO_SECOND);
>>> WaitList[1] = gST->ConIn->WaitForKey;
>>>
>>> // Start the timer
>>> WaitIndex = 0;
>>> Print(L"The default boot selection will start in ");
>>> while ((Timeout > 0) && (WaitIndex == 0)) {
>>> Print(L"%3d seconds",Timeout);
>>> gBS->WaitForEvent (2, WaitList, &WaitIndex);
>>> if (WaitIndex == 0) {
>>> Print(L"\b\b\b\b\b\b\b\b\b\b\b");
>>> Timeout--;
>>> }
>>> }
>>>
>>> So, I just wanted to understand if the auto-timeout during boot works
>>> on Juno-Rev1 and if yes, how does it connect to the underlying
>>> ArmArchTimerLib
>>>
>>> Please help.
>>>
>>>> -----Original Message-----
>>>> From: Sharma Bhupesh-B45370
>>>> Sent: Wednesday, June 10, 2015 4:01 PM
>>>> To: [email protected]
>>>> <mailto:[email protected]>; '[email protected]
>>>> <mailto:[email protected]>'
>>>> Subject: AARCH64: Timer Dxe
>>>>
>>>> Hi Olivier,
>>>>
>>>> 1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE
>>>> driver and seeing how the timer interrupts are registered:
>>>>
>>>> // Install secure and Non-secure interrupt handlers // Note:
>>>> Because it is not possible to determine the security state of the //
>>>> CPU dynamically, we just install interrupt handler for both sec and
>>>> non-sec // timer PPI Status = gInterrupt->RegisterInterruptSource
>>>> (gInterrupt, PcdGet32 (PcdArmArchTimerVirtIntrNum),
>>>> TimerInterruptHandler); ASSERT_EFI_ERROR (Status);
>>>>
>>>> Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
>>>> (PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
>>>> ASSERT_EFI_ERROR (Status);
>>>>
>>>> Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
>>>> (PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
>>>> ASSERT_EFI_ERROR (Status);
>>>>
>>>> Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32
>>>> (PcdArmArchTimerIntrNum), TimerInterruptHandler); ASSERT_EFI_ERROR
>>>> (Status);
>>>>
>>>> I wanted to understand how the Interrupt registration changes for PPI
>>>> or SPI interrupt sources.
>>>> As usually the Virtual, Hypervisor, Physical and Physical Non-Secure
>>>> interrupts are PPI does the PPI number need to be defined as the PCD
>>>> values in the same way as linux. The Linux gicv3 documentation says
>>>> (Documentation/devicetree/bindings/arm/gic-v3.txt):
>>>>
>>>> SPI interrupts are in the range [0-987]. PPI interrupts are in the
>>>> range [0-15].
>>>>
>>>> 2. Also one related question is whether on Juno Rev1, you are able to
>>>> get the BootDelay to work via timer based events? If yes, can you
>>>> please share if you achieve this by using the ARMv8 generic timer or
>>>> the SP804 timer.
>>>>
>>>
>>> Regards,
>>> Bhupesh
>>>
>>> ----------------------------------------------------------------------
>>> -------- _______________________________________________
>>> edk2-devel mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>> <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
>>
>> _______________________________________________
>> boot-architecture mailing list
>> [email protected]
>> <mailto:[email protected]>
>> https://lists.linaro.org/mailman/listinfo/boot-architecture
>> <https://lists.linaro.org/mailman/listinfo/boot-architecture>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
