Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
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 #include #include 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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze【请注意，邮件由lists.intric...@gmail.com代发】
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: (0xff62 - 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 - 0x2005) 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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
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: (0xff62 - 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 - 0x2005) 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, -Kurtdiff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 22:08 +0530, Jagan Teki wrote: > On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller > wrote: > > > > > > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > > > > > > > > > > > > From: Jagan Teki > > > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > > > > > + Kever > > > > > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > > > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - > > > > > 22:31:31) > > > > > Trying to boot from BOOTROM > > > > > Returning to boot ROM... > > > > > > > > > > U-Boot SPL 2019.10-rc2-1-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 mailing list U-Boot@lists.denx.de
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, Aug 19, 2019 at 10:37 PM Kurt Miller
wrote:
>
> On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> > On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller
> > 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", >cic->cic_ctrl0,
> > readl(>cic->cic_ctrl0));
> > printf("cic: status0: (0x%x - 0x%x)\n",
> > >cic->cic_status0, readl(>cic->cic_status0));
> > printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> > >grf->ddrc0_con0, readl(>grf->ddrc0_con0));
> > printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> > >grf->ddrc1_con0, readl(>grf->ddrc1_con0));
> > printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
> > readl(>grf->soc_con0));
> > printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> > >pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
> > printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> > >pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
> > printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> > >pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
> > printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> > >pmugrf->os_reg2, readl(>pmugrf->os_reg2));
> > printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> > >pmugrf->os_reg3, readl(>pmugrf->os_reg3));
> > printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> > >pmusgrf->soc_con4, readl(>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: (0xff62 - 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 - 0x2005)
> 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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller
> 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", >cic->cic_ctrl0,
> readl(>cic->cic_ctrl0));
> printf("cic: status0: (0x%x - 0x%x)\n",
> >cic->cic_status0, readl(>cic->cic_status0));
> printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> >grf->ddrc0_con0, readl(>grf->ddrc0_con0));
> printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> >grf->ddrc1_con0, readl(>grf->ddrc1_con0));
> printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
> readl(>grf->soc_con0));
> printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> >pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
> printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
> printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
> printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> >pmugrf->os_reg2, readl(>pmugrf->os_reg2));
> printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> >pmugrf->os_reg3, readl(>pmugrf->os_reg3));
> printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> >pmusgrf->soc_con4, readl(>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: (0xff62 - 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 - 0x2005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)
Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
I see 'Size=2048MB'.
Regards,
-Kurt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller 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", >cic->cic_ctrl0,
readl(>cic->cic_ctrl0));
printf("cic: status0: (0x%x - 0x%x)\n",
>cic->cic_status0, readl(>cic->cic_status0));
printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
>grf->ddrc0_con0, readl(>grf->ddrc0_con0));
printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
>grf->ddrc1_con0, readl(>grf->ddrc1_con0));
printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
readl(>grf->soc_con0));
printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
>pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
>pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
>pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
>pmugrf->os_reg2, readl(>pmugrf->os_reg2));
printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
>pmugrf->os_reg3, readl(>pmugrf->os_reg3));
printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
>pmusgrf->soc_con4, readl(>pmusgrf->soc_con4));
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller wrote: > > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > > > From: Jagan Teki > > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > > > + Kever > > > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > > Trying to boot from BOOTROM > > > > Returning to boot ROM... > > > > > > > > U-Boot SPL 2019.10-rc2-1-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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, Aug 19, 2019 at 7:01 PM Mark Kettenis wrote: > > > From: Jagan Teki > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > + Kever > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > Trying to boot from BOOTROM > > > Returning to boot ROM... > > > > > > U-Boot SPL 2019.10-rc2-1-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. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hi Kurt On Mon, Aug 19, 2019 at 4:04 PM Kurt Miller wrote: > > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > > > From: Jagan Teki > > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > > > + Kever > > > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > > Trying to boot from BOOTROM > > > > Returning to boot ROM... > > > > > > > > U-Boot SPL 2019.10-rc2-1-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@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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote: > > > > From: Jagan Teki > > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > > > + Kever > > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > > Trying to boot from BOOTROM > > > Returning to boot ROM... > > > > > > U-Boot SPL 2019.10-rc2-1-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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
> From: Jagan Teki > Date: Mon, 19 Aug 2019 00:21:40 +0530 > > + Kever > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller > 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > > Trying to boot from BOOTROM > > Returning to boot ROM... > > > > U-Boot SPL 2019.10-rc2-1-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@fe32: 1, sdhci@fe33: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In:serial@ff1a > Out: serial@ff1a > Err: serial@ff1a > Model: Pine64 RockPro64 > rockchip_dnl_key_pressed: adc_channel_single_shot fail! > Net: > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
+ Kever On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller 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-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2019.10-rc2-1-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@fe32: 1, sdhci@fe33: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff1a Out: serial@ff1a Err: serial@ff1a Model: Pine64 RockPro64 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze
Hello, The Rockpro64_V2.1 2018-07-02 using master code base freezes with only the following output: U-Boot TPL 2019.10-rc2-1-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-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc2-1-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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
