Initial support for STM32 FMC NOR/PSRAM

[GeorgeCGV]

This PR extends existing #29686 and adds NOR/PSRAM controller.

The goal is to use an external display over the 8080 parallel interface.

The driver was tested using a custom H7 board with a modified #39335 driver.

The adapted display driver uses direct memory writes (for example, *FMC_BANK2_REG = Reg; __DSB();), where FMC_BANK2_REG is a definition of the SRAM bank address.

Everything works but there are some questions:

• Shall there be an API to write/read to/from NOR/PSRAM memory? Or is it okay when drivers expose properties for FMC reg and mem?
• Maybe it is better to combine dt-bindings of FMC under one header as it is done in LL?

[lochej]

Thank you for your contribution ! At some point I wanted to start on the same task and bumped into the same questions.

FMC in the first PR where it was introduced used linker sections to point to the correct adresses and allow the app to use data in a specific sdram.

If we come to the use case of driving a display:

Display drivers implementations use different interfaces, SPI, bitbang, FMC, LTDC... Some of them are shareable between architectures like SPI and bitbang, and others are device or familly specific (i.e. STM32).

For all 8080 display drivers that we have today, we have to access some kind of databus between the LCD and the MCU.
If it has to be device generic, then an FMC or memc driver should probably have a read()/write() api, to allow for non-memory mapped buses. Allowing to factor implementation for all architectures.

Who do we want to give the responsability of managing this databus ?
The display driver or the memc driver ? Or another layer ?

[mbolivar-nordic]

A couple of devicetree requests, otherwise no objections.

addressed

[mbolivar-nordic]

@GeorgeCGV thank you! I've dropped my -1.

[gmarull]

lgtm, one minor nitpick

[lochej]

Dear @GeorgeCGV,
Thank you for your great work !
I was able to run replicate your test with samples/drivers/display and samples/subsys/display/lvgl on my stm32l562e_dk by merging your PR and my st7789h2 driver and adding the necessary modification to use the FMC instead of the GPIO bitbang 👍

I'm using FMC-BANK1 as the LCD memory bus address like ST did in stm32l562e_discovery's BSP.

I'll therefore be able to provide support for FMC norsram for the stm32l5x when this is merged ! 😄
We'll have to sort out how to pass the used memory bank address though.

FMC definition for L5 series: -> dts/arm/st/l5/stm32l5.dtsi

soc {
  /* Non secure address 0x44020000 */
  /* Secure address 0x54020000*/
  fmc: memory-controller@44020000 {
	  compatible = "st,stm32-fmc";
	  reg = <0x44020000 0x400>;
	  clocks = <&rcc STM32_CLOCK_BUS_AHB3 0x00000001>;
	  label = "STM32_FMC";
	  status = "disabled";
  };
};

FMC config for the L562E_DK: -> boards/arm/stm32l562e_dk/stm32l562e_dk_common.dtsi

#include <dt-bindings/memory-controller/stm32-fmc-nor-psram.h>
&fmc {
    status = "okay";
    /* ST7789H2 FMC pinout based on UM2614 */
    pinctrl-0 = <&fmc_nce_pd7 &fmc_nwe_pd5 &fmc_noe_pd4
		&fmc_a0_pf0 &fmc_d0_pd14 &fmc_d1_pd15
		&fmc_d2_pd0 &fmc_d3_pd1 &fmc_d4_pe7 &fmc_d5_pe8 &fmc_d6_pe9
		&fmc_d7_pe10 &fmc_d8_pe11 &fmc_d9_pe12 &fmc_d10_pe13
		&fmc_d11_pe14 &fmc_d12_pe15 &fmc_d13_pd8 &fmc_d14_pd9
		&fmc_d15_pd10>;

    pinctrl-names = "default";

    lcd_fmc_sram: sram {
      status = "okay";
      compatible = "st,stm32-fmc-nor-psram";
      label = "STM32_FMC_NOR_PSRAM";

      #address-cells = <1>;
      #size-cells = <0>;

      bank1@0 {
        reg = <0x0>;
        st,control = <STM32_FMC_DATA_ADDRESS_MUX_DISABLE
                      STM32_FMC_MEMORY_TYPE_SRAM
                      STM32_FMC_NORSRAM_MEM_BUS_WIDTH_16
                      STM32_FMC_BURST_ACCESS_MODE_DISABLE
                      STM32_FMC_WAIT_SIGNAL_POLARITY_LOW
                      STM32_FMC_WAIT_TIMING_BEFORE_WS
                      STM32_FMC_WRITE_OPERATION_ENABLE
                      STM32_FMC_WAIT_SIGNAL_DISABLE
                      STM32_FMC_EXTENDED_MODE_DISABLE
                      STM32_FMC_ASYNCHRONOUS_WAIT_DISABLE
                      STM32_FMC_WRITE_BURST_DISABLE
                      STM32_FMC_CONTINUOUS_CLOCK_SYNC_ONLY
                      STM32_FMC_WRITE_FIFO_DISABLE
                      STM32_FMC_PAGE_SIZE_NONE>;
        st,timing = <1 1 32 0 0 2 2 STM32_FMC_ACCESS_MODE_A>;
	st,timing-ext = <5 1 3 2 STM32_FMC_ACCESS_MODE_A>;
      };
    };
  };

Enabling FMC: ->boards/arm/stm32l562e_dk/Kconfig.defconfig

#Under Display section
if DISPLAY

config ST7789H2
	default y

config MEMC_STM32_NOR_PSRAM
	default y

config MEMC
	default y

config REGULATOR
	default y

endif #DISPLAY

And other ports on my st7789h2 driver to remove the init of the bitbang GPIO and replace the writing to GPIOs by writing at the FMC bank 1 address:

#define LCD_REGISTER_ADDR FMC_BANK1_1
#define LCD_DATA_ADDR     (FMC_BANK1_1 | 0x00000002UL)

Writing to LCD pixel data ram is therefore just: ->drivers/display/display_st7789h2.c --> st7789h2_write(... , buffer)

	uint16_t *buffer = (void *)buf;
	size_t len = desc->buf_size/ST7789H2_PIXEL_SIZE;
	for (size_t i = 0; i < len; i++) {
		*(uint16_t *)LCD_DATA_ADDR = buffer[i];
	}

Writing a register is also simplified to: -> drivers/display/display_st7789h2.c --> st7789h2_transmit(..., uint8_t cmd, uint8_t *tx_data, size_t tx_count)

        /* Write register address */
	*(uint16_t *)LCD_REGISTER_ADDR = cmd;

	if (tx_data != NULL) {
		for (size_t count = 0; count < tx_count; count++) {
			*(uint16_t *)LCD_DATA_ADDR = (uint16_t) tx_data[count]; 
		}
	}

[lochej]

LGTM, implementation performs correct init of the FMC in NOR/SRAM mode.
Though, drivers accessing the configured FMC-banks should define their address space because it's not provided by this implementation.

[luispimo]

It is not possible to use this driver with STM32F103 SoCs. Apparently, the HAL code for these SoCs uses the old FSMC driver. Any suggestion on how to adapt the driver?

[GeorgeCGV]

@luispimo depending on how different it is. There is always a possibility to create f1 specific driver with a different compatibility label