| 23:59 | Artox | earthy: the first one, yes |
| 23:59 | Artox | and, what freescale bsp exactly? |
| 23:59 | Artox | I am only aware of specific softwre packages by freescale; Yocto is a good source for those |
| 23:59 | Artox | but I am mostly ignorant on freescales sdk's |
| 00:00 | Artox | basically there is a gpu-viv-bin package by freescale for 3d stuff |
| 00:03 | earthy | hm. |
| 00:04 | earthy | that's the stuff in http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/ ? |
| 00:04 | Artox | I believe the timesys stuff is outdated |
| 00:05 | Artox | at leasr what you can find there |
| 00:05 | Artox | for one, this is a freescale mirror |
| 00:05 | Artox | https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf#L17 |
| 00:05 | Artox | as well as https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf#L14 |
| 00:06 | Artox | and the current filename is gpu-viv-bin-mx6q_3.10.17-1.0.1-hfp.bin |
| 00:06 | Artox | and gpu-viv-bin-mx6q_3.10.17-1.0.1-sfp.bin |
| 00:06 | earthy | ha. right. |
| 00:06 | Artox | arrgh |
| 00:06 | Artox | nope, those are newer ............. |
| 00:06 | Artox | no |
| 00:06 | Artox | wrong ones |
| 00:07 | Artox | gpu-viv-bin-mx6q-3.10.17-1.0.0-hfp.bin |
| 00:07 | Artox | there |
| 00:07 | Artox | I havent tried the 1.0.1 versions so I cant say if they are compatible |
| 00:07 | Artox | maybe someone else can? |
| 00:07 | Artox | jnettlet or rabeeh maybe |
| 00:08 | earthy | yeah, I kinda was hoping for some guidance here, as that really is the last bit of the puzzle that I'm trying to solve |
| 00:09 | Artox | well, youve come to the right place at least |
| 00:10 | Artox | the 1.0.0 are compatible with 3.14 that I know |
| 00:14 | mk01 | FSC viv fbdev driver for X11 is ABI 14 |
| 00:14 | mk01 | je |
| 00:15 | mk01 | debian jessie has xorg 1.16 |
| 00:15 | mk01 | what is ABI18 |
| 00:15 | mk01 | and ubuntu trusty is 1.15 -> ABI16 |
| 00:15 | Artox | mk01: but its opensource |
| 00:15 | Artox | and can be patched |
| 00:15 | earthy | okay. FSC == Freescale Semiconductor, viv == vivante, fbdev == framebuffer device, ABI 14 is xorg driver |
| 00:15 | Artox | I had it loaded under 1.16 once |
| 00:15 | Artox | but didnt work well |
| 00:16 | mk01 | I'm just informing |
| 00:16 | earthy | I'm just trying to make heads and tails of all the info out there |
| 00:16 | earthy | there's a tantalizing amount of data, but no real overview |
| 00:17 | Artox | [00:16] the 3.10.31 .bin is the first one that uses v5 |
| 00:17 | Artox | [00:16] so 3.17.* should be fine? |
| 00:17 | Artox | [00:16] yes |
| 00:17 | mk01 | one can of course update the ABI calls |
| 00:17 | mk01 | but that guarantees only that it will COMPILE and LOAD |
| 00:17 | mk01 | it just half of the storhy |
| 00:17 | mk01 | story |
| 00:18 | Artox | sure |
| 00:18 | Artox | add a bit of prayer |
| 00:18 | Artox | and it could work |
| 00:18 | mk01 | what is confirmed to work is 1.14 xserver |
| 00:18 | Artox | indeed |
| 00:19 | mk01 | actually the version what also YOCTO provides |
| 00:19 | Artox | including a patch to libdrm that yocto provides while we're at it |
| 00:19 | earthy | call me naive, but shouldn't a good update not only update the exact calls, but also check for the semantics thereof, i.e., call the correct functions with the correct paramters? |
| 00:19 | Artox | yeah |
| 00:19 | earthy | ofcourse, obviously, such a patch doesn't exist yet. |
| 00:19 | earthy | 'yaay'. :) |
| 00:20 | mk01 | earthy: sure, but there is no VIVANTE(c) update |
| 00:20 | mk01 | its all us standard people |
| 00:20 | mk01 | and remember that all the libs in gpu-viv-package |
| 00:20 | mk01 | are CLOSED SOURCE, BINARY only |
| 00:20 | mk01 | with hidden symbols |
| 00:21 | mk01 | AND |
| 00:21 | mk01 | compiled to WORK on YOCTO and with 1.14 server |
| 00:21 | earthy | and the etna_viv drivers don't support GC2000 yet, and lack some other bits |
| 00:22 | Artox | now the 1.0.1 pkg might be worth investigating |
| 00:22 | mk01 | if you want EGL SCREEN SUPPORT |
| 00:22 | mk01 | it works |
| 00:22 | mk01 | well |
| 00:22 | mk01 | and fast |
| 00:22 | mk01 | even without "paperwise" GC2000 support |
| 00:23 | mk01 | Artox: if you get the link send it |
| 00:23 | mk01 | will DL it too |
| 00:23 | Artox | the link is "easy" |
| 00:23 | earthy | and that's the upstream etna_viv in https://github.com/etnaviv/etna_viv ? |
| 00:24 | mk01 | yes that one I talk about |
| 00:24 | Artox | or so I hoped ..... |
| 00:24 | mk01 | there is also a mesa fork with EGL integration for ETNA as Galli |
| 00:24 | mk01 | Gallium driverr |
| 00:27 | earthy | but that doesn't support full GC2000 either? but apparently GC2000 will correctly render the command streams generated by etna_viv, if not necessarily at top performance? |
| 00:27 | earthy | or am I misunderstanding again? |
| 00:27 | mk01 | Artox: what is the address of yocto DL servers ? |
| 00:28 | mk01 | from that I remember |
| 00:28 | Artox | well I got 404's |
| 00:28 | Artox | ............. |
| 00:28 | Artox | ..... |
| 00:28 | mk01 | earthy: es2_gears_screen is doing ~350fps at 1920x1080 |
| 00:28 | Artox | . |
| 00:28 | mk01 | Artax |
| 00:29 | mk01 | yd I know, you have to know exact filename too |
| 00:29 | Artox | yes |
| 00:29 | mk01 | tell me the DL server |
| 00:29 | mk01 | I will tell yo then whole addr |
| 00:29 | Artox | https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc#L22 |
| 00:29 | Artox | there it says filename |
| 00:29 | Artox | https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf#L14 |
| 00:29 | Artox | and there mirror |
| 00:29 | mk01 | NN |
| 00:29 | mk01 | filename is always .tar.gz |
| 00:29 | mk01 | ending |
| 00:30 | Artox | no |
| 00:30 | Artox | 1.0.0 is .bin |
| 00:30 | earthy | that fork is https://github.com/laanwj/mesa ? |
| 00:30 | mk01 | Artox: it is per pkg :))) |
| 00:30 | mk01 | firmware & gpu is bin |
| 00:31 | mk01 | libvpu and xservrre is tar.gz |
| 00:32 | jnettlet | earthy, please use http://github.com/etnaviv/mesa |
| 00:32 | mk01 | earthy: yes |
| 00:32 | Artox | [00:29] I will tell yo then whole addr |
| 00:32 | Artox | so, I am curious |
| 00:32 | jnettlet | in general they are all pretty much the same but we are trying to push the community repos for general use. |
| 00:33 | earthy | jnettlet: thanks for the heads up. |
| 00:34 | mk01 | Artox: ach. I never remember yocto dl servers address. |
| 00:35 | Artox | HIT: www.freescale.com/lgfiles/NMG/MAD/YOCTO/gpu-viv-bin-mx6q-3.10.17-1.0.1-hfp.bin |
| 00:35 | Artox | I wrote a fetch script exactly to not remeber anything |
| 00:35 | Artox | I tell it a filename and the md5 |
| 00:35 | Artox | it will try 2 mirrors |
| 00:35 | Artox | and check sums |
| 00:35 | earthy | okay, so it seems that austriancoder is also hard at work on the etna_viv stuff |
| 00:36 | earthy | good, now at least I feel like I'm getting a handle on things again. |
| 00:40 | earthy | man it's hard to get back into linux after 10 years of not paying attention; especially as it's on a new-to-me platform |
| 00:41 | earthy | okay, I'll be off lurking again and mixing my own devil's brew system image |
| 00:42 | earthy | thanks guys |
| 01:57 | Artox | mk01: tried anything yet with the 1.0.1 pkg? |
| 02:15 | mk01 | Artox:it is not different from 1.0.0 |
| 02:59 | Fortuona | well, I tried, and the 3.10.17-1..0.1-ga binaries work fine as far as I could test |
| 07:28 | mk01 | can anyone tell me what is the CONFIG_ parameter (3.14.y) what is playing bad with H1 not booting (even no showing hdmi output?). same kernel works on C4p, dtb's are latest with no patches. |
| 07:29 | mk01 | already tried "last chance" approach - like default config -> compile -> runs C4p, runs H1. the menuconfig while reading some of settings -> compile -> C4p ok, H1 no boot |
| 09:46 | jj_ | hello everybody, I got a original cubox (not ..-i) and wonder if there is a android image available or whether the cubox-i images are compatible |
| 09:49 | jj_ | anybody here? I've seen chats with much less people |
| 09:54 | cbxbiker61 | not compatible, i don't think android on the original cubox went very far |
| 09:58 | malte | http://www.solid-run.com/archive/mw |
| 10:01 | cbxbiker61 | damn cool, the latest linux4kix 3.14 code finally fixed my hdmi audio buzzing, i'm guessing it was msi |
| 11:03 | jj_ | is there any recommended distribution/image for the original cubox, I used ubuntu from that time (I think 10.04), but it's confirgured not to be longtime stable (e.g. logs....), so I'm looking for something that will cause me less maintance (I'm using gentoo on my desktop, so technically it's not a problem, but time matters) |
| 11:03 | jj_ | I woiuld like to have mainly browser (and if possible video-player) |
| 11:05 | jj_ | the list of distris in above link is long, so the question for me is which is lean and uptodate |
| 11:06 | jnettlet_ | jj_, right now, unfortunately no. The Dove soc doesn't NEON so the more recent Vivante binaries won't work with it. |
| 11:06 | jnettlet_ | The good news is that the etnaviv 2d drivers are coming along fast so a full OSS driver stack will fix this problem for you. |
| 11:06 | jnettlet_ | You will be able to use any distro you want. |
| 11:07 | jj_ | ok, so they are all kept up to date? |
| 11:59 | earthy | jj_: not so much kept as being brought |
| 12:08 | jj_ | I will try what the installer can do (need the serial/usb modules though) |
| 13:48 | R0nd | hi |
| 13:48 | R0nd | are there any tricks for increasing NFS I/O performance? |
| 13:50 | mk01 | in role os client of server ? |
| 13:52 | R0nd | I'm running nfs kernel server on cubox and using win7 as a client |
| 13:52 | R0nd | not sure what's bottlenecking |
| 13:52 | jnettlet | which kernel version? |
| 13:52 | R0nd | 3.14.14 |
| 13:53 | jnettlet | most recent commits? |
| 13:54 | jnettlet | regardless I would recommending configuring your nfs server to use tcp rather than udp as the transfer protocol |
| 13:54 | R0nd | no idea, I'm using igor's image |
| 14:02 | R0nd | I think windows nfs client is at least a part of the problem |
| 14:04 | R0nd | dd'ing from another linux system gives twice the speed |
| 14:04 | jnettlet | R0nd, what sort of speeds are you seeing? |
| 14:06 | R0nd | 2MB/s from windows and 4.4 from linux |
| 14:06 | R0nd | dd'ing to the drive locally shows about 15 |
| 14:18 | mk01 | R0nd: change the default 1M rsize and wsize buffers on mount to much lower value |
| 14:19 | Rond | mk01: is it done on the client side? |
| 14:19 | mk01 | ye |
| 14:19 | mk01 | yes |
| 14:19 | mk01 | try wsize/rsize=65536 |
| 14:20 | mk01 | that way I go over 5 |
| 14:20 | mk01 | (from yours 4) |
| 14:20 | mk01 | ((and mine 4 also)) |
| 14:20 | Rond | should I set mtype=soft or hard? |
| 14:23 | mk01 | what is mtype (it is not unix nfs mount parameter) |
| 14:23 | R0nd | must be a windows specific thing then |
| 14:24 | mk01 | maybe it is recovery type ? |
| 14:24 | R0nd | okay, the windows client only allows rsize of 1, 2, 4, 8, 16 or 32 KB |
| 14:24 | mk01 | it is just hard/soft on unix |
| 14:25 | mk01 | ok so win doesn't use 1M as all linux since 2.6 kernelens and sun too ? |
| 14:25 | mk01 | if the mtype is recovery type on the link |
| 14:26 | mk01 | it should have no effect if you have LAN ok |
| 14:27 | mk01 | and it should have more impact on UDP as carrier, TCP is stageful so NFS maybe won't recognise minor problems |
| 14:27 | mk01 | anyhow |
| 14:28 | mk01 | I had to bench that myself as I was suprsed you report only 4 (but have to confirm) |
| 14:28 | mk01 | because THE SAME cubox as client |
| 14:28 | mk01 | doing dd from NFS server to of=/dev/null is doing actual eth0 max |
| 14:29 | mk01 | ~60-70 |
| 14:30 | R0nd | what about dd from if=/dev/zero to nfs? |
| 14:34 | mk01 | just trying that (did tmpfs and exported) |
| 14:34 | mk01 | (meaning cubox server - but reading from memory to same client) |
| 14:35 | mk01 | got again 5mb |
| 14:35 | mk01 | so it is not limited by reads from storage |
| 15:27 | R0nd | I think I'm join going to use cubox as a samba client for large file transfers |
| 15:28 | R0nd | :s/join/just |
| 15:28 | jnettlet | I can do line speed using scp on a 100Mbps connection |
| 15:28 | jnettlet | gigabit maxes out at like 14MBps |
| 15:28 | Humpelstilzchen | uhm how does someone change the audio device in xbmc? |
| 15:30 | R0nd | ah damn, my cubox has lost the network again |
| 16:18 | mk01 | jnettlet: scp will be slower due the cpu handling encryption . NFS direction in maxes eth0 so isn't it weird NFS out at 4MB/s ? |
| 16:20 | jnettlet | mk01, that is what I am saying. scp being faster than NFS isn't right at all. We do have the in kernel NEON handling the AES bit slicing which is what allows us to get over the normal 3-4MBps that you usually see. |
| 16:26 | mk01 | jnettlet: got the context now ... |
| 17:11 | R0nd | hmm gotta get a different power adaptor for the cubox |
| 17:11 | R0nd | getting some very peculiar behaviour again |
| 17:44 | R0nd | it can't handle heavy i/o |
| 17:44 | R0nd | keeps dropping wifi connection, and video output cuts out |
| 17:51 | jnettlet | R0nd, how big is the current on, and on what hardware? |
| 17:53 | R0nd | jnettlet: cubox i2ex plugged into the adaptor that came with it (3000mA) |
| 17:53 | R0nd | I have a 2.5" hdd plugged into esata and hdmi connection to my tv |
| 17:54 | jnettlet | but the esata drive should have an external power supply |
| 17:54 | R0nd | hdd is powered through a separate adaptor |
| 17:54 | jnettlet | 3Amps is more than enough to power that configuration. |
| 17:55 | R0nd | I'm trying to copy files onto hdd over wifi |
| 17:55 | jnettlet | I rarely see my dev board break 1Amp |
| 17:55 | jnettlet | most likely a wifi bug. |
| 17:55 | R0nd | network load reaches about 33mbit/s |
| 17:56 | R0nd | everything is stable for a couple of minutes, then wifi and sometimes hdmi cuts out |
| 17:56 | jnettlet | yeah that is nothing. Over ethernet I will do a scp copy that max's out the 100Mbps connection |
| 17:57 | R0nd | so I tested the same configuration except I tried copying to microsd instead of hdd |
| 17:57 | R0nd | successfully copied ~1.5GB file |
| 17:58 | Humpelstilzchen | does anyone use a recent xbmc git version and can tell me how to change the audio device? |
| 18:00 | jnettlet | Humpelstilzchen, http://wiki.xbmc.org/index.php?title=Settings/System#Audio_output |
| 18:00 | jnettlet | R0nd, are you sure that there isn't a problem with the power adapter for your eSata drive? |
| 18:00 | Humpelstilzchen | jnettlet: yeah, thats the option I usually try, its just grayed out |
| 18:00 | jnettlet | or is that powered from a USB port? |
| 18:01 | jnettlet | Humpelstilzchen, which distro? |
| 18:01 | Humpelstilzchen | jnettlet: self compiled xbmc from git on a debian |
| 18:02 | jnettlet | best bet is to check the forums. I don't have the time to troubleshoot that. |
| 18:02 | R0nd | jnettlet: I've reproduced the same behavior with microsd right now |
| 18:02 | R0nd | wifi has dropped again |
| 18:02 | jnettlet | I would probably recommend trying Geexbox/OpenElec and testing that |
| 18:02 | jnettlet | R0nd, like I said this is most likely a wifi problem |
| 18:03 | jnettlet | that driver is still stabilizing |
| 18:03 | R0nd | eh, might as well plug a patchcord into it |
| 18:03 | R0nd | I'm not moving it around after all |
| 18:03 | jnettlet | R0nd, that is probably the simple solution, and you will get faster transfer speeds |
| 18:04 | R0nd | yeah, thanks, it makes more sense than blaming a 15W power adaptor |
| 18:08 | jnettlet | R0nd, I will be posting a "state of the 3.14.14" kernel summary soon. Then people can have a better idea of what they can expect to work. |
| 18:44 | R0nd | jnettlet: that's great, I bet it will save people quite some time trying to fix what's not supposed to work :) |
| 18:46 | jnettlet | R0nd, well in general I have disabled what is not supposed to work in device-tree. The problem is people keep turning it on and then wondering why it doesn't work :P |
| 22:59 | foundatron | Hi, I just got my cubox i2 with the intent of using the the optical s/pdif for audio with android...but as of yet I haven't been able to get it to output anything. Has anyone gotten optical audio to work in android? |
| 22:59 | foundatron | I see a couple forum posts about, but the seem a little dated |
| 23:15 | cbxbiker61 | Since last night I've been exercising a 3.14.18 kernel, it's working wonderfully |
| 23:16 | cbxbiker61 | i use xbmc code from https://github.com/FernetMenta/xbmc/ , this is a repo that i've used for years now for my amd builds and they now have imx code integrated |