Hi Stephen,
On 29/11/2023 18:45, Stephen Graf wrote:
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
Interesting, many thanks for the elaborate experiments! To be fair, the timing parameters were from Xunlong's setup, so with 792 MHz, but I remember that in my early testing this failed more often than not, so I reverted back to 720MHz. But I had different parameters back then, I believe. I will try to arrange some boot loop, to see how it fares with the 792 MHz, though I believe you that it's more stable. If that works, I will send a v2 with the USB and the DRAM clock fixed.
Thanks again for testing and the report!
Cheers, Andre
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