Thank you very much for your answer! Apologies if I mess up the process of communicating via mailing lists, it's my first time communicating via this channel.
The project that requires me to implement this board in QEMU currently would require full USB interface and flash storage at the end of the day, and I feel on the same page that implementing UART via USB would indeed be a good place to start. I personally don't need any of the GPIO interfaces, but if needed by someone else, that could be a good second step to work on once that part of the board is implemented. I have jotted down a few lines based on the MPS2 implementation, which made me get a feel of how a board is implemented. I'll look at the board you recommended too, thanks a lot for the recommendation! As for upstreaming, once (if?) I get a working "MVP", and if I cannot figure out the best way to submit the patches, I'll keep in touch to figure it out, if that's alright! Again, thanks a bunch! //Saana Le lun. 15 août 2022 à 16:58, Peter Maydell <peter.mayd...@linaro.org> a écrit : > 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 >
