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