search

ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

Arch64-A53 -GIC CPU Interface icc_sgi1r_el1 register in EL1 is map to undefined address #639

Closed mariusxp closed 5 years ago

mariusxp commented 6 years ago

have a simulator for A53 and I have a test case that try to generate an SGI from code in El1 secure but I got an exception! for GIC initialization I used the arm trusted code from https://github.com/ARM-software/arm-trusted-firmware I used this asm: msr S3_0_C12_C11_5, x0 /// ICC_SGI1R_EL1 When I checked the waves I see an access to unallocated memory 0x00_6fff_ff80 which is wrong.

I tried the equivalent instruction asm volatile ("mcrr "#coproc","#opc1", %Q0, %R0,"#CRm : : "r" (v)); but gcc not be able co process / compile it.

The compiler used is gcc 4.7.2

What is the correct equivalent instruction to be compiled ? Why I got this exception, this address is correct ? can you check also for ICC_SGI0R_EL1 register?

ghost commented 6 years ago

The correct mnemonic is the one you are using: msr S3_0_C12_C11_5, x0. The mcrr instruction is only available in AArch32 mode.

The address depends on your simulator, you aren't giving enough information. Which simulator are you using? Do you know the base addresses of the GIC registers?

mariusxp commented 6 years ago

we have an RTL simulator Synopsys VCS/DVE

mariusxp commented 6 years ago

the gic base address is :0x20500000

soby-mathew commented 6 years ago

The generation of SGIs on GICv3, is via system registers. Depending on the RTL implementation of the GICv3 IP, it may/maynot generate memory transactions but that should not matter if the implememntation is correct. The instruction encoding is correct for both the registers.

There could be several things happening here:

  1. You mentioned you are writing to the ICC_SGI0R_EL1. Is the interrupt number you are writing already configured as a Group 0 interrupt?

  2. GICv3 Group0 interrupts are usually configured as EL3 interrupts which means appropriate routing model must be configured by the SPD at EL3. If they are triggered on the FIQ line of CPU, are the appropriate FIQ routing bits in SCR_EL3 set so as to enable the right El to handle it ?

It looks like a Interrupt configuration issue to me. Although the GIC is initialized in TF-A, you need to setup the routing model and the appropriate handlers for each group. Refer https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/interrupt-framework-design.rst for details.

mariusxp commented 6 years ago

Hi Mathew,

I already took in account of all you pointed me . What the problem I have now is : The PPI is trigger in El3 (test run in el3) but when I jump into El1 secure Nothing happened. I suppose I have to do something special for El1.I enabled (ICC_SRE_EN_BIT | ICC_SRE_SRE_BIT) for ICC_SRE_EL1. But not more. I suppose I need to do more ?

Thanks marius

From: Soby Mathew [mailto:notifications@github.com] Sent: Tuesday, October 30, 2018 2:12 PM To: ARM-software/tf-issues tf-issues@noreply.github.com Cc: Predut, MariusX mariusx.predut@intel.com; Author author@noreply.github.com Subject: Re: [ARM-software/tf-issues] Arch64-A53 -GIC CPU Interface icc_sgi1r_el1 register in EL1 is map to undefined address (#639)

The generation of SGIs on GICv3, is via system registers. Depending on the RTL implementation of the GICv3 IP, it may/maynot generate memory transactions but that should not matter if the implememntation is correct. The instruction encoding is correct for both the registers.

There could be several things happening here:

  1. You mentioned you are writing to the ICC_SGI0R_EL1. Is the interrupt number you are writing already configured as a Group 0 interrupt?

  2. GICv3 Group0 interrupts are usually configured as EL3 interrupts which means appropriate routing model must be configured by the SPD at EL3. If they are triggered on the FIQ line of CPU, are the appropriate FIQ routing bits in SCR_EL3 set so as to enable the right El to handle it ?

It looks like a Interrupt configuration issue to me. Although the GIC is initialized in TF-A, you need to setup the routing model and the appropriate handlers for each group. Refer https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/interrupt-framework-design.rst for details.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/ARM-software/tf-issues/issues/639#issuecomment-434276387, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AmJIEUQv5XCBWzB4im9Jjof1DqxTWL55ks5uqEIbgaJpZM4X3rui.

Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

soby-mathew commented 6 years ago

I suppose I have to do something special for El1.I enabled (ICC_SRE_EN_BIT | ICC_SRE_SRE_BIT) for ICC_SRE_EL1.

All these are already done as part of GICv3 initialization at EL3.

The PPI is trigger in El3 (test run in el3) but when I jump into El1 secure Nothing happened.

The Test Secure Payload (TSP) in TF-A does this exactly. It configures a secure timer interrupt (PPI) to fire at regular intervals. Refer the TSP and TSPD interrupt implementation for details.

If the interrupt is pending at the GIC (GICR_ISPENDR) and not being signalled to the CPU, it is most likely a interrupt configuration issue.

soby-mathew commented 5 years ago

Please reopen if this is still an issue.