<mnemoc>
they are kept isolated in separated repos
<mnemoc>
not mixed with free projects
<mnemoc>
and important blobs need to be maintained too
<mnemoc>
but it's fine. np
<ssvb>
allwinner just needs to provide some sort of EULA for these blobs and the problem will be solved
<mnemoc>
but they won't
<mnemoc>
because they don't care
<ssvb>
yes, I suspected something like this
<mnemoc>
*they* point people to us when people asks for sources.... :<
<ssvb>
well, and the ARM guys point people to silicon vendor - http://forums.arm.com/index.php?/topic/16259-how-can-i-upgrade-mali-device-driver/page__p__39744#entry39744
<mnemoc>
"your request isn't worth of my time, go and bother someone else"
<mnemoc>
hipboi even sent a free mele and cubieboard to some ARM developers who promised to help with the integration and providing better blobs. they didn't.
<ssvb>
to me it looks like nobody simply wants to take responsibility in the case if shit hits the fan
<Alex1269_>
mnemoc, hi... Was too busy last week. Today I got some time for coding. I found a gpio_request function in sun3i/sun4i/sun5i platform code conflicting with gpiolib. To compile it I have to rename sunxi platform code function. Look this: http://sprunge.us/EaHA?diff - is this acceptable changes ?
<mnemoc>
Alex1269_: ouch
<mnemoc>
need to go to pickup my daughters. back in 20m
<mnemoc>
Alex1269_: please do the rename for both sunxi-3.0/3.4 branches, and separated from any gpiolib work
<mnemoc>
gpio_release will need it too
rsalveti has quit [Ping timeout: 276 seconds]
rsalveti has joined #arm-netbook
<ln2>
vinifm: A "binary blob" is an .exe / .bin / .deb ect. The term is normally used when a company releases software as a binary without providing the source. Making our lives very difficult.
<gzamboni>
its nice to know there are work in progress. when the gpio for the allwinner soc will support inputs it will be awesome
<gzamboni>
Thank you mripard
<mnemoc>
rellla: i believe lawrence is mostly convinced to do the sourcing and manufacturing research and then go for indiegogo to see if there is interest. the PCB part still unclear... GeorgeIoak mentioned interest
<hramrach>
but phones should have some reliability
<hramrach>
you don't went to interrupt your call because your hone needs a reboot
<hramrach>
+p
Quarx has quit []
<hramrach>
android suffers from the basic ARM device problem
<ln2>
Android suffers from a Java problem.
<ln2>
4.5 watt AMD chips already exist. We aren't limited to ARM anymore.
<hramrach>
buggy drivers are released, they are fixed enough to make a demo of the device working, if you are lucky a fix or two for most serious bugs is released after device goes to market. Then if it's broken you get to keep the pieces. The manufacturer has moved on to another device
<ln2>
Linux on ARM is rock solid. With Ubuntu Phone running on ARM and X86 devices we will have an apples to apples comparison.
<ln2>
Right now the best we can say is that Java sucks.
<hramrach>
ln2: it's the same blobware as arm so same problem
rellla has quit [Remote host closed the connection]
<ln2>
hramrach: Blobware comes from Google. Ubuntu Phone doesn't run in a java rapper, or have any proprietary software.
<hramrach>
at least you get chips directly from AMD who also designs them so you can possibly get drivers more easily than for ARM
<ln2>
*wrapper
<hramrach>
but that is to be seen
<ln2>
ARM GPU designs are used in only a subset of ARM powered devices.
<hramrach>
what does it run on?
<ln2>
Ubuntu Phone is Ubuntu ARM with a tiny Unity interface.
<hramrach>
the other GPU designs are also third party licensed by SoC maker
<jinzo>
regarding the AMD GPUs, unfortunately they're moving back to a closed drivers for good.
<hramrach>
they were never open in fact
<ln2>
I agree that other embedded GPU vendors are also closed. But my point is that our problems are not caused by the ARM architecture. ARM is not forcing anyones hand.
<hramrach>
when the X developers tried to make the card boot without any AMD blob the progress has somehow stopped
<ln2>
If PowerVR released its drivers tomorrow, we would all have ARM devices with full 3D with no proprietary code.
<hramrach>
yes, the problems are by closed architecture, not specifically arm
<ln2>
Absolutely. Thats where Ubuntu Phone is actually different.
<hramrach>
the additional problem of ARM is that you talk to SoC make who has no power over the IP of the stuff they put in SoC
<ln2>
It is in fact the full Ubuntu desktop OS running on an ARM device. With no proprietary code.
<ln2>
If just one embedded GPU manufacturer releases code, all of our dreams will come true.
<ln2>
But Google and Java are responsible for the problems with Android. Not ARM.
<hramrach>
no, no problem with java
mr_oz has joined #arm-netbook
<hramrach>
google has played the politics wrong around their code, though
<hramrach>
which worsens the problems we already have on ARM
<ln2>
Java is responsible for almost all problems with all software on Earth. The rest are caused by Flash.
<ln2>
But I don't exactly see what "ARM problem" exists? Stability? Efficiency?
<ln2>
Got disconnected for a second. =(
<hramrach>
stability due to lack of maintenace
<hramrach>
every SoC has some 1-2yrs lifetime
<hramrach>
you can't debug drivers for a device in that time
<hramrach>
and google adds to that
<ln2>
Sorry phone. I'm still here. =)
<hramrach>
on Windows lptop branding is done by setting the wallpaper and installing some vendor utilities
<hramrach>
on Android it is done by *implementing* the home screen app
pcat has joined #arm-netbook
<hramrach>
so ever vendor has differnt one with tons of bugs
<mripard>
hramrach: blame the vendors.
<mripard>
you could very well just change the default wallpaper.
<hramrach>
if google released something working I Am sure some would use that
<mripard>
the vendors choose to reimplement the launcher
<mripard>
they do.
extrados has quit [Ping timeout: 276 seconds]
<mripard>
see the nexus devices
<ln2>
Alright back.
<ln2>
Vendors write software bugs into Java applications. That is a massive problem.
<ln2>
However ARM architectures that are deployed into SoC's do not break compatibility. There is no ARM architecture bug that I'm aware of.
TestModule has quit [Ping timeout: 248 seconds]
<ln2>
I can cross-compile code from ARMv6 SoC to ARMv7 and there won't be any issues. That spans more like eight years, not two.
TestModule has joined #arm-netbook
<ln2>
However if there is any evidence of the ARM architecture itself causing a software bug, I would be very interested in seeing it.
<ln2>
ARM is being massively deployed in Top 500 supercomputers worldwide. I'm not sure they believe there is an architectural problem with ARM.
<ln2>
Now... with that in mind. I believe that they are delusional that those systems will have a higher performance per watt than Xen Phi, or even consumer i7's. But we will see.
<ln2>
*Xeon
<rm>
> ARM is being massively deployed in Top 500 supercomputers
<rm>
wat
<ln2>
Mont-Blonc will be the first.
<traeak>
being massively deployed?
<traeak>
i was looking at that list yesterday, a customer was asking us for suggestions for a mass processing system we're helping them set up (our software
<ln2>
By massively I don't mean massively adopted. I mean massive hardware installations ($$millions).
<traeak>
hmm
<traeak>
don't see arm anywhere on the top 500
<ln2>
I doubt that it will be massively adopted because as stated above, I believe that their performance per watt figures are inflated and inaccurate.
<traeak>
the floating point performance is pretty pathetic
<ln2>
*Also I meant the Top 500 Green. =)
<traeak>
ahh
<traeak>
our stuff is so double precision and branch heavy
<ln2>
To the extent that ARM does not have any architectural bugs or stability problems on a hardware level. I couldn't agree more that existing ARM chips are not suitable for scale.
<ln2>
However these systems would simply not exist if there was a massive problem with ARM architectures in general. What exists are software problems. That exists in the X86 world too. 40% of all desktops still run Windows XP. Thats a lot worse than minor bugs in vendor written Java applications.
<ln2>
traeak: You might want to look into Xeon Phi. ; )
<traeak>
ln2 too rich for us, we're actually pumping tons of throughput on just dual xeons
<traeak>
5k per machine is fine to keep up with one sensor :-p
<traeak>
for our stuff at least hehe
<traeak>
for MS i think that's a trailer of supercomputers
<traeak>
anyways
<ln2>
Xeon Phi would be a money saver actually. You get sixty (yes sixty) 1.0ghz ivy bridge cores for ~$600.
<traeak>
interesting
<traeak>
or last run was on 500k images, maxxed out at 56GB ram
<ln2>
These are medical images?
<traeak>
the algorithms can be 'fixed"
<traeak>
no
<traeak>
wait one
<traeak>
we have very high throughput geometric correct for sensors like pictometry, midas, etc. popular with apple, google, MS. we just need them to give us money (we're not big enough strangely)
<traeak>
the stuff you see when you zoom in on google maps or bird's eye on virtual earth or whatever apple has
<ln2>
I can't see any reason at all why that couldn't run on Phi. It may require some minimal porting. But the benefits could be tremendous. I'm curious why don't you guys already run CUDA?
<traeak>
because we're generalists
<traeak>
branch heavy double precision
<traeak>
strangely enough
<traeak>
we've run into some guys usiing gpus
<traeak>
strangely enough we're more correct and faster
<traeak>
some idiots were trying to do lidar scanner processing on a gpu single precision
<traeak>
using our code my buddy did a reference implementation
<traeak>
full double precision and we were 4x faster
<traeak>
our stuff ran on a laptop real time and they ahd to download the data to a desktop to run it as well
<traeak>
so they suck, we don't, etc i know
<traeak>
and speed isn't our game, ultra high precision is (and not being stupid)
<traeak>
i got my fill of special processing hardware in the late 90's. its a manpower and maintenance nightmare, and stops dead portabilty
<traeak>
today i could recompile everything and run it on an arm
<ln2>
That is a good point about code portability. I think that Phi might be a really good fit in that case since although it is an accelerator, it is an X86 / IvyBridge one.
<traeak>
that's probably worth looking into
<techn_>
cubie stuck on customs :(
<traeak>
yuk
<traeak>
need to get a cusotmer to buy one for us
<traeak>
i can tell you right now 8GB is'nt enough
<traeak>
it would force me to do a bunch of coding to get around the limitations
extrados has joined #arm-netbook
<traeak>
my partner's genius with calculus is in great part a big deal here. And our stuff scales linearly even to the quad socket amd systems with 48cores (and intels, the bottlenecks are different between those 2 systems)
<traeak>
sorry offtopic
<traeak>
where are the phis for 600usd?
<traeak>
one company ms bought gpu processing technology from, one of their partners told us: yeah their stuff is fast but the output is crap. but they dont' do geometric correction stuff, mostly just rectification engine and some image mosaic processing (the easy stuff)
<extrados>
I have debian booting on an a10 netbook, but lsusb doesn't show the wireless adapter. The adapter shows up and works in android. Any suggestions?
<techn_>
is cubieboard person or company? I need to give senders information for customs..
<techn_>
or should I just use Tom's name
<extrados>
(The adapter id is 0bda:8176 which corresponds to either RTL8188CE or RTL8188CUS)
<ln2>
I'm not sure that you can buy them individually *yet*. But you will be able to VERY soon.
<ln2>
There are already systems with Phi running.
<mnemoc>
techn_: company is "cubietech"
<w00tc0d3>
=/ =/ how to configure iptables? i did once & was locked out of my VPS LOL
<traeak>
w00tc0d3: very carefully. I still have nightmares over the first couple of iptables configurations I did.
<traeak>
of late i've just used the guis on my routers to deal with it
<drachensun>
Does any know if cedarx can be used to speed up video encoding like from a webcam stream?
<mnemoc>
drachensun: in theory it encodes too
<mnemoc>
the libva plugin is waiting for you
<drachensun>
ok, I was reading the contents of "instructions of CedarX recorder
popolon has quit [Quit: Quitte]
<drachensun>
ahhh ok, so that is the standard api that needs to a glue piece to cedar
<drachensun>
to have a glue piece I mean
w00tc0d3 has quit [Quit: No Ping reply in 180 seconds.]
simosx has joined #arm-netbook
simosx has quit [Changing host]
simosx has joined #arm-netbook
w00tc0d3 has joined #arm-netbook
<drachensun>
oh yeah, I finished that nand merge
<drachensun>
is there any interest in that?
<drachensun>
I didn't see any comments on the first patch
<drachensun>
i'm not sure I sent it right though
<mnemoc>
once you are happy, send it
<drachensun>
ok
<mnemoc>
i have quite a bunch of "pending" patches marked on the list because I can't test them atm. Acked/Reviewed-by replies would speed it up :)
<w00tc0d3>
YEAH!! OpenVZ = SHIT
<mnemoc>
vserver is much nicer than openvz
<w00tc0d3>
mnemoc: but this VPS is 3 euro/month :D
<mnemoc>
:)
<slapin>
mnemoc: you forget about Tested-by thingy...
<slapin>
drachensun: which nand merge?
<mnemoc>
slapin: that would be even better obviusly :)
<drachensun>
I needed that to fix NAND with the hynix ships they are shipping now
<drachensun>
I remember hno mentioning having trouble getting the hynix spec sheet
<mnemoc>
drachensun: so, will you start the libva plugin for cedarx? :p
<drachensun>
I wonder if its for the same chip
<drachensun>
mnemoc: Yes, but I can't start immediately.
<drachensun>
mnemoc: My hdmi output on the mk802 isn't working, I thought it was related to the new EDID changes but I pulled an old kernel and that didn't fix it
<drachensun>
x keeps having segfaults
<mnemoc>
:|
<w00tc0d3>
Hmm. I have a request for everyone here. :) If someone has a nice dedi server with a core i5, and 8-16GB RAM, could I get access to it please? Because, I'm building Android ROMs, and I want to run unstable builds every night :) Thank you in advance!
<traeak>
ouch, something like that is pretty cheap to acquire
<mnemoc>
vinifm: you *decided* pull = 3 means repeater, documentation doesn't say anything about that value. and no .fex uses it
<extrados>
Thanks again. I was able to get my wireless working with the script.bin tip. I just had to chang the usb_init_state to 1
dyoung-away is now known as dyoung
jochensp has joined #arm-netbook
<vinifm>
yea, was just an attempt
<jochensp>
Hi, I have distored sound on a mini x (allwinner A10) with linux, any tips?
ibrah has joined #arm-netbook
<w00tc0d3>
is there an API to create repos @ GitHub?
<mnemoc>
w00tc0d3: #github ?
<WarheadsSE>
jochensp: define "distorted sound"
<jochensp>
WarheadsSE: overdriven I would say
<jochensp>
WarheadsSE: it's gone when I turn the volume really low, but than it's not loud enough
<jochensp>
and it's not the case with android
<WarheadsSE>
mm
<WarheadsSE>
compared the two fex?
<w00tc0d3>
interesting...
<w00tc0d3>
making a script to push all my Android repos (~150) to github
<mnemoc>
w00tc0d3: it's a better idea to fork the already existing repos
<jochensp>
w00tc0d3: copied the one from the device, no difference
<w00tc0d3>
mnemoc: these are from android.googlesource.com
<jochensp>
@WarheadsSE meant you
<mnemoc>
w00tc0d3: it's for bw and storage economy
<mnemoc>
jochensp: don't prefix nicks with @ in irc
<mnemoc>
jochensp: many clients won't highlight the nick match
<jochensp>
mnemoc: sorry, thanks
<jochensp>
WarheadsSE: I've copied script.bin from the device, used bin2fex and update the fex from the repo (changed dram.c as well), is there any other place I have to change the values?
<WarheadsSE>
no, those are the likely places.
<WarheadsSE>
admittedly I've never had overdriving issues on the A10's I have
<jochensp>
WarheadsSE: should I post my fex files somewhere, because the had some different values to the once in the repro
<WarheadsSE>
that ones not up to me
<jochensp>
any other idea? Could it help to upgrade android to the latest version and get the fex stuff from it?
<techn_>
with that you can reproduce pageflip problem easily
<techn_>
seems that offscreen rendering doesnt work with normal layer :/
vinifm has quit [Quit: Saindo]
<ssvb>
techn_: is the problem in FBIOPAN_DISPLAY?
<ssvb>
techn_: in any case, FBIOPAN_DISPLAY is only suitable for fullscreen, so it has limited utility
gimli has quit [Ping timeout: 248 seconds]
freakazoid0223 has joined #arm-netbook
ln2 has quit [Ping timeout: 252 seconds]
ibrah has quit [Ping timeout: 255 seconds]
mr_oz has quit [Quit: Leaving]
eFfeM has quit [Quit: Leaving.]
popolon has joined #arm-netbook
eFfeM has joined #arm-netbook
ln2 has joined #arm-netbook
<jochensp>
WarheadsSE: just upgraded to the the newest android, copied a new .fex, still same problem, sound is disterted when I put master volume above 50%, any other ideas?