On Sat, 13 Aug 2022 at 18:54, Shiny Saana <shinysa...@gmail.com> wrote: > I'd like to implement support for emulating the teensy 4.1 board ( > https://www.pjrc.com/store/teensy41.html) to QEMU. > > I'm honestly quite lost as to where to start at the moment, since > I can't really find any emulated Cortex-M7 that would be close to > that board already implemented.
Hi! Yes, implementing a new board and SoC model is quite a bit of work, and unfortunately the process isn't really documented, so the best thing is to look for some other existing SoC model and do something similar. In this case, we implement the Cortex-M7 CPU itself, but we don't implement the IMXRT1062 SoC that it uses, or any similar SoC in that family. (We do have some of the older A-profile IMX boards, so it's possible some device models are reusable -- but equally they might be very different.) As a pattern, I would look at the stm32vldiscovery machine. This is a Cortex-M3 system based on the stm32f100 SoC, where we have implemented a few of the SoC devices and have stub implementations of most of the rest. That's a fairly recently added M-profile SoC and it's written in the "modern" style we'd recommend for new code, so it's a good pattern to copy, and because it only has a few 'real' devices it's hopefully not an overwhelmingly large amount of code. An initial simple implementation would get a level of functionality capable of basic "can run code and it will be able to do serial port (UART) input and output". (If you're hoping for/would need more than that, do say so, so we can check how much effort what you're aiming for would be. Some things QEMU doesn't really support very well, like emulation of GPIO input/output line hardware lines being connected to LEDs and switches... In any case "just a UART" is a good first step.) You'll need detailed documentation of both the board and the SoC. Handily a lot of that is collected here: https://www.pjrc.com/teensy/datasheets.html If you're hoping to submit a new board model upstream you should give some consideration to git commit structure as you work on it -- for code review we need big changes like a new board type to be broken up into smaller self-contained pieces. It is possible to just write all the code first and then split it into digestible pieces later, but personally I find it much easier to try to keep the changes at least roughly in a series of separate patches as I go along. Our "submitting a patch" page has some general advice and information on our patch processes: https://www.qemu.org/docs/master/devel/submitting-a-patch.html thanks -- PMM
