• State Accepted Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 142 subscribers
  • Views 10295 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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