On Sun, Feb 10, 2019 at 10:37 PM Vignesh R <vigne...@ti.com> wrote: > > > > On 11/02/19 9:01 AM, Adam Ford wrote: > > On Tue, Feb 5, 2019 at 12:00 AM Vignesh R <vigne...@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 <vigne...@ti.com> > >> Tested-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> > >> Tested-by: Stefan Roese <s...@denx.de> > >> Tested-by: Horatiu Vultur <horatiu.vul...@microchip.com> > >> Reviewed-by: Jagan Teki <ja...@openedev.com> > >> Tested-by: Jagan Teki <ja...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
