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 there - absolutely works
and seems intuitively correct to me, but Microchip preferred the idea of
also setting the stack pointer and that's where I failed. This idea came
from the <boards/arm/samv7/common/src/sam_boot_image.c> code which is
NOT copying code to SDRAM but running in XIP mode I think. So probably
was not a good starting point!
On 13/02/2025 00:12, Lwazi Dube wrote:
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.
