Re: Teensy 4.1 Implementation

[Shiny Saana]

> 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