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: Alistair Francis
Subject: Re: [Qemu-devel] Better Cortex-M support?
Date: Fri, 14 Nov 2014 11:01:13 +1000

On Thu, Nov 13, 2014 at 5:48 PM, Liviu Ionescu <address@hidden> wrote:
>
> 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?

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. Although they both look more like
CPU functionality rather then board/machine functionality, I have
focused on the board, SoC and peripherals, not on the CPU.

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

I have implementations for the more important system peripherals in
the STM32F2xx/4xx SoC families, including GPIO. You are welcome to use
those if you want

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

I'll keep an eye on your work and help where I can. As I mentioned
above my use case is more aimed at higher level machine/peripherals
support

> ---
>
> 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).
>

Sounds good

Thanks,

Alistair

>
> regards,
>
> Liviu
>



reply via email to

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