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@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@orangepizero3:~# free -h
total used free shared buff/cache
available
Mem: 917Mi 137Mi 766Mi 360Ki 79Mi
780Mi
Swap: 0B 0B 0B
root@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@orangepizero3:~# free -h
total used free shared buff/cache
available
Mem: 917Mi 134Mi 768Mi 360Ki 79Mi
782Mi
Swap: 0B 0B 0B
root@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
