[PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

[Chris Packham]

On 10/02/21 2:15 am, Marek Behun wrote:
> On Tue, 9 Feb 2021 06:50:35 +0000
> Chris Packham <Chris.Packham at alliedtelesis.co.nz> wrote:
>
>> On 9/02/21 3:07 pm, Marek Behun wrote:
>>> On Tue, 9 Feb 2021 01:08:54 +0000
>>> Chris Packham <Chris.Packham at alliedtelesis.co.nz> wrote:
>>>   
>>>> On 9/02/21 1:16 pm, Chris Packham wrote:
>>>>> On 9/02/21 9:18 am, Marek Behun wrote:
>>>>>> On Mon, 8 Feb 2021 20:11:06 +0000
>>>>>> Chris Packham <Chris.Packham at alliedtelesis.co.nz> wrote:
>>>>>>      
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> Do you have this in a repo I can pull from? I've got a couple of boards
>>>>>>> I can give this a spin on.
>>>>>> https://gitlab.nic.cz/turris/turris-omnia-uboot/
>>>>>> branch v2021.04-rc-mv-ddr-14.0.0
>>>>>>
>>>>>> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
>>>>>> one contains one more commit that is needed for Omnia with Samsung DDR
>>>>>> chips.
>>>>> I've tested the dm-88f6820-amc board. Training completed without
>>>>> issue, as does memtester running from Linux.
>>>>>
>>>>> Hit a bit of a snag on the x530 because the changes pushed it over the
>>>>> SPL size (it was already pretty close). I'll look to see if there's
>>>>> anything I can drop out or maybe bump the SPL size (I never did get a
>>>>> clear answer from Marvell as to what the size limit actually is).
>>>> I can temporarily work around the size issue by disabling watchdog
>>>> support in SPL (I really don't want that to be the long term solution).
>>>>
>>>> But then I encounter an odd problem. When I "reset" the board gets
>>>> through the DDR training but never makes it to u-boot proper, but if I
>>>> power cycle it boots through to the u-boot prompt. This doesn't happen
>>>> on the db-88f6820-amc board. One difference between the x530 and the amc
>>>> board is that the x530 has ECC so maybe something is going into the
>>>> weeds if ECC has already been enabled by a previous boot.
>>>>   
>>> Could you bisect which commit causes this?
>> Seems to be the last one (ddr: marvell: a38x: fix SPLIT_OUT_MIX state
>> decision) not entirely sure what the problem is. So I guess you can
>> consider the upstream update good, the fix SPLIT_OUT_MIX not so much it
>> happens to be the thing that causes the issue and the straw that tips
>> the build size over the limit.
> That's bad, because that is the one commit that is needed for Omnias
> with Samsung chips. Could you try to apply this last commit without the
> previous 18 ones? It should apply.
>
> If it does not work, could you please send me your board ddr topology
> definition? I will try to update the patch.

With just the one patch I see the hang (and the size blow out). The 
board topology is all upstream (board/alliedtelesis/x530/x530.c).