On Wed, 12 Feb 2025 at 13:10, Tim Hardisty <timhardist...@gmail.com> 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 > that the entire image in the flash slot, minus the 32 byte header, > should be copied to > * A further 32 bytes, that are perhaps a NuttX or gnu header or > something, but I can't track done what is is specifically. Don't > like loose ends, but hey ho > This "header" is the first 32 bytes of your nuttx binary also known as the ARM vector table. The first eight instructions have opcode e59ff018. This can be seen in the objdump of the sama5d3-xplained nuttx file. I use "arm-none-eabi-objdump -drl nuttx" The line numbers and disassembly are interleaved. I added the comments starting with <------ ---------------------------------------------------------------- nuttx: file format elf32-littlearm Disassembly of section .text: 20008000 <_vector_start>: <------ START running here. ADDRESS 0x20008000 _vector_start(): /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:66 20008000: e59ff018 ldr pc, [pc, #24] @ 20008020 <_vector_start+0x20> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:67 20008004: e59ff018 ldr pc, [pc, #24] @ 20008024 <_vector_start+0x24> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:68 20008008: e59ff018 ldr pc, [pc, #24] @ 20008028 <_vector_start+0x28> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:69 2000800c: e59ff018 ldr pc, [pc, #24] @ 2000802c <_vector_start+0x2c> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:70 20008010: e59ff018 ldr pc, [pc, #24] @ 20008030 <_vector_start+0x30> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:71 20008014: e59ff018 ldr pc, [pc, #24] @ 20008034 <_vector_start+0x34> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:72 20008018: e59ff018 ldr pc, [pc, #24] @ 20008038 <_vector_start+0x38> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:73 2000801c: e59ff018 ldr pc, [pc, #24] @ 2000803c <_vector_start+0x3c> 20008020: 20008240 .word 0x20008240 <------- ADDRESS loaded into PC by line 66 20008024: 200081c0 .word 0x200081c0 20008028: 200080a0 .word 0x200080a0 2000802c: 20008160 .word 0x20008160 20008030: 20008100 .word 0x20008100 20008034: 20008224 .word 0x20008224 20008038: 20008040 .word 0x20008040 2000803c: 20008220 .word 0x20008220 20008040 <arm_vectorirq>: arm_vectorirq(): <---snip----> ... 20008240 <__start>: <------- The instruction at 0x20008000 jumps here __start(): /nuttx/arch/arm/src/armv7-a/arm_head.S:220 20008240: f10e00df cpsid if,#31 ---------------------------------------- > * 4 byte reset handler address > * 4 byte stack pointer value as appropriate for the reset handler > * The address that I saw, 24 bytes in (i.e. 8 bytes after the reset > handler address) is the address that the reset handler will finally > jump to, after whatever it needs to do, I think? My debugger says > this is the "Entry point"? > * The NuttX Binary itself (i.e. pre MCUboot header stuff) does not > include the "load address" so my debugger must get this from the > loader script or map file etc. > > For my binary: > The load address 0x20008000 is where you should enter this image. (Not true for all boards) The instruction at the load address will jump to the correct location. NuttX should set the stack pointers. I can get my NuttX binary to run by either: > > * setting the stack value to 0 and running from 0x20008000 - but not > 0x20008040. Or > * setting the stack value to 0x200082e0 and running from 0x200080c0 > > I still admit to being confused and hate not 100% "knowing" what is > going on. > I respect people who admit they don't know _everything_. Unless you customized your startup code, copying your image to the correct address and running from 0x20008000 should be enough.
