Hi Laszlo,

-----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com] Sent: Saturday, June 13, 2015 5:59 PM To: Sharma Bhupesh-B45370; edk2-devel@lists.sourceforge.net; olivier.martin@arm.com; Leif Lindholm; boot-architecture@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 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

...

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.martin@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