All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-arm] QEMU user mode for cortex M
@ 2019-03-14 21:46 Massimiliano Cialdi
  2019-03-15 10:04 ` Peter Maydell
  0 siblings, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2019-03-14 21:46 UTC (permalink / raw)
  To: qemu-arm

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

hello,
I would like to try some algorithms on cortex M (especially cortex M4). I
don't need to emulate the whole machine, I just need the user mode.
To test the feasibility, I wrote the trivial "hello world".

I can compile it with arm-none-eabi-gcc, but the newlib associated with it
does not implement any syscall.
So I tried, on ubuntu, with the cross compiler arm-linux-gnueabihf-gcc and
its libc6, but the latter is only distributed for cortex A.

What do you suggest? Should I recompile the libc6 for cortex M (or do I
find it pre-compiled)? Should I implement (and how?) syscalls on newlib?

In summary, I would need a step-by-step guide to running Cortex M code on
QEMU arm user mode.

best regards
Max

-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cialdi@gmail.com

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-14 21:46 [Qemu-arm] QEMU user mode for cortex M Massimiliano Cialdi
@ 2019-03-15 10:04 ` Peter Maydell
  2019-03-15 10:56   ` Alex Bennée
  2019-03-15 22:12   ` Massimiliano Cialdi
  0 siblings, 2 replies; 8+ messages in thread
From: Peter Maydell @ 2019-03-15 10:04 UTC (permalink / raw)
  To: Massimiliano Cialdi; +Cc: qemu-arm

On Thu, 14 Mar 2019 at 22:30, Massimiliano Cialdi <cialdi@gmail.com> wrote:
>
> hello,
> I would like to try some algorithms on cortex M (especially cortex M4). I don't need to emulate the whole machine, I just need the user mode.
> To test the feasibility, I wrote the trivial "hello world".
>
> I can compile it with arm-none-eabi-gcc, but the newlib associated with it does not implement any syscall.
> So I tried, on ubuntu, with the cross compiler arm-linux-gnueabihf-gcc and its libc6, but the latter is only distributed for cortex A.
>
> What do you suggest? Should I recompile the libc6 for cortex M (or do I find it pre-compiled)? Should I implement (and how?) syscalls on newlib?
>
> In summary, I would need a step-by-step guide to running Cortex M code on QEMU arm user mode.

User-mode in Cortex-M is a weird thing to do, because what QEMU
gives you is the A-profile Linux syscalls. It's a hybrid that
we only continue to provide because it happens to be used and
useful to the gcc folks doing compiler testing. I would
recommend against using it, personally.

System emulation mode will get you something that actually
works the way the real hardware does. You can then do
output either via the UART or via semihosting (you need to
enable the latter on the commandline).

