DM SPI flash improvements

Simon Glass sjg at
Mon Mar 27 06:00:37 CEST 2023

Hi Tony,

On Mon, 27 Mar 2023 at 12:28, Tony Dinh <mibodhi at> wrote:
> Hi Simon,
> I'm investigating a problem with the Thecus N2350 board that has SPI
> flash on controller 1, but not on controller 0. Booting with SPI SPL
> is not possible with CONFIG_SF_DEFAULT_BUS=1.
> Reference:
> That led me to the drivers/mtd/spi/sf-uclass.c and drivers/spi/spi-uclass.c.
> And I found there are some problems in the spi_flash_probe(), as well
> as _spi_get_bus_and_cs(). But seeing your comment in the
> spi_flash_probe function header, I'm thinking perhaps I should not try
> to fix them.
> /*
>  * TODO(sjg at This is an old-style function. We should remove
>  * it when all SPI flash drivers use dm
>  */
> struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
>                                   unsigned int max_hz, unsigned int spi_mode)
> Could you or Jagan clarify the TODO above meaning? Are we fully in DM
> SPI yet? If we are, should this be replaced with other means to probe
> the SPI bus? Or it should have been automatically probed by DM SPI
> infrastructure, and we just need to tag the SPI 1 DTS node with
> boot-phase? If that's the case then perhaps this function should be
> defined out with some configs wrapping.

Ideally you would obtain the SPI-flash device using
spi_flash_std_probe(). The SPI buses can be added to the device tree
with 'spi0' and 'spi1' aliases. Then you can add a child noe of spi1
with your flash chip.

There is definitely some work needed to remove the old code. We don't
have a proper way to select the boot device yet, Probably what is
needed ultimately is something like the u-boot.spl-device-order used
by Rockchip boards. We should really get away from using SPI-bus

> My current SPI configs:
> # CONFIG_CMD_SF_TEST is not set
> Thanks,
> Tony


More information about the U-Boot mailing list