Re: [edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Ard Biesheuvel]

On 18 March 2016 at 14:34, Cohen, Eugene  wrote:
> Vladimir,
>
>> Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280
>> ArmTimerDxe.efi
>
> This is the point where the Timer driver will register with the interrupt 
> controller driver and enable timer tick interrupts so the first IRQ interrupt 
> will fire shortly thereafter.
>
>> JTAG debug shows that the CPU is looping in IrqSpx:
>> EL2:0x85008A80 : BIrqSPx ; 0x85008A80
>
> This instruction does not correspond to the new exception handling code 
> (ArmExceptionLib).  Based on my searching the only place I see a construct 
> like this is in DebugAgentException.S 
> (ArmPkg\Library\DebugAgentSymbolsBaseLib).
>
> I haven't used this library but understand that it (the library class, at 
> least) intended to assist with source level debugging (GDB agent over serial 
> port or equivalent).  This particular instance doesn't actually appear to be 
> a debug agent nor does it implement the SaveAndSetDebugTimerInterrupt.   This 
> instance is installing exception handlers that just spin but now that's 
> overlapping with the responsibilities of CpuExceptionHandlerLib (and the 
> DefaultExceptionHandlerLib which provides more useful output than a 
> spinloop).  We don't want yet another copy of exception handlers floating 
> around (which is the whole point behind ArmExceptionLib), instead we need to 
> find a way to make them work together or at least rip out the exception 
> vector init from this driver.
>
> Regardless, when CpuDxe initializes exceptions it should be taking over 
> exception vectors including the IRQ handler.  Since I don't have a platform 
> to test this with at the moment, can you help debug it by stepping through  
> InitializeExceptions in CpuDxe and see what is happening with regard to the 
> exception table (VBAR programming, and the contents at that address)?
>
> Also please help me duplicate your setup - can you confirm which libraries 
> you are using (are you using the ArmPkg DebugAgentSymbolsBaseLib?) and which 
> components (SEC or otherwise) are using it?
>

You need to change the resolution for CpuExceptionHandlerLib in your
platform definition:

-  
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65 causes UEFI boot freeze (armv8 platform)

[Vladimir Olovyannikov]

Hi Ard, Eugene,

Thanks a lot for your help.
You were absolutely right: I forgot to switch from
CpuExceptionhandlerLibNull to ArmExceptionLib in my platform dsc file.

Everything is OK now.

Eugene, please let me know if you still want to do some testing on the
platform.

Thank you,
Vladimir
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, March 18, 2016 7:00 AM
To: Cohen, Eugene
Cc: Vladimir Olovyannikov; edk2-devel@lists.01.org
Subject: Re: Applying the patch 5811eea0fdb56187597e50b1282e7cfab4965a65
causes UEFI boot freeze (armv8 platform)

On 18 March 2016 at 14:34, Cohen, Eugene  wrote:
> Vladimir,
>
>> Loading driver at 0x000BBE23000 EntryPoint=0x000BBE23280
>> ArmTimerDxe.efi
>
> This is the point where the Timer driver will register with the interrupt
> controller driver and enable timer tick interrupts so the first IRQ
> interrupt will fire shortly thereafter.
>
>> JTAG debug shows that the CPU is looping in IrqSpx:
>> EL2:0x85008A80 : BIrqSPx ; 0x85008A80
>
> This instruction does not correspond to the new exception handling code
> (ArmExceptionLib).  Based on my searching the only place I see a construct
> like this is in DebugAgentException.S
> (ArmPkg\Library\DebugAgentSymbolsBaseLib).
>
> I haven't used this library but understand that it (the library class, at
> least) intended to assist with source level debugging (GDB agent over
> serial port or equivalent).  This particular instance doesn't actually
> appear to be a debug agent nor does it implement the
> SaveAndSetDebugTimerInterrupt.   This instance is installing exception
> handlers that just spin but now that's overlapping with the
> responsibilities of CpuExceptionHandlerLib (and the
> DefaultExceptionHandlerLib which provides more useful output than a
> spinloop).  We don't want yet another copy of exception handlers floating
> around (which is the whole point behind ArmExceptionLib), instead we need
> to find a way to make them work together or at least rip out the exception
> vector init from this driver.
>
> Regardless, when CpuDxe initializes exceptions it should be taking over
> exception vectors including the IRQ handler.  Since I don't have a
> platform to test this with at the moment, can you help debug it by
> stepping through  InitializeExceptions in CpuDxe and see what is happening
> with regard to the exception table (VBAR programming, and the contents at
> that address)?
>
> Also please help me duplicate your setup - can you confirm which libraries
> you are using (are you using the ArmPkg DebugAgentSymbolsBaseLib?) and
> which components (SEC or otherwise) are using it?
>

You need to change the resolution for CpuExceptionHandlerLib in your
platform definition:

-
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel