> On 06 Apr 2016, at 15:02, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 5 April 2016 at 22:57, Liviu Ionescu <i...@livius.net> wrote: >> (I know that from time to time this question pops up, but) is >> there anyone working or planning to work on the M4 emulation? > > Not that I'm aware of; Michael Davidsaver had some patches for > improving the v7M interrupt/exception emulation,
I also have on my TODO list to implement the SCB registers used during exception processing (MMFAR, BFAR, CFSR); I checked and in version 2.5.1 apparently they are still not implemented. > but I don't > think I've seen anything for the FPU side of things. ok, actually I did not expect much :-( > .. I expect > that the actual instruction emulation should all be there. sounds better. > Lazy-restore will be the most complicated part. My initial > thoughts would be that you'd want to do it by treating > "lazy state preservation active" as similar to "fp disabled", > so it's a TB flag that causes an exception to be taken > (in this case a qemu internal one that we handle by doing > the necessary state-save and then resuming the instruction). I need to study the code more thoroughly to understand exactly what you mean. but before addressing the M4, I decided to restructure the rest of the Cortex-M system code, that now is all together in the NVIC object. 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. I'll use the Peripheral/Peripheral-Register/Register-Bitfield objects that I already use for the rest of the STM32 objects. these are table driven objects, that automatically handle storing/retrieving register data, shifting, masking, alignment, endianness, etc. in addition to the detailed tables (which in the future I plan to generate automatically from ARM CMSIS SVD files), the application needs only to add *_pre_read()/*_post_write() callbacks, to handle actions associated with registers/bitfields. the entire story is still quite complex, but at least it is very systematic, and should improve the emulation accuracy and reduce the risk of errors. once I have this again functional, I'll try to address the M4 configuration, and let you know if there is any progress. regards, Liviu
