[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Teensy 4.1 Implementation

From: Peter Maydell
Subject: Re: Teensy 4.1 Implementation
Date: Mon, 15 Aug 2022 15:57:28 +0100

On Sat, 13 Aug 2022 at 18:54, Shiny Saana <shinysaana@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:

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:

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]