qemu-devel
[Top][All Lists]
Advanced

[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: Tue, 23 Aug 2022 15:21:25 +0100

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



reply via email to

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