• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 347 subscribers
  • Views 4835 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GICv3: setting G1SEN / G1NSEN in GICD_CTLR

Vincent Siles

During my experiment with GICv3 using ARM Foundation platform, I tried to set GICD_CTLR value from 0x0 to 0x37 (ARE S/NS + Enable G0, G1S and G1NS)

and I got the surprise to see that the finale value of GICD_CTLR was 0x33. G1S was not enabled.

So I decided to first enable ARE S / NS, and in a second time to enable all groups, since the documentation states that switching ARE from 0 to 1 is

unpredicatable when groups are enabled.

Is this the right way to do or can I enable all 5 bits at the same time, and there is an issue with Foundation ?

Best,

V.

Parents
  • 0

    Hi,

    It looks like you're actually running the model with a GICv2 distributor which means some of those bits are read-as-zero / writes-ignored (RAZ/WI).

    If you navigate to your DS-5 installation directory and go to `/sw/models/bin/Foundation_Platform[.exe]' and run it with `--help' you'll see this:

    --(no-)gicv3           enable GICv3 or otherwise use legacy-compatible GICv2

                            (default: GICv2)

    So you need to run the model with `--gicv3'. You can do this by adding it to this box in your debug config:

    gicv3.png

    Before doing this I was seeing the same behaviour as you, but now it works as expected:

    x SP:0x2F000000

    SP:0x000000002F000000:  0x00000000

    memory set SP<verify=0>:0x2F000000 32 ((unsigned int) 0x00000030)

    memory set SP<verify=0>:0x2F000000 32 ((unsigned int) 0x00000037)

    x SP:0x2F000000

    SP:0x000000002F000000:  0x00000037

    So first I read the Secure GICD_CTLR register (that's what the SP: denotes), then I set the ARE_NS and ARE_S by writing 0x30 to it, then I set EnableGrp0, EnableGrp1NS, and EnableGrp1S by writing 0x37 to it, then finally I read the value back to ensure the write was successful.

    Note that I've used <verify=0> because there can be a small but finite delay between the write to the register becoming visible, which can confuse DS-5 as by default it will immediately verify that writes were successful.

    Hope that helps,

    Ash.

Reply
  • 0

    Hi,

    It looks like you're actually running the model with a GICv2 distributor which means some of those bits are read-as-zero / writes-ignored (RAZ/WI).

    If you navigate to your DS-5 installation directory and go to `/sw/models/bin/Foundation_Platform[.exe]' and run it with `--help' you'll see this:

    --(no-)gicv3           enable GICv3 or otherwise use legacy-compatible GICv2

                            (default: GICv2)

    So you need to run the model with `--gicv3'. You can do this by adding it to this box in your debug config:

    gicv3.png

    Before doing this I was seeing the same behaviour as you, but now it works as expected:

    x SP:0x2F000000

    SP:0x000000002F000000:  0x00000000

    memory set SP<verify=0>:0x2F000000 32 ((unsigned int) 0x00000030)

    memory set SP<verify=0>:0x2F000000 32 ((unsigned int) 0x00000037)

    x SP:0x2F000000

    SP:0x000000002F000000:  0x00000037

    So first I read the Secure GICD_CTLR register (that's what the SP: denotes), then I set the ARE_NS and ARE_S by writing 0x30 to it, then I set EnableGrp0, EnableGrp1NS, and EnableGrp1S by writing 0x37 to it, then finally I read the value back to ensure the write was successful.

    Note that I've used <verify=0> because there can be a small but finite delay between the write to the register becoming visible, which can confuse DS-5 as by default it will immediately verify that writes were successful.

    Hope that helps,

    Ash.

Children