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

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

[Kurt Miller]

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.

Regards,
-Kurt

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

[Jagan Teki]

+ Kever

On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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.

I'm able to boot with mainline tree.
U-Boot TPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)
Trying to boot from MMC1


U-Boot 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)

Model: Pine64 RockPro64
DRAM:  3.9 GiB
MMC:   dwmmc at fe320000: 1, sdhci at fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial at ff1a0000
Out:   serial at ff1a0000
Err:   serial at ff1a0000
Model: Pine64 RockPro64
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:

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

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Date: Mon, 19 Aug 2019 00:21:40 +0530
> 
> + Kever
> 
> On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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.

> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17)
> Trying to boot from BOOTROM
> Returning to boot ROM...
> 
> U-Boot SPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)
> Trying to boot from MMC1
> 
> 
> U-Boot 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)
> 
> Model: Pine64 RockPro64
> DRAM:  3.9 GiB
> MMC:   dwmmc at fe320000: 1, sdhci at fe330000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> In:    serial at ff1a0000
> Out:   serial at ff1a0000
> Err:   serial at ff1a0000
> Model: Pine64 RockPro64
> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> Net:
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

[Kurt Miller]

On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > 
> > From: Jagan Teki <jagan@amarulasolutions.com>
> > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > 
> > + Kever
> > 
> > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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:

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

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

[Michael Nazzareno Trimarchi]

Hi Kurt

On Mon, Aug 19, 2019 at 4:04 PM Kurt Miller <lists@intricatesoftware.com> wrote:
>
> On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > >
> > > From: Jagan Teki <jagan@amarulasolutions.com>
> > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > >
> > > + Kever
> > >
> > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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:
>
> 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

It's possible to dump the register after training in mainline uboot?

Mciahel
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

[Kurt Miller]

Hi Michael,

On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> It's possible to dump the register after training in mainline uboot?

I'm working on getting master to build now. How would I
go about dumping the register after training?

Regards,
-Kurt

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

[Jagan Teki]

On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller <lists@intricatesoftware.com> wrote:
>
> Hi Michael,
>
> On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > It's possible to dump the register after training in mainline uboot?
>
> I'm working on getting master to build now. How would I
> go about dumping the register after training?

It would be a bit hard, I tried below sequence at the end of
sdram_init (sorry for direct copy)

        printf("cic: ctr10: (0x%x - 0x%x)\n", &dram->cic->cic_ctrl0,
readl(&dram->cic->cic_ctrl0));
        printf("cic: status0: (0x%x - 0x%x)\n",
&dram->cic->cic_status0, readl(&dram->cic->cic_status0));
        printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
&dram->grf->ddrc0_con0, readl(&dram->grf->ddrc0_con0));
        printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
&dram->grf->ddrc1_con0, readl(&dram->grf->ddrc1_con0));
        printf("grf: soc_con0 (0x%x - 0x%x)\n", &dram->grf->soc_con0,
readl(&dram->grf->soc_con0));
        printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
&dram->pmu->pmu_noc_auto_ena, readl(&dram->pmu->pmu_noc_auto_ena));
        printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
&dram->pmu->pmu_bus_idle_req, readl(&dram->pmu->pmu_bus_idle_req));
        printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
&dram->pmu->pmu_bus_idle_st, readl(&dram->pmu->pmu_bus_idle_st));
        printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
&dram->pmugrf->os_reg2, readl(&dram->pmugrf->os_reg2));
        printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
&dram->pmugrf->os_reg3, readl(&dram->pmugrf->os_reg3));
        printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
&dram->pmusgrf->soc_con4, readl(&dram->pmusgrf->soc_con4));

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

[Kurt Miller]

