UPDATE:   I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. 

As for your questions Olivier:

The vector table is loaded during bl31 (its called in the bl31_main.c  main() function, right after bl31_platform_setup()).   The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. 

Right now both my irq and fiq handlers use:    ID = gicv2_get_pending_interrupt_id();  to read the INTID.

Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG().  Nothing returns for irq.    

Build options are:  PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1

Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) .   However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved.    

Questions:  Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly?  If you do not, then I think I can take it from here. 

Sent from Mail for Windows 10

From: Olivier Deprez
Sent: Monday, February 1, 2021 2:36 AM
To: tf-a@lists.trustedfirmware.org; AT&T
Subject: Re: [TF-A] Spurious interrupt 1023

Hi Ian,

I guess we'll need a bit more details in order to help you.

Which platform are you using? which GIC version is it using (looks like GICv2?) ?

How did you built TF-A for this platform (command line arguments)?

What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE?

Are you trying to route the UART RX interrupt to EL3?

Is this UART instance only owned by the SWd?

How did you setup the interrupt handler?

Which function are you using to read the INTID?

Regards,

Olivier.

________________________________________

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a@lists.trustedfirmware.org>

Sent: 29 January 2021 21:08

To: tf-a@lists.trustedfirmware.org

Subject: [TF-A] Spurious interrupt 1023

I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3.  I placed an HS_DEBUG command to print the ID, which returns 1023.  The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops.

I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code?

Ian Burres

Cybersecurity R&D

--

TF-A mailing list

TF-A@lists.trustedfirmware.org

https://lists.trustedfirmware.org/mailman/listinfo/tf-a