DM SPI flash improvements

Tony Dinh mibodhi at gmail.com
Mon Mar 27 07:10:55 CEST 2023


Hi Simon,

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
> numbers.

Yes, indeed. Using SPI-bus numbers is problematic in this scenario.

Thanks,
Tony

>
> >
> > 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
>
> Regards,
> Simon


More information about the U-Boot mailing list