[U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

[Kurt Miller]

On Mon, 2019-08-19 at 22:08 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller <lists at intricatesoftware.com> wrote:
> > 
> > 
> > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > > 
> > > > 
> > > > 
> > > > From: Jagan Teki <jagan at amarulasolutions.com>
> > > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > > > 
> > > > + Kever
> > > > 
> > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists at intricatesoftware.com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > > > with only the following output:
> > > > > 
> > > > > U-Boot TPL 2019.10-rc2-00001-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > > > 
> > > > > Whereas another board dated 2018-06-06 works and outputs the following:
> > > > > 
> > > > > U-Boot TPL 2019.10-rc2-00001-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > > > Trying to boot from BOOTROM
> > > > > Returning to boot ROM...
> > > > > 
> > > > > U-Boot SPL 2019.10-rc2-00001-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 +0200)
> > > > > 
> > > > > Both board have 4G RAM.
> > > > > 
> > > > > U-Boot was built by Mark Kettenis from master with only the
> > > > > baud rate changed for both tests. The 2018-07-02 board has different
> > > > > markings for the CPU and the RAM as follows:
> > > > > 
> > > > >      2018-06-06       2018-07-02
> > > > > CPU: RK3399           RK3399
> > > > >      SBETMF976 1652   SBETNM271 1826
> > > > > 
> > > > > RAM: PS006-075 BT     PS052-053 BT
> > > > >      N1YJ             83RL
> > > > > 
> > > > > Please let me know if there is additional information needed to
> > > > > further diagnose the boot freeze.
> > > > Please use mainline, and with doc/README.rockchip instructions.
> > > This is mainline as of Aug 16.  I built the image for Kurt and it the
> > > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> > > board.
> > > 
> > > > 
> > > > 
> > > > I'm able to boot with mainline tree.
> > > Sure I can believe that.  I believe your board from the same batch as
> > > mine.  I suspect that the DRAM used on Kurt's board may require
> > > slightly different timings.
> > > 
> > While my board (2018-07-02) freezes with Aug 16 mainline TPL,
> > it does boot ok with the rockchip-linux TPL with the following
> > output which may have some useful info:
> I think rockchip-linux doesn't have lddr4 code instead they rely on
> ddr bin, you can use same bin in Mainline w/o enabling TPL it would
> work like
> 
> rkbin => SPL => U-Boot proper
> 
> > 
> > 
> > DDR Version 1.23 20190709
> > In
> > channel 0
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 1
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 0 training pass!
> > channel 1 training pass!
> > change freq to 416MHz 0,1
> > Channel 0: LPDDR4,416MHz
> > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> > Channel 1: LPDDR4,416MHz
> > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> > 256B stride
> > channel 0
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 1
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 0 training pass!
> > channel 1 training pass!
> > channel 0, cs 0, advanced training done
> > channel 1, cs 0, advanced training done
> > change freq to 856MHz 1,0
> > ch 0 ddrconfig = 0x101, ddrsize = 0x40
> > ch 1 ddrconfig = 0x101, ddrsize = 0x40
> > pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
> > OUT
> Okay.
> 
> There are two possible areas to look here.
> 
> 1) sdram timings, like the one ie used via .dtsi
>     Use the working ddr bin and identify the board working frequency
> and follow below instructions to get the sdram dtsi
>     https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

Thank you. In the above output I saw this:

change freq to 856MHz 1,0

There is one entry in rk3399pro_ddr_800MHz_v1.23.bin for 856Mhz and
I was able to extract the DDR timings through step 4 in the provided
link. However from there the instructions don't appear to be correct
and I'm unsure how to get the timings formatted (step 5 and 6) and
added into the build.

Could you provide some additional guidance with these steps?

> 2) lpddr4 set rate sequence in driver, may not be a problem but only
> if 1) failed
>     right now, the driver would start initializing the actual board
> frequency(50MHz on my board) and then it switches to 400MHz and 800MHz
> simultaneously to make the proper sequence work on each channel with
> associated training.