On 10/02/21 2:15 am, Marek Behun wrote: > On Tue, 9 Feb 2021 06:50:35 +0000 > Chris Packham <chris.pack...@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.pack...@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.pack...@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).