STM32H750 as a standard target

[blckmn]

No description provided.

[SteveCEvans]

We need to support the EXST file format to be downloaded by boot loaders as used on H750 FCs.

[hydra]

I was just pointed at this after making some comments regarding the catch-22 situation that exists in the config storage subsystem initilazation.

Please see my comment here: #11110 (comment)
And my existing comments in the existing C code here:

SdCard - https://github.com/betaflight/betaflight/blob/master/src/main/fc/init.c#L302-L319
External Flash - https://github.com/betaflight/betaflight/blob/master/src/main/fc/init.c#L349-L367

The problem:
Currently the configuration for ANY unified target, where the config storage subsystem isn't internal flash, needs to be known at compile-time. This includes:

1. which subsystem to use.
2. what hardware resources should be used which can include:
   a) spi/quadspi/octospi/sdmmc peripheral choice
   b) peripheral configuration as there's no single peripheral config that works for all, system specific requirements e.g. SPI CS pin, QUADSPI hardware or software CS pin, QUADSPI io bank selection, octospi mux io configuration (OCTOSPIM).
   c) pin io config, flash clock speed, sdmmc clock speed, sdmmc detect pin + inverted or not config.
   d) when running from memory mapped flash it's not possible to disable the external flash chip's memory map mode as you need to know EXACTLY which flash chip is used because each flash chip has a different way of exiting SIOO mode which you need for performant memory mapped flash.

Some of the above CAN be detected at runtime, some CANNOT as assumptions would have to be made.
e.g. since a bootloader booted an FC you interrogate the current state of peripherals, such as SDMMC state, QUADSPI state, OCTOSPI state, OCTOSPIMUX state.
it's likely not very feasible to do this in a small amount of code however, and is complicated and does not work for most cases and can't really work for GPIO as it's not possible to tell the difference between a bootloader configured button and a bootloader configured SD card detect switch just by looking at the GPIO registers.

Solution:
There is a solution which I do feel is workable though and that is to encode the configuration required for the external storage subsystem INTO THE FIRMWARE itself.

i.e. you build a 'unified target' and then 'inject' the subsystem config into the firmware, then the firmware can read from itself, which it can obviously already do as it's already running. the offset from the start of the firmware for the unified target can be known at compile time and thus the linker can be used to calculate it.

example layout: |<vector table>|<firmware>|<subsystem config>|<exst hash>|

The definition of a unified target would thus then include 3 things:

1. unified target binary selection.
2. external storage configuration.
3. unified target config.

In the case of memory mapped flash targets, the external storage configuration would also need to include the JEDEC id of the external flash chip used by target due to the requirement that you need to know how to disable SIOO and you can't do that unless you know the JEDEC ID of the flash first.

Note also: The JEDEC ID is what BF uses to decide how to use the flash. This means that memory mapped unified target manufactures MUST NOT change the flash chip if the new flash chip doesn't allow SIOO to be disabled in the same way as the old one. Once SIOO is disabled and QUAD/OCTOSPI memory mapped mode is disabled BF firmware is then able to re-detect the flash chip and re-enable SIOO mode and memory mapped mode as required. Thus it /would/ be possible to have a single unified target for a H730 board that uses a 2MB flash that is then changed in a later production run to an 8MB flash in the same family with the same SIOO configuration.

The boot process is then:

1. CPU boots into vendor-supplied bootloader in internal flash.
2. bootloader initializes hardware for storage subsystem (sd card, external flash, etc).
3. bootloader verifies EXST hash of firmware.
4. bootloader loads firmware from storage subsystem into RAM (H750) or enables memory mapped mode (H730). (See OctoSPI and Memory Mapped Flash support #11825)
5. bootloader runs firmware which is now in RAM (H750) or via memory mapped flash (H730).
6. BF boot process starts, initiatives CPU.
7. BF initializes memory regions (which are linker-defined addresses)
8. BF boot process refers to linker defined compiled-in offset to storage subsystem config and reads it.
9. BF initialises storage subsystem. For a MM flash mode this includes disabling SIOO mode, disabling CPU MM flash mode, re-detecting the flash chip, re-enabling SIOO mode and CPU MM flash mode. The flash chip re-detection is required for other BF subsystems, e.g. flash chip layout for BB logging.
10. BF reads the config and continues to boot normally.

Technical notes:

• Some space is already reserved in the EXST bootloader layout for additional configuration such as this in the EXST block which also contains the MD5 hash.
• There is already a method and code to inject the EXST block into a target in the Makefile, an additional step to create a machine-readable chunk just needs to be added in the Makefile just before the block is injected.
• Once an FC is initially flashed with an H730/H750 unified target, as defined above, it can be interrogated for upgrades by the configurator as per any other unified target.
• The point of the process of injecting a storage subsystem is the same as created unified targets. it cuts down on the amount of BINARY variances.
• At the time you build the UNIFIED target is there is no SPECIFIC storage subsystem config so something, somewhere, would have to make sure the EXST hash is created and valid before a user can flash it. Currently this is the Makefile, but this should likely be changed to either a) the configurator or b) the new custom build-on-demand or c) some other build system, as a single file needs be generated for a user-selected unified target from the binary AND the storage system config, combine them adding the EXST hash in the process.

The benefit of all this is that there is ZERO interaction with ANY bootloader from ANY vendor and BF controls and owns the entire boot process once the handover to BF code is done.

[SteveCEvans]

Given that our new cloud build system effectively customises the unified builds per target it should be possible to select from my mutually exclusive set of storage options for an H750.

[blckmn]

@hydra you can put the necessary defines for activating the SPI for SDCARD etc in the unified target file. The build system will use those defines in the EXTRA_FLAGS passed on the cli. Which I think essentially achieves the "baking in the config" option you have presented.

[blckmn]

Given that our new cloud build system effectively customises the unified builds per target it should be possible to select from my mutually exclusive set of storage options for an H750.

Of course I will need to modify the system to support downloading a bin file :)

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> PASS
• cooling off period lapsed -> PASS
• commit count less or equal to three -> FAIL
• Don't merge label NOT found -> PASS
• at least one RN: label found -> PASS
• Tested label found -> FAIL
• assigned to an approver -> PASS
• approver count at least three -> FAIL

[hydra]

@blckmn no .bin file is needed for distribution, just the hex file. but the process of building a an EXST .hex file has the extra steps that perform hashing and EXST block injection. As noted in other conversations, a .bin file is no good for distribution as it doesn't contain a start address, .hex files can contains non-contiguous blocks which is what we need. For reference PX4 uses a json file with descriptions, dates, etc, an encoded and compressed firmware file and can contain multiple images which is much more useful.

@blckmn I'm rebasing my H7RF branch on master now, I guess a similar approach is needed for the H730 as we have for the H750 in this PR right?

Can you please re-open #11110 and I'll update the issue and PR to include an H730 target.

[blckmn]

Can you please re-open #11110 and I'll update the issue and PR to include an H730 target.

Reopened! :)

great news about the HEX file, as it will mean I do not need to add additional support for alternative file formats to the build API.

And yes - please follow the convention here for H730.

The unified target config file can have the defines needed to bake in the storage medium used at compile time.

[hydra]

@blckmn I'll give this a whirl soon. Did you re-create the SPRacingH7EXTREME/NANO/ZERO universal targets or does that still need to be done?

[hydra]

The EXST_ADJUST_VMA setting always needs to be specified but should be in the universal target cloud-build files as it is bootloader and flash-chip specific.

I'll do a PR to remove it.

[haslinghuis]

@hydra please add merge request in unified targets repo for H7EXTREME/NANO/ZERO.