> 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