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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
