Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-04-15 Thread Clement Wong
Looks exciting!! Especially for us who use full HD!
Hope we'll be able to test something soon. :)

Clement

On Apr 6, 2014, at 12:43 PM, Siarhei Siamashka  
wrote:

> On Sat, 05 Apr 2014 17:58:11 +0200
> Jens Kuske  wrote:
> 
>> On 03/04/14 07:49, Siarhei Siamashka wrote:
>>> 
>>> I would guess that the .tpr settings, bundled with .cas=6, are likely
>>> assuming 400MHz memory clock speed. Which also agrees with the tRFC
>>> hardcoded values as you mentioned above. And also with the A10
>>> and A20 user manuals, which specify 0~400MHz range for SDRAM_clk.
>>> 
>>> The .cas=9 style sets of timings are likely very conservative and
>>> assuming memory clock speeds up to 667MHz if we take the cas value
>>> as a hint. If we are running dram at around 480MHz, these settings
>>> may unnecessarily sacrifice some performance.
>> 
>> I found some documentation for TPR registers in the rk30xx manual from
>> radxa. Their dram controller is pretty much different, but comparing the
>> default values and settable bits of the TPR registers makes it likely
>> that at least these registers have nearly the same bitfields.
>> 
>> This makes the .cas=6 set look like:
>> tMRD = 2, tRTP = 4, tWTR = 4, tRP = 6, tRCD = 6,
>> tRAS = 18, tRRD = 4, tRC = 24, tCCD = 0
>> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
>> tXS = 200, tXP = 8, tCKE = 3
>> 
>> Assuming this is valid, we can do some trail and error again and try to
>> figure out the original timings.
>> 
>> As it turns out, your guess was pretty good. The settings *exactly*
>> match DDR2(!)-800E speed bin at 400MHz. Its DDR2 again, as with tRFC.
>> Interesting part is, if we assume DDR3-1333H chips (as on cubieboard)
>> many parameters are still in spec up to 480MHz (not all however, tFAW,
>> tXS and what else I missed not).
>> 
>> And for the .cas=9 set, most settings match DDR3-1333H speed bin at
>> 667MHz. But some settings, like tFAW and tXP are too low,
>> they only fit for ~420MHz.
>> 
>> tMRD = 3, tRTP = 5, tWTR = 5, tRP = 9, tRCD = 9,
>> tRAS = 24, tRRD = 6, tRC = 33, tCCD = 0
>> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
>> tXS = 512, tXP = 10, tCKE = 4
> 
> That's a very nice catch. Thanks! Looks like this is a stepping stone
> in the memory controller reverse engineering.
> 
> However things would have been surely much easier if all of this was
> properly documented by Allwinner.
> 
>> I tried to calculate the correct parameters for 480MHz on cubietruck,
>> and currently lima-memtester is running without any errors till now. I
>> first accidentally kept the clock at 432MHz and only changed the tprs,
>> and even that gave a ~150MB/s boost at tinymembench compared to the
>> original values.
>> This is highly experimental, but if somebody wants to try (only
>> cubietruck, other dram chips need different timings):
>> .clock = 480
>> .cas = 7
>> .tpr0 = 0x30b27790
>> .tpr1 = 0xa078
>> .tpr2 = 0x0001b200
>> 
>> These timings are calculated by hand, but maybe this could lead to some
>> program or even function in u-boot that calculates matching parameters
>> for given dram chip type and speed.
> 
> Well, not a big surprise, but my "lucky" Cubietruck fails
> lima-memtester tests with these settings too:
> 
> Kernel driver is version 14
> Detected 1 Mali-400 GP Cores.
> Detected 2 Mali-400 PP Cores.
> FB: 1280x720@32bpp at 0x51001000 (0x00A8C000)
> Using dual buffered direct rendering to FB.
> 
> memtester version 4.3.0 (32-bit)
> Copyright (C) 2001-2012 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
> 
> pagesize is 4096
> pagesizemask is 0xf000
> want 300MB (314572800 bytes)
> got  300MB (314572800 bytes), trying mlock ...locked.
> Loop 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: testing 221FAILURE: 0xf7ff != 0xf700 at offset 
> 0x03e041fc.
> FAILURE: 0x0800 != 0x080c at offset 0x03e04200.
> FAILURE: 0xf7ff != 0xf706 at offset 0x03e04204.
>  Walking Ones: ok 
>  Walking Zeroes  : ok 
> 
> Loop 2:
>  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: testing 213FAILURE: 0xfbff != 0xfb00 at offset 
> 0x038051bc.
> FAILURE: 0x0400 != 0x04ff at offset 0x038051c0.
> FAILURE: 0xfbf

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-04-06 Thread Siarhei Siamashka
On Sat, 05 Apr 2014 17:58:11 +0200
Jens Kuske  wrote:

> On 03/04/14 07:49, Siarhei Siamashka wrote:
> >
> > I would guess that the .tpr settings, bundled with .cas=6, are likely
> > assuming 400MHz memory clock speed. Which also agrees with the tRFC
> > hardcoded values as you mentioned above. And also with the A10
> > and A20 user manuals, which specify 0~400MHz range for SDRAM_clk.
> >
> > The .cas=9 style sets of timings are likely very conservative and
> > assuming memory clock speeds up to 667MHz if we take the cas value
> > as a hint. If we are running dram at around 480MHz, these settings
> > may unnecessarily sacrifice some performance.
> 
> I found some documentation for TPR registers in the rk30xx manual from
> radxa. Their dram controller is pretty much different, but comparing the
> default values and settable bits of the TPR registers makes it likely
> that at least these registers have nearly the same bitfields.
> 
> This makes the .cas=6 set look like:
> tMRD = 2, tRTP = 4, tWTR = 4, tRP = 6, tRCD = 6,
> tRAS = 18, tRRD = 4, tRC = 24, tCCD = 0
> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
> tXS = 200, tXP = 8, tCKE = 3
> 
> Assuming this is valid, we can do some trail and error again and try to
> figure out the original timings.
> 
> As it turns out, your guess was pretty good. The settings *exactly*
> match DDR2(!)-800E speed bin at 400MHz. Its DDR2 again, as with tRFC.
> Interesting part is, if we assume DDR3-1333H chips (as on cubieboard)
> many parameters are still in spec up to 480MHz (not all however, tFAW,
> tXS and what else I missed not).
> 
> And for the .cas=9 set, most settings match DDR3-1333H speed bin at
> 667MHz. But some settings, like tFAW and tXP are too low,
> they only fit for ~420MHz.
> 
> tMRD = 3, tRTP = 5, tWTR = 5, tRP = 9, tRCD = 9,
> tRAS = 24, tRRD = 6, tRC = 33, tCCD = 0
> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
> tXS = 512, tXP = 10, tCKE = 4

That's a very nice catch. Thanks! Looks like this is a stepping stone
in the memory controller reverse engineering.

However things would have been surely much easier if all of this was
properly documented by Allwinner.

> I tried to calculate the correct parameters for 480MHz on cubietruck,
> and currently lima-memtester is running without any errors till now. I
> first accidentally kept the clock at 432MHz and only changed the tprs,
> and even that gave a ~150MB/s boost at tinymembench compared to the
> original values.
> This is highly experimental, but if somebody wants to try (only
> cubietruck, other dram chips need different timings):
> .clock = 480
> .cas = 7
> .tpr0 = 0x30b27790
> .tpr1 = 0xa078
> .tpr2 = 0x0001b200
> 
> These timings are calculated by hand, but maybe this could lead to some
> program or even function in u-boot that calculates matching parameters
> for given dram chip type and speed.

Well, not a big surprise, but my "lucky" Cubietruck fails
lima-memtester tests with these settings too:

Kernel driver is version 14
Detected 1 Mali-400 GP Cores.
Detected 2 Mali-400 PP Cores.
FB: 1280x720@32bpp at 0x51001000 (0x00A8C000)
Using dual buffered direct rendering to FB.

memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xf000
want 300MB (314572800 bytes)
got  300MB (314572800 bytes), trying mlock ...locked.
Loop 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: testing 221FAILURE: 0xf7ff != 0xf700 at offset 
0x03e041fc.
FAILURE: 0x0800 != 0x080c at offset 0x03e04200.
FAILURE: 0xf7ff != 0xf706 at offset 0x03e04204.
  Walking Ones: ok 
  Walking Zeroes  : ok 

Loop 2:
  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: testing 213FAILURE: 0xfbff != 0xfb00 at offset 
0x038051bc.
FAILURE: 0x0400 != 0x04ff at offset 0x038051c0.
FAILURE: 0xfbff != 0xfb00 at offset 0x038051c4.
FAILURE: 0x0400 != 0x04ff at offset 0x038051c8.
FAILURE: 0xfbff != 0xfb00 at offset 0x038051cc.
FAILURE: 0x0400 != 0x04ff at offset 0x038051d0.
FAILURE: 0xfbff != 0xfb00 at offset 0x038051d4.
FAILURE: 0x0400 != 0x04ff at offset 0x03805

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-04-05 Thread Jens Kuske
On 03/04/14 07:49, Siarhei Siamashka wrote:
>
> I would guess that the .tpr settings, bundled with .cas=6, are likely
> assuming 400MHz memory clock speed. Which also agrees with the tRFC
> hardcoded values as you mentioned above. And also with the A10
> and A20 user manuals, which specify 0~400MHz range for SDRAM_clk.
>
> The .cas=9 style sets of timings are likely very conservative and
> assuming memory clock speeds up to 667MHz if we take the cas value
> as a hint. If we are running dram at around 480MHz, these settings
> may unnecessarily sacrifice some performance.

I found some documentation for TPR registers in the rk30xx manual from
radxa. Their dram controller is pretty much different, but comparing the
default values and settable bits of the TPR registers makes it likely
that at least these registers have nearly the same bitfields.

This makes the .cas=6 set look like:
tMRD = 2, tRTP = 4, tWTR = 4, tRP = 6, tRCD = 6,
tRAS = 18, tRRD = 4, tRC = 24, tCCD = 0
tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
tXS = 200, tXP = 8, tCKE = 3

Assuming this is valid, we can do some trail and error again and try to
figure out the original timings.

As it turns out, your guess was pretty good. The settings *exactly*
match DDR2(!)-800E speed bin at 400MHz. Its DDR2 again, as with tRFC.
Interesting part is, if we assume DDR3-1333H chips (as on cubieboard)
many parameters are still in spec up to 480MHz (not all however, tFAW,
tXS and what else I missed not).

And for the .cas=9 set, most settings match DDR3-1333H speed bin at
667MHz. But some settings, like tFAW and tXP are too low,
they only fit for ~420MHz.

tMRD = 3, tRTP = 5, tWTR = 5, tRP = 9, tRCD = 9,
tRAS = 24, tRRD = 6, tRC = 33, tCCD = 0
tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
tXS = 512, tXP = 10, tCKE = 4

I tried to calculate the correct parameters for 480MHz on cubietruck,
and currently lima-memtester is running without any errors till now. I
first accidentally kept the clock at 432MHz and only changed the tprs,
and even that gave a ~150MB/s boost at tinymembench compared to the
original values.
This is highly experimental, but if somebody wants to try (only
cubietruck, other dram chips need different timings):
.clock = 480
.cas = 7
.tpr0 = 0x30b27790
.tpr1 = 0xa078
.tpr2 = 0x0001b200

These timings are calculated by hand, but maybe this could lead to some
program or even function in u-boot that calculates matching parameters
for given dram chip type and speed.

Last warning, all numbers were juggled around many times and I did never
check them again, so they could easily be wrong. But the overall idea
should be correct.

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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-04-02 Thread Siarhei Siamashka
On Fri, 28 Mar 2014 14:21:33 +0100
Jens Kuske  wrote:

> > On 03/28/2014 11:42 AM, Siarhei Siamashka wrote:
> >>  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.
> 
> >> 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.

BTW, I did not mean that the tRFC patch is bad or anything. Just that
no impact is observable on my hardware.

Now I also have some data ready for the dcdc3 voltage tweaks as
discussed on IRC a few days ago:
http://irclog.whitequark.org/linux-sunxi/2014-04-01#6986335;

Your observation about the dcdc3 voltage being set wrong was really
spot on! Kudos for the multimeter based debugging :-)

And dcdc3 really affects the maximum stable memory clock speed ("stable"
in terms of passing the lima-memtester tests). Though changing it to
1.3v (as needed for MBUS) was not really enough to get clearly distinct
results, so I pushed it even further to 1.35v. The A20 datasheet
does not seem to be providing the valid voltage range for VDD-DLL:

https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A20-PDFs/A20%20Datasheet%20v1.0%2020130227.pdf?raw=true
But I optimistically assumed that up to 1.4v might be fine.

Anyway, with dcdc3 voltage set to 1.35v, I could run lima-memtester
successfully for many hours on my Cubieboard2 with dram clock set
to 528MHz. That's at least 24MHz more than was previously possible
with dcdc3 set to 1.25v

The Cubietruck is a bit different story. In general, when running
lima-memtester, the following outcomes are possible:
  a) it runs infinitely or until terminated by the user (success)
  b) the device deadlocks (an obvious fail)
  c) the memtester log starts showing errors (a fail too)

With dcdc3 originally set to 1.25v on my Cubietruck, lima-memtester
fails pretty fast (typically in less than 15 minutes) and most of the
failures are the device deadlocks. With dcdc3 increased to 1.35v,
lima-memtester still fails, but takes much longer and the failures are
reported as memtester errors in the log. Again, testing both with and
without the tRFC patch in u-boot does not seem to change anything.

I have the following preliminary theory. It looks like the deadlocks
and memtester log errors are the symptoms of two (or more?) distinct
problems.

The deadlocks seem to be caused by insufficient dcdc3 voltage, and some
percentage of A20 chips may be really sensitive to low dcdc3. I wonder
if that's the primary cause of the 480MHz dram clock stability problems
on some small percentage of Cubieboard2 devices?
http://irclog.whitequark.org/linux-sunxi/2013-07-29#4520613;

And the regular memtester errors with 1.35v dcdc3 are probably
indicating that the traces to DDR3 are not so good on the Cubietruck
PCB. Or the timings are too tight for one of the unlucky DDR3 chips in
my Cubietruck. Either way, this is probably not dcdc3 voltage related.
And not tRFC related either.

I'll keep running tests and will provide an update if something new
gets discovered.

> 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).

You have an unusual definition of "bad" ;-)

I'm not very happy having Cubietruck with slow dram, because being lower
than the sunxi-typical 480MHz dram speed may affect the credibility
of benchmark results. But using Cubietruck instead of Cubieboard2 is
important when testing for bus address calculation bugs on systems
with 2GiB of RAM.

I myself would prefer to have it the other way around. A Cubieboard,
which can reliably clock dram at 480MHz. And a Cubieboard2, which can't.

> 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 dimensi

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Ian Campbell
On Sun, 2014-03-30 at 20:39 +0300, Siarhei Siamashka wrote:
> Yes, right now it needs sunxi-3.4 kernel, which is a bit more feature
> complete at the moment. That's a good point, appears that readme.txt
> also needs to be improved for more clarity.

While you are there it took me a few seconds to work out which binary I
should run once I'd run the build script.

Ian.


-- 
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Siarhei Siamashka
On Sun, 30 Mar 2014 13:13:29 +0100
Ian Campbell  wrote:

> On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote:
> > https://github.com/ssvb/lima-memtester
> 
> I needed the following to get it to build on my Debian rootfs.

Thanks for the fix, pushed to github.

> (and it turns out I can't run it anyway since I'm running a mainline
> kernel and haven't figured out mali.ko yet, for another time I think)

Yes, right now it needs sunxi-3.4 kernel, which is a bit more feature
complete at the moment. That's a good point, appears that readme.txt
also needs to be improved for more clarity.

In the mainline kernel we first need a display driver (sunxi-kms?),
which would provide emulation of the linux framebuffer interface among
other things. And then, I guess, the mali400 kernel driver could
be used with a bit of adaptation.

> -8<---
> 
> From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Sun, 30 Mar 2014 13:09:55 +0100
> Subject: [PATCH] Remove bashisms from scripts
> 
> [ "a" == "b" ] is a bashism, the portable alternative is [ "a" = "b" ].
> 
> Fixes the following issue on Debian where /bin/sh == dash:
> 
> # ./build-lima-memtester-static-binary.sh
> ./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator
> ./build-lima-memtester-static-binary.sh: 11: 
> ./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found
> 
> The alternative would be to explicitly use #!/bin/bash in the script but since
> the fix is trivial we might as well make it.
> 
> Signed-off-by: Ian Campbell 
> ---
>  build-lima-memtester-static-binary.sh | 2 +-
>  build-textured-cube-static-binary.sh  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/build-lima-memtester-static-binary.sh 
> b/build-lima-memtester-static-binary.sh
> index e84e51b..d253cbb 100755
> --- a/build-lima-memtester-static-binary.sh
> +++ b/build-lima-memtester-static-binary.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>  
> -if [ x$CC == "x" ]
> +if [ x$CC = "x" ]
>  then
>  echo Note: using 'gcc' as a compiler. But it is possible to do something
>  echo like \'export CC=foobar\' to override this.
> diff --git a/build-textured-cube-static-binary.sh 
> b/build-textured-cube-static-binary.sh
> index 61f3e95..cc9f5d0 100755
> --- a/build-textured-cube-static-binary.sh
> +++ b/build-textured-cube-static-binary.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>  
> -if [ x$CC == "x" ]
> +if [ x$CC = "x" ]
>  then
>  echo Note: using 'gcc' as a compiler. But it is possible to do something
>  echo like \'export CC=foobar\' to override this.

-- 
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Ian Campbell
On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote:
> https://github.com/ssvb/lima-memtester

I needed the following to get it to build on my Debian rootfs.

(and it turns out I can't run it anyway since I'm running a mainline
kernel and haven't figured out mali.ko yet, for another time I think)

-8<---

>From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Sun, 30 Mar 2014 13:09:55 +0100
Subject: [PATCH] Remove bashisms from scripts

[ "a" == "b" ] is a bashism, the portable alternative is [ "a" = "b" ].

Fixes the following issue on Debian where /bin/sh == dash:

# ./build-lima-memtester-static-binary.sh
./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator
./build-lima-memtester-static-binary.sh: 11: 
./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found

The alternative would be to explicitly use #!/bin/bash in the script but since
the fix is trivial we might as well make it.

Signed-off-by: Ian Campbell 
---
 build-lima-memtester-static-binary.sh | 2 +-
 build-textured-cube-static-binary.sh  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-lima-memtester-static-binary.sh 
b/build-lima-memtester-static-binary.sh
index e84e51b..d253cbb 100755
--- a/build-lima-memtester-static-binary.sh
+++ b/build-lima-memtester-static-binary.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-if [ x$CC == "x" ]
+if [ x$CC = "x" ]
 then
 echo Note: using 'gcc' as a compiler. But it is possible to do something
 echo like \'export CC=foobar\' to override this.
diff --git a/build-textured-cube-static-binary.sh 
b/build-textured-cube-static-binary.sh
index 61f3e95..cc9f5d0 100755
--- a/build-textured-cube-static-binary.sh
+++ b/build-textured-cube-static-binary.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-if [ x$CC == "x" ]
+if [ x$CC = "x" ]
 then
 echo Note: using 'gcc' as a compiler. But it is possible to do something
 echo like \'export CC=foobar\' to override this.
-- 
1.9.0



-- 
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-29 Thread Siarhei Siamashka
On Fri, 28 Mar 2014 13:29:17 +0100
Olliver Schinagl  wrote:

> On 03/28/2014 11:42 AM, Siarhei Siamashka wrote:
> > 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/
>
> 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...

Nah :) The whole point of doing this exercise was exactly that now:

1. The only runtime dependency of this lima-memtester tool is just a
   linux kernel with a mali kernel module. The users of linux-sunxi
   defconfigs already have it enabled. Even if some users have disabled
   mali support in their kernels, they are expected to have enough
   skills to enable it back.

2. The only build dependency is just a GCC compiler. And lazy or
   inexperienced users can even skip this step and download a static
   binary.

The choice of rootfs or distro should not matter at all. Just like
with a10-meminfo-static, you run this program and it gets the job
done without extra efforts and time consuming preparations.

The users get a basic smoke test for the 3D hardware (even if they
don't give rats about 3D support in general). And in the case if the
test fails, they will know that the dram clock/timings are likely not
good for their hardware.

By the way, this does not bring anything new to the table with regard
to mali400 gpu support. I'm using almost a year old public limadriver
snapshot. The only purpose for it here is to make mali400 hardware do
memory reads and writes for extra pressure on the memory controller.

-- 
Best regards,
Siarhei Siamashka

-- 
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-28 Thread Olliver Schinagl

On 03/28/2014 02:21 PM, Jens Kuske wrote:

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  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.


Where did you learn all this DRAM knowledege! You keep supprising me ;)

I'd almost make you do all of the dram cleanup stuff.

Good going Jens!

Olliver


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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-28 Thread Jens Kuske
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  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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-28 Thread Olliver Schinagl

On 03/28/2014 11:42 AM, Siarhei Siamashka wrote:

On Thu, 27 Mar 2014 16:26:02 +0100
Hans de Goede  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/
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.
That's unfortunate, I slightly hoped that the proper timings would 
result in better performance.


But all hope is not yet lost, maybe on badly designed boards 
(tablets/mele) it does work better with the right timings.


More test results using different hardware are welcome.


Olliver

--
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-28 Thread Siarhei Siamashka
On Thu, 27 Mar 2014 16:26:02 +0100
Hans de Goede  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/

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.

More test results using different hardware are welcome.

-- 
Best regards,
Siarhei Siamashka

-- 
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.


Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-27 Thread Hans de Goede
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 ?

Regards,

Hans


On 03/26/2014 05:40 PM, Jens Kuske wrote:
> I tried to start cleaning up the u-boot DRAM setup code for sunxi and
> found a bug(?) that *could* be responsible for the low possible memory
> frequencies on some boards like cubietruck.
> 
> The patches don't raise any memory frequencies, but they could make it
> possible to raise them. My cubietruck runs with 504MHz dram clock since
> 24 hours, without any problems. But it also does this without the
> patches, so this is no proof.
> 
> I don't think these changes can break something, nonetheless they need
> extensive testing on different boards.
> 
> The first patch changes cubietruck dram parameters to provide correct
> data for the second patch. I don't know what was the reason to set them
> this way, but I didn't find any problems when setting them to the
> technically correct values.
> 
> The second patch does the real work. It is based on guesses, but
> they fit very well, so I think they are the truth.
> I don't know if this really was responsible for the low frequency or
> any other memory problems, but it was obviously wrong, as explained in
> the commit message.
> 
> What do you think?
> I'll try to continue clean up, but to not break anything I believe it
> is better to do it in really small steps.
> 
> 
> 
> Jens Kuske (2):
>   sunxi: dram: Adjust cubietruck dram chip width and density
>   sunxi: dram: Fix autorefresh timing setup
> 
>  arch/arm/cpu/armv7/sunxi/dram.c| 70 
> --
>  arch/arm/include/asm/arch-sunxi/dram.h |  4 ++
>  board/sunxi/dram_cubietruck.c  |  4 +-
>  3 files changed, 30 insertions(+), 48 deletions(-)
> 

-- 
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.


[linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-26 Thread Jens Kuske
I tried to start cleaning up the u-boot DRAM setup code for sunxi and
found a bug(?) that *could* be responsible for the low possible memory
frequencies on some boards like cubietruck.

The patches don't raise any memory frequencies, but they could make it
possible to raise them. My cubietruck runs with 504MHz dram clock since
24 hours, without any problems. But it also does this without the
patches, so this is no proof.

I don't think these changes can break something, nonetheless they need
extensive testing on different boards.

The first patch changes cubietruck dram parameters to provide correct
data for the second patch. I don't know what was the reason to set them
this way, but I didn't find any problems when setting them to the
technically correct values.

The second patch does the real work. It is based on guesses, but
they fit very well, so I think they are the truth.
I don't know if this really was responsible for the low frequency or
any other memory problems, but it was obviously wrong, as explained in
the commit message.

What do you think?
I'll try to continue clean up, but to not break anything I believe it
is better to do it in really small steps.



Jens Kuske (2):
  sunxi: dram: Adjust cubietruck dram chip width and density
  sunxi: dram: Fix autorefresh timing setup

 arch/arm/cpu/armv7/sunxi/dram.c| 70 --
 arch/arm/include/asm/arch-sunxi/dram.h |  4 ++
 board/sunxi/dram_cubietruck.c  |  4 +-
 3 files changed, 30 insertions(+), 48 deletions(-)

-- 
1.9.1

-- 
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.