mnemoc changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at
payne_ has joined #linux-sunxi
payne__ has quit [Ping timeout: 240 seconds]
petr has quit [Ping timeout: 244 seconds]
wickwire has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
joedj has quit [Ping timeout: 245 seconds]
F1skr has quit [Quit: WeeChat 0.4.3]
petr has joined #linux-sunxi
joedj has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
Black_Horseman has joined #linux-sunxi
speakman has quit [Ping timeout: 240 seconds]
speakman has joined #linux-sunxi
speakman has quit [Changing host]
speakman has joined #linux-sunxi
le has joined #linux-sunxi
le has quit [Ping timeout: 245 seconds]
le has joined #linux-sunxi
montjoie1home] has joined #linux-sunxi
montjoie[home] has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 272 seconds]
jebba has quit [Ping timeout: 244 seconds]
jebba has joined #linux-sunxi
TheSeven has joined #linux-sunxi
jebba has quit [Ping timeout: 240 seconds]
jebba has joined #linux-sunxi
<wens> mripard: curious, is the cp15 frequency register always set to 24 MHz, or should it be the actual speed the CPU is running at?
xavia has joined #linux-sunxi
Andy-D has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
<afaerber> ssvb, rc2 uImage did not work either. I've found that even my zImage apparently boots according to __log_buf read via md.b - so uart and gmac don't seem to work
FreezingCold has quit [Ping timeout: 245 seconds]
amitk has joined #linux-sunxi
<ssvb> afaerber: if I don't set fdt_high to ffffffff, it does not boot for me either
<ssvb> afaerber: also I actually use "bootcmd=tftp 0x43000000 sun7i-a20-cubietruck.dtb; tftp 0x48000000 mainline-uImage; bootm 0x48000000 - 0x43000000"
<ssvb> afaerber: (the addresses are different from what is recommended in the linux-sunxi wiki)
JohnDoe_71Rus has joined #linux-sunxi
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<ssvb> afaerber: but just checked it and the addresses from the wiki also work fine for me
<afaerber> I just tried enabling earlyprintk (and your addresses) and now get "Uncompressing Linux... done, booting the kernel." as last line on UART0
<ssvb> which u-boot are you using?
<afaerber> earlyprintk shows an oops:
<ssvb> the wiki implies that the dtb overwrite problem is a bug in u-boot, so its version may be important
<ssvb> this oops log looks like the dtb indeed might be corrupted
<afaerber> openSUSE Base:System u-boot v2014.04 with linux-sunxi diff patched in
<afaerber> does it matter when the fdt_high is set?
<ssvb> yes, of course
<afaerber> I'm doing it from my boot.scr just before loading the files
<ssvb> in any case, I'm using the mainline u-boot master from git with a few extra sunxi fixes from patchwork and my dram initialization patches
bbrezillon has joined #linux-sunxi
<afaerber> tried moving it directly before the bootz after ext2loads, no change
bbrezillon has quit [Ping timeout: 255 seconds]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
xavia has quit [Quit: Leaving.]
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 245 seconds]
ssvb has quit [Ping timeout: 244 seconds]
afaerber_ is now known as afaerber
akaizen has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
ssvb has joined #linux-sunxi
<afaerber> ssvb, I got in via ssh; I reverted back to 46/49... and used 0xffffffff rather than ffffffff
rgenoud has joined #linux-sunxi
le has quit [Ping timeout: 245 seconds]
Black_Horseman has quit [Ping timeout: 255 seconds]
le has joined #linux-sunxi
maksimlin has quit [Quit: ChatZilla [Firefox 30.0/20140608211828]]
libcg has joined #linux-sunxi
arend has joined #linux-sunxi
<mripard> wens: iirc, you can set it at any value you want, and it's not dependent of the CPU's frequency
<wens> doesn't that affect arch_timer's clock rate or something?
<wens> how do we know if it's accurate?
<mripard> afaerber: what u-boot commands are you using? could you paste them somewhere?
<mripard> wens: ah no, I was wrong, it has to be programmed to the frequency of the source clock
<wens> the kernel seems to take that frequency x2 as the system bogobips if you use arch_timer
<wens> that's why i was curious
<wens> along with the u-boot PSCI patches setting them to 24 MHz
bbrezillon has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
jacq has joined #linux-sunxi
sehraf has joined #linux-sunxi
Quarx has joined #linux-sunxi
le has quit [Read error: Connection timed out]
le has joined #linux-sunxi
notmart has joined #linux-sunxi
blsd has joined #linux-sunxi
blsd has quit [Quit: Leaving.]
blsd has joined #linux-sunxi
phh has joined #linux-sunxi
<arokux> hi wens and mripard
<arokux> it is with latest linux-sunxi/sunxi-next, on Mele A1000 (A10)
<mripard> so with an emac
<mripard> hmmm
<mripard> I thought we fixed that issue
GeertJohan has quit [Read error: Connection reset by peer]
GeertJohan has joined #linux-sunxi
GeertJohan has joined #linux-sunxi
GeertJohan has quit [Changing host]
<arokux> mripard:
<arokux> After some debugging I've found out that this is bus_find_device
<arokux> which returns NULL, instead of some meaningful value
<arokux> mripard: tell me please if I can find out more for you or what to try out...
<mripard> is this a custom DT?
<arokux> mripard: no, this is default one.
<mripard> ok
<mripard> let me see
<arokux> mripard: everything is default.
<mripard> ok
<mripard> first, try with this patch:
<mripard> it should fix the second oops
<mripard> well, the oops actually
<mripard> what's your configuration file?
<arokux> mripard: do you mean kernel config?
<mripard> yep.
<arokux> mripard: its sunxi_defconfig + ext4 + CGROUPS + FHANDLE + debug output enablement (do not have it right time with me)
<arokux> mripard: I'll try your patch in the evening.
<arokux> mripard: any idea why the device cannot be found on mii bus?
<mripard> make sure you have MDIO_SUN4I
<arokux> mripard: I'll check in my config at home, but running make sunxi_defconfig here will produce CONFIG_MDIO_SUN4I=y
<arokux> mripard: and at home I've seen probing of the emac mdio thing...
<arokux> of this one I mean ./drivers/net/phy/mdio-sun4i.c
<arokux> mripard: let me double check everything tonight.
<mripard> if not, then, it's maybe the phy address that is not right
<mripard> iirc, there's a way to set it to autodetect
<arokux> mripard: wrong address in the dts, you mean?
<mripard> yep
<mripard> you should probably ask Turl
<wens> try putting a phy with address -1, it will trigger of_mdio autodetect
<mripard> I never had that board, maybe it's always been broken
<mripard> wens: ah, thanks.
<wens> that's right
<mripard> it's actually the line 35 that you have to modify
<wens> the reg (address) of the phy, not the mdio bus
<arokux> ok, sorry guys, you know I'm a noob.
<arokux> I'll try out all these things tonight. bbl
<wens> np
<wens> that reminds me, stmmac of_mdio support is still lacking
<arete74> hi i have modify dts for set 2 pin as gpio: one for 1-wire bus and another for standard gpio.Was is the comapitble string for standard gpio?
<arete74> this are my diff dts
<mripard> arokux: what do you want to use your gpio for?
<mripard> hmm
<mripard> arete74: ^
<mripard> arokux: sorry :)
<wens> arete74: if you aren't refenencing the gpio1 pin set, no need to add it
<wens> for example, if you're using it from /sys/class/gpio/export
<arete74> wens: yes i have need use for on/off relay
<arete74> was is the compatible string? i not find an example...the bbb example ose dt overlay!
<wens> arete74: exporting gpio pins to userspace doesn't need compatibles
<wens> you just 'echo NN > /sys/class/gpio/export'
<wens> and you get /sys/class/gpio/gpioNN to play with
<wens> mripard: did you get your hummingbird?
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<mripard> wens: yes, two weeks ago
<mripard> I didn't have time to boot it yet though
<mripard> arete74: and if it's just a regulator, look for fixed-regulator
bonbons has joined #linux-sunxi
diego_r has joined #linux-sunxi
<arete74> wens: i try the command, but the pinmux do not change:
<arete74> pin 268 (PI12): (MUX UNCLAIMED) (GPIO UNCLAIMED)
<arete74> i see the gpio in /sys/class/gpio/gpio1
<mripard> you have to write the gpio number in export
<mripard> so 268 in your case.
<arete74> mripard: echo 01 > /sys/class/gpio/export
<mripard> which will export gpio 1
<mripard> just like you ask it.
<mripard> not gpio 268, which is the one you want
<arete74> mripard: I thought that was the number NN in dts
<arete74> now work fine
<arete74> thanks
issueat has joined #linux-sunxi
deasy has joined #linux-sunxi
shineworld has joined #linux-sunxi
shineworld has quit [Changing host]
shineworld has joined #linux-sunxi
le has quit [Remote host closed the connection]
<arokux> mripard: my GPIO? what do you mean? :)
<mripard> arokux: nothing, it was supposed to be for arete74
<arokux> mripard: oh, sorry.
<arokux> mripard: sorry, just noticed that.
arokux has quit [Remote host closed the connection]
arokux has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
<Black_Horseman> hola
wickwire has joined #linux-sunxi
<arokux> months ago I was working on USB support in u-boot. I never submitted that code... is there an interested in it...?
Quarx has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
<wickwire> Hi guys, I was just playing with libvdpau-sunxi and mali-r3p2-01rel2 on my cubieboard 2
<wickwire> playing sintel's 1080p trailer and at the same time, running glmark2-es2
arend_ has joined #linux-sunxi
arend has quit [Ping timeout: 240 seconds]
<wickwire> after a while, I get choppy video - but no noticeable CPU/mem increase
<wickwire> so, knowing these approaches are experimental, is there something unexpected with my setup maybe (i.e. they should get along)
arend_ has quit [Remote host closed the connection]
<wens> maybe it's just a lack of memory bandwidth
<wickwire> or does anyone know of any possible interferences between libvdpau-sunxi and mali r3p2-01rel2 when using both
<wickwire> I adjusted the uEnv.txt parameter to 128mb
<wickwire> for the video
<wickwire> didn't do anything for graphics
<wickwire> sunxi_ve_mem_reserve=128
<wickwire> if I stop both apps, the desktop background breaks into a weird kind of "dragged" image effect
arend has joined #linux-sunxi
<wickwire> can't quite explain
<wickwire> if I start both apps (mplayer and glmark2-es2), the desktop background is correctly displayed again
arend has quit [Remote host closed the connection]
<wickwire> hmm I think it's libvdpau-sunxi
<wickwire> as my system is right know,
<wickwire> any attempt to playback video results in choppy video playback
arend has joined #linux-sunxi
<wickwire> if I stop mplayer, the whole desktop background gets deformed
<wickwire> I'm using Cubian and installed the libvdpau-sunxi package from Cubian's repos, I think I'll try to build from github and see if there's any change
<arokux> ccaione: hi
<ssvb> wickwire: the desktop background gets deformed?
<ssvb> wickwire: maybe you can make a picture or video?
<wickwire> ssvb: yes I think I can
<wickwire> In the meantime, I purged all libvdpau-sunxi stuff from the cubian repos,
<wickwire> installed libvdpau-sunxi from github
<wickwire> same issue
<wickwire> the windows don't have to be overlapped even
<wickwire> just side by side
<wickwire> ok, adjusted to sunxi_ve_mem_reserve=512 and rebooted
<wickwire> seems stable now
<wickwire> sintel is looping and no choppy video
<wickwire> glmark2 is still running
<wickwire> hmmm mouse pointer is stuck inside mplayer's canvas
<wickwire> can't get it out
<wickwire> :p
TJvV has joined #linux-sunxi
<wickwire> ok, ran the glmark2 app again without stopping mplayer's loop - video got choppy
<wickwire> lost the mouse completely
<wickwire> ok I'll try to film this
<TJvV> Hello, I am having some trouble with USB devices (FTDI and OTG) on an A13 OlinuXino-WIFI board in combination with the 3.4.75-r1 kernel; I was wondering if someone could help me figure out what is going wrong and why?
<TJvV> as it stands, the devices seem to stop responding after a while, but I can't find any traces of failure in my logs
<ccaione> arokux: hi
<arokux> ccaione: you were working on AXP, right?
<ccaione> arokux: yes
<arokux> ccaione: so I do not know if this is AXP, but if I try to reboot my A10 based Mele A1000 it will fail. have you did that part responsible for rebooting already?
<ccaione> which kernel?
<arokux> ccaione: linux-sunxi/sunxi-next
<ccaione> reboot is up to the watchdog not axp, probably something wrong with the latest patches of mripard about the reboot system
<netchip> wat
<netchip> Verizon SGS5 pledge for root access: Total Pledges - $18,470.00
<netchip> wat
<netchip> Geohot got that amount of cash for his root exploit xD
<arokux> ccaione: I see. Thanks. Another question, can I somehow configure power button so it acts like board reset, so I do not need to unplug/plug the power cable. is it something I can use axp support for?
<ccaione> dunno the mele but in the cubiebords the power button is managed by axp so yes you can if that is also the case on mele.
<arokux> ccaione: can you please provide some hints as how to test if the power btn is managed by AXP on Mele?
<mripard> ccaione: yeah, it's my fault
<mripard> or at least
<mripard> the patch I sent and was supposed to be going in 3.16, along with the other reboot related patches wasn't sent...
<netchip> "Now you can do low level development on your tablet, even when on the move. Just don't bring it up in a conversation with normal people if you still want them to respect you afterwards."
<netchip> hehe
<arokux> mripard: I could test it if you like.
shineworld has left #linux-sunxi ["Leaving"]
<mripard> arokux: it's not a matter of testing, it's a matter of a maintainer not doing his job
<arokux> mripard: yes, but I could make sure your patch works on mele :)
<mripard> but it *does* work.
<arokux> mripard: if so, can you tell me where it is? :)
imcsk8 has joined #linux-sunxi
imcsk8 has quit [Client Quit]
imcsk8 has joined #linux-sunxi
<arokux> mripard: thank you
Gerwin_J has joined #linux-sunxi
<TJvV> arokux: I saw your name pop up a number of times in discussions about USB problems; any chance you can help me get a grip on my problems?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
<arokux> TJvV: well... I'm quite a noob, I should say. I worked a bit on usb host, so I know nothing about otg
<TJvV> luckily OTG isn't the only thing that's malfuctioning :P
<TJvV> I'm mostly trying to simply get more output from the drivers so I can hopefully actually see the malfunction on the device itself
<arokux> TJvV: here I can help. here is the page written by me
<arokux> TJvV: there you see what to enable to get the most debug output possible.
<TJvV> cool, recompiling as we speak
<TJvV> bit of a shame that my sure-fire way to reproduce the problem takes quite a while
<TJvV> using the FTDI to drive a 3D printer, which rambles on for about 15 minutes before shutting down
<TJvV> at which point all other USB devices stop responding as well
<arokux> TJvV: I'm afraid I won't be able to help understand what is going on... if you have time you could try mainline and see if it works, but that is not an answer to your original question of course
<TJvV> arokux: for now I'll be happy enough to simply have some debug information. For some reason when I create a modprobe rule to enforce debugging in ftdi_sio, my kernel hangs (again without any information) when booting up
<afaerber> mripard, my U-Boot commands:
<mripard> afaerber: that doesn't match with the logs you provided
<afaerber> mripard, it's the ones I have currently booted from AHCI with. as stated before, UART0 is not working once the kernel switches to the 8250 driver but I can later log in via gmac
<mripard> afaerber: so you don't have the oops anymore?
<mripard> what's the logs shown by dmesg?
<afaerber> mripard, no oops right now, possibly since using 0xffffffff instead of ffffffff - or it's pure luck
<afaerber> mripard, CPU1 fails btw
<wens> you need the PSCI patches for u-boot to get CPU1 up
<mripard> my guess is that the addresses were not right
<afaerber> I had tried both 46/49 as in the Wiki initially and then 48/43 as suggested by ssvb
<mripard> what are you using then? 48/43 or 46 and 49?
<ssvb> afaerber: many different combinations of addresses should be workable, as long as fdt_high is set right
<mripard> and so, what's your actual issue right now?
<ssvb> mripard: if I understand it correctly, this issue is already resolved
<wickwire> ssvb: video is uploading with the "oil painting effect" >
<wickwire> about 10min left
<mripard> ssvb: I don't know, he's saying he has an oops, then no uart, then no oops.
<mripard> I have no idea what he's asking...
<afaerber> mripard, the actual issue is no serial (UART0) output despite console=ttyS0,115200
<wickwire> relevant bits: 0:35 - 1:00 > mouse pointer lockup inside mplayer window + 6:00 onwards
<afaerber> the oops is is not reoccurring for now
<wickwire> if anything, it seems that setting sunxi_ve_mem_reserve=512 delays the issue
<afaerber> it was trying to investigate why it did not seem to boot
tomboy64 has quit [Ping timeout: 264 seconds]
<mripard> afaerber: what's the dmesg output?
jebba has quit [Quit: Leaving.]
<afaerber> line 117 matches the last thing I see with earlyprintk
tomboy64 has joined #linux-sunxi
<ssvb> wickwire: don't know, libvdpau-sunxi might be leaking buffers, you can try to add some debugging print to it just to see how it manages memory over its lifetime
<wickwire> ssvb: ok
tomboy64 has quit [Remote host closed the connection]
<kivutar> what is the reference repos ? github or gitorious?
jemk has joined #linux-sunxi
<mripard> afaerber: it's weird, everything seems fine from the logs
<afaerber> mripard, yeah, I also checked that &uart0 is status = "okay" and node name matches .dtsi; don't know about the GPIOs though
<afaerber> mripard, could some driver reordering be going on that the output arrives on a different UART?
<mripard> what board are you booting it on?
<afaerber> Cubietruck v1.0-0606
<afaerber> and the console= and serial adapter has worked fine for 3.4 kernel and other boards
<mripard> it's probing fine though, so everything's compiled in, the only thing is the muxing that could be changed
<afaerber> (3.4 was pretty unusable with gcc48 though, therefore trying upstream)
<mripard> I don't have a cubietruck though, so I can't really test, but that seems odd that the muxing is not right
<mripard> so others would have noticed
<jemk> wickwire: I reproduced your problem, it looks like something is going terribly wrong with disp layers
<afaerber> mripard, sorry, what does "muxing" refer to here? driver code? dts?
<mripard> pin muxing, each pin has several functions on an SoC, so you have to assign them properly
<mripard> if this is not done right, the driver could work, but the signals wouldn't be "routed" on the pins
<mripard> and yes, that's expressed in the DT
<wickwire> jemk: as far as I could tell, setting less memory aside for the video makes the issue come up sooner, but I didn't test this heavily though
gzamboni has joined #linux-sunxi
<jemk> ssvb: after running es2gears and mpv, then closing both and starting only mpv this happens:
<jemk> wickwire: more than around 256 cant help, ve can only use the first 256mb
<wickwire> jemk: ok I'll tone it down
blsd has quit [Remote host closed the connection]
<jemk> but I suspect its likely we see the consequences of messing with disp from userspace
_massi has joined #linux-sunxi
wens has quit [Read error: Connection reset by peer]
jebba has joined #linux-sunxi
wens has joined #linux-sunxi
Quarx|2 has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
Quarx has quit [Ping timeout: 252 seconds]
<afaerber> mripard, according to the A20 manual linked from the Wiki, UART0 is muxed with IR1 on PB22/PB23
speakman has quit [Ping timeout: 244 seconds]
speakman has joined #linux-sunxi
speakman has quit [Changing host]
speakman has joined #linux-sunxi
xavia has joined #linux-sunxi
<ssvb> jemk: are you fine with ?
arend has quit [Remote host closed the connection]
<ssvb> libv: I'm likely not authorized to rename pages in the linux-sunxi wiki (or I can't find how to do it)
<libv> ssvb: why didn't you say so to begin with :)
Quarx has joined #linux-sunxi
Quarx|2 has quit [Ping timeout: 252 seconds]
<arokux> just interesting is anyone "mainlining" cedarx?
<ssvb> libv: oh, now I found that it is in a drop down menu
<libv> ok :)
Skaag has quit [Ping timeout: 240 seconds]
<arokux> libv: what is going on in Mali world? :)
<jemk> ssvb: sure, go on. that reminds me i wanted to write some more info on some registers
<ssvb> jemk: ok, and I'm also going to document all the registers that are used in the current driver
<libv> arokux: as much as in every other world atm.
enrico_ has joined #linux-sunxi
<arokux> libv: mm... actually I meant Lima
<libv> yeah, i understood that
HeHoPMaJIeH has quit [Remote host closed the connection]
<jemk> ssvb: is this supposed to look like that? fresh reboot, no libvdpau, latest fbturbo, only resized es2gears window:
<ssvb> jemk: not really
<ssvb> jemk: or are you resizing it all the time?
<ssvb> jemk: such glitches may show up during the process of resizing, when the stride becomes wrong for a very short time
<jemk> ssvb: no, resized once, then let alone. moving the window it flickers more
leviathanch2 has quit [Ping timeout: 260 seconds]
<ssvb> jemk: looks strange
<ssvb> jemk: are you using some pre-made sd card image?
<jemk> ssvb: i just wonder if this could be related to wickwires issue
<jemk> ssvb: no, archlinux, latest git kernel/u-boot/fbturbo
<ssvb> jemk: and the monkey background picture? ;)
<ssvb> jemk: which hardware is that?
<jemk> ssvb: selfmade ;) cubietruck, but i also tried on cubieboard1 now, same issue
libcg has quit [Remote host closed the connection]
kz1 has quit [Ping timeout: 260 seconds]
<ssvb> jemk: ok, I'll try to reproduce it later today
blsd has joined #linux-sunxi
<arokux> TJvV: were you able to advance on your problem?
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
leviathanch2 has joined #linux-sunxi
rgenoud has quit [Ping timeout: 240 seconds]
<alexvf> wickwire: ssvb: jemk: i also had issues with layers
<alexvf> in particular, it seems that something doesnt like the first layer being touched
<wickwire> I will also test the es2gears issue
<alexvf> wickwire: do you know how many layers are you using in total?
astr has quit [Quit: Ex-Chat]
<ssvb> alexvf: touched in which way?
<wickwire> how can I validate it?
<alexvf> ssvb: released
<alexvf> wickwire: i don't know what es2gears uses, if i recall mplayer2 uses one or two (depending on VDPAU_OSD environment)
<wickwire> hmmm ok - how may I check this?
<wickwire> I used mplayer and glmark2-es2
<jemk> wickwire: did you ever set VDPAU_OSD=1? if not, vdpau uses one
<TJvV> arokux: not really; it seems that things go wrong when I just let the board run its course. When I'm constantly mucking about with it through SSH, the print job runs to completion
<arokux> TJvV: ...
<TJvV> downside is that running to completion means it runs for 2 and a half hours, whereas letting it crash only takes 20 mins...
<wickwire> jemk: I didn't
vslap has quit [Ping timeout: 260 seconds]
<TJvV> great way to waste time...
<alexvf> wickwire: then, you are using 1 for mplayer, 1 for the desktop, and i know nothing about glmark2-es2 :(
<arokux> TJvV: have you considered switching to mainline? :)
rgenoud has joined #linux-sunxi
<TJvV> arokux: I've considered it; but there was some dependency that required me to use this kernel. Of course I've forgotten which dependency that was...
<alexvf> wickwire: can you check fb0_framebuffer_num in .fex?
<arokux> TJvV: ok.. :)
<TJvV> and it would mean I'd have to recover all changes made so far and re-apply/port them to the new (mainline) kernel to be used
<wickwire> alexvf: fb0_framebuffer_num = 4
<alexvf> wickwire: if im not mistaken, you should have at least the number of layers you are using
<arokux> TJvV: hm.. you are making changes to the kernel?
<alexvf> wickwire: so i guess you are ok with that
<wickwire> oh ok
<jemk> TJvV: what cpufreq governor are you using? Maybe your cpu freq is too low when idle
<TJvV> arokux: mostly configuration; did have to change some code for a proper bootlogo though
<wickwire> I'm just trying to build es2gears to test jemk's issue on my cubieboard2
<TJvV> jemk: I don't know, how can I check that?
<jemk> TJvV: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<TJvV> jemk: performance
<jemk> wickwire: can't glmark2 window be resized? It should happen there too if it isn't only a bug in es2gears
<wickwire> jemk ok I'll check
<jemk> TJvV: ok, thats good. Then that shouldn't be the problem
<TJvV> maybe an auto-suspend issue?
<TJvV> I know it should be turned off for non-hubs by default
jemk has quit [Quit: leaving]
<TJvV> regardless, I have to go now; I'll be back wednesday
<wickwire> jemk: weird as it may sound, I can't seem to resize it
<wickwire> I can resize any other window
<wickwire> wait
<wickwire> nope
jemk has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
<wickwire> I really can't resize i
<wickwire> it
<wickwire> I'm building es2gears from mesa-demos
<wickwire> please let me know if there's a faster way to get the binary for ARM
<wickwire> I searched in Cubian's repos
<wickwire> couldn't find it
Andy-D has quit [Ping timeout: 272 seconds]
rgenoud has quit [Quit: Leaving.]
<wickwire> jemk: I managed to build es2gears
<wickwire> but can't seem to reproduce your problem
<wickwire> I can resize the window,
<wickwire> but the cogs turn normally
<wickwire> the only effect I'm getting so far, is that the cogs scale a little while after I've already resized the window
<wickwire> possibly scaling progressively with each frame as the new window dimensions are defined...?
<wickwire> I'm getting around 400fps
<wickwire> and I used mesa-demos 8.1.0, the tarball from here >
Andy-D has joined #linux-sunxi
<wickwire> although for 8.0.1, it applied successfully on 8.1.0
<wickwire> fps seem related to the scaled size of the window which makes sense
libcg has joined #linux-sunxi
<wickwire> basically, ~400fps with the default dimensions when it starts
<wickwire> (which is quite small)
<wickwire> I'll leave it running, see if it breaks like yours did
pfdm has joined #linux-sunxi
<wickwire> jemk: es2gears resizing ok here
Netlynx has joined #linux-sunxi
bbrezillon has quit [Ping timeout: 245 seconds]
_massi has quit [Quit: Leaving]
bertrik has joined #linux-sunxi
bertrik has quit [Changing host]
bertrik has joined #linux-sunxi
amitk has quit [Quit: leaving]
enrico_ has quit [Quit: Bye]
pfdm has quit [Quit: Page closed]
tomboy64 has joined #linux-sunxi
diego_r has quit [Ping timeout: 264 seconds]
Quarx has joined #linux-sunxi
arokux2 has joined #linux-sunxi
<arokux2> mripard: setting reg of phy to -1 will not compile, dtc doesn't like negative addresses it seems
leviathanch2 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 264 seconds]
bertrik has quit [Ping timeout: 240 seconds]
bertrik has joined #linux-sunxi
<arokux2> mripard: your patch ( fixes oops. MDIO_SUN4I is there, the addresses seems to be unchanged since the times emac worked in mainline fine.
leviathanch2 has quit [Ping timeout: 272 seconds]
<arokux2> wens: you there?
<Turl> howdy :)
<arokux2> oh, hi Turl
<arokux2> Turl: you are the prominent user of Mele A1000, aren't you? :)
<Turl> yeah, but I run 3.4 on it
fredy has quit [Excess Flood]
<arokux2> Turl: maybe you are smart enough to guess what might go wrong if the phy cannot be found on the bus...?
<Turl> you'd get an error message and no network
fredy has joined #linux-sunxi
<arokux2> Turl: right :) but what is the cause of it, not the consequence :p
<Turl> the cause is wrong phy addr? :P or broken hw
<Turl> try setting it to 0xffffffff
<arokux2> Turl: the address hasn't changed and I'm using this hardware to get the kernel over the tftp from u-boot
<arokux2> Turl: [ 0.763034] mdio_bus 1c0b080.mdio-mii: /soc@01c00000/mdio@01c0b080/ethernet-phy@1 PHY address -1 is too large
<arokux2> Turl: #define PHY_MAX_ADDR32
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<arokux2> Turl: ah, the reg should be empty for autodetect!
<Turl> maybe it was some other value that triggered a bus scan hm
gzamboni_ has joined #linux-sunxi
gzamboni has quit [Ping timeout: 240 seconds]
Gerwin_J has quit [Ping timeout: 252 seconds]
<arokux2> Turl: huh
<arokux2> Turl: so to have it autodetected you need to delete the line with reg=<>; completely
<arokux2> and.... it will autodetect it!! :)
notmart has quit [Quit: notmart terminated!]
<arokux2> Turl: however it is not clear at which address it was found, since everything was tried?!
<Turl> maybe later in the log
<arokux2> Turl: on the other hand I see something like this:
<arokux2> Turl: no, nothing later in the log
<Turl> see if you find a reg property in one of those
<Turl> you can test your luck too, address is probably 1 or 2
<arokux2> Turl: shouldn't there be a break instead of continue? o_O?
<arokux2> Turl: the continue will make the execution to go to next iter on the inner for loop won't it?
<Turl> yap
<Turl> I dunno, maybe you can have many phy?
<Turl> then it kind of makes sense
<arokux2> Turl: then why this line at all?
<Turl> link?
<arokux2> Turl: I mean why this if-statement at all
<arokux2> oh sorry, I've thought I've sent it :D
wickwire has quit [Remote host closed the connection]
ninolein has quit [Ping timeout: 245 seconds]
<arokux2> Turl: after defining DEBUG I do see
<arokux2> [ 0.865742] mdio_bus 1c0b080.mdio-mii: registered phy ethernet-phy at address 1
ninolein has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<Turl> that continue looks fishy indeed
<arokux2> Turl: there is another continue just above it.
<Turl> that one looks ok
<Turl> that one is shady as well
Netlynx has quit [Quit: Leaving]
<arokux2> Turl: maybe it is like a statement: "if error do next iteration"
<arokux2> Turl: and what if I tell you that if adding some printk it starts finding the phy? o_O
bgal has joined #linux-sunxi
nove has joined #linux-sunxi
<Turl> timing? missing regulator?
<arokux2> Turl: so there is one printk needed BEFORE and AFTER:
<arokux2> omitting either one will fail
<Turl> sounds like an awful race somewhere
<arokux2> Turl: ok, a couple more tests reveal two printk are needed just at the beginning of that function
<arokux2> Turl: where to go from here? :)
<Turl> make sure the regulator stuff matches the uboot config
<arokux2> Turl: basically delay is needed before this:
<mripard> arokux2: cool, I'll submit it then
<arokux2> mripard: there is an awful issue with emac... if adding two printk everything works........
<mripard> arokux2: two printk where?
<arokux2> mripard: at the beginning of this func:
<mripard> weird
<arokux2> mripard: another question is: what is statement doing? :)
<arokux2> this is unrelated to the bug
<mripard> arokux2: I guess it registers all the phy nodes under the mdio node
<arokux2> mripard: but these statements are noops
<mripard> which stamement?
<mripard> of_mdio_register_phy?
<arokux2> if (rc) continue;
<mripard> ah
<mripard> if (rc != 0) continue;
<mripard> continue being, jump directly to the next iteration of the loop
<arokux2> mripard: right, but this statement is at the END of the loop so it can be omitted?!
<mripard> yep
<arokux2> but being there it makes us asking the question "why it is there?" :)
<mripard> maybe because there was some code after it before
<mripard> that got removed
<arokux2> mripard: could be.
<mripard> I don't know
<arokux2> mripard: anyways, not enough printk will cause this to fail:
<mripard> and if you add some delay to sun4i_mdio_read ?
<arokux2> mripard: in the end of it or in the beginning?
<mripard> I don't know, where were the printk?
<mripard> before or after the function?
<arokux2> mripard: adding msleep(1); at the end of sun4i_mdio_read seems to fix
<arokux2> mripard: checked two times :)
<mripard> it's odd though
<mripard> what was the issue btw?
<mripard> still the phy detection?
<arokux2> mripard: yes
<arokux2> mripard: so phy will not be detected
<mripard> I thought it was autodetecting it?
<arokux2> mripard: adding msleep(1); before this line works:
<arokux2> mripard: autodetecting works. it detects the same address as in dts i.e. 1, but because it tries 0 before trying 1 there is a delay...
<mripard> and increasing MDIO_TIMEOUT?
<arokux2> mripard: fails, even increasing it to 1000. or it is not enough?
<arokux2> mripard: ok, another finding. it does not matter where sleep is, in the beginning of sun4i_mdio_read or in the end of it........
<arokux2> mripard: both will work
<arokux2> mripard: should I find out what fails here?
<arokux2> on the other hand i have nothing else to do...
kivutar has quit [Ping timeout: 240 seconds]
tomboy64 has joined #linux-sunxi
fredy has quit [Excess Flood]
<arokux2> mripard: so phy_id is -1, that is why it is failing......
akaizen has quit [Remote host closed the connection]
<nove> in the blobs, h264 decoding was failing because of allocator wrapper was returning 0x0 for an address, and the blob was writing it to register without checking first if valid
akaizen has joined #linux-sunxi
<nove> more than 10 hours wasted, that is the blob's life
fredy has joined #linux-sunxi
<arokux2> nove: ... :(
<arokux2> nove: is it the last thing that was failing...?
<arokux2> mripard: am I annoying? :) next finding... it works if I put mdelay at the beginning of
<arokux2> mripard: this function is calling sun4i_mdio_read as I understand. so basically it means there shouldn't be any delays in sun4i_mdio_read?
<arokux2> mripard: maybe there should be a delay in sun4i_mdio_probe?
<nove> arokux2: what to expect from blobs, is a gamble in each dumping, it is really trying all until find one that magically works
<mripard> arokux2: I don't know, it depends on wether you need the delay only once or at each reading
<arokux2> mripard: as said, one before both readings helps
<mripard> then in sun4i_mdio_read I guess
<arokux2> mripard: why? if it is needed before reading then in _probe, no?
<mripard> you said you needed the delay several times...
<arokux2> mripard: no, only once (those were printk I needed several)
<mripard> I don't understand anything you're saying then. Send a patch that makes things work.
<arokux2> mripard: ok, here is summary. having a msleep(1); in _probe just after enabling the regulator works.
Andy-D has quit [Ping timeout: 240 seconds]
<mripard> and if you could cross-test this with someone else that has a mele to get if it's just your board, and what is actually going on, it would be great
<arokux2> Turl: ^^^^
<Turl> arokux, waiting post regulator for it to settle makes sense
<Turl> post regulator on*
Andy-D has joined #linux-sunxi
<arokux2> mripard: Turl so here is the patch:
<Turl> sleep post error check
<Turl> and add a comment so it's not a magic sleep
wickwire has joined #linux-sunxi
<arokux2> Turl: ah, post error, right. so now this looks fine? :)
<arokux2> Turl: I do not know other users of Mele A1000 than you... so maybe you could give it a try?
<nove> jemk: not much new, other than than anaglyph registers are now been cleared, and in encoder isp has "thumbnail output" enabled
<arokux2> nove: what are you doing at the moment with this stuff?
<nove> arokux2: this is making the more recent blobs(version 1.2) usable for tracing
<arokux2> nove: I see.
kivutar has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
<Turl> change the comment to something like "wait for the phy to settle"
<arokux2> Turl: ok...
<arokux2> Turl: :)
<mripard> and add a new line before the comment
<mripard> and then you can send it
<arokux2> mripard: no problem.
<Turl> send it and I'll test it soon
<arokux2> oh, thank you Turl. I think you need to have the exact same version of the kernel and same config... so I'll provide them for you.
akaizen has quit [Remote host closed the connection]
bbrezillon has quit [Ping timeout: 244 seconds]
akaizen has joined #linux-sunxi
jacq has quit [Ping timeout: 240 seconds]
akaizen has quit [Ping timeout: 264 seconds]
ganbold has quit [Remote host closed the connection]
rz2k has joined #linux-sunxi
setkeh has quit [*.net *.split]
tm512_ has joined #linux-sunxi
tm512 has quit [Quit: Just relax and enjoy this pleasant adventure]
TheSeven has quit [Ping timeout: 252 seconds]
libcg has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
<arokux2> Turl: I'm puzzled... it seems I have enabled everything for the usb, but usb stick is still not appearing. so i'm taking a look at regulators...
jemk has quit [Quit: leaving]
<arokux2> Turl: and they are disabled.
setkeh has joined #linux-sunxi
<arokux2> Turl: but how can I enable them if they are read-only?
<arokux2> -r--r--r-- 1 root root 4096 Dec 31 17:04 /sys/class/regulator/regulator.4/state
akaizen has joined #linux-sunxi
<rz2k> call regulator_enable/regulator_bulk_enable for the names of regulators?
<rz2k> did not really follow your discussion, but you can find typical examples of this routine all over simple drivers like i2c/spi sensors.
<rz2k> dont forget to declare regulator consumers, of course.
<arokux2> rz2k: everything is supposed to be correct in the code. i just need to figure out how to turn it on...
<arokux2> rz2k: ever run a recent mainline?
<rz2k> do you have errno's from regulator core when you do 'enable'?
<arokux2> rz2k: that is the point. how do I do 'enable'? :)
<arokux2> rz2k: I thought by echoing, but these files are readonly
<rz2k> you enable and disable regulator consumers wich are linked to regulators themselves, when there are 0 regulator consumers enabled, if regulator is not declared as 'always_on', linux will shut it down as useless. you must have a proper setup routine in your .c of the driver. example
<rz2k> regulator consumer name should be obviously declared in devicetree/whatever
<rz2k> fiddling with sysfs is not a good idea and it is there to get you a debug info
<arokux2> rz2k: you see, I'm now using this code. I'm not developing anything. I'm just running this kernel and see that USB is dead. and so I'm asking myself it that regulator is enabled.......
<rz2k> hmmm
<rz2k> is your board 1:1 to the other popular sunxi boards?
<arokux2> rz2k: yes, I'm the one who developed that usb driver in the first place :)
<arokux2> rz2k: it was than adapted and mainlined. I'm maybe missing some config.....
<rz2k> I remember some mele boards had interesting way of switching off vbus, that caused trouble at 3.0 times :)
<rz2k> like they had a gpio to connected to fet or something like that.
<arokux2> rz2k: yes, so they are represented by these regulators
<arokux2> ah, maybe this is something else
<arokux2> rz2k: do you have mainline running?
<arokux2> rz2k: with usb working? :)
<rz2k> just got my boards yesterday from old place, did not check out 'nowdays' mainline, but I've ran cubietruck on mainline couple months ago and had usbflash working.
<rz2k> if I remember correctly, ofcourse.
<gaby> hi ! Is there someone working on the mainlining of the sunxi display driver ? I would like to use it, if there is some tree I can use, at least to test a little
<rz2k> try to enable regulator core full debug and trace whatever happens there
<rz2k> gaby: libv was doing sunxi-kms driver, but it was pointed forward sunxi-3.4
<arokux2> rz2k: seems to be fine... reg-fixed-voltage usb1-vbus.1: usb1-vbus supplying 5000000uV
<arokux2> but state is disabled, weird
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
FR^2 has joined #linux-sunxi
<arokux2> rz2k: I've remembered how to know for sure the regulator isn't enabled... the led on the usb sitck will not be on :)
<arokux2> so now I now. the regulator isn't enabled.
<arokux2> now I know*
<gaby> rz2k: in fact I need to be able to launch it on recent kernels, I don't really care if its correct or not, I just need to have device tree support instead of the fex thing
<arokux2> gaby: you are using mainline? do you have usb working?
<gaby> don't know, never tried it :)
bgal has quit [Ping timeout: 255 seconds]
<arokux2> gaby: you could stick in a usb stick
<Turl> arokux2: make sure you enable the usb phy config thingy apart from the platform usb stuff
<gaby> arokux2: I do not have the board on me. I'll try that tomorrow
<arokux2> Turl: ... that might be it....
<arokux2> Turl: it should get enabled by default if I enable usb hcd :(((
sehraf has quit [Quit: ... be part of it...]
<Turl> arokux2: usb hcd is generic
<Turl> imagine if you're using a imx board and it turns out the sunxi phy thingy :P
<Turl> the opposite may e handy though
<Turl> be*
<arokux2> Turl: you know what should have been enabled... you'll never guess
<arokux2> you were right... but it cannot be enabled directly
<arokux2> Turl: you should enable USB Physical Layer drivers -> GPIO based peripheral-only VBUS sensing 'transceiver'
<arokux2> fuck!
<arokux2> Turl: ok..... it still will not work.
<rz2k> gaby: do you have time to ctrl+c/v current display driver from 3.4 to mainline replacing .fex with device tree?
<rz2k> and figuring out the new DMA and missing clks?
<gaby> rz2k: that what I intend to do if nobody have started it yet
petr has quit [Ping timeout: 255 seconds]
<rz2k> awesome, I was thinking about trying to do it, but I dont think I can handle it
<Turl> arokux2: eh, no that's not it
<arokux2> Turl: yep! just found out...... :D
<arokux2> Turl: good i'm not on the airplane :)
FreezingCold has joined #linux-sunxi
<arokux2> Turl: hurray! it works! thanks :)
<Turl> arokux2: np :)
<arokux2> Turl: I'm thinking how to make it more user friendly
<gaby> I don't know anything about arm and such, but I'm stuck if I don't try that, so...
<rz2k> arokux2: just to be clean here, did you have messages about dummy regulator provided instead of real one for usb_vbus?
<arokux2> rz2k: no! that is the point
<Turl> rz2k: I believe there's no dma involved in disp
<rz2k> arokux2: then its time to add 'depends' to the Kconfig
<rz2k> :)
<arokux2> even more funny I had reg-fixed-voltage usb2-vbus.2: usb2-vbus supplying 5000000uV
<arokux2> although it was false
<rz2k> would be interesting to figure out the call chain that gives supplying state for regulator that has no subsystem connected to the other side of it
<Turl> arokux2: user friendly? fix the defconfig :)
<arokux2> Turl: give me a hint how...
<arokux2> the point is usb is implemented though USB_EHCI_HCD_PLATFORM
<arokux2> a very generic thing.
<Turl> I think mrialready sent some patches to do that
<arokux2> Turl: should there be "default y if (USB_EHCI_HCD_PLATFORM || USB_OHCI_HCD_PLATFORM) at CONFIG_PHY_SUN4I_USB ?
kz1 has joined #linux-sunxi
<arokux2> Turl: just checked, mripard seems hasn't sent anything about it
<Turl> mripard*
<Turl> arokux2: that would turn it on for all platforms using hcd platform
<Turl> what I was suggesting was making sure sunxi_defconfig/multi_v7_defconfig enable the USB PHY config
<Turl> and I think mripard sent some patches to dothat
<arokux2> Turl: ah
<Turl> sorry for horrible latency and typos, I'm on a bus :)
<arokux2> Turl: no prob! well one could make default y if (sunxi and if usb things)
bertrik has quit [Remote host closed the connection]
<arokux2> I'll wait till mripard replies though.
<Turl> arokux2: another possibility would be to make the phy select the usb hcd thing
<Turl> or to make a new kconfig node like 'sunxi usb driver' that people can use to select both the hcd platform stuff as well as the phy driver
<arokux2> Turl: the point is you are normally selecting the other way around... you are selecting USB support and suppose is should just work
<Turl> but imo just fixing the defconfigs would be enough
bonbons has quit [Quit: Leaving]
<Turl> and maybe making a wiki page lsiting all the kconfig options concerning sunxi
maksimlin has joined #linux-sunxi
<Turl> arokux2: want to help me with such a wiki page? :)
<arokux2> Turl: yes, no problem. I'm basically creating such a page for myself. but before jumping on it I'll wait till it is discussed with the others :p
<Turl> arokux2: 19:20 rz2k> arokux2: just to be clean here, did you have messages about dummy regulator provided instead of real one for usb_vbus?
<Turl> 19:20 arokux2> rz2k: no! that is the point
<Turl> fuu :p
<Turl> arokux2: if you already started, even better :)
<Turl> go ahead and create it
<arokux2> Turl: yes, I've started in a text file :)
<arokux2> Turl: what about rz2k notice. do you think those regulators should report as working when they are not?
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
<Turl> arokux2: what notice?
akaizen has quit [Ping timeout: 255 seconds]
<arokux2> Turl: there shouldn't be something like this if regulator isn't enabled
<arokux2> Turl: reg-fixed-voltage usb1-vbus.1: usb1-vbus supplying 5000000uV
kivutar has quit [Ping timeout: 240 seconds]
xavia has quit [Quit: Leaving.]
<Turl> arokux2: that's just the standard printout when a fixed regulator is probed
<Turl> search supplying in linux/drivers/regulator/fixed.c
<arokux2> Turl: oh.. ok.
<Turl> arokux2: maybe you could augment with ", disabled" or ", enabled" depending on actual state
<arokux2> Turl: now I see. this message is misleading :)
<Turl> but dunno :)
<arokux2> Turl: I do not think I have enough weight to push patch like this :D
<arokux2> Turl: what about NAND, somebody was working on it...
<Turl> yes, Boris
<Turl> he doesn't seem to be online now
<arokux2> ok
FR^2 has quit [Quit: Leaving]
rz2k has quit []
nove has quit [Quit: nove]
<afaerber> arokux2, usb> my USB stick got recognized okay on Cubietruck with -rc2
wickwire has quit [Remote host closed the connection]
<afaerber> uses ohci-platform
<arokux2> afaerber: yeah, mine too after proper config was set... :)
<afaerber> arokux, mainline state is much better than the Wiki says ;) despite some warts
issueat has quit [Remote host closed the connection]
<arokux2> afaerber: yeah, USB was done by myself :p it was later adapted by some other guy and submitted
<afaerber> arokux2, well then thanks a lot for your work!
<arokux2> Turl: sd card works, usb works, network works, wifi works on mele a1000 :) you can switch to mainline :)
<arokux2> afaerber: you are welcome :)
<Turl> arokux2: yeah
<Turl> I'll probably do that
<Turl> 3.4 has more sensors stuff though, and I was using that :p
<arokux2> Turl: yeah, best time, now that I fixed last glitches and backed nice config :p
<Turl> unless that got in with the axp patches from ccaione
<arokux2> Turl: baked*
* afaerber was hoping to test and possibly contribute to Lima, but no much luck with sunxi-3.4 - guess it'll take some more effort to get graphics with mainline
<Turl> afaerber: no luck? why?
<Turl> 3.4 works fine
<afaerber> Turl, my distro has gcc 4.8, and I kept getting weird memory corruption issues after boot-up. 3.16-rc2 is really stable by comparison
<afaerber> didn't get my hands on a gcc47 yet
<Turl> afaerber: grab one from codesourcery or linaro
<Turl> afaerber: and spare yourself the pain :)
<Turl> wget, untar, tada!
deasy has joined #linux-sunxi
<afaerber> can't package a binary kernel though. building it against an older distro version might work, but writing a full spec file seemed too much effort initially ;)
<arokux2> afaerber: why package?
<arokux2> afaerber: you can get along without packaging. all you need it to copy uImage and modules to the proper places
<afaerber> arokux2, personally I can, and that's what I'm doing right now. but for our distro we package per-device JeOS images for SD card installation, and I was trying to clean up some existing packages
<arokux2> afaerber: ah, ok, I thought this is for hacking only :)
maksimlin has quit [Read error: Connection reset by peer]
<arokux2> alright. good night guys.
<Turl> night arokux2
arokux2 has quit [Quit: Leaving]
Nyuutwo_ has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 264 seconds]
petr has joined #linux-sunxi