qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]