[Qemu-devel] Better Cortex-M support?

[Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

Hi! 

I'm currently maintaining the GNU ARM Eclipse plug-ins (http://gnuarmeclipse.livius.net/blog/), and I'm considering, for the mid-term future, adding a new debugging plug-in to run certain tests under un emulator, and the first choice was QEMU.

Do you know if there are any plans to improve the Cortex-M support? As it is now, for my needs, I would consider it barely usable.

My requirements would be:

- Cortex-M3 support, as complete as possible, including SysTick and other system peripherals.
- full semihosting support
- full integration with GDB

For future versions, support for M0/M0+/M4 would also be interesting.


The only branch that I tested and looked partly functional was from Andre Bechus (https://github.com/beckus/qemu_stm32), but this is a specific STM32 port, and I'm interested in a more generic Cortex-M emulation.


Do you know of any other branches that improve Cortex-M support?

Is there anyone else interested in contributing to such development?


Regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 10:43, Liviu Ionescu <ilg@livius.net> wrote:
> Do you know if there are any plans to improve the Cortex-M support?
> As it is now, for my needs, I would consider it barely usable.

I don't know of anybody actively working on it. If people
want to contribute patches to improve it I'm happy to review
them, but M profile is unfortunately not something I can
devote much time to myself. We do see a steady trickle of
people complaining that the M profile emulation is not
very good, so it would be nice to see it more actively
maintained upstream.

- Cortex-M3 support, as complete as possible, including
  SysTick and other system peripherals.
- full semihosting support
- full integration with GDB

I'm not sure what you mean exactly by "full integration
with GDB", but I think we have most of these at the moment,
they just have bugs in the implementation.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 14:22, Peter Maydell <peter.maydell@linaro.org> wrote:

> ... We do see a steady trickle of
> people complaining that the M profile emulation is not
> very good, so it would be nice to see it more actively
> maintained upstream.

ok, than I'll probably clone the repo, add a 'gnuarmeclipse' branch and experiment there.

> I'm not sure what you mean exactly by "full integration
> with GDB", but I think we have most of these at the moment,
> they just have bugs in the implementation.

you are right, there is some GDB support, I'll test it and see if it is enough. I have a J-Link Eclipse plug-in, I'm quite happy with Segger GDB support, and I would like a similar functionality from the emulator.

as for the semihosting support, if I try to use it, I get:

qemu: Unsupported SemiHosting SWI 0x00
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
PSR=60000173 -ZC- T svc32
Abort trap: 6

if I try to use the Bechus branch, it (more or less) works, but not while the GDB session is active, which is a limitation.

I'd also consider adding some tracing support (ITM, data tracing), etc, but I'm not sure this is reasonable with the current code.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 12:40, Liviu Ionescu <ilg@livius.net> wrote:
> as for the semihosting support, if I try to use it, I get:
>
> qemu: Unsupported SemiHosting SWI 0x00
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
> PSR=60000173 -ZC- T svc32
> Abort trap: 6

What code sequence and which semihosting function are
you trying to use here?

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 14:45, Peter Maydell <peter.maydell@linaro.org> wrote:

>> qemu: Unsupported SemiHosting SWI 0x00
>> R00=00000000 R01=00000000 R02=00000000 R03=00000000
>> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
>> R08=00000000 R09=00000000 R10=00000000 R11=00000000
>> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
>> PSR=60000173 -ZC- T svc32
>> Abort trap: 6
> 
> What code sequence and which semihosting function are
> you trying to use here?

I guess it is:

      call_host (SEMIHOSTING_SYS_WRITE0, (void*) buf);

where SEMIHOSTING_SYS_WRITE0 = 0x04.

I calibrated my code with J-Link semihosting support, which is quite complete.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 12:52, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 28 Oct 2014, at 14:45, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>>> qemu: Unsupported SemiHosting SWI 0x00
>>> R00=00000000 R01=00000000 R02=00000000 R03=00000000
>>> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
>>> R08=00000000 R09=00000000 R10=00000000 R11=00000000
>>> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
>>> PSR=60000173 -ZC- T svc32
>>> Abort trap: 6
>>
>> What code sequence and which semihosting function are
>> you trying to use here?
>
> I guess it is:
>
>       call_host (SEMIHOSTING_SYS_WRITE0, (void*) buf);
>
> where SEMIHOSTING_SYS_WRITE0 = 0x04.

Can you give the disassembly of the actual code making
the semihosting request, please? As you can see we seem
to have interpreted this as a semihosting function zero,
not 4, but it's hard to see why without seeing what the
assembly instructions are that your code is executing.

-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 14:57, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 28 October 2014 12:52, Liviu Ionescu <ilg@livius.net> wrote:
>> 
>> On 28 Oct 2014, at 14:45, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 
>>>> qemu: Unsupported SemiHosting SWI 0x00
>>>> R00=00000000 R01=00000000 R02=00000000 R03=00000000
>>>> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
>>>> R08=00000000 R09=00000000 R10=00000000 R11=00000000
>>>> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
>>>> PSR=60000173 -ZC- T svc32
>>>> Abort trap: 6
>>> 
>>> What code sequence and which semihosting function are
>>> you trying to use here?
>> 
> ...
> Can you give the disassembly of the actual code making
> the semihosting request, please? As you can see we seem
> to have interpreted this as a semihosting function zero,
> not 4, but it's hard to see why without seeing what the
> assembly instructions are that your code is executing.

right, I did some more tests, and the the actual code is:

00001564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>:
    {

      // ======================================================================
      int
      SemiHosting::BKPT(int op, void* p1, void* p2)
      {
    1564:	b480      	push	{r7}
    1566:	b085      	sub	sp, #20
    1568:	af00      	add	r7, sp, #0
    156a:	60f8      	str	r0, [r7, #12]
    156c:	60b9      	str	r1, [r7, #8]
    156e:	607a      	str	r2, [r7, #4]
        register int r0 asm("r0");
        register int r1 asm("r1") __attribute__((unused));
        register int r2 asm("r2") __attribute__((unused));

        r0 = op;
    1570:	68f8      	ldr	r0, [r7, #12]
        r1 = (int) p1;
    1572:	68bb      	ldr	r3, [r7, #8]
    1574:	4619      	mov	r1, r3
        r2 = (int) p2;
    1576:	687b      	ldr	r3, [r7, #4]
    1578:	461a      	mov	r2, r3
        asm volatile(""
            " bkpt 0xAB \n"
            : "=r"(r0)
            :
            :
        );
    157a:	beab      	bkpt	0x00ab
        return r0;
    157c:	4603      	mov	r3, r0
      }
    157e:	4618      	mov	r0, r3
    1580:	3714      	adds	r7, #20
    1582:	46bd      	mov	sp, r7
    1584:	f85d 7b04 	ldr.w	r7, [sp], #4
    1588:	4770      	bx	lr
    158a:	bf00      	nop

I also collected all calls in the test:

        BKPT(0x04, (void*) pString, (void*) 0);
     270:	2004      	movs	r0, #4
     272:	68f9      	ldr	r1, [r7, #12]
     274:	2200      	movs	r2, #0
     276:	f001 f975 	bl	1564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>


            // ADP_Stopped_ApplicationExit
            // (qemu ignores this value)
            BKPT(0x18, (void*) 0x20026, (void*) 0);
    227a:	2018      	movs	r0, #24
    227c:	4906      	ldr	r1, [pc, #24]	; (2298 <_ZN3hal4qemu4diag11SemiHosting4exitEi+0x2c>)
    227e:	2200      	movs	r2, #0
    2280:	f7ff f970 	bl	1564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>
    2284:	e006      	b.n	2294 <_ZN3hal4qemu4diag11SemiHosting4exitEi+0x28>


            // Generate an unsupported call, to force qemu to quit.
            BKPT(0xF0 + code, (void*) 0, (void*) 0);
    2286:	687b      	ldr	r3, [r7, #4]
    2288:	33f0      	adds	r3, #240	; 0xf0
    228a:	4618      	mov	r0, r3
    228c:	2100      	movs	r1, #0
    228e:	2200      	movs	r2, #0
    2290:	f7ff f968 	bl	1564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>


    22b6:	697b      	ldr	r3, [r7, #20]
    22b8:	60fb      	str	r3, [r7, #12]
    22ba:	2004      	movs	r0, #4
    22bc:	68f9      	ldr	r1, [r7, #12]
    22be:	2200      	movs	r2, #0
    22c0:	f7ff f950 	bl	1564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>


        BKPT(0x03, (void*) &ch, (void*) 0);
    22d2:	f107 030b 	add.w	r3, r7, #11
    22d6:	2003      	movs	r0, #3
    22d8:	4619      	mov	r1, r3
    22da:	2200      	movs	r2, #0
    22dc:	f7ff f942 	bl	1564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>


none seem to pass a zero value in R0.

I would check the way "bkpt 0x00ab" is processed.

you can also check the differences from Bechus version.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 13:23, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 28 Oct 2014, at 14:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> On 28 October 2014 12:52, Liviu Ionescu <ilg@livius.net> wrote:
>>>
>>> On 28 Oct 2014, at 14:45, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>
>>>>> qemu: Unsupported SemiHosting SWI 0x00
>>>>> R00=00000000 R01=00000000 R02=00000000 R03=00000000
>>>>> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
>>>>> R08=00000000 R09=00000000 R10=00000000 R11=00000000
>>>>> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
>>>>> PSR=60000173 -ZC- T svc32
>>>>> Abort trap: 6
>>>>
>>>> What code sequence and which semihosting function are
>>>> you trying to use here?
>>>
>> ...
>> Can you give the disassembly of the actual code making
>> the semihosting request, please? As you can see we seem
>> to have interpreted this as a semihosting function zero,
>> not 4, but it's hard to see why without seeing what the
>> assembly instructions are that your code is executing.
>
> right, I did some more tests, and the the actual code is:
>
> 00001564 <_ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_>:
>     {
>
>       // ======================================================================
>       int
>       SemiHosting::BKPT(int op, void* p1, void* p2)
>       {
>     1564:       b480            push    {r7}
>     1566:       b085            sub     sp, #20
>     1568:       af00            add     r7, sp, #0
>     156a:       60f8            str     r0, [r7, #12]
>     156c:       60b9            str     r1, [r7, #8]
>     156e:       607a            str     r2, [r7, #4]
>         register int r0 asm("r0");
>         register int r1 asm("r1") __attribute__((unused));
>         register int r2 asm("r2") __attribute__((unused));
>
>         r0 = op;
>     1570:       68f8            ldr     r0, [r7, #12]
>         r1 = (int) p1;
>     1572:       68bb            ldr     r3, [r7, #8]
>     1574:       4619            mov     r1, r3
>         r2 = (int) p2;
>     1576:       687b            ldr     r3, [r7, #4]
>     1578:       461a            mov     r2, r3
>         asm volatile(""
>             " bkpt 0xAB \n"
>             : "=r"(r0)
>             :
>             :
>         );
>     157a:       beab            bkpt    0x00ab
>         return r0;
>     157c:       4603            mov     r3, r0
>       }
>     157e:       4618            mov     r0, r3
>     1580:       3714            adds    r7, #20
>     1582:       46bd            mov     sp, r7
>     1584:       f85d 7b04       ldr.w   r7, [sp], #4
>     1588:       4770            bx      lr
>     158a:       bf00            nop

Hmm. That code looks OK, but as you can see from the register
dump, QEMU thinks that at the point where it complained
r0 is zero.

> I would check the way "bkpt 0x00ab" is processed.

Do you have a test binary (plus qemu command line) you
can send me?

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

> Do you have a test binary (plus qemu command line) you
> can send me?

sure: https://dl.dropboxusercontent.com/u/78151643/minimal.elf

for reference, when running the code with Bechus (2.1.1), the result is:

ilg-mbp:build ilg$ /Users/ilg/bin/qemu-system-arm -machine stm32-p103 -nographic -monitor null -serial null -semihosting -m 513M -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf  
LED Off

os::diag::Trace::Trace() @20000854

livius.net / Minimal v1.1.1, Oct 27 2014 19:57:45
uOS++ v5.1.7631, GCC 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
QEMU Processor Emulator
Synthetic ARM Cortex-M3
Cooperative scheduler, 1000 ticks/second.
...


exactly the same binary, with 2.1.50:

ilg-mbp:build ilg$  /Users/ilg/Work/NoBackup/qemu/qemu.git/arm-softmmu/qemu-system-arm -machine lm3s6965evb -nographic -monitor null -serial null -semihosting -m 513M -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf
qemu: Unsupported SemiHosting SWI 0x00
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
PSR=60000173 -ZC- T svc32
Abort trap: 6


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 13:54, Liviu Ionescu <ilg@livius.net> wrote:
>
>> Do you have a test binary (plus qemu command line) you
>> can send me?
>
> sure: https://dl.dropboxusercontent.com/u/78151643/minimal.elf

> exactly the same binary, with 2.1.50:
>
> ilg-mbp:build ilg$  /Users/ilg/Work/NoBackup/qemu/qemu.git/arm-softmmu/qemu-system-arm -machine lm3s6965evb -nographic -monitor null -serial null -semihosting -m 513M -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf
> qemu: Unsupported SemiHosting SWI 0x00
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=200ffed8 R14=000022c5 R15=0000157c
> PSR=60000173 -ZC- T svc32
> Abort trap: 6

Thanks. I've identified what's happening here, and
it's not a bug in QEMU as such. The 'lm3s6965evb'
model is of a microcontroller with 64KB of SRAM,
so valid RAM is only from 0x20000000 to 0x20010000,
but your binary is trying to use the area beyond that
as RAM as well, and is therefore misbehaving.
(We ignore any attempt to specify RAM size via the
command line -m switch, so your '-m 513M' has no effect).
You can turn on tracing of what QEMU executes like this:

./build/x86/arm-softmmu/qemu-system-arm -machine lm3s6965evb -display
none -semihosting -kernel ~/Downloads/minimal.elf -d in_asm,cpu,exec
-singlestep

and you can see (note that the register dumps
here are always for the point *before* the insn
we've just printed, as you can tell from the values
of R15):

IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x00001568:  af00       add     r7, sp, #0

Trace 0x7f4286560710 [00001568] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000004 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffef0
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=00001568
PSR=60000173 -ZC- T svc32
----------------
IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x0000156a:  60f8       str     r0, [r7, #12]

Trace 0x7f4286560750 [0000156a] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000004 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156a
PSR=60000173 -ZC- T svc32
----------------
IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x0000156c:  60b9       str     r1, [r7, #8]

Trace 0x7f42865607e0 [0000156c] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000004 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156c
PSR=60000173 -ZC- T svc32
----------------
IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x0000156e:  607a       str     r2, [r7, #4]

Trace 0x7f4286560870 [0000156e] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000004 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=0000156e
PSR=60000173 -ZC- T svc32
----------------
IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x00001570:  68f8       ldr     r0, [r7, #12]

Trace 0x7f4286560900 [00001570] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000004 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=00001570
PSR=60000173 -ZC- T svc32
----------------
IN: _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
0x00001572:  68bb       ldr     r3, [r7, #8]

Trace 0x7f4286560990 [00001572] _ZN3hal7cortexm4diag11SemiHosting4BKPTEiPvS3_
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=200ffed8
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=200ffed8 R14=000022c5 R15=00001572
PSR=60000173 -ZC- T svc32
----------------

Your stack is in invalid memory, which is treated as
"writes ignored, reads as zeros". So we get the correct
r0 value on entry, but the code stores it to the
(invalid) stack and then when it tries to read it back
it gets zero, which is incorrect.

It's just a coincidence that the first thing your binary
does that relies on a working stack happens to involve
semihosting.

I suggest you relink your binary to fit in the 64K
of RAM this board has. (There's also flash at address
zero.)

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 16:18, Peter Maydell <peter.maydell@linaro.org> wrote:

> Thanks. I've identified what's happening here, and
> it's not a bug in QEMU as such. The 'lm3s6965evb'
> model is of a microcontroller with 64KB of SRAM,
> so valid RAM is only from 0x20000000 to 0x20010000,
> but your binary is trying to use the area beyond that
> as RAM as well, and is therefore misbehaving.

outch! 

actually my application is not for lm3s6965evb at all, it is a generic Cortex-M3 application, and in the past I could use 'qemu-system-arm -cpu cortex-m3' to run it, but now I got an error and had to enter one of the Cortex-M boards.

> (We ignore any attempt to specify RAM size via the
> command line -m switch, so your '-m 513M' has no effect).

that explains it. my linker script assumes 1MB of flash and 1MB of RAM.

what would be the recommended solution for a generic Cortex-M3 emulation, make it back work with '-cpu cortex-m3' or do you mandate to use add a generic '-machine cortex-m3'?

> I suggest you relink your binary to fit in the 64K
> of RAM this board has. (There's also flash at address
> zero.)

yeah, the flash issue is another item on my features list.

the behaviour that I expect is to have the flash as a read only area, where gdb will be allowed to write in a similar way as when writing the physical flash (same as J-Link does).

is this supported by the current version?


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 14:37, Liviu Ionescu <ilg@livius.net> wrote:
> On 28 Oct 2014, at 16:18, Peter Maydell <peter.maydell@linaro.org> wrote:
>> Thanks. I've identified what's happening here, and
>> it's not a bug in QEMU as such. The 'lm3s6965evb'
>> model is of a microcontroller with 64KB of SRAM,
>> so valid RAM is only from 0x20000000 to 0x20010000,
>> but your binary is trying to use the area beyond that
>> as RAM as well, and is therefore misbehaving.

>> (We ignore any attempt to specify RAM size via the
>> command line -m switch, so your '-m 513M' has no effect).
>
> that explains it. my linker script assumes 1MB of flash and 1MB of RAM.
>
> what would be the recommended solution for a generic Cortex-M3 emulation, make it back work with '-cpu cortex-m3' or do you mandate to use add a generic '-machine cortex-m3'?

There's no such thing as a "generic Cortex-M3 emulation".
We model actual hardware (though in this case not a very
useful set of boards).

>> I suggest you relink your binary to fit in the 64K
>> of RAM this board has. (There's also flash at address
>> zero.)
>
> yeah, the flash issue is another item on my features list.
>
> the behaviour that I expect is to have the flash as a read only
> area, where gdb will be allowed to write in a similar way as when
> writing the physical flash (same as J-Link does).

I think writes via gdb will be treated in the same way as
writes by the CPU (ie interpreted as attempts to program
the flash device). QEMU doesn't support a "debug access"
abstraction.

-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 16:40, Peter Maydell <peter.maydell@linaro.org> wrote:

> There's no such thing as a "generic Cortex-M3 emulation".
> We model actual hardware (though in this case not a very
> useful set of boards).

at least for now I do not plan to go into emulating actual hardware, I'd like to first fix the generic cortex-m.

I'll probably make a branch and see if I can bring back -cpu cortex-m3, otherwise I'll add a virtual cortex-m3 'machine', so I can run my tests.

> I think writes via gdb will be treated in the same way as
> writes by the CPU (ie interpreted as attempts to program
> the flash device). QEMU doesn't support a "debug access"
> abstraction.

ok, I'll think on how to improve this.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 14:50, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 28 Oct 2014, at 16:40, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> There's no such thing as a "generic Cortex-M3 emulation".
>> We model actual hardware (though in this case not a very
>> useful set of boards).
>
> at least for now I do not plan to go into emulating actual hardware,
> I'd like to first fix the generic cortex-m.

There really is no such thing. Allowing command lines that
just specified a cortex-m3 CPU with no machine was an
error, which is why we don't let you do it any more.

> I'll probably make a branch and see if I can bring back
> -cpu cortex-m3, otherwise I'll add a virtual cortex-m3
> 'machine', so I can run my tests.

Pick some real hardware to model, please.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 14:59, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 28 October 2014 14:50, Liviu Ionescu <ilg@livius.net> wrote:
>> I'll probably make a branch and see if I can bring back
>> -cpu cortex-m3, otherwise I'll add a virtual cortex-m3
>> 'machine', so I can run my tests.
>
> Pick some real hardware to model, please.

You might be able to achieve what you want by making the
existing stellaris boards a bit more flexible, so they honour
the command line '-m' option to specify the SRAM size; that
would be much less effort I think.

-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 17:03, Peter Maydell <peter.maydell@linaro.org> wrote:

> existing stellaris boards a bit more flexible, so they honour
> the command line '-m' option to specify the SRAM size; 

thank you, I'll consider this, but generally I would like to avoid making my plug-in configuration specific for a certain vendor/board.

another solution I considered was to add the ARM SC300, which is more or less manufacturer neutral, but the emulation will obviously not include the 'secure' features.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 15:22, Liviu Ionescu <ilg@livius.net> wrote:
> On 28 Oct 2014, at 17:03, Peter Maydell <peter.maydell@linaro.org> wrote:
>> existing stellaris boards a bit more flexible, so they honour
>> the command line '-m' option to specify the SRAM size;
>
> thank you, I'll consider this, but generally I would like to avoid
> making my plug-in configuration specific for a certain vendor/board.

It is simply not possible to avoid being specific here. QEMU
insists that you say which machine model you want to run on,
and the Cortex-M3 CPU itself does not define all the properties
of a machine.

If your test code really restricts itself to just the functionality
in the core CPU then it should work fine on one of our
existing M3 models. I don't think it makes sense to try
to have a "generic M3" board in QEMU.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 17:38, Peter Maydell <peter.maydell@linaro.org> wrote:

> It is simply not possible to avoid being specific here. QEMU
> insists that you say which machine model you want to run on,
> and the Cortex-M3 CPU itself does not define all the properties
> of a machine.
> 
> If your test code really restricts itself to just the functionality
> in the core CPU then it should work fine on one of our
> existing M3 models. I don't think it makes sense to try
> to have a "generic M3" board in QEMU.

from the point of view of QEMU, you are probably right.

from the point of view of the build/debug processes, things are a bit different.

when you create a new project, you usually assign a device to this project, and this device definition auto-magically configures many other build configuration details, for example defines the CMSIS headers to be used, defines the memory map, the hardware initialisations and so on.

similarly, when you create a debug configuration, the same device name is passed to the (J-Link) debugger, and the debugger knows how to connect via jtag/swd and how to write the flash.

(the above apply to GNU ARM Eclipse plug-ins, but should be similar to most development environments).


assuming the cortex-m emulation is complete, ideally the same configuration used to create a physical (J-Link) debug configuration should be used to create an emulated (qemu) debug configuration.

however this is not that easy, since some/most peripherals are not available, so it is preferable to not allow the application to access the CMSIS peripheral definitions, which means it is recommended to not use the same build configuration as for physical devices, but one tailored for emulation.

I checked the ARM CMSIS definitions and they provide some more or less generic definitions, for example they provide the device names ARMCM0, ARMCM0P, ARMCM3, ARMCM4, etc.

I'm not sure what the QEMU definition of '-machine' stands for, a device or a board, but I think that the ARM definitions are good candidates for QEMU emulation names.

once the core Cortex-M emulation is fully functional, it should be easier to add support for specific devices, by configuring some of the parameters (flash/ram, add some peripherals, etc).

going with the analyse even further, from the development point of view it would be useful to define some virtual hardware, similar to the devices defined in virtual machines, like VMware, for example virtual Ethernet devices, virtual USB, virtual USART, etc and then add drivers for these virtual devices, to have a convenient test platform for TCP/IP stacks, USB stacks, etc.

for this latest case it is obvious that the emulation will not match any physical device, since it might get implemented with semihosting like technologies, and custom device names (like QEMUCM3, for example) would be a more appropriate solution.

---

to conclude, from the Eclipse plug-ins point of view, I would prefer to build projects targeted for more or less generic devices like ARMCM3 (possibly QEMUCM3, after adding virtual devices) to run them on QEMU, instead of targeting them to any specific device (like Luminary or STM).

similarly, if adding a board is mandatory, I would add definitions to refer to devices like ARMCM3, instead of specific boards with specific devices.

---

there are many things to discuss related to the integration of an emulator in a development suite, and on the usability of such a solution, and I'm convinced the experience of the developers on this list is amazing, unfortunately up to now it was not fully used for helping those working with Cortex-M devices.

regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 16:38, Liviu Ionescu <ilg@livius.net> wrote:
> I'm not sure what the QEMU definition of '-machine' stands for, a device
> or a board, but I think that the ARM definitions are good candidates for
> QEMU emulation names.

-machine specifies a board name. We don't care how you build the binary
for the board or what library you choose to use for hardware abstraction.

> once the core Cortex-M emulation is fully functional, it should be
> easier to add support for specific devices, by configuring some of
> the parameters (flash/ram, add some peripherals, etc).

QEMU doesn't conveniently support runtime flexible specification
of what is present in an emulated board (beyond very basic things
like "how much RAM"). What the .c file in the QEMU sources defines
is what you get.

> going with the analyse even further, from the development point of
> view it would be useful to define some virtual hardware, similar to
> the devices defined in virtual machines, like VMware, for example
> virtual Ethernet devices, virtual USB, virtual USART, etc

You could maybe do this with virtio-mmio. I'm reluctant to define
a virtual board for M profile though -- we're having enough trouble
managing the configuration for the "virt" board we added for A
profile KVM use. Modelling real hardware is much more manageable
because there is a defined thing you're trying to match.

> similarly, if adding a board is mandatory, I would add definitions
> to refer to devices like ARMCM3, instead of specific boards with
> specific devices.

I had a quick look at the CMSIS headers for ARMCM3 and they
look to me like they're defining information for a specific
board (probably an fpga or dev board from ARM for the Cortex-M3):
there's information about UARTs, external interrupts, FPGA
devices, and so on.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 19:08, Peter Maydell <peter.maydell@linaro.org> wrote:

>> once the core Cortex-M emulation is fully functional, it should be
>> easier to add support for specific devices, by configuring some of
>> the parameters (flash/ram, add some peripherals, etc).
> 
> QEMU doesn't conveniently support runtime flexible specification
> of what is present in an emulated board (beyond very basic things
> like "how much RAM"). What the .c file in the QEMU sources defines
> is what you get.

the CMSIS packs and especially the SVD files (my GNU ARM Eclipse J-link plug-in uses the SVD files available in CMSIS packs to examine/modify the peripheral registers) contain quite detailed descriptions of the actual hardware, it would be great if the emulator could make use of interesting entries, like memory map, and, at least partially, support any existing device.

but I guess this is way beyond the scope of this project.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Christopher Covington]

On 10/28/2014 01:08 PM, Peter Maydell wrote:
> On 28 October 2014 16:38, Liviu Ionescu <ilg@livius.net> wrote:
>> I'm not sure what the QEMU definition of '-machine' stands for, a device
>> or a board, but I think that the ARM definitions are good candidates for
>> QEMU emulation names.
> 
> -machine specifies a board name. We don't care how you build the binary
> for the board or what library you choose to use for hardware abstraction.
> 
>> once the core Cortex-M emulation is fully functional, it should be
>> easier to add support for specific devices, by configuring some of
>> the parameters (flash/ram, add some peripherals, etc).
> 
> QEMU doesn't conveniently support runtime flexible specification
> of what is present in an emulated board (beyond very basic things
> like "how much RAM"). What the .c file in the QEMU sources defines
> is what you get.

I've sometimes thought it might be cool if QEMU could consume a DTB and
emulate whatever is described, assuming the devices and configurations are
supported. I've yet to come up with a real problem to motivate this
"solution", though.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Qemu-devel] Better Cortex-M support?

[Andreas Färber]

Am 29.10.2014 um 14:28 schrieb Christopher Covington:
> On 10/28/2014 01:08 PM, Peter Maydell wrote:
>> On 28 October 2014 16:38, Liviu Ionescu <ilg@livius.net> wrote:
>>> I'm not sure what the QEMU definition of '-machine' stands for, a device
>>> or a board, but I think that the ARM definitions are good candidates for
>>> QEMU emulation names.
>>
>> -machine specifies a board name. We don't care how you build the binary
>> for the board or what library you choose to use for hardware abstraction.
>>
>>> once the core Cortex-M emulation is fully functional, it should be
>>> easier to add support for specific devices, by configuring some of
>>> the parameters (flash/ram, add some peripherals, etc).
>>
>> QEMU doesn't conveniently support runtime flexible specification
>> of what is present in an emulated board (beyond very basic things
>> like "how much RAM"). What the .c file in the QEMU sources defines
>> is what you get.
> 
> I've sometimes thought it might be cool if QEMU could consume a DTB and
> emulate whatever is described, assuming the devices and configurations are
> supported. I've yet to come up with a real problem to motivate this
> "solution", though.

Xilinx already implemented something along those lines in their branch.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 29 October 2014 13:28, Christopher Covington <cov@codeaurora.org> wrote:
> I've sometimes thought it might be cool if QEMU could consume a DTB and
> emulate whatever is described, assuming the devices and configurations are
> supported. I've yet to come up with a real problem to motivate this
> "solution", though.

This has been suggested before, but unfortunately it's not really
feasible except in certain constrained scenarios (for instance
the Xilinx work Andreas mentioned, where as I understand it they
have one tool that generates the DTB and the FPGA they're trying
to model and so it's easy to be sure the DTB has all the necessary
information).

The fundamental issue is that a DTB is basically a data structure
controlled by the kernel -- it contains all the information the
kernel needs to know about how the hardware is configured and
wired up together, where the kernel can't dynamically probe for it.
The information QEMU needs to know to be able to model a board is
related but not the same (and why would the kernel people modify
their device tree files to add information that only QEMU cares
about?) So it sounds nice but in practice it gets very quickly
into a morass of problems I think.

[To take one example, boards with CPUs that support TrustZone
may have devices that appear only in the Secure world, but there's
no way in a device tree to indicate this. The kernel doesn't
care because it only executes in one world and only needs to
know about the devices that exist there.]

-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Paolo Bonzini]

On 10/28/2014 03:40 PM, Peter Maydell wrote:
> I think writes via gdb will be treated in the same way as
> writes by the CPU (ie interpreted as attempts to program
> the flash device). QEMU doesn't support a "debug access"
> abstraction.

I think they should work right.  See cpu_memory_rw_debug.

Paolo

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 29 Oct 2014, at 17:11, Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 10/28/2014 03:40 PM, Peter Maydell wrote:
>> I think writes via gdb will be treated in the same way as
>> writes by the CPU (ie interpreted as attempts to program
>> the flash device). QEMU doesn't support a "debug access"
>> abstraction.
> 
> I think they should work right.  See cpu_memory_rw_debug.

I'm not sure I can follow you. do you mean there is a recent patch that fixed this?

otherwise, according to my tests, when the GDB session is active, the semihosting output is no longer displayed in the qemu console.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Paolo Bonzini]

On 10/29/2014 04:18 PM, Liviu Ionescu wrote:
> 
> On 29 Oct 2014, at 17:11, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 10/28/2014 03:40 PM, Peter Maydell wrote:
>>> I think writes via gdb will be treated in the same way as
>>> writes by the CPU (ie interpreted as attempts to program
>>> the flash device). QEMU doesn't support a "debug access"
>>> abstraction.
>>
>> I think they should work right.  See cpu_memory_rw_debug.
> 
> I'm not sure I can follow you. do you mean there is a recent patch that fixed this?
> 
> otherwise, according to my tests, when the GDB session is active, the semihosting output is no longer displayed in the qemu console.

That's due to usage of the breakpoint instruction, as Peter pointed out.

I mean that writes to ROM or flash via gdb should modify the ROM
directly, unlike writes by the CPU.

Paolo

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 29 Oct 2014, at 17:31, Paolo Bonzini <pbonzini@redhat.com> wrote:

> That's due to usage of the breakpoint instruction, as Peter pointed out.

>> Are we treating the
>> breakpoint as a breakpoint and dropping into gdb
>> rather than treating it as a semihosting call?

my first thought was that the semihosting BRKs go to GDB, but execution does not stop at these places, the semihosting BRKs seem ignored.

from my tests GDB looks normal, no unexpected breaks.

just that nothing is displayed on the semihosting output.

> I mean that writes to ROM or flash via gdb should modify the ROM
> directly, unlike writes by the CPU.

you may be right, but I don't see the point related to semihosting, in this case the BRKs are permanent in flash.

but if you understand these implementation details, could you suggest a fix?

you can use the same executable I used for tests (https://dl.dropboxusercontent.com/u/78151643/minimal.elf), it does a lot of semihosting tracing.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Paolo Bonzini]

On 10/29/2014 05:37 PM, Liviu Ionescu wrote:
>> > I mean that writes to ROM or flash via gdb should modify the ROM
>> > directly, unlike writes by the CPU.
> you may be right, but I don't see the point related to semihosting, in this case the BRKs are permanent in flash.

It's not, it's just something else you brought up. :)

Paolo

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 16:18, Peter Maydell <peter.maydell@linaro.org> wrote:

> (There's also flash at address zero.)

if this is wrong, can you suggest a fix? some time ago when I first used qemu the entire memory was similar, ram or flash alike. should I define them explicitly?

> so valid RAM is only from 0x20000000 to 0x20010000,
...
> I suggest you relink your binary to fit in the 64K
> of RAM this board has.

https://dl.dropboxusercontent.com/u/78151643/minimal.elf


with the above updated file it runs fine standalone with:

/opt/local/bin/qemu-system-arm -machine lm3s6965evb -nographic -monitor null -serial null -semihosting -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf

but if I add '-gdb tcp::51234 -S', I can connect with GDB and debug, but the semihosting output is no longer working.

is this a bug or a feature that I missed?


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 29 October 2014 07:03, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 28 Oct 2014, at 16:18, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> (There's also flash at address zero.)
>
> if this is wrong, can you suggest a fix?

No, it's correct, because it's what the board has.

> some time ago when I first used qemu the entire memory
> was similar, ram or flash alike. should I define them explicitly?

I'm pretty sure this is because you were accidentally
using a totally broken QEMU config that put an M class CPU
into a board model that doesn't work with M class CPUs,
and which happened to have a lot of RAM in the area
you were using.

The memory layout (which bits are flash and which RAM)
depend on the board you're targeting. So you need to make
sure you compile for the right hardware.

>> so valid RAM is only from 0x20000000 to 0x20010000,
> ...
>> I suggest you relink your binary to fit in the 64K
>> of RAM this board has.
>
> https://dl.dropboxusercontent.com/u/78151643/minimal.elf
>
>
> with the above updated file it runs fine standalone with:
>
> /opt/local/bin/qemu-system-arm -machine lm3s6965evb -nographic -monitor null -serial null -semihosting -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf
>
> but if I add '-gdb tcp::51234 -S', I can connect with GDB
> and debug, but the semihosting output is no longer working.
>
> is this a bug or a feature that I missed?

I think I'd call that a bug; I suspect there's an
unfortunate interaction between the gdbstub and
semihosting because for M profile semihosting is hooked
off the breakpoint instruction. Are we treating the
breakpoint as a breakpoint and dropping into gdb
rather than treating it as a semihosting call?
(On A/R profile this problem doesn't exist because
semihosting calls use SVC.)

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 29 Oct 2014, at 12:31, Peter Maydell <peter.maydell@linaro.org> wrote:

> I think I'd call that a bug; I suspect there's an
> unfortunate interaction between the gdbstub and
> semihosting ...

should we open a ticket for this?

regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Fabien Chouteau]

On 10/28/2014 11:43 AM, Liviu Ionescu wrote:
> Hi! 
> 
> I'm currently maintaining the GNU ARM Eclipse plug-ins (http://gnuarmeclipse.livius.net/blog/), and I'm considering, for the mid-term future, adding a new debugging plug-in to run certain tests under un emulator, and the first choice was QEMU.
> 
> Do you know if there are any plans to improve the Cortex-M support? As it is now, for my needs, I would consider it barely usable.
> 

I think Francis Alistair [1] is working on STM32 support, search for Netduino patches.

We also have partial support for STM32F4 on our repository [2], look inside the qemu-stable-2.0.0 branch.

Regards,

[1] alistair23@gmail.com
[2] https://forge.open-do.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=couverture-qemu/couverture-qemu.git;a=summary

Re: [Qemu-devel] Better Cortex-M support?

[Alistair Francis]

On Tue, Nov 4, 2014 at 10:05 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 10/28/2014 11:43 AM, Liviu Ionescu wrote:
>> Hi!
>>
>> I'm currently maintaining the GNU ARM Eclipse plug-ins (http://gnuarmeclipse.livius.net/blog/), and I'm considering, for the mid-term future, adding a new debugging plug-in to run certain tests under un emulator, and the first choice was QEMU.
>>
>> Do you know if there are any plans to improve the Cortex-M support? As it is now, for my needs, I would consider it barely usable.
>>
>
> I think Francis Alistair [1] is working on STM32 support, search for Netduino patches.

That's true, I am working on support for the Netduino 2 (STM32F205),
I'm hoping it will be accepted soon.
I'm not sure if it will help with what you want but you are welcome to
have a look and I will help where I can. The latest patch is available
at: https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg03059.html
and it has more details

Thanks,

Alistair

>
> We also have partial support for STM32F4 on our repository [2], look inside the qemu-stable-2.0.0 branch.
>
> Regards,
>
> [1] alistair23@gmail.com
> [2] https://forge.open-do.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=couverture-qemu/couverture-qemu.git;a=summary
>

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 28 Oct 2014, at 12:43, Liviu Ionescu <ilg@livius.net> wrote:

> ... GNU ARM Eclipse plug-ins (http://gnuarmeclipse.livius.net/blog/), and I'm considering, for the mid-term future, adding a new debugging plug-in to run certain tests under un emulator

I did the first steps towards this, I added a branch of QEMU as a sub-project of GNU ARM Eclipse.

I fixed the semihosting/gdb problems, and I added some cosmetic features (like some verbosity, accept to load image via GDB without -kernel, some option aliases).

I also documented the build procedure on Windows/Linux/Mac and the intended use cases:

http://gnuarmeclipse.livius.net/wiki/The_GNU_ARM_Eclipse_Plug-ins_Developer_Wiki#QEMU


Next I plan to add support for new boards, mainly STM32F ones, probably starting with STM32F4-DISCOVERY.

I tried to make my patches as generic as possible, to easily contribute them back to the main distribution, if anyone is interested.

I'd be happy if GNU ARM Eclipse QEMU would catalyse/concentrate development for Cortex-M emulation.

> I think Francis Alistair [1] is working on STM32 support, search for Netduino patches.

I plan to analyse all existing solutions, and, if Francis agrees to contribute his changes to GNU ARM Eclipse, I can consider them for inclusion.

Regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 11 November 2014 21:56, Liviu Ionescu <ilg@livius.net> wrote:
> I fixed the semihosting/gdb problems, and I added some cosmetic
> features (like some verbosity, accept to load image via GDB
> without -kernel, some option aliases).

> Next I plan to add support for new boards, mainly STM32F ones,
> probably starting with STM32F4-DISCOVERY.

Cortex-M4 support would definitely be interesting.

> I tried to make my patches as generic as possible, to easily
> contribute them back to the main distribution, if anyone is
> interested.

I'm certainly interested in fixes and improvements being
contributed back to QEMU mainline. In general people tend
to find that maintaining boards and bugfixes out of tree
is more expensive (in time and maintenance effort) than
they first expect -- it can make it pretty tricky to
update to new versions of QEMU. In the long run it often
works out better to pay the up front cost of getting the
code through our review process, because once you've done
that it's done forever...

If you have some fixes you think should be in mainline
the first step is to send patches to us.

-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 12 Nov 2014, at 01:08, Peter Maydell <peter.maydell@linaro.org> wrote:

> Cortex-M4 support would definitely be interesting.

:-)

any hints on what is missing for Cortex-M4 support? are all thumb instructions supported? the hard FP? 

> If you have some fixes you think should be in mainline
> the first step is to send patches to us.

sure, I'd be happy to contribute all my changes back.

do you really need the git format-patch files sent via email? I thought that using a remote to my git://git.code.sf.net/p/gnuarmeclipse/qemu is easier.

I tried to make my changes not affect the current arm-softmmu configuration, and for this I added a new target gnuarmeclipse-softmmu.

I also added 3 new configuration variables (branding_message="", semihosting_native="no", verbose="no") to control the features I added, and enable them only on the gnuarmeclipse target. these variables are passed to config-host.h and used to include my changes.

hopefully these will not damage anything in the current distribution (but need to be checked).


some of my intermediate commits were changed in subsequent commits, so only the final result is relevant.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 12 November 2014 12:50, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 12 Nov 2014, at 01:08, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> Cortex-M4 support would definitely be interesting.
>
> :-)
>
> any hints on what is missing for Cortex-M4 support? are all thumb
> instructions supported? the hard FP?

The instructions themselves are generally supported for
the A profile cores, so getting that part right would mostly
involve enabling those feature bits for the new M4 CPU class.
The difficult bits are going to involve:
 * correct trapping when fp is disabled
 * getting the exception handling right, including lazy
   exception frame population
 * bits where M profile FP differs from A profile (eg fp
   status and ID registers being memory mapped)

> sure, I'd be happy to contribute all my changes back.
>
> do you really need the git format-patch files sent via
> email? I thought that using a remote to my
> git://git.code.sf.net/p/gnuarmeclipse/qemu is easier.

It's easier for us on the receiving end to have patches sent
as email, because it means we can conveniently review them
in public on the mailing list. I'm afraid a lot of our
conventions for accepting patches are based around making
life easier for the maintainers doing the review, because
we're generally pretty heavily loaded with work. There's
a summary at http://wiki.qemu.org/Contribute/SubmitAPatch
of how it works.

> I tried to make my changes not affect the current arm-softmmu
> configuration, and for this I added a new target gnuarmeclipse-softmmu.

For upstream we would just want to fix arm-softmmu, I think.

> I also added 3 new configuration variables (branding_message="",
> semihosting_native="no", verbose="no") to control the features
> I added, and enable them only on the gnuarmeclipse target.
> these variables are passed to config-host.h and used to include my changes.

It sounds like you should separate out the things which are
bug fixes to upstream from the parts which are integration
with Eclipse. The former are going to be easier to get upstream
than the latter, so you can start with the easier parts first.

> some of my intermediate commits were changed in subsequent commits,
> so only the final result is relevant.

For submitting changes upstream you'll need to clean up
this set of commits (rebase, rearrange, split or merge commits,
etc so you have one commit (patch) per thing you're fixing and
it's a clean change that stands on its own.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 12 Nov 2014, at 15:02, Peter Maydell <peter.maydell@linaro.org> wrote:

> The instructions themselves are generally supported for
> the A profile cores, so getting that part right would mostly
> involve enabling those feature bits for the new M4 CPU class.

ok

> The difficult bits are going to involve:
> * correct trapping when fp is disabled
> * getting the exception handling right, including lazy
>   exception frame population
> * bits where M profile FP differs from A profile (eg fp
>   status and ID registers being memory mapped)

all seem related to FP, which, for my priority list, comes second, after specific vendor system registers for the supported processors.

my first priority is to make the emulator run the images generated by the project templates *without* any changes.

this requires the presence of the registers used by the CMSIS SystemInit() call, which generally are vendor specific, related to clock settings (pll & co).

> For upstream we would just want to fix arm-softmmu, I think.

for me, the plain arm-softmmu is not usable, since it forwards the semihosting calls via gdb instead of using native implementation, so I had to add a configuration variable to change this behaviour.

> For submitting changes upstream you'll need to clean up
> this set of commits (rebase, rearrange, split or merge commits,
> etc so you have one commit (patch) per thing you're fixing and
> it's a clean change that stands on its own.

I understand. I'll consider this, but we'll probably postpone until significant improvements are there and someone else needs them.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 12 November 2014 13:43, Liviu Ionescu <ilg@livius.net> wrote:
> all seem related to FP, which, for my priority list, comes second,
> after specific vendor system registers for the supported processors.
>
> my first priority is to make the emulator run the images generated
> by the project templates *without* any changes.
>
> this requires the presence of the registers used by the CMSIS
> SystemInit() call, which generally are vendor specific, related
> to clock settings (pll & co).

This sounds to me like it's part of the SoC and/or board rather
than the CPU itself. You'll need to model the SoC and board,
which can be a fair bit of work. (Our existing M3 code isn't
a great example, either. I'd suggest looking at Alistair's patches
on the list for supporting the netduino2, if you haven't already.)

>> For upstream we would just want to fix arm-softmmu, I think.
>
> for me, the plain arm-softmmu is not usable, since it forwards the
> semihosting calls via gdb instead of using native implementation,
> so I had to add a configuration variable to change this behaviour.

That sounds like the kind of thing that other people might also
want to be able to do, so it would be better to make arm-softmmu
be runtime configurable on this, I think.

thanks
-- PMM

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 12 Nov 2014, at 15:51, Peter Maydell <peter.maydell@linaro.org> wrote:

> ... I'd suggest looking at Alistair's patches
> on the list for supporting the netduino2,

will certainly do.

and I also plan to review the patches of Andre Bechus, available from https://github.com/beckus/qemu_stm32.

>> for me, the plain arm-softmmu is not usable, since it forwards the
>> semihosting calls via gdb instead of using native implementation,
>> so I had to add a configuration variable to change this behaviour.
> 
> That sounds like the kind of thing that other people might also
> want to be able to do, so it would be better to make arm-softmmu
> be runtime configurable on this, I think.

for the gnuarmeclipse-qemu target, since I never need to forward semihosting to gdb, the solution was to add a configuration variable and statically set it at build time to always use native calls.

--- gdbstub.c ---
/* If gdb is connected when the first semihosting syscall occurs then use
   remote gdb syscalls.  Otherwise use native file IO.  */
int use_gdb_syscalls(void)
{
#if !defined(CONFIG_SEMIHOSTING_NATIVE)
    if (gdb_syscall_mode == GDB_SYS_UNKNOWN) {
        gdb_syscall_mode = (gdbserver_state ? GDB_SYS_ENABLED
                                            : GDB_SYS_DISABLED);
    }
    return gdb_syscall_mode == GDB_SYS_ENABLED;
#else
    // Make semihosting always use native file IO.
    if (gdb_syscall_mode == GDB_SYS_UNKNOWN) {
        gdb_syscall_mode = GDB_SYS_DISABLED;
    }
    return FALSE;
#endif
}

for arm-softmmu you probably need a way to configure this at run-time, which would involve a new monitor command, that can be issued from the GDB client via 'mon XXXX'.

I guess you are not happy with a new gnuarmeclipse-qemu target, but since my experience with arm-softmmu is almost null, I want to avoid breaking anything there.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Alistair Francis]

On Thu, Nov 13, 2014 at 12:23 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 12 Nov 2014, at 15:51, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> ... I'd suggest looking at Alistair's patches
>> on the list for supporting the netduino2,

I figure I will fill you in on what I am trying to do, in case it is any help.

I am trying to model the Netduino Plus 2 (STM32F4xx - Cortex-M4) board
in QEMU. I didn't want to spend time on implementing the Cortex-M4 CPU
as for my use case I don't need it, so out of tree I have the Netduino
Plus 2 with a Cortex-M3. I am trying to get as much of my work
upstreamed to mainline by using the Netduino 2 board (STM32F2xx -
Cortex-M3). There are a few submissions on list and hopefully after
the release of 2.2 it will be accepted.

All of my work can be seen at: https://github.com/alistair23/qemu.
Some of it is specific for my use case (it is aimed as a learning tool
for a University class) so if you need any help understanding what I
did just ask and I am happy to help. Support for the Cortex-M4 would
be great so I will help where I can.

Thanks,

Alistair

>
> will certainly do.
>
> and I also plan to review the patches of Andre Bechus, available from https://github.com/beckus/qemu_stm32.
>
>>> for me, the plain arm-softmmu is not usable, since it forwards the
>>> semihosting calls via gdb instead of using native implementation,
>>> so I had to add a configuration variable to change this behaviour.
>>
>> That sounds like the kind of thing that other people might also
>> want to be able to do, so it would be better to make arm-softmmu
>> be runtime configurable on this, I think.
>
> for the gnuarmeclipse-qemu target, since I never need to forward semihosting to gdb, the solution was to add a configuration variable and statically set it at build time to always use native calls.
>
> --- gdbstub.c ---
> /* If gdb is connected when the first semihosting syscall occurs then use
>    remote gdb syscalls.  Otherwise use native file IO.  */
> int use_gdb_syscalls(void)
> {
> #if !defined(CONFIG_SEMIHOSTING_NATIVE)
>     if (gdb_syscall_mode == GDB_SYS_UNKNOWN) {
>         gdb_syscall_mode = (gdbserver_state ? GDB_SYS_ENABLED
>                                             : GDB_SYS_DISABLED);
>     }
>     return gdb_syscall_mode == GDB_SYS_ENABLED;
> #else
>     // Make semihosting always use native file IO.
>     if (gdb_syscall_mode == GDB_SYS_UNKNOWN) {
>         gdb_syscall_mode = GDB_SYS_DISABLED;
>     }
>     return FALSE;
> #endif
> }
>
> for arm-softmmu you probably need a way to configure this at run-time, which would involve a new monitor command, that can be issued from the GDB client via 'mon XXXX'.
>
> I guess you are not happy with a new gnuarmeclipse-qemu target, but since my experience with arm-softmmu is almost null, I want to avoid breaking anything there.
>
>
> regards,
>
> Liviu
>
>
>

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 13 Nov 2014, at 02:11, Alistair Francis <alistair23@gmail.com> wrote:

> I am trying to model the Netduino Plus 2 (STM32F4xx - Cortex-M4) board...
> upstreamed to mainline by using the Netduino 2 board (STM32F2xx -
> Cortex-M3).

ok, great work!

however, I'm more interested in a more systematic approach; before going into the devices of a specific board, I would like to know that (in order)
- the core Cortex-M is properly supported, then
- the specific Cortex-M0/0+/3/4/(7) are supported (system devices, debug registers, etc), then
- the STM families STM32F[012347] are supported, then
- specific devices like STM32F405/STM32F205/etc are supported (well, at a certain degree, at least run the CMSIS SysInit() init code), and then 
- implement board peripherals.

can you confirm that your code properly runs the CMSIS SysInit() code, and that using SysTick in the application properly sets the timer frequency, based on the actual processor clock setting?

in my GNU ARM Eclipse plug-ins I have C/C++ project templates for most STM processor families; the results are simple but fully functional Blinky projects, using SysTick for time reference and trace_printf() via semi-hosting or SVD; my first priority is to be able to run these projects on QEMU, and this requires, in addition to system peripherals, only a GPIO port, so it must be is relatively easy to implement.

> All of my work can be seen at: https://github.com/alistair23/qemu.
> Some of it is specific for my use case (it is aimed as a learning tool
> for a University class) so if you need any help understanding what I
> did just ask and I am happy to help.

thank you, I appreciate it.

> Support for the Cortex-M4 would
> be great so I will help where I can.

up to now I fixed the semihosting/gdb issues, and prepared a version that can be easily integrated into Eclipse, with a debug plug-in planned to handle everything automatically, in the same manner I handle J-Link and OpenOCD.

for the mid-term, I plan to use a systematic approach and try to define the Cortex-M/STM32F generic code, up to F4 (F7?), even if I'll probably leave many issues open, to be implemented in detail later.

if you want to join, you're more than welcome. 

---

as suggested by Peter, I'm currently reorganising my patches to make them less specifica, to be applied to the master branch (to be submitted soon).


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Alistair Francis]

On Thu, Nov 13, 2014 at 5:48 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 13 Nov 2014, at 02:11, Alistair Francis <alistair23@gmail.com> wrote:
>
>> I am trying to model the Netduino Plus 2 (STM32F4xx - Cortex-M4) board...
>> upstreamed to mainline by using the Netduino 2 board (STM32F2xx -
>> Cortex-M3).
>
> ok, great work!
>
> however, I'm more interested in a more systematic approach; before going into the devices of a specific board, I would like to know that (in order)
> - the core Cortex-M is properly supported, then
> - the specific Cortex-M0/0+/3/4/(7) are supported (system devices, debug registers, etc), then
> - the STM families STM32F[012347] are supported, then
> - specific devices like STM32F405/STM32F205/etc are supported (well, at a certain degree, at least run the CMSIS SysInit() init code), and then
> - implement board peripherals.
>
> can you confirm that your code properly runs the CMSIS SysInit() code, and that using SysTick in the application properly sets the timer frequency, based on the actual processor clock setting?

I haven't looked into CMSIS or using SysTick, so I can't confirm that
they work. I don't have any experience with using either, so I can't
really be of much help with those. Although they both look more like
CPU functionality rather then board/machine functionality, I have
focused on the board, SoC and peripherals, not on the CPU.

>
> in my GNU ARM Eclipse plug-ins I have C/C++ project templates for most STM processor families; the results are simple but fully functional Blinky projects, using SysTick for time reference and trace_printf() via semi-hosting or SVD; my first priority is to be able to run these projects on QEMU, and this requires, in addition to system peripherals, only a GPIO port, so it must be is relatively easy to implement.
>

I have implementations for the more important system peripherals in
the STM32F2xx/4xx SoC families, including GPIO. You are welcome to use
those if you want

>> All of my work can be seen at: https://github.com/alistair23/qemu.
>> Some of it is specific for my use case (it is aimed as a learning tool
>> for a University class) so if you need any help understanding what I
>> did just ask and I am happy to help.
>
> thank you, I appreciate it.
>
>> Support for the Cortex-M4 would
>> be great so I will help where I can.
>
> up to now I fixed the semihosting/gdb issues, and prepared a version that can be easily integrated into Eclipse, with a debug plug-in planned to handle everything automatically, in the same manner I handle J-Link and OpenOCD.
>
> for the mid-term, I plan to use a systematic approach and try to define the Cortex-M/STM32F generic code, up to F4 (F7?), even if I'll probably leave many issues open, to be implemented in detail later.
>
> if you want to join, you're more than welcome.
>

I'll keep an eye on your work and help where I can. As I mentioned
above my use case is more aimed at higher level machine/peripherals
support

> ---
>
> as suggested by Peter, I'm currently reorganising my patches to make them less specifica, to be applied to the master branch (to be submitted soon).
>

Sounds good

Thanks,

Alistair

>
> regards,
>
> Liviu
>

Re: [Qemu-devel] Better Cortex-M support?

[Liviu Ionescu]

On 14 Nov 2014, at 03:01, Alistair Francis <alistair23@gmail.com> wrote:

> I haven't looked into CMSIS or using SysTick, so I can't confirm that
> they work. I don't have any experience with using either, so I can't
> really be of much help with those.

when you'll have some time, perhaps it would be useful to install GNU ARM Eclipse and generate a project for your board, run it on the physical hardware, then test it on QEMU.

> I have implementations for the more important system peripherals in
> the STM32F2xx/4xx SoC families, including GPIO.

did you implement the clock related registers? PLL & others? these are used during CMSIS SystemInit() and are mandatory, otherwise emulation will either fail or not be realistic.

> You are welcome to use
> those if you want

thank you!

> above my use case is more aimed at higher level machine/peripherals
> support

yes, that's great, but without a proper base, like system registers and debug, usability may be not be as good as expected.


regards,

Liviu

Re: [Qemu-devel] Better Cortex-M support?

[Alistair Francis]

On Fri, Nov 14, 2014 at 5:32 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
> On 14 Nov 2014, at 03:01, Alistair Francis <alistair23@gmail.com> wrote:
>
>> I haven't looked into CMSIS or using SysTick, so I can't confirm that
>> they work. I don't have any experience with using either, so I can't
>> really be of much help with those.
>
> when you'll have some time, perhaps it would be useful to install GNU ARM Eclipse and generate a project for your board, run it on the physical hardware, then test it on QEMU.

Sorry about the long delay. I probably won't be able to do that for
some time, I have other other aspects for the project that are higher
priority. If I get a chance I will though

>
>> I have implementations for the more important system peripherals in
>> the STM32F2xx/4xx SoC families, including GPIO.
>
> did you implement the clock related registers? PLL & others? these are used during CMSIS SystemInit() and are mandatory, otherwise emulation will either fail or not be realistic.

Not specifically. I did implement a timer peripheral, but I assume
that isn't the same. I didn't have any issues with timing and
unrealistic emulation, but I'm not looking for exact time accurate
emulations

Thanks,

Alistair

>
>> You are welcome to use
>> those if you want
>
> thank you!
>
>> above my use case is more aimed at higher level machine/peripherals
>> support
>
> yes, that's great, but without a proper base, like system registers and debug, usability may be not be as good as expected.
>
>
> regards,
>
> Liviu
>
>