On Fri, Nov 14, 2014 at 5:32 PM, Liviu Ionescu i...@livius.net wrote:
On 14 Nov 2014, at 03:01, Alistair Francis alistai...@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
On Thu, Nov 13, 2014 at 5:48 PM, Liviu Ionescu i...@livius.net wrote:
On 13 Nov 2014, at 02:11, Alistair Francis alistai...@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).
On 14 Nov 2014, at 03:01, Alistair Francis alistai...@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
On 12 November 2014 12:50, Liviu Ionescu i...@livius.net wrote:
On 12 Nov 2014, at 01:08, Peter Maydell peter.mayd...@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
On 12 Nov 2014, at 15:02, Peter Maydell peter.mayd...@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
On 12 November 2014 13:43, Liviu Ionescu i...@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
On 12 Nov 2014, at 15:51, Peter Maydell peter.mayd...@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.
On Thu, Nov 13, 2014 at 12:23 AM, Liviu Ionescu i...@livius.net wrote:
On 12 Nov 2014, at 15:51, Peter Maydell peter.mayd...@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
On 13 Nov 2014, at 02:11, Alistair Francis alistai...@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
On 28 Oct 2014, at 12:43, Liviu Ionescu i...@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
On 11 November 2014 21:56, Liviu Ionescu i...@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,
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
On Tue, Nov 4, 2014 at 10:05 PM, Fabien Chouteau chout...@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
On 28 Oct 2014, at 16:18, Peter Maydell peter.mayd...@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
On 28 Oct 2014, at 19:08, Peter Maydell peter.mayd...@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
On 29 October 2014 07:03, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 16:18, Peter Maydell peter.mayd...@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
On 29 Oct 2014, at 12:31, Peter Maydell peter.mayd...@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
On 10/28/2014 01:08 PM, Peter Maydell wrote:
On 28 October 2014 16:38, Liviu Ionescu i...@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
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 i...@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
On 29 October 2014 13:28, Christopher Covington c...@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
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
On 29 Oct 2014, at 17:11, Paolo Bonzini pbonz...@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
On 10/29/2014 04:18 PM, Liviu Ionescu wrote:
On 29 Oct 2014, at 17:11, Paolo Bonzini pbonz...@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
On 29 Oct 2014, at 17:31, Paolo Bonzini pbonz...@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
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
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
On 28 October 2014 10:43, Liviu Ionescu i...@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
On 28 Oct 2014, at 14:22, Peter Maydell peter.mayd...@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
On 28 October 2014 12:40, Liviu Ionescu i...@livius.net wrote:
as for the semihosting support, if I try to use it, I get:
qemu: Unsupported SemiHosting SWI 0x00
R00= R01= R02= R03=
R04= R05= R06= R07=200ffed8
R08= R09=
On 28 Oct 2014, at 14:45, Peter Maydell peter.mayd...@linaro.org wrote:
qemu: Unsupported SemiHosting SWI 0x00
R00= R01= R02= R03=
R04= R05= R06= R07=200ffed8
R08= R09= R10= R11=
R12=
On 28 October 2014 12:52, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 14:45, Peter Maydell peter.mayd...@linaro.org wrote:
qemu: Unsupported SemiHosting SWI 0x00
R00= R01= R02= R03=
R04= R05= R06= R07=200ffed8
R08=
On 28 Oct 2014, at 14:57, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 October 2014 12:52, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 14:45, Peter Maydell peter.mayd...@linaro.org wrote:
qemu: Unsupported SemiHosting SWI 0x00
R00= R01= R02=
On 28 October 2014 13:23, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 14:57, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 October 2014 12:52, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 14:45, Peter Maydell peter.mayd...@linaro.org wrote:
qemu: Unsupported
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
On 28 October 2014 13:54, Liviu Ionescu i...@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$
On 28 October 2014 14:37, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 16:18, Peter Maydell peter.mayd...@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
On 28 Oct 2014, at 16:40, Peter Maydell peter.mayd...@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
On 28 October 2014 14:50, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 16:40, Peter Maydell peter.mayd...@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
On 28 October 2014 14:59, Peter Maydell peter.mayd...@linaro.org wrote:
On 28 October 2014 14:50, Liviu Ionescu i...@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
On 28 Oct 2014, at 17:03, Peter Maydell peter.mayd...@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
On 28 October 2014 15:22, Liviu Ionescu i...@livius.net wrote:
On 28 Oct 2014, at 17:03, Peter Maydell peter.mayd...@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
On 28 Oct 2014, at 17:38, Peter Maydell peter.mayd...@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
On 28 October 2014 16:38, Liviu Ionescu i...@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
43 matches
Mail list logo