thanks
-- PMM

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-15 10:04 ` Peter Maydell
@ 2019-03-15 10:56   ` Alex Bennée
  2019-03-15 22:12   ` Massimiliano Cialdi
  1 sibling, 0 replies; 8+ messages in thread
From: Alex Bennée @ 2019-03-15 10:56 UTC (permalink / raw)
  To: qemu-arm; +Cc: Massimiliano Cialdi


Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 14 Mar 2019 at 22:30, Massimiliano Cialdi <cialdi@gmail.com> wrote:
>>
>> hello,
>> I would like to try some algorithms on cortex M (especially cortex M4). I don't need to emulate the whole machine, I just need the user mode.
>> To test the feasibility, I wrote the trivial "hello world".
>>
>> I can compile it with arm-none-eabi-gcc, but the newlib associated with it does not implement any syscall.
>> So I tried, on ubuntu, with the cross compiler arm-linux-gnueabihf-gcc and its libc6, but the latter is only distributed for cortex A.
>>
>> What do you suggest? Should I recompile the libc6 for cortex M (or do I find it pre-compiled)? Should I implement (and how?) syscalls on newlib?
>>
>> In summary, I would need a step-by-step guide to running Cortex M code on QEMU arm user mode.
>
> User-mode in Cortex-M is a weird thing to do, because what QEMU
> gives you is the A-profile Linux syscalls.
<snip>
> System emulation mode will get you something that actually
> works the way the real hardware does. You can then do
> output either via the UART or via semihosting (you need to
> enable the latter on the commandline).

We've recently added the ability to compile system-mode tests although
we currently only have one test for Cortex-M0 (see
tests/tcg/test-armv6m-undef.s). However if you could write a boot.S for
cortex-m4 with a semihosting __sys_outc and link it with
tests/tcg/minilib then you have a reasonable test harness for building C
binaries (albeit without a proper libc) you can run with the system
emulator.

--
Alex Bennée

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-15 10:04 ` Peter Maydell
  2019-03-15 10:56   ` Alex Bennée
@ 2019-03-15 22:12   ` Massimiliano Cialdi
  2019-03-16 12:01     ` Alex Bennée
  1 sibling, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2019-03-15 22:12 UTC (permalink / raw)
  To: Peter Maydell; +Cc: qemu-arm

[-- Attachment #1: Type: text/plain, Size: 4246 bytes --]

I have tried to follow some websites, such as, for example,
https://gnu-mcu-eclipse.github.io/qemu/options/,
http://sushihangover.github.io/arm-cortex-m-semihosting-with-qemu/ or
https://balau82.wordpress.com/2010/11/04/qemu-arm-semihosting/ without
success

I have my exetutable compiled with
/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -std=gnu11
-mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -fno-common
-specs=rdimon.specs -Wl,--cref,-Map=main.map main.c -o main.elf

then I try to execute qemu:
~/Downloads/qemu/qemu-3.1.0/arm-softmmu/qemu-system-arm -d
unimp,guest_errors -machine virt -monitor null -serial null  -semihosting
-nographic -semihosting-config enable=on,target=native -kernel main.elf
pflash_write: Unimplemented flash cmd sequence (offset 0000000003fffffc,
wcycle 0x0 cmd 0x0 value 0x80f7)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffcc,
wcycle 0x0 cmd 0x0 value 0xa984)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffd4,
wcycle 0x0 cmd 0x0 value 0x3)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffbc,
wcycle 0x0 cmd 0x0 value 0x1b368)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffc0,
wcycle 0x0 cmd 0x0 value 0x1b304)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffc4,
wcycle 0x0 cmd 0x0 value 0xa6cb)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001b304,
wcycle 0x0 cmd 0x0 value 0x1)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffff94,
wcycle 0x0 cmd 0x0 value 0x1b304)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffa4,
wcycle 0x0 cmd 0x0 value 0xa984)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffffac,
wcycle 0x0 cmd 0x0 value 0xa617)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffff6c,
wcycle 0x0 cmd 0x0 value 0x1b304)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffff74,
wcycle 0x0 cmd 0x0 value 0x1)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffff78,
wcycle 0x0 cmd 0x0 value 0x7ffffb4)
pflash_write: Unimplemented flash cmd sequence (offset 0000000003ffff84,
wcycle 0x0 cmd 0x0 value 0xa545)
pflash_write: Unimplemented flash cmd sequence (offset 000000000001aac0,
wcycle 0x0 cmd 0x0 value 0x18)
write access to unsupported AArch32 64 bit system register cp:12 opc1: 15
crm:8 (non-secure)


and nothing happend. Where am I wrong? I'm wrong at the compilation stage,
at the execution stage or both? Is there something wrong with the command
line parameters? Which one? How do I force a cortex-m4? How can I force the
Cpu without having to choose any machine?

best regards
Max

On Fri, Mar 15, 2019 at 11:05 AM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 14 Mar 2019 at 22:30, Massimiliano Cialdi <cialdi@gmail.com>
> wrote:
> >
> > hello,
> > I would like to try some algorithms on cortex M (especially cortex M4).
> I don't need to emulate the whole machine, I just need the user mode.
> > To test the feasibility, I wrote the trivial "hello world".
> >
> > I can compile it with arm-none-eabi-gcc, but the newlib associated with
> it does not implement any syscall.
> > So I tried, on ubuntu, with the cross compiler arm-linux-gnueabihf-gcc
> and its libc6, but the latter is only distributed for cortex A.
> >
> > What do you suggest? Should I recompile the libc6 for cortex M (or do I
> find it pre-compiled)? Should I implement (and how?) syscalls on newlib?
> >
> > In summary, I would need a step-by-step guide to running Cortex M code
> on QEMU arm user mode.
>
> User-mode in Cortex-M is a weird thing to do, because what QEMU
> gives you is the A-profile Linux syscalls. It's a hybrid that
> we only continue to provide because it happens to be used and
> useful to the gcc folks doing compiler testing. I would
> recommend against using it, personally.
>
> System emulation mode will get you something that actually
> works the way the real hardware does. You can then do
> output either via the UART or via semihosting (you need to
> enable the latter on the commandline).
>
> thanks
> -- PMM
>


-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cialdi@gmail.com

[-- Attachment #2: Type: text/html, Size: 5536 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-15 22:12   ` Massimiliano Cialdi
@ 2019-03-16 12:01     ` Alex Bennée
  2019-03-16 14:06       ` Peter Maydell
  2019-03-16 20:34       ` Massimiliano Cialdi
  0 siblings, 2 replies; 8+ messages in thread
From: Alex Bennée @ 2019-03-16 12:01 UTC (permalink / raw)
  To: qemu-arm; +Cc: Peter Maydell


Massimiliano Cialdi <cialdi@gmail.com> writes:

> I have tried to follow some websites, such as, for example,
> https://gnu-mcu-eclipse.github.io/qemu/options/,
> http://sushihangover.github.io/arm-cortex-m-semihosting-with-qemu/ or
> https://balau82.wordpress.com/2010/11/04/qemu-arm-semihosting/ without
> success
>
> I have my exetutable compiled with
> /opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -std=gnu11
> -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -fno-common
> -specs=rdimon.specs -Wl,--cref,-Map=main.map main.c -o main.elf

I thought you wanted to target a cortex-m4?

Have a look at how test-armv6m-undef is built. It is the simplest
dumbest M profile image you can build with a kernel that maps to 0 and a
simple reset vector at the start of the vector table:

>
> then I try to execute qemu:
> ~/Downloads/qemu/qemu-3.1.0/arm-softmmu/qemu-system-arm -d
> unimp,guest_errors -machine virt -monitor null -serial null  -semihosting
> -nographic -semihosting-config enable=on,target=native -kernel
> main.elf

I don't know what the virt machine defaults to for CPU but I'm fairly
sure it's not an m-profile CPU.
> write access to unsupported AArch32 64 bit system register cp:12 opc1: 15
> crm:8 (non-secure)
>
>
> and nothing happend. Where am I wrong? I'm wrong at the compilation stage,
> at the execution stage or both? Is there something wrong with the command
> line parameters? Which one? How do I force a cortex-m4? How can I force the
> Cpu without having to choose any machine?

It's hard to say without seeing what your test is doing. However I can force
a cortex-m4 on a microbit and run the following ok:

  ./qemu-system-arm  -monitor none -display none \
                     -chardev file,path=test-armv6m-undef.out,id=output \
                     -semihosting -M microbit \
                     -cpu cortex-m4 \
                     -kernel tests/test-armv6m-undef
                     -d in_asm,cpu,nochain


>
> best regards
> Max
>
> On Fri, Mar 15, 2019 at 11:05 AM Peter Maydell <peter.maydell@linaro.org>
> wrote:
>
>> On Thu, 14 Mar 2019 at 22:30, Massimiliano Cialdi <cialdi@gmail.com>
>> wrote:
>> >
>> > hello,
>> > I would like to try some algorithms on cortex M (especially cortex M4).
>> I don't need to emulate the whole machine, I just need the user mode.
>> > To test the feasibility, I wrote the trivial "hello world".
>> >
>> > I can compile it with arm-none-eabi-gcc, but the newlib associated with
>> it does not implement any syscall.
>> > So I tried, on ubuntu, with the cross compiler arm-linux-gnueabihf-gcc
>> and its libc6, but the latter is only distributed for cortex A.
>> >
>> > What do you suggest? Should I recompile the libc6 for cortex M (or do I
>> find it pre-compiled)? Should I implement (and how?) syscalls on newlib?
>> >
>> > In summary, I would need a step-by-step guide to running Cortex M code
>> on QEMU arm user mode.
>>
>> User-mode in Cortex-M is a weird thing to do, because what QEMU
>> gives you is the A-profile Linux syscalls. It's a hybrid that
>> we only continue to provide because it happens to be used and
>> useful to the gcc folks doing compiler testing. I would
>> recommend against using it, personally.
>>
>> System emulation mode will get you something that actually
>> works the way the real hardware does. You can then do
>> output either via the UART or via semihosting (you need to
>> enable the latter on the commandline).
>>
>> thanks
>> -- PMM
>>


--
Alex Bennée

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-16 12:01     ` Alex Bennée
@ 2019-03-16 14:06       ` Peter Maydell
  2019-03-16 20:34       ` Massimiliano Cialdi
  1 sibling, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2019-03-16 14:06 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-arm