On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller <lists@intricatesoftware.com> wrote:
> > 
> > 
> > Hi Michael,
> > 
> > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > > 
> > > It's possible to dump the register after training in mainline uboot?
> > I'm working on getting master to build now. How would I
> > go about dumping the register after training?
> It would be a bit hard, I tried below sequence at the end of
> sdram_init (sorry for direct copy)
> 
>         printf("cic: ctr10: (0x%x - 0x%x)\n", &dram->cic->cic_ctrl0,
> readl(&dram->cic->cic_ctrl0));
>         printf("cic: status0: (0x%x - 0x%x)\n",
> &dram->cic->cic_status0, readl(&dram->cic->cic_status0));
>         printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> &dram->grf->ddrc0_con0, readl(&dram->grf->ddrc0_con0));
>         printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> &dram->grf->ddrc1_con0, readl(&dram->grf->ddrc1_con0));
>         printf("grf: soc_con0 (0x%x - 0x%x)\n", &dram->grf->soc_con0,
> readl(&dram->grf->soc_con0));
>         printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> &dram->pmu->pmu_noc_auto_ena, readl(&dram->pmu->pmu_noc_auto_ena));
>         printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> &dram->pmu->pmu_bus_idle_req, readl(&dram->pmu->pmu_bus_idle_req));
>         printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> &dram->pmu->pmu_bus_idle_st, readl(&dram->pmu->pmu_bus_idle_st));
>         printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> &dram->pmugrf->os_reg2, readl(&dram->pmugrf->os_reg2));
>         printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> &dram->pmugrf->os_reg3, readl(&dram->pmugrf->os_reg3));
>         printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> &dram->pmusgrf->soc_con4, readl(&dram->pmusgrf->soc_con4));

Thank you. I have built mainline with CONFIG_RAM_ROCKCHIP_DEBUG=y
with your printf's above and it outputs the following before freezing:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)      
LPDDR4, 50MHz                                                                
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB                      
LPDDR4, 50MHz                                                                
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride                             
cic: ctr10: (0xff620000 - 0x14)         
cic: status0: (0xff620010 - 0x101)      
grf: ddrc0_con0 (0xff77e380 - 0x1f81)   
grf: ddrc1_con0 (0xff77e388 - 0x1f81)   
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x20000005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)

Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
I see 'Size=2048MB'.

Regards,
-Kurt

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

[Jagan Teki]

On Mon, Aug 19, 2019 at 10:37 PM Kurt Miller
<lists@intricatesoftware.com> wrote:
>
> On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> > On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller <lists@intricatesoftware.com> wrote:
> > >
> > >
> > > Hi Michael,
> > >
> > > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > > >
> > > > It's possible to dump the register after training in mainline uboot?
> > > I'm working on getting master to build now. How would I
> > > go about dumping the register after training?
> > It would be a bit hard, I tried below sequence at the end of
> > sdram_init (sorry for direct copy)
> >
> >         printf("cic: ctr10: (0x%x - 0x%x)\n", &dram->cic->cic_ctrl0,
> > readl(&dram->cic->cic_ctrl0));
> >         printf("cic: status0: (0x%x - 0x%x)\n",
> > &dram->cic->cic_status0, readl(&dram->cic->cic_status0));
> >         printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> > &dram->grf->ddrc0_con0, readl(&dram->grf->ddrc0_con0));
> >         printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> > &dram->grf->ddrc1_con0, readl(&dram->grf->ddrc1_con0));
> >         printf("grf: soc_con0 (0x%x - 0x%x)\n", &dram->grf->soc_con0,
> > readl(&dram->grf->soc_con0));
> >         printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> > &dram->pmu->pmu_noc_auto_ena, readl(&dram->pmu->pmu_noc_auto_ena));
> >         printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> > &dram->pmu->pmu_bus_idle_req, readl(&dram->pmu->pmu_bus_idle_req));
> >         printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> > &dram->pmu->pmu_bus_idle_st, readl(&dram->pmu->pmu_bus_idle_st));
> >         printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> > &dram->pmugrf->os_reg2, readl(&dram->pmugrf->os_reg2));
> >         printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> > &dram->pmugrf->os_reg3, readl(&dram->pmugrf->os_reg3));
> >         printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> > &dram->pmusgrf->soc_con4, readl(&dram->pmusgrf->soc_con4));
>
> Thank you. I have built mainline with CONFIG_RAM_ROCKCHIP_DEBUG=y
> with your printf's above and it outputs the following before freezing:
>
> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> 256B stride
> cic: ctr10: (0xff620000 - 0x14)
> cic: status0: (0xff620010 - 0x101)
> grf: ddrc0_con0 (0xff77e380 - 0x1f81)
> grf: ddrc1_con0 (0xff77e388 - 0x1f81)
> grf: soc_con0 (0xff77e200 - 0x7)
> pmu: noc_auto_ena (0xff3100d8 - 0x0)
> pmu: bus_idle_req (0xff310060 - 0x0)
> pmu: bus_idle_st (0xff310064 - 0x0)
> pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
> pmugrf: os_reg3 (0xff32030c - 0x20000005)
> pmusgrf: soc_con4 (0xff33e010 - 0x2600)
>
> Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
> I see 'Size=2048MB'.

