Teensy 4.1 Implementation

Teensy 4.1 Implementation

[Shiny Saana]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Hello!

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.

I asked around on IRC, and I was redirected to those two mailing lists, for
guidance, and also as writing code without maintainers approval would be
pointless.

Thank you!

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: Teensy 4.1 Implementation

[Peter Maydell]

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:
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

Re: Teensy 4.1 Implementation

[Shiny Saana]

[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]

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.maydell@linaro.org> a
écrit :

> 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:
> 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
>

[-- Attachment #2: Type: text/html, Size: 5128 bytes --]

Re: Teensy 4.1 Implementation

[Alex Bennée]

Shiny Saana <shinysaana@gmail.com> writes:

> 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.

Don't worry about it - mailing lists are absolutely a good place to
discuss things ahead of time. I suspect because the devel list looks
to be mostly consisting of PATCHes and discussion of them that puts off
people from asking questions up front.

> 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.

Does the board use a standardised host controller or something custom?
You can see all the current host controllers in hw/usb/meson.build:

  # usb host adapters
  softmmu_ss.add(when: 'CONFIG_USB_UHCI', if_true: files('hcd-uhci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_OHCI', if_true: files('hcd-ohci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_OHCI_PCI', if_true: files('hcd-ohci-pci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_EHCI', if_true: files('hcd-ehci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_EHCI_PCI', if_true: files('hcd-ehci-pci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_EHCI_SYSBUS', if_true: files('hcd-ehci.c', 'hcd-ehci-sysbus.c'))
  softmmu_ss.add(when: 'CONFIG_USB_XHCI', if_true: files('hcd-xhci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_XHCI_PCI', if_true: files('hcd-xhci-pci.c'))
  softmmu_ss.add(when: 'CONFIG_USB_XHCI_SYSBUS', if_true: files('hcd-xhci-sysbus.c'))
  softmmu_ss.add(when: 'CONFIG_USB_XHCI_NEC', if_true: files('hcd-xhci-nec.c'))
  softmmu_ss.add(when: 'CONFIG_USB_MUSB', if_true: files('hcd-musb.c'))
  softmmu_ss.add(when: 'CONFIG_USB_DWC2', if_true: files('hcd-dwc2.c'))
  softmmu_ss.add(when: 'CONFIG_USB_DWC3', if_true: files('hcd-dwc3.c'))

  softmmu_ss.add(when: 'CONFIG_TUSB6010', if_true: files('tusb6010.c'))
  softmmu_ss.add(when: 'CONFIG_IMX', if_true: files('chipidea.c'))
  softmmu_ss.add(when: 'CONFIG_IMX_USBPHY', if_true: files('imx-usb-phy.c'))
  softmmu_ss.add(when: 'CONFIG_VT82C686', if_true: files('vt82c686-uhci-pci.c'))
  specific_ss.add(when: 'CONFIG_XLNX_VERSAL', if_true: files('xlnx-versal-usb2-ctrl-regs.c'))
  specific_ss.add(when: 'CONFIG_XLNX_USB_SUBSYS', if_true: files('xlnx-usb-subsystem.c'))

So hopefully you can just use an existing model. Search for the TYPE_FOO
variable for your given host controller to see how the board models
instantiate it.


> 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.

>
> 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!

The submitting patches document has a lot of information on this
including a guide to using sourcehut to publish a branch as emails if
setting up local email is too tricky.

>
> Again, thanks a bunch!
>
> //Saana
>
> Le lun. 15 août 2022 à 16:58, Peter Maydell <peter.maydell@linaro.org> a écrit :
>
>  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:
>  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


-- 
Alex Bennée

Re: Teensy 4.1 Implementation

[Peter Maydell]

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

Re: Teensy 4.1 Implementation

[Shiny Saana]

[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4498 bytes --]

Re: Teensy 4.1 Implementation

[Peter Maydell]

On Sun, 21 Aug 2022 at 01:05, Shiny Saana <shinysaana@gmail.com> wrote:
> 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.

Great, that's good progress!

> 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?

Yes, I think this is probably a reasonable way to go.

> 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?

Depends exactly what you want to do. If you want "let the user
load data to an arbitrary address", then the "generic loader"
is usually helpful:
https://www.qemu.org/docs/master/system/generic-loader.html

If you mean "C code within QEMU loads data to a specific place",
rom_add_blob_fixed_as() is probably what you want. This is how
hw/arm/boot.c loads both user-provided data files and the
hand-coded mini-bootloader into the guest.

> 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?

The behaviour of armv7m_load_kernel() depends on what kind
of file you pass to -kernel. If you pass -kernel an ELF file,
then it will get loaded to the addresses as specified by
the ELF file, so you can use that to put data anywhere you like.
If you pass it a raw binary file then, yeah, at the moment
that gets loaded to address 0. There's no real reason for this
limitation -- it's mainly because when that code was written
we supported very few M-profile boards, and all of them booted
from address 0. (That is, the board doesn't set either the
init-svtor or init-nsvtor properties on the armv7m object to
anything other than 0.) We could change how this works, but
the difficulty is that the desire for "Just Do What I Mean"
behaviour for a specific board tends to conflict with the
desire for all boards to behave in a consistent manner.
In particular, at the moment passing a binary file to -kernel
means "I want this to be loaded so that it has the
CPU vector table in it and execution starts from reset as
the architecture says it should"; it can't both mean that
consistently across M-profile boards and also mean "on the
teeny board, be an image file intended to boot via the ROM
loader".

Loading the teeny images via the generic loader rather than
via -kernel would be one way to sidestep this issue...

Do you know what the hardware sets the initial vector
base address to? (that is, where the ROM itself puts its
reset/interrupt vector table). I couldn't find anything in
the datasheet that said that.

(By the way, calling armv7m_load_kernel() is mandatory even if
you don't care about loading an image, because it's the function
that arranges that the CPU gets reset correctly.)

thanks
-- PMM

Re: Teensy 4.1 Implementation

[Shiny Saana]

[-- Attachment #1: Type: text/plain, Size: 6451 bytes --]

Thank you again for your time!

I didn't know at all about the generic loader!! It feels to me that it will
definitely be very useful in loading the Teensy image.

(To give more background: the Teensy-Arduinon toolchain first compiles an
.elf and then convert that to an Intex hex file. We can retrieve that .elf
in /tmp after compilation, but if all you have is an ihex (which is the
case for my use-case), then you're out of luck.)

To answer your question:

> Do you know what the hardware sets the initial vector
> base address to? (that is, where the ROM itself puts its
> reset/interrupt vector table). I couldn't find anything in
> the datasheet that said that.

From experimentation and dissasembly on the ROM, (located in 0x0020_0000),
the very first int (converted to BE) is "0x2020_1000" , which is located to
"OCRAM2", also referred as "ROM RAM" by the documentation, and the next int
is "0x0020_2091", which both points inside the ROM itself , and which when
forcibly disassembled in Ghidra does look like a function.
So I'm pretty confident the initial vector base address is 0x0020_0000.

Regarding the "kernel loading" issue, I believe that I was initially
mistaken. From other examples online, I believed that it was the way to
load the Teensy image. But thinking and discussing it with another ARM dev,
wouldn't the ROM itself actually be considered the kernel?

The teensy ihex image (converted to raw binary) could then be loaded via
the generic loader (and then, document that behavior in QEMU, and for user
convenience, in my own program using QEMU, I could merely provide a script
that handles the arguments for them).

Knowing that, if the call to  armv7m_load_kernel() is mandatory, maybe it
would make sense to load the ROM in C code via this function, with the
compiled ROM addresses from 0x0000_0000 to 0x001F_FFFF being padded with 0.
I'm *absolutely not sure* if this is a good idea, but that's the one I got
from the understanding that I have.

As always, thank you again for the help (and for using some of your time to
go through the documentation yourself, I genuinely appreciate the help a
great lot.)

Saana

Le mar. 23 août 2022 à 15:09, Peter Maydell <peter.maydell@linaro.org> a
écrit :

> On Sun, 21 Aug 2022 at 01:05, Shiny Saana <shinysaana@gmail.com> wrote:
> > 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.
>
> Great, that's good progress!
>
> > 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?
>
> Yes, I think this is probably a reasonable way to go.
>
> > 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?
>
> Depends exactly what you want to do. If you want "let the user
> load data to an arbitrary address", then the "generic loader"
> is usually helpful:
> https://www.qemu.org/docs/master/system/generic-loader.html
>
> If you mean "C code within QEMU loads data to a specific place",
> rom_add_blob_fixed_as() is probably what you want. This is how
> hw/arm/boot.c loads both user-provided data files and the
> hand-coded mini-bootloader into the guest.
>
> > 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?
>
> The behaviour of armv7m_load_kernel() depends on what kind
> of file you pass to -kernel. If you pass -kernel an ELF file,
> then it will get loaded to the addresses as specified by
> the ELF file, so you can use that to put data anywhere you like.
> If you pass it a raw binary file then, yeah, at the moment
> that gets loaded to address 0. There's no real reason for this
> limitation -- it's mainly because when that code was written
> we supported very few M-profile boards, and all of them booted
> from address 0. (That is, the board doesn't set either the
> init-svtor or init-nsvtor properties on the armv7m object to
> anything other than 0.) We could change how this works, but
> the difficulty is that the desire for "Just Do What I Mean"
> behaviour for a specific board tends to conflict with the
> desire for all boards to behave in a consistent manner.
> In particular, at the moment passing a binary file to -kernel
> means "I want this to be loaded so that it has the
> CPU vector table in it and execution starts from reset as
> the architecture says it should"; it can't both mean that
> consistently across M-profile boards and also mean "on the
> teeny board, be an image file intended to boot via the ROM
> loader".
>
> Loading the teeny images via the generic loader rather than
> via -kernel would be one way to sidestep this issue...
>
>
>
> (By the way, calling armv7m_load_kernel() is mandatory even if
> you don't care about loading an image, because it's the function
> that arranges that the CPU gets reset correctly.)
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 11235 bytes --]

Re: Teensy 4.1 Implementation

[Peter Maydell]

On Tue, 23 Aug 2022 at 15:00, Shiny Saana <shinysaana@gmail.com> wrote:
> From experimentation and dissasembly on the ROM, (located in 0x0020_0000), the very first int (converted to BE) is "0x2020_1000" , which is located to "OCRAM2", also referred as "ROM RAM" by the documentation, and the next int is "0x0020_2091", which both points inside the ROM itself , and which when forcibly disassembled in Ghidra does look like a function.
> So I'm pretty confident the initial vector base address is 0x0020_0000.

Right. In fact, rereading the datasheet, I see that I overlooked
that the IOMUXC_GPR_GPR16 reset value is actually specified. Bits
[31:7] of that are the CM7_INIT_VTOR, which is to say that they're
bits [31:7] of the initial vector table address. And they're set
so that is 0x0020_0000.

Your board code should be setting the init-nsvtor property on
the armv7m object to 0x00200000, if it isn't already.

> Regarding the "kernel loading" issue, I believe that I was initially
> mistaken. From other examples online, I believed that it was the way
> to load the Teensy image. But thinking and discussing it with another
> ARM dev, wouldn't the ROM itself actually be considered the kernel?

Yes, this would be in line with the way we use -kernel on other
M-profile board models.

> Knowing that, if the call to  armv7m_load_kernel() is mandatory,
> maybe it would make sense to load the ROM in C code via this
> function, with the compiled ROM addresses from 0x0000_0000 to
> 0x001F_FFFF being padded with 0.

That's one way to do it. I think it would be better to adjust
armv7m_load_kernel() so that it loaded the file to a board-specific
ROM base, which would avoid the need for the weird zero-padding.
Two options:
 * we could make armv7m_load_kernel() take a base address as well as
   a size for the region it loads the "kernel" to
 * we could have armv7m_load_kernel() be clever enough to query
   the CPU to find out what the VTOR value is and load the
   "kernel" there

I'll have a think about which one of those I prefer, and maybe
write a patch...

thanks
-- PMM

Re: Teensy 4.1 Implementation

[Shiny Saana]

[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]

> Your board code should be setting the init-nsvtor property on
> the armv7m object to 0x00200000, if it isn't already.

I'm going to add that property right away!

> Yes, this would be in line with the way we use -kernel on other
> M-profile board models.

Got it! Thank you for correcting my understanding!

> I'll have a think about which one of those I prefer, and maybe
> write a patch...

I do think it would be better with such a solution, yes.
I personally think querying init-nsvtor would reduce complexity and "make
sense".
Or perhaps both?
Something as simple as adding a function taking a functing the base load
address as a parameter, and another that queries init-nsvtor and call it
with that value? Everyone would happy :p

I will go with the "padded 0 bytes" plan for now, so that I can move on
with the rest of the implementation, but please do ping me if you do end up
upstreaming such a patch!
As always, thanks again!

Saana

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

> On Tue, 23 Aug 2022 at 15:00, Shiny Saana <shinysaana@gmail.com> wrote:
> > From experimentation and dissasembly on the ROM, (located in
> 0x0020_0000), the very first int (converted to BE) is "0x2020_1000" , which
> is located to "OCRAM2", also referred as "ROM RAM" by the documentation,
> and the next int is "0x0020_2091", which both points inside the ROM itself
> , and which when forcibly disassembled in Ghidra does look like a function.
> > So I'm pretty confident the initial vector base address is 0x0020_0000.
>
> Right. In fact, rereading the datasheet, I see that I overlooked
> that the IOMUXC_GPR_GPR16 reset value is actually specified. Bits
> [31:7] of that are the CM7_INIT_VTOR, which is to say that they're
> bits [31:7] of the initial vector table address. And they're set
> so that is 0x0020_0000.
>
> Your board code should be setting the init-nsvtor property on
> the armv7m object to 0x00200000, if it isn't already.
>
> > Regarding the "kernel loading" issue, I believe that I was initially
> > mistaken. From other examples online, I believed that it was the way
> > to load the Teensy image. But thinking and discussing it with another
> > ARM dev, wouldn't the ROM itself actually be considered the kernel?
>
> Yes, this would be in line with the way we use -kernel on other
> M-profile board models.
>
> > Knowing that, if the call to  armv7m_load_kernel() is mandatory,
> > maybe it would make sense to load the ROM in C code via this
> > function, with the compiled ROM addresses from 0x0000_0000 to
> > 0x001F_FFFF being padded with 0.
>
> That's one way to do it. I think it would be better to adjust
> armv7m_load_kernel() so that it loaded the file to a board-specific
> ROM base, which would avoid the need for the weird zero-padding.
> Two options:
>  * we could make armv7m_load_kernel() take a base address as well as
>    a size for the region it loads the "kernel" to
>  * we could have armv7m_load_kernel() be clever enough to query
>    the CPU to find out what the VTOR value is and load the
>    "kernel" there
>
> I'll have a think about which one of those I prefer, and maybe
> write a patch...
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 6446 bytes --]