Re: [edk2] AARCH64: Timer Dxe

2015-06-15 Thread Olivier Martin 
Sorry for the delay I was on holiday.

1. PPI and SGI are registered in the same way.
2. Juno Rev1 support is upstream (ArmPlatformPkg/ArmJunoPkg). It uses ARMv8 
Generic Timer and BootDelay works.

If it does not work I am guessing it is due to some security misconfiguration. 
You Secure World (likely to be ARM Trusted Firmware) should configure your 
timer interrupt as Non-Secure.


-Original Message-
From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com]
Sent: 10 June 2015 11:31
To: edk2-devel@lists.sourceforge.net; Olivier Martin
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


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] AARCH64: Timer Dxe

2015-06-14 Thread Sharma Bhupesh 
Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Saturday, June 13, 2015 5:59 PM
> To: Sharma Bhupesh-B45370; edk2-devel@lists.sourceforge.net;
> olivier.mar...@arm.com; Leif Lindholm; boot-architect...@lists.linaro.org
> Subject: Re: AARCH64: Timer Dxe
> 
> On 06/13/15 10:52, Sharma Bhupesh 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'
> 
> Do you reach the gBS->SetTimer() call at all? For example, if there was a
> non-volatile variable called Timeout, with value 0x or 0, that could
> prevent it.

Yes, via debugger tracing I can see that the gBS->SetTimer() call is indeed 
invoked and
calls DXE Core's respective CoreTimer() APIs

Regards,
Bhupesh

> 
> >
> > if (Timeout != 0x) {
> > 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

Re: [edk2] AARCH64: Timer Dxe

2015-06-14 Thread Andrew Fish 

> On Jun 14, 2015, at 2:35 AM, Sharma Bhupesh  
> wrote:
> 
>> From: Andrew Fish
>>> On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh
>>  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
>> > 
>> 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
>> > 
>> 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 
> CoreTimer() 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 != 0x) {
>>>   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);  A

Re: [edk2] AARCH64: Timer Dxe

2015-06-14 Thread Sharma Bhupesh 
> From: Andrew Fish
> > On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh
>  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
>  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
>  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 
CoreTimer() 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 != 0x) {
> >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 a

Re: [edk2] AARCH64: Timer Dxe

2015-06-13 Thread Andrew Fish 

> On Jun 13, 2015, at 1:52 AM, Sharma Bhupesh  
> 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/Event/Timer.c
 

The DXE Core registers CoreTimerTick() with the gEfiTimerArchProtocolGuid

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c
 

  if (CompareGuid (Entry->ProtocolGuid, &gEfiTimerArchProtocolGuid)) {
//
// Register the Core timer tick handler with the Timer AP
//
gTimer->RegisterHandler (gTimer, CoreTimerTick);
  }

Thanks,

Andrew Fish

> if (Timeout != 0x) {
>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

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] AARCH64: Timer Dxe

2015-06-13 Thread Laszlo Ersek 
On 06/13/15 10:52, Sharma Bhupesh 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'

Do you reach the gBS->SetTimer() call at all? For example, if there was
a non-volatile variable called Timeout, with value 0x or 0, that
could prevent it.

Laszlo

> 
> if (Timeout != 0x) {
> 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

Re: [edk2] AARCH64: Timer Dxe

2015-06-13 Thread Sharma Bhupesh 
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'

if (Timeout != 0x) {
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

[edk2] AARCH64: Timer Dxe

2015-06-10 Thread Sharma Bhupesh 
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