<arokux>
tomee^: also, you may want to ask ppl on the mailing list. lots are working on the same problems they just keep sitting quietly, but when they see something on the ML they respond.
boycottg00gle has quit [Remote host closed the connection]
<mnemoc>
no clue
<mnemoc>
but in general we prefer unified drivers, sunxi-foo
<tomee^>
ok
<tomee^>
i will need to compare the cubieboard defconfing with your config parameters
<tomee^>
to see if some differ
<tomee^>
definitely not willing to go through menuconfig from scratch
<torbenh3>
mnemoc: upps. overlooked the include linux/types.h... yeah. that one should work
<tomee^>
ok, so the kernel tree is being checked out now
<arokux>
mnemoc: what is this? "\ No newline at end of file"
<tomee^>
meanwhile, any of you tried (wrote? :>) the vdpau driver?
<mnemoc>
arokux: windows editors forget to add a new line marker at the end of the file, and vi fixes that
<arokux>
tomee^: you should ask wingrime, ssvb rellla jemk etc.
<arokux>
mnemoc: I see, but is this text present in C code?!
<mnemoc>
no
<tomee^>
are they around here sometimes? or only on mailing list/git/whatever ?
<mnemoc>
`patch` deals with that
<jemk>
tomee^: im here
<arokux>
tomee^: yes, they are around... but you'd need to catch them.
<mnemoc>
tomee^: jemk is one of the care cedarx devs
<tomee^>
I see
<tomee^>
anyway, I got it working, but now I am wondering if there's any way to use overlays with it
<tomee^>
like subtitles
<binaryferret>
If building android should I be using a different kernel branch than sunxi-3.4 for the kernel? mirror/android-3.4?
<tomee^>
already implemented/planned or vlc->demux->vdpau->vram->memcpy->ram->overlays/compositing->memcpy->vram ...
<arokux>
( tomee^: you'd want to ping people so that they reply faster )
<jemk>
tomee^: overlays aren't possible yet, i had tried it, but it needs a lot of memcpy which kills performance
<Turl>
mnemoc: have you seen benn this week?
<jemk>
tomee^: or it needs some way to interact with the xorg driver (or ignore it and take the whole screen)
<mnemoc>
nope
<tomee^>
jemk: neither with "pure" libcedarx?
<arokux>
Turl: I had some e-mail communication with him
<mnemoc>
Turl: notmart
<mnemoc>
err
<mnemoc>
notmart: sorry
<jemk>
tomee^: i don't work on libcedarx, but it doesn't have overlays either
<tomee^>
jemk: i see. so what's rendered inside the program window/fb coords cannot be in any way changed.
<tomee^>
jemk: only possibility is to f*ck with memcpys which will bring the performance back to softdecoding or draw other stuff aside (e.g. subtitles below the video, given the video is not full-screen)
<tomee^>
jemk: did I get that right?
<Turl>
maybe you can use disp layers for that
<jemk>
tomee^: yes, thats one way, the other would be to figure out some inteligent way of using disp layers, but as only two layers can be blended and the video layer already is the second one...
<jemk>
for fullscreen it would be no problem at all, there video is back layer and subtitles front layer
<mnemoc>
torbenh3: did that patch work for you?
<jemk>
but in window mode desktop is back layer and video front and nothing left for overlay
enrico_ has joined #linux-sunxi
<torbenh3>
mnemoc: i have other things todo.... testing it in the evening.
<tomee^>
jemk: hmm, so in fullscreen 2 layers can be blended...
<jemk>
for fully visible windows same as fullscreen, but such things can only be decided by xorg driver
<tomee^>
jemk: you mean that 2 RGBA framebuffers are composited into one?
<mnemoc>
torbenh3: np :) please let me know to push it
<jemk>
tomee^: disp can blend two layers without copy, but only two
<tomee^>
ok
<tomee^>
so that would require 3 or 4 framebuffers?
<tomee^>
1 for widgets, 1 for video, another one for off-screen widget redraw = 3 ?
<tomee^>
and then swapping 3->1 then compositing 1+2 ?
naobsd has joined #linux-sunxi
<tomee^>
arokux: should your kernel work with the cubie bootloader? or your bootloader with the cubie kernel? or should I reinstall both at once?
<jemk>
tomee^: in vdpau those are all handled by VideoSurfaces and OutputSurfaces, so that's no problem, the only problem is to bring those surfaces to display without copying them around
ganbold_ has quit [Ping timeout: 244 seconds]
<tomee^>
but that's not yet implemented, right? :)
<jemk>
right, because it is nearly impossible to get fully compatible vdpau. it would be easy to write it for special needs like fullscreen, but not universal
<tomee^>
yeah, I know
<jemk>
well, not impossible if you allow copying, but that makes watching 1080p not very funny
<tomee^>
but vdpau is already somewhat more promising than cedarx... since VDPAU is at least SOMEWHAT of an abstraction layer
ganbold_ has joined #linux-sunxi
<jemk>
but it's an abstraction layer that has too many possible ways of doing things that can't be represented by the limited hardware in arm socs.
<tomee^>
yup
<tomee^>
I cannot argue with the fact that you are right and more your knowledge is more comprehensive that mine
<tomee^>
still, from my point of view, mplayer+vdpau/sunxi=no subtitles ;-)
<tomee^>
while, I think, the stagefright android binaries somehow do support subtitle rendering in hardware
<jemk>
possible, but android hasn't have to handle obscured windows. if the vdpau window is allways on top the same as for fullscreen works
<Turl>
you could composite all desktop and subtitles by software to a layer and have the video on the 2nd one
<JohnDoe71rus>
your kernel 3.4 only for Linux? suitable for android?
<jemk>
Turl: i talked with ssvb some months ago about possible tricks, but they all need much work and xorg driver interaction
<jemk>
like only copying the part of the video that is used for subtitles
<tomee^>
Turl: couldn't that be done with acceleration? the compositing I mean.
<tomee^>
I don't care about playback in a window as long as I can draw something on the video
<Turl>
I'm not much into the graphics stack, but I think there's two alpha layers that get blended by sw
<Turl>
if you can put the subtitles onto the desktop layer, then they could be overlayed over the video
<mnemoc>
JohnDoe71rus: for android you need a different defconfig. crane in the case of a10 for example
<mnemoc>
JohnDoe71rus: but the tree is androidized
<tomee^>
jemk: when I played with mxplayer, I managed to get 2 sets of subtitles (one s/w, one h/w I guess), plus the top menu bar visible... this is far from Xorg complexity, but shows that the hardware can cope with that
<JohnDoe71rus>
can i take defconfig from lichee 3.3 ?
<tomee^>
Turl: say, an mplayer playing transparent video file + subtitles overlaid on top of the proper vdpau-drawn video?
<Turl>
tomee^: I mean one layer with your desktop, mplayer window, a hole instead of video, and subtitles inside the hole
<Turl>
and a second layer with the video
<tomee^>
arokux: CC [M] drivers/net/wireless/bcmdhd/dhd_linux.o drivers/net/wireless/bcmdhd/dhd_linux.c: In function ‘dhd_os_prealloc’: drivers/net/wireless/bcmdhd/dhd_linux.c:5192:2: error: implicit declaration of function ‘wl_android_prealloc’ [-Werror=implicit-function-declaration]
<tomee^>
arokux: I guess you should ifdef the DHD_OS_PREALLOC option for non-android builds... or I did something wrong
<jemk>
Turl: possible, but not nice, especially as vdpau redraws all layers each frame, so the subtitles get redrawn too
<mnemoc>
http://sprunge.us/ESHh .... wee... and I broke every driver now because of node duplication :p
<arokux>
tomee^: cubietech guys just grab our u-boot i think.
<arokux>
tomee^: i do not know what they have preinstalled
<mnemoc>
i would bet they just use allwinner's SDK like olimex
<arokux>
tomee^: but if using an uSD card you need to flash the bootloader anyways
<arokux>
tomee^: so grab ours, it has support for CT, however it won't see 2GiB of RAM, there is patch for that.
<arokux>
tomee^: oliv3r said if you are lucky the kernel will still see 2GiB of RAM
<mnemoc>
mine doesn't...
<arokux>
tomee^: where is that error msg comming from?
<arokux>
oliv3r: how to be lucky so that the kernel sees 2GiB on CT?
<tomee^>
arokux: 432MHz. that's the speed at which my board runs with sunxi bootloader, too. but look here:http://dl.cubieboard.org/software/a20-cubietruck/common/ct-v101_sys_config.fex
<tomee^>
arokux: I simply do not know why 432MHz if the hardware can do 480... they downclocked it for security purposes in the first batch?
<arokux>
tomee^: sorry, I have no idea.
<tomee^>
arokux: I've heard somewhere that someone complained about overheating of the prototype
<arokux>
tomee^: Turl may know.
<Turl>
dunno, we should ask benn
<tomee^>
arokux: and about the error you asked me about
<tomee^>
arokux: it comes from the bcmdhd driver compilation
<tomee^>
arokux: when I disabled buffer preallocation for it, it went through
derethor_ has quit [Read error: No route to host]
<arokux>
tomee^: but first you enabled that driver (bcmdhd), right?
<arokux>
tomee^: ok, thanks for the input. if you find out if the blootooth works, i'd be awesome!
<tomee^>
arokux: CONFIG_DHD_USE_STATIC_BUF=y broke the compilation. CONFIG_DHD_USE_STATIC_BUF=n made it work. maybe this flag should depend on android or some other build environment
<arokux>
Turl: correct it, add some more questions if any. or just tell it is fine.
<Turl>
arokux: you quoted my opinion on the subject, "<Turl> dunno, we should ask benn" :p
<arokux>
Turl: ok, so I mail Benn now.
<mnemoc>
[[Ask Benn]]
rz2k has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
<arokux>
mnemoc: we should document more and more. please try to push that line.
wolfy has left #linux-sunxi ["Paradoxul homosexualilor este ca, desi nu reusesc sa se reproduca, sunt in fiecare an din ce in ce mai multi. (Tristan Bernard)"]
<mnemoc>
we can add a bunch of those pages... [[Ask Eva]], [[Ask ...]], ...
<arokux>
mnemoc: I do not mean info about asking docs only. any info on sunxi. we must have it somewhere not just buried in IRC logs.
<arokux>
mnemoc: first ugly dumps will do, hopefully somebody will improve them.
<juanfont_>
tomee^, jemk these overlay problems also affect xbmc when running standalone?
<jemk>
juanfont_: think so, but i didn't look too deep into xbmc
<tomee^>
arokux: colorize nick names.
Black_Horseman has joined #linux-sunxi
<arokux>
tomee^: I'd like those dumps to be rewritten as doc, so making dumps nicer isn't priority.
<tomee^>
i see
<tomee^>
i just find it much easier to read colorized logs than plain-text
<tomee^>
i never know who is who without colors ;)
<arokux>
tomee^: sure. please improve it.
<tomee^>
I don't have admin rights on the wiki.
<tomee^>
and it was just a wild suggestion. sorry.
<Turl>
mnemoc: maybe we can add a wiki prefix for those (like Talk:)
juanfont_ is now known as juanfont
<mnemoc>
go ahead :)
<mnemoc>
this is fully community driven
<tomee^>
arokux: so far the kernel didn't boot (but the sd card was a mess). I saw penguins, then nothing. will try with another one.
<Turl>
I need to leave now :p but I'll do so when I come back if nobody opposes by then
<arokux>
tomee^: but it booted before...?
AreaScout has joined #linux-sunxi
<tomee^>
yes
<tomee^>
wait a sec
Black_Horseman has quit [Quit: Αποχώρησε]
<arokux>
( tomee^: I think you should definitely use serial connection to see early boot log )
<ssvb>
tomee^: 480mhz memory clock speed is too fast for cubieboard2
<ssvb>
tomee^: it needs to be reduced, or we will keep getting reports about occasional stability issues from some users
<tomee^>
ssvb: and cubietruck too?
<tomee^>
ssvb: even though the spec says its ok?
<oliv3r>
the spec lies!
<ssvb>
tomee^: the spec says 400mhz for dram
<tomee^>
arokux: this would require either dragging my amplituner and tv to my workstation, or dragging my workstation there, or wiring up an arduino in between, or whatever. not that simple ;)
<ssvb>
tomee^: but the spec also says 1.2ghz for the cpu, which is overly optimistic :)
<tomee^>
ssvb: ok, maybe I misread. or the spec was wrong.
<tomee^>
ssvb: yeah. what's the safe speed? 1008? 912 ?
<tomee^>
given I have a radiator and and airflow
<ssvb>
tomee^: what's more important is that some real users are having real problems at 480mhz dram clock
<tomee^>
as you see by the compilation date in dmesg
<tomee^>
it must have been pulled out of their prebuilt linux image
<tomee^>
so... don't know
nove has joined #linux-sunxi
<arokux>
tomee^: can you post their config?
mkutsevol has left #linux-sunxi [#linux-sunxi]
mkutsevol has joined #linux-sunxi
<tomee^>
ha, something's strange. when I explicitly specified the same fw file the module won't load. but on the other hand, maybe it just won't load twice (ie. the hardware can not be re-initialized)
<gzamboni>
did anyone already manage to make spidev work ?
<tomee^>
yet it works WITHOUT specying those parameters on cmdline
<arokux>
juanfont: please paste your conversation on overlays to hat Misc_Docs pages, thanks.
<arokux>
tomee^: their kernel is not perfect, they hacked on it till it work then just shipped. that is why you'd like to use ours, our priorities are different.
<tomee^>
root@cubietruck:/sys/module# for file in /lib/firmware/ap6210/fw_bcmxxxx.bin /lib/firmware/ap6210/nvram_apxxxx.txt; do test -f $file && echo "$file exists" || echo "no $file"; done
<tomee^>
arokux: yeah, I can see all around that there are hacks and poor documentation on the cubietech side
<gzamboni>
i have the /dev/spidev0.0 but when i try to test it using the compiled spidev_test.c example i just get: can't send spi message: Invalid argument Aborted
<tomee^>
arokux: and I would prefer your kernel too ;-)
<arokux>
tomee^: first we just need to go to their kernel and cherry pick stuff. it shouldn't be hard. then we fix it - takes more time.
<tomee^>
yes...
<tomee^>
i spent dozens of hours on the board already
<tomee^>
it's not that their stuff even works properly ;/
<arokux>
tomee^: hw is nice though :)
<arokux>
tomee^: what was your original goal, btw?
<tomee^>
and while a10 and a20-cubieboard2 are not "top sellers", 90 bucks for a cubietruck is really a competitive price
<tomee^>
for a board with dual-core GPU, dual-core CPU, 2GB RAM, 8GB NAND, SD, BT, WiFi, SATA, GPIO...
<tomee^>
gigabit ethernet, two tv-out ports and most importantly to me, TOSLINK
<tomee^>
arokux: xbmc. not there yet but I see light at the end of the tunnel.
<Montjoie>
hello, I have perhaps hit a bug in sunxi-3.4, does someone with CRYPTO_USER_API want to test my poc http://pastebin.com/33MKW7R9?
<hramrach>
there are problems @ 480MHz even on A10, more on a20. So they downclocked for the new board and pray that they get fewer issues I guess
hipboi has joined #linux-sunxi
<arokux>
Montjoie: This paste has been removed!
<hramrach>
but there is no extensive stability testing with *any* clock speed I suspect. They make a handful of prototypes, test them, do test batch, and we are currently testing that :p
<tomee^>
hramrach: yeah. and how do the ram problems manifest themselves? so far I've only had trouble with make -j2 once - the gmac stopped responding, but upon reloading it was OK
<hramrach>
and they don;t ahve the budget to make a batch of thousands boards (or at least hundreds) and extensively test all of them
<hramrach>
tomee^: I have no idea. I don;t have problems. You can try searching the ML for some problems that were blamed on ram
<arokux>
Montjoie: please specify which boards/kernels should I use.
<hramrach>
but there are reportedly 'stability issues'
<Montjoie>
ok arokux
<tomee^>
hramrach: maybe I will face them too... since its the 1st batch...
<hramrach>
tomee^: sometimes problems with -j2 are also makefile problems
<hramrach>
and they are not reliably reproducible either
<hramrach>
if it's it never happens with -j1 don't blame ram
<tomee^>
hramrach: so far, I know for sure that it ran ok for 24hr+ seeding torrents (legal stuff of course), and a couple of hours playing video
<tomee^>
hramrach: I suspect the driver is flawed and simply shut down on race conditions
<hramrach>
you can try multiple -j1 builds in parallel for testing. Or run a cedar using video player while building for extra memory stress testing
FDCX has quit [Remote host closed the connection]
<tomee^>
hramrach: and with make -j2 + ethernet + ddrt + wifi2.4 + openwrt + wifi5ghz + ssh session there is a big chance of retransmissions
<hramrach>
also if gmac shuts down it might just be bug in the driver
FDCX has joined #linux-sunxi
<ssvb>
tomee^: gcc compilation of itself, 7-zip (p7zip) benchmark and memtester can be used to spot obvious memory stability problems
<hramrach>
I like booted the board and sshd in but that's pretty much everything I did
<Montjoie>
arokux, I do not have the rights to edit this page
<hramrach>
Montjoie: everyone does
<hramrach>
just register and don't post links
<Montjoie>
I have just registred
<ssvb>
tomee^: also the simultaneous use of mali has been observed to make it break at a lower dram clock frequency than with just cpu alone
<hramrach>
arokux: on arm you need higmem for 1G
<tomee^>
ssvb: yeah, a lot of memset & memcpy in video
<hramrach>
was it dropped from sun4i?
<tomee^>
ssvb: zeroing a large parge of nonbuffered ram could even lead to capacitor/voltage regulator problems
<tomee^>
ssvb: this is stuff you face even in "enterprise" servers if you use desktop memory chips
<hramrach>
Montjoie: ok, that page has links already so to edit it you might need to ask mnemoc to make an exception for you
<hramrach>
because the spam filter pretty much flags every link as spam
<hramrach>
tomee^: that's why there are server memry sticks with less power draw :p
<tomee^>
hramrach: ... and buffering and ECC-R.
<ssvb>
tomee^: the dram chips themselves are rated as DDR3-1333, the problematic part is likely inside of the A20 SoC
<tomee^>
ssvb: why can't it be related to the voltage/power circuitry?
<tomee^>
ssvb: I mean, the same stuff works in thousands of samsung smartphones, right?
<tomee^>
ssvb: but they probably spent some time designing the power supply
<ssvb>
tomee^: which same stuff?
<tomee^>
Mali GPU ?
<hramrach>
even if it's power circuitry it's the way it is on the board
<oliv3r>
arokux: re: your mail to benn; is there still confusion or has it been resolved/
<hramrach>
but the amount of ram on the board is ridiculously small and so is the frequency
<arokux>
oliv3r: ppl are saying the correct freq it determined experimentally.....
<ssvb>
tomee^: how is mali related other than providing additional stress on the memory controller and maybe having some problematic memory access pattern which triggers the issue more easily?
<tomee^>
hramrach: if you "forget" a capacitor somewhere... or better yet, power the device from a impulse 0,5A "universal usb charger" for $5...
<oliv3r>
arokux: yeah, the chip is somewhat buggy sometimes, depends on the quality of your chip, so the 'safest' freq. is 380 :p i think standard is 432, but some can clock upto 480. I think tom even had samples that would run at 520 MHz but I don't think it was fully stable :)
<ssvb>
tomee^: btw, cubieboard and cubieboard2 are using identical PCBs, but cubieboard2 has more problems with dram overclocking
<tomee^>
ssvb: I admit, it might be not. I just don't know if it's allwinner's flaw really... or the PCB
<arokux>
oliv3r: please reply like this to my request to benn, then we make a wiki page out of the ML thread
Soru___ has quit [Read error: Connection reset by peer]
<tomee^>
ssvb: identical PCBs but the hardware on it is different
<ssvb>
oliv3r: I kinda successfully overclocked dram in my cubieborad2 to 552MHz, but this was only possible with 552MHz mbus :)
<tomee^>
so this would suggest a problem with the PCB
<ssvb>
tomee^: which part is different other than SoC?
Soru has joined #linux-sunxi
<ssvb>
oliv3r, Turl: higher mbus frequency seems to mean better stability for dram when running at the higher clock speed, at least that's what I have observed with my board
<tomee^>
ssvb: I didn't analyze thoroughly
<tomee^>
ssvb: but cb1 came with 0,5GB ram at first I think
<tomee^>
ssvb: plus the A20 SoC comes with "dual-core" Mali
<tomee^>
which would mean "need more juice at peak"
<tomee^>
of course I may be mistaken
<tomee^>
but I have played around with AVR chips, I²C buses and the like
<arokux>
tomee^: boards require voltage in the 6 to 16V
<tomee^>
arokux: yeah
<tomee^>
arokux: because they have a decent voltage regulator with some BIG FAT DIODES
<arokux>
Montjoie: ok. will sun4i also do? sun7i - I'll test on cubietruck.
<tomee^>
arokux: "olinuxino" and header layout suggests electronics - and those boards are usually designed that way
<tomee^>
arokux: (olinuxino sounds like arduino, which also can be fed with 5 do 30V)
<Montjoie>
arokux, I have only a cubieboard2, no other board
Soru_ has quit [Read error: Connection reset by peer]
<ssvb>
tomee^: I don't have olimex sunxi boards myself, but any conclusions pointing to the A20 chip being the culprit should apply to cubieboard2/cubietruck too
<arokux>
Montjoie: do you want me to test sun4i or you know it won't work?
<Montjoie>
you can test
<tomee^>
ssvb: yes.
<arokux>
Montjoie: ok!
<Montjoie>
I want to be sure that it is not myself the problem:)
<Montjoie>
this bug is blocking all my progress on the security system
Soru___ has joined #linux-sunxi
<tomee^>
ssvb: I just think it may be ONLY cubieboard design flaw. or a little error, say, the spec from allwinner said "+/- 10%" whereas it runs only on "+/- 5%", cubie implemented it as written in the spec (or even "oh, let's make it 15%") and hence the trouble
<arokux>
Montjoie: I want to see it working, that is why i help!
<Montjoie>
On x86_64 3.10.17 the bug is not here
Soru__ has quit [Ping timeout: 244 seconds]
<tomee^>
ssvb: also, just count the capacitors and diodes surrounding ICs on the olinuxino, and compare that to the cubie PCB... and then look at the monstrous electrolytic capacitor that olinuxino has...
<tomee^>
ssvb: if I have time, I will try overclocking with a) a phone charger b) a decent phone charger (LTE router charger) c) a professional transformer-based stabilized 5V PSU
Soru__ has joined #linux-sunxi
<Dapsaille>
phone chargers are generally crappy
<Dapsaille>
imho
Soru___ has quit [Ping timeout: 240 seconds]
<tomee^>
Dapsaille: frankly speaking, everything that weighs less than 0,5kg and costs less than $30 can't be considered a dependable power supply
<Dapsaille>
:)
<tomee^>
and people often don't realize that
<tomee^>
for example, plug a Xenon HID to a non-stabilized PSU and see what happens
<tomee^>
and they don't sell stabilized PSUs, because they are big and costly
<Dapsaille>
i've just replaced one of them in a diy thermal/humidity controller .. he just burned ....
<tomee^>
yeah
<mnemoc>
arokux: I broke all drivers here, so my dmesg does look nice :p
<tomee^>
drawing too much current from a cheap impulse PSU can cause anything from voltage drops to the PSU becoming a pass-through of AC voltage ;)
<binaryferret>
Anyone had any luck getting ektf2k touch screen driver to work with sunxi kernel? It keeps throwing a wobbler about 'Unknown symbol register_early_suspend' which I've read was taken out in an earlier linux kernel version.
<binaryferret>
I grabbed the driver from another source tho as I've been trying a few things. Just wondering if anyone can help.
<Dapsaille>
for christmas i hope to have a lab regulated power supply of 0 - 30 V DC / 0 - 5 A 150 W
<Dapsaille>
instead of having 243636631234 chargers lying around :)
<arokux>
tomee^: so tell exactly how do you boot our kernel with cubie-u-boot, do you hit a key in u-boot and get theirs prompt?
Soru_ has quit [Read error: Connection reset by peer]
Soru____ has joined #linux-sunxi
Soru__ has quit [Ping timeout: 240 seconds]
<tomee^>
arokux: no. there is an ext2 partition that holds uImage, uEnv.txt and script.bin
<tomee^>
arokux: this particular partition also has a boot.scr and other stuff (came from a cubieboard2 image)
<arokux>
tomee^: so you overwritten that stuff?
<speakman>
Any idea which is the lower voltage limit of a "high" signal on GPIO input pins?
<tomee^>
arokux: I overwrote the bootloader (8-2048s)
Soru_ has joined #linux-sunxi
<tomee^>
arokux: and I replaced uEnv, uImage and script.bin -> this way it booted with the cubie kernel. I didn't care about the rest of crap on the partition (hdmi_drv etc)
<tomee^>
arokux: by putting your uImage on that partition, your kernel also booted
<rz2k>
[19:04:21] <speakman> Any idea which is the lower voltage limit of a "high" signal on GPIO input pins? - VDD_IO of the board
<rz2k>
lower limit is around 0.3 or something
<speakman>
rz2k: Hm. So that's the lower limit? I'm on a OLinuXino A20
Soru____ has quit [Ping timeout: 252 seconds]
<speakman>
I've got 2v2 right now and it's interpreting is properly. I just wonder how close to the limit I really am.
<nove>
disappointing, the h264 encoder only get to encode 1920x1080 at around 20fps
<arokux>
nove: whos limitation is this?
apo_ has joined #linux-sunxi
<tomee^>
disappointing?
<tomee^>
on a core i7 I *encode* 1,5Mbit/s 700x400 xvid streams at ~100fps
<nove>
arokux, no idea, maybe memory pressure, 1280x720 get 46fps
apo has quit [Ping timeout: 248 seconds]
<nove>
this if i get the memory clock correct at 320Mhz, A13
<arokux>
nove: what software is used for encoding, some blobs or community oss?
<nove>
tomee^, it should be able to decode and encode at fullHD in real time, that is what hardware is for
<arokux>
nove: so 20fps is done by open source software developed by community?
<tomee^>
"up to full-hd performance at up to 25fps in up to real-time *" * - depending on software, hardware configuration and current planet constellation
soul is now known as Guest74573
Guest74573 has quit [Read error: Connection reset by peer]
<arokux>
nove: "nove> tomee^, it should be able to decode and encode at fullHD in real time, that is what hardware is for"
<arokux>
nove: how do you know what is the hw for?
<oliv3r>
arokux: i don't know why it won't for mnemoc it works for everybody else :)
Soru_ has joined #linux-sunxi
Soru___ has quit [Ping timeout: 248 seconds]
<arokux>
oliv3r: defined everybody else?
<tomee^>
arokux: funny, I thought hardware was only for running software. else can be used as a paperweight or a stool or coffee table.
<oliv3r>
arokux: tomee^ mee, probably you :)
dalee has joined #linux-sunxi
<arokux>
oliv3r: tomee^ uses u-boot from cubiethech! me has 1GiB as well as mnemoc! :)
<arokux>
oliv3r: so... give us 2GiB in sunxi-3.4 please! :)
<nove>
arokux, the hardware is for what we want, if the hw doesn't do what we want is not good hardware
<oliv3r>
are you using my u-boot?
<tomee^>
nove: agreed.
<dalee>
have some1 problems with UVC capture from WebCam? I did compile kernel with UVC and preview working but capture gets green image on saving
<tomee^>
but then comes the definiton of full hd. blu ray is full hd, but uses an MPEG1/2 codec which your kitchen oven could deal with.
<tomee^>
then there's h264 which is really, really sophisticated and makes that 30GB of movie fit into 3GB...
<arokux>
oliv3r: no. i'm using sunxi-u-boot, but you said it should be fine too and that kernel is smart enough to figure out the memory size by itself. is it not true?
Soru__ has joined #linux-sunxi
<oliv3r>
it doesn't figure anything out, but the overflown int cast back to an int makes it so that it shouldn't be an issue
<oliv3r>
the kernel NEEDS u-boot to tell it its correct size; for that to work, the .size and .density parameters need to be correct
Soru_ has quit [Ping timeout: 272 seconds]
rellla3 has joined #linux-sunxi
rellla3 has quit [Client Quit]
Soru_ has joined #linux-sunxi
<WarheadsSE>
arokux: and others. Status of CB2 integration to linux-sunxi from the prior 3.3 pile of $%^&
<arokux>
oliv3r: so sunxi-3.4 doesn't have a chance to see 2GiB with current u-boot. YES/NO?
<arokux>
WarheadsSE: what? :)
<WarheadsSE>
how is the CB2 (linux sun7i) for the 3.4 tree?
Soru__ has quit [Ping timeout: 272 seconds]
<arokux>
WarheadsSE: no idea, I just recently got truck.
<WarheadsSE>
yeah, i know :P
<WarheadsSE>
Whats the SoC on that again?
<arokux>
A20
<arokux>
sun7i
<arokux>
same as on CB2
<arokux>
WarheadsSE: just tell here what isn't working and it will get fixed (soon)
<WarheadsSE>
K
<tomee^>
hmm
<WarheadsSE>
Well, we're still packaging the 3.3 CB2 kernel
<WarheadsSE>
we'd like to move to the proper linux-sunxi/sun7i 3.4+
<tomee^>
arokux: so you say that cubie has a repo of the bootloader, but the crucial part comes from allwinner and is closed-source?
hno has quit [Excess Flood]
wingrime has joined #linux-sunxi
hno has joined #linux-sunxi
jemk has joined #linux-sunxi
Soru__ has joined #linux-sunxi
<arokux>
WarheadsSE: so you want somebody to submit you an updated .config?
Soru_ has quit [Ping timeout: 245 seconds]
atiti has quit [Ping timeout: 245 seconds]
<arokux>
tomee^: I never said that. I have no idea what bootloader they use, mnemoc had some ideas.
<WarheadsSE>
the whole tree needs moved from 3.3 to 3.4
<WarheadsSE>
I'd rather know it was sound to move, and everything was functioning
<tomee^>
arokux: definitely uboot ;) but /me no idea as well.
shineworld has joined #linux-sunxi
notmart has quit [Read error: Operation timed out]
<arokux>
WarheadsSE: I see. it is hard to tell everything works I think. is it an option to do something like -testing and push it to your users so we know how good it is?
<WarheadsSE>
well, then I would not push it to my users.. I would make it individually available
<pfdm>
arokux: I've seen your todo list, I have a pkgbuild for arch kernel 3.4.61 with cedar patches, if you want to update the official repo.
<hramrach>
the gnome performance is not a showstopper. You can use less demanding desktop and wiht Lima doing proper buffer management you can get doublebuffering and probably better performance
<hramrach>
but there is no known way to decode video on an a10/a20
<hramrach>
10bit media is common and cedar either cannot decode that or it is not known how to feed it such media
<pfdm>
arokux: there's a misunderstanding , I think pat's branch pathces are merged to sunxi3.4. But I was using it from mid october , so i have a pkgbuild for it. Now the patches have been merged into sunxi3.4 so it's ok.
tzafrir has joined #linux-sunxi
<hramrach>
arokux: also on a10 the low memory bandwidth that prevents 1080p scanout might be showstopper for some. I don't use that large resolution so I don't mind that much
<arokux>
pfdm: are you sure they are merged already? just want to be sure.
<arokux>
hramrach: is it better with A20?
<pfdm>
arokux: No I don't have a repo, but it's nothing special. Let me verify. What is not merged yet, is montjoie patch for axp209 temperature sensors.
<hramrach>
unknown. there is possibility to tune mbus which seems to yield better memcpy performance but how it affects scanout and what speeds are still stable is untested
<hramrach>
and since I don't have a 1080p screen I won't test this I guess
<arokux>
hramrach: i see.
<hramrach>
it can output 1080i without issue. with 1080p you may have issues when the system is not idle. might be better with 50Hz over 60Hz ans 16bpp over 32bpp. ymmv
<Dapsaille>
ty
<arokux>
pfdm: montjoie patch isn't a bug fix, so it is not that critical.
Soru__ has joined #linux-sunxi
<pfdm>
arokux: ok. From what i see in the log, all the cedar patches have been merged. So looks ok from me.
<Dapsaille>
do you know if the A20 had a real VGA output signals ?
<hramrach>
Dapsaille: as on a10 VGA is wired to TVout
<arokux>
pfdm: perfect. how can I contact you so that you can test the up-to-date kernel package?
<jemk>
torbenh3, arokux: any progress with gmac at u-boot? i don't get it to send anything...
<arokux>
pfdm: as I understand you own cb2?
<arokux>
jemk: what u-boot are you using?
<Dapsaille>
does it mean that we can get vga signals from tvout ? i don't understand :x
<hramrach>
Dapsaille: if you configure the registers correctly you should have VGA signal
Soru has quit [Ping timeout: 272 seconds]
<Dapsaille>
ok, i'm trying to get a 15.6khz signal from a13 vga out but no luck .. black screen
<jemk>
arokux: linux-sunxi/u-boot-sunxi with designware at the moment, but sun6i_gmac was the same
tomboy64 has quit [Quit: Uhh ... gotta go.]
<pfdm>
arokux: yes I'm on cb2.
<Dapsaille>
so i wonder if it will be easy with an A10 or A20
<Dapsaille>
easier . sorry
tomboy64 has joined #linux-sunxi
<jemk>
arokux: mii info works on both, phy receives all ok and even sends to mac, but mac doesn't talk to phy
<arokux>
jemk: I am hacking around sun6i_gmac, no success so far, I was able to see something.. but its not working yet.
<hramrach>
I have no idea about a13 or VGA. never got it working. presumably the parts that are bot on a10 and a13 are mostly the same
<arokux>
jemk: oh.. you know more then me then. do you have your code handy at github?
<hramrach>
note that at least on HDMI not every clock frequency is supported and if your screen is picky it won't sync
<Dapsaille>
hramrach => i use olimex a13 board with onboard hack lcd> vga .. but i'm affraid that this hack is only for standard vga signals (34khz) .. so 15.6 don't work ...
ZetaNeta has quit [Ping timeout: 252 seconds]
<Dapsaille>
and i cannot get help from olimex chan :x
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
<hramrach>
Dapsaille: try the mainlinglist. also try normal VGA screen and modes first if you did not
<arokux>
jemk: yesterday I've added this and it got better, but still not working.
rz2k has joined #linux-sunxi
<jemk>
arokux: i verified that tx/rx clock is running correctly by measurement today, so clocks are okay
Soru__ has quit [Read error: Operation timed out]
<arokux>
jemk: how can you measure this?
<jemk>
arokux: also received data is send between phy and gmac, but gmac doesn't react on it
Soru__ has joined #linux-sunxi
<jemk>
arokux: the clocks are at R129 and R132, so i probed there and had a nice 25MHz clock signal as expected for 100Mbps
<pfdm>
arokux: for the cedarx , I am trying to make it work with gles output without copy. I haven't had much time lately, but it's possible to use a texture from UMP memory, has to see the perf now.
Soru____ has joined #linux-sunxi
<arokux>
jemk: I need to take a look at home if you got this right: #define GMAC_AHB_BIT0x00020000
Gerwin_J has quit [Quit: Gerwin_J]
<jemk>
arokux: it is right, otherwise the gmac regs wouldn't even be accessible
Soru__ has quit [Ping timeout: 244 seconds]
<arokux>
jemk: u're right. 17th bit, I have the same.
Soru____ has quit [Read error: Connection reset by peer]
<arokux>
pfdm: I see, sorry I know very little about cedar&gpu
<arokux>
jemk: luckily there is stage/sunxi-3.4 where GMAC works.
Soru_ has joined #linux-sunxi
<arokux>
jemk: will gmac send something to phy?
<jemk>
arokux: no, only phy to gmac, but the tx clock is generated properly by gmac
ZetaNeta has joined #linux-sunxi
<jemk>
arokux: so i believe there is some problem doing dma right
<arokux>
jemk: ok, I cannot tell you something new. you know much more than me, sorry.
Gerwin_J has joined #linux-sunxi
* tomee^
been afk
<jemk>
arokux: i only verified the electrical signals, i don't know more about the software side
<arokux>
mnemoc: sorry, that is everything I've seen :p
<arokux>
mnemoc: look for sensors
popolon has quit [Quit: Quitte]
pfdm has quit [Ping timeout: 250 seconds]
Soru__ has joined #linux-sunxi
Soru_ has quit [Ping timeout: 245 seconds]
wolfy has joined #linux-sunxi
Soru_ has joined #linux-sunxi
arokux2 has joined #linux-sunxi
Soru__ has quit [Ping timeout: 248 seconds]
<arokux2>
mnemoc: have you found it?
eebrah has joined #linux-sunxi
Soru_ has quit [Ping timeout: 245 seconds]
<oliv3r>
arokux2: I don't remember. But since i have a patch, I didn't look into it really, there's a current working u-boot patch that works ;)
Soru_ has joined #linux-sunxi
<arokux2>
oliv3r: but it is not yet in sunxi-u-boot, so I've thought kernel can solve this problem, but it seems not to be the case.
<arokux2>
oliv3r: if you are satisfied with you patch, can you push it to our u-boot-sunxi, please?
<arokux2>
oliv3r: if testing is needed let me know.
Soru_ has quit [Read error: Connection reset by peer]
_massi_ has quit [Quit: Leaving]
Soru has joined #linux-sunxi
<arokux2>
wingrime: how much of blob was RE already?
<oliv3r>
arokux2: no, kernel can't solve it without a working u-boot
<arokux2>
oliv3r: ok (you were saying the opposite that is why I was hoping...)
<oliv3r>
arokux2: i am satisfied and I think it works, if you are using it and concider it stable, i'd love to; but it's quite an invasive patch to u-boot core, that goes beyond sunxi-u-boot and requires atleast hno's blessing
<arokux2>
oliv3r: you are even scared to push it to u-boot-sunxi?
<oliv3r>
nah; :p
<oliv3r>
if hno would say 'ok lets push it and see what happens' i'd be happy to do that too
<oliv3r>
I was hoping, months ago when starting it, that the patch would have landed upstream allready, and we could have only pushed our board specific patches
enrico_ has quit [Quit: Bye]
<arokux2>
oliv3r: you should resubmit now as plain text
<oliv3r>
arokux2: yeah as git send-email :)
<oliv3r>
i will do that right now
<arokux2>
oliv3r: I wonder, no ARM board had 2GiB before?!
<oliv3r>
yeah u-boot claims 'it works fine'
<oliv3r>
but i think it's because the overflow issue at 2 GiB isn't really big, and some cast magic actually fixes it below the line; it's still a bug
Soru has quit [Ping timeout: 248 seconds]
<arokux2>
oliv3r: u-boot as u-boot maintainers?
<oliv3r>
but you saw the mails; they where arguing about random shit without even looking at the stuff
<oliv3r>
u-boot maintainers say 'we have other boards, it works fine'
<oliv3r>
but i think if you skip the memory detection check, you don't hit the bug
<arokux2>
oliv3r: yes, hopefully they will be more focused if they see code.
<oliv3r>
which is what they are arguing about
Soru_ has joined #linux-sunxi
<oliv3r>
and now for the secret to be revealed, mailing list time
<arokux2>
oliv3r: +1
<arokux2>
oliv3r: have you tried to skip that detection on CT?
hipboi has quit [Quit: Leaving]
<oliv3r>
memory detection should be used; and butchering u-boot over it will be a lot of useless work
<oliv3r>
btw, i can confirm current u-boot will not ever work with more then 1 GiB right now, as it's limited to not ever check more then 1 GiB :)
Soru_ has quit [Ping timeout: 272 seconds]
Soru has joined #linux-sunxi
<arokux2>
oliv3r: good argument for you cover letter.
<arokux2>
oliv3r: oh, could you improve that sunxi limitation only? ppl are really pissed off if we tell them kernel sees only 1GiB, even if the second GiB is not really used.
<oliv3r>
i'll prepare my patches, resend them to u-boot ML and then push it ot ours
<oliv3r>
we can always remove the patch(es)
Soru_ has quit [Read error: Connection reset by peer]
Soru has quit [Ping timeout: 272 seconds]
Soru has joined #linux-sunxi
<torbenh3>
jemk: ping
<torbenh3>
jemk: you said you were having troubles with gmac transmitting stuff in u-boot ?
<jemk>
torbenh3: yes, did you get it work?
<torbenh3>
jemk: i am seeing the same thing in mainline, i think
<torbenh3>
jemk: i see packets being reveived fine.
<jemk>
torbenh3: with the driver from cubieboard ported to mainline?
<torbenh3>
jemk: yes.
<torbenh3>
jemk: but transmission of packets doesnt work.
<torbenh3>
looks ok, from the dma pov.
<jemk>
you really receive them in software, or only the led blinks?
<torbenh3>
driver debug features, print out the contents of rx packets.
<torbenh3>
i see them.
<jemk>
ok, thats better then u-boot, there i don't see anything at the software side
<torbenh3>
hmm... ok. then we are seeing seomthing different i guess.
Soru_ has joined #linux-sunxi
<jemk>
torbenh3: do you correctly set up the gmac module clock (0x01c20164 = 0x00000006), as this is responsible for the transmit clock, but NOT for the rx clock
Soru has quit [Ping timeout: 245 seconds]
Soru_ has quit [Read error: Connection reset by peer]
Soru has joined #linux-sunxi
<arokux2>
jemk: this driver is working in sunxi-3.4, it should be correct then?
<arokux2>
techn_: ping
wolfy has quit [Ping timeout: 252 seconds]
<techn_>
arokux2: pong
<jemk>
arokux2: it should, but it doesn't work so something must be different
<jemk>
afk, bbl
<arokux2>
techn_: you've just replied to the e-mail, that guy had another patch. I'm asking myself it resolve hackberry issue too.
<hno>
<hno> If it looks sane and works for two people then I am happy.
<hno>
<hno> oliv3r^
<hno>
<hno> but changes to u-boot core should really be sent to u-boot mailinglist for discussion.
* hno
really should get a vpn of some sort to his IRC bouncer to avoid disconnects.
<oliv3r>
hno: ok, rgr
<techn_>
arokux2: might solve.. I was thinking if it need to be fex file variated
<oliv3r>
hno: i did send the patch and even discussed it, but they kinda ignored the content of the patch, had some small talk; and then just gave up
<oliv3r>
hno: so would have been happy if you would have weighted in on u-boot ML; i'll resend the patch again though.
<oliv3r>
hno: p.s. HansG did review and test it
soul has joined #linux-sunxi
soul is now known as Guest87208
Soru has quit [Ping timeout: 245 seconds]
Guest87208 has quit [Read error: Connection reset by peer]
<oliv3r>
arokux2: can you build and test a u-boot if I give you a repo now?
Soru has joined #linux-sunxi
<arokux2>
oliv3r: yes
Gerwin_J has quit [Quit: Gerwin_J]
<oliv3r>
arokux2: ok cool let me fix this compile error and then i push --force it to my repo; if you test it also (i will too) i will push it to sunxi :)
<arokux2>
oliv3r: I'll test it right away.
<oliv3r>
ok i'm getting mmc compile errors
<oliv3r>
did something get pushed that breaks things?
<oliv3r>
oh wait, let me switch back to an older compiler
<oliv3r>
i think i'm hitting some gcc 4.7.3 u-boot bugs
<oliv3r>
no that's not it
<oliv3r>
arokux2: what do you get if you compile current head?
<mnemoc>
arokux2: [linux-sunxi] [PATCH][RFC] Add standalone driver for the A20 Soc TP embedded temperature sensor
<arokux2>
oliv3r: for which board should I compile.. (if it matters)
<mnemoc>
arokux2: oct. 7th..... but ... was it accepted?
<oliv3r>
Cubietruck
wingrime has quit [Ping timeout: 245 seconds]
pfdm has joined #linux-sunxi
<oliv3r>
mnemoc: i think the author was in talk with the hansg, who had some issues/pointers, i think in the end we agreed for 3.4 it didn't matter much
<arokux2>
Montjoie is here
<mnemoc>
so I just apply it?
<mnemoc>
or wait for a v2?
<oliv3r>
mnemoc: i don't remember the conclusion
<arokux2>
oliv3r: everything compiles find for me.
<mnemoc>
:\
FR^2 has quit [Quit: Connection reset by peer]
<arokux2>
oliv3r: fine*
<oliv3r>
arokux2: your not usign the BSP are you
<arokux2>
oliv3r: no!
<arokux2>
oliv3r: make distclean
<mnemoc>
oliv3r: will you push your fixes/branches to revive the bsp?
<oliv3r>
arokux2: the BSP uses O(output)=build/${BOARDNAME} so you don't ever hae to dot hat
<oliv3r>
mnemoc: i think i pushed them to a WIP branch
<oliv3r>
still get the error on the timer
<arokux2>
oliv3r: where is your u-boot branch, I can compile it.
<oliv3r>
hno: btw, the next u-boot merge with upstream will be interesting, there where quite some cleanup patches (whitespaces/tabs) on boards.cfg for example
<arokux2>
oliv3r: !! your git hub wasn't up to date!
<oliv3r>
olimex has i2c rom, but doesn't buy mac either; these are 'dev boards' and don't get mac's. then again Mele doesn't buy a mac either
<oliv3r>
arokux2: you pushed to fast :p
<oliv3r>
pulled
<hramrach>
no change here
<mnemoc>
arokux2: just set a MAC on userspace
<oliv3r>
if mnemoc and arokux2 can compile and use this u-boot; i will push
<oliv3r>
mnemoc: rather set it via boot env of u-boot
<oliv3r>
a little cleaner imo :)
<mnemoc>
true
<arokux2>
oliv3r: Mele did put sticker
focus2 has joined #linux-sunxi
<oliv3r>
arokux2: so maybe they did buy a valid mac; good!
<mnemoc>
arokux2: mele bought addresses, and write them on the u-boot of each device
<mnemoc>
u-boot env*
<oliv3r>
arokux2: basically, companies buy a mac 'block' like 10 million or whatever mac addresses, they buy the 'prefix', in USB words, the vendor ID; they can then use as many mac addresses as they want from that pool
<arokux2>
mnemoc: do you already see 2GiB in kernel?
<oliv3r>
arokux2: does that include HEAD? i think it does, i only wanna send a few patches, but not the top few; i thought the syntax was 'from hash'-'to hash' but never gotten that to work
<hramrach>
I use something like HEAD~3 to get 3 patches
<hramrach>
but why HEAD^ ?
<arokux2>
hramrach: what compiler are u using, plz run --version
<hramrach>
excluding last patch?
<oliv3r>
git format-patch 43cafbd^..da7a3b6
<oliv3r>
works, angel
<montjoie[home]>
If someone know what exactly means the last value of sunxi_dma_config, I will love it (what means data block size...)
<arokux2>
hramrach: disregard
<hramrach>
gcc (Debian 4.7.2-5) 4.7.2 (emdebian)
<arokux2>
oliv3r: got prompt, now do not know why.
<oliv3r>
so, you guys play with what i have in my git hub now (forced push 30 seconds ago, should be identical, just some commit messages changed) and i'll push it after bathroom break
<oliv3r>
hramrach said it's all okay
<arokux2>
oliv3r: I confirm everything works, so please push it.
<arokux2>
montjoie[home]: now I'll test you hackery
ZetaNeta has quit [Ping timeout: 240 seconds]
rellla has quit [Ping timeout: 246 seconds]
FR^2 has joined #linux-sunxi
<oliv3r>
not gonna push da7a3b6 Update all references to get_ram_size to unsigned long
<arokux2>
mnemoc: can we somehow have `git describe` instead of "+" here "Linux alarm 3.4.67+ ...." ?
<mnemoc>
that's the standard way of linux versioning
<mnemoc>
we don't touch it...
<arokux2>
mnemoc: I do not like it :(
<arokux2>
mnemoc: we never know what ppl run
<mnemoc>
argue that on lkml :p
<oliv3r>
mnemoc: Warning: apc_store(): Potential cache slam averted for key 'sunxi-mw:user:id:454' in /srv/http/sunxi/linux-sunxi.org/wiki/includes/objectcache/APCBagOStuff.php on line 59
<oliv3r>
arokux2: can't update, it's allready there
<oliv3r>
* 2GiB RAM works with u-boot-sunxi git
<mnemoc>
arokux2: i think there is a CONFIG_ to get the hash appended
<mnemoc>
arokux2: we can add it to the defconfigs
<arokux2>
mnemoc: we should do it.
<oliv3r>
i agree, it's a realyl good idea
<oliv3r>
u-boot built from git does it too
<hramrach>
do we have battery status form axp?
* hramrach
had a battery pack somewhere
<oliv3r>
I use an old iPhone 3gS battery with a connector soldered on
popolon has joined #linux-sunxi
<hramrach>
I have a battery from a mobile DVD player
<hramrach>
2x 1300 mAh
<arokux2>
scripts/setlocalversion
<mnemoc>
arokux2: find the CONFIG_ and submit the patch
<jemk>
arokux2: yes, but that needs aligned memory and the designware driver doesn't care about aligned memory, so much work
<oliv3r>
so disable it :D
<oliv3r>
revert the patch
<arokux2>
patch cannot be reverted, it was overwritten.
<arokux2>
i.e. part of the original patch was deleted.
<arokux2>
i.e. reformatted.
shineworld has joined #linux-sunxi
shineworld has left #linux-sunxi [#linux-sunxi]
<oliv3r>
arokux2: yeah but i ment ..
<oliv3r>
but yeah
<oliv3r>
arokux2: libv always goes to fosdem :p
<arokux2>
I wonder what the speed up with dcache is anyways.
<arokux2>
oliv3r: I didn't know. I always ask if I don't know something. :)
<arokux2>
oliv3r: and I do not promise things without doing them :p
wolfy has left #linux-sunxi [#linux-sunxi]
<oliv3r>
lol
<arokux2>
oliv3r: what is this for? sun4i_crane_defconfig
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
<oliv3r>
android it hink
<arokux2>
mnemoc: ^
tomboy64 has quit [Ping timeout: 240 seconds]
tomboy64 has joined #linux-sunxi
n01 has quit [Ping timeout: 245 seconds]
<jemk>
arokux2: sorry, i'll finish and push it tomorrow morning, need some sleep
<arokux2>
jemk: ok, np! good night.
Soru_ has quit [Ping timeout: 272 seconds]
nove has quit [Quit: nove]
jemk has quit [Quit: night all]
AreaScout has quit []
<oliv3r>
arokux2: got the mail ready to go out, just gotta write the cover letter; it's open in my editor I will think about a good cover letter and send it off tomorrow
<oliv3r>
nna ll
<arokux2>
oliv3r: +1
iamfrankenstein has quit [Quit: Nettalk6 - www.ntalk.de]
<Dapsaille>
well .. i've made some progress regarding A13 Vga to 15khz crt ... it seems that i lack csync and i cannot find anything in docs regarding csync in sunxi
focus2 has quit [Quit: Leaving]
<Dapsaille>
and of course my arcade cab monitors need csync :)
<Dapsaille>
time to get some rest for now ... see ya tomorrow, code safe o/
iamfrankenstein has joined #linux-sunxi
* tomee^
go 2 sleep
tomee^ has quit [Quit: I Quit.]
Black_Horseman has quit [Quit: Αποχώρησε]
Black_Horseman has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
pfdm has quit [Ping timeout: 250 seconds]
<arokux2>
Dapsaille: night.
FR^2 has quit [Quit: und weg...]
dalee has quit [Quit: Page closed]
<Turl>
ssvb: were you using my mbus patches? maybe it's the higher voltage and not the mbus
<arokux2>
Turl: did you get your CT?
<ssvb>
Turl: no, these were the old results from a long time ago
<Turl>
arokux2: nope
<Turl>
ssvb: ah ok
<arokux2>
Turl: can you track it?
<arokux2>
ssvb: please update this thread with new results, if any, I'll create a doc based on that.
<Turl>
arokux2: yes I can, it's on customs
<arokux2>
Turl: is Patrick Wood working for Cubietech?