> 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
> 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
> ain/DxeProtocolNotify.c
> <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?
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; '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
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> _______________________________________________
> boot-architecture mailing list
> boot-architect...@lists.linaro.org
> 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
