Closed hydra closed 3 years ago
davids5
commented
3 years ago @hydra - we will keep the issue here but to be clear. ALL H7 bootloaders live in the PX4-Autopilot repo. There is no H7 support here and there will never be
See https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v6x/bootloader.cmake
hydra
commented
3 years ago @davids5 Should I re-create this issue in the PX4-Autopilot issue tracker?
LorenzMeier
commented
3 years ago Can you try to copy the FMUv6x target and update it to your pin mapping? Then you automatically have a bootloader.
hydra
commented
3 years ago @LorenzMeier yes, but the other changes as above would still need to happen. @Igor-Misic Fancy having a go at this?
LorenzMeier
commented
3 years ago Any reason to not flash the PX4 bootloader into the lower flash sectors and just use it like for any other target? Are you trying to save flash or am I missing something?
Or is it the external flash support that you're missing? We've done that for I.MXRT1060 already. We might need to check about portability.
davids5
commented
3 years ago Any reason to not flash the PX4 bootloader into the lower flash sectors and just use it like for any other target? Are you trying to save flash or am I missing something?
The H750 has one 128K sector. But all that is needed is the the program mem interface and seeing this leads me to believe this is a solved problem.
Or is it the external flash support that you're missing? We've done that for I.MXRT1060 already. We might need to check about portability.
To date there is no I.MXRT1060 bootloader.
davids5
commented
3 years ago it is all right here https://github.com/PX4/PX4-Autopilot/blob/46f0388fc778d63ff1ded2125c76e006d3690f74/boards/spracing/h7extreme/src/flash_w25q128.c
Please use the linker to select the flash driver and not hack the bootloader files.
hydra
commented
3 years ago @LorenzMeier the goal is not to replace the bootloader that ships with any H750 FC, but turn the current PX4 bootloader into a second stage bootloader that the bootloader that shipped with the FC runs, which in turns runs the PX4 second stage bootloader that provides PX4 firmware update capability via QGC and/or other command line tools. Users cannot re-install the SP Racing bootloader if they erase it. The FC must always be able to boot any firmware, be it Betaflight, iNAV, PX4, Ardupilot, etc, and the FC must still support all the features it was sold with, such as dual boot and firmware (BF or SSBL) upgrades from SD card, which the SP Racing bootloader provides.
It shouldn't be that difficult to do, most of the code is already present I think.
The current situation is that flashing via QGroundControl and/or the PX4 build system is not possible.
The architecture of flight controllers that use the H750 (or other ST value-line) MCU's is different, the value-line CPUs have limited flash for a vendor specific, and often secure, bootloader that provide functionality for exposing the external flash that is connected via QSPI. The PX4 code runs directly from external flash when the CPU is in memory mapped mode. Bootloaders often provide other functionality, such as USB Mass-Storage or USB-DFU support for firmware updates, methods to boot from SD cards, dual boot functionality, diagnostics, methods to erase/reset config/firmware/entire external flash, etc. Vendors also may use 'Option bytes' that enable ST's secure boot functionality.
I propose that support for the H750 with external QSPI flash is added to the PX4 bootloader codebase, and that it's build-scripts are updated so that it can build an EXST format images.
== Background == The H750 has a single 128k page of flash which contains the vendor's bootloader.
In the case of the H7EXTREME the PX4 firmware has to be updated using DFU mode of the SPRacing bootloader. The vendor bootloader is non-upgradable and is write protected. It should not be erased.
== Boot process ==
The PX4 boot process is currently: 1) power on 2) run vendor bootloader code 3) vendor bootloader code looks for external flash chip and 'loadable firmware', copies it to ram and executes it. 4) For PX4 the 'loadable firmware' the SPRacing SSBL is used, which enables memory mapped mode and jumps to whatever code is on the flash chip at the 'correct location'. The 'correct location' was as-defined by the PR for PX4 that added support for the SPRacingH7EXTREME - https://github.com/PX4/PX4-Autopilot/pull/15385 and implemented in the SSBL code and the PX4 linker scripts.
The SSBL is here:
https://github.com/spracing/ssbl
The SSBL, when built, generates a binary image with an EXST block which contains an MD5 hash for firmware image for validation (validation only, no crypto keys involved).
The details of the EXST format are here:
https://github.com/betaflight/betaflight/blob/master/docs/EXST%20bootloader.md
The code/build steps for getting from a .elf to a .bin with EXST block is here:
linker script: https://github.com/spracing/ssbl/blob/master/src/main/link/stm32_ram_h750_exst_post.ld#L3-L28
makefile: https://github.com/spracing/ssbl/blob/master/Makefile#L434-L479
The definition of the 'correct address' is here:
https://github.com/spracing/ssbl/blob/master/src/main/main.c#L67-L68
i.e
0x90100000.The PX4 firmware address is influenced by the flash chip's page and block erase boundaries and the MCU's MPU granularity and the desire to reserve so space at the start of the flash chip for future use, such as partitioning information, etc.
== Key Implementation points ==