[edk2] AARCH64: Timer Dxe

Discussion:

Sharma Bhupesh

2015-06-10 10:31:05 UTC

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

------------------------------------------------------------------------------

Sharma Bhupesh

2015-06-13 08:52:37 UTC

Permalink

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 != 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
Subject: AARCH64: Timer Dxe
Hi Olivier,
1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE driver
// 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
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

------------------------------------------------------------------------------

Laszlo Ersek

2015-06-13 12:29:27 UTC

Permalink

Post by 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'

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

Laszlo

Post by Sharma 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.

Regards,
Bhupesh

------------------------------------------------------------------------------

Sharma Bhupesh

2015-06-15 04:16:27 UTC

Permalink

Hi Laszlo,

-----Original Message-----
Sent: Saturday, June 13, 2015 5:59 PM
Subject: Re: AARCH64: Timer Dxe

Post by 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.

Post by Sharma Bhupesh
The following snippet of code shows how the timeout is created as a

event using the CreateEvent and SetTimer APIs.

Post by Sharma Bhupesh
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 0xFFFF 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 CoreTimerXXXX() APIs

Regards,
Bhupesh

EFI_SET_TIMER_TO_SECOND);

Post by Sharma Bhupesh
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
Subject: AARCH64: Timer Dxe
Hi Olivier,
1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE
// 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
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

------------------------------------------------------------------------------

Andrew Fish

2015-06-13 14:18:34 UTC

Permalink

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 <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 <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

Regards,
Bhupesh
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Sharma Bhupesh

2015-06-14 09:35:09 UTC

Permalink

From: Andrew Fish

On Jun 13, 2015, at 1:52 AM, 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’
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
Subject: AARCH64: Timer Dxe
Hi Olivier,
1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE
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
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel

_______________________________________________
boot-architecture mailing list
https://lists.linaro.org/mailman/listinfo/boot-architecture

------------------------------------------------------------------------------

Andrew Fish

2015-06-14 18:19:13 UTC

Permalink

Post by Sharma Bhupesh

From: Andrew Fish

On Jun 13, 2015, at 1:52 AM, 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â
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.
// 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

Post by Sharma Bhupesh
Regards,
Bhupesh

EFI_SET_TIMER_TO_SECOND);

-----Original Message-----
From: Sharma Bhupesh-B45370
Sent: Wednesday, June 10, 2015 4:01 PM
Subject: AARCH64: Timer Dxe
Hi Olivier,
1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE
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
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel <https://lists.sourceforge.net/lists/listinfo/edk2-devel>

_______________________________________________
boot-architecture mailing list
https://lists.linaro.org/mailman/listinfo/boot-architecture <https://lists.linaro.org/mailman/listinfo/boot-architecture>

Olivier Martin

2015-06-15 15:38:22 UTC

Permalink

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:***@freescale.com]
Sent: 10 June 2015 11:31
To: edk2-***@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

------------------------------------------------------------------------------