Topic: Add linkable target to increase genericity

Hi !
I recently ported wolfboot to the RP2040 and i wanted to share with a PR but i encounter some problems.
Context :
The RP2040 is almost totally initialized with the stage 1 bootloader that is in a ROM. Except the Direct-XIP that requier initialization in bootloader. The fact is this initialization is given directly with the SDK and this is really a waste time to write manually this initialization in hal initialisation of wolfboot. I think this is so simple to link the bootloader given by the SDK right before Wolfboot that it is the best idea. This solution reduce effort, increase reliability and maintainability. MCUboot/Zephyr chooses this solution too. 
I suggest to add a final linkable object that allow users to link in another final binary. This would be a very nice and generic solution for users that want to use Wolfboot at any stage of booting.
I personally added 2 more targets to easily link my final elf :

# Transform it to object so it can be linked to final elf
../build/obj/image_v1_signed.o: ../build/image_v1_signed.bin
    @echo "\t[OBJCOPY]" $^ " --> " $@
    @$(OBJCOPY) -v -I binary -O elf32-littlearm -B arm \
        --rename-section  .data=.image_app \
        --set-section-alignment .data=8 \
        --set-section-flag .data=code \
        $^ $@

wolfboot.o: wolfboot.bin
    @echo "\t[OBJCOPY]" $^ " --> " $@
    @$(OBJCOPY) -I binary -O elf32-littlearm -B arm --rename-section .data=.boot3,code,alloc,contents $^ $@

As i'm not experimented with wolfboot, i'm not quiet sure that this solution is the best and i wanted to have your opinion about this. Porting Wolfboot on pico was only for a PoC during my project that's why you may find some nasty code but in case you are interested my modifications, here is my fork:

I didn't plane to work anymore on this solution but if you like my suggestion i can submit a PR.


Re: Add linkable target to increase genericity

Hi Thisora,

Thanks for your interest in wolfBoot.
Regarding the use of the linker to build the final image:

I think it's best to separate as much as possible the linking of the application, other stages of the bootloader, and wolfboot itself.
This allows better flexibility and abstractions among these different components, so I believe concatenating the components (as we do with the binassembly tool) is the most simple and effective approach.
If you really want to use the linker for this purpose you can always do that externally, without coupling these components in the normal wolfboot building process.
Do you see other strong reasons to not use concatenate the files directly with binassembly?

Besides that, please note that if you want to file a PR it shouldn't alter other targets and it should include tests.