Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 12 November 2014 12:50, Liviu Ionescu <address@hidden> wrote:
>
> On 12 Nov 2014, at 01:08, Peter Maydell <address@hidden> wrote:
>
>> Cortex-M4 support would definitely be interesting.
>
> :-)
>
> any hints on what is missing for Cortex-M4 support? are all thumb
> instructions supported? the hard FP?

The instructions themselves are generally supported for
the A profile cores, so getting that part right would mostly
involve enabling those feature bits for the new M4 CPU class.
The difficult bits are going to involve:
 * correct trapping when fp is disabled
 * getting the exception handling right, including lazy
   exception frame population
 * bits where M profile FP differs from A profile (eg fp
   status and ID registers being memory mapped)

> sure, I'd be happy to contribute all my changes back.
>
> do you really need the git format-patch files sent via
> email? I thought that using a remote to my
> git://git.code.sf.net/p/gnuarmeclipse/qemu is easier.

It's easier for us on the receiving end to have patches sent
as email, because it means we can conveniently review them
in public on the mailing list. I'm afraid a lot of our
conventions for accepting patches are based around making
life easier for the maintainers doing the review, because
we're generally pretty heavily loaded with work. There's
a summary at http://wiki.qemu.org/Contribute/SubmitAPatch
of how it works.

> I tried to make my changes not affect the current arm-softmmu
> configuration, and for this I added a new target gnuarmeclipse-softmmu.

For upstream we would just want to fix arm-softmmu, I think.

> I also added 3 new configuration variables (branding_message="",
> semihosting_native="no", verbose="no") to control the features
> I added, and enable them only on the gnuarmeclipse target.
> these variables are passed to config-host.h and used to include my changes.

It sounds like you should separate out the things which are
bug fixes to upstream from the parts which are integration
with Eclipse. The former are going to be easier to get upstream
than the latter, so you can start with the easier parts first.

> some of my intermediate commits were changed in subsequent commits,
> so only the final result is relevant.

For submitting changes upstream you'll need to clean up
this set of commits (rebase, rearrange, split or merge commits,
etc so you have one commit (patch) per thing you're fixing and
it's a clean change that stands on its own.

thanks
-- PMM