On 28/03/14 13:29, Olliver Schinagl wrote: > On 03/28/2014 11:42 AM, Siarhei Siamashka wrote: >> On Thu, 27 Mar 2014 16:26:02 +0100 >> Hans de Goede <hdego...@redhat.com> wrote: >> >>> Hi, >>> >>> Thanks for the patches. I've merged and pushed the 1st one. >>> >>> The 2nd one esp. is a good find and a nice cleanup. >>> >>> It also seems to explain why we were getting various reports about >>> instability on the cubieboard2, which ships with a dram clock of 480 >>> where as it seems to be stable at 432, which exactly matches the >>> threshold above which you say the timings become wrong. >>> >>> As Olliver already indicated we would like to do some more tests with >>> the 2nd patch first, but eventually we definitely will want to merge >>> it (assuming the testing goes well). >>> >>> I'm thinking that this means that we may be able to safely bump the dram >>> clock on the cubietruck to 480, any opinion on this ? >> >> I have a Cubietruck, which can successfully boot to a login prompt >> with dram clocked at 504MHz. And a Cubieboard2, which can also boot >> to a login prompt with dram clocked at 552MHz respectively. >> >> However it does not mean that these devices are going to really work >> stable in these configurations. I have tried different tests and >> workloads during the last year or so. And it appears that competing >> memory accesses from both ARM CPU and Mali GPU tend to cause problems >> at the memory clock speeds, which are otherwise stable for CPU-only >> workloads. >> >> I understand that setting up binary drivers and then running some 3D >> accelerated applications while checking for memory corruption bugs at >> the same time is not something that many people would enjoy (or even try >> in the first place). And I had plans to try to simplify the test setup >> since a long time ago. Finally here it is: >> >> https://github.com/ssvb/lima-memtester >> >> Basically, that's just a single static binary with no dependencies. >> It combines a memtester tool with a simple spinning textured cube >> demo from the work-in-progress free open source Mali400 driver >> project http://limadriver.org/
Nice tool, I already used memtester but didn't bother to load the GPU. > That's amazing, we should prep a rootfs with all of that in it maybe > too? setting up lima + mali + god knows what may be a bit too much for > some right now, so having a pre-defined test rootfs might proove usefull... >> >> It would be 100% free software using only free software tools if the >> open source lima shader compiler could handle vertex shaders. Right now >> only the fragment shader binary had been generated using the open >> source shader compiler. But the vertex shader binary (injected as an >> array into the source code) still used the output of the proprietary >> shader compiler from the libMali.so blob. >> >> Anyway, my Cubietruck passes the test at 456MHz dram clock speed and >> fails at 480MHz. And my Cubieboard2 passes it at 504MHz but fails >> at 528MHz. The second patch from Jens Kuske unfortunately does not >> seem to have any visible effect here and does not change anything >> for me. Looks like my cubietruck is a bad test device, it successfully run memtester at 504MHz for 24h and also lima-memtester runs good till now (two loops finished ok). > That's unfortunate, I slightly hoped that the proper timings would > result in better performance. > I didn't want to stir up too much hope for faster memory, only wanted to mention the possibility. There are many other dram timing parameters that depend on things like clock speed but don't get calculated anywhere. They must be somewhere in .tpr[0-2] and therefore fixed at some (hopefully big enough) value. The tRFC was fixed for 400MHz, so with some bad luck the other parameters are also dimensioned for 400MHz. > But all hope is not yet lost, maybe on badly designed boards > (tablets/mele) it does work better with the right timings. The refresh timings aren't influenced much by board characteristics as far as I know, it's a DRAM chip internal thing. It could help to stay stable at higher temperature or for bad quality DRAM chips. Jens -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.