• State Accepted Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 142 subscribers
  • Views 10350 views
  • Users 0 members are here
Options
Related
How was your experience today?

GIC-400 non-secure access

bug57520

Hi, experts

I'm the new one porting armv8 linux. I have some problem about gic400 access.

In the porting linux progress,CPU will switch to EL1NS.

In gic_dist_init() function, I read the the  GICD_ISENABLERn\GICD_ICENABLERn\GICD_ITARGETSRn\GICD_IPRIORITYRn  registers  and  get 'zero' value.

Linux kernel warns the message "GIC CPU mask not found - kernel will fail to boot."

Then I can' receive any IRQ exception and I guess it's caused GIC wrong setting.

The above registers can't access by non-secure access,right?

How can I read/write correctly the gic register?

Parents
  • 0 Arm Employee Badge in reply to bug57520

    Many of the GIC registers behave differently depending on whether the read/write is a Secure or Non-secure access. This allows, for example, the GIC to prevent Non-secure accesses seeing or modifying the settings for Secure interrupts.

    GICD_CTLR is a good example of this.

    For Secure accesses: bit[0]=EnableGrp0, bit[1]=EnableGrp1

    For Non-secure accesses: bit[0]=EnableGrp1, bit[1]=<unused>

    In other words, a Secure access can access the enables for both Secure and Non-secure interrupts.  A Non-secure access can only access the Non-secure (Group 1) enable.  So what you are describing is consistent with doing a Non-secure write.

    What I meant by "firmware" is the software that runs after a reset.  A common sequence would look something like this:

    <reset> --> boot ROM code --> firmware code from flash --> OS loaded (e.g. UEFI/U-boot) --> OS

    The first two parts (boot ROM and firmware) would typically run in Secure state.  And part of what they did would be to configure which interrupt sources are Secure/Non-secure.  You could take a look at the ARM Trusted Firmware project in GitHub for a more concrete example.

Reply
  • 0 Arm Employee Badge in reply to bug57520

    Many of the GIC registers behave differently depending on whether the read/write is a Secure or Non-secure access. This allows, for example, the GIC to prevent Non-secure accesses seeing or modifying the settings for Secure interrupts.

    GICD_CTLR is a good example of this.

    For Secure accesses: bit[0]=EnableGrp0, bit[1]=EnableGrp1

    For Non-secure accesses: bit[0]=EnableGrp1, bit[1]=<unused>

    In other words, a Secure access can access the enables for both Secure and Non-secure interrupts.  A Non-secure access can only access the Non-secure (Group 1) enable.  So what you are describing is consistent with doing a Non-secure write.

    What I meant by "firmware" is the software that runs after a reset.  A common sequence would look something like this:

    <reset> --> boot ROM code --> firmware code from flash --> OS loaded (e.g. UEFI/U-boot) --> OS

    The first two parts (boot ROM and firmware) would typically run in Secure state.  And part of what they did would be to configure which interrupt sources are Secure/Non-secure.  You could take a look at the ARM Trusted Firmware project in GitHub for a more concrete example.

Children