ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
Turl has joined #linux-sunxi
<hno> bhoj, I have not studied A31 yet, but if it's anything like the A10/A13 in boot order then SD card boot is before it even touches NAND.
<hno> bhoj, we do not yet have an SPL for A31.
<wowon> hno : Could you please tell me why my A10 based tablet could not boot smoothly from Sd card ? it boot from SD card ... but not smooth. I mostly need to do 'reset' for it to able boot from SD card. And so the reboot mostly stuck.
<hno> wowon, both A10 and u-boot SPL is a bit picky about what SD cards you use. Try another card brand/model.
<wowon> hno : Thankyou for your help ... I'll try that
<hno> For example it seems some cards are too slow for the A10 to see them at power on, requiring a soft reset to detect the card.
<wowon> hno : roger that
Wetomelo has joined #linux-sunxi
Wetomelo has left #linux-sunxi [#linux-sunxi]
BJfreeman has quit [Quit: had a good time]
resistencio has joined #linux-sunxi
<resistencio> hello
<wowon> yup
rz2k has joined #linux-sunxi
resistencio has left #linux-sunxi ["Ex-Chat"]
aholler_ has joined #linux-sunxi
aholler has quit [Ping timeout: 248 seconds]
TheSeven has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
<bhoj> hno, thanks for the info.
bhoj has quit [Remote host closed the connection]
bhoj has joined #linux-sunxi
rz2k has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
BJfreeman has quit [Client Quit]
christopher has quit [Quit: Leaving]
<wingrime> where is CedarX register space?
<wingrime> who have a fun with Cedar?
rellla has joined #linux-sunxi
rellla has quit [Quit: Nettalk6 -]
shineworld has joined #linux-sunxi
n01|work|afk is now known as n01
<shineworld> why sometime the kernel build have a + (plus) and something haven't ? For eg: 3.0.62+ vs 3.0.76
<shineworld> *sometime
Dreadlish has joined #linux-sunxi
<oliv3r> lkcl: does it Decompile arm? my less legal version of 6.1 has the arm decompiler plugin, but only seems to decompile x86 to pseudocode
<wingrime> oliv3r: I have some news
<oliv3r> shineworld: was nofi; I was just thinking, if libvecore is a dedicated arm core, (other then it being a wasted resource when not decoding) it probably would need firmware, and haven't found it as of yet
eebrah|away is now known as eebrah
<wingrime> oliv3r:ping
<oliv3r> ssvb, not shine
<oliv3r> wingrime: sorry was reading backlog
<oliv3r> what's that? mmiotrace?
<shineworld> I guess :)
<oliv3r> wingrime: Mmiotrace was built for reverse engineering any memory-mapped IO device
<oliv3r> oh!
<rm> shineworld, + means "built from source with some commits or changes past this version"
<shineworld> thanks for info
<oliv3r> wingrime: nly x86 and x86_64 architectures
<oliv3r> are supported.
<wingrime> crap
<oliv3r> feck :(
<oliv3r> lol
<oliv3r> wingrime: that or, simply put, memory map a chunk of 'my' memory, call the function (like InitJpegHW() for example) and see what it writes where
<wingrime> we need some one to dump IO map
<wingrime> VE Engine IO space
<oliv3r> I guess we can even fake SRAM in memory?
<oliv3r> just need to learn a lot, and mostly; need a lot of time
<gzamboni> hi, does anyone managed to make network boot work ?
<gzamboni> i am getting a kernel panic
<gzamboni> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000007
<gzamboni> i am getting also this two lines before: <6>Switched to NOHz mode on CPU #0
<oliv3r> sorry, no
egbert_ is now known as egbert
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<hno> lkcl, I should get the package today.
<hno> gzamboni, sunxi kernels is not stable with CONFIG_NO_HZ last time I tried.
<gzamboni> i am doing some try outs here :)
<hno> wingrime & oliv3r, I would suggesting looking into what libv did for lima. The MALI libraries is also using a lot of mmap:ed accesses.
<lkcl> hno: magic.
<hno> lkcl, is there something running on the board? Or is the NAND image in bad shape?
* hno remembers lkcl said he played with livesuit
BJfreeman has quit [Quit: had a good time]
<oliv3r> hno: wingrime is allready making my ears smoke with details that are far beyond me :p
<oliv3r> libv: ping
<hno> oliv3r, If I am not mistaken it's this LD_PRELOAD wrapper:
<oliv3r> hno: glancing over it, it takes the mali calls, does something with them and forwards them to the kernel?
<oliv3r> ah, i see
<oliv3r> it hijacks mmap, ioctl and open from libc, i thought the driver would make direct kernel syscalls, bypassing libc, silly me
<oliv3r> but in the case of cedarX, we actually have the driver, so we can hijack code directly there? :) libv :D
<hno> oliv3r, I have not studied it in detail, but it obviously tracks mali mapped memory and ioctl accesses.
<hno> oliv3r, mali kernel part is also open.
<oliv3r> hno: then i'm curious why libv choose that approach
<oliv3r> probably because its easier to combine everything in 1 wrapper
rellla has joined #linux-sunxi
<hno> it is a lot easier to study things in userspace.
<hno> for one thing you can easily dump the trace in a file.
<oliv3r> so will always use libc/libbionic for those calls right? there's no way it does some realy special things via cedar.ko?
<oliv3r> or otherwise
<hno> it's very very unlikely it does direct syscalls.
<oliv3r> but technically possible?
<oliv3r> not that I doubt you ;)
<hno> but if it mmaps I/O space then maybe there is hardware actions which do not involve a syscall at all.
<oliv3r> such as?
<hno> yes ofcourse it is technically possible to make direct syscalls, but requires a bit of inline assembly and gets quite messy with no gain to the developer.
<oliv3r> then it's even more unlikly
<oliv3r> :p
<hno> mmap:ed I/O space can do anything the I/O module can. See for example pio.c in sunxi-tools. It has mmap support for playing directly with PIO (gpio etc) bypassing the kernel.
<oliv3r> fel-pio you mean?
<hno> No, just pio.c built natively for sunxi.
<oliv3r> ah okay
<hno> fel-pio is a wrapper to access PIO via FEL. Same program used in both cases for manipulating the PIO state but on case of fel-pio pio.c runs on the host and not the sunxi board (only a little fel wrapper runs on the sunxi board then to dump/restore the PIO state)
<hno> It is possible to track even such I/O operations but requires some clever use of mprotect() in the LD_PRELOAD wrapper to trap accesses.
<oliv3r> doubt that'll be needed thought
<ssvb> wingrime: the kernel based tracer for cedarx is also going to work if you implement it for arm and if you don't like the existing userland solution so much
<hno> Do the kernel module provide mmap access to I/O space or only SRAM?
<wingrime> we can mmap to any file instead driver
<wingrime> and try trace reg access
<ssvb> wingrime: that's the old news :)
<oliv3r> ssvb: i think iainb was a) wrapping android, b) was using very old wrappers
<ssvb> oliv3r: have you actually tried it?
<oliv3r> hno: you mean if cedarx.ko maps only IO or both IO and SRAM? on sun7i readl is basically exposed via an IOCTL, so I guess anything goes; it's less clear (to me) how sun4i does sram
<ssvb> oliv3r: it has a few bugs, but it surely can works in linux
<oliv3r> ssvb: oh no i haven't ;p
<oliv3r> i'll deffinatly use it as a base (if i continue with this, again, so much to do, so little time )
<ssvb> oliv3r: just the buffer at is a bit too small and thumb2 instructions can't be traced
<ssvb> oliv3r: but this is fixable
<oliv3r> aye
<oliv3r> do we know if uses thumb2?
<ssvb> oliv3r: the latest available linux armhf linux blob (the buggy one) is using thumb2
<oliv3r> bummer :(
<gzamboni> hno: i disabled CONFIG_NO_HZ and i still cant boot from the nfs share at my dev pc.
<n01> gosh, anyone willing to offer me a job?
<hno> gzamboni, that's crashing during fbconsole initialization it looks like.
<ssvb> oliv3r: if you are analyzing the disassembly of, then you should find a lot of details pretty fast
<oliv3r> n01: hum?
<oliv3r> ssvb: I was, both android and linux versions
<ssvb> oliv3r: at least the details about how the decoding is set up are the first priority
<oliv3r> ssvb: i wrote up what I know so far up on linux-sunxi
<oliv3r> ssvb: also traced out calling graphs for jpeg
<oliv3r> Just trying to find a way to put it up on the wiki
<n01> oliv3r: lol, I am fed up with my current job, just complaining about life :D
<oliv3r> n01: lol i see :)
<gzamboni> :( nfs boot would avoid me from removing and putting the sdcard in each change.
<hno> gzamboni, try disabling fbconsole in your kernel build.
<gzamboni> let me try
<ssvb> oliv3r: good, it's nice to see some progress
<oliv3r> ssvb: heh, it's making my head smoke though; so dunno if there's progress really, or if there will be more :p
<oliv3r> ssvb: want to setup my cubieboard and test some drivers first :)
<ssvb> oliv3r: about the "firmware", I think it must be somewhere because this thing seems to be programmable (the decoding bugs exposed by decoding certain video formats can be fixed)
<oliv3r> ssvb: i haven't found anything resembling it yet
<ssvb> oliv3r: when doing code coverage tests, are all the relevant functions executed on the cortex-a8 core?
<oliv3r> ssvb: que? :D
<ssvb> oliv3r: using valgrind or something else, you can do some tracing and check which parts of code were involved
<oliv3r> ah, i have no clue, am studying the asm :)
<ssvb> oliv3r: you mentioned that you looked at jpeg, are you able to decode jpeg images using libvecore api and some simple test program?
<oliv3r> ssvb: i looked at asmbly only
<oliv3r> haven't compiled anything
<oliv3r> only documenting/investigating
<rellla> ssvb: weightp=1 issue isn't there with libhybris/android, right?
<ssvb> rellla: yes, it's fixed with libhybris/android
<rellla> oliv3r: :P
<oliv3r> rellla: ok i was wrong! :p
<oliv3r> but don't tell AW about libhybris yet, or they'll just wrap their android lib in libhybris and stop caring about native linux libs
* rellla deleted the last line ....
<ssvb> oliv3r: only looking at the code without trying to trace it is not very efficient
<hno> Ah, nice. didn't remember CedarXWrapper.
<gzamboni> hno: still didnt work. Do i have to remove the virtual memory paging ? i have a paging error now:
<oliv3r> ssvb: well it's a combination of looking at assembly, and learning how to use IDA :)
<rellla> i got answer from allwinner. any questions i should include in my response?
<oliv3r> ssvb: next step is trying if we can mmap a file and call InitJpegHw();
<hno> gzamboni, it's still failing in the same place.. which has nothing at all to do with NFS booting.
<ssvb> oliv3r: maybe try some simple video codec first, such as mpeg1? make a simple test program, trace it and disassembly the relevant parts
<oliv3r> ssvb: i think jpeg might be simpler, and i belive only mpeg2 and 4 are supported, didn't see any mpeg1 references yet
<gzamboni> the only changes i did to the sun4i defconfig is CONFIG_IP_PNP=y and CONFIG_ROOT_NFS=y
<ssvb> oliv3r: what about MPEG2_SUB_FORMAT_MPEG1 in libve_typedef.h ?
<oliv3r> ssvb: pff :p
<oliv3r> ssvb: that's the easy way
<hno> gzamboni, yes, the kernel is not supposed to crash like this.
<ssvb> oliv3r: I like your confidence :) keep it up
<oliv3r> ssvb: you really think mpeg1 is easier then jpeg?
shineworld is now known as shine|coffee
<wingrime> ssvb: mpeg coder do jpeg
<wingrime> as I noticed now
<ssvb> wingrime: yes
<wingrime> I understand InitJpegHw now
<wingrime> code like crap
<oliv3r> lol
<oliv3r> i am NOT supprised
<wingrime> it call ve_get_reg_base_addr every time he want write /read some regs
<wingrime> look like thay make macros
<wingrime> we can trace it easy
<oliv3r> wingrime: so jpeg encoder uses mpeg1 Video Engine?
<wingrime> yes
<wingrime> see
<wingrime> InitJpegHw write some values to regs: to VE_BASE + 0x1c0 , 0x11B , 0x180 (in whait loops ??) than 01d0
<wingrime> in order
<wingrime> 0x100 is MPEG base
<gzamboni> hno: i'm using linaro's gcc 4.8, i heard you had some problems with v. 4.8
<ssvb> wingrime: ah, you mean mpeg (not mjpeg), but it still makes sense because they all are based on 8x8 idct
<oliv3r> wingrime: so what was 0xc00 that we saw earlier
<oliv3r> ah yeah, I saw that
<wingrime> I mistaken with this - it look like strange way to export IVEControl_t;
<wingrime> 0x180 - look like some READY register
<wingrime> or simular
<oliv3r> lemme go read a little about mepg1
<oliv3r> and how it relates to jpeg
<wingrime> it relates
<oliv3r> aye
<wingrime> mpeg and jpeg are use same FFT
<oliv3r> fft, dct and idct are the most computational functions are they not
<oliv3r> so if INitjpeghw etc calls mpeg functions, the interesting stuff is probably in mpeg decoder :)
<ssvb> more like huffman is the real bottleneck (with software decoding), because it can't be easily vectorized for using SIMD
<ssvb> DCT/IDCT are very cheap when using NEON or SSE2
<oliv3r> is mpeg1 a special case of mpeg2?
<oliv3r> i recal writing a software jpeg decoder once, without using simd or anything, and dct/idct where far the most expensive opperaton
<wingrime> I may be make pseudocode for InitJpegHw late
<oliv3r> i do think that does huffman tables (or something) in software
<wingrime> but InitJpegHw read some values form structures inited before
<oliv3r> yeah, lots of vars are global
<oliv3r> InitJpegHw is called from JpegDecodeHW(); which is called by JpegDecodeMain() iirc
<wingrime> to test InitJpegHw you need simpy can dump 0x100-0x200 addressed on ve_get_reg_base
<oliv3r> and JpegDecodeMain() calls get_markers() which is straight from libjpeg and probably fills global structs
<wingrime> we have working example for jpeg decoding
<wingrime> ?
<ssvb> oliv3r: however when I tried to profile video decoding (using perf), I did not notice any significant CPU usage attributed to
<ssvb> oliv3r: this is what made me think about a dedicated code which could do huffman, bitstream reading, etc.
<ssvb> s/code/core/
<wingrime> ssvb: we have code example that tested for jpeg decoding
paulk-desktop has joined #linux-sunxi
<wingrime> ?
<oliv3r> ssvb: and it's not possible/likly that they wrote several huffman routines in hardware?
<oliv3r> ssvb: well we did fine ff_build_huffman_tree() etc
<oliv3r> so something like that is done in software at the least
<oliv3r> wingrime: I don't know, I would not be supprised if we did not
<ssvb> oliv3r: variable length decoding (for huffman or anything else) should be somehow accelerated, or it will easily become a bottleneck
<oliv3r> i haven't looked much into huffman, only saw some references
<oliv3r> if only we had docs, if only we had info to the hardware :(
<wingrime> add printf for mpeg regs dumping or file write
<oliv3r> All standards-compliant MPEG-2 Video Decoders are fully capable of playing back MPEG-1; interesting :)
<wingrime> as AW call this before every access to VE
<oliv3r> wingrime: is their crappy implementation actually an advantage to us? e.g. every single reg call; makes it easier to RE?
<wingrime> yes,
<wingrime> it REALY call this every time it write byte to MMIO
<ssvb> oliv3r: but jpeg restart markers are a pita and inhibit huffman optimizations, so I guess this might be done entirely in software
<ssvb> wingrime: just take the freaking tracer and run it
<wingrime> JpegHwDec aslo call this every time
<oliv3r> wingrime: makes sense, JpegDecodeRaw() { SetJpegFormat(); InitJpegHw(); JpegHwDec(); } is basically what is done
<wingrime> but it not all
<oliv3r> FillJpegHuffmanTable()
<wingrime> read_markers
<wingrime> first_marker
<wingrime> get_dqt
<oliv3r> yeah, but that's all mostly libjpeg() stuff
<wingrime> get_dht
<oliv3r> I doubt they changed much/anything there
<wingrime> get_sof
<oliv3r> but atleast that leaves us with reference code
<wingrime> next_marker
<oliv3r> get_soi() is dfeined, but not even used :)
<ssvb> oliv3r: does it mean that you might have found the firmware? :)
<oliv3r> ssvb: lol all the other get_ sources are called, but i think they simply used jdmarker.c and didn't bother with get_soi();
<oliv3r> get_soi() is 5? assembly lines so I doubt that's the firmware :p
<ssvb> oliv3r: yeah, it is possible that there is some dead code
<wingrime> Jpeg maybe deadcode
<oliv3r> lol
<wingrime> H264 for example not call get_base every time
<oliv3r> FillJpegHuffmanTable looks quite expensive, but only done on init; I wonder how much performance impact mjpeg has, as that does a lot of jpeg decoding
<ssvb> oliv3r: make a simple test program first :)
<oliv3r> yeah, that's probably next on the list :D
<oliv3r> from my inital mpeg2 readings, it's based on mpeg2, so jpeg may aswell use mpeg2 Video Engine
<oliv3r> since jpeg does YUV4:4:4 and YUV:4:2:2, but mpeg1 only does YUV:4:2:0 (thought that is the most common jpeg colorspace)
<wingrime> olvi3r: it possible use small amount abilites form mpeg engine
<oliv3r> if I would write a hardware accelerator with my little knowldge
<oliv3r> i'd do components tbh; like huffman, idct, fft, motion estimation I think can be done too
<oliv3r> all seperate functions that could work with tons of codecs
<oliv3r> but that's just me :)
shine|coffee is now known as shine|listeningj
shine|listeningj is now known as shine|list_jazz
<ssvb> oliv3r: the problem is that coordinating the work of all these components and passing data around may be pretty expensive
<oliv3r> maybe, but in the case of the A10, you load 'data' into sram, i would not be supprised that the video engine does its work on the sram
<oliv3r> so something like transform_colorspace(); for example, would do this in hardware on the sram. it's up to the client to retrieve this data/modfiy this data, or to call the next operation
shine|list_jazz has quit [Quit: Leaving]
<oliv3r> you just leave the data in sram while it's being processed
<lunra> In the case of the FFT, it would be nice if you could queue up a large FFT job, call doFFT() and the process is blocking until the coprocessor completes the task, but I'm not sure how you'd go about implementing that without some serious kernel hax
<oliv3r> when everything is done, you replace it with the next bit
shineworld has joined #linux-sunxi
<oliv3r> lunra: it's done in userpsace atm
<ssvb> oliv3r, wingrime: are there really no attempts to get the address of some chunk of code and copy it somewhere to a fixed hardware address (to SRAM or anywhere else)?
<oliv3r> ssvb: but this flexibility would allow you to use any 'component' of the hardware, to be used for anything else (who knows what)
<lunra> like some kind of while(!*done_flag)sched_yield(); or something within the client program?
<oliv3r> ssvb: i just saw references to SRAM, which is likly, since C1 is VE sram
<ssvb> oliv3r: even if the data exchange is done via SRAM, the timing between kicking different hardware blocks (waiting for completion of one block before kicking the other) would be a bit of a challenge
<ssvb> oliv3r: a dedicated core could just sit in a busy loop
<lunra> It would be nice if we could find a raise interrupt flag so that the coprocessor does not have to busy loop. Anyway I best stop being an armchair soldier here XD
<rm> ARM chair!
<lunra> haha rm :D
<lunra> brb, integrating a cubieboard in my chair
<oliv3r> I-frames can be considered effectively identical to baseline JPEG images
<oliv3r> there we go
<oliv3r> now i undrstand
hipboi|cubie has quit [Ping timeout: 256 seconds]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
vicenteH has joined #linux-sunxi
sankasan has joined #linux-sunxi
<libv> oliv3r: did ianb not choose the right tools?
<oliv3r> libv: i think most of those questions have answered themselves partially
<oliv3r> but where IS ianb! :(
hipboi|cubie has joined #linux-sunxi
<libv> oh, and capture, then replay, then reproduction
<oliv3r> aye, if only we had full cedar register level documentation, that would help a bunch
<oliv3r> but i gota work on some other things first :S as I said, soo much to do, so little tim
<ssvb> rellla: btw, about allwinner's cedarx replay, did it look like they are willing to cooperate?
<oliv3r> trying to reproduce initially
<ssvb> oliv3r, wingrime: if you are really committed to reverse engineering cedarx, I can help you with the ianb's hw registers access tracer
<oliv3r> i'm affraid i'm atm lacking technical knowledge and rather focus on a10 'regular' support?
tinti has quit [Read error: Connection reset by peer]
hansg has joined #linux-sunxi
BJfreeman has quit [Quit: had a good time]
rz2k has joined #linux-sunxi
<hno> gzamboni, yes,the kernel crashes & burns for me with 4.8. 4.7 works fine.
Undertasker has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
vicenteH has quit [Ping timeout: 268 seconds]
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
_jm has joined #linux-sunxi
sankasan has quit [Quit: Leaving]
<shineworld> I've just now updated uImage and modules from last github/linux-sunxi/linux-sunxi 3.0 applying them to and when attach the ACCESSORY DEVICE I've got that [sw_udc] goes literally crazy with an infinite message loop in TTL debug port:
<shineworld> and lsusb sign: Bus 001 Device 021: ID 18d1:0005 Google Inc.
<shineworld> instead of usual: Bus 001 Device 021: ID 18d1:0003 Google Inc.
<shineworld> also after have to removed connection and re-connect to PC for ADB
<shineworld> TTL debug port at this point don't throw out nothing
<shineworld> I'm finishing an ADK-Device simulator running on Linux if someone is interest to try what don't works in accessory support
eebrah is now known as eebrah|away
paulk-desktop has quit [Quit: Ex-Chat]
Yaku321 has joined #linux-sunxi
<shineworld> seem don't exit by accessory mode so every time I connect the usb to computer the system re-enter in accessory mode with all data
<shineworld> E/gralloc ( 86): FBIO_WAITFORVSYNC failed
<shineworld> D/UsbDeviceManager( 156): entering USB accessory mode: UsbAccessory[mManufacturer=FTDI, mModel=FTDIUARTDemo, mDescription=Vinculum Accessory Test, mVersion=1.0, mUri=, mSerial=VinculumAccessory1]
<shineworld> I/ActivityManager( 156): START {act=android.hardware.usb.action.USB_ACCESSORY_ATTACHED flg=0x10000000 cmp=it.shineworld.allwinner.accessorytest/.MainActivity (has extras)} from pid 156
<shineworld> additionally with 3.0.72 a new massive message entered in logcat:
<shineworld> /qtaguid ( 156): Failed write_ctrl(s 0 10031) res=-1 errno=1
<shineworld> 3.0.72 is worse than 3.0.56+ in that... I will back to previous
hansg has quit [Quit: Leaving]
torindel_ has joined #linux-sunxi
torindel has quit [Read error: Connection reset by peer]
bhoj has quit [Read error: Connection reset by peer]
<rm> shineworld, go 3.4
<shineworld> will support android 4.0.4 ?
<rm> no idea :))
rz2k has quit []
<rm> but if you try and it does then it will be a great service to humanity o/
<shineworld> ok
<rm> mnemoc waits for more "Android people" to confirm they can use 3.4
<shineworld> just time to change brach and build
<shineworld> shine@shine:~/android/build/linux-sunxi/linux-sunxi$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sun4i_crane_defconfig
<shineworld> scripts/ /home/shine/android/build/linux-sunxi/linux-sunxi/scripts/basic/Makefile: No such file or directory
<shineworld> make[1]: *** No rule to make target `/home/shine/android/build/linux-sunxi/linux-sunxi/scripts/basic/Makefile'. Stop.
<shineworld> I'm using the 3.0 make "way" perhaps for 3.4 is different ?
<oliv3r> I'll try 3.4 with android on SD
<oliv3r> and use my tablet in 'sd' mode
<oliv3r> i can't boot any kernel on my tablet besides factory, and don't have breakout board to see why
<shineworld> I always boot on SD for cubieboard
<shineworld> but what is right make calls for 3.4 ?
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<shineworld> is a right branch ?
<shineworld> shine@shine:~/android/build/linux-sunxi/linux-sunxi$ git branch -v
<shineworld> sunxi-3.0 274a66a Merge branch 'reference-3.0' into sunxi-3.0
<shineworld> * sunxi-3.4 6416f0b Merge branch 'reference-3.4' into sunxi-3.4
<shineworld> -a +the
<shineworld> ok I can't do ... another time when I understand how to activate a remote/origin/... and get that works
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
_jm has quit [Remote host closed the connection]
<wingrime> ssvb:ping
<wingrime> oliv3r ping
Kadosch has joined #linux-sunxi
<ssvb> wingrime: nice, we just have one problem - to get an idea about the purpose of these hardware registers we still need a small jpeg decoder test program and a trace of its execution with a log of all registers access (how many times, which values, etc.)
<ssvb> wingrime: with just disassembly alone you are moving into a guesswork territory too much
<wingrime> now I have more ... whait I copy to paste
tinti has joined #linux-sunxi
<wingrime> but I realy have no idea with it code do
<wingrime> *what
<wingrime> It imposible for me alone do RE for whole CEDAR
<Turl> wingrime: are you disassemling by hand?
tinti has quit [Ping timeout: 245 seconds]
<wingrime> Trul: ida , asm and brain
<wingrime> no decompiler
<wingrime> errors very possible
<libv> wingrime: this is not your code
<libv> wingrime: you are not allowed to license it as you see fit, and you are definitely not allowed to distribute it.
<wingrime> libv: this is not code that can be compile
<wingrime> it right reference
<libv> wingrime: no, that is not a reference.
<libv> wingrime: that is a simplistic disassembly, and therefor a copy.
<wingrime> it reference for REs to make sure what some regs do in pseudocide
<libv> no, it's simplistic disassembly.
<libv> err, decompile
<libv> and therefor not your code.
<wingrime> any way you know other way make it work without blob ?
<libv> reference for others is when you document what which register does and how to use each register.
<libv> wingrime: yes, proper REing.
<wingrime> libv: for me it reference that I will use to fill wiki with registers
<libv> wingrime: then stop spreading and relicensing it.
<wingrime> I need someone who can help me with that HELL
<wingrime> libv: do you know normal way, to trace MMIO ?
<libv> wingrime: if you are not prepared to play properly and see it through, then don't bother to start
<libv> ianb has things set up.
rellla has quit [Quit: Nettalk6 -]
<wingrime> libv: how do you deal with mali
<wingrime> it use mmio too
<libv> no, it does not.
<wingrime> and debian paste have limit 24h
<libv> but again, ianb has things set up
<libv> wingrime: doesn't matter what limit it has.
<libv> wingrime: stop distributing disassembled crap.
<wingrime> Only thig that I want make - Reg reference
<libv> wingrime: and this is definitely not that.
<wingrime> this is realy crap you right
Yaku321 has quit [Ping timeout: 245 seconds]
ganbold_ has quit [Remote host closed the connection]
<wingrime> libv: how do you think operation order can be in wiki?
<libv> wingrime: ?
<wingrime> setup order
<wingrime> I mean HW registers setup order
<ssvb> wingrime: how do you know that it is important?
<wingrime> it do strange things sometime for example write to one reg 40 times
<wingrime> order not always imortant but sometimes like START or simular or reset order
<ssvb> it makes sense to document stuff after you understand the logic behind it
<ssvb> you need to know what data is actually written there and how it correlates with the input file being decoded
CountryGeek has quit [Read error: Operation timed out]
<wingrime> libv: how you make radion driver without it ?
<wingrime> if you know better way to undersand logic please say...
CountryGeek has joined #linux-sunxi
<wingrime> but I need such pseudo code for refernce
<libv> wingrime: use a brain.
<wingrime> now I use much brain for make asm understandable and findout what code do but after manual it still not clear as code use many globals
n01 is now known as n01|afk
<libv> wingrime: how long did you expect all of your "labour" to take?
<libv> 2 minutes?
<libv> an hour?
<wingrime> heh...
<libv> wingrime: do you know how long i have been working on the lima driver already?
<wingrime> let me know
<libv> well over 2 manyears.
<wingrime> how many regs are you realy understand
<libv> very little
<libv> as the mali only uses a few dozen
<wingrime> you still use traces for init ?
<libv> all the magic is however in the command stream
<libv> i know 95+% of what i am currently using
<libv> 10kloc of code to properly employ what i know
<wingrime> do you know ARM ASM?
<libv> proper code, that i wrote from scratch as my knowledge of this hw grew
<libv> wingrime: why do you ask?
<wingrime> I may be will have to ask some info for some commands
<libv> wingrime: google.
<libv> wingrime: and i am not helping you in any way on the broken path you are trying to follow
<wingrime> libv: what do you consider as broken
<libv> wingrime: especially since you clearly are not up for the magnitude of this task.
<wingrime> jpeg can be not much difficult all whole
<wingrime> but possible as it use only 5 functions
<wingrime> it a not first time I do RE code for make some fun
<libv> wingrime: then why don't you just throw some different jpeg files at it and capture the command stream?
<libv> and the register accesses?
<wingrime> we have not workable code example for it
<wingrime> and more generaly
<wingrime> driver simply map registers to userspace
<wingrime> there is no ioctl for it
_BJFreeman has joined #linux-sunxi
<libv> wingrime: for the 50.000th time, ianb is using a segfault handler for register accesses
<ssvb> wingrime: just make a workabe code first, what's the problem?
<wingrime> where is it
<wingrime> that code firstly
<wingrime> and secondly
<libv> *sigh*
<wingrime> example for jpeg
BJfreeman has quit [Ping timeout: 256 seconds]
focus has quit [Remote host closed the connection]
<ssvb> wingrime: workable code == jpeg example. the hw registers tracer = ianb's
<ssvb> just make this freaking jpeg example yourself
<ssvb> what's the problem?
<libv> wingrime: do you really think that i did mali by just pointing a disassembler at it and then calling it free software?
<libv> wingrime: or did i first have to go and learn about opengles2 and render a triangle with a binary driver?
<wingrime> do you realy think all posible with data flow ? in world there is some crypto / checksums that not even possible with dissasembler
tinti has joined #linux-sunxi
<libv> wingrime: you said yourself that this jpeg stuff is supposedly trivial
<wingrime> trivial but it may be dead code
<wingrime> but mpeg decoder are same
<wingrime> for mpeg124 and mjpeg and jpeg
<libv> wingrime: you have some serious logical issues there
<wingrime> maybe
<libv> why, if it is dead code, are you bothering with it?
<libv> why is supposed dead code a reason for disassembly and then misappropriation, and not for proper REing?
<wingrime> becose jpeg stuff have shared things with mpeg
<wingrime> many shared things
<wingrime> FFT for example
<wingrime> If i generaly understand jpeg decoding procedure it make much simpler understand general mpeg decoding
<wingrime> and make sure that not use some sorts of firmware
<libv> none of that explains why you chose to do what you are doing like you are doing it
<libv> s/like/the way/
<wingrime> I need firstly know registers that code touches
<wingrime> and have it or not have some conditions here
<libv> no.
<libv> first you get a working jpeg decoder based on the binary.
<libv> wingrime: if you are not willing to go through the motions, then please go away.
<wingrime> libv: I have no intension write code for cedar I only want make some register reference
<wingrime> at least now
<wingrime> ssvb: are you still here
<ssvb> yes
<wingrime> what revisions numers a10 have
<wingrime> I just find that logic check some unmbers that may be a10/cedar revisions
<ssvb> better ask mnemoc
<wingrime> for example 0x1623
<wingrime> or 0x1620
<wingrime> crap
<wingrime> logic differs for cedar versions
<ssvb> relax, that's the last thing to worry about at the moment
<wingrime> good things
<wingrime> I find that 4 bit at 0x0 reg are control reset logic
<wingrime> now will looking for irq logic
ijc has quit [Read error: Operation timed out]
<wingrime> realy funny
<wingrime> ve have reg with version
<wingrime> who can dump regs with uboot ?
<wingrime> I not have uart now
ijc has joined #linux-sunxi
<wingrime> I can add version detection to cedar driver
<wingrime> avs here realy stud
_BJFreeman is now known as BJfreeman
sanka has joined #linux-sunxi
sanka has quit [Client Quit]
n01 has joined #linux-sunxi
<CountryGeek> Q: so I wrote a pwm driver a couple of days ago not adhering to any standard (pwm not compiled into my kernel) and I'm working on an lradc driver now.
<CountryGeek> How should I implement? Include in pwm driver, not adhering to any standards?
<CountryGeek> New driver, not adhering to any standards?
<CountryGeek> build a new kernel with iio and implement an iio driver?
eebrah|away is now known as eebrah
<n01> CountryGeek: uhm, does not exist a pwm framework?
<CountryGeek> There is one, but it wasn't compiled into my kernel (hansg port of Fedora), so I did a sysfs interface by hand
<CountryGeek> :-[
<CountryGeek> And I think the pwm interface has changed since 3.4 anyway
<CountryGeek> I'm afraid that if I do a driver within the iio system that it won't be generally useful if that system isn't in many / any standard kernels
* CountryGeek has a pcDuino
<CountryGeek> n01 - what would you do?
<wingrime> mnemoc: are you here?
<n01> CountryGeek: (1) cannot you recompile the kernel with the framework? (2) if you want to mainline the driver you must use the framework :)
<ssvb> TheSeven: what's wrong with your TV? which kernel version are you using?
<CountryGeek> n01 - good point - that's my dilemma. I don't want to have to support the CountryGeek kernel though, just the pwm / lradc code.
<CountryGeek> Do any boards ship with the iio subsystem enabled?
<CountryGeek> * ship with kernels with
<n01> CountryGeek: you just have to maintain the driver eventually, people willing to use it have to eventually recompile the kernel by themselves
<n01> oor, of course, just enable it in defconfig :)
<CountryGeek> n01 - k - maybe I'll reach out to hansg and see what Arch has enabled. That's the right answer
vinifm has joined #linux-sunxi
<CountryGeek> n01 ??
<n01> CountryGeek: I mean: if u write a driver for sunxi-pwm requiring the pwm framework to be enabled in the kernel, just modify the defconfig for sunxi enabling framework and driver
* n01 dinner-time
<CountryGeek> n01 - Oh - k...
<CountryGeek> Thanks!
<vinifm> someone successfully cross compiled VLC for sunxi?
shineworld has joined #linux-sunxi
<wingrime> 4svb: where can I get mmio records form CedarXWrapper
<wingrime> ssvb: I have no a10 closely
eebrah is now known as eebrah|away
fredy has quit [Quit: ZNC -]
fredy has joined #linux-sunxi
n01 has quit [Ping timeout: 245 seconds]
rellla has joined #linux-sunxi
<TheSeven> ssvb: my TV set works with the A10, at least on android, but its panel resolution is just crappy. it is too dumb to configure overscan though, and I vaguely remember berrybooted linaro ubuntu getting clipped off at the edges
<TheSeven> I'm more annoyed by a whole lot of PC monitors just refusing to work with the A10 (which do work fine with a raspberry pi), and by the unavailability of hardware-accelerated XBMC (at least back when I tried it, did something move in the meantime?)
<CountryGeek> TheSeven: I'm not having any trouble like that with my pcDuino with Fedora - have you tried that?
<TheSeven> which of my various troubles are you referring to?
<CountryGeek> the stock Lubuntu looks like ass though
<CountryGeek> "pc monitors refusing to work"
<TheSeven> I think I generally just got a black screen, no matter which combination I tried
<TheSeven> however I might be mixing up some of the ARM boards that I have sitting around here
<TheSeven> I just remember that the only device that just worked out of the box with PC (DVI) monitors was the raspberry pi, which is just too crappy to do anything useful with it :P
* CountryGeek is jealous hearing of "mixing up arm boards"
<TheSeven> all the powerful boards (panda, cubie, odroid-x2) had some issues
<rellla> ssvb, wingrime: iainb is back...
<CountryGeek> Yeah - that distro that comes on the pcDuino is hideous. Fedora and Arch looked ok though
<CountryGeek> raspi - true
<ssvb> TheSeven: good support for various monitors via EDID needs a recent kernel, I guess it is possible that you used an ancient one
<ssvb> rellla: good :)
<ssvb> wingrime: mmio records? what do you mean?
<oliv3r> wingrime: oh i like your pseudocode
<TheSeven> ssvb: I last tried that on the cubie about half a year ago. since then I've been using rm's headless kernel
<oliv3r> wingrime: arg0, if passed to fillhuffman, is maybe a pointer to a struct?
<TheSeven> is there any reason to assume that it would nowadays work with DVI PC displays?
<TheSeven> I thought there was some hardware or proprietary driver problem that limited it to YUV output or something like that
<TheSeven> the problem that I have with the exynos - being locked to 720p and 1080p resolutions - is absolutely hilarious
nove has joined #linux-sunxi
<nove> hello, i am new here
<nove> last week i finally installed bind in a a13 tablet,
<nove> and supresing was very easy
<wingrime> oliv3r: big big stuct
<nove> after finding out that booting,doesnt work at 100%
<ssvb> TheSeven: I think most monitors should be fine now, for example here is a "success story" about using a 1280x1024 DVI monitor -
<nove> I am here, because of RE cedar, i am interested to join
<ssvb> rellla: filed a bug to poke ianb - ;)
<oliv3r> CountryGeek: remember, we have the sunxi-3.0 and sunxi-3.4 kernels here (the one hansg uses), but those will eventually go away; effort is being put into rewriting the whole shebang for mainlining, which started at 3.10. if you want something useable now, use 3.4 and use your driver as is. submit it to the ML and let someone else or you, port it eventually to 3.11+ for eventual ML support.
<nove> and have made a partial tracer using valgrind
<rellla> ssvb: :)
<ssvb> nove: welcome on board :)
<nove> ssvb: let's make allwinner to change is name to allopen
<CountryGeek> oliv3r: K - Hopefully the iio subsystem won't change that much. Currently working on getting a kernel with iio enabled.
<CountryGeek> I was originally happy that I finished the driver, now I'm embarrassed that it doesn't adhere to standards :-[
<nove> i did some traces with vp8, and i think i can see all
<oliv3r> rellla: oh wow really, lets see if heis gonna pop by here :p
<ssvb> nove: valgrind is a good choice
<nove> ssvb: a bit slow, with the huge vlc
<nove> in the traces that i made, is easy to see the vp8 bitstream and vp8 coefficients tables or what si called
<nove> i think is a fixed function engine
<ssvb> have you tried to replay these traces?
<nove> not yet
<nove> but
<nove> i can't see where is the decoded frame
<wingrime> nove: can you add special page for traces and one per trace with parameters and link to file
<nove> maybe, because it uses /dev/disp
<wingrime> and you can use paste for trace
<wingrime> I want mjpeg tace
<nove> that is other problem, how the the legally of sharing this
<wingrime> actualy you did log
<wingrime> not see any problem
<libv> wingrime: you have a history of not seeing problems.
<nove> libv, hi
<wingrime> libv: do you see some copyright stuff in logs?
<wingrime> you like stollman
<libv> wingrime: well... you do not see me offering up replayed frames of q3a for instance...
<wingrime> libv: problem that cedar have revisons
<nove> that is a question that i would like to ask, how to RE cedar without making legal mistakes?
<wingrime> some decoders have some if (verson == 0x1620)
<wingrime> nova : best way analyze logs
<nove> what can be done, and what can't be done, of the legal point of view
<wingrime> rewrite code from dissassembly directly illigal
<wingrime> do logs i think legal
<wingrime> as read/write regs for testing
<TheSeven> depends on whether you've accepted an EULA that has further restrictions, but generally there's a DMCA copyright exception that covers reverse engineering for compatibility purposes
<wingrime> DMCA usa only
<TheSeven> note that I may not give legal advice though
<TheSeven> generally speaking, a "chinese wall" approach is typically used to avoid legal problems
<TheSeven> one team documents stuff from reading disassemblies, another team reimplements the stuff from the documentation, pokes at the hardware, and possibly figures out further details
<wingrime> TheSeven: one word about world: Russia
<wingrime> I am there, so does not care
<oliv3r> CountryGeek: any driver is a good driver ;) i had started on pwm; so if you post yours, i think i can mold it into 3.12 terms with the PWM framework :)
<nove> yes, i understand the clean room way
<wingrime> nove: black box
<oliv3r> nove: i was still backreading, welcome! Check out our wiki, espcially ianb's cedarX wrapper
<nove> but i don't understand by per example, how lima is done
<CountryGeek> oliv3r: But I'm working on a lradc driver now and would like to do it right the first time
<TheSeven> nove: I don't think lima did really care about the legal aspects, from what I read they aren't doing a clean room approach at all
<CountryGeek> Damn Fedora - missing libgcc.a for arm
<nove> how can the people doing the reverse engineering, can then later write the drivers
<TheSeven> nove: because nobody would care to go after the reverse engineers - they'd rather hunt down the commercial users of the driver with patent claims
<oliv3r> CountryGeek: well the lrdac is basically a low-resolution DAC, and is abused as keyboard by tablets etc
<CountryGeek> yeah - I want to use it as a DAC - dunno if it's got enough res or not...
<ssvb> TheSeven: do you have a link confirming that "lima did really care about the legal aspects"?
<oliv3r> CountryGeek: there is the input framework, and i'm sure there's some sort area where DACs go (i know there's digital pots etc in the kernel allready) but how to 'tie those two together' good quesiton. we do have the lrdac driver as sun4i-keyboard i belive
<oliv3r> CountryGeek: lrADC, not dac :p
<TheSeven> ssvb: "I don't think ..."
<CountryGeek> oliv3r: wouldn't it go into the iio framework?
<libv> i definitely cared about the legal aspects.
<nove> then what is the best way to do cedar, without scaring allwinner?
<ssvb> TheSeven: yes (sorry for a bad quote), but the link please :)
<oliv3r> nove: i think libv didn't do the register bit, he actually puzzled it out, by sending data, capturing outputs etc, not reading asm etc
<CountryGeek> oliv3r: What is your development environment like? Distro? Compilers?
<oliv3r> nove: well i think the lima approach is best legally speaking. and scaring AW, i think they are actually violating the GPL with cedarx, there's most likly code in there that is copy/pasted from GPL code
<TheSeven> ssvb: I don't have any particular link to back that up, but the general approach (dissecting that shader compiler, the same developer building a new one, directly comparing outputs, ...) seems equally fishy as most other RE projects to me, but I'm sure libv knows better, so better ask him
<oliv3r> CountryGeek: gentoo, i installed the toolchain via crossdev and crosscompile using the sunxi-bsp
<TheSeven> I'm looking at this mostly from a perspective about what I know about US copyright law (which isn't terribly much), no idea whether something else might apply here
<nove> well, i don'r have any intention to touch the binary blob
<libv> to the extent that the other party asked me to do this:
<oliv3r> nove: we have a page up on about cedarX and our findings how things stick together
<libv> as that was the only thing they had to state.
<libv> i have used disassembly in my lima work
<oliv3r> nove: you need to run the binary blob and compare outputs at the least :p
<nove> oliv3r, yes, but not lookin inside
<libv> but i have always used this as documentation to figure out what is going with the command stream i was looking at
<libv> and i damn well make sure that this disassembled or manually decompiled stuff _never_ leaves this encrypted disk i am on
<libv> as i do not own that code
<libv> as i stated before...
<libv> first you create a testcase
<libv> then you grab what's flying about
<libv> then you replay that
<libv> then you pry apart what you just replayed.
<wingrime> libv: paranoid soluton - live in russia
<libv> and you keep a nice git history of how you go about prying this apart.
<libv> wingrime: whatever.
<libv> wingrime: i have 10kloc of limare, 2kloc of wrapper, a heap of test cases with the equivalent limare code, and an especially ported q3a to show for it
<wingrime> libv: so much paranoid
<libv> but before i did all that, i sat down, and thought things through, and even wrote up, in quite great detail, how i was going to tackle this.
<libv> and i am still working that same plan 2 years on
<oliv3r> libv: gotta remember that you are quite experience
rellla has quit [Remote host closed the connection]
<libv> indeed, and i have employed targetted disassembly, objdump and loads of manual work, during the past 10ys, as needed, but never as a goal in itself, and i never let any code go out that i did not write myself to achieve the same hw results
<wingrime> there is russian joke about it "termo-anal-cryptoanalysis" - soldering iron in your butt and you say any pass form any disk, so encrypted stuff not so helpfull like looks
<libv> actually, compared to the hours of simply throwing stuff at the hw, trying to figure out how .tw or so code worked, or how the meagre docs that ATI was forced to hand us fitted together, i have done amazingly little assembly
<oliv3r> libv: that's suprising, as around RE hangs this vibe of asm
<libv> 99.9% is throwing stuff at the hw and seeing what happens.
<wingrime> libv: black box analysis
<libv> wingrime: in soviet russia...
<wingrime> libv: libv: try IDA
<wingrime> libv: most powerfull instrument for RE
<libv> wingrime: try a real brain instead.
<nove> wingrime, why waste time to understand a complex binary, when the hardware is more simple
<libv> oliv3r: anyway, ianb made a fantastic start with his wrapper
<wingrime> I ask ianb toaday
<libv> oliv3r: now it is mostly a task of writing tests, and seeing what falls out, and then reproducing again
shineworld has quit [Quit: Leaving]
<wingrime> he send me some new info according logs
<wingrime> and some logs
<wingrime> I must think about freqency analysis
<ssvb> nove: are you sure that this code is talking directly to hardware and not doing some kind of rpc communication with another programmable core?
<nove> ssvb: in that case isnt the programmable core, the hardware
<ssvb> anything resembling ?
<wingrime> ssvb: may be something in
<wingrime> thay possible can steal some verilog code
<wingrime> new dedicated core is open risc from opencores
<nove> ssvb, still have to look more in detail
<nove> ssvb, what i guess, is that for vp8 it use the same engine as h264, as is in the kernel sources side
<oliv3r> libv: live and learn, i found it 'interesting' to twirl around the blob for a bit and see what was there, function names, how it all fits together etc. but ianb's wrapper seems deffinatly the way forward in this case
<lkcl> wingrime: the technique that libv came up with is extremely effective. i did the same thing for the samba nt domains reverse-engineering. i did *not* need IDApro.
<ssvb> nove: it would be also interesting to compare traces of a buggy blob vs. fixed blob for the problem
<lkcl> the only point at which IDA was needed was for the crypto algorithms, and that turned out to be 30 lines of code.
<nove> ssvb, is to early
<oliv3r> ssvb: actually, there's something called ISP in the kernel bit of cedar. its s strange name, and might be something to program the Video Engine imo
<libv> oliv3r: oh, it is extremely helpful to look at the structure of things by looking at symbols
<libv> oliv3r: but that should never be the start of development
<lkcl> the *entire* remainder of the 150,000 lines of code was done by replay bootstrapping, in a 2x2 matrix, one packet at a time, server-to-client, client-to-server.
<lkcl> packet not understood: don't give a shit, just replay it at the relevant point in the conversation until it *is* understood.
<ssvb> nove: I'm kinda curious about what they could screw up to trigger this bug
<oliv3r> libv: if you know what you are doing, then yes, but if you are just curious first, you try to look under the skirt a bit first, so you can get an idea wha tthey did and what you can expect ;) it's all you got if oyu have zero experience
<oliv3r> and it's fun to do :)
<oliv3r> ssvb: you mean because the use the same codec software, and only the front end glue is differnt between those two libs?
<wingrime> lkcl: Ida are pro instrument can do more with it when you know how to use 1) cross references 2) function types and arguments 3) decomiller on x86 4) comments, naming, auto strucures and constants
<nove> lkcl: hi, what do you think that will be the reaction on allwinner to a a cedar RE project?
<oliv3r> ssvb: i would not be supprised they took the webm code for VP8. i mean, heck, look at cedarX, it's all kinds of random code glued together
<oliv3r> ssvb: and we _know_ they initially did the entire soc on an FPGA
<wingrime> oliv3r: now *every* SOC have R&D on FPGA
<oliv3r> so having a big fpga, and also add this pre-made verilog code ... why not. there's divx/h264 decoders on opencores too, and i don't even have to look to know there'll be mpeg2 cores too. so it's quite easy to just grab some of it
<oliv3r> wingrime: yeah of course :p
<wingrime> oliv3r:
<wingrime> opensource hw code
<oliv3r> i typted that up there ;p
<wingrime> GPL verilog code for HW
<oliv3r> actually, as wingrime pointed out, they 'used' the openrisc core i think or what was it for the sr100 (from my head) so they deffinatly know where to get it
<nove> can't be idle, i read the logs
nove has quit [Quit: nove]
<oliv3r> work .. what time zone you in? :)
paulk-desktop has joined #linux-sunxi
paulk-desktop has quit [Client Quit]
wingrime has quit [Ping timeout: 255 seconds]
paulk-desktop has joined #linux-sunxi
paulk-desktop has quit [Read error: Connection reset by peer]
paulk-desktop has joined #linux-sunxi
vinifm has quit [Quit: Saindo]
Kadosch has quit [Remote host closed the connection]
Undertasker has left #linux-sunxi [#linux-sunxi]
paulk-desktop has quit [Quit: Ex-Chat]
rz2k has joined #linux-sunxi
myth has joined #linux-sunxi
foresto has joined #linux-sunxi
jukivili has quit [Ping timeout: 252 seconds]
jukivili has joined #linux-sunxi