[U-Boot] [PATCH v4 14/20] mtd: spi: Switch to new SPI NOR framework

[Adam Ford]

On Sun, Feb 10, 2019 at 10:37 PM Vignesh R <vigneshr at ti.com> wrote:
>
>
>
> On 11/02/19 9:01 AM, Adam Ford wrote:
> > On Tue, Feb 5, 2019 at 12:00 AM Vignesh R <vigneshr at ti.com> wrote:
> >>
> >> Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
> >> layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
> >> use new interfaces/definitions
> >>
> >> Signed-off-by: Vignesh R <vigneshr at ti.com>
> >> Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> >> Tested-by: Stefan Roese <sr at denx.de>
> >> Tested-by: Horatiu Vultur <horatiu.vultur at microchip.com>
> >> Reviewed-by: Jagan Teki <jagan at openedev.com>
> >> Tested-by: Jagan Teki <jagan at amarulasolutions.com> #zynq-microzed
> >
> > This patch appears to break the da850_evm board which boots from SPI
> > Flash and initializes the davinci driver with platdata since the
> > device tree stuff does not quite work right in SPL.
>
> Oops, I did test on K2G EVM that has davinci SPI controller with micron
> n25q flash but that was with DT. Not sure whats missing with platdata.
>
> >
> > U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 10 2019 - 21:24:38 -0600)
> > Trying to boot from SPI
> > SPI probe failed.
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
>
> Could you enable debug prints at spi-mem level in drivers/spi/spi-mem.c
> (especially debug prints at the end of spi_mem_exec_op()) and post the
> logs here?
>
> >
> > Any suggestions on how to fix the SPI initialization without needing
> > the device tree?  I have tried to port the device tree stuff to SPL,
> > but I haven't yet been successful so I have had to leave the platdata
> > initialization in place.
> >
>
> I haven't changed any driver names so, platdata to driver bindings
> should still be the same. Could you verify if spi_nor_scan() is being
> called in drivers/mtd/spi/spi-nor-tiny.c for SPL?

I globally turned on DEBUG and I have two logs for you:

Not working:

U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 12 2019 - 13:04:19 -0600)
Trying to boot from SPI
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'davinci_spi'
   - not found
spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
driver=spi_flash_std
spi_get_bus_and_cs: Error path, created=1, device 'spi_flash'
SPI probe failed.
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

As a point of reference , I thought I'd show
WORKING version (before this patch):

U-Boot SPL 2019.01-02922-g2ee6705be0-dirty (Feb 12 2019 - 12:59:49 -0600)
Trying to boot from SPI
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'davinci_spi'
   - not found
spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
driver=spi_flash_std
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'spi_flash'
   - not found
spi_flash_std_probe: slave=8001fd60, cs=0
davinci_spi_set_speed speed 30000000
davinci_spi_set_mode mode 3
davinci_spi_set_speed speed 30000000
davinci_spi_set_mode mode 3
spi_get_bus_and_cs: bus=8001fbf4, slave=8001fd60
SPL: payload image: U-Boot 2019.01-02922-g2ee6705be0   load addr:
0xc107ffc0 size: 405306
Jumping to U-Boot
loaded - jumping to U-Boot...
image entry point: 0xc1080000
...

During this process, I learned a few things.
1.  I am not really using the device tree during SPL like i originally
thought and the OF_PLATDATA
2.  Getting SPL to support device tree with or without PLATDATA isn't
as straightforward as I hoped
3.  With the knowledge I learned from item 1, I tried to disabled
OF_CONTROL during SPL, but this patch also fails to build since it
assumes OF_CONTROL is always enabled.

If there are any suggestions you might have, I am willing to try them.

adam

>
> Sorry for the trouble.
>
> Regards
> Vignesh
>
>
> --
> Regards
> Vignesh