OrangePI Zero3 memory timing testing
Siarhei Siamashka
siarhei.siamashka at gmail.com
Thu Nov 30 02:15:41 CET 2023
Hello,
Please try to insert udelay() calls in addition to dsb() in the
mctl_mem_matches()
and see if this helps. I suspect that there's just no way to do
perfectly reliable
synchronization all the way from the CPU to DRAM and back in this particular
scenario (which involves wacky things, such as accessing aliased physical
memory addresses). So just having a generous delay may do the job and
solve all the timing issues.
Another comment is about the use of memtester program. It's actually not very
sensitive to memory reliability problems as-is.
Back in A10/A20 and H3 days, it was necessary to run memtester simultaneously
with a Mali GPU rendered spinning textured cube animation for best results:
https://github.com/ssvb/lima-memtester
For example, a misconfigured H3 DRAM was showing no problems at all in
the memtester test at 624MHz, but couldn't survive memtester together with
the spinning textured cube until downclocked to 384MHz. Only aggressive
simultaneous access from both CPU and GPU really exposes reliability
problems. The other types of DMA transfers couldn't replace the GPU. It
was also possible to use the G2D accelerator instead of the Mali GPU, but
only when performing 90 degrees rotations. Doing simple non-rotated blits
with G2D was useless and couldn't expose reliability problems.
I would suggest to install 3D drivers (whatever is available for the
modern kernels
nowadays) and run some textured spinning cube demo together with memtester
before deciding that your DRAM configuration is alright.
On Thu, Nov 30, 2023 at 2:11 AM Andre Przywara <andre.przywara at arm.com> wrote:
>
> 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 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
> >>
More information about the U-Boot
mailing list