Incorrect CPSIZE for STM32MP1 FMC

[Rockyaaaaa]

I am using the FMC peripheral of the STM32MP157 to access the FPGA, the FMC is configured as a Synchronous read synchronous write PSRAM. For the simplicity of the FPGA logic design I would like to have the burst reads and burst writes with CRAM page size (CPSIZE) fixed at 1024 bits.

This is the device tree configuration:

&fmc {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&fmc_pins_mx>;
	pinctrl-1 = <&fmc_sleep_pins_mx>;
	status = "okay";
    psram@0,0 {
		compatible = "mtd-ram";
		reg = <0 0x00000000 0x100000>;
		bank-width = <2>;

		st,fmc2-ebi-cs-transaction-type = <8>;
		st,fmc2-ebi-cs-cclk-enable = <1>;
		st,fmc2-ebi-cs-mux-enable;
		st,fmc2-ebi-cs-buswidth = <16>;
		st,fmc2-ebi-cs-clk-period-ns = <60>;
		st,fmc2-ebi-cs-cpsize = <128>;
		st,fmc2-ebi-cs-data-latency-ns = <0>;
		st,fmc2-ebi-cs-write-bus-turnaround-ns = <0>;
		st,fmc2-ebi-cs-max-low-pulse-ns = <0>;
    };
    psram@1,0 {
		compatible = "mtd-ram";
		reg = <1 0x00000000 0x100000>;
		bank-width = <2>;

		st,fmc2-ebi-cs-transaction-type = <8>;
		st,fmc2-ebi-cs-cclk-enable = <1>;
		st,fmc2-ebi-cs-mux-enable;
		st,fmc2-ebi-cs-buswidth = <16>;
		st,fmc2-ebi-cs-clk-period-ns = <60>;
		st,fmc2-ebi-cs-cpsize = <128>;
		st,fmc2-ebi-cs-data-latency-ns = <0>;
		st,fmc2-ebi-cs-write-bus-turnaround-ns = <0>;
		st,fmc2-ebi-cs-max-low-pulse-ns = <0>;
    };
};

This is the part of user space program for Linux to read and write PSRAM:

    if ((fd1 = open("/dev/mtd6", O_SYNC | O_RDWR)) < 0)
        errmsg_die("open()");
    if (0 != lseek(fd1, 0, SEEK_SET))
        errmsg_die("lseek()");

    err = write(fd1, data, size);
    if (err < 0)
        errmsg_die("write()");
 

But the actual test found two problems, I got stuck for a long time completely do not know how to solve:

1. When reading PSRAM, the length of one burst access cannot reach 1024 bits, but only 256 bits.
2. A burst write to PSRAM can reach 1024 bits, but there is a small probability that 256 bits will be written at one time, and there will be a delay before the next round of write operation.

I suspect that this is due to some mechanism with Linux kernel or A7 core, but I am not familiar with the underlying layer at all.
I would like to ask how to solve this problem. Thanks!

[Erwan SZYMANSKI]

Hello @Rockyaaaaa ,
Cross-checked with FMC expert, no obvious misconfiguration seen on our side. Do you have your own driver on top of FMC stack ? Do you have a FMC register dump available somewhere ?

Kind regards,
Erwan.

[Rockyaaaaa]

Glad to get your reply, I don't have my own FMC driver and I don't have a FMC register dump. The "mtd-ram" in the device tree is the driver that comes with the kernel. Should I dump the FMC registers using the devmem utility?

[Erwan SZYMANSKI]

Hi @Rockyaaaaa ,
If you can get it with devmem2 yes it could be good for us to analyze this dump, as we do not see any error in your DT.

Kind regards,
Erwan.