Cortex-M7 System Control register issue

[benoitdudu]

Hello,

I am trying to understand how Qbox works. To do so, I am testing the 'hello-qbox' example by replacing the Cortex-A53 CPU with a Cortex-M7, which I am more familiar with.

However, I am facing an issue. Accessing (read or write) the VTOR register (at address 0xE000ED08) triggers a Hard Fault interrupt.

After investigating, it appears that the transaction to this register goes to the SystemC (which is not mapped and returns a TLM error, causing the hard fault). I thought that QEMU should manage these registers. Having read the qemu code, I get the impression that the Cortex-M7 system control registers are modelled by qemu. So I don't understand why accessing these registers goes outside QEMU.

Is there something missing from the Qbox wrapper around the Cortex-M7?

Best Regards,
Benoît

[markfoodyburton]

I think you just need some memory mapped for your VTOR? You can add that in the Lua config.

[benoitdudu]

Hi Mark Burton (@markfoodyburton) ,

Adding a memory map for VTOR effectively solves the TLM error, but it does not address the underlying issue.

I looked into the qemu code a bit more and came up with the following:

• It is the nvic that is responsible for reading/writing the cpu "System Control registers" (this seems to be done in the 'nvic_readl' and 'nvic_writel' functions, cf https://github.com/qualcomm/qemu/blob/master/hw/intc/armv7m_nvic.c#L1628 ).
• The mapping of the nvic is done here https://github.com/qualcomm/qemu/blob/master/hw/arm/armv7m.c#L437 . So, I guess that we should do the same in Qbox.

I tried two things to resolve this issue.

1. Add a new memory region (as the Qbox API seems to allow that) for the nvic but I couldn't find the proper way to do that (I got a segfault).
2. Instantiate a new QemuDevice of type "armv7m". However, when I did that I got the error message here https://github.com/qualcomm/qemu/blob/master/hw/arm/armv7m.c#L294 and I didn't find a way to create clock with Qbox.

I think that adding the "armv7m" QemuDevice would be the best option. What is your opinion?

[markfoodyburton]

Sorry, I'm not 100% sure I know what you tried, did you just add some memory at the right address in your platform.lua?
I have a feeling that these read's might come out of a different address space - we have a bypass for that sort of thing called the global_periferal_initiator. Something like this - MIGHT work, but I'm not sure.

global_peripheral_initiator_arm_0 = {
        moduletype = "global_peripheral_initiator",
        args = {"&platform.qemu_inst", "&platform.cpu_0"},
        global_initiator = {bind = "&router.target_socket"},
};

If not, let me know and I'll dig further.

[benoitdudu]

Yes I just add some memory at the right address :)
I just tried the global_peripheral_initiator and it doesn't solve my issue.

[markfoodyburton]

MMm, ok, I'll ask about in the Qemu community, not 100% sure what the novice is doing....

[benoitdudu]

I tried the following things:

• main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic
  I redirect the transaction from address 0xe000e000 to 0xe001000 to the NVIC socket. This gives me the expected result (QEMU fills its internal CPU registers, and when I read from the embedded code, the values seem correct). However, I do not think this is the right approach.

• main...benoitdudu:qbox:trial_create_qemu_armv7m_object
  This is my attempt (as explained yesterday) to instantiate the QEMU 'armv7m' object. It fails in the 'armv7m_realize' function when QEMU checks whether 'clock_has_source(s->cpuclk)' is true. I think this is the right approach, but I may be wrong as I don't know the implications of doing this.

[tmarcero]

Hello benoitdudu !

If you try with Cortex-M55 (which is implemented in Qbox too and very similar to Cortex-M7), do you have the same issue with clock_has_source(s->cpuclk) ?

[markfoodyburton]

I tried the following things:

• main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic
  I redirect the transaction from address 0xe000e000 to 0xe001000 to the NVIC socket. This gives me the expected result (QEMU fills its internal CPU registers, and when I read from the embedded code, the values seem correct). However, I do not think this is the right approach.
  I don't fully understand what your doing here - it seems like you've set up some sort of pass-through, but I don't see the reason for that, how have you wired that up in the Lua file?

[benoitdudu]

Hello benoitdudu !

