> On Jun 14, 2015, at 2:35 AM, Sharma Bhupesh <bhupesh.sha...@freescale.com> 
> wrote:
> 
>> From: Andrew Fish
>>> On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh
>> <bhupesh.sha...@freescale.com> 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: edk2-devel@lists.sourceforge.net 
>>>> <mailto:edk2-devel@lists.sourceforge.net>; 'olivier.mar...@arm.com 
>>>> <mailto:olivier.mar...@arm.com>'
>>>> 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
>>> edk2-devel@lists.sourceforge.net <mailto:edk2-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel 
>>> <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
>> 
>> _______________________________________________
>> boot-architecture mailing list
>> boot-architect...@lists.linaro.org 
>> <mailto:boot-architect...@lists.linaro.org>
>> https://lists.linaro.org/mailman/listinfo/boot-architecture 
>> <https://lists.linaro.org/mailman/listinfo/boot-architecture>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to