[U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master

[Vignesh Raghavendra]

On 01/03/19 1:42 PM, Chris Packham wrote:
> On Fri, Mar 1, 2019 at 8:40 PM Chris Packham <judge.packham at gmail.com> wrote:
>>
>> On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra <vigneshr at 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 at 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