[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Better Cortex-M support?
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-devel] Better Cortex-M support? |
Date: |
Thu, 13 Nov 2014 09:48:27 +0200 |
On 13 Nov 2014, at 02:11, Alistair Francis <address@hidden> 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?, Fabien Chouteau, 2014/11/04
- Re: [Qemu-devel] Better Cortex-M support?, Liviu Ionescu, 2014/11/11
- Re: [Qemu-devel] Better Cortex-M support?, Peter Maydell, 2014/11/11
- Re: [Qemu-devel] Better Cortex-M support?, Liviu Ionescu, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?, Peter Maydell, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?, Liviu Ionescu, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?, Peter Maydell, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?, Liviu Ionescu, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?, Alistair Francis, 2014/11/12
- Re: [Qemu-devel] Better Cortex-M support?,
Liviu Ionescu <=
- Re: [Qemu-devel] Better Cortex-M support?, Alistair Francis, 2014/11/13
- Re: [Qemu-devel] Better Cortex-M support?, Liviu Ionescu, 2014/11/14
- Re: [Qemu-devel] Better Cortex-M support?, Alistair Francis, 2014/11/30