Hi,

I got a nanopc-t4 amongst others which shipped with:

DDR Version 1.15 20181010 Channel 0: LPDDR3, 933MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB ..

I have since upgraded to more recent u-boot versions:

U-Boot TPL 2020.07 (Sep 27 2020 - 12:34:15) Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB

U-Boot TPL 2020.10 (Nov 10 2020 - 13:37:45) Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB

The machine was highly instable showing memory and locking issues. When only using two little cores, it was a lot more stable.

I went and also tried:

DDR Version 1.24 20191016 Channel 0: LPDDR3, 933MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB

which seems to match recent u-boot but all of them are different to the original Die BW of 32 which I currently assume to be correct for the Samsung K4E6E304EC-EGCG (so possibly the error also migrated into rokchip-linux/rkbin ?).

Looking at sdram_common.c::sdram_detect_dbw()

300 cs_cap = (1 << (row + col + bk + bw - 20)); 301 if (bw == 2) { 302 if (cs_cap <= 0x2000000) /* 256Mb */ 303 die_bw_0 = (col < 9) ? 2 : 1; 304 else if (cs_cap <= 0x10000000) /* 2Gb */ 305 die_bw_0 = (col < 10) ? 2 : 1; 306 else if (cs_cap <= 0x40000000) /* 8Gb */ 307 die_bw_0 = (col < 11) ? 2 : 1; 308 else 309 die_bw_0 = (col < 12) ? 2 : 1; 310 if (cs > 1) { 311 row = cap_info->cs1_row; 312 cs_cap = (1 << (row + col + bk + bw - 20)); 313 if (cs_cap <= 0x2000000) /* 256Mb */ 314 die_bw_0 = (col < 9) ? 2 : 1; 315 else if (cs_cap <= 0x10000000) /* 2Gb */ 316 die_bw_0 = (col < 10) ? 2 : 1; 317 else if (cs_cap <= 0x40000000) /* 8Gb */ 318 die_bw_0 = (col < 11) ? 2 : 1; 319 else 320 die_bw_0 = (col < 12) ? 2 : 1; 321 } 322 } else {

ca_cap is off by 20 bits compared to the values you are comparing to; in my case 0x400 and not 0x40000000:

type 6 row 15 col 10 bk 3 cs 2 bw 2 cs_cap 8 cs1_row 15 1 << (15 + 10 + 3 + 2 - 20) == 1 << 10 == 0x400

And similar in the 2nd case with cs1_row given cs > 1.

Now I know very little about all the memory chips out there but it seems very unlikely to regain these 20 bits in these calculations. So either the “-20” goes or the cs_cap <= values need adjustment.

The problem now comes from the fact that cap_info->dbw gets the wrong value from die_bw_0 this way and given it is LPDDR3 I assume that set_cap_relate_config() in sdram_rk3399.c later restores the wrong values for the “memdata_ratio”.

There might be more problems lingering, but changing this, my machine got a lot more reliable, though I still see memory errors when I push it to its (temperature) limits running on all 6 cores, even with decent cooling, but that might be a secondary problem.

Can someone with a lot more insight into this magic have a look and if needed please fix it?

/bz