<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 http://linux-sunxi.org/GPIO#The_Process , 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, http://dl-fr1.linux-sunxi.org 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 libvecore.so | 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
<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 ;)
<ssvb>
but it has one obvious buffer overflow bug and also is unable to support thumb2 instructions which are used in the current libvecore.so
<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?
<Turl>
gzamboni: does it accept requests for dl.linux-sunxi.org?
<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>
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_>
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: github.com/nand2/libvmod-throttle
<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