qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bill Paul
Subject: Re: [Qemu-devel] ARM Cortex-M issues
Date: Mon, 29 Aug 2016 17:12:56 -0700
User-agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; x86_64; ; )

Of all the gin joints in all the towns in all the world, Peter Maydell had to 
walk into mine at 12:51:04 on Monday 29 August 2016 and say:

> On 29 August 2016 at 13:59, Bill Paul <address@hidden> wrote:
> > Unfortunately it's been a frustrating experience because there seem to be
> > several key places where QEMU's hardware emulation diverges from reality.
> > The ChibiOS examples often seem to depend on behavior that is valid for
> > actual hardware but which is either broken or just missing in QEMU. Some
> > of these issues are board-specific, but the last one seems a bit more
> > general.
> 
> Yes, our Cortex-M support is a bit undermaintained at the moment.
> If you'd like to write patches to fix some of the bugs you're
> encountering I'd be happy to review them, but I'm not aware of anybody
> actively working on M profile right now. We could really use a
> contributor who cares about it and has time to tackle improving it.
> (A-profile ARM emulation is in much better shape.)

I had a feeling you were going to say that. But I already fell for this trick 
once when I started using FreeBSD, and then I ended up being a developer for  
about 10 years. I'm older and wiser now. (Also I have a day job that consumes 
most of my time.)

The best I might be able to do is patch the STM32 SUART driver so that it 
supports the TX fifo empty interrupt. I'm really not sure how to fix the STM32 
timer driver (like I said, the ST Micro documentation is really hard to 
follow) and I'm not sure that any attempt to get the NMI to work would be any 
less of a hack then what's there now.

[...]
 
> The reason for this kind of thing is that the original support was
> done to support a specific RTOS, and so bugs which resulted in that
> RTOS not working were found and fixed. Bugs which weren't exercised
> by that RTOS remain lurking in the code, and if you try to use a
> different RTOS guest then you can run into them. (This is less
> obvious on the A profile cores because to a first approximation
> nobody runs anything but Linux on them, but in the embedded world
> there's still a fairly rich diversity of RTOSes which take different
> approaches to how they prod the hardware.)

In other words it's half-baked. :(

-Bill

> thanks
> -- PMM

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



reply via email to

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