Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
indy has quit [Ping timeout: 240 seconds]
indy has joined #linux-sunxi
maksimlin has quit [Remote host closed the connection]
physis has quit [Remote host closed the connection]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
egbert has quit [Ping timeout: 276 seconds]
egbert has joined #linux-sunxi
<wens> 3.15-rc1!
seere_ has joined #linux-sunxi
seere has quit [Ping timeout: 258 seconds]
physis has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
geecko has quit [Remote host closed the connection]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
smotocel69 has joined #linux-sunxi
smotocel69 has quit [Client Quit]
t3st3r has quit [Remote host closed the connection]
hramrach has quit [Remote host closed the connection]
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-sunxi
maksimlin has joined #linux-sunxi
<Turl> wens: time to rebase all the things :)
<wens> :)
JohnDoe_71Rus has joined #linux-sunxi
<Turl> wens: is usb supposed to work on 3.15? it doesn't for me on CT
<wens> Turl: otg? no
<wens> usb hosts should work
<wens> but you'll have to ask hans
<Turl> wens: yeah, hosts
<Turl> pins look alright, but it doesn't seem to give devices any power
<Turl> my usb stick doesn't turn on
<wens> check the regulators?
<Turl> they look alright, judging by the log
<Turl> and the pins match the fex
<Turl> it doesn't work on sunxi-devel either, interesting
<wens> hmm, mine works, but not sure which sunxi-devel version I have on it now
<Turl> yay works now
<Turl> Bus 001 Device 002: ID 0781:5530 SanDisk Corp. Cruzer
<Turl> I didn't have the phy driver enabled
<Turl> maybe they should depend on each other...
<wens> ah hah
<Turl> my soundcard works as well, on ohci :)
<Turl> ah, but the usb option is generic, can't have a dependency
<Turl> nevermind then :)
<Turl> sparse has some funny messages
<Turl> net/core/filter.c:798:58: error: subtraction of functions? Share your drugs
cubear has joined #linux-sunxi
<wens> lol
<cubear> morgen
pseudomind has quit [Quit: pseudomind]
FreezingCold has quit [Ping timeout: 276 seconds]
<wens> gzamboni: what's up with China? :)
<gzamboni> AW is officialy telling A80/A31 will support android, firefoxOS, ubuntu, chromeOS and windowsRT
<gzamboni> wens i order some prototypes boards from a company in Shenzhen and they are not answering my emails anymore :(
<wens> can't help you there :(
<gzamboni> when i try to call them i get a strange thing in my tellphone with a chinese message in the end and of course i dont understand chinese
<gzamboni> last message i got they said they were in ching ming festival or something
<gzamboni> brb
sdfsg has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
sdfsg has quit [Quit: Page closed]
<wens> ah ching ming
<gzamboni> ching ming is a one day hollyday, right ?
<gzamboni> 5 April
<wens> it's around 4/4 or 4/5, local customs vary, but it's mostly a time to visit ancestors' graves
<gzamboni> ok, thank you, maybe they are still onto it
Black_Horseman has quit [Ping timeout: 240 seconds]
<wens> the holiday varies, in Taiwan it's customary to have a long weekend, or even a one week spring break for students
<wens> I suppose the customs vary across China as well.
<gzamboni> nice to know
sehraf has joined #linux-sunxi
maksimlin has quit [Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140317233623]]
bbrezillon has joined #linux-sunxi
theskilledworker has joined #linux-sunxi
theskilledworker has quit [Changing host]
theskilledworker has joined #linux-sunxi
montjoie[home] has quit [Remote host closed the connection]
<buZz> anyone know where i can get that allwinner shirt? :D
* slapin is interested, too
<buZz> it looks good
<buZz> maybe i could extrapolate the design from the video ..
leviathanch2 has joined #linux-sunxi
physis has joined #linux-sunxi
FR^2 has joined #linux-sunxi
leviathanch2 has quit [Remote host closed the connection]
rz2k has joined #linux-sunxi
physis has quit [Ping timeout: 258 seconds]
wickwire has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Leaving]
_massi_ has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
physis has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
physis has quit [Ping timeout: 252 seconds]
souther has quit [Ping timeout: 246 seconds]
dannymi2 has quit [Remote host closed the connection]
leviathanch2 has quit [Ping timeout: 240 seconds]
Guest47151 has quit [Ping timeout: 240 seconds]
kuldeepdhaka has joined #linux-sunxi
Guest47151 has joined #linux-sunxi
ganbold has quit [Ping timeout: 240 seconds]
ccube has quit [Remote host closed the connection]
leviathanch2 has joined #linux-sunxi
ccube has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 245 seconds]
montjoie[home] has joined #linux-sunxi
bgal has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
theskilledworker has quit [Quit: Leaving]
bgal has quit [Ping timeout: 250 seconds]
speakman_ is now known as speakman
leviathanch2 has quit [Ping timeout: 245 seconds]
FreezingCold has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 252 seconds]
leviathanch2 has joined #linux-sunxi
souther has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
geecko has joined #linux-sunxi
cubear has quit [Quit: Leaving]
kuldeepdhaka has quit [Ping timeout: 250 seconds]
F1skr has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
Black_Horseman has quit [Ping timeout: 258 seconds]
Gerwin_J has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Gerwin_J has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
kuldeepdhaka has quit [Ping timeout: 252 seconds]
kuldeepdhaka has joined #linux-sunxi
CoSM0 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
leviathanch2 has joined #linux-sunxi
hypothalamus has joined #linux-sunxi
sehraf has quit [Ping timeout: 245 seconds]
jemk has joined #linux-sunxi
<ssvb> hi jemk
<jemk> hi (reading logs)
<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: when searching for the information, I found this blog, which explains dram refresh quite nicely - http://utaharch.blogspot.fi/2013/11/a-dram-refresh-tutorial.html
<ssvb> jemk: but not much else, so please also let me know if you end up finding some good information about ddr3 memory
<jemk> ssvb: opencores.org has some opensource memory controllers, but they are too basic to learn much about "real" ones
<ssvb> yeah
<jemk> ssvb: hm, ruby hates me: /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- generator (LoadError)
<ssvb> jemk: which version of ruby do you have?
<jemk> ssvb: archlinux, so the latest 2.1.0
<ssvb> jemk: hmm, I have older ones
<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
xavia has joined #linux-sunxi
<ssvb> jemk: one more thing, I have generated the timings for my cubietruck using the https://github.com/ssvb/a10-meminfo/blob/master/cubietruck-dram-timings-calculator.rb script
<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
<libv> the red is a template
<libv> i do not remember how i did it, but mediawiki supports any colouring you like
<ssvb> I thought about changing the autogenerated output format from html to wiki format, so that anyone could dump the results directly to the wiki
<ssvb> instead of having access to some web server to host things like http://people.freedesktop.org/~siamashka/files/20140414-sunxi/sunxi-dram-tpr3-tests.html
<ssvb> libv: right, I need to check it with the linux-sunxi wiki
<ssvb> libv: I found some mediawiki table examples, but they did not get any colors when I tested them with the github wiki :)
joe112 has joined #linux-sunxi
<ssvb> libv: or does wiki support just embedding chunks of html?
diego_r has joined #linux-sunxi
pseudomind has joined #linux-sunxi
<wens> yay! hansg just rebased sunxi-devel
pseudomind has quit [Quit: pseudomind]
notmart has quit [Read error: Connection reset by peer]
<ssvb> jemk: do you have the cubietruck dram datasheets?
jemk_ has joined #linux-sunxi
<ssvb> jemk: http://dl.linux-sunxi.org/chips/GT-DDR3-2Gbit-B-DIE-(X8,X16).pdf seems to be for the lower density chips
<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
<libv> byECHO: which one of these is it: http://linux-sunxi.org/Category:A13_Tablets
<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: can you work through http://linux-sunxi.org/New_Device_howto ?
<libv> the a13_mid.fex does say 800x480
<libv> is your tablet 4:3 or 16:9?
<byECHO> 16:9
<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
<byECHO> So, I should do like this http://linux-sunxi.org/Q8 or what?
<libv> http://linux-sunxi.org/New_Device_howto will guide you through it ":)
<libv> also, it pays to get another copy of the .fex from the android (which is easy) and to compare it with a13_mid.fex
<libv> byECHO: does your device look like the Q8?
<byECHO> yeah
<byECHO> not its case but its hardware is similar
<libv> the board looks the same?
<libv> most a13 tablets have 800x480 and 512mb
<Turl> oliv3r!
<libv> comes with the territory of being the cheapest soc
<byECHO> well I never saw my tablets board. I cant say
<Turl> libv: now intel is pushing bay trail for 5$ on china, wonder what will happen
<ssvb> Turl: link?
<rm> what, below $5 is still "almost" on par?
<rm> other quad core CPUs cost $2 or something?
<ssvb> Turl: that's an excellent news, unless this is the "first dose free" strategy
<Turl> ssvb: how is it good news?
<Turl> ssvb: and yeah, it's probably that. Intel has like.. no market share
leviathanch has quit [Remote host closed the connection]
<ssvb> Turl: more competition in this area, better hardware documentation, free open source drivers, ...
leviathanch has joined #linux-sunxi
<Turl> but if they crush the competition it's not going to be of much use for us
byECHO has quit [Quit: Page closed]
bbrezillon has quit [Ping timeout: 252 seconds]
souther has quit [Ping timeout: 245 seconds]
FreezingCold has joined #linux-sunxi
nove has quit [Quit: nove]
ZetaNeta has quit [Ping timeout: 240 seconds]
FreezingAlt has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 240 seconds]
bbrezillon has joined #linux-sunxi
bbrezillon has quit [Quit: WeeChat 0.4.1]
FreezingAlt is now known as FreezingCold
FDCX has quit [Remote host closed the connection]
boycottg00gle has quit [Remote host closed the connection]
<libv> the really fun thing about android is that intel is having to use an arm emulator for some native programs :)
<libv> it's quite ironic given how the pc industry has worked since the 80s
<megal0maniac_afk> libv: Are Intel coming into this market with x86?
<libv> megal0maniac_afk: they have been trying since 2010
<libv> or 2011 at least
<libv> whether they succeed or not, remains to be seen
<megal0maniac_afk> Ah, with Atom?
FDCX has joined #linux-sunxi
<libv> variations thereof, yes
<libv> actually, february 2010 is when they announced meego, together with nokia
<megal0maniac_afk> Which died a quick death iirc
<libv> it could be argued that it started with moblin in july 2007
<libv> but that was mostly for netbooks, which were highly popular
<libv> megal0maniac_afk: well, nokia decided to commit suicide...
<megal0maniac_afk> I'm getting to appreciate linux-sunxi as I get more familiar with it
<megal0maniac_afk> Yeah, they did... :)
<Turl> libv: yeah, they have some thing they call libhoudini iirc
<Turl> to emulate some arm code on some apps
<megal0maniac_afk> Silly Intel
<Turl> but nowadays NDK lets you build for x86 as well, and most people probably do
<libv> i don't own a proper intel android device, so i do not know how things work with the google play store
<libv> but having to emulate arm, that's the world as we knew it, turned upside down :)
<Turl> libv: most apps don't have native components and are pure java
<Turl> those don't need any emulation
<Turl> the apps with native components are mostly games and video players
<libv> Turl: i am quite aware of that :)
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
<libv> jemk: i do not think that you need to limit this to your talk page :)
<jemk> libv: its only a scratchpad for now, and ssvb had different results, so i though it would be good to connect it to the user
<ssvb> jemk: well, my result for the cubietruck is quite similar (the potentially good tpr3 values are all concentrated in the top left corner)
<ssvb> jemk: if you increase the dram clock speed or reduce the dcdc3 voltage, maybe the green area will get smaller
<ssvb> jemk: now I'm trying to decide what to do next with these results
<ssvb> jemk: because every 'green' result needs a more extensive check
<jemk> ssvb: I will try that tomorrow, and hopefully cb1 too
<ssvb> jemk: ok, thanks, I'll try to make the script more useful and maybe look at the watchdog again
<jemk> ssvb: if we follow what scan_dll_para does we could chose the line with most green and test the middle of the green row
<ssvb> jemk: has the watchdog failed only one time during this run?
<jemk> ssvb: yes, only once, but it sometimes waited really long, nothing worked but it didn't reset it for some miniutes
<ssvb> jemk: yes, it might wait up to 5 minutes in some cases
<jemk> k
Fusing has joined #linux-sunxi
Fusing2 has joined #linux-sunxi
Fusing has quit [Ping timeout: 265 seconds]
orly_owl has quit [Ping timeout: 240 seconds]
jemk has quit [Remote host closed the connection]
orly_owl has joined #linux-sunxi
Fusing has joined #linux-sunxi
souther has joined #linux-sunxi
Fusing2 has quit [Ping timeout: 240 seconds]
dtr has joined #linux-sunxi
bgal has quit [Ping timeout: 245 seconds]
t3st3r has quit [Ping timeout: 272 seconds]
t3st3r has joined #linux-sunxi
dtr has quit [Quit: Page closed]
physis has joined #linux-sunxi
Fusing has quit [Quit: Nettalk6 - www.ntalk.de]
F1skr has joined #linux-sunxi
<F1skr> Are there any mmc driver in the sunxi-next branch?
xavia has left #linux-sunxi ["PART #interlock :PART #arduino :PART #wnydev :PART #buffalolab :PART #docker :PART #symfony :PART #virtuvia :QUIT :Leaving."]
hypothalamus has quit [Quit: www.miranda-fusion.de ... be part of it...]
FreezingCold has quit [Ping timeout: 276 seconds]
<arete74> f1skr: yes hans have update mmc for 3.15-rc1
<arete74> the branch is sunxi-devel
<F1skr> arete74: ahh I see I checked out next instead of devel. will test it out!
bertrik has quit [Remote host closed the connection]
ccaione has quit [Ping timeout: 260 seconds]
geecko has quit [Remote host closed the connection]
libv has quit [Ping timeout: 260 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
ccaione has quit [Ping timeout: 260 seconds]
libv has joined #linux-sunxi
geecko has joined #linux-sunxi
maksimlin has joined #linux-sunxi
Skaag has joined #linux-sunxi
libv has quit [Ping timeout: 260 seconds]
nabblet has quit [Quit: leaving]
Skaag has quit [Ping timeout: 252 seconds]
libv has joined #linux-sunxi
ccaione has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
Skaag has joined #linux-sunxi
physis_ has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
tomcheng76 has quit [Ping timeout: 252 seconds]
kuldeepdhaka has quit [Quit: bbye]
FunkyPenguin has quit [Ping timeout: 276 seconds]
FunkyPenguin has joined #linux-sunxi