| 04:45 | dbsx | jnettlet: Do you wish to share you iwmmxt string functions? I am more than happy to test |
| 15:33 | jnettlet | dv_, think I have finally managed to sort out getting linaro's gcc 4.8 compiler and environment working with OE. Got passed the eglibc and gcc builds so will have to see if I can spit out a cubox image. |
| 18:18 | _rmk | 18:18 * _rmk_ finally gets ASoC DPCM workign |
| 18:19 | _rmk_ | ... but only with a couple of core ASoC hacks |
| 18:23 | _rmk_ | but maybe not quite |
| 18:38 | dv_ | jnettlet: nice |
| 18:39 | _rmk_ | ... and then it suddenly starts working again mid-track |
| 18:40 | dv_ | jnettlet: be careful with parallel builds though. you need to make sure you have at least 4-8 GB RAM for make -j4 and 4 BB threads |
| 18:40 | dv_ | I have 16, and builds fine with it. with 8, I can see swap activity |
| 18:42 | dv_ | _rmk_: I am amazed at how freescale managed to implement almost the exact opposite of refcounted dmabuf-style buffer handling in their VPU API :) |
| 18:44 | dv_ | I am actually wishing for a vmeta-style approach atm |
| 19:05 | jnettlet | dv_, yeah I have 8 GB's so limited things to -j3. Looks like everything compiled but the do_install has failed. |
| 19:05 | dv_ | do_install of what? |
| 19:06 | dv_ | and, are you using my layerss |
| 19:06 | dv_ | ? |
| 19:07 | jnettlet | dv_, yeah I am using your layer and doing a bitbake cubox-demo-image-sato |
| 19:07 | dv_ | can you paste the logss |
| 19:07 | dv_ | ? |
| 19:07 | dv_ | the output says something about "log." something file. |
| 19:08 | jnettlet | cp: cannot stat `//libc/lib/*': No such file or directory |
| 19:08 | jnettlet | the log is just what it says on the screen. DEBUG: Executing shell function do_install |
| 19:08 | jnettlet | cp: cannot stat `//libc/lib/*': No such file or directory |
| 19:08 | jnettlet | ERROR: Function failed: do_install (log file is located at /home/jnettlet/Source/oe/build/tmp-eglibc/work/marvellpj4hf-vfp-oe-linux-gnueabi/external-linaro-toolchain/-r2/temp/log.do_install.23219) |
| 19:10 | dv_ | uh oh |
| 19:10 | dv_ | I recommend talking to the #oe and #yocto crowd |
| 19:10 | dv_ | but I can imagine they will tell you that trying to use gcc 4.8 is .. brave, currently |
| 19:12 | dv_ | (or perhaps I did something wrong. but my image isnt complex; I do not see what could be wrong) |
| 19:12 | jnettlet | I actually see what happened. To build with the linaro toolchain I need to specify the eglibc version as 2.17. It used that for eglibc-initial which is why everything built properly. But then it built eglibc for the system as 2.18. Then when it went to install 2.17 wasn't there |
| 19:12 | dv_ | jnettlet: ideally, the OE devs manage to get gcc 4.8 in the yocto 1.5 release. then I can add a branch for that release to meta-cubox , with the proper gcc 4.8 PJ4 flags |
| 19:13 | jnettlet | dv_, I am hoping to do "optimized builds" which would carry the tuning patch for our chips as well. |
| 19:13 | jnettlet | ./eglibc-initial/2.17-r3/eglibc-2.17/libc |
| 19:13 | jnettlet | ./eglibc/2.18-r0/eglibc-2.18/libc |
| 19:14 | dv_ | oh.. |
| 19:14 | jnettlet | I should probably just port the linaro-toolchain patches for eglibc and gcc 4.8 over to the 2.18 eglibc |
| 19:15 | jnettlet | I think a lot of the 2.17 patches are backports from fixes in 2.18 |
| 23:15 | _rmk_ | gah, no, it just oopsed |
| 23:15 | _rmk | 23:15 * _rmk_ thinks DPCM abuses ALSA :p |
| 23:34 | dv_ | oh! just found out that the cubox' vivante drivers do contain GL_VIV_direct_texture |
| 23:34 | dv_ | I could avoid the xv hack completely! |
| 23:35 | dv_ | and instead use EGL |
| 23:35 | dv_ | (well, EGL & GLES2) |
| 23:35 | dv_ | jnettlet, _rmk_, your thoughts? |
| 23:38 | _rmk_ | if it works then great. it's something I haven't investigated but would like to at some point - but I do have a lurking question about how the app gets to know when the display window is partially obscured. |
| 23:40 | dv_ | good point. typically, this is not a concern with GL, since applications using GL redraw their contents all the time |
| 23:40 | dv_ | my guess when it is obscured and playback is paused: the application must manually redraw when notifications about invalidated areas come in |
| 23:45 | _rmk_ | I was thinking about what happens when another app pops up a window on top of the video window |
| 23:45 | _rmk_ | and wondering how that window doesn't get overwritten by the video. Maybe it does for a few frames... |
| 23:47 | _rmk_ | good, cubox is back in a working state for tomorrow |
| 23:47 | _rmk_ | want to show it off tomorrow :) |