On 12 November 2014 12:50, Liviu Ionescu <i...@livius.net> wrote: > > On 12 Nov 2014, at 01:08, Peter Maydell <peter.mayd...@linaro.org> 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
