OrangePI Zero3 memory timing testing

[Stephen Graf]

Some testing results:

With the default DRAM timing of 30x24=720, most often when my system 
boots it comes up with DRAM 2G, but I have a 1G system. Once in a while 
the boot shows 1G.  When it shows 2G the linux OS also shows 2G and 
continuing does not make much sense.

On one boot where u-boot reported 1G the OS agreed and I ran memtester 
successfully.

If I build u-boot with CONFIG_DRAM_CLK=792 (33*24=792) I have never seen 
my system boot with anything other than DRAM 1G showing in u-boot. I ran 
memtester successfully and this system has been stable running linux 6.6.2.

Andre, if you can put together a few patches I can test them to see 
which works.

If anyone else with different variations of the Zero3 would test with 
the two DRAM timings and report results.

I also use the Zunlong image on occasion and it consistently shows 1G 
and from my poking around I think it runs at a 792 clk.


Console output with DRAM default:

U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  2 GiB

Last login: Wed Nov 29 09:35:15 PST 2023 on ttyS0
root at orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           1.9Gi       139Mi       1.7Gi       360Ki        82Mi 
   1.7Gi
Swap:             0B          0B          0B


U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB

root at orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           917Mi       137Mi       766Mi       360Ki        79Mi 
   780Mi
Swap:             0B          0B          0B


root at orangepizero3:~# memtester 700M 1
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 700MB (734003200 bytes)
got  700MB (734003200 bytes), trying mlock ...locked.
Loop 1/1:
   Stuck Address       : ok
   Random Value        : ok
   Compare XOR         : ok
   Compare SUB         : ok
   Compare MUL         : ok
   Compare DIV         : ok
   Compare OR          : ok
   Compare AND         : ok
   Sequential Increment: ok
   Solid Bits          : ok
   Block Sequential    : ok
   Checkerboard        : ok
   Bit Spread          : ok
   Bit Flip            : ok
   Walking Ones        : ok
   Walking Zeroes      : ok
   8-bit Writes        : ok
   16-bit Writes       : ok

Done.

Console output with DRAM clk 792:


U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 21:34:46 
-0800) Allwinner Technology

CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB

root at orangepizero3:~# free -h
                total        used        free      shared  buff/cache 
available
Mem:           917Mi       134Mi       768Mi       360Ki        79Mi 
   782Mi
Swap:             0B          0B          0B


root at orangepizero3:~# memtester 700M 1
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 700MB (734003200 bytes)
got  700MB (734003200 bytes), trying mlock ...locked.
Loop 1/1:
   Stuck Address       : ok
   Random Value        : ok
   Compare XOR         : ok
   Compare SUB         : ok
   Compare MUL         : ok
   Compare DIV         : ok
   Compare OR          : ok
   Compare AND         : ok
   Sequential Increment: ok
   Solid Bits          : ok
   Block Sequential    : ok
   Checkerboard        : ok
   Bit Spread          : ok
   Bit Flip            : ok
   Walking Ones        : ok
   Walking Zeroes      : ok
   8-bit Writes        : ok
   16-bit Writes       : ok

Done.


On 2023-11-27 5:37 p.m., Andre Przywara wrote:

> 
> This symptom is pretty surely not directly related to the DRAM
> frequency, it's caused by a missing barrier or delay *somewhere*.
> People report that this is fixed by adding another "dsb();" at the
> beginning of the mctl_mem_matches() function, but I don't have a good
> explanation why exactly there, and would like to avoid submitting
> patches that "just seem to work (TM)".
> 
> If I find some time, I will try to setup some automated environment
> where I can run some experiments with different barrier locations.
> I can offer some rationale for putting it at the end of the function(s)
> that call mctl_mem_matches(), so hope that this fixes it.
> 
> Cheers,
> Andre
>