| 12:03 | otavio | dv: the software codecs? |
| 12:03 | dv | otavio: no, getting specs and tools for the BIT processor |
| 12:04 | dv | the VPU is software for that processor |
| 12:04 | otavio | dv: humm not sure; I can try to ask but I am unsure it'll go anywhere |
| 12:04 | dv | rabeeh had the idea of using this processor for other tasks as well, like image recognition |
| 12:05 | otavio | dv: this can be done using openct no? |
| 12:05 | dv | ehm, you mean opencv? |
| 12:06 | dv | but opencv would do this with the cpu |
| 12:06 | otavio | eheh yes, opencv |
| 12:07 | otavio | dv: indeed |
| 12:07 | dv | well thats the whole point of the idea - to do it in the coprocessor |
| 12:18 | rabeeh | actually not image recognition |
| 12:18 | rabeeh | i was looking more into things that has video streams technology |
| 12:18 | rabeeh | not the standard h.264 etc...; but others that are used for thin computing |
| 12:22 | dv | either way, a publicly accessible bit processor would be very nice |
| 12:23 | dv | depending on what operations are hardwired in it , coming up with custom codecs based on it could be feasible |
| 12:23 | dv | then we could have a connection through vaapi or vdpau |
| 12:25 | dv | and also support other formats like vp9, daala, theora, h265 . obviously not UHD h265/daala videos, but still.. |
| 12:26 | dv | also, the imx6 would become the first commercial embedded SoC which does not require blobs for access to some of its features |
| 12:34 | otavio | I am unsure it will happen but I can try |
| 12:34 | otavio | Can you e-mail me with a description of what you'd need and plans? |
| 12:35 | rabeeh | otavio: the approach should be mainly getting the tools and not the codecs themselves |
| 12:36 | rabeeh | if we ask for codecs then they will be protective |
| 12:36 | otavio | rabeeh: yes; but this is out of my knownledge area so I need a full description about what to ask for |
| 13:22 | dv | otavio: a PDF for the bit processor API (ioctls, or registers etc.) , and whatever headers and libraries are necessary |
| 13:22 | dv | examples would also be nice |
| 13:22 | otavio | dv: please send it by e-mail to me |
| 13:22 | dv | okay |
| 13:22 | otavio | dv: so I can forward it |
| 13:23 | dv | I will pass it to rabeeh first, to see if I missed anything |
| 19:35 | hste | Does the C1 have Gbit ethernet? I thought it only had 100Mbit, but ethtool eth0 says 1000Mb/s |
| 19:35 | dv | it has ... kinda |
| 19:35 | dv | its limited |
| 19:36 | dv | it does *not* go through USB though |
| 19:36 | dv | here, read this http://boundarydevices.com/i-mx6-ethernet/ |
| 19:36 | hste | yes but I tought solo had 100 and quad 1000 (or actually 400+) |
| 19:37 | dv | oh that i dont know |
| 19:37 | dv | have a look at the cubox-i.com comparison table |
| 19:37 | dv | I cant currently |
| 19:39 | hste | it says 10/100 on i1 and i2 |
| 19:41 | dv | makes sense |
| 19:41 | dv | the bigger two have gb lan then |
| 19:43 | _rmk_ | hste: don't make the mistake of confusing the carrier-1 with the cubox-i - they're different |
| 19:43 | dv | rabeeh: bad news: the 3D situation is very complicated |
| 19:44 | dv | rabeeh: a guy with lots of 3D-TV experience is explaining in the gstreamer channel just how messy it is |
| 19:44 | _rmk_ | hste: the cubox-i solo has a different phy which will only go to 100Mbit, but the iMX6S can go to 1000Mbit |
| 19:45 | _rmk_ | what's supplied on the carrier-1 is the 1000Mbit phy with the iMX6S, hence the carrier-1 can do 1000Mbit |
| 19:45 | hste | ok. I thought the imx6s had only 100 :) nice |
| 19:50 | jnettlet | wow, opensuse just released a new version with ARM support. http://en.opensuse.org/Portal:ARM |
| 19:50 | jnettle | 19:50 * jnettlet had thought opensuse had died with Novell. |
| 19:51 | jnettlet | oh they support the Cubox also. |
| 19:51 | jnettlet | http://en.opensuse.org/HCL:CuBox |
| 19:53 | _rmk_ | so... DT people want "make installdtbs" to install the kernel build DT blobs to a path under /lib/modules (I don't care about that) and during the installation, rename the filenames to the compatible string, so you end up with completely different filenames in /lib/modules to those in arch/arm/boot/dts/ |
| 19:53 | _rmk_ | *brain* *dead* |
| 19:58 | jnettlet | what good are the dtbs existing in /lib/modules to begin with? Should they be installed next to the z/uImage? |
| 19:58 | jnettlet | s/Should/Shouldn't/ |
| 19:59 | _rmk_ | maybe, but the path isn't what concerns me about this idea |
| 20:00 | _rmk_ | let's say I want to tell someone to use a specific DT image file. |
| 20:00 | _rmk_ | Do I tell them to use the filename which appears in arch/arm/boot/dts/ or do I tell them to use the one used after installation? |
| 20:01 | _rmk_ | or do I have to tell them something like "if you haven't installed the DT blobs, then you need to use arch/arm/boot/dts/blah.dtb, otherwise you need to use foobar.dtb" |
| 20:04 | jnettlet | don't the compatible strings have ,'s in them also? |
| 20:04 | _rmk_ | yep |
| 20:04 | jnettlet | definitely sounds like quite the clusterf*** |
| 20:05 | _rmk_ | most filesystems have no problem with "," in filenames (which is a good thing, SCCS etc all put ,v on the end of filenames) |
| 20:06 | jnettlet | it is just a strange thing to have in a filename though. Making things harder than they need to be. |
| 20:07 | jnettlet | Why not just install them as the are built in the kernel and make a symlink with the compatible property if it is really needed. |
| 20:07 | _rmk_ | tbh, I don't really care about the name which ends up being used - what I care about is that arch/arm/boot/dts/$name.dtb should result in the file being installed as $target/$name.dtb and not $target/$someothername.dtb |
| 20:08 | _rmk_ | jnettlet: yes, that's another solution to the problem |
| 20:09 | jnettlet | like you said. how are you supposed to track down what the compatible name should so you know what installed .dtb you are looking for? grep through the kernel source directory? |
| 20:13 | _rmk_ | well, there's an inbuilt problem here: what if you have multiple compatible strings for the platform... |
| 20:14 | _rmk_ | eg... |
| 20:14 | _rmk_ | compatible = "globalscale,mirabox", "marvell,armada370", "marvell,armada-370-xp"; |
| 20:14 | _rmk_ | compatible = "plathome,openblocks-ax3-4", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp"; |
| 20:14 | _rmk_ | compatible = "armadeus,imx27-apf27dev", "armadeus,imx27-apf27", "fsl,imx27"; |
| 20:15 | jnettlet | I guess that makes my symlink solution seem a bit more reasonable |
| 20:16 | _rmk_ | but it doesn't work - because we have... |
| 20:16 | _rmk_ | arch/arm/boot/dts/imx28-cfa10036.dts- compatible = "crystalfontz,cfa10036", "fsl,imx28"; |
| 20:16 | _rmk_ | arch/arm/boot/dts/imx28-cfa10037.dts- compatible = "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28"; |
| 20:17 | _rmk_ | arch/arm/boot/dts/imx28-cfa10049.dts- compatible = "crystalfontz,cfa10049", "crystalfontz,cfa10036", "fsl,imx28"; |
| 20:17 | _rmk_ | arch/arm/boot/dts/imx28-cfa10055.dts- compatible = "crystalfontz,cfa10055", "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28"; |
| 20:17 | _rmk_ | which one does "crystalfontz,cfa10036.dtb" get symlinked to? |
| 20:17 | jnettlet | ah I was just wondering if that use case existed |
| 21:16 | svere | jas-hacks_: the uImage you provided me has no devtmpfs. is this correct? |
| 21:16 | jas-hacks_ | svere: I guess so, kernel source is here https://github.com/mtx512/linux-imx/commits/imx_3.0.35_4.1.0-solidrun |
| 21:19 | svere | jas-hacks_: ok. i'm trying to get an archlinuxarm to fly without building a cross-compiler, but i think i give up on this |
| 21:20 | sver | 21:20 * svere is building an armv7 cross-compiler to setup a kernel... |
| 21:23 | jas-hacks_ | svere: time pending I can create a kernel with what you need |
| 21:23 | svere | jas-hacks_: i would at least require devtmpfs enabled |
| 21:27 | svere | jas-hacks_: my underpowered notebook appreciates your effort! ;-) |
| 21:27 | svere | thx |
| 21:30 | hste | svere: http://stende.no-ip.info/c1/kernel_c1_410.tgz |
| 21:37 | svere | hste: thx |
| 21:38 | svere | i now get into the next issue (no init found)... will ask the arch guys |
| 22:16 | svere | hehe tried a gentoo image and it works like a charm :-) |
| 22:17 | svere | cu |