[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] Any progress with the Cortex-M4 emulation?
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-arm] Any progress with the Cortex-M4 emulation? |
Date: |
Thu, 7 Apr 2016 10:04:39 +0300 |
> On 07 Apr 2016, at 03:46, Michael Davidsaver <address@hidden> wrote:
>
> ... don't hesitate to appropriate, or ignore, what I've done so far. ...
> https://github.com/mdavidsaver/qemu/tree/fixirq2
from what I see here, the nvic is still one big monolithic device.
as I said before, I like modular things, and, even if this might be a little
slower, I'd split nvic:
"the current plan is to create a new object (probably called SCS - System
Control Space), that will cover the 0xE000E000-0xE000EFFF area and inside it to
map SysTick, NVIC, SCB, MPU, Debug and FPU as separate objects."
another difference is that I have a very elaborated infrastructure to manage
registers, and I'd like to use it for the system registers too.
fyi, a simple device is:
https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/gpio/stm32-gpio.c
a more complicated device (in terms of tables, otherwise the additional actions
are minimal) is the
https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/misc/stm32-rcc.c
this table-driven way of implementing peripherals is specific to GNU ARM
Eclipse QEMU and I plan to further improve it, with an automated tool to
generate the tables.
Peter expressed concerns that this infrastructure will clash very badly with
your work. actually it shouldn't, because it is completely separated, there are
3 objects (Peripheral/Peripheral-Register/Register-Bitfield).
in general none of the changes I did in GNU ARM Eclipse clash with existing
code, because I use separate objects, from separate "cortex-m*" mcus, to
separate peripherals and separate boards.
unfortunately nobody else expressed any interest in this new infrastructure, so
it is available only in GNU ARM Eclipse QEMU.
> Separately, I have a set of target test programs which I can run both with
> qemu and a real board. They mostly agree. Aside from test8.c (MPU) they
> might be of interest.
>
> https://github.com/mdavidsaver/baremetal/tree/qemutest
ok, good to know.
however projects generated by GNU ARM Eclipse use a distinct trace
infrastructure, I'll probably create a separate test inspired by your code.
regards,
Liviu