DM SPI flash improvements
sjg at chromium.org
Mon Mar 27 06:00:37 CEST 2023
On Mon, 27 Mar 2023 at 12:28, Tony Dinh <mibodhi at gmail.com> 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.
> 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 chromium.org): 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_DM_HWSPINLOCK is not set
> # CONFIG_CMD_SF_TEST is not set
More information about the U-Boot