| 00:00 | dv_ | hmm yes seems so |
| 00:00 | dv_ | I didnt use imx-lib/imx-vpu directly |
| 00:00 | dv_ | but, I think somebody already did work on imx<->libav integration |
| 00:02 | dv_ | there are https://community.freescale.com/thread/300676 and https://community.freescale.com/thread/310966 , but I remember seeing some code as well. I'm looking. |
| 00:55 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/commit/?h=bmm-3.12 |
| 13:23 | mocara | rabeeh Last week your support people told me in an email that you were shipping computers and that I was in the queue. |
| 13:23 | mocara | Yesterday you tell us that you haven't even recieved the computers yet. |
| 13:23 | mocara | When are you actually going to get the CuBox-i4Pro? Because "a week or so" doesn't actually mean anything. |
| 13:34 | rabeeh | mocara: please send me that mail to my email - [email protected] |
| 13:39 | prae | rabeeh: do you have a prefered platform for developers to build images on for the cubox-i |
| 13:39 | prae | what will your "officially" supported images be based of? |
| 13:43 | dv_ | prae : so far, I see yocto, buildroot, Ubuntu, and arch as the most supported |
| 13:44 | prae | is there any preference between any of them? |
| 13:45 | dv_ | I prefer yocto, because that is the one I have been using most in the past, and because freescale is starting to use it as their officially supported platform |
| 13:46 | prae | i've used yocto a little in the past - if freescale are using it that works for me :) |
| 13:46 | dv_ | (they are shifting away from their own old LTIB platform) |
| 13:47 | prae | thanks |
| 13:47 | dv_ | Generally speaking, if a distro already supports the imx6 soc, then there is a good chance it can be made to support Cubox-i |
| 14:03 | unununium_ | Well, I got the mail about delayed shipping as well, but I think, I will survive that. |
| 14:05 | unununium_ | But as I'm from Germany, I'll have to wait for ages anyways. :D |
| 15:29 | dv_ | unununium_: yeah what is it with germany and their customs? |
| 15:33 | lycanthr1pist_ | The german customs are very slow, because there are so many regulations here in germany, especially if it comes to electronics. |
| 15:34 | lycanthr1pist_ | A few month ago Ouya users had a lot of problems with the german customs. They couldn't get their devices becaus of some small paper work problems. |
| 15:35 | lycanthr1pist_ | Germa authorities just looove paper work. ^^ |
| 15:35 | dv_ | heh |
| 15:35 | dv_ | "passierschein a38" |
| 15:35 | MarcusVinter | Germans are usually so efficient though. |
| 15:36 | lycanthr1pist_ | The Zoll (german name for the customs) seem to be an exception there. :/ |
| 15:39 | lycanthr1pist_ | Even if Solid Run would ship my Cubox-i4 today (and I chose fast EMS shipping), I probably wont get it until next year. ;) |
| 15:39 | lycanthr1pist_ | But it's okay, I'm used to that and I'm very patient. :) |
| 15:54 | unununium_ | dv_: I don't know, and I'm wondering why it takes so long. But we cannot change it, so I won't get mad. |
| 16:08 | MikeSeth | unununium_: manufacturer promised A, delivered A * 0.2 |
| 16:08 | MikeSeth | which is fairly normal business conduct in Israel |
| 17:19 | unununium_ | MikeSeth: That's no problem for me, as I said. ;) I have to move anyways within the next weeks, so I wouldn't have any time for the CuBox. |
| 17:21 | MikeSeth | well I go to the post office every day |
| 17:21 | MikeSeth | :P |
| 17:21 | MikeSeth | though I got the apology mail yesterday |
| 17:22 | MikeSeth | but I cant figure out if it means my order hasn't been processed yet |
| 17:43 | bnilsen | Hi, I have an issue with waking up imx6 from mem power state in linux 3.12. Anyone with knowledge about power management here? |
| 17:49 | bnilsen | It seems none of my wakeup sources are able to wake up the cpu |
| 17:52 | _rmk_ | you're talking about the carrier-1 or the cubox-i? |
| 17:56 | bnilsen | _rmk_: Could be, however my question is more generically about imx6 |
| 22:38 | dv_ | jnettlet, _rmk_ : do these flags look ok for gcc 4.8 and the armada SoC ? -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=vfpv3-d16 -mcpu=iwmmxt2 -mtune=marvellpj4 |
| 22:43 | _rmk_ | they look reasonable - are you encountering a problem with it? |
| 22:43 | _rmk_ | hang on... |
| 22:45 | _rmk_ | normally, you give -mcpu= or -march= and -mtune= |
| 22:45 | _rmk_ | -mcpu= effectively sets the other two |
| 22:45 | hste | http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options |
| 22:45 | dv_ | yeah, but according to jnettlet, I have to specify it like this for pj4 and iwmmxt2 support |
| 22:45 | dv_ | its due to some internal gcc weirdness about their pj4 support |
| 22:46 | _rmk_ | ok then :) |
| 22:46 | dv_ | ... and it doesnt work it seems: configure: error: cannot compute suffix of object files: cannot compile |
| 22:47 | dv_ | I'll retry with only the vfp flag |
| 22:47 | _rmk_ | what's in the config.log ? |
| 22:47 | dv_ | oh hold on. this will take a bit |
| 22:48 | _rmk_ | that's where the compiler error will be from that |
| 22:48 | dv_ | yeah but I cleaned the build right before you wrote :) |
| 22:52 | dv_ | okay got it |
| 22:53 | dv_ | hmm this actually happens during compiling, not configure |
| 22:55 | dv_ | ah lovely. its marvell-pj4, not marvellpj4 :) |
| 22:56 | dv_ | jnettlet: can you confirm these flags? I think you told them to me |
| 23:05 | dv_ | sigh ... no, not out of the woods yet. the -march=armv7-a bit is probably not from jnettlet, but from an automated yocto build. "warning: switch -mcpu=iwmmxt2 conflicts with -march=armv7-a switch" |
| 23:05 | dv_ | and "lib1funcs.S:1348: Error: selected processor does not support ARM mode `movw r7,#2'" |
| 23:08 | hste | dv_ : try -march=iwmmxt2 |
| 23:39 | dv_ | ok without -march=armv7-a it works |
| 23:39 | dv_ | except that eglibc 2.18 causes an ICE |