Is your board running at 50MHz? (look like No). As I said please
explore step-by-step
00: First boot the board rkbin => SPL => U-Boot proper
01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
replace rkbin withTPL
02: Then dump the regmap if 01 failed.

Jagan.

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

[Kurt Miller]

Hi Jagan,

On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote:
> Is your board running at 50MHz? (look like No).

No it is running at 800Mhz or 856MHz (see rkbin TPL output below).

> As I said please
> explore step-by-step
> 00: First boot the board rkbin => SPL => U-Boot proper

This step was completed already. Here is the output again for reference:

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

> 01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
> replace rkbin withTPL

I am stuck here. I see that there were three 800Mhz entries
in the rkbin rk3399_ddr_800MHz_v1.20.bin file that was used to
create ./arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi.

rk3399-sdram-lpddr4-100.dtsi has one entry that appears to
be from the first 800Mhz data in rk3399_ddr_800MHz_v1.20.bin.

Using the instructions you linked:
https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

I have inspected rkbin rk3399_ddr_800MHz_v1.23.bin and found
there are two 800Mhz entries in it. I have extracted the two
entries but have have questions that the instructions don't
address well.

Why does the existing rk3399-sdram-lpddr4-100.dtsi only have
one entry while the instructions appear to indicate there
should be two, one for single and another for dual ranked?

Step 6 refers to editing the dtsi file:

"..., edit the initial values (don’t forget that they are in
little endian form) to match what the SPL code expects, 
convert the frequency value from the binary back into MHz
(line 38 in the attached dtsi files for reference)"

I believe I was able to convert the data into the updated
values correctly (see attached diff). However, one value
stood out to me. The 800Mhz value of 0x2faf0800 was converted
into decimal 50 in the existing data whereas other sdram files
converted it into 1/2 the Mhz value (e.g. 800Mhz -> 400).

With it set to 50 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 18:45:16)         
pctl_start: Failed to init pctl for channel 0 

With it set to 400 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 19:14:10)      
sdram_init: DDR3 - 400MHz failed!                                            
rk3399_dmc_init DRAM init failed -22                                         
Missing DTB 

> 02: Then dump the regmap if 01 failed.
> 
> Jagan.

01 failed. With the timings diff reverted I get this before it freezes:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)      
LPDDR4, 50MHz                                                                
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB                      
LPDDR4, 50MHz                                                                
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride                             
cic: ctr10: (0xff620000 - 0x14)         
cic: status0: (0xff620010 - 0x101)      
grf: ddrc0_con0 (0xff77e380 - 0x1f81)   
grf: ddrc1_con0 (0xff77e388 - 0x1f81)   
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x20000005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)

Please let me know other items can be tried to get this up and
running with the U-Boot TPL.

Regards,
-Kurt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timings.diff
Type: text/x-patch
Size: 17666 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190819/48fe60fd/attachment.bin>