If you try with Cortex-M55 (which is implemented in Qbox too and very similar to Cortex-M7), do you have the same issue with clock_has_source(s->cpuclk) ?

Would you like me to try applying my modification (main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic) to the Cortex-M55? I only encountered the clk error after making my modifications.

[benoitdudu]

I tried the following things:

• main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic
  I redirect the transaction from address 0xe000e000 to 0xe001000 to the NVIC socket. This gives me the expected result (QEMU fills its internal CPU registers, and when I read from the embedded code, the values seem correct). However, I do not think this is the right approach.
  I don't fully understand what your doing here - it seems like you've set up some sort of pass-through, but I don't see the reason for that, how have you wired that up in the Lua file?

In my opinion, transactions ranging from 0xe000e000 to 0xe001000 should be managed by the QEMU nvic model. These modifications aim to do that.
For that I created a 'local' target socket connected to the cpu.socket. Inside the b_transport of this 'local' target socket I forward the transaction either to nvic socket or to the cortex-m7 socket according to the address.

I'll try to make a reproducible example by the end of the week.

[markfoodyburton]

I tried the following things:

• main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic
  I redirect the transaction from address 0xe000e000 to 0xe001000 to the NVIC socket. This gives me the expected result (QEMU fills its internal CPU registers, and when I read from the embedded code, the values seem correct). However, I do not think this is the right approach.
  I don't fully understand what your doing here - it seems like you've set up some sort of pass-through, but I don't see the reason for that, how have you wired that up in the Lua file?

In my opinion, transactions ranging from 0xe000e000 to 0xe001000 should be managed by the QEMU nvic model. These modifications aim to do that. For that I created a 'local' target socket connected to the cpu.socket. Inside the b_transport of this 'local' target socket I forward the transaction either to nvic socket or to the cortex-m7 socket according to the address.

I'll try to make a reproducible example by the end of the week.

What I see is a pair of (unconnected?) sockets that feed from one to the other.... but I don't know how you are wiring up those sockets - I don't see any 'nvic' as such ....

[benoitdudu]

I tried the following things:

• main...benoitdudu:qbox:redirect_cortexm7_internal_registers_access_to_nvic
  I redirect the transaction from address 0xe000e000 to 0xe001000 to the NVIC socket. This gives me the expected result (QEMU fills its internal CPU registers, and when I read from the embedded code, the values seem correct). However, I do not think this is the right approach.
  I don't fully understand what your doing here - it seems like you've set up some sort of pass-through, but I don't see the reason for that, how have you wired that up in the Lua file?

In my opinion, transactions ranging from 0xe000e000 to 0xe001000 should be managed by the QEMU nvic model. These modifications aim to do that. For that I created a 'local' target socket connected to the cpu.socket. Inside the b_transport of this 'local' target socket I forward the transaction either to nvic socket or to the cortex-m7 socket according to the address.
I'll try to make a reproducible example by the end of the week.

What I see is a pair of (unconnected?) sockets that feed from one to the other.... but I don't know how you are wiring up those sockets - I don't see any 'nvic' as such ....

Sorry for not being clear.
Please let me know if the schema below does not make things clearer.

┌───────────────────────────────────────────────────────┐     
│   Cortex-M7                                           │     
│                                                       │     
│                                                 socket│     
│         ┌──────────────────┐      b_transport       ┌─┼────►
│         │                  │     ┌───────────────┐  │ │     
│         │   CPU     socket─┼─────┤tsocket        ┼──┘ │     
│         │                  │     │               │    │     
│         │                  │     │ addr 0xe...   │    │     
│         └──────────────────┘     │isocket_to_nvic│    │     
│         ┌──────────────────┐     └────┬──────────┘    │     
│         │   nvic    socket │◄─────────┘               │     
│         │                  │                          │     
│         └──────────────────┘                          │     
└───────────────────────────────────────────────────────┘     

(I don't want to merge these modifications; they were just a trial.)

[markfoodyburton]

I'm not sure this is what you have built, nor what you mean.

You're right, the nvic needs to be wired in. You can look at how the context M55 does it, but that's a little "hacky" too. The cleanest way would simply be to add the nvic to the Lua file, and wire it up at the right addresses (and IRQ's). That should be a trivial change the the Lua file. You should not need to change the C/C++ code. The model is called nvic_armv7m.