why the inter-core SGI interrupt cannot be trigged on GICv3 hardware

Hi Martin,

Thanks so much for your reply!

You said that you'd written GICR_ISENABLER0 to enable the SGI you're sending.  Which core's Redistributor did you write to?  It needs to have been that of receiving core (or both of course)

- Both core0 & core1 are written

Did you also write GICR_IGROUPR0 to set the interrupt as NS.G1?  (Note, you'll need to do this in Secure state)

- No, I didn't, because the core is running in 32 bit hyp mode.  But, even so, if everyghing is ok, core 1 will receive a SGI either in group0 or group1, actually core1 see nothing.

Have you written GICR_WAKER to make the cores as awake? (You'll need to do this for sender and receiver)

-Sure, this is done

What's the priority of the SGI (GICR_IPRORITYRn, of the receiver) and what's the PMR value

- PMR is 0xff

Does GICR_ISPENDR0 (of the receiver's Redistributor) show the interrupt as pending after the write to ICC_SGI1R?

- It's always 0

Strictly, you'll need a DSB between the write of the ICC_SGI1R and the read of the GICR_ISPENDR0

- Sure, DSB is used.

Hi Martin,

Thanks so much for your reply!

You said that you'd written GICR_ISENABLER0 to enable the SGI you're sending.  Which core's Redistributor did you write to?  It needs to have been that of receiving core (or both of course)

- Both core0 & core1 are written

Did you also write GICR_IGROUPR0 to set the interrupt as NS.G1?  (Note, you'll need to do this in Secure state)

- No, I didn't, because the core is running in 32 bit hyp mode.  But, even so, if everyghing is ok, core 1 will receive a SGI either in group0 or group1, actually core1 see nothing.

Have you written GICR_WAKER to make the cores as awake? (You'll need to do this for sender and receiver)

-Sure, this is done

What's the priority of the SGI (GICR_IPRORITYRn, of the receiver) and what's the PMR value

- PMR is 0xff

Does GICR_ISPENDR0 (of the receiver's Redistributor) show the interrupt as pending after the write to ICC_SGI1R?

- It's always 0

Strictly, you'll need a DSB between the write of the ICC_SGI1R and the read of the GICR_ISPENDR0

- Sure, DSB is used.

Pretty much.

When GICD_CTLR.DS==0, only secure software can access GICR_IGROUPR0 (or GICD_IGROUPRn).  So you would need to program Secure software to program these registers, typically before entering Non-secure state for the first time.

Hi Martin,

In my environment, GICD_CTLR.DS is 0.

The value of GICR_IGROUPR0 is always 0 and I cannot reconfigure it. I think this is because cores are in non-secure state, So does this mean the receiver core will always treat this as a group0 SGI?  And according to the document you mention(table 11), a group0 SGI won't be forwarded if the GICR_NSACR is not set correctly in secure state.

So, with the current configuration in non-secure state, I cannot send a SGI from one core to another, is this correct?

Got it. Thank you so much.

Hi Martin

I set GICD_CTLR as 0x47 in secure state. I.e, DS is 1.

Now in my 32bit hyp mode, the value of GICR_ISENABLER0 is 0x300, GICR_IGROUPR0 is 0xffff, GICR_IGRPMODR0 is 0. But I still cannot send out a #8 SGI using icc_sgi1r or GICD_SGIR.

The other SPI interrupt, say timer, works fine in the system.

Do you have any other ideas about this issue?

Thanks.

Couple of questions.

Are you doing this write from Secure state?  If so, I would suggest just writing GICR_IGROUPR0 and not setting DS==1.  If not, you can't set the DS bit from Non-secure state.

Also, you don't appear to be setting the ARE bits.  The ARE bits select between the GICv3 and legacy mode.  If you're setting the SRE bits, then the ARE bits should also be set.

EDIT: For reference, attached is a simple assembler program I wrote once to test something.  It's a very minimal GICv3 set up sequence, targeting the Base Platform model.