On Sat, 16 Mar 2019 at 12:01, Alex Bennée <alex.bennee@linaro.org> wrote:
> Massimiliano Cialdi <cialdi@gmail.com> writes:
> > then I try to execute qemu:
> > ~/Downloads/qemu/qemu-3.1.0/arm-softmmu/qemu-system-arm -d
> > unimp,guest_errors -machine virt -monitor null -serial null  -semihosting
> > -nographic -semihosting-config enable=on,target=native -kernel
> > main.elf
>
> I don't know what the virt machine defaults to for CPU but I'm fairly
> sure it's not an m-profile CPU.

Default is Cortex-A15. "virt" cannot handle M-profile CPUs.

> > write access to unsupported AArch32 64 bit system register cp:12 opc1: 15
> > crm:8 (non-secure)
> >
> >
> > and nothing happend. Where am I wrong? I'm wrong at the compilation stage,
> > at the execution stage or both? Is there something wrong with the command
> > line parameters? Which one? How do I force a cortex-m4? How can I force the
> > Cpu without having to choose any machine?
>
> It's hard to say without seeing what your test is doing. However I can force
> a cortex-m4 on a microbit and run the following ok:
>
>   ./qemu-system-arm  -monitor none -display none \
>                      -chardev file,path=test-armv6m-undef.out,id=output \
>                      -semihosting -M microbit \
>                      -cpu cortex-m4 \
>                      -kernel tests/test-armv6m-undef
>                      -d in_asm,cpu,nochain

