Open nvlsianpu opened 2 years ago
From what i read, qspi is not a unified zephyr driver. qspi nor flash driver is MCU manufacture specific. For example both ST and Nordic have their own QSPI nor-flash driver.
For example the sfdp-bfp
definition is different, st one includes the SFDP header, but nordic one doens't.
&octospi1 {
pinctrl-0 = <&octospim_p1_clk_pb2 &octospim_p1_ncs_pg6
&octospim_p1_io0_pd11 &octospim_p1_io1_pf9
&octospim_p1_io2_pf7 &octospim_p1_io3_pf6
&octospim_p1_io4_pc1 &octospim_p1_io5_ph3
&octospim_p1_io6_pg9 &octospim_p1_io7_pd7
&octospim_p1_dqs_pc5>;
pinctrl-names = "default";
status = "okay";
mx25lm51245: ospi-nor-flash@0 {
compatible = "st,stm32-ospi-nor";
reg = <0>;
ospi-max-frequency = <DT_FREQ_M(50)>;
size = <DT_SIZE_M(512)>; /* 512 Megabits */
spi-bus-width = <OSPI_OPI_MODE>;
data-rate = <OSPI_DTR_TRANSFER>;
status = "okay";
sfdp-bfp = [
53 46 44 50 06 01 02 ff
00 06 01 10 30 00 00 ff
C2 00 01 04 10 01 00 ff
84 00 01 02 C0 00 00 ff
00 00 00 00
];
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "nor";
reg = <0x00000000 DT_SIZE_M(4)>;
};
};
};
};
&qspi {
status = "okay";
pinctrl-0 = <&qspi_default>;
pinctrl-1 = <&qspi_sleep>;
pinctrl-names = "default", "sleep";
mx25r64: mx25r6435f@0 {
compatible = "nordic,qspi-nor";
reg = <0>;
/* MX25R64 supports only pp and pp4io */
writeoc = "pp4io";
/* MX25R64 supports all readoc options */
readoc = "read4io";
sck-frequency = <8000000>;
jedec-id = [c2 28 17];
sfdp-bfp = [
e5 20 f1 ff ff ff ff 03 44 eb 08 6b 08 3b 04 bb
ee ff ff ff ff ff 00 ff ff ff 00 ff 0c 20 0f 52
10 d8 00 ff 23 72 f5 00 82 ed 04 cc 44 83 68 44
30 b0 30 b0 f7 c4 d5 5c 00 be 29 ff f0 d0 ff ff
];
size = <67108864>;
has-dpd;
t-enter-dpd = <10000>;
t-exit-dpd = <35000>;
};
};
Hi @de-nordic,
This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.
Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.
@nvlsianpu you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.
Thanks!
Is your enhancement proposal related to a problem? Please describe. SFDP headers are read up to static allocated amount (spi_nor.c: 3, stm32_qspi.c: 3, stm32_ospi.c: 3) It would be possible to make number of header possible to read dynamic.
Describe the solution you'd like Rework SFDP discovery procedures so it will iterates over SFDP headers and its parameter tables.
Describe alternatives you've considered
Additional context Maybe a common procedure for iterating over SFDP tables can be created. It can use handlers provided by the driver for fetch the SFDP data and call drivers callback for apply settings basing on SFDP tables data.