stm32: New Driver for FMC/FSMC

[matthew-koch]

Is your feature request related to a problem? Please describe.
The STM32 series isn't able to use on-board memory devices (NOR Flash, NAND, SRAM, and SDRAM).

Describe the solution you'd like
More memory.

New driver type, "memory-controller." It doesn't do much after startup, but needs to start early for possible data/bss.

A sample/test for memory.

• Create drivers/memory_controller/

• Rename dts/bindings/memory-controllers/ to "memory-controller" (singular) to match Device Tree name.

• Create dts/bindings/sdram/ - YAML for SDRAM chips (e.g., Micron). Not sure where to put dts files for chips, but it would be nice to be able to reuse them instead of putting them in the board/ dts files.

• The driver only needs to read the info from device tree (I guess by #define), do a little math to figure out the timing and setup the clocking. Low power modes could be a future implementation.

Additional context
There are differences between the FSMC (F4, L4, etc..) and the FMC (F7, H7, etc..). The main difference is the FMC can drive SDRAM. I think they can go into a single driver, but we'll see.

I'm not sure what the overall objective with using /ext/ HAL is (or isn't). Is it a temporary solution or is the long-term goal to use it? Should this driver work with registers or use HAL?

[erwango]

I'm not sure what the overall objective with using /ext/ HAL is (or isn't). Is it a temporary solution or is the long-term goal to use it? Should this driver work with registers or use HAL?

Aim of using HALs is to fasten deployment of drivers and ease their maintenance.
Specifically, the abstraction capability should ease development of drivers that can cover a whole family of controllers.
For more information, I recommend @MaureenHelm's presentation: https://www.youtube.com/watch?v=BV7EYCzSXH0
To be short, HALs allowed to quickly enlarge Zephyr HW support, helping developers to spend more time on application rather than pure HW enabling. To keep this momentum, vendors are committed to maintain them to make it a perennial solution.

Should this driver work with registers or use HAL?

Regarding STM32, there are two flavors:
-HAL: Fully featured, high level API.
-LL: Low level, modular API with low footprint

In general LL is used for 'simple' drivers, like UART, I2C, SPI, where we can benefit from low footprint and still develop drivers that are compatible with full STM32 family (modulo some IP specific adaptation, as done in the case of I2C for instance).
HAL is rather used in cases where developing/validating a driver from scratch would require too much effort vs the gain in footprint (rater small compared to the use case): ethernet, USB, ..

So, if you prefer to work with registers and the driver is meant to be simple, LL might fit.

This being said, this is only a recommendation, this is not mandatory. Though, the more series you enable on your driver the more users it will get, so more feedback, fixes, enhancements ... In that regard I think using HAL/LL helps in community work.

[carlescufi]

Please submit a Pull Request.

[carlescufi]

#23453 is actually a PR for this, reopening and relabeling as enhancement.