* [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.