08:16 | fritsch | sopparus: openelec will never publish an apk |
09:00 | sopparus | fritsch, I meant when spotify publish the sdk |
09:00 | sopparus | if.. :) |
11:33 | curlymo | arebody here running kernel 3.14.14? |
11:36 | R0nd | yes |
11:36 | curlymo | on a Hummingboard? |
11:36 | R0nd | nope, cubox-i |
11:37 | jnettlet | curlymo, do you need something tested? |
11:37 | curlymo | yes |
11:37 | jnettlet | can do. what is it? |
11:37 | curlymo | i get some wierd results using wiringHB/X on that version |
11:38 | curlymo | please download and compile wiringX: https://github.com/pilight/wiringX |
11:38 | jnettlet | sure I have it :) |
11:38 | jnettlet | I have been recommending it to anyone trying to use GPIO/I2C |
11:38 | curlymo | run "make" in the examples folder |
11:38 | curlymo | then run the interrupt example |
11:39 | curlymo | ofc with a jumper connecting GPIO0 and GPIO1 |
11:40 | curlymo | [offtopic] Funny how nobody came up with the idea to bundle all wiring* versions. The BananaPi and Radxa devs just ported wiringpi on their own... |
11:40 | jnettlet | curlymo, have you contacted them offering integration? |
11:40 | curlymo | i did it myself |
11:40 | curlymo | with pilight users |
11:41 | jnettlet | great. I have a patch I need to send that adds the Novena GPIO breakout board |
11:41 | jnettlet | just need to finish testing and haven't had much time |
11:45 | curlymo | how far are you with testing the interrupt example? |
11:45 | jnettlet | curlymo, will be just a second the new image I brought up doesn't have a compiler on it yet. |
11:45 | curlymo | ok |
11:45 | curlymo | as long as i know :) |
11:45 | jnettlet | I just shifted around my hardware this morning |
11:47 | curlymo | other sidenote, i'm currently using a HB i2eX as an offsite ZFS Backup :D |
11:50 | jnettlet | nice! |
11:50 | jnettlet | which zfs implementation are you using? |
11:50 | curlymo | zfs on linux package |
11:52 | curlymo | zfs package can be found in the XBian repository ofc |
12:09 | curlymo | updates? |
12:23 | jnettlet | curlymo, sorry juggling a few things. You wanted a jumper between ping 7 and 22? |
12:24 | curlymo | no, 11 and 12 |
12:25 | jnettlet | sorry just looked at the scroll back. |
12:25 | jnettlet | I see interrupt, interrupt, timeout |
12:25 | jnettlet | looping |
12:25 | curlymo | great |
12:26 | jnettlet | is that all you needed? |
12:26 | curlymo | can you now try again with this line removed: https://github.com/pilight/wiringX/blob/master/hummingboard.c#L208 |
12:26 | curlymo | and of course the bracket @215 |
12:27 | jnettlet | okay |
12:28 | jnettlet | first interrupt and then all timeouts after that |
12:28 | curlymo | then there is your bug :) |
12:29 | curlymo | inside the kernel ofc |
12:30 | jnettlet | I don't doubt that |
12:30 | jnettlet | the exported sysfs node should only writable if the gpio is set to in? |
12:31 | curlymo | if a GPIO pin is exported through memory and you set the direction through sysfs, all memory allocated GPIO resets |
12:32 | curlymo | you can also test it by not setting the jumper but instead connecting a led to pin 12 |
12:32 | curlymo | it will stop blinking as soon as something is written to sysfs gpio |
12:32 | curlymo | it will start again when you explicitly export the pin through memory again |
12:33 | jnettlet | wonderful |
12:33 | curlymo | as in "who else you have told me about this bug then curlymo?" |
12:36 | jnettlet | but this works properly on the other platforms? |
12:36 | curlymo | yes |
12:36 | curlymo | and it also works on the 3.0.* kernel |
12:37 | curlymo | and on the older 3.14.14 kernel |
12:37 | jnettlet | ? |
12:37 | jnettlet | do you have a git commit? |
12:37 | curlymo | no |
12:37 | curlymo | haven't been using 3.14.14 for a while |
12:38 | jnettlet | nothing has changed in gpio-mxc.c since it was released |
12:38 | curlymo | i really don't have a clue |
12:39 | curlymo | just wanted to make sure it not again an XBian issue :p |
12:39 | jnettlet | thanks |
12:40 | jnettlet | it sounds to me like writing to the sysfs nodes are disabling all interrupts for some reason. |
12:40 | curlymo | it also disables all regular gpio writing |
12:40 | curlymo | it's not just reading |
12:40 | curlymo | pin 11 also stops blinking |
12:40 | jnettlet | but it would stop blinking if interrupts were disabled. |
12:41 | jnettlet | does it always stop off? |
12:41 | curlymo | yes |
12:41 | jnettlet | interesting |
12:41 | jnettlet | then probably not interrupts |
13:32 | crazystick | hi jnettlet, you said that you have been using WiringHB for I2C? What is the number of the I2C bus for you? |
13:34 | jnettlet | crazystick, hey. rabeeh had sent me over a post from you and I haven't had time to follow up on it. |
13:36 | crazystick | ah ok, good that it isn't lost yet. I also added a PR for the SR kernel which I think is also needed: https://github.com/SolidRun/linux-imx6-3.14/pull/19 |
13:36 | jnettlet | while we can't "force" the i2c bus numbering to be the same. People are able to change the .dts files to manipulate them if they choose. But by default i2c3 will be used, which will get numbered by the kernel as i2c2 |
13:36 | jnettlet | devices start at 0 |
13:37 | crazystick | so if that dts change in PR 19 was merged into SR's kernel, that number would be stable unless someone went out of their way to modify it? |
13:38 | crazystick | assuming that the SR kernel is used by the distribution in question of course! |
13:39 | jnettlet | crazystick, yes. ultimately the device numbering is mapped in imx6qdl.dtsi in the aliases section. |
13:39 | jnettlet | and that is pulled from upstream, so things are pretty set in that regard |
13:39 | R0nd | still can't get kodi to play most videos on cubox :/ |
13:39 | jnettlet | R0nd, using what? |
13:41 | R0nd | jnettlet: I'm on debian wheezy with 3.14.14 |
13:41 | R0nd | if you're asking about that |
13:41 | jnettlet | yes |
13:42 | jnettlet | what formats are "most" videos? |
13:42 | jnettlet | can you post a sample? |
13:42 | jnettlet | is kodi compiled natively or cross-compiled? |
13:42 | R0nd | natively |
13:43 | jnettlet | the videos aren't HI10P format are they? |
13:44 | Humpelstilzchen | iirc R0nds videos could be played by ffmpeg, just not by hw |
13:45 | jnettlet | are they anime? |
13:45 | R0nd | nope, no anime. movies, cartoons, pretty sure none of them are hi10p |
13:48 | jnettlet | R0nd, please post the output of ffmpeg -i fubar_video.type |
13:48 | R0nd | here's mediainfo of a file that doesn't play http://pastebin.com/ZCE9dxjQ |
13:50 | sopparus | so got my cubox 10 minutes ago |
13:50 | sopparus | at the door! |
13:50 | sopparus | is there an sd cart inside? |
13:50 | sopparus | its small allright |
13:57 | jnettlet | R0nd, I don't see anything very out of the ordinary with the files |
13:57 | jnettlet | have they been edited in any way? |
14:01 | R0nd | jnettlet: here's another one, it's a bluray remux that's not supposed to have been edited http://pastebin.com/HCWze3sP |
14:03 | R0nd | and here's a bluray remux that plays fine http://pastebin.com/DFRQIJYE |
14:03 | jnettlet | R0nd, please download this and report back how it plays. http://jell.yfish.us/media/Jellyfish-35-Mbps.mkv |
14:06 | jnettlet | R0nd, also do you have change display rate to match video set? I need to tweak some things so our hdmi output can support 23.976 properly |
14:16 | R0nd | jnettlet: thanks, I'll test it when I'm home, unfortunately kodi is unusable over vnc :) |
14:17 | jnettlet | R0nd, yeah no problem. report back. fyi I have been hacking on Kodi for the past 3-4 days and have bumped up the framerate significantly |
14:18 | R0nd | fb vnc server still eats up 100% of cpu |
14:23 | jnettlet | which code-base? there are like a billion vnc servers at this point |
14:53 | R0nd | jnettlet: imx-vncserver, I think it comes from xbian |
16:10 | sopparus | hm am I supposed to get a picture when first plugging in the cubox? |
16:10 | sopparus | even with no os |
16:10 | sopparus | I though some kind of os should be preinstalled |
16:11 | sopparus | either linux or android |
16:13 | deniska | cubox-i comes with sd card with android preinstalled |
16:13 | deniska | (I don't remember if it was optional) |
16:14 | sopparus | then something is broke? |
16:14 | sopparus | I see nothing |
16:14 | sopparus | there is no "on" button riht |
16:15 | jnettlet | sopparus, the sd card is not shipped inside the Cubox-i. It should have been separate in the box. |
16:17 | sopparus | hm |
16:17 | sopparus | no such thing |
16:19 | jnettlet | and there is an sdhc card in the card slot? |
16:22 | sopparus | ah |
16:22 | sopparus | i see its empty |
16:22 | sopparus | I think.. |
16:22 | sopparus | how do you really tell |
16:22 | sopparus | :) |
16:24 | jnettlet | if you tip it towards the light you can see the pins on the roof of the slot |
16:24 | sopparus | seems to be empty |
16:25 | sopparus | https://www.youtube.com/watch?v=SjG7pb4hD2s |
16:25 | sopparus | that is an uboxing video |
16:25 | sopparus | he got a bag with a card in it |
16:25 | sopparus | I did not.. |
16:28 | deniska | sd card might have been optional |
16:28 | deniska | it was at least when I ordered it iirc |
16:29 | sopparus | if I have to get an sd card its soon as much as nuc |
16:31 | jnettlet | maybe a nuc barebones |
16:38 | topi` | I'm wondering how I'm supposed to partition the SD card for proper i.MX6 bootup |
16:38 | topi` | I'm looking at the partitioning of the supplied debian/jessie .dd image but sfdisk is confused |
16:38 | topi` | it says expected (c,h,s) (32,0,1) found (0,32,33) |
16:39 | topi` | so I'm really baffled - how am I supposed to reproduce the partitioning (via an automated script)? |
16:40 | topi` | also, sfdisk interprets that /dev/mmcblk0 has 243200 cylinders, 4 heads and 16 sectors/track which seem very oddball numbers to me |
16:40 | topi` | usually you *always* see 255 heads and 63 sectors |
16:43 | topi` | does the i.MX6 bootloader use CHS or LBA addressing? |
16:43 | topi` | what about U-Boot? |
16:47 | jnettlet | topi`, this is the card shipped with the CBi? |
16:48 | topi` | nope. it's a bulk 8GB card that I flashed a debian/jessie image downloaded from solid-run |
16:48 | topi` | so I wrote over the SD with dd |
16:49 | topi` | I hope the i.MX6 boot process works with LBA addressing as well |
16:49 | jnettlet | topi`, you can try. fdisk -H32 -S32 /dev/device |
16:50 | jnettlet | that is generally what I use to build images as it helps to align things closer to GPT and matches up with most SDHC erase block layouts |
16:51 | topi` | but I need to leave some space in front of the SD card, right? |
16:51 | topi` | where the SPL goes |
16:51 | topi` | does U-Boot go into the beginning as well, or can it be placed on a MSDOS partition? |
16:52 | topi` | can I use GPT with Hummingboard? |
16:52 | topi` | that'd be helpful |
16:55 | jnettlet | H32 S32 buts the first partition at sector 2048 which leaves plenty of room. at the start of the card |
16:55 | lubiana | /buffer #chaos-angel |
16:55 | lubiana | UHH |
16:55 | lubiana | SRY |
16:56 | jnettlet | topi`, good question. I vaguely remember me testing GPT with u-boot but I can't give a definitive answer |
16:57 | topi` | jnettlet: ok, I'll try that setup |
16:57 | jnettlet | if you test it please add it to the wiki :) |
16:57 | topi` | jnettlet: it seems that GPT puts stuff to LBA 0, 1, 2, 3 which can prevent SPL from working |
16:58 | topi` | hmm, there *is* a secondary GPT header at positions LBA -34 .. LBA -1 |
16:58 | topi` | so it might be possible to just overwrite those first sectors |
18:16 | topi` | how big is the SPL + uboot anyways? |
18:18 | jnettlet | how big do you want it to be ? ;) |
18:19 | topi` | I'm just grabbing the spl+uboot directly from that working SD card |
18:19 | topi` | so I did dd if=/dev/mmcblk0 of=bootstuff bs=1k skip=1 count=512 |
18:19 | topi` | I hope it's enough |
18:19 | jnettlet | SPL is about 35K and uboot is about 227K |
18:19 | topi` | I need to get another SD card to be able to test |
18:19 | topi` | right |
18:20 | topi` | I guess it's compiled by you, since it came from solidrun? :) |
18:20 | jnettlet | yes 512k should be fine |
18:21 | jnettlet | the source partially came from me. rabeeh probably compiled the production images |
18:21 | topi` | ok :) |
18:22 | jnettlet | but I did a lot of the early u-boot tinkering |
18:22 | topi` | it's boring, isn't it ;) getting all those DRAM timings right, etc... |
18:23 | topi` | although I'd guess that had already been done properly for the i.MX6 chip |
18:23 | topi` | it's not exactly some exotic chinese SoC |
18:23 | jnettlet | yes, and rabeeh tweaked them. Actually FSL has a pretty decent DRAM timing calibration algorithm |
18:24 | jnettlet | but if you don't do the dynamic calibration you can tweak the memory to get better performance |
18:24 | jnettlet | in general the SR microsom generally beats most other MX6 based boards in memory benchmarks |
18:24 | topi` | at least it beats the Pandaboard (a 1GHz A9 SoC) quite nicely |
18:25 | topi` | 360MB/s vs. 240MB/s from disk buffers |
18:25 | topi` | (hdparm -T ) |
18:25 | jnettlet | which version? |
18:26 | topi` | the older, rev.A version |
18:26 | topi` | I don't have the Pandaboard-ES |
18:26 | jnettlet | although an interesting fact, for CPU based memory performance there isn't much difference between the iMX6S/DL vs iMX6D/Q 32-bit vs 64-bit |
18:27 | jnettlet | because of the multiple bus-masters the overhead limits the total amount of memory bandwidth just the CPU has access to. |
18:27 | jnettlet | it is only with the media decoding and GPU usage that the performance is seen |
18:28 | topi` | yes, it must be a pretty crowded bus |
18:28 | topi` | I wonder how those chinese SoCs with 8 cortex-a7's do the bus mastering and cache coherency |
18:28 | jnettlet | not well :) |
18:29 | topi` | afaik the ARM-supplied hardware only supports cache coherency for up to 4 cores |
18:29 | jnettlet | they are getting better, but early models used to be plagued by problems |
18:29 | topi` | any chance there'll be a Solid-run product using a cheap chinese SoC? :) |
18:30 | jnettlet | the cache coherency for more cores was something that Samsung struggled with for their initial octa-core processors |
18:30 | topi` | not that the Freescale i.MX6 parts are very expensive at $12 apiece... |
18:30 | jnettlet | not that I know of |
18:30 | topi` | I'm also prototyping a chinese Allwinner A31 based board |
18:30 | topi` | it's quad A7, but cheap as dirt |
18:31 | topi` | but the software (and engineering) support sorely lacking |
18:31 | jnettlet | that is generally the drawbacks |
18:31 | jnettlet | the Chinese have made huge progress in chips but the software support is way behind. |
18:31 | topi` | I just told my boss that even though there's the cheaper upfront price, we'd be taking a HUGE risk on betting to solve all the sw problems on time |
18:32 | jnettlet | and then they get stuck in the old mindset of anti-OSS which would really help them |
18:32 | topi` | yeah, it's weird |
18:32 | jnettlet | yeah the driver issues can kill you |
18:33 | topi` | I'm almost finished my initial work with the HB, next week I'll present a "prototype" :) |
18:33 | topi` | to the big bosses |
18:33 | topi` | it's basically a 3G router with some fairly custom software |
18:34 | jnettlet | cool. you are using the mPCIe slot or usb? |
18:34 | topi` | and you can't run custom stuff with off-the-shelves routers, they only have like 64MB of memory |
18:34 | topi` | yes, the mPCIe slot |
18:34 | topi` | the usb slot won't work in production |
18:34 | topi` | I mean, it's just mechanically weak |
18:35 | topi` | we probably want to do a custom board build throwing out all the components and connectors we don't need |
18:35 | jnettlet | I would have figured you would use something wired off the second usb header |
18:35 | jnettlet | yeah, not much need of hdmi for a router |
18:35 | topi` | that's also one possibility, but we feel more safe with the mPCIe based hardware |
18:36 | topi` | we also need plenty of other I/O like I2C stuff, ethernet, etc... |
18:36 | topi` | the i.MX6 is like a one-stop shop :) |
18:36 | jnettlet | yeah, lots of IO |
18:40 | topi` | I was surprised that it was SO much faster than a Raspberry PI |
18:41 | topi` | in my python benchmarks, single-core about 4-5 times the performance and quad something like 12-15x |
18:41 | jnettlet | lots of advantages with the Cortex-A9. our GPIOs are actually fast enough to drive multiple 1-wire devices |
18:41 | topi` | I guess scripting languages really benefit from out-of-order (cortex-a9) |
18:42 | jnettlet | you are using python or javascript? |
18:42 | topi` | I'm a python guy |
18:42 | topi` | but some colleagues sometimes work with js |
18:43 | topi` | for encoding/decoding media, you bind with C libraries and get decent speed that way |
18:47 | jnettlet | sure |
18:47 | jnettlet | especially if you are using gstreamer. python has much better integration |
18:55 | topi` | yes, we're using gstreamer, it's a fairly userful framework |
18:55 | jnettlet | 1.0 or 0.10? |
18:55 | topi` | damn, it's tiresome to do some tooling for image creatoin |
18:55 | topi` | creation |
18:56 | topi` | I think I have some 0.99 plugins for gst :) so it's gotta be 1.0 then |
18:57 | jnettlet | sounds about right |
19:05 | topi` | odd, why do I get libwayland-server when I try to install xserver-xorg-video-fbdev |
19:15 | jnettlet | lol...welcome to the modern world of linux |
19:15 | jnettlet | xorg and fbdev are old...blech here take unfinished wayland. |
19:16 | topi` | :) |
19:16 | topi` | I had a vivante_drv.so lingering on this image... and it was the cause for the Xorg -configure not working |
19:16 | topi` | I rm'ed it |
19:17 | topi` | the Server ABI was 18 and the ABI at that vivante driver was only 14 |
19:17 | topi` | so X refused to start... |
19:17 | topi` | I'm trying to get it to work with fbdev |
19:21 | topi` | bah, the new Xorg server is using a different config method... you place files in /etc/X11/xorg.conf.d |
19:21 | topi` | now I got Xorg to start... and got a black screen, and it froze there |
19:21 | topi` | this with the fbdev driver |
19:22 | topi` | umm, the device works, I can login via ssh, but console is dead |
19:22 | jas-hacks | topi`: if it is the jessie image with the vivante stuff then you need to remove a few libs to get back to a clean state |
19:23 | topi` | yeah, I guessed that. I just removed the vivante_drv.so |
19:24 | topi` | I wonder if etnaviv stuff would have a chance of working for desktop X... |
19:24 | topi` | I mean 2D |
19:25 | jas-hacks | in /usr/lib there is bunch of libGL.so.... that need to be removed and you need to reinstall mesa packages so that libGL.so is correctly configured. |
19:26 | topi` | ok |
19:27 | jas-hacks | it would be easier to start with a minimal console rootfs and just add the X packages |
19:27 | topi` | OK, glxgears works now :) |
19:28 | topi` | indeed, I'm trying to create a script for creating a readymade Hummingboard image |
19:28 | topi` | created from debootstrap |
19:34 | jnettlet | jas-hacks, vivante v5 integration should be ready for testing end of this week or early next week |
19:35 | jas-hacks | jnettlet: in 3.14? |
19:35 | jnettle | 19:35 * jnettlet nods |
19:38 | jas-hacks | v5 (beta) doesn't work too well with X11 + xorg 1.15, fb is ok |
20:03 | R0nd | jnettlet: that jellybox sample won't play either |
20:03 | R0nd | wat did I just say, jellyfish |
20:04 | jnettlet | R0nd, really. Can you enable debug mode and post the output of ~/.kodi/temp/kodi.log somewhere? |
20:04 | jnettlet | preferable after a clean startup, select movie, play it, close it |
20:05 | jas-hacks | jnettlet: should imx_v7_defconfig compile on 3.14? |
20:06 | jnettlet | jas-hacks, yes and boot, but it won't have support for all the devices on the CBi/HB or all the additional kernel functionality we have added to optimize the performance |
20:09 | jnettle | 20:09 * jnettlet is off to finish preparing supper |
20:09 | R0nd | jnettlet: http://pastebin.com/BYWCdDMv |
20:11 | jnettlet | R0nd, kodi isn't using the VPU |
20:11 | jnettlet | cat /proc/interrupts while a video is playing. I am certain you will see the VPU isn't doing anything |
20:24 | R0nd | jnettlet: 44: 30902 0 0 0 GIC 44 VPU_CODEC_IRQ |
20:34 | fritsch | jnettlet: https://github.com/xbmc/xbmc/pull/5805 <- any comments from kernel side? |
20:34 | fritsch | jnettlet: we could need another pair of eyes to fix performance issue from kernel drivers point of view |
21:50 | deuter | malte: https://github.com/patrykk/linux-udoo |
21:50 | deuter | malte: updates |
21:54 | malte | thanks |
23:10 | armv7l | hi |
23:10 | armv7l | does anyone have an ETA on when the hummingboard rev 3.5 will start shipping? |
23:10 | armv7l | thanks |