Thanks for taking the time to reply, Lwazi.
As best as I know, the Nuttx build (with my, or any app, set as the
start app) is running from RAM. Uboot certainly copies iteself to RAM
and runs - and if I get it it to load my build (which is smaller than
than the available ram) it works fine.
I see from that arm_head.S has a #error if CONFIG_BOOT_RUNFROMFLASH is
set, which confuses me as I haven't knowingly done anything to build the
NuttX binary to specifically run from DRAM or in XIP mode. But I will
delve deeper, thanks.
Related - I think the QSPI flash would need to be be put into XIP mode
to run that way so something else I can search for clues. Also I can
look at relocatable elf files etc which I know I've seen reference to.
I also see that u-boot does a memcpy of the elf binary from flash to RAM
so examining that code further might also give me clues.
If all else fails I will revert to using u-boot; I want(ed) to use
mcuboot as it natively supports iamge upgrades and swaps along with
encryption checks and seems to boot faster than uboot does. And I find
u-boot difficult to understand and work with, whereas mcuboot seemed
more "friendly"...until now lol.
Thanks,
TimH.
On 29/01/2025 02:46, Lwazi Dube wrote:
On Tue, 28 Jan 2025 at 13:30, Tim Hardisty <timhardist...@gmail.com> wrote:
Hi all,
I am trying to get MCUboot to work on my custom board with a SAMA5D2
(Arm V7A) and after a lot of battles am nearly there.
I can boot into MCUboot stored in flash, and I can also download/debug it.
MCUboot is happy enough with my firmware images to call my board's
"board_boot-image" function - but no SAMA5 boards in the repo have this
function for me to refer to.
I have never used MCUboot.
What happens if you jump into _vector_start at the beginning of the SAMA5
image? I presume that both your bootloader and nuttx are running XIP from
NOR flash.
The entry is _vector_start here -> arch/arm/src/arm/arm_vectortab.S
... and it jumps into __start here ->arch/arm/src/arm/arm_head.S
Is this what you are looking for?
