> 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.mayd...@linaro.org> a écrit : > On Tue, 23 Aug 2022 at 15:00, Shiny Saana <shinysa...@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 >
