<arokux2>
I've changed country to my country, but nothing helped same shit.
<wens>
arokux2: i would look for why it was disconnected: <6>CFG80211-ERROR) wl_cfg80211_disconnect : Reason 3
pitillo has quit [Ping timeout: 246 seconds]
tinti has quit [Quit: Leaving]
bsdfox\ has quit [Ping timeout: 252 seconds]
bsdfox\ has joined #linux-sunxi
<arokux2>
wens: giving up for today
<arokux2>
good night
techn_ has quit [Read error: Connection reset by peer]
arokux2 has quit [Ping timeout: 246 seconds]
TehCaptain has quit [Read error: Connection reset by peer]
TehCaptain has joined #linux-sunxi
kenny has quit [Read error: Operation timed out]
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #linux-sunxi
arete74 has quit [Ping timeout: 246 seconds]
kenny has joined #linux-sunxi
bsdfox\ has quit [Remote host closed the connection]
hipboi has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
derethor has quit [Read error: Connection reset by peer]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
pirea has joined #linux-sunxi
apo has quit [Ping timeout: 245 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
pirea has quit [Quit: Leaving]
torindel has quit [Ping timeout: 264 seconds]
torindel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hipboi_ has joined #linux-sunxi
hipboi has quit [Ping timeout: 272 seconds]
apo has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
FDCX has quit [Remote host closed the connection]
aep has quit [Read error: Operation timed out]
aep has joined #linux-sunxi
Taduro has quit [Ping timeout: 248 seconds]
eagles0513875 has quit [Remote host closed the connection]
cubear has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
FDCX has joined #linux-sunxi
wolfy has joined #linux-sunxi
Quarx has joined #linux-sunxi
atiti has joined #linux-sunxi
Taduro_ has joined #linux-sunxi
rellla has joined #linux-sunxi
gzamboni has joined #linux-sunxi
maz_ has quit [Read error: Operation timed out]
n01 has joined #linux-sunxi
Turl has quit [Ping timeout: 252 seconds]
AreaScout has joined #linux-sunxi
Turl has joined #linux-sunxi
deasy has joined #linux-sunxi
<wens>
arokux: bummer, my usb dac is full speed, not high speed
<wens>
arokux: and my thumb drives don't work with EHCI only. seems tey do full-speed first, then switch to high-speed.
atiti has quit [Quit: Leaving]
<wens>
arokux: I pushed some cleanups, and proper clock support for stmmac
wolfy has left #linux-sunxi ["Un barbat nu este complet daca nu este insurat. Abia atunci este terminat. (Robert Frost)."]
FR^2 has joined #linux-sunxi
arete74 has joined #linux-sunxi
notmart has joined #linux-sunxi
<arokux>
wens: hm.. so thumb drive won't work with current patches for usb host?
<wens>
arokux: i tried a thumb drive and a usb sd card reader. no response at all
<arokux>
wens: I see.
<wens>
arokux: ethernet dongle works though
<arokux>
wens: I'll continue to work on it once I've sorted out things with support of ct in sunxi-3.4
<arokux>
it is important, so that we have users
<wens>
:)
<wens>
a friend of mine is going to buy a ct, and he'll lend it to me for a few days to do some testing
<arokux>
wens: I'd ask cubietech to donate you one
jinzo has joined #linux-sunxi
jinzo has quit [Changing host]
jinzo has joined #linux-sunxi
hipboi_ has quit [Ping timeout: 272 seconds]
<wens>
mripard: the a20 smp code cannot be compiled in Thumb-2 mode
<wens>
mripard: arch/arm/mach-sunxi/headsmp.S:16: Error: Thumb encoding does not support an immediate here -- `msr cpsr_fsxc,#0xd3'
<mripard>
n01: pong
popolon has joined #linux-sunxi
<mripard>
wens: hmmm, ok
<n01>
mripard: hi ... for the lradc I have a really weird problem. I successfully read from channel 1 but I got a timeout when reading from channel 0 ... have you any idea why?
<n01>
it's really annoying
<mripard>
wens: then you can reply to Fan :)
<mripard>
but I'm not sure it's really worth going further with Fan's code
<mripard>
He's pretty much MIA
<mripard>
and Marc has PSCI working
* wens
has no idea what that is
<mripard>
a standard interface pushed by arm to do all the cpu-related operations
<mripard>
like powering up a new cpu, going into suspend, etc.
<wens>
i see, so that should be better
panda84kde has joined #linux-sunxi
<mripard>
so what he has is u-boot setting a small firmware in the SRAM, and that firmware is actually the one doing all the work
<mripard>
and linux only contacts it through PSCI
<mripard>
and it requires 0 change in the kernel, apart from adding a few nodes to the DT
<arete74>
ls
<mripard>
password:
<wens>
mripard: do you think we should switch to gmac/stmmac for cb2 and olinuxino-micro?
<mripard>
aren't those not able to use gmac?
<oliv3r>
i would, gmac hardware is more bug free then emac :D
<wens>
mripard: i am using cb2 for testing :)
<mripard>
ok
<mripard>
I thought those didn't have a phy with the right *MII
<oliv3r>
but with olimexino, you can add a phy to the ata port on a20 so on olimexino-a20
<wens>
mripard: GMAC supports MII
<wens>
oliv3r: second ethernet port on a custom expansion board?
<oliv3r>
wens: i thought you where said gmac was missing gmac pins
<oliv3r>
erm GMII pins?
<wens>
oliv3r: yes, but no board uses a GMII phy.
<oliv3r>
so only MII, RMII and RGMII where suppored?
<oliv3r>
but yes, EMAC can be done via a expansion board if created as I think those pins are brought out
<wens>
don't know about RMII. MII (on cb2) and RGMII (on ct) definitely yes.
<oliv3r>
MII and GMII aren't compatible are they?
<oliv3r>
i mean backwards*
<oliv3r>
e.g. same number of pins?
<oliv3r>
MII is 16 pins, right?
<oliv3r>
hmm, EMAC is 18 pins
<wens>
oliv3r: 16 pins for MII + 2 pins for MDIO/MDC
<wens>
and TX_ERR (pin PA17) isn't even connected, according to cubietech layouts
<mripard>
wens: then yes, of course we can enable it if it works :)
<wens>
the signal is rarely used, according to datasheets, and the boards seem to use it for phy hardware reset (but it's left unconnected)
panda84kde has quit [Ping timeout: 252 seconds]
<wens>
oliv3r: GMII uses 24 pins, RGMII only 12
<oliv3r>
ah no, MII is 16 pins + 2 mdio/mdc pins
<oliv3r>
oh you siad that; and there i go figuring things out
<oliv3r>
TX_ERR is very rarly used according to wikipedia
<oliv3r>
I should read ALL replies first before commenting :)
<oliv3r>
wenns is to awesome :)
<wens>
oliv3r: i spent a day reading wikipedia and phy datasheets :)
<oliv3r>
:p
<oliv3r>
so if i understand GMII is MII + 2x 4 lines for TX/RX extra
<oliv3r>
e.g. 4 bit vs 8 bit tx/rx lines
<torbenh3>
oliv3r: and higher clockrate... 125 MHz....
<wens>
oliv3r: yes
<wens>
pushed dts for cb2 and olinuxino-micro
<oliv3r>
cool
<oliv3r>
anyway, I feel stronlg yon using the GMAC driver by default on A20 designs using PA for network
<oliv3r>
a) this leaves EMAC on PH easily available
<oliv3r>
b) possibly avoiding issues in the EMAC that where seen in the past
<wens>
wiki mainline page updated :)
Black_Horseman has quit [Ping timeout: 272 seconds]
apo has quit [Read error: Connection reset by peer]
<mnemoc>
oliv3r: an alternative to categorytree that arokux wants
<oliv3r>
ahh ok
<binaryferret>
What's the best way to start debugging a touch screen driver? I'm really lost as to why it isn't working and because I'm still new and learning I'd appreciate if someone could point me in the right location of where to begin looking.
<binaryferret>
I've been going through Xorg.0.log seeing if there are any devices that have been handled that match, but alas nothing
<mnemoc>
binaryferret: uinput
<binaryferret>
I've checked /dev/input/eventX to see if they're registering anything.
<binaryferret>
mnemoc: uinput. Okdokey. Will google, and go from there. Thanks.
rz2k has quit [Ping timeout: 245 seconds]
<mnemoc>
err... no
<mnemoc>
that's not the name of the input event watcher
<mnemoc>
evdev
<binaryferret>
evdev
<mnemoc>
uinput is to inject inputs from userspace apps
<binaryferret>
I didn not know about uinput. evdev is, although I wasn't sure how to probe it. I'll look closer into that area.
<kriegerod>
arokux: could you tell what git branch results in this? even if yours experimental branch
Guest82257 has quit [Ping timeout: 245 seconds]
Quarx has quit [Ping timeout: 248 seconds]
cubear has quit [Quit: Leaving]
Black_Horseman has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Black_Horseman has quit [Quit: Αποχώρησε]
mouchon has joined #linux-sunxi
Seppoz has quit []
<honx>
i saw those mails on the list about mainlining a display driver. do they mean the limadriver?
adb has joined #linux-sunxi
yousong has joined #linux-sunxi
tomee^ has joined #linux-sunxi
<libv>
honx: contrary to fd.o thinking, there are many parts to graphics hardware and graphics drivers
<libv>
honx: there's things like display, 2d accel, 3d accel, media decoding, media encoding
geecko has joined #linux-sunxi
<libv>
honx: does lima cover all that?
<libv>
honx: if not, what part does it cover?
<honx>
i have no idea, sorry. i just read that mail and was wondering what driver they're talking about...
<libv>
honx: lima is for the arm mali, which is a 3d core
<honx>
ah, ok.
<honx>
is any graphics functionality for the sunxi chips already in mainline?
<libv>
nope
<libv>
disp is huge and complex
<honx>
ok. i'm working with an a20-olinuxino and a cubietruck here..but only on console. somehow it never occured to me to connect a monitor ;)
<libv>
and as i have proven over the years, again, contrary to fd.o thinking, it's much more difficult to get right than the support for a well designed 3d engine
<honx>
fd.o = freedesktop?
<libv>
honx: yes
fredy has quit [Excess Flood]
<arokux>
kriegerod: cubie/sunxi-3.4
<libv>
honx: there is some info on setting up display and other bits, up on our wiki
<honx>
libv: but thats for the 3.4 kernel, right? i'v got display working with that kernel. i was just wondering about the mainlining efforts..
<libv>
honx: ok
<honx>
i'm working on a common software platform for a number of products (some with display, some without). and we started with 3.12 and not the "old" 3.4 stuff. the display stuff is not hugely urgent though...we can wait until it shows up in mainline (or at least mainine patches are available..)
<honx>
i hope we can contribute some work/code back to the project...
<kriegerod>
now i tried stage/sunxi-3.4 with mostly arch/arm/configs/sun7i_defconfig for my CT, got no sunxi_gmac module, but sunxi_emac; loading it tells "emac_init fetch emac using configuration failed". What do i miss?
<libv>
honx: as said, display is a big and complex subsystem that is hard to get absolutely right
<kriegerod>
can it be ethaddr bootarg missing?
<libv>
unless someone clued with a lot of stamina does it, nothing will happen there. and no small shop which uses the ultra cheap allwinner hw is going to be willing to back such a big effort
kaspter has joined #linux-sunxi
<honx>
ok, thanks. i'll forward that information...
<kriegerod>
i got it. i miss some script.bin entries
<kriegerod>
is sunxi_gmac -> sunxi_emac a rename?
<libv>
honx: i have rather hands-on experience with how cheap small shops like to sponsor display development, even when it is absolutely essential to their product.
<libv>
honx: so please, leave the mainline fetish at the door, and stick to 3.4
<honx>
ok, i'll keep that in mind :)
kaspter has quit [Remote host closed the connection]
zeRez_ is now known as zeRez
<zeRez>
How well is the mali running outside android nowadays? read about linux images providing 2/3D Acc. ?
<zeRez>
And most important, vpu support
<oliv3r>
kriegerod: no
<libv>
zeRez: scroll back half an hour
<zeRez>
ok
<zeRez>
:)
<zeRez>
thanks sir
<libv>
as for the first part of your question, we have working binaries
<libv>
and the mesa driver is now getting almost useful, i think i just did enough plumbing work to be able to tackle resizing
kaspter has joined #linux-sunxi
n01 has quit [Ping timeout: 272 seconds]
notmart has quit [Ping timeout: 252 seconds]
notmart has joined #linux-sunxi
kaspter has quit [Client Quit]
<oliv3r>
libv: can't wait to try it!
<Turl>
kriegerod: no, they're two completely different hardware components
<Turl>
kriegerod: you need gmac for cubietruck
<oliv3r>
Turl: soon you'll need gmac for A20 generally, and emac only if it's connected to the other ports ;)
<Turl>
yeah but meanwhile I can keep using emac on cb2 :p
<zeRez>
libv so its no problem to use the binaries to get the mali/vpu working? But a binary is depends on kernel it is build for right?
<mnemoc>
the blobs mostly only use mmap and ioctrl()s to reach the hw directly... the kernel drivers are just interfacing
<zeRez>
Turl gmac == general mac? so the mac of the device itself?
<zeRez>
okay
<mnemoc>
gmac = gigabit ethernet mac
<oliv3r>
zeRez: vpu != GPU
<Turl>
zeRez: g must be for gigabit or something
<zeRez>
oliv3r i know
<kriegerod>
Turl: but i see no sunxi_gmac in github.com/linux-sunxi/linux-sunxi, branch sunxi-3.4
<oliv3r>
zeRez: VPU is a sperate piece of IP completly unrelated to Mali, disp etc drivers
<zeRez>
Turl okay
<mnemoc>
kriegerod: stage/sunxi-3.4
<Turl>
kriegerod: that's because it's not there yet :)
<zeRez>
iam really new to this stuff, but i try my best to understand
notmart_ has joined #linux-sunxi
<kriegerod>
have just done find * | grep sunxi_gmac
<kriegerod>
in stage/sunxi-3.4 rootdir
<mnemoc>
kriegerod: | grep allwinner/gmac
<zeRez>
oliv3r perfect, know the site but dont know theres a "guideline" on there ^^
<mnemoc>
zeRez: write one ;-)
<kriegerod>
mnemoc: no results
notmart has quit [Ping timeout: 246 seconds]
<Turl>
kriegerod: net/ethernet/allwinner/gmac
<zeRez>
mnemoc no problem, but i have to understand the hole thing first :P
<zeRez>
iam really intrested in these little arm devices...
<Turl>
err, drivers/...
<zeRez>
and iam thinking about buying a ct so thats why i ask for mali and vpu support on linux cause i dont wanna use android at all
<kriegerod>
hm. seems i was not on last commit
<mnemoc>
shame on you
<zeRez>
But in conclusion the problem with gpu drivers are all the same right? what i know so far about the freescale guys is that there are binaries only too...so it makes no difference if i choose a20 or i.mx!?
<oliv3r>
zeRez: there's a LOT of information on the wiki ;)
<oliv3r>
zeRez: olimex is OSHW so much higher recommended ;)
<oliv3r>
zeRez: check out their 'Lime' anouncement, olimex.com
kaspter has joined #linux-sunxi
<zeRez>
oliv3r okay okay, i will stop asking and will read there :)
<oliv3r>
actually that's on their blog :)
kaspter has quit [Remote host closed the connection]
<zeRez>
oliv3r ive read about the release of the olimex devices...but from specs i would prefer a wandboard!?^^
<oliv3r>
zeRez: A20 has the benevit of having a MALI gpu, which libv is working extremly hard on having opensource drivers.
<oliv3r>
benefit too
<zeRez>
so libv is the founder of the lima project? :)
<oliv3r>
yes
<zeRez>
libv thanks for the project!
<zeRez>
^^
<oliv3r>
we have people here also of the cederus project, e.g. opensource driver for cedarX, the VPU on A20
<zeRez>
oliv3r sure mali is nice, but whats with vivante gc2000 from imx6q?
<oliv3r>
so A20, in a year or two can be fully opensource, without zero blobs
<oliv3r>
zeRez: not sure on that status
<zeRez>
so theres still movement on the a20 site, good to know :)
<zeRez>
*side
<zeRez>
Damn, its a hard choice which device to buy -.-
<zeRez>
whant to find the most opensource friendly one
<oliv3r>
zeRez: not really, olimex-a20-micro or olimex-lime ;)
<zeRez>
because opensource you mean? ^^
<zeRez>
wandboard is oshw too
<zeRez>
but more expensive
<oliv3r>
i'm personally waiting for the olimex-a20-lime v2, which is rumored to feat. gigabit, but that may veryw ell be a year or two away :p
<oliv3r>
zeRez: it is?!
<oliv3r>
ah, the board is OSHW, the SoC needs blobs
<zeRez>
yes
<zeRez>
think the same with olimex, they use freescale socs too!?
<zeRez>
oh sorry, got it wrong... the OLinuXino is using an a20 too
<zeRez>
the MarS board was using an imx
<mnemoc>
there are olinuxinos que several different specs and socs
<mnemoc>
s/que/with/
<zeRez>
yeah...but not all availiable in my country -.-
<zeRez>
-i
<zeRez>
sry no native ^^
<zeRez>
atm. iam between cubietruck and wandboard quad
hglm has joined #linux-sunxi
nove has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Leaving]
<zeRez>
cubietruck is less expensive, but dont know whats up with freescale and their support for os...hard nut ^^
<hglm>
There is also an upcoming rockchip board (fast) from Cubie...google radxa
<zeRez>
if i had enough money i would take both :P
<mnemoc>
nice, didn't know wand had added a quad version
<zeRez>
hglm yeah i read it...but from rockchip i know nothing, how linuxfriendly are there chips?
<zeRez>
mnemoc yes they did, and it has the big gpu (gc2000)
<mnemoc>
zeRez: /j #linux-rockchip
<hglm>
zeRez: Not very, but kernel sources seem to be available now
<libv>
zeRez: rockchip has a nonfree bootloader, and the community for its linux support is pretty early
<zeRez>
okay, so maybe not the best choice yet
<mnemoc>
hopefully the radxa rock will help them to grow
shineworld has joined #linux-sunxi
<zeRez>
would be nice!
<libv>
the issue with allwinner is pvr for the more powerful versions
<zeRez>
pvr?
<libv>
and therefor limited popularity
<libv>
imagination technologies powervr sgx
<mnemoc>
same gpu as the omap5, VERY closed :<
<libv>
and very awkward
<hglm>
The Mali400MP4 on the RK3188 is pretty fast..old GPU core but at 28nm fillrate is 8x that of A10.
<mnemoc>
probably they keep things closed to hide their shame :p
<zeRez>
libv ah okay, know it :)
<libv>
hglm: 2x of that is process based
<hglm>
libv: you mean threads?
<libv>
hglm: no, the frequency at which the chip is able to operate
<hglm>
libv: Yes, I understand..also the memory paths/bandwidth is a lot higher in the RK3188.
<zeRez>
hm, so i think allwinner vs. freescale the allwinner has the better community atm!?
<zeRez>
thats a important factor i forgot to think about
<libv>
it is claimed that the mali frequency is 600MHz on rk3188, at 4x PPs
<libv>
zeRez: i do not think there is any community as advanced as sunxi atm
<zeRez>
yeah thats what i mean
<hglm>
libv: I have the impression that Rockhip has lowered their clock rates in recent firmware -- for example I have a tablet that only runs at about 420 MHz for Mali (1.4 GHz CPU) -- the tech ref for the 3188 from Rockchip on the Radxa site also mentions 1.4 GHz as max CPu.
<libv>
ok
<libv>
well, depending on workload, you can almost see that linearly
<libv>
as PPs do one pixel per clock
<hglm>
libv: Yeah, I noticed the tablet has lower 3D benchmark throughput than older RK3188 devices with more aggressive firmware.
<zeRez>
libv my mainreason for get a sbc is for research...want to learn more about processing units and get a indepth look how it works, thats why iam searching the most opensource friendly one and of course a good community...maybe iam right here and with allwinner SoC?
dack has joined #linux-sunxi
yousong_ has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
<libv>
zeRez: get one of the featured devices on our front wiki page
n01 has joined #linux-sunxi
yousong has quit [Ping timeout: 265 seconds]
<oliv3r>
olimex is strongly recommend at the moment ;)
<zeRez>
oliv3r i prefer cubietruck atm..what would be the benefit against it when i choose olimex?
<zeRez>
half of RAM :P
<zeRez>
?
<libv>
zeRez: olimex is full OSHW
<zeRez>
so cubie isnt?
<oliv3r>
OSHW
<oliv3r>
cubie isn't
<zeRez>
kk
<zeRez>
its a reason!
<zeRez>
oh yeah it has composite too :)
<zeRez>
so differences oli vs ct: 100MBit/1000MBit LAN, 1GB/2GB RAM, NAND both 4gb?, Oli is OpenSource Hardware and less expensive
<ganbold_>
zeRez: one problematic thing could be documentation with Chinese SoC vendors
<libv>
zeRez: i don
<zeRez>
ganbold so theres no international extension!?
<zeRez>
translation
<zeRez>
sry
<zeRez>
^^
<libv>
't think we have the gbit ethernet fully working yet
<libv>
but several folks in here are hard at work on it
<ganbold_>
but luckily there is such community like linux-sunxi, but still documentation is really needed sometimes
<zeRez>
ganbold but thats a problem with all these socs? accept freescale?
<zeRez>
libv okay
<zeRez>
so gbit ethernet isnt much important for me
<zeRez>
but ram
<ganbold_>
zeRez: I meant if you port or write driver then full documentation should be really usefull
codingrobot has quit [Ping timeout: 264 seconds]
<libv>
zeRez: both olimex and cubie is heavily recommended, pick on the basis of the features you need/prefer
<ganbold_>
if I'm not mistaken freescale im.x5/6 etc has better doc
<zeRez>
and sorry guys that i kill youre nerves with my questions, but i have only a very little budget and have to make the right choice! ^^
<ganbold_>
zeRez: cubie/olimex should be good :)
<zeRez>
libv cubie is more future secure cause gbit/2gb ram ^^
<zeRez>
but olimex seems to be a nice device too and its os
<zeRez>
^^
<libv>
zeRez: there will be a new gen in 6 months anyway
<zeRez>
from what?
<zeRez>
cubie? oli? both?
<zeRez>
^^
codingrobot has joined #linux-sunxi
<libv>
zeRez: that's how fast things move with ARM SoCs these days
<libv>
worse than with desktop graphics hw 6 years ago
<zeRez>
yeah
<zeRez>
6 months and we are in another world
<Turl>
slapin: re. mail, pretty sure VGA is available on the headers
<zeRez>
but its good, so more vendors will come up maybe ^^
<Turl>
slapin: cubie guys sell an expansion board with a connector
<libv>
zeRez: both cubie and olimex guys are active parts of our community: the featuresets and price will be different for the different boards: olimex being oshw which is the biggest differentiator
<libv>
and there is simply no futureproofing with this hw, match your requirements of today.
<zeRez>
but how can it be oshw with a non os SoC on it!?
<zeRez>
^^
<zeRez>
okay, would be the best idea to do it like you said
<zeRez>
in 6/12/24 months its depricated
<libv>
zeRez: allwinner A1x/A20 is the most open source friendly ARM SoC out there
<libv>
zeRez: but that has nothing to do with OSHW
<libv>
zeRez: full schematics and board layout files are available
<libv>
you could, in theory, build your own board from scratch
<libv>
and you can adapt designs to your needs
Quarx has joined #linux-sunxi
<libv>
(and then get olimex to build you the boards ;))
<zeRez>
yes iam reading at the olimex page atm ^^...
<zeRez>
or i just whant to support os community :)
<zeRez>
the more ppl buy oshw the more oshw will be build ^^
<zeRez>
and when i see it right, the olimex has a sata power jack what means that i can run 3,5" sata without extras!?
<jinzo>
libv, regarding OSHW - didn't cubie post mechanical files too? (don't know the license tho)
<libv>
jinzo: i would expect our wiki to have been adjusted if cubie was fully OSHW
<zeRez>
okay theres one thing that benefits more for me on cubie, the build in wifi
<zeRez>
damn
<zeRez>
^^
<zeRez>
its a really hard nut for me to pick one of them
<zeRez>
^^
<oliv3r>
Turl: on which board? olimex has VGA output; cubieboard12 both have headers
<mnemoc>
CT has VGA :)
deasy has quit [Remote host closed the connection]
<Turl>
oliv3r: cb1/2, see the thing I linked
<oliv3r>
I wish we could get the Lime!
<oliv3r>
Turl: yeha i read the 9other things first
<mnemoc>
Turl: what about reviving allwinner-common and porting 4.4? :p
<oliv3r>
wasn't atsampson working on that
<mnemoc>
ART is supposed to run nicely on 512MB
<mripard>
ART is not used yet
<zeRez>
Okay, atm for my usecase i prefer ct...i will see what i take at the end :P... libv are you know anything about new boards in 6 months? and btw what are you guys own for boards!? :P
deasy has joined #linux-sunxi
<Sonic1>
Are you saying that not having a jit compiler on each application launch actually improves performance?
<Sonic1>
:P
yousong_ has quit [Quit: leaving]
<mnemoc>
libv: can the lima stuf be separated into an standalone lib (then hooked into mesa) so it can be used on AOSP too?
<mnemoc>
android using open source GPU and VPU drivers, even if REed and incomplete, will be amazing
<oliv3r>
zeRez: within 6 months, hopefully within 1 :p there will be the olimex Lime, hopefully with gbit at launch ;)
<oliv3r>
zeRez: most of us have olimex and cubie boards ;)
<oliv3r>
mnemoc: how will you integrated surfaceflinger or whatever they use :p need that too
<slapin>
Turl: it will be too slow for me to order anything, I need everything running tonight :( or, better, yesterday :(
<mnemoc>
oliv3r: integrating lima and the cedarx REed lib into android is another story
<zeRez>
oliv3r roger that :)
<mnemoc>
oliv3r: but "it's just glue" :p
<oliv3r>
slapin: what hardware do you have exactly
<Turl>
slapin: well, if you have a vga thing, some jumper cables, soldering iron and a 75 ohm/kohm (don't recall) you should be all sety
<oliv3r>
mnemoc: cederus shouldn't be huge once we have cederus :p
<mnemoc>
well... the thing already decodes h264 and mpeg2 iirc
<mnemoc>
and for the rest, NEON ;-)
<mnemoc>
on ffmpeg
dack has quit [Ping timeout: 246 seconds]
<wens>
Turl: BNC connector? # 75 ohm
dack has joined #linux-sunxi
<slapin>
oliv3r: original cubie1 without case, just plain board, USB cable, and sata cable
<Turl>
wens: dunno :p I just read it on the list
<slapin>
Turl: I can solder directly to VGA if I must. I have jumper cables, resitors, soldering station, etc. I jut need instructions :)
<oliv3r>
slapin: yeah you can check the pinout and connect vga there (or composite) don't think you need (many?) active components
<oliv3r>
passive*
<oliv3r>
slapin: check the Cubietruck schematic for passives
<oliv3r>
should be identical; specilaly with a10 and a20 being pin compatible
<hglm>
Based on my limited experience with the A20 chip (Android tablet) I have some concerns about it (hardware side). Is anyone using the A20 without experiencing random unexplained hardware lockups? Is it adressable/has it been addressed with kernel changes such as config/CPU handling/governor/speed? I guess it is possible that certain hardware bugs may not be possible to work around...correct me if I am wrong.
<slapin>
hglm: /me, but I use A20 as headless appliance
<slapin>
hglm: and hardware quality varies.
<rz2k>
hglm: there was a topic somewhere around ML about hard lockups happening from time to time
<slapin>
Turl: I'm out of 74AHCT04 :(
<hglm>
slapin: Good to hear, I guess it could be depend on the board as well as chip stepping etc. But at least in this Android tablet the chip seems to be crippled (runs at 720 MHz, locks up randomly, very low android 2D speed, screen refresh limited to 14fps for some reason). And it is not suprising that the A20 has failed commercially in the chinatab market.
<rz2k>
they were happening because of UART
<Turl>
slapin: the vga signals are on the header apparently
<slapin>
hglm: $50-tablet? I had some like this, it is quite unstable
<Turl>
slapin: pin 27, 30
<slapin>
rz2k: hi!
<slapin>
rz2k: can we talk?
<hglm>
slapin: It was not the cheapest tablet, has an IPS screen, and build quality not too bad at first glance. I am thinking it needs something drastic like disabling L2 cache.
<rz2k>
slapin: not right now, I'm at work, sorry
<slapin>
hglm: btw, check that script.bin has no errors, too, mine had one pin set as output which led to fast battery discharge
<rz2k>
slapin: I will get back home around 22 gmt+4
<slapin>
rz2k: just gimme link to your mtd git please
<hglm>
slapin: Thanks, I did notice that Allwinners "fantasys" governor in Android rarely revs down from 720 MHz which isn´t good for battery.
<slapin>
rz2k: thanks!
<libv>
mnemoc: intel from time to time fixes up the mesa build for android
<slapin>
hglm: dunno, mine was ok regarding power, but yours seems to have RAM problems, hence bus speed reduced.
<libv>
mnemoc: so it really is just a question of fixing up the build system and small issues
<slapin>
hglm: mine was totally broken, could not live more than 40 minutes on battery and was very hot, but it is some cheap, like $56 or something.
<slapin>
hglm: but it was running off smaller MHZ values. Check what prevents it from sleeping, like interrupt counters
<slapin>
hglm: all different hardware is different, anyway
<hglm>
slapin: I tried linux-sunxi on it a few months ago but didn´t work, I did run Linux (Debian) in a chroot environment on it. I can try again and tweak some kernel settings.
<slapin>
hglm: also mine had some rape done to power chip, which made me to put resistor on 5VDC to prevent heat during charge
<arokux>
anybody with working wifi on ct?
<wens>
arokux: do we have a spec sheet for the chip? i can't even find a manufacturer
<slapin>
hglm: try with proper script.bin, it should boot. If not, solder serial port and look (but check tha there is no incompatible settings in your script.bin, or you will get lockups).
<arokux>
wens: not that I know.
* slapin
still waits for some ct donation, might be best NY present for him
<hglm>
slapin: I will double check the script.bin.
ZetaNeta has quit [Ping timeout: 246 seconds]
pfdm has joined #linux-sunxi
<torbenh3>
wens: manufacturer is broadcom
<torbenh3>
wens: ap6210
<wens>
torbenh3: don't see it listed in broadcom's data
<torbenh3>
me neither.
<wens>
the best i could dig up:
<wens>
AMPAK AP6210 (Broadcom WiFi IP BCM43362 + Broadcom BT IP BCM20710)
<torbenh3>
yup... also got that.
iamfrankenstein has quit [Read error: Connection reset by peer]
<torbenh3>
so wifi is BCM43362
<torbenh3>
bt seems to over uart.
<wens>
since AMPAK is a taiwanese company, i might as well give them a call lol
<torbenh3>
:D
<torbenh3>
at least you can read chinese -> huge advantage.
iamfrankenstein has joined #linux-sunxi
* torbenh3
clicked one link on that site. and was lost ;)
<slapin>
Turl: any phone-readable pinouts for cubie1 available (re vga)?
<slapin>
Turl: I mean N900-readable
<wens>
that was suprisingly easy to find...
<torbenh3>
wens: good work...
<wens>
torbenh3: google did the work lol
<wens>
wifi depends on working SDIO... hmm
<wens>
torbenh3: i wonder if there is any liability to using leaked documents though
<torbenh3>
what liability ?
<torbenh3>
as long as we dont leak the docs ourselves....
<wens>
torbenh3: i don't know
<binaryferret>
If I have a change to the script.bin file, I can just replace the old one and when I turn the device on it should use that new script.bin file?
<binaryferret>
I'm pretty positive that that's the point, but I just thought I'd double check.
<wens>
torbenh3: BT seems like the easy part. setup the UART, and everything would be handled by bluetooth stack
<wens>
I'd do it, but I don't have a ct to test it on yet
Taduro_ has joined #linux-sunxi
Quarx has quit [Read error: Connection reset by peer]
Quarx has joined #linux-sunxi
Taduro_ has quit [Read error: No route to host]
nove has quit [Quit: nove]
Taduro_ has joined #linux-sunxi
<atsampson>
oliv3r: I got 4.1 working but didn't get any further -- and I'm probably not going to, since having now used Android I've decided it's not really worth the effort ;-)
<atsampson>
but it'd make sense to pull my changes into the common project in case anyone else wants to pick it up
<torbenh3>
wens: doing it now.
<torbenh3>
wens: where is your current stmmac queue ? iirc its ready now ?
<torbenh3>
arokux: just go to a commit on the webinterface... and then there is a patch link
<arokux>
torbenh3: yes, found it, thanks
panda84kde has quit [Ping timeout: 248 seconds]
n01 has joined #linux-sunxi
* WarheadsSE
needs to revisit mali packaging for Arch
Taduro___ has joined #linux-sunxi
FR^2 has quit [Quit: Connection reset by peer]
Taduro has quit [Ping timeout: 272 seconds]
<torbenh3>
mmm... looks like that bt thingy wants some firmware.
<torbenh3>
does BT work somewhere ?
Quarx has joined #linux-sunxi
pfdm has joined #linux-sunxi
rellla3 has joined #linux-sunxi
Fusing has joined #linux-sunxi
AutoStatic has joined #linux-sunxi
Taduro___ has quit [Read error: Connection reset by peer]
Taduro_ has joined #linux-sunxi
rz2k has joined #linux-sunxi
<AutoStatic>
I'm trying to use a Cubieboard2 in a real-time, low latency setting but I'm getting inconsistent results from jack_iodelay. This is with the onboard codec. I'm a bit stumped as to where this jitter comes from. Maybe someone here has an idea?
n01 has quit [Ping timeout: 252 seconds]
hglm has joined #linux-sunxi
<hglm>
AutoStatic: Could be related to cpu scaling (cpu revving down to low speed such as 60 MHz). You could change the scaling governor to peroformance or increase the min speed.
<AutoStatic>
Hi hglm, CPU governor is already set to performance
<hglm>
AutoStatic: In that case the CPU speed should fixed on high so there must be a different cause...have you also changed the kernel scheduler (I think there exists a real-time setting)?
<AutoStatic>
I'm using a real-time kernel
<hglm>
Is the IO delay mostly small but seeing delays regularly, or just all over the place?
<AutoStatic>
mostly small but the delays seem to be irregular, both intervals and values
mouchon has quit [Read error: Operation timed out]
<hglm>
Probably something related to the kernel. I don´t have much experience with real-time though, did you see more consistent results on other platforms?
<mnemoc>
the allwinner kernel is full of mdelay() hacks
<AutoStatic>
That doesn't sound good. Have to say that I'm not a developer though.
<mnemoc>
mdelay() means busy-waiting for certain amount of ms just in the hope some condition gets solved with time
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
tomboy64 has quit [Remote host closed the connection]
<AutoStatic>
And mdelay() is unaffected by PREEMPT RT?
rellla3 has quit [Remote host closed the connection]
tomboy64 has joined #linux-sunxi
<mnemoc>
mdelay() will be interrupted by the scheduler eventually
<mnemoc>
but still delays things...
stekern has quit [Ping timeout: 240 seconds]
<hglm>
AutoStatic: I can imagine there´s some kind of buffer for audio data used by the kernel codec driver, and the IO delay depends on how full the buffer is...maybe related to the way the Allwinner codec driver is designed. Maybe it could be worth trying to avoid the codec driver and use another type of I/O such as USB...
<AutoStatic>
hglm: that's an option, especially given the information mnemoc just provided
<AutoStatic>
I've already adjusted the buffer defaults in sunxi-codec.c, the defaults were a bit weird an wouldn't allow me to go lower than 1024 frames at 4 periods
<AutoStatic>
I'm now running it at 64 frames, 2 periods
FR^2 has joined #linux-sunxi
<hglm>
AutoStatic: Does the device work with such a small buffer?
<AutoStatic>
Yes but you can't go much lower
<AutoStatic>
I've tried 16 and 32 frames but then audio gets distorted
<hglm>
I don´t really know what frames/periods really means, but have you tried fixing frames to 64 but increasing periods to a high number?
<AutoStatic>
No, not yet actually. I could give that a try
Taduro___ has joined #linux-sunxi
<hglm>
I am just imagining that the frames is related to buffer size (latency) and periods is the number of buffers...
<tomee^>
ok, now I see the wpa_supplicant.conf is gone from my current uSD config
<arokux2>
tomee^: this is what I did and it failed...
<tomee^>
so it must have been on the linaro-xbmc-whatever + my hacks
<tomee^>
I am not sure if I wiped that card already
<tomee^>
but yes, I can re-try for you
<tomee^>
i.e. re-flash the image and retry connecting
<tomee^>
but definitely not today
<arokux2>
tomee^: you do not need to reflash everything just put a correct kernel
<arokux2>
tomee^: of course
<arokux2>
tomee^: ok, good night
<tomee^>
what I recall for now is that FOR SURE scanning did work (meaning a direct probe, not passive IBSS receive)
<tomee^>
and for 90% it was usable (connect-able)
<tomee^>
ok, I'm off to bed
<tomee^>
remind me 2morrow if you wish
<tomee^>
you can google up my e-mail I guess
<tomee^>
[d]
<arokux2>
tomee^: bye (scanning worked for me too, but no connect)
tomee^ has quit [Quit: I Quit.]
<hglm>
arokux2: I noticed in the logs you were involved with the defunct fabless multimedia chip design company ESS? It´s funny because I used to follow it as an investor a long time ago.
<arokux2>
hglm: what?? :)
<arokux2>
hglm: I do not understand what are you talking about
<hglm>
arokux2: OK maybe I confused you with a different nick :)