This is also kind of dubious, because the microbit is
really a Cortex-M0 v6M system. In fact I think it
is just ignoring the -cpu argument and giving you the M0
anyway.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-16 12:01     ` Alex Bennée
  2019-03-16 14:06       ` Peter Maydell
@ 2019-03-16 20:34       ` Massimiliano Cialdi
  2019-03-17 11:10         ` Massimiliano Cialdi
  1 sibling, 1 reply; 8+ messages in thread
From: Massimiliano Cialdi @ 2019-03-16 20:34 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-arm

[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]

On Sat, Mar 16, 2019 at 1:01 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Massimiliano Cialdi <cialdi@gmail.com> writes:
>
> > I have my exetutable compiled with
> > /opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -std=gnu11
> > -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -fno-common
> > -specs=rdimon.specs -Wl,--cref,-Map=main.map main.c -o main.elf
>
> I thought you wanted to target a cortex-m4?
yes.
I tried to compile it like this.:
/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc
-std=gnu11 -mcpu=cortex-m4 -mthumb  -fno-common -specs=rdimon.specs
-Wl,--cref,-Map=main.map -T prova.ld -O0 -g3 main.c -o main.elf
The linker script is attached

I don't know how to compile with arm-linux-gnueabihf-gcc

>
> Have a look at how test-armv6m-undef is built. It is the simplest
> dumbest M profile image you can build with a kernel that maps to 0 and a
> simple reset vector at the start of the vector table:
I don't want to have to deal with interrupt vectors and memory layouts.
Just see "hallo world!" on the output.



> I don't know what the virt machine defaults to for CPU but I'm fairly
> sure it's not an m-profile CPU.
I had only tried the machine none and virt... I didn't know which one
to choose for cortex M4