[U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze【请注意，邮件由lists.intricate@gmail.com代发】

[Kever Yang]

Hi Kurt,


Does this patch fix your issue?

https://patchwork.ozlabs.org/patch/1147457/


Thanks,

- Kever

On 2019/8/20 上午7:32, Kurt Miller wrote:
> Hi Jagan,
>
> On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote:
>> Is your board running at 50MHz? (look like No).
> No it is running at 800Mhz or 856MHz (see rkbin TPL output below).
>
>> As I said please
>> explore step-by-step
>> 00: First boot the board rkbin => SPL => U-Boot proper
> This step was completed already. Here is the output again for reference:
>
> 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
>
>> 01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
>> replace rkbin withTPL
> I am stuck here. I see that there were three 800Mhz entries
> in the rkbin rk3399_ddr_800MHz_v1.20.bin file that was used to
> create ./arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi.
>
> rk3399-sdram-lpddr4-100.dtsi has one entry that appears to
> be from the first 800Mhz data in rk3399_ddr_800MHz_v1.20.bin.
>
> Using the instructions you linked:
> https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html
>
> I have inspected rkbin rk3399_ddr_800MHz_v1.23.bin and found
> there are two 800Mhz entries in it. I have extracted the two
> entries but have have questions that the instructions don't
> address well.
>
> Why does the existing rk3399-sdram-lpddr4-100.dtsi only have
> one entry while the instructions appear to indicate there
> should be two, one for single and another for dual ranked?
>
> Step 6 refers to editing the dtsi file:
>
> "..., edit the initial values (don’t forget that they are in
> little endian form) to match what the SPL code expects,
> convert the frequency value from the binary back into MHz
> (line 38 in the attached dtsi files for reference)"
>
> I believe I was able to convert the data into the updated
> values correctly (see attached diff). However, one value
> stood out to me. The 800Mhz value of 0x2faf0800 was converted
> into decimal 50 in the existing data whereas other sdram files
> converted it into 1/2 the Mhz value (e.g. 800Mhz -> 400).
>
> With it set to 50 I get this output before it stops:
>
> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 18:45:16)
> pctl_start: Failed to init pctl for channel 0
>
> With it set to 400 I get this output before it stops:
>
> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 19:14:10)
> sdram_init: DDR3 - 400MHz failed!
> rk3399_dmc_init DRAM init failed -22
> Missing DTB
>
>> 02: Then dump the regmap if 01 failed.
>>
>> Jagan.
> 01 failed. With the timings diff reverted I get this before it freezes:
>
> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> 256B stride
> cic: ctr10: (0xff620000 - 0x14)
> cic: status0: (0xff620010 - 0x101)
> grf: ddrc0_con0 (0xff77e380 - 0x1f81)
> grf: ddrc1_con0 (0xff77e388 - 0x1f81)
> grf: soc_con0 (0xff77e200 - 0x7)
> pmu: noc_auto_ena (0xff3100d8 - 0x0)
> pmu: bus_idle_req (0xff310060 - 0x0)
> pmu: bus_idle_st (0xff310064 - 0x0)
> pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
> pmugrf: os_reg3 (0xff32030c - 0x20000005)
> pmusgrf: soc_con4 (0xff33e010 - 0x2600)
>
> Please let me know other items can be tried to get this up and
> running with the U-Boot TPL.
>
> Regards,
> -Kurt

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

[Kurt Miller]

Hi Kever,

On Tue, 2019-08-20 at 10:46 +0800, Kever Yang wrote:
> Hi Kurt,
> 
> 
> Does this patch fix your issue?
> 
> https://patchwork.ozlabs.org/patch/1147457/
> 

Yes! It fixes my boot issue. Thank you for working on it.

However there is a second issue. Only 2G of memory was recognized
instead of the 4G the board has. I added this to get more
debug output:

diff --git a/drivers/ram/rockchip/sdram_rk3399.c b/drivers/ram/rockchip/sdram_rk3399.c
index 81fc71c051..0f876217c8 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -5,6 +5,10 @@
  * Adapted from coreboot.
  */
 
+#ifndef DEBUG
+#define DEBUG
+#endif
+
 #include <common.h>
 #include <clk.h>
 #include <dm.h>

U-Boot TPL 2019.10-rc2-00036-ga2ca54ff52-dirty (Aug 20 2019 - 09:41:36)
con reg        
cru , cic , grf , sgrf , pmucru , pmu 
Starting SDRAM initialization...
sdram_init: data trained for rank 1, ch 0
sdram_init: data trained for rank 1, ch 1
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 400 mhz 0, 1
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 800 mhz 1, 0
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...

Note that both the Row and Size differers from the
rkbin TPL output:

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

Regards,
-Kurt

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

[Jagan Teki]

On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller <lists@intricatesoftware.com> wrote:
>
> On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > >
> > > From: Jagan Teki <jagan@amarulasolutions.com>
> > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > >
> > > + Kever
> > >
> > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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

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.

[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@intricatesoftware.com> wrote:
> > 
> > 
> > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > > 
> > > > 
> > > > 
> > > > From: Jagan Teki <jagan@amarulasolutions.com>
> > > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > > > 
> > > > + Kever
> > > > 
> > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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.

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

[Jagan Teki]

On Mon, Aug 19, 2019 at 7:01 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Jagan Teki <jagan@amarulasolutions.com>
> > Date: Mon, 19 Aug 2019 00:21:40 +0530
> >
> > + Kever
> >
> > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller <lists@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.

Yes, this can be the cause. Thanks for pointing this.