Re: Teensy 4.1 Implementation

[Shiny Saana]

Hello!

Thank you all again for your initial guidance.

I've been able to write an initial Teensy 4.1 machine, for now with only the few important memory regions initialized, and successfully ran some hand-written ARM code on it. 

I was wondering what your opinions might be for implementing the next step, which in my opinion should be bootstrapping a "kernel" in the format the board actually expects. This is however the current roadblock I am hitting.

The documentation ( https://www.pjrc.com/teensy/IMXRT1060RM_rev3.pdf ), in section 9.7.1, gives some informations on how, in the actual Teensy board, the ROM, executed at boot, initialize the board peripherals, and also reads from a data structure included in the Flash memory (the user-provided program) where the CPU should jump to after the ROM has done its work (somewhere in that same Flash memory, usually).

I was able to successfully dump the ROM of the real board and confirm this behavior. Given that the current plan is not to emulate every peripherals, I am of the opinion that writing a very simple ROM that merely reads this Flash provided data structure and jumps to the provided address sounds like a good starting point, so that I can keep iterating on writing more and more complex code through the provided Teensy toolchain, and implementing needed peripherals.

As such, I have several questions:

1/ To replicate this behaviour, is this considered the correct approach by the current QEMU maintainers?

2/ If so, I have not been able to find any function that would be able to load data into a memory region "statically". Does one exist? Is there an alternative to this process?

3/ Regarding loading the "kernel" of the board, as part of the init process, I am calling the usual "armv7m_load_kernel" function with its usual parameters. However, it seems to load it as the very start of the address space, which is not where the flash memory is, and so is not where the kernel should be loaded. I wasn't able to find a workaround. Is there something I'm missing?

Sorry to bother you with so many questions.

Thanks again,

Saana

Le mar. 16 août 2022 à 12:06, Peter Maydell <peter.maydell@linaro.org> a écrit :

On Tue, 16 Aug 2022 at 10:59, Alex Bennée <alex.bennee@linaro.org> wrote:
> Shiny Saana <shinysaana@gmail.com> writes:
> > 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.
>
> Handling GPIOs in QEMU is fine (we have things like the qdev_init_gpio_*
> functions to handle them). The problem is usually what to do with the
> actual general purpose pins which aren't wired to something we emulate
> in the board. Some boards expose their values via QMP properties but I
> suspect whats really needed is a generic mechanism for exposing GPIO to
> external scripts rather than have every board define it's own thing.

Yes. However one key thing for trying to get a new board model
in is not to get tangled up in trying to improve/extend
the core QEMU facilities for something. That's much harder
than "my board model supports GPIO output lines to the same
extent as the other existing board models" :-)

thanks
-- PMM