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