[U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master
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.
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.
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?
On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra vigneshr@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.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?
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.
-- Regards Vignesh
On Fri, Mar 1, 2019 at 8:40 PM Chris Packham judge.packham@gmail.com wrote:
On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra vigneshr@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.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?
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]
The command sequence for the erase looks correct per the datasheet.
-- Regards Vignesh
On 01/03/19 1:42 PM, Chris Packham wrote:
On Fri, Mar 1, 2019 at 8:40 PM Chris Packham judge.packham@gmail.com wrote:
On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra vigneshr@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.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?
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
On Fri, Mar 1, 2019 at 9:35 PM Vignesh Raghavendra vigneshr@ti.com wrote:
On 01/03/19 1:42 PM, Chris Packham wrote:
On Fri, Mar 1, 2019 at 8:40 PM Chris Packham judge.packham@gmail.com wrote:
On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra vigneshr@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.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?
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?
Yep SPI_FLASH_BAR seems to do the trick. Should I update the defconfig and consider that the fix or do we want to make SPI_FLASH_BAR selected based on some condition?
The command sequence for the erase looks correct per the datasheet.
-- Regards Vignesh
-- Regards Vignesh
participants (2)
-
Chris Packham -
Vignesh Raghavendra