How do I get U-Boot to detect a single quad-SPI memory so that I can program it with STM32CubeProgrammer?

[Spamfast]

Hi.

I'm using the v2.1.0 ecosystem to build for a target that will boot TF-A & U-Boot from a single ISSI IS25LP016D-JNLE 2 mebibyte quad-SPI NOR flash connected with the rest of the system in e.MMC. (This is to work around the bug in the rev.B STM32MP1 silicon BOOTROM regarding e.MMC boot.)

I've used STM32CubeIDE 1.5.1 on Ubuntu 20.04 Linux to configure the device tree and I can read and write the device in Linux booted from e.MMC and have enabled NOR & nor-sdcard features in the machine/config/stm32mp153c-veethree-mx.conf file.

However I cannot get U-Boot to detect the 'nor0' flash device in the same way as I can on my STM32MP157A-EV1 kit using mtd list so that attempting to program the NOR flash with STM32CubeProgrammer results in a 'no such device nor0' error.

I've added

CONFIG_SPI_FLASH_SFDP_SUPPORT=y

CONFIG_SPI_FLASH_ISSI=y

to build-veethreeconnectbox2-stm32mp1-connectbox2/workspace/sources/u-boot-stm32mp/configs/stm32mp15_trusted_defconfig and I've added the line

    { INFO("is25lp032", 0x9d6015, 0, 64 * 1024,  32, 0) },

before

    { INFO("is25lp032", 0x9d6016, 0, 64 * 1024,  64, 0) },

to build-veethreeconnectbox2-stm32mp1-connectbox2/workspace/sources/u-boot-stm32mp/drivers/mtd/spi/spi-nor-ids.c to support the smaller device.

I've searched the STM32MP1 ecosystem wiki but cannot find any instructions that I'm not already following concerning configuring U-Boot.

What else do I need to do to get U-Boot to detect the flash?

[Olivier GALLIEN]

Hi @Spamfast​ ,

Sorry for late reply,

Did you declare your nor inside the U-boot DT ?

See how it's done for eval nor :

&qspi {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a &qspi_bk2_pins_a>;
	pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a &qspi_bk2_sleep_pins_a>;
	reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";
 
	flash0: mx66l51235l@0 {
		compatible = "jedec,spi-nor";
		reg = <0>;
		spi-rx-bus-width = <4>;
		spi-max-frequency = <108000000>;
		#address-cells = <1>;
		#size-cells = <1>;
	};
 
	flash1: mx66l51235l@1 {
		compatible = "jedec,spi-nor";
		reg = <1>;
		spi-rx-bus-width = <4>;
		spi-max-frequency = <108000000>;
		#address-cells = <1>;
		#size-cells = <1>;
	};
};

As a minor remark it could be cleaner to use the exact name of the part in stm32mp15_trusted_defconfig :

 { INFO("IS25LP016D", 0x9d6015, 0, 64 * 1024,  32, 0) },

Olivier

[Spamfast]

Thanks for the reply but I solved the problem myself.

FYI I used "is25lp016" in the device table to follow the existing pattern - the paste into my question was a typo. And yes, I expanded the &qspi node in both DTs and remember I said only ONE QSPI flash IC, not two so I omitted flash1. And speaking of naming - using 'mx661512351' in the DT is a daft idea idea anyway since the BOM will often change to a different part in production.

Because of the smaller flash IC capacity, I'd reduced the ssbl size from 2MiB to 1 and the env from 512KiB to 256 in the TSV file.

I'd assumed that the build & programming system would be designed in such a way as not to have to knife-and-fork the same data into lots of different places in the system but sadly not. I had to change the hard-coding in the U-Boot C-source that generates the default U-Boot mtdparts env-var by means of modifying the Kconfig stm32mp1_defconfig. This was not very well documented in the ecosystem wiki I must say, especially for those chosing the CubeMX route.

But then the documentation also claims that the boot sequence only uses IO0/1 for booting whereas the actual STM U-Boot QSPI customization hard-codes the driver to user all four and the CubeMX C++ libraries aren't built thread-safe so what was I expecting?