DM SPI flash improvements
mibodhi at gmail.com
Mon Mar 27 07:10:55 CEST 2023
On Sun, Mar 26, 2023 at 9:01 PM Simon Glass <sjg at chromium.org> wrote:
> Hi Tony,
> 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.
> > Reference:
> > https://lists.denx.de/pipermail/u-boot/2023-March/511517.html
> > 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.
Thanks! What you said about spi_flash_std_probe() has confirmed what
I've been reading and thinking too.
> 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
Yes, indeed. Using SPI-bus numbers is problematic in this scenario.
> > My current SPI configs:
> > CONFIG_SPL_DM_SPI=y
> > CONFIG_SPL_DM_SPI_FLASH=y
> > # CONFIG_DM_HWSPINLOCK is not set
> > CONFIG_DM_SPI_FLASH=y
> > CONFIG_DM_SPI=y
> > CONFIG_SF_DEFAULT_SPEED=50000000
> > CONFIG_SF_DEFAULT_MODE=0x0
> > # CONFIG_CMD_SF_TEST is not set
> > CONFIG_SF_DEFAULT_BUS=1
> > CONFIG_SF_DEFAULT_CS=0
> > Thanks,
> > Tony
More information about the U-Boot