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

Marek Behun marek.behun at nic.cz
Tue Feb 9 15:57:38 CET 2021


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.

BTW Chris if the first 18 patches are working for your devices, could
you please give Tested-by? Thanks.

Marek


More information about the U-Boot mailing list