> It's hard to say without seeing what your test is doing. However I can force
> a cortex-m4 on a microbit and run the following ok:
>
>   ./qemu-system-arm  -monitor none -display none \
>                      -chardev file,path=test-armv6m-undef.out,id=output \
>                      -semihosting -M microbit \
>                      -cpu cortex-m4 \
>                      -kernel tests/test-armv6m-undef
>                      -d in_asm,cpu,nochain

tried with:
~/Downloads/qemu/qemu-3.1.0/arm-softmmu/qemu-system-arm -d
in_asm,cpu,nochain,unimp,guest_errors -chardev
file,path=prova.out,id=output -machine microbit -cpu cortex-m4
-monitor null -serial null  -semihosting -nographic
-semihosting-config enable=on,target=native  -kernel main.elf
----------------
IN:
0x00000000:  00000000  andeq    r0, r0, r0

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=ffffffff R15=00000000
XPSR=40000000 -Z-- A priv-thread
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xfffffe0)
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xfffffe4)
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xfffffe8)
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xfffffec)
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xffffff0)
nrf51_soc.private: unimplemented device write (size 4, value
0xffffffff, offset 0xffffff4)
nrf51_soc.private: unimplemented device write (size 4, value 0x0,
offset 0xffffff8)
nrf51_soc.private: unimplemented device write (size 4, value
0x40000000, offset 0xffffffc)
----------------
IN:
0x00000000:  00000000  andeq    r0, r0, r0

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
XPSR=40000003 -Z-- A handler
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
XPSR=40000003 -Z-- A handler
FPSCR: 00000000
Aborted (core dumped)


still no success

best regards
Max


--
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cialdi@gmail.com

