On 01/03/19 7:00 AM, Chris Packham wrote:
On Fri, Mar 1, 2019 at 11:15 AM Chris Packham judge.packham@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?
Could you enable debug prints in drivers/spi/spi-mem.c (especially ones at the of spi_mem_exec_op()) and post the log?