dave0x6d has quit [Quit: Connection closed for inactivity]
Andy-D has quit [Ping timeout: 264 seconds]
FrostyBytes has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<wens>
codekipper: next time i think it would be easier if you sent all related patches in one series (regarding the spdif patches)
Andy-D has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 250 seconds]
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
LargePrime has joined #linux-sunxi
mzki has quit [Ping timeout: 248 seconds]
terra854 has joined #linux-sunxi
perr has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
camh has quit [Ping timeout: 245 seconds]
apritzel has quit [Ping timeout: 250 seconds]
camh has joined #linux-sunxi
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
jernej has joined #linux-sunxi
akaizen has quit [Ping timeout: 264 seconds]
victhor has quit [Ping timeout: 246 seconds]
<wens>
beeble: did you guys get hdmi working on the a80?
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
paulk-collins has quit [Ping timeout: 250 seconds]
fraveydank has joined #linux-sunxi
jernej has quit [Ping timeout: 258 seconds]
fraveydank has quit [Ping timeout: 258 seconds]
<wens>
codekipper: spdif works on my sina31s (had to patch the pinctrl driver as well)
<wens>
though with spdif on either a20 or a31, i think there's an imbalance between the channels, could be my decoder though
<wens>
also there might be some rounding error in the clk driver... the actual clk rates used for spdif seem to be lower than the codec
paulk-collins has joined #linux-sunxi
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
longsleep has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 250 seconds]
longsleep has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<wens>
well, good news is that the libhdcp blob from the a80 bsp, when disassembled, matches some source code i found
<wens>
bad news is that the source code seems to be from synopsys, and is all rights reserved
<beeble>
wens: there is a guy doing part time stuff on it. so i think he is still trying to figure out the register layout
<beeble>
last time i have talked with him he has found the hpd bit
<beeble>
so not a lot of progress and not the highest on our priority list
<wens>
beeble: well it really seems like straight forward designware
<wens>
i just have to find some of the chip specific parameters to use the mainline dw-hdmi driver
<beeble>
that sounds reasonable. i will tell him next year, since he is already on christmas break
<wens>
i see
<beeble>
pretty much everything on hold till the second week of january for us lazy europeans
<igraltist>
hi
<igraltist>
when i boot my orangepi-pc with mainlain and uart-usb cable, the keyboard is not working
<igraltist>
iam not sure if i forgot something
<wens>
beeble: i don't suppose you have any specs for hdmi, either for the a80 or rk3399?
<igraltist>
its boots till login promt and running because when i plugin an usb keyboard i see message on screen
fraveydank has joined #linux-sunxi
ErwinH has joined #linux-sunxi
Andy-D has quit [Ping timeout: 264 seconds]
ErwinH has quit [Ping timeout: 258 seconds]
fraveydank has quit [Read error: Connection reset by peer]
<beeble>
wens: not for the a80
<beeble>
wens: looks better for the rk3399, but havent that deep into the higher level video sections since i'm still at board level design
<wens>
hmm, the imx6 manual seems handy
<wens>
anyway, still have to dig out the chip specific values
<beeble>
and just started doing cli stuff on the eval board
<wens>
but at least now i know what they mean
<beeble>
but you think the rk3399 has the same designware core?
TheSeven has quit [Ping timeout: 245 seconds]
reinforce has joined #linux-sunxi
TheSeven has joined #linux-sunxi
<beeble>
btw, rockchip doku look very nice in comparison to the one from aw
<beeble>
still not imx level but getting there
<beeble>
it even has dram sections with register descriptions! :)
IgorPec has joined #linux-sunxi
kaspter has joined #linux-sunxi
<wens>
beeble: i think i saw rk3399 hdmi patches using dw-hdmi
<wens>
beeble: which rockchip wiki? i think there are several?
<MoeIcenowy>
the U-Boot H3 HDMI patch benefited a lot from rk-hdmi.c ;-)
leviathanch has joined #linux-sunxi
cajg has quit [Ping timeout: 256 seconds]
IgorPec has quit [Ping timeout: 250 seconds]
ErwinH has joined #linux-sunxi
muvlon has quit [Ping timeout: 258 seconds]
montjoie has quit [Ping timeout: 265 seconds]
ErwinH has quit [Ping timeout: 250 seconds]
montjoie has joined #linux-sunxi
<beeble>
wens: i meant the datasheet. unfortunately it's restricted in access
<wens>
beeble: i see
muvlon has joined #linux-sunxi
foxx_ has joined #linux-sunxi
ErwinH has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 248 seconds]
cnxsoft1 is now known as cnxsoft
<rookieone>
good moring :)
IgorPec has joined #linux-sunxi
<ErwinH>
Testing the stability of the slower frequencies is hard since the kernel panics more easily...
<KotCzarny>
use the watchdog luke, the watchdog
<jonkerj>
and a usb relay to powercycle the board
<jonkerj>
it might get stuck in a way the wd cannot recover from
<KotCzarny>
i though hw watchdog would reset the board no matter of soc state?
<KotCzarny>
*thought
<ErwinH>
Watchdog din't recover...
<KotCzarny>
bad watchdog, bad!
<KotCzarny>
some programmable relay would help then, with delay cycle reset every few secs
<ErwinH>
Or simply ignore the lower frequencies :)
<KotCzarny>
sure, if you stick to 2-3 good ones and remove other from dvfs/throttling
<ErwinH>
If 672MHz is running at 910mv 480MHz should work fine at 910mv as well.
<KotCzarny>
but it will be better if at 480 it could go even lower
tkaiser has joined #linux-sunxi
<tkaiser>
KotCzarny: Wrong, doesn't matter at all. When the CPU cores are idle then they're idle. There's not much to gain here. The whole procedure is only interesting for cpufreq operating points that are used with load. And that is everything from top speed below to lowest cpufreq value that will be reached when throttling occurs. Everything else is uninteresting
<tkaiser>
So when H5 on OPi PC 2 running cpuburn-a53 throttles down to 648 MHz then this freq is interesting. Otherwise not that much.
<KotCzarny>
then why did you pursued 'the lowest mA you can get' ?
<KotCzarny>
idle power is also important, those boxes are often doing jobs that are mostly idle
<KotCzarny>
and idling at different voltages draw different power
<tkaiser>
KotCzarny: Why are you talking about idle consumption when you've no numbers? Do a google search for 'rate to idle' concept and you get why cpufreq scaling doesn't scale down to 24 MHz but to 480 MHz. Since it helps the CPU cores entering deep sleep states more often.
<tkaiser>
And lower VDD_CPUX voltage is important under load since the lower, the less temperatures and less throttling occurs. So by tweaking those upper dvfs operating points you get more performance in throttling situations.
<tkaiser>
'race to idle' concept, sorry
<KotCzarny>
where was i talking about mhz? i was talking about voltages
<KotCzarny>
we dont scale down to 24mhz because no one found it can operate on lower mV than 480
<tkaiser>
KotCzarny: Yeah, and I stop here. If you would start to do a search first for the topic (minimize idle consumption) you would get what's necessary. It's *not* undervolting lower dvfs operating points.
<muvlon>
race to idle doesn't scale down at all, tkaiser
<tkaiser>
ErwinH: How many OPi PC 2 do you have around?
<ErwinH>
btw. the lowest VDD_CPUX voltage on which my board functions is 890mV. Dropping to 880mV instantly crashes the board no matter what frequency (624Mhz and lower).
<ErwinH>
One unfortunately.
<tkaiser>
ErwinH: Then the whole approach is questionable anyway since when you found the limits of your specific SoC/board we must add a reasonable 'safety headroom' to each dvfs operating point and then it really doesn't matter any more what happens at the lower end. And real consumotion differences are neglectible anyway (since when CPU cores enter deep sleep states it doesn't matter that much how high VDD_CPUX is set)
<tkaiser>
When I played around with Pine64 I was very enthousiastic to optimize settings, wasted a lot of time, came up with nice settings and after adding the 'safety headroom' ended up nearly with Allwinner's recommendations.
<ErwinH>
I'll test the upper frequencies and see if there's any room for improvement over the DVFS table I'm using atm. But the safety room doesn't leave much for improvement.
<tkaiser>
ErwinH: On the bright side with peekpoke now we could provide a simple script that allows end users to test their individual SoC/board...
<ErwinH>
Peekpoke and the i2ctools.
<tkaiser>
True, I forgot that.
<tkaiser>
ErwinH: And maybe you're able to exceed the 1152 MHz also when testing. But then a second round of tests with cpuburn-a53 would also be great and this might be really challenging regarding heat dissipation.
<ErwinH>
The board is a great heat dispencer and running the board in a tunnel should do the trick.
<ErwinH>
And don't be scared of high temperatures.
<ErwinH>
Running xhpl at 1008MHz reaches a little over 80C without forced cooling.
<likewise>
Did anyone reproduce the CHIP build with alpha MALI drivers for their A13/R8/GR8?
<buZz>
i've seen ppl use the blobs
apritzel has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<likewise>
buZz: and the upstream kernel with that?
<buZz>
thats what CHIP uses
<buZz>
some 4.recent.something
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 268 seconds]
<MoeIcenowy>
apritzel: I finished axp803 driver
<MoeIcenowy>
and of course 64-bit SPL with it has size boomed
apritzel has quit [Ping timeout: 245 seconds]
perr has quit [Quit: Leaving]
<likewise>
I have been reading into the status of A13 support in Linux, and although it all seems good it's hard to find a working build for MALI + EGLFS +Qt5 using Buildroot or OpenEmbedded or Yocto. What am I doing wrong?
<likewise>
Should I use the Allwinner kernel (3.4.x) in order to get MALI working w/ EGLFS, or does linux-sunxi have a more mainline kernel with MALI + EGLFS support?
<buZz>
likewise: i just told you, CHIP uses a -newer- kernel , with mali blobs
<likewise>
buZz: I know that. That was not my question.
<buZz>
ah ok
leviathanch has quit [Remote host closed the connection]
<likewise>
buZz: Let me rephrase: before any efforts from CHIP, what was the best way to get a MALI + EGFLS build for A13 using existing linux-sunxi community efforts?
<buZz>
not sure, i'd guess those armbian builds
<ErwinH>
1296MHz@1270mv failed.
<ErwinH>
1248MHz@1280mv passed
muvlon has quit [Quit: Leaving]
jernej has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
bugzc has quit [Ping timeout: 260 seconds]
Andy-D_ has quit [Ping timeout: 250 seconds]
aballier has quit [Ping timeout: 246 seconds]
aballier has joined #linux-sunxi
foxx_ has quit [Ping timeout: 265 seconds]
likewise has quit [Ping timeout: 258 seconds]
likewise has joined #linux-sunxi
<ErwinH>
tkaiser: http://pastebin.com/0z3FhfkU HPL results starting from 1296MHz at 1300mv which is the max my setup will let me run.
fkluknav has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<ErwinH>
Running at 1392MHz @ 1400mv failed. So that's not usable.
<jonkerj>
are you using some form of automated testing, ErwinH?
<ErwinH>
Yep, Start a test at a certain cpufreq/voltage and lowering the voltage until HPL fails. Then drop the cpufreq by 1 step and start over from the failed core voltage -10mv.
Net147 has joined #linux-sunxi
Putti has quit [Quit: Leaving]
<ErwinH>
Max usable frequency with my setup/board is 1368MHz and it needs at least 1380mV. So there isn't much room for error.
kaspter has quit [Ping timeout: 240 seconds]
<miasma>
ErwinH: does the fanless test use a heatsink
<ErwinH>
Nope
foxx_ has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
<ErwinH>
Only the 2 frequencies 1392 and 1368 used a heatsink.
<ErwinH>
I thought the board was a big enough heatsink :)
<ErwinH>
And up to 1296 that's true :)
<miasma>
ok, but that's a great table. although, too bad we can't see how much the consumption changes
<ErwinH>
Can't measure consumption reliably.
libv_ has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
ErwinH: Thanks for the numbers. Would be great if you could add link to results on to your 'gear' as a stub on OPi PC 2 wiki page (just like ssvb did a year ago for H3 OPi PC: starting with 'recommended' values and then adding your results).
libv has quit [Ping timeout: 250 seconds]
<ErwinH>
tkaiser: in the wiki or forum?
<ErwinH>
Nevermind
tkaiser has quit [Read error: Connection reset by peer]
<jonkerj>
err, can you explain the options again? :-)
<KotCzarny>
once as in one full table of values for different freqs, and on evey boot as in 'when os starts it runs some quick stability test'. which is kinda stupid now that i think of it
<jonkerj>
you need to reboot to alter the operating point table, I'm afraid
<KotCzarny>
i think he was doing it via peekpoke and i2c
<jonkerj>
and when the voltage was too low, the system would reboot
<KotCzarny>
in the optimistic variant you detect corruptions before system reboots
<KotCzarny>
or hangs
foxx_ has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jonkerj>
I dont like the idea of peekpoke-i2c-setting de voltage regulator
<jonkerj>
probably works most of the time, but is not guaranteed reliable. cpufreq may touch settings
<miasma>
so do you fel boot or how do you change the configs and boot quickly?
<jonkerj>
furthermore, it only saves 1 reboot, which is < 30s in my case. The whole test run will take much more time
victhor has joined #linux-sunxi
<jonkerj>
uboot script that fires off some fdt commands
<miasma>
ah ok
<jonkerj>
from userspace you create a '/boot/patch.cmd', and have boot.cmd include that
<jonkerj>
(if existing)
<jonkerj>
+/- compiling to scr, of course
FergusL59 has joined #linux-sunxi
<jonkerj>
using this method I am going to fire off a "bisect" binary search for the proper voltage
<jonkerj>
and the test yields either "raise voltage", "lower voltage" or "convergence"
FergusL59 is now known as FergusL
<jonkerj>
should be easy to test a voltage in say an hour (6x 10 min, 2^6 = 64 voltage steps)
<KotCzarny>
or just stick with aw defaults and find better play target?
<jonkerj>
well, I thing the aw default have too high voltages, so the cooling will throttle max speed
<jonkerj>
which kills performance
<jonkerj>
tricky thing will be testing the higher frequencies, since stressing the CPU will raise temperature and the cooling will throttle
<KotCzarny>
well, im using youtube on droid with my self built image/kernel/settings, temp is 42C
<jonkerj>
and testing under idle load is not very realistic
<KotCzarny>
so you either use the board for things it was made of, or struggle with performance
<KotCzarny>
s/of/for/
ErwinH has joined #linux-sunxi
hojnikb has joined #linux-sunxi
<hojnikb>
jonkerj: Maybe start with allwinner default voltages and go down from there
<hojnikb>
less options
<hojnikb>
so faster testing
dh1tw has joined #linux-sunxi
<hojnikb>
and if certain frequency/voltage target exceeds max tems
<hojnikb>
remove it from the table entirely
ErwinH has quit [Ping timeout: 258 seconds]
<hojnikb>
Also for the max frequency script should do a longer testing (say an hour or so) and some some dram/io testing as well
<hojnikb>
so it's really stable
<hojnikb>
and on that voltage apply some margin (+20mA or so) for silicon degradation and temperature
<hojnikb>
+20mV i meant :)
<hojnikb>
too bad allwinner boards don't have some sort of current/power measurement, so you could do the most efficient frequency point :)
hojnikb has quit [Quit: Page closed]
reinforce has quit [Quit: Leaving.]
<tkaiser>
hojnikb: They have, all boards equipped with PMIC (read as 'not H3 and not H5') and and ADC can be used for that.
<tkaiser>
That's how I did all my consumption measurements over a few months: Let a Banana Pi Pro power the boards and monitor there voltage and amperage. You need average values and it stops to be useful when differences are just 20mW or less (since not precise enough)
<victhor>
hi, speaking of pmic... is axp233 supported for battery charging?
<msev->
Hojnikb are u from Slovenia maybe?
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Client Quit]
ErwinH has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
<ErwinH>
jonkerj hojnikb: I just used the clean armbian rootfs with u-boot and kernel from apritzel. Installed HPL from the Pine64 testsuite and created a script that alters the frequency and voltage via i2c and peekpoke. I'll clean up the testscript a bit and share it.
<ErwinH>
Tests take 60 seconds per voltage per frequency.
ErwinH has quit [Remote host closed the connection]
netlynx has joined #linux-sunxi
interrobangd has joined #linux-sunxi
foxx_ has quit [Ping timeout: 268 seconds]
perr has quit [Quit: Leaving]
mzki has quit [Ping timeout: 245 seconds]
<beeble>
just as a heads up. workload is quite importent for dvfs stability tests. i have seen crashes after hours with settings that looked fine otherwise
<KotCzarny>
imo just having 2-3 freqs is enough
<beeble>
so testing it innonly 60s seems a little bit optimistic to me
<tkaiser>
beeble: Totally agree, the xhpl test is a bit too short
mzki has joined #linux-sunxi
<tkaiser>
And running cpuburn-a53 as already suggested might already be a good idea. And then we end up with Allwinner
<tkaiser>
's defaults ;)
<tkaiser>
KotCzarny: 2-3 what?
<KotCzarny>
dvfs entries
<tkaiser>
KotCzarny: Why? To ensure low performance when throttling occurs later?
<KotCzarny>
idle, full load, turbo
<tkaiser>
OMG. It's still about getting reliable dvfs operating points. As *much as possible*
<KotCzarny>
yup
<KotCzarny>
having 3 stable points is enough
<tkaiser>
When you later run something heavy on the board and it starts to throttle you don't want to jump from 1152 to 816 and back (since this is *low* performance) but you want fine grained throttling!
<tkaiser>
BS
<KotCzarny>
and much more reliable when you can put spare testing time in those 3 instead of 10 diff. freqs
<tkaiser>
O my...
<KotCzarny>
anyway, those boards werent made for high performance, so the whole topic is moot
<beeble>
i usually verify with a full spec2000 run. cpuburn it good to verify thermal behaviour but does not reflect heavy workload behaviour
<beeble>
you can still run in spec misscompares even if couburn is running fine
<tkaiser>
beeble: Good to know.
<beeble>
sine ist mostly a cooling topic
<beeble>
since
<KotCzarny>
beeble, testing worse case scenario then?
<KotCzarny>
*worst
<beeble>
damn smartphone keyboard
<tkaiser>
KotCzarny: I prepared RPi-Monitor templates also using cpuminer (also NEON optimized), the key to more performance is using INTELLIGENT settings and that means the more dvfs operating points the better. It's easy to confirm this.
<beeble>
KotCzarny: you don't get the same thermal profile. so it really depends what you are tuning for
<KotCzarny>
i could imagine thing oliv3r done to be worst case
<KotCzarny>
ie. board stuck in the closed case with heater nearby
<beeble>
cpuburn can give you 50% more power consumption but does not verify correct cpu,bus and memory behaviour
<beeble>
so use it to test your cooling solution (heatsink, fan, throtteling) but not for voltage stability
<beeble>
use a test that does workloads and verify its testresults
<beeble>
for that
<scelestic>
i read (somewhere here i think) that cpu mining was a good one because it had to be correct and you could see by the hashes/s if it throttled
<beeble>
also if you are into thermal profiling you should have the gpu running. this can also easily double yiur power consumption
<beeble>
as always, hard to do a one fits all solution
interrobangd has quit [Quit: Leaving]
Putti has quit [Ping timeout: 252 seconds]
Axl_ has joined #linux-sunxi
likewise has quit [Ping timeout: 252 seconds]
fkluknav has quit [Ping timeout: 246 seconds]
likewise has joined #linux-sunxi
apritzel has joined #linux-sunxi
hojnikb has joined #linux-sunxi
<hojnikb>
msev-: you're correct :)
<hojnikb>
ErwinH: please do share the image... :)
<hojnikb>
if i understand correctly, it's possible to set any voltages and frequency on the fly with peekpoke, or do you need to reset ?
mossroy has quit [Quit: Leaving]
Leepty has quit [Remote host closed the connection]
hojnikb has quit [Quit: Page closed]
apritzel has quit [Ping timeout: 260 seconds]
Nacho has quit [Ping timeout: 250 seconds]
<KotCzarny>
x220 is a few gens higher
<KotCzarny>
um, wrong chan. eh, sorry
Ntemis has quit [Remote host closed the connection]
Putti has joined #linux-sunxi
deskwizard has quit [Ping timeout: 252 seconds]
Amit_T has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<KotCzarny>
pine64 overheats a bit, now this.. mm, fries?
<deskwizard>
nice, I needed a coffee heater :P
<KotCzarny>
it has mali400, hehe
<KotCzarny>
overall nice little board
Amit_T has quit [Ping timeout: 250 seconds]
<deskwizard>
seems like it, im still not sold on the micro-usb as power input thing...
<KotCzarny>
it might be they support powering via uart 4th pin
<deskwizard>
oh, or the header, good point!
<KotCzarny>
' Here is a setup where we connect a NanoPi A64 to a PC via the PSU-ONECOM and you can power on your A64 from either the PSU-ONECOM or the board's MicroUSB:'
Putti has quit [Remote host closed the connection]
<deskwizard>
solved then. ty :)
<KotCzarny>
it's from their wiki
vagrantc has quit [Quit: leaving]
Axl_ has quit [Remote host closed the connection]
Axl_ has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
Amit_T has joined #linux-sunxi
ErwinH has joined #linux-sunxi
r1mikey has joined #linux-sunxi
interrobangd has joined #linux-sunxi
Amit_T has quit [Ping timeout: 250 seconds]
ErwinH has quit [Ping timeout: 268 seconds]
jernej has quit [Quit: Konversation terminated!]
r1mikey has quit [Remote host closed the connection]
Err has quit [Ping timeout: 256 seconds]
Err has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
scelestic has quit [Read error: Connection reset by peer]
dave0x6d has quit [Quit: Connection closed for inactivity]
paulk-collins_ is now known as paulk-collins
paulk-collins has quit [Quit: Leaving]
paulk-collins has joined #linux-sunxi
Amit_T has joined #linux-sunxi
popolon has joined #linux-sunxi
apritzel has joined #linux-sunxi
jstein_ has joined #linux-sunxi
Amit_T has quit [Ping timeout: 265 seconds]
jstein_ is now known as jstein
interrobangd has quit [Quit: Leaving]
deskwizard has quit [Ping timeout: 250 seconds]
Amit_T has joined #linux-sunxi
Amit_T has quit [Ping timeout: 252 seconds]
Putti has joined #linux-sunxi
jstein__ has joined #linux-sunxi
jstein is now known as Guest42815
jstein__ is now known as jstein
Amit_T has joined #linux-sunxi
Guest42815 has quit [Ping timeout: 245 seconds]
popolon has quit [Quit: WeeChat 1.4]
Amit_T has quit [Ping timeout: 264 seconds]
Axl_ has quit [Ping timeout: 268 seconds]
Axl_ has joined #linux-sunxi
Amit_T has joined #linux-sunxi
Amit_T has quit [Ping timeout: 252 seconds]
terra854 has quit [Quit: Connection closed for inactivity]
dh1tw has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7036-gfd20b1a, build type: debug, sources date: 20160102, built on: 2016-12-02 12:15:06 UTC git-7036-gfd20b1a http://www.kvirc.net/]