[-- Attachment #2: prova.ld --]
[-- Type: application/octet-stream, Size: 9079 bytes --]

/* Script for -z combreloc: combine and sort reloc sections */
/* Copyright (C) 2014-2018 Free Software Foundation, Inc.
   Copying and distribution of this script, with or without modification,
   are permitted in any medium without royalty provided the copyright
   notice and this notice are preserved.  */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
	      "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x10100)); . = SEGMENT_START("text-segment", 0x10100);
  .interp         : { *(.interp) }
  .note.gnu.build-id  : { *(.note.gnu.build-id) }
  .hash           : { *(.hash) }
  .gnu.hash       : { *(.gnu.hash) }
  .dynsym         : { *(.dynsym) }
  .dynstr         : { *(.dynstr) }
  .gnu.version    : { *(.gnu.version) }
  .gnu.version_d  : { *(.gnu.version_d) }
  .gnu.version_r  : { *(.gnu.version_r) }
  .rel.dyn        :
    {
      *(.rel.init)
      *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
      *(.rel.fini)
      *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
      *(.rel.data.rel.ro .rel.data.rel.ro.* .rel.gnu.linkonce.d.rel.ro.*)
      *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
      *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
      *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
      *(.rel.ctors)
      *(.rel.dtors)
      *(.rel.got)
      *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
      PROVIDE_HIDDEN (__rel_iplt_start = .);
      *(.rel.iplt)
      PROVIDE_HIDDEN (__rel_iplt_end = .);
    }
  .rela.dyn       :
    {
      *(.rela.init)
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.fini)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
      *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
      *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
      *(.rela.ctors)
      *(.rela.dtors)
      *(.rela.got)
      *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
      PROVIDE_HIDDEN (__rela_iplt_start = .);
      *(.rela.iplt)
      PROVIDE_HIDDEN (__rela_iplt_end = .);
    }
  .rel.plt        :
    {
      *(.rel.plt)
    }
  .rela.plt       :
    {
      *(.rela.plt)
    }
  .init           :
  {
    KEEP (*(SORT_NONE(.init)))
  }
  .plt            : { *(.plt) }
  .iplt           : { *(.iplt) }
  .text           :
  {
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)
    *(.text.exit .text.exit.*)
    *(.text.startup .text.startup.*)
    *(.text.hot .text.hot.*)
    *(.text .stub .text.* .gnu.linkonce.t.*)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx)
  }
  .fini           :
  {
    KEEP (*(SORT_NONE(.fini)))
  }
  PROVIDE (__etext = .);
  PROVIDE (_etext = .);
  PROVIDE (etext = .);
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
  .rodata1        : { *(.rodata1) }
  .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
   PROVIDE_HIDDEN (__exidx_start = .);
  .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
   PROVIDE_HIDDEN (__exidx_end = .);
  .eh_frame_hdr   : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) }
  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) }
  .gcc_except_table   : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
  .gnu_extab   : ONLY_IF_RO { *(.gnu_extab*) }
  /* These sections are generated by the Sun/Oracle C++ compiler.  */
  .exception_ranges   : ONLY_IF_RO { *(.exception_ranges*) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  . = ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1));
  /* Exception handling  */
  .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) *(.eh_frame.*) }
  .gnu_extab      : ONLY_IF_RW { *(.gnu_extab) }
  .gcc_except_table   : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
  .exception_ranges   : ONLY_IF_RW { *(.exception_ranges*) }
  /* Thread Local Storage sections  */
  .tdata	  :
   {
     PROVIDE_HIDDEN (__tdata_start = .);
     *(.tdata .tdata.* .gnu.linkonce.td.*)
   }
  .tbss		  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
  .preinit_array    :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  }
  .init_array    :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
    KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
    PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array    :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
    KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
    PROVIDE_HIDDEN (__fini_array_end = .);
  }
  .ctors          :
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*crtbegin?.o(.ctors))
    /* We don't want to include the .ctor section from
       the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }
  .dtors          :
  {
    KEEP (*crtbegin.o(.dtors))
    KEEP (*crtbegin?.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  .jcr            : { KEEP (*(.jcr)) }
  .data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }
  .dynamic        : { *(.dynamic) }
  .got            : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }
  .data           :
  {
    __data_start = .;
    *(.data .data.* .gnu.linkonce.d.*)
    SORT(CONSTRUCTORS)
  }
  .data1          : { *(.data1) }
  _edata = .; PROVIDE (edata = .);
  . = .;
  __bss_start = .;
  __bss_start__ = .;
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.
      FIXME: Why do we need it? When there is no .bss section, we do not
      pad the .data section.  */
   . = ALIGN(. != 0 ? 32 / 8 : 1);
  }
  _bss_end__ = .; __bss_end__ = .;
  . = ALIGN(32 / 8);
  . = SEGMENT_START("ldata-segment", .);
  . = ALIGN(32 / 8);
  __end__ = .;
  _end = .; PROVIDE (end = .);
  .stack         0x80000 :
  {
    _stack = .;
    *(.stack)
  }
  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  .gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* DWARF 3 */
  .debug_pubtypes 0 : { *(.debug_pubtypes) }
  .debug_ranges   0 : { *(.debug_ranges) }
  /* DWARF Extension.  */
  .debug_macro    0 : { *(.debug_macro) }
  .debug_addr     0 : { *(.debug_addr) }
  .ARM.attributes 0 : { KEEP (*(.ARM.attributes)) KEEP (*(.gnu.attributes)) }
  .note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }
  /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
}

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Qemu-arm] QEMU user mode for cortex M
  2019-03-16 20:34       ` Massimiliano Cialdi
@ 2019-03-17 11:10         ` Massimiliano Cialdi
  0 siblings, 0 replies; 8+ messages in thread
From: Massimiliano Cialdi @ 2019-03-17 11:10 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-arm

I did it.

File main.c:

--------8<------------------------
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    printf("Hallo ARM world!\n");
    exit(0);
}
--------8<------------------------

compiled with:
/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc
-std=gnu11 -mcpu=cortex-m4 -mthumb  -fno-common -specs=rdimon.specs
-Wl,--cref,-Map=main.map  -O0 -g3 main.c -o main.elf

I run it with qemu user mode, and it works:
~/Downloads/qemu/qemu-3.1.0/arm-linux-user/qemu-arm -D prova.out -d
in_asm,cpu,nochain,unimp,guest_errors -cpu cortex-m4 main.elf
Hallo ARM world!


probably works by accident, but I have achieved my goal. Any comment?

