Adapt for FMU with only FRAM and EEPROM

[niklaut]

Solved Problem

We built a smol FMU without SD card only with FRAM as minimal file system. Also doesn't have the revision resistors only EEPROM.

Solution

1. LittleFS manages the FRAM as /mnt/microsd and mounts it as /fs/microsd. We chose to keep the paths the same for compatibility. The rcS needs minor updates to allow the hardfault handler to still work.
2. The FRAM can do 30MHz writes, but the RamTron only does 10MHz by default. Adding a new BOARD_SPI_RAMTRON_SPEED_MHZ define to make that configurable.
3. LittleFS requires more stack in a couple of tasks (this is probably not the best solution).
4. Our board does not have a resistor for revisions, it only stores it in the EEPROM. Adding a new BOARD_HAS_ONLY_EEPROM_VERSIONING define to enable that behavior.

Changelog Entry

For release notes:

Feature Allow using FRAM as file system storage
Feature Allow using only EEPROM for versioning

Alternatives

All changes are backward compatible, except for:

• the stack increases due to LittleFS is dependent on configuration. Not sure how to handle that without impacting other boards.

Test coverage

• Lot's of hardware testing on our board

[davids5]

@niklaut Can we do the bmi changes as a separate PR single commit?

I would like to have a way to abstract the stack size change Maybe in board common define some 0 value defaults that will be added to values or replace them

#!defined(PX4_LOGGER_STACK_FS_ADJST)
#define PX4_LOGGER_STACK_FS_ADJST 0
#endif

PX4_STACK_ADJUSTED(3700+PX4_LOGGER_STACK_FS_ADJST),

Or

#!defined(PX4_LOGGER_STACK_SIZE)
#define PX4_LOGGER_STACK_SIZE 3700
#endif

PX4_STACK_ADJUSTED(PX4_LOGGER_STACK_SIZE),

[niklaut]

Removed the BMI changes, those can be done separately. Added a overridable logger stack define.

[dagar]

manages the FRAM as /mnt/microsd and mounts it as /fs/microsd

Please let's just abstract the path rather than fake it.

[dagar]

This could be moved to kconfig.

PX4-Autopilot/platforms/common/include/px4_platform_common/defines.h

Line 67 in ca9948a

#define PX4_STORAGEDIR PX4_ROOTFSDIR "/fs/microsd"

If there are any parts of the init scripting that are hard to adapt I'd propose pushing more of it into board/platform init code (driven by kconfig). I was planning to do this eventually either way.

[dagar]

kconfig

[niklaut]

I tried to understand how the RAMTRON speed is set in the code:

1. It's currently hardcoded to start initialization at 10MHz and if it fails tries 9 times again down to 1MHz.
2. Once the initialization succeeds and the part is detected, the speed is taken from the table (Between 25 and 40MHz) and set to priv->speed.
3. This table speed is then simply overwritten and set to between 1 and 10MHz.

So RAMTRON has is always running at slower than max speed.

I don't understand what the use case is for dynamically determining the max speed? The RAMTRON is not hot pluggable so unless your PCBs differ in quality, the max speed should always be the same.

I think the speed should be config option in the px4_mft_device_t struct and defaulted to use the max device speed. But that seems to be a larger refactoring, so I now hacked it to start at 30MHz, since I spent my timebox on this already.

[dagar]

I believe it was just desperation for the extremely rare case parameters were failing to restore in the field and we had nothing to go on.

[PetervdPerk-NXP]

@dagar @niklaut
Can we push to get this pr in
#23003
It allows us to be flexible for use cases like this.

[dagar]

I've merged #23003.

[niklaut]

Please let's just abstract the path rather than fake it.

It would break a lot of external code that has the /fs/microsd path hardcoded in, so we have to fake it.

[PetervdPerk-NXP]

Please let's just abstract the path rather than fake it.

It would break a lot of external code that has the /fs/microsd path hardcoded in, so we have to fake it.

We can de-hardcode /fs/microsd by adding it into rc.filepaths and then use the macro. Most other entries have been replaced by the kconfig symbol in #23003

[niklaut]

Sure, but not in this PR and certainly not in the time I have allocated for this. :-(

[niklaut]

Ping?

[davids5]

@niklaut I restarted https://github.com/PX4/PX4-Autopilot/actions/runs/10388157561/job/28763193102?pr=23424
If it fails again please have a look at what might have broken it

[davids5]

@dagar CI is happy now. Ok to merge?

[dagar]

So this would now be exporting the parameters twice to the same storage?

[dagar]

I disagree with faking the path, but hopefully we'll still be able to untangle it later pushing more of this into board init and a parameter backend.