Re: [Qemu-devel] ARM Cortex-M issues

[Bill Paul <wpaul@windriver.com>]

Of all the gin joints in all the towns in all the world, Liviu Ionescu had to 
walk into mine at 12:19:42 on Monday 29 August 2016 and say:

> > On 29 Aug 2016, at 20:59, Bill Paul <wpaul@windriver.com> wrote:
> > 
> > I recently started tinkering with ChibiOS as part of a small personal
> > project ...
> 
> I did most of the development for the µOS++/CMSIS++
> (http://micro-os-plus.github.io) on STM32F4DISCOVERY board, emulated by
> GNU ARM Eclipse QEMU, which implements even animated LEDs on a graphical
> image of the board.
> 
> FreeRTOS also works properly on the emulator, both the M0 and M3 ports.
> 
> As for Cortex-M implementation, there are many improvements in the GNU ARM
> Eclipse QEMU fork (http://gnuarmeclipse.github.io/qemu/), including an
> Eclipse debug plug-in to start it; it may be worth giving it a try for
> ChibiOS too.

I think I've been down this road already with Xilinx ARM support. ("We have 
our own fork of QEMU For the MPSoC parts!" "It seems to have diverged a lot of 
from the mainline. Also you've only been testing the ARM builds and those only 
on Linux hosts, and now the code has bitrotted." "Yeah... but... we're going 
to submit our changes to upstream Real Soon Now (tm).")

Note that I'm not suggesting the ARM Eclipse code suffers from bitrot. I'll 
give it a try. I just wish all of this was in once place.

Also, from a cursory look at the code, it doesn't look like this fork handles 
the NMI interrupt any better than the mainline.

The Cortex-M model has an explicit NMI vector in its vector table (#2). It's 
possible to trigger this interrupt via software by writing a 1 to the 
NMIPENDSET bit in the ICSR register in the System Control Block (which seems 
to be a Cortex-M-specific thing).

Currently this vector is treated just like any other IRQ. The problem is that 
means it is also subject to the case where CPSR_I is masked off in the CPU, 
which for the NMI is wrong. (How can you mask that which is unmaskabkle?)

From looking at how things are structured, I think the only way to make it 
work is to give the target-arm/cpu.c code a separate external NMI pin (e.g. 
CPU_INTERRUPT_NMI) and make the arm_gic.c smart enough to trigger that pin 
instead of the IRQ or FIQ pins when the NMI is triggered. The handling for 
that pin could then be special-cased not to ignore the state of CPSR_I.

But that was just from a quick look last night while I was experimenting. I 
don't know if maybe there's a better way. This is why I'm here asking 
questions. :)

-Bill

> 
> Regards,
> 
> Liviu

-- 
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
                 wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================