best regards
Max


On Sat, Mar 16, 2019 at 9:34 PM Massimiliano Cialdi <cialdi@gmail.com> wrote:
>
> On Sat, Mar 16, 2019 at 1:01 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> >
> > Massimiliano Cialdi <cialdi@gmail.com> writes:
> >
> > > I have my exetutable compiled with
> > > /opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -std=gnu11
> > > -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -fno-common
> > > -specs=rdimon.specs -Wl,--cref,-Map=main.map main.c -o main.elf
> >
> > I thought you wanted to target a cortex-m4?
> yes.
> I tried to compile it like this.:
> /opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc
> -std=gnu11 -mcpu=cortex-m4 -mthumb  -fno-common -specs=rdimon.specs
> -Wl,--cref,-Map=main.map -T prova.ld -O0 -g3 main.c -o main.elf
> The linker script is attached
>
> I don't know how to compile with arm-linux-gnueabihf-gcc
>
> >
> > Have a look at how test-armv6m-undef is built. It is the simplest
> > dumbest M profile image you can build with a kernel that maps to 0 and a
> > simple reset vector at the start of the vector table:
> I don't want to have to deal with interrupt vectors and memory layouts.
> Just see "hallo world!" on the output.
>
>
>
> > I don't know what the virt machine defaults to for CPU but I'm fairly
> > sure it's not an m-profile CPU.
> I had only tried the machine none and virt... I didn't know which one
> to choose for cortex M4
>
>
> > It's hard to say without seeing what your test is doing. However I can force
> > a cortex-m4 on a microbit and run the following ok:
> >
> >   ./qemu-system-arm  -monitor none -display none \
> >                      -chardev file,path=test-armv6m-undef.out,id=output \
> >                      -semihosting -M microbit \
> >                      -cpu cortex-m4 \
> >                      -kernel tests/test-armv6m-undef
> >                      -d in_asm,cpu,nochain
>
> tried with:
> ~/Downloads/qemu/qemu-3.1.0/arm-softmmu/qemu-system-arm -d
> in_asm,cpu,nochain,unimp,guest_errors -chardev
> file,path=prova.out,id=output -machine microbit -cpu cortex-m4
> -monitor null -serial null  -semihosting -nographic
> -semihosting-config enable=on,target=native  -kernel main.elf
> ----------------
> IN:
> 0x00000000:  00000000  andeq    r0, r0, r0
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=00000000 R14=ffffffff R15=00000000
> XPSR=40000000 -Z-- A priv-thread
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xfffffe0)
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xfffffe4)
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xfffffe8)
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xfffffec)
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xffffff0)
> nrf51_soc.private: unimplemented device write (size 4, value
> 0xffffffff, offset 0xffffff4)
> nrf51_soc.private: unimplemented device write (size 4, value 0x0,
> offset 0xffffff8)
> nrf51_soc.private: unimplemented device write (size 4, value
> 0x40000000, offset 0xffffffc)
> ----------------
> IN:
> 0x00000000:  00000000  andeq    r0, r0, r0
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> XPSR=40000003 -Z-- A handler
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> XPSR=40000003 -Z-- A handler
> FPSCR: 00000000
> Aborted (core dumped)
>
>
> still no success
>
> best regards
> Max
>
>
> --
> Et nunc, auxilium solis, vincam!
> Oppugnatio solaris!
> VIS!
>
> Massimiliano Cialdi
> cialdi@gmail.com



-- 
Et nunc, auxilium solis, vincam!
Oppugnatio solaris!
VIS!

Massimiliano Cialdi
cialdi@gmail.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-03-17 11:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-14 21:46 [Qemu-arm] QEMU user mode for cortex M Massimiliano Cialdi
2019-03-15 10:04 ` Peter Maydell
2019-03-15 10:56   ` Alex Bennée
2019-03-15 22:12   ` Massimiliano Cialdi
2019-03-16 12:01     ` Alex Bennée
2019-03-16 14:06       ` Peter Maydell
2019-03-16 20:34       ` Massimiliano Cialdi
2019-03-17 11:10         ` Massimiliano Cialdi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.