Lwazi - today was a school day and you are now my favourite teacher :-)
You could not have explained this more clearly or thoroughly and I
TOTALLY get it now!!!
THANK YOU
What you propose as the way to do it - just use the load address as
provided in the MCUboot header and running from t
On Wed, 12 Feb 2025 at 13:10, Tim Hardisty wrote:
> Thanks Lwazi and Peter. By examining the data in the NuttX binary I have
> tentatively concluded that the binary, as stored as an MCUboot signed
> bootable image:
>
> * Has the 32 byte MCUboot header. This contains the address in RAM
> tha
Lwazi,
My bad, but you could build Nuttx for armv7-a and disassemble its vector
table to figure it out.
Try configuring Nuttx for qemu-armv7a:nsh and build the image. Then
using addr2line you can determine where the source for the vector table
is via "addr2line -e nuttx 0x0" which returns
"
Thanks Lwazi and Peter. By examining the data in the NuttX binary I have
tentatively concluded that the binary, as stored as an MCUboot signed
bootable image:
* Has the 32 byte MCUboot header. This contains the address in RAM
that the entire image in the flash slot, minus the 32 byte header
On Tue, 11 Feb 2025 at 18:59, Peter Barada wrote:
> Tim,
>
> Common across bulk of ARM processors, the vector table starting at
> address 0x0 contains the 32-bit value of the stack pointer, address 0x4
> contains the reset vector (i.e. where to start execution in supervisor
> state) and then the
Tim,
Common across bulk of ARM processors, the vector table starting at
address 0x0 contains the 32-bit value of the stack pointer, address 0x4
contains the reset vector (i.e. where to start execution in supervisor
state) and then the exception and IRQ vectors.
As an example, nuttx/arch/arm/
Hello all.
I'm trying to understand the "header" bytes of a NuttX .bin file (ELF?),
so I can try and locate and use the ARM Cortex A (SAMA5D2) reset and
stack pointer vectors in an MCUboot image.
It seems that there are 32 bytes (after the MCUboot header) of a
repeating pattern (0xe59ff018)
