New topic to follow up on the bootloader discussion with @ksschwabe that started here
The question asked there was as follows:
On the topic of the bootloader- is it strictly necessary to use the PX4 Bootloader? If I have a bootloader for my particular board that’s already able to set up all the device peripherals and jump to the main app, it doesn’t seem like it should be necessary? Though I’m guessing it would take some modification of the PX4 build system to skip the normal bootloader…
No, it is not strictly necessary to use the PX4 bootloader. You could even not have a bootloader at all and use only the PX4 Firmware app (PX4/Firmware repo) and then upload your firmware via JTAG or SWD each time, or use the STM32F4 built-in bootloader. 
The STM32 microcontrollers boots to flash address 0x08000000 by default. This is the entry point for any firmware that you program onto the chip. (You can also get the microcontroller to boot to its built-in bootloader by pulling the “BOOT” pins high, see ST application note AN2606 for further details).
In the PX4 system, the Bootloader lives at address 0x08000000 and the Firmware lives at address 0x08004000 (note: the address for the PX4IO chips is different). Since the bootloader is at the base address, when the microcontroller boots/is reset, it always runs through the bootloader first. The bootloader checks whether it should remain in the bootloader or jump directly into the main app/firmware.
If you want to move the main firmware to another address on the microcontroller, you will need to change the address in the linker script, so that the firmware is correctly linked together during linking (the final stage of the compilation process). The linker script is found here: Firmware/nuttx-configs/<board-name>/scripts/ld.script. This would be the only change that you need to make to the main firmware to use your own bootloader. You won’t even need to change the linker script, provided that you put your own bootloader at address 0x08000000 and make sure that it correctly jumps to the main firmware when needed - don’t forget to relocate the vector table before you jump to the main app.
Perfect, that all makes sense with what I was seeing, thank you for the explanation 
So from an end product/functionality perspective, is there a benefit to incorporating the standard boot loader? For instance, would that allow you to use QGroundControl to upload a new firmware?
Also, would it be appropriate to use the PX4 bootloader as more of a “2nd stage” bootloader a la U-Boot? I ask because the chip I’m working with has two core clusters, one running Cortex application cores, and the other running dual Cortex-R5F cores, so consequently it has a rather complicated startup process. However it would be relatively straight forward to have the existing FSBL load the PX4 bootloader along with the NuttX/PX4 flight stack to the appropriate location and start the PX4 BL running if that would provide any benefit in the long run.
Of course all of this is only relevant once I complete the NuttX port for this chip… Currently working to understand the minimal set of NuttX functionality I need to have working to compile everything with the PX4 build system.
Edit: Moved post so it was a proper reply
I can’t really comment on whether it would be appropriate or not to use it as a second-stage bootloader. The one advantage that you have with using the Px4 bootloader, is that it’s transfer protocol is supported by QGroundControl, so you will be able to upload a new .px4 firmware image from QGC to your MCU.
If you are already bootloading your MCU with your own bootloader, I don’t know what advantage you would necessarily gain with having the Px4 bootloader in addition to your own. Unless you perhaps want to bootload your separate cores and then leave them alone whilst you work solely on the Px4 stuff. Then, you might have less of a work around to upload the firmware after compiling it.
It might be better to pose the question to someone more closely associated with the Px4 project. One of the maintainers, perhaps.