ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
krimpsok has quit [Ping timeout: 245 seconds]
<slapin_n1> rz2k: my time is on gmt+4 too (04:11 now, damnit)
<slapin_n1> hno: I've played with patches a bit. soma suffling is required - remove unncecessary changes to configs, remove seperate flash table (get fresh Linux one, merge to u-boot and add missing chips if any. That is obvious things to do. And a lot of cleanup is needed.
<slapin_n1> s/suffling/shuffling/
* slapin_n1 really needs that bot here
* slapin_n1 gone for some sleep as need to wake up on 7:25 and there is already 4:16
<slapin_n1> it is good it is just visit to doctor
<rz2k> you found somebody who will work in the morning after 1may?
tinti_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
torqu3e has joined #linux-sunxi
wowon has joined #linux-sunxi
<wowon> Hi ... I just re-read about A13 GPIO , there used PE11 as example. I cross check with A13 datasheet ... the PE11 is used by UART. Potential unused GPIO Pin on A13 is i.e :PG0,PG1,PG2 ... please cmiiw
tinti_ has quit [Remote host closed the connection]
rz2k has quit []
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
anunnaki has quit [Ping timeout: 245 seconds]
christopher has joined #linux-sunxi
christopher is now known as anunnaki
rellla has joined #linux-sunxi
<gzamboni> mnemoc, i made a redirect to port 81 as using my failover ip it did not work
<gzamboni> if you need to cache other things just let me know
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 256 seconds]
rellla2 is now known as rellla
shineworld has joined #linux-sunxi
shineworld has quit [Read error: Connection timed out]
shineworld has joined #linux-sunxi
focus has joined #linux-sunxi
focus has quit [Quit: Ex-Chat]
n01 has joined #linux-sunxi
focus has joined #linux-sunxi
fra79Wii has joined #linux-sunxi
<fra79Wii> Good morning everyone
<Dreadlish> mornin'
<fra79Wii> I saw rumors of newer allwinner sdk, with openmax support...
<fra79Wii> I've looked allover but i can't find not even the a31 sdk...Is there something around?
<mnemoc> fra79Wii: the 4.2.2 SDK comes with omx cedarx drivers, yes. but I'm not aware of any public copy of it
<mnemoc> hopefully olimex or cubietech will be able to release it soon, even if it's gpl violating
fra79Wii has quit [Ping timeout: 248 seconds]
<ssvb> mnemoc: is the old libve api abandoned now?
<mnemoc> don't know
<mnemoc> i'm more inclined to believe they made an omx wrapping around libve
<mnemoc> fits better their usual style
<ssvb> but if libve is not a public interface anymore, they can introduce incompatible changes to it
<mnemoc> yes
<mnemoc> and the kernel part is even more awful, they added an ioctrl() to export the registers raw
<ssvb> wasn't it always this way?
<mnemoc> not that explicitly
<rellla> ssvb, mnemoc: i asked for some support at allwinner regarding cedarx. let's see if anybody wants to talk...
<mnemoc> good linux support will make them sell more
<mnemoc> but it feels like they fear to be sued by IP owners
<ssvb> "readelf -s | grep ff_" :)
<rellla> do we have any infos, who is responsible for cedarx at the end, if it's not allwinner themselves?
<mnemoc> there is no doubt about the ffmpeg "influence" in the userspace libs. I was talking about cedarx hw itself
<mnemoc> a year ago it was said that only one (asocial) developer within allwinner had access to cedarx's specs and code
<ssvb> is this guy still with allwinner?
<rellla> ... or with cubietech now? :P
<mnemoc> i doubt the cedarx guy moved to cubietech as (if I recall correctly) he and tom didn't quite stand each other well
<rellla> so if there's only one guy, i'm not wondering anymore, why cedarx- and especially xbmc-support for gimli and the others was so bad. maybe he was ill a long time ;)
<mnemoc> afaik he denies gimli's claims
<mnemoc> arguing wrong usage of libve's api
<rellla> but afaik we don't have any newer/ more detailed guide than ?!
<mnemoc> ack
<mnemoc> we really need a cedarx RE project :p
<mnemoc> libcedrus! :p
<ssvb> are we allowed to rip it into pieces with a disassembler (assuming that it is a ffmpeg derivative work under LGPL license)?
<mnemoc> the lib is in explicit gpl violation
<mnemoc> but to make it clean the people disassembling it and the people writting the new code can only communicate via documentation
<mnemoc> but libv is the expert
mike111 has joined #linux-sunxi
<ssvb> sunxi wiki refers to this hardware registers access tracer in the reverse engineering section -
<ssvb> but it has one obvious buffer overflow bug and also is unable to support thumb2 instructions which are used in the current
<ssvb> all of this is trivially fixable
focus has quit [Remote host closed the connection]
<mnemoc> unless the only dev with access is a lazy jerk
<ssvb> we don't know why this reverse engineering effort has been abandoned
<ssvb> the tracer (reverse engineering tool) has bugs, and it's not allwinner's fault :)
<mnemoc> :)
<mnemoc> need to go. bbl
fra79Wii has joined #linux-sunxi
<fra79Wii> Also I finally manage to boot android from nand using 3.4 kernel :)… I think is more performing… might just be placebo effect tough...
tzafrir has quit [Ping timeout: 245 seconds]
<oliv3r> mnemoc: backreading, your fixing stuff from a BK; lol; free-wifi ftw :)
<oliv3r> mnemoc: if they use 3.9, that'll be awesome, since AW will then find our sunxi stuff in the standard kernel they'd have to work around/with
vicenteH has joined #linux-sunxi
shineworld has quit [Remote host closed the connection]
tzafrir has joined #linux-sunxi
<libv> ssvb: nothing stops your from disassembling it
<libv> ssvb: but the disassembly can not be spread, as it is not your work and it cannot be licensed in any way
<libv> you are safe when you use this as documentation
<libv> and build up support and knowledge from command stream and register access grabbing, occasionally looking to what you need to know
<libv> is there any solid info on this being an ffmpeg derived work?
<ssvb> libv: just the names of the symbols in the blob so far ('ff_' is a well known function name prefix used in ffmpeg), some symbols even have exactly the same names as in ffmpeg
<ssvb> disassembly and analysis of these functions might (or might not) provide some more solid proof
<libv> ooh wow, internal
<libv> ssvb: this definitely is a horrid license violation
krimpsok has joined #linux-sunxi
<libv> get lkcl involved
<ssvb> it might make sense to first get some usable blobs for a20/a31 before making any fuss about this :)
BJFreeman has quit [Ping timeout: 252 seconds]
<libv> there's always android
<libv> (when you need to RE stuff)
paulk-desktop has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJFreeman
anunnaki has quit [Ping timeout: 256 seconds]
vicenteH has quit [Ping timeout: 256 seconds]
anunnaki has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
<Turl> hi mripard_
<mripard_> Turl: hi
hramrach_ has quit [Remote host closed the connection]
<Turl> mripard_: I saw your i2c patches, I wondered how you tested them
<Turl> mripard_: I'll give them a go and add the nodes to the cubie dts
hansg has joined #linux-sunxi
<mripard_> Turl: there's a I2C RTC on the olinuxino
<mripard_> plus, the lines of this bus are exported on some headers
<mripard_> so I tried to communicate with the RTC, while probing the bus with a logical analyzer
<Turl> mripard_: yeah, the cubie has headers for twi1, but I lack twi hardware :(
<Turl> I think the AXP is wired via i2c
<mripard_> you can still use i2cdetect and see what's on the bus :)
<mripard_> I have something on the i2c0 bus on the olinuxino, which is not on the schematics
<mripard_> it could very well be the PMIC
<mripard_> Turl: I pushed the branch on my github
<mripard_> if you want all the needed patches and so on.
<Turl> I need more than what you sent on the ML?
paulk-desktop has quit [Quit: Ex-Chat]
<Turl> ah, clocks and pins
<mripard_> well, most of the thing that will be merged in 3.10 :)
<Turl> I had checked out torvalds/master but arm-soc hasn't landed yet
<mripard_> you know, some guy wrote the clock driver, you'll need it :)
<Turl> haha
<mripard_> no, olof sent the pull requests this morning
<mripard_> well, my morning, so during your evening I guess :)
<mripard_> I can't remember who was interested about the i2c on this channel
<mripard_> ssvb ?
<Turl> your morning is my night
<mripard_> ah, bsdfox_ maybe
<ssvb> mripard_: ?
<mripard_> ssvb: were you the one that was interested in the i2c driver I was writing?
<mripard_> I can't remember
<ssvb> no, it wasn't me
<mripard_> ok, sorry then :)
<ssvb> np :)
<Turl> mripard_: I suppose 0x34 is the PMIC
<mripard_> Turl: probably, but you'll need to ask hipboi I guess :)
<Turl> mripard_: do you also see it on 0x34?
<mripard_> but the something I have on the olinuxino is at the same bus, same address
<mripard_> so it would make sense
<mripard_> Ah, I misread the schematics
<mripard_> it's indeed an AXP209
<Turl> [pmu_para]
<Turl> pmu_used = 1
<Turl> pmu_twi_addr = 52
<Turl> pmu_twi_id = 0
<Turl> 52 = 0x34
<Turl> so it's working :)
<mripard_> good to know you doubted it ;)
<Turl> haha
<Turl> mripard_: does olinuxino expose all the i2c on the headers?
<Turl> the cubie only exposes twi1, and twi0 is used internally just for the pmic from what I see
mike111 has quit [Ping timeout: 245 seconds]
<mripard_> Turl: yes
<mripard_> it's a pretty great toy to work with
<mripard_> you have everything available on the headers
<mripard_> Turl: I did a new layout for the mainlining page on the Wiki
<mripard_> and updated it
<mripard_> tell me what you think
<mripard_> Turl: wow, that was quick :)
<Turl> mripard_: :)
<Turl> let me check it out
<Turl> the wiki seems to be crawling today, really slow :/
<Turl> mripard_: really nice :)
<Turl> mripard_: the mini x-plus needs a wiki page
<mripard_> yeah, I know
<mripard_> but I was too lazy to do it right now :)
ganbold_ has joined #linux-sunxi
<Turl> mripard_: is there any problem with the server? it's sloooow
<mripard_> yes, here as well
<Turl> my ip address according to the wiki is
<Turl> I smell a misconfigured proxy
<mripard_> yes, there's probably a proxy between us and the webserver :)
<Turl> stupid varnish
<Turl> it ate all ram and swapped like 7G
<Turl> and I restarted it and it ate all ram again :(
<Turl> mripard_: is it faster now?
<mripard_> it is
<Turl> mnemoc: I configured varnish to pass dl.(cubieboard|linux-sunxi).org through, might need to add more subdomains
<gzamboni> i configured a cache of the dl.linux-sunxi at
<Turl> gzamboni: does it accept requests for
<gzamboni> it should
<Turl> fuu, varnish is eating all ram again
<gzamboni> but we will have to do a dns round robin or a cname to put it in production
<gzamboni> it should minimize the traffic on the server for the most downloaded stuff
<Turl> yep, a DNS round robin with low TTL should be fine, assuming its synced frequenty
paulk-desktop has joined #linux-sunxi
<mnemoc> Turl: the point of adding varnish was to throttle the bw used by the dl. leechers :p
<mnemoc> Turl: the last days the bw jumped from under 200M/h to 10+GB/h
<mnemoc> Turl: the idea was to allow full speed for civilized users, but limit those ips who pass certain threshold
<oliv3r> mnemoc: it was bsdfox_ who asked for i2c several times
<mnemoc> oliv3r: don't know what you are talking about. have been very disconnected these days
mike111 has joined #linux-sunxi
<oliv3r> mnemoc: Burger-King wifi fixage :p && Android 4.3/5.0 using 3.9 would be good as it has initial sunxi stuff in; 3.10 would have been far more awesome though
<Turl> mnemoc: I configured varnish to pipe all dl.*.org
<Turl> otherwise it was caching the linaro images and such
<Turl> eating all ram and swapping
<mnemoc> Turl: vcl_fetch was configured to not cache large files
<Turl> it somehow still did
<mnemoc> reason for varnish is to throttle the speed of those IPs downloading too much (and eating my 5TB/M quota)
<Turl> I suppose pipe allows for throttling still
<mnemoc> can you try? :)
<mnemoc> the vmod is already installed
<mnemoc> just not configured
<mnemoc> Turl: also, afaik if you define your own vcl_recv you need to keep the "default" code
<mnemoc> or that logic won't be used
<mnemoc> oliv3r: burger-king was only because everything else was closed yesterday :|
<mnemoc> oliv3r: about 3.9/3.10, I don't think it's a good idea to invest energy in making a legacy (script.bin-based) kernel >3.4
<Turl> mnemoc: the comment claimed otherwise (something like "the default will always be appended on the end")
<mnemoc> for unification and drivers maturity we should be good with 3.4 (porting sun[67]i from 3.3), and for newer stuff... a (DTS-based) sunxi-next aimed at mainline?
<mnemoc> Turl: ah, nice
<mripard_> mnemoc: I agree :)
<Turl> mnemoc: I plan to make a sunxi-next tracking torvalds/master + any not yet merged patches
<mripard_> Turl: the dt is a hardware description, so the fact that there's no driver isn't a valid point ;)
<oliv3r> mnemoc: well IF android 4.3/5.0 uses 3.9/3.10, it will end up in the hands of AW, and they will have to work with it. Porting their changes over will result in conflicts etc, so they'll have to either rip-out the sunxi stuff, or work with it :)
<oliv3r> Turl: oh that sounds nice
<mripard_> or they will just keep using their 3.4 kernel
<mnemoc> oliv3r: I bet they'll rip us out
<oliv3r> i would expect so
<oliv3r> but one can always hope!
<Turl> using old kernel is just easier :)
<mnemoc> mripard_: 3.3 :)
<mripard_> Turl: I already made more or less such branch already :)
<oliv3r> you think they gonna try using android 5.0 with 3.3 kernel?
<mripard_> mnemoc: ye,s sorry :)
<Turl> mripard_: I replied that it's useful for i2c from userspace
<Turl> mripard_: nice :)
<oliv3r> that's not the linux-sunxi ML is it?
<mripard_> Turl: yes, I know
<mripard_> Turl: and that answer is indeed a valid point
<mripard_> imo
<mripard_> and notice how I did exactly like you did for my olinuxino :)
<Turl> did what?
<mripard_> not putting any child device on the i2c buses
<Turl> mripard_: well, my patch was mostly git show yourpatch|patch sun4i-a10-cubieboard.dtb :)
<mripard_> :)
<mripard_> but it's funny how Arnd looked at your patch, but overlooked mine :)
<Turl> dts*
<Turl> mripard_: probably he saw it was a series and skipped it
<oliv3r> what ML is this on? And why didn't you CC the sunxi ML :p
<mripard_> he has a cubieboard
<Turl> oliv3r: lakml
<oliv3r> i'll gmane it in my newsreader then
<oliv3r> gmane.linux.ports.arm.kernel ;D
<mripard_> oliv3r: probably for the same reason you don't cc lakml in your patches :)
<oliv3r> mripard_: I assume it's highly likly it'll be on supported by the a20 aswell, but we'll see when the chip lands in our hands
<oliv3r> mripard_: I will from now on!
<oliv3r> mripard_: once i'm happy with it enough that I don't sound like a complete noob :p
<oliv3r> no need to noisyify the list with dumb simple questions :)
<mripard_> but I completely screwed this patch post, I forgot to cc the allwinner guys, linux-sunxi, and the mail from the i2c maintainer has changed and I sent it to his old one....
<Turl> mnemoc: what vmod did you install?
<mripard_> oliv3r: yeah, but I didn't want to assume anything.
<oliv3r> mripard_: just go into your sent-items, Edit-as-new; fix the addressing, resend excluding lalkml :p
<mnemoc> Turl: libvmod-throttle
<mnemoc> Turl:
<mnemoc> Turl: recommended for the goal by #varnish people
<Turl> mnemoc so you want to limit connections?
<libv> mnemoc: i do not need to be throttled
<mnemoc> Turl: for some reason the traffic exploded 150x
<Turl> mnemoc: Symbol not found: 'throttle.is_allowed' (expected type BOOL):
<Turl> ('input' Line 19 Pos 14)
<mnemoc> Turl: don't want to let possible abusers affect the service of others
<mnemoc> Turl: import throttle; ?
<Turl> I'm going to set it up for 2 req/s 30 req/h
<Turl> is that reasonable limits?
<mnemoc> Turl: what about bw?
<Turl> it doesn't do any bw limiting
<mnemoc> Turl: set it to what you feel it's good
mike111 has quit [Ping timeout: 245 seconds]
<mnemoc> Turl: on #varnish I was told this module supported rate limits based on thresholds
<Turl> yeah rate limits as in req/time
<mnemoc> if it really doesn't. bye bye varnish. and let's use delay pools and the evil cephalopod
<mnemoc> of course it can also be a good idea to identify the abuser :p
<Turl> mnemoc: you used nginx right?
<mnemoc> notification time! 15:00-16:00 17GB
<mnemoc> Turl: that limits per-connection and without threshold
<mnemoc> Turl: punishing everyone
<mnemoc> and this traffic still doesn't include which still lives (peacefully) on the old server
<mnemoc> of which I need to get rid :|
<Turl> I don't see anyone using huge amounts of bandwidth
<mnemoc> >300GB yesterday :(
<Turl> the speediest one I see a mexican ip which judging by the speeds it's a 3-6Mb cable connection
<Turl> hopefully this 30req/hour limit fixes it
<Turl> mnemoc: do you have munin or such plotting bw usage?
<mnemoc> haven't installed anything of the sort yet
<mnemoc> 1m
<mnemoc> Turl: /q
eebrah has quit [Quit: Leaving]
rz2k has joined #linux-sunxi
Undertasker has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
fra79Wii has quit [Quit: Leaving]
n01 is now known as n01|work|away
torqu3e has quit [Ping timeout: 268 seconds]
rellla has quit [Quit: Nettalk6 -]
<Turl> mripard_: you were the barebox fan weren't you?
<mripard_> I am
<Turl> mripard_: someone is porting barebox to sunxi
<mripard_> yeah, I've seen someone discussing it quite some time ago on the barebox mailing list
ganbold_ has quit [Remote host closed the connection]
<bsdfox_> did someone mention i2c?
<mripard_> I did
<mripard_> but I have to go, sorry
<mripard_> ;)
<bsdfox_> thanks
<bsdfox_> I've got access to bus 1 and 2 on my mele
zumbi has quit [Quit: Changing server]
mnemoc_webchat has joined #linux-sunxi
vinifm has joined #linux-sunxi
<vinifm> libcrystalhd is used where?
<mripard_> bsdfox_: we don't have any support for the melee yet, but feel free to add it
<mripard_> If you need any help, don't hesitate to ask
<bsdfox_> alright
<mripard_> (I'm really off now :))
n01 has joined #linux-sunxi
shineworld has joined #linux-sunxi
<oliv3r> vinifm: that's broadcom's x264 accelerator
zumbi_ has joined #linux-sunxi
sanka has joined #linux-sunxi
<vinifm> oliv3r, hm, to H264 encoding?
<jelly-home> vinifm: decoding
<jelly-home> typically a cheap mini-pci card to plug into an atom netbook and make it able to play 1080p
<jelly-home> alright, sorry, mini-pcie
<vinifm> then it is necessary to have the card
<vinifm> ?
<oliv3r> vinifm: absolutly
<vinifm> libcrystalhd is useless without the card
<oliv3r> corrcet
<vinifm> thanks for help :)
<oliv3r> mripard_: barebox really u-boot v2? or has u-boot caught up dev again and it's just fine
<mripard_> oliv3r: barebox is nothing like u-boot v2
<mripard_> it was its former name, but it's a pretty bad one if you ask me :)
<mripard_> the development of u-boot hasn't stopped
<mripard_> it's just two completely separate projects
<n01> i like much more barebox :)
<mripard_> yeah, me too
<mripard_> but I didn't want to say that loud
<mripard_> too much u-boot fans around ;)
<n01> hahha :D
<n01> BTW I was looking to hno reply in ML, but I don't see that many arch_wdt_reset() inline functions around
<n01> but a lot of wdt drivers use the reboot_notifier
tinti has quit [Ping timeout: 258 seconds]
tinti has joined #linux-sunxi
<oliv3r> mripard_: well, it profile's itself as 'u-boot v2'
<mripard_> where?
<oliv3r> on the main page :p
<mripard_> yeah, "formerly known as u-boot v2"
<mripard_> ;)
<oliv3r> anyway, what makes barebox so special, meaning, why do we need it, what does it do that u-boot doesn't?
<mripard_> it has a sane configuration mechanism
<oliv3r> lol
<oliv3r> that's valid
<mripard_> you script it using a shell script
<mripard_> it has a single device model
<oliv3r> i just always cringe a little, when I see the 'nih' syndrome at work, and spreading manpower
<mripard_> a single API for gpios/clocks/ etc.
<n01> and it takes a lot of kernel frameworks
<mripard_> and the internals are mostly the same one than linux
<mripard_> so you can port to barebox a linux driver quite easily
<n01> also IIRC it has dt-support :)
<mripard_> u-boot has dt support as well
<mripard_> well, depending on what you mean by dt support
<mripard_> other than that, it has mostly the same features than u-boot
<mripard_> the hardware support is very limited compared to u-boot though
<n01> device drivers configurable at run-time with dt
<mripard_> yeah, to me, it's useless, but anyway :)
<n01> well, you can compile barebox just once and use it for several boards ... is it the same for u-boot? don't remember
<mripard_> you can use it for several boards? really?
<mripard_> then where does the dt comes from ? :)
<Undertasker> what does barebox better/different than u-boot?
<mripard_> Undertasker: backlog for like 20 lines :)
<Undertasker> ok
<Undertasker> tftp?
<mripard_> well then, the bootloader will have to know that the device has an ethernet chip, which one, at which address it's located
<n01> mripard_: :D
<mripard_> which is basically told by the dt :)
<n01> don't moke me
<mripard_> egg/chicken problem
<mripard_> n01: I'm not mocking you
<mripard_> well, at least, not in a mean way
<mripard_> but in a theorical point of view, yes, it would be great to have dt support from barebox
<n01> anyway, IMHO barebox is _very_ well written
<mripard_> but the image will still be for only one board
<mripard_> since you'll probably have to embed the dt in the binary
<techn_> unless board can be determined from machine id?
<techn_> or some fuses?
<mripard_> (and here, I sincerely hope that someone smarter than me will come up with a solution)
<mripard_> techn_: yeah, that's probably a solution too, but it's not generic anymore
<mripard_> because you have to know how to detect the machine
<mripard_> and it's soc-specific
<mripard_> moreover, that means that when you come up with a new board, you have to compile a new image embedding the new device tree
<mripard_> so you end up with again a specific image for your board :)
<mripard_> n01: but yes, I agree with you, it's cleaner than u-boot
<mripard_> still not perfect, but anyway
<mripard_> n01: oh, you did the support for the rpi
<mripard_> great :)
<techn_> 3-25
<techn_> Implementor, Variant, Architecture, Primary part number and Revision
<Undertasker> To be honest, the more I learn abut the rpi internals, the less I like it.
<mripard_> techn_: still, cortex a8
<mripard_> it only gives you an indication about the CPU
<mripard_> not the SoC
<mripard_> let alone the board
<techn_> true
mnemoc_webchat has quit [Ping timeout: 245 seconds]
tinti has quit [Ping timeout: 272 seconds]
<n01> mripard_: yeah, long time ago ;)
tkoskine has joined #linux-sunxi
CyberPK has joined #linux-sunxi
<CyberPK> why in is repeted twice the mkbootimg command?
tinti has joined #linux-sunxi
Tartarus has quit [Excess Flood]
Tartarus has joined #linux-sunxi
eebrah has joined #linux-sunxi
* slapin_n1 is awake finally
<slapin_n1> hi, all!
<slapin_n1> hno: are you here?
tzafrir has quit [Ping timeout: 264 seconds]
vinifm has quit [Ping timeout: 272 seconds]
vinifm has joined #linux-sunxi
sanka has quit [Remote host closed the connection]
tzafrir has joined #linux-sunxi
paulk-desktop has quit [Quit: Ex-Chat]
n01 has quit [Ping timeout: 255 seconds]
shineworld has quit [Remote host closed the connection]
<lkcl> libv: que?
<lkcl> ssvb: que?
<lkcl> ssvb: can you get me a list, and/or instructions on how to replicate this. i'll get onto allwinner if it's a GPL-derived work.
<lkcl> but, email me ok? it's very late here
<lkcl> ssvb: i've just done an unpack of the stuff at git://
<lkcl> ar x *.a
<lkcl> nm *.o | grep ff_
<lkcl> there's no sign of any ffmpeg code.
<lkcl> you'll have to point me at a more up-to-date version if there is one
<ssvb> lkcl: try "readelf -s | grep ff_" for the blob from that repository
<ssvb> and then google for some of the reported symbol names :)
CyberPK has quit [Quit: Page closed]
anunnaki has quit [Ping timeout: 256 seconds]
anunnaki has joined #linux-sunxi
Undertasker has left #linux-sunxi [#linux-sunxi]
vinifm has quit [Quit: Saindo]