On 01/03/19 1:42 PM, Chris Packham wrote: > On Fri, Mar 1, 2019 at 8:40 PM Chris Packham <judge.pack...@gmail.com> wrote: >> >> On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra <vigne...@ti.com> wrote: >>> >>> >>> >>> On 01/03/19 7:00 AM, Chris Packham wrote: >>>> On Fri, Mar 1, 2019 at 11:15 AM Chris Packham <judge.pack...@gmail.com> >>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I was just testing out the db-88f6820-amc on u-boot#master and found >>>>> that the SPL can't fetch then next stage from SPI. >>>>> >>>>> U-Boot SPL 2019.04-rc2-00139-g91c56ed98da7 (Mar 01 2019 - 10:26:26 +1300) >>>>> High speed PHY - Version: 2.0 >>>>> Detected Device ID 6820 >>>>> board SerDes lanes topology details: >>>>> | Lane # | Speed | Type | >>>>> -------------------------------- >>>>> | 0 | 5 | PCIe0 | >>>>> | 4 | 0 | SGMII1 | >>>>> | 5 | 0 | SGMII2 | >>>>> -------------------------------- >>>>> PCIe, Idx 0: detected no link >>>>> High speed PHY - Ended Successfully >>>>> mv_ddr: mv_ddr-armada-18.09.2 >>>>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window >>>>> mv_ddr: completed successfully >>>>> Trying to boot from SPI SPI probe failed. >>>>> SPL: failed to boot from all boot devices >>>>> ### ERROR ### Please RESET the board ### >>>>> >>>>> I haven't had time to bisect this yet but I wondered if this was >>>>> related to the recent spi changes (this board uses SPI1 so maybe >>>>> that's the corner case). I may also potentially be fixed by the SPI >>>>> Kconfig series that is floating around on the list. >>>> >>>> The plot thickens... >>>> >>>> The failure to boot is because the db-88f6820-amc does not set >>>> CONFIG_SYS_MALLOC_F_LEN and the default is too small to support all >>>> the probing required to fetch the next stage from SPI. I don't know >>>> why I never set this. The other mvebu boards all have it set. Patch >>>> for that on the way. >>>> >>>> Now I run into a situation where I can't update u-boot. The spi >>>> commands all say success but erasing won't actually delete the data >>>> and updating fails (presumably because the erase fails). Similarly >>>> when I change something and use saveenv it doesn't stick for the next >>>> boot. >>>> >>> >>> Hmm, interesting. What's the flash part on this board? Is flash >>> identified correctly by sf probe? >> >> Seems to be correct. >> >> => sf probe >> SF: Detected n25q256a with page size 256 Bytes, erase size 4 KiB, total 32 >> MiB >> >>> >>> Could you enable debug prints in drivers/spi/spi-mem.c (especially ones >>> at the of spi_mem_exec_op()) and post the log? >>> >> >> They're a bit too verbose to post here but nothing out of the >> ordinary, bytes in/out all ret 0. >> > > Here's a snippet of the commands used when the saveenv command runs > > 0c 00 13 fd 00 | [256B in] [ret 0] > 0c 00 13 fe 00 | [256B in] [ret 0] > 0c 00 13 ff 00 | [256B in] [ret 0] > Erasing SPI flash...06 | [0B -] [ret 0] > 21 | [4B out] [ret 0] > 05 | [1B in] [ret 0] > 06 | [0B -] [ret 0] > 21 | [4B out] [ret 0] > 05 | [1B in] [ret 0] > 06 | [0B -] [ret 0] > 21 | [4B out] [ret 0] > 05 | [1B in] [ret 0] >
Hmm, I dont see sector address for erase commands (similar to what is printed at for read command at the beginning of the log)? Does kirkwood_spi.c support 4 byte addressing mode? If not could you try enabling SPI_FLASH_BAR and see if that helps? > The command sequence for the erase looks correct per the datasheet. > >>> >>> >>> -- >>> Regards >>> Vignesh -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot