<jemk>
ssvb: wow, looks like you did a lot of tpr3 testing
souther has quit [Ping timeout: 258 seconds]
<jemk>
ssvb: the tables are interesting, i would have expected to see much less difference between cubieboard1 and 2
<ssvb>
jemk: yes, it's very interesting if these tpr3 patterns apply to all the devices of the same model or are unique for each unit
deasy has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 245 seconds]
<ssvb>
jemk: cubieboard1 and cubieboard2 are likely using different voltage for the memory controller, and also each chip has its own voltage tolerances
<ssvb>
jemk: I could increase the dcdc3 voltage for the cb2 to see if the green isles will look more like the ones from cb1
<ssvb>
jemk: however the difference in the top left corner is still a bit of a mystery
<jemk>
ssvb: i'll try to set up your scripts and do some tables with my cb1 and ct, but I guess they aren't much different
<ssvb>
jemk: for cubieboard2 and cubietruck I had two independent runs, just to see if the results are deterministic, and it seems like they are
<jemk>
ssvb: but 0x73333 crashed my ct immediately and you have green, so we will see...
rz2k has quit []
<ssvb>
jemk: are you using nfs root? because a huge number of watchdog triggered reboots may probably corrupt the sd card pretty fast
npcomp_ is now known as npcomp
<jemk>
ssvb: yes, i know, already had this problem with cedrus, random physical memory addresses also corrupt sd cards pretty fast
<ssvb>
jemk: btw, u-boot does not set tpr3 correctly on a10, that's a bug to be fixed
<ssvb>
jemk: by the a10-set-tpr3 userspace tool handles this just fine :)
<ssvb>
jemk: we also have a lot of other dram controller configuration knobs in addition to just the bits used in tpr3, that's a vast space to explore
CoSM0 has quit [Ping timeout: 252 seconds]
<ssvb>
jemk: the results from your cb1 and ct would be indeed very interesting, we need to know if the tpr3 pattern is going to remain mostly the same
<ssvb>
jemk: do you need some basic test setup instructions?
<jemk>
ssvb: but most other knobs aren't documented, at least i didn't find them in rk30xx yet
FreezingCold has joined #linux-sunxi
<ssvb>
jemk: the tpr3 covers only MFWDLY and MFBDLY from the command lane and SDPHASE from the byte lanes
<ssvb>
jemk: if I understand it correctly, byte lanes also have MFWDLY and MFBDLY
<ssvb>
jemk: probing the effect of trying to tweak them is also in my todo list
<jemk>
ssvb: you read the ddr phy chapter in rk manual?
<ssvb>
jemk: yes
leviathanch2 has quit [Ping timeout: 240 seconds]
<ssvb>
jemk: I might be wrong, but it seems to me that MDLL used for the command lane is a stripped down version of MSDLL used for the byte lanes
<ssvb>
jemk: just because it only sends data and never receives anything back
<ssvb>
jemk: I believe that byte lane MSDLLs also have the MFWDLY and MFBDLY bits which may have some effect
<ssvb>
jemk: I just did not have time to run some tests with this yet
souther has joined #linux-sunxi
<jemk>
ssvb: i'm still searching for some public information about how ddr3 controllers generally work, how they use the dlls, but it looks like there is none
<ssvb>
jemk: just try to remove this require statement, I think that generators are a pretty standard ruby language feature
<jemk>
ssvb: uninitialized constant Generator
<ssvb>
bummer
<ssvb>
jemk: can you check if you also have some other versions of ruby installed?
<jemk>
Enumerator::Generator seems to work
<jemk>
I don't speak ruby, but it looks like its correct
<ssvb>
yes, that's probably how they do it in the newer versions
<ssvb>
I'll try to check compatibility with different versions of ruby, thanks for bringing this up
<ssvb>
jemk: is it running happily now?
<jemk>
ssvb: yes, already reboots a lot ;)
<ssvb>
jemk: you can also generate html reports for the partially collected data, to preview what's going on :)
<ssvb>
jemk: just wonder what color you got for 0x73333
<jemk>
ssvb: 2/2
<ssvb>
jemk: oh, if it moved to another tpr3 value, then this means that it managed to run lima-memtester with the 8M buffer tow times, and then it deadlocked on the third attempt (out of 5 maximum)
<ssvb>
jemk: what is the dram clock frequency and dcdc3 voltage in this setup?
<jemk>
ssvb: 552MHz at 1.3v, i had running this the whole weekend without problems with 0x72222
<ssvb>
jemk: I think, I generated it for 600mhz and then manually changed dram_clk to 552 when dumping this this stuff into u-boot sources
Skaag has quit [Ping timeout: 250 seconds]
<ssvb>
jemk: don't know if this could have skewed the results, but with the 528mhz output of this calculator my poorly overclockable cubietruck could run stable at 528mhz and dcdc3=1.275v
<ssvb>
jemk: the dram timings are yet another story, as you have earlier written in the mailing list, the current ones in u-boot seem to be rather poorly selected
<jemk>
ssvb: I'm not 100% sure, but i think as long as the timings are long enough they don't influence tpr3 results
<jemk>
ssvb: i currently use the original ones, only clock changed to 552
<ssvb>
jemk: ok, I was just afraid that at higher dram clock frequencies, the original timings might behave poorly
<jemk>
ssvb: no worries, they are for 667MHz
<jemk>
ssvb: on cubieboard1 however it could be a problem, they are for 400mhz
<jemk>
and lime maybe too
<libv>
ssvb/jemk: how about throwing some of that on the wiki?
<jemk>
ssvb: ah, i see you changed them to the cas=9 ones
<ssvb>
jemk: yes, I took care of this :)
<ssvb>
libv: this dram stuff is still highly experimental, and we are using time to run tests and tweak code at the moment
<ssvb>
libv: there are still a lot of obvious things to verify before starting to document it
<ssvb>
libv: but basically, for the a10/a13/a20 dram controller we have the relevant and very useful documentation from rockchip :)
<libv>
well, there are two ways of tackling this, either you use the wiki as a temporary data store, and clean it up later, or... you wait until you have all the information, and then throw in afterwards what you still remember, or no longer can be bothered to document it properly afterwards
<ssvb>
libv: all the knowledge is currently getting translated into the code and scripts
<ssvb>
libv: that's why there is nothing to forget so far :)
<libv>
well, like most things i complain about, wait and see how this pans out.
<ssvb>
btw, does linux-sunxi wiki support colored tables?
<libv>
it's a bit of a faff, but you can use a template to take part of the pain away
<jemk_>
ssvb: no, only this one, which is for the 512mb cubieboard
jemk has quit [Ping timeout: 252 seconds]
jemk_ is now known as jemk
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<ssvb>
jemk: I see, maybe we need to search harder :)
<ssvb>
jemk: as for the memory timings, if we strictly follow dram datasheets, then moving from 528MHz to 552MHz increases a lot of timing parameters from 7 to 8 cycles
<ssvb>
jemk: and CL supposedly needs to jump directly from 7 to 9
<ssvb>
jemk: so the latency is going to suffer, and also the efficiency of memory bandwidth utilization may drop too
<jemk>
ssvb: yeah, the timings are optimized for standard frequencies, so they jump above 533mhz
<ssvb>
jemk: so going beyond 528mhz may be not very practical for us
FR^2 has quit [Quit: Connection reset by peer]
<ssvb>
jemk: it might make sense to primarily target 528mhz, test this extensively and (if everything looks fine) finally go down to 504mhz for normal use
<ssvb>
jemk: but I still need to check if better dram clock speed and timings can fix the hdmi glitches with 1080p monitors, that's a rather major issue to address
<ssvb>
libv: sorry about the wiki, it's just that only now we are starting to get some real information, I spent a lot of time during the last few days just developing and debugging scripts
<ssvb>
libv: now with the test tools available, it hopefully should be an easy ride :)
diego_r has quit [Ping timeout: 252 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
bonbons has joined #linux-sunxi
notmart has quit [Remote host closed the connection]
bertrik has joined #linux-sunxi
bertrik has quit [Changing host]
bertrik has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
nove has joined #linux-sunxi
bbrezillon has quit [Ping timeout: 252 seconds]
deasy has joined #linux-sunxi
notmart has quit [Quit: notmart terminated!]
FreezingCold has quit [Ping timeout: 252 seconds]
wickwire has quit [Ping timeout: 252 seconds]
_massi_ has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
<jemk>
ssvb: we should also try different sdphase for each byte lane, I often get errors like 0x00ff0000 != 0x00000000 and 0xff00ffff != 0xffffffff. That looks like only one byte is too late/early
ZetaNeta has joined #linux-sunxi
F1skr has quit [Quit: WeeChat 0.4.3]
<ssvb>
jemk: right, this sounds reasonable
<jemk>
ssvb: my ct table looks a little bit different (and i need a webserver...) http://sprunge.us/ceIG
<ssvb>
jemk: oh, looks like it can be directly pasted into the linux-sunxi wiki :)
<ssvb>
jemk: I get a reasonably looking preview
rz2k has joined #linux-sunxi
<ZetaNeta>
Anyone know a cheap service where they can replace BGAs?
<ssvb>
jemk: it's good that I did not bother to add the <html>, <head> and other boilerplate tags
<ssvb>
jemk: so you can just take it and copy into some linux-sunxi wiki page without stripping anything unneeded ;)
<ZetaNeta>
A rework service basically
kenny has joined #linux-sunxi
<ssvb>
libv: ^ turns out that wiki is either more clever or more dumb than I expected :)
<libv>
ssvb: wikis are great, but they also never completely and entirely do what you want them to do, such is the nature of such tools
<libv>
ssvb: when i was stuck at a nasty automotive project a while ago, i really learned how important a wiki really is, as i had to battle the "architect" professor with respect to collecting, retaining and distributing knowledge
<libv>
his answer: "one of my students did it, why can't you consultants do it?"
<libv>
"what did he do exactly?" and "ok, so where did he document what he did?" never got a single answer
<ssvb>
libv: I mean the technical part :) it just takes the html formatted table and shows it perfectly, I only wonder if it is sanitizing html in any way against something "malicious"
<libv>
so stuck what i learned into the wiki immediately, and quickly saw this idiots little empire crumble
<libv>
as he no longer was able to play divide and conquer, and our knowledge as a team grew exponentially
<libv>
ssvb: well, if anything malicious was really possible, it would've been exploited by now
<libv>
perhaps it is mostly pure html formatting wrapped a bit more nicely for our typing ease, without completely hiding the innards?
<libv>
anyway, good to know that you are having a just as easy time with the wiki as with the manually formatted page
<ssvb>
libv: btw, the github wiki also shows the table, but strips all the colors (which clearly indicates that they are sanitizing it)
<libv>
right, different wiki implementation then
FreezingCold has quit [Ping timeout: 245 seconds]
rz2k has quit []
t3st3r has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
<ssvb>
jemk: one more interesting test - we can probably configure the dram controller to use only one byte lane and try to find the best settings for it first
byECHO has joined #linux-sunxi
<ssvb>
jemk: at least when I used the dram config from a10-lime on cubieboard1, it worked perfectly fine (with just half of the RAM visible)
<ssvb>
jemk: so we might pretend that we only have a 8-bit memory interface, if this configuration is acceptable
<byECHO>
Hello. I managed to install xorg and lxde. The problem is everything is triying to load lima driver.like "libGL error: failed to load driver: lima" but fbturbo is installed.
<ssvb>
byECHO: it's ok
hramrach has joined #linux-sunxi
t3st3r has quit [Remote host closed the connection]
hramrach has quit [Remote host closed the connection]
<ssvb>
byECHO: don't believe all the scary messages, and actually there should be also a message telling you to ignore this one
t3st3r has joined #linux-sunxi
hramrach has joined #linux-sunxi
<byECHO>
Alright.Is there any method for getting more performance?I have a13 which doesnt have g2d.System is sluggish.
<ssvb>
byECHO: check the cpufreq governor if you have cpufreq enabled
bgal has joined #linux-sunxi
<ssvb>
byECHO: do you have an LCD display? what is the screen resolution?
<byECHO>
tablets own screen. 800x600
<jemk>
ssvb: nice idea, but i don't think bus_width=8 is possible. it could be worth a try however
<libv>
byECHO: what hardware is this?
<jemk>
ssvb: and the watchdog failed, i came back and it hangs...
<ssvb>
jemk: sigh, the watchdog is a tricky thing, I need to look at it again
<byECHO>
Well it is 512mb a13 tablet.
<jemk>
ssvb: only 80mA current, so its in a strange state
<ssvb>
jemk: unless it's a HW problem with watchdog not doing its work properly, then the watchdog code needs to be improved
<jemk>
libv: I can't create a user page in wiki, no permission
nabblet has joined #linux-sunxi
<ssvb>
jemk: basically, we can't trust any variable because it may be corrupted, so if the countdown counter gets corrupted, then we are in a trouble
<libv>
jemk: ok, user id is?
<jemk>
libv: Jemk
<libv>
jemk: fixed
<jemk>
libv: thx
<libv>
byECHO: we do not have a single documented tablet which has 800x600
boycottg00gle has joined #linux-sunxi
<byECHO>
Well,screen res is 800x600 not screen itself
<libv>
byECHO: what u-boot target and what sunxi-boards .fex file did you use?
<byECHO>
I used a13-mid
<libv>
byECHO: why did you pick that one?
<ssvb>
jemk: I have already added some checks, trying to prevent a broken client application asking to set an astronomical value as a timeout value, but this is only scratches the surface
<byECHO>
there was an app in android which gives hardware information.It gave me it.
<libv>
byECHO: so your android device id read a13-mid?
<byECHO>
yeah
<libv>
byECHO: then we definitely need you to document your device
<libv>
byECHO: are you using all of the screen with the sunxi-boards .fex?
<byECHO>
Brand actually brought SoC from china and make tablet and write their name on it
<byECHO>
yes
<byECHO>
all of it
<libv>
then it is 800x480 :)
<byECHO>
well sorry for misunderstood
<libv>
byECHO: get it documented, please, this really helps our community out, and will help people who just randomly look for their hw on the web out as well
netlynx has quit [Quit: Leaving]
<libv>
byECHO: you have installed to an sd-card, right?
<byECHO>
Will I will try.I will look into tomorrow.
<libv>
you still have the original android on the nand?
<byECHO>
yes I have
<libv>
fantastic, then the android identification strings will be valid still