| 17:12 | jnettle | 17:12 * jnettlet curses at dv_ for sending me down the rabbit hole of open-embedded |
| 17:14 | _rmk_ | what did you find at the bottom of the hole? |
| 17:14 | TrevorH1 | more hole ;) |
| 17:15 | _rmk_ | ah, but then it couldn't be the bottom of the hole! |
| 17:15 | jnettlet | _rmk_, confusion |
| 17:16 | _rmk_ | and we wouldn't like jnettlet to be swallowed by a black hole |
| 17:17 | jnettlet | I have my Linaro layers brought in so I can use gcc 4.8, I can see how to set up special arch or tune compilation options. I am failing to see where I would specify -mcpu to setup iwmmxt compilation properly |
| 20:09 | dv_ | jnettlet: :) |
| 20:09 | dv_ | jnettlet: trying to add a new gcc to OE is ... brave |
| 20:10 | dv_ | jnettlet: you set such flags in the tune features |
| 20:10 | dv_ | example: https://github.com/dv1/meta-cubox/blob/master/conf/machine/include/tune-marvell-pj4.inc |
| 20:10 | dv_ | in here I did not have gcc 4.8 , so I couldnt use -march=marvellpj4 . but these are tune features. |
| 20:11 | dv_ | and then have a look at https://github.com/dv1/meta-cubox#building-the-meta-cubox-layer |
| 20:11 | dv_ | in short, you could take my layer and just edit tune-marvell-pj4.inc |
| 20:15 | dv_ | jnettlet: also, did you use barebones OE, or did you grab a copy of poky from the yocto site as a starting point? |
| 20:15 | dv_ | (I recommend the latter) |
| 20:16 | jnettlet | dv_, but don't the tune features just change the -mtune= parameter to gcc? |
| 20:16 | dv_ | no |
| 20:17 | jnettlet | ah that is what confused me. I could find ARCH_ and TUNE_ settings and figured those represented the different gcc flags |
| 20:18 | jnettlet | well I am using the Linaro overlay. I assume that they have partially smoke-tested it. I guess I will find out. |
| 20:18 | dv_ | you just have to modify TUNE_CCARGS |
| 20:19 | jnettlet | I don't think -march=marvellpj4 works properly with -mcpu=iwmmxt. Well it works but complains about conflicts |
| 20:20 | jnettlet | I need to revisit this and document it all, as well as push gcc to take the scheduling optimization patch |
| 20:21 | jnettlet | dv_, can I set those optimizations for only specific packages? Really only want it for cairo, pixman, ffmpeg, vpx, SDL and some audio libraries. |
| 20:21 | dv_ | hmm not sure. you could try to set CFLAGS |
| 20:22 | dv_ | in the package recipes |
| 20:22 | jnettlet | I also have a set of iwmmxt optimized asm string functions if we really want to rice the build up. |
| 20:22 | dv_ | there is probably a way to add cflags to specific packages by setting some values in the local.conf |
| 20:22 | jnettle | 20:22 * jnettlet will go further down the rabbit hole |
| 20:23 | jnettlet | thanks for the pointers |
| 20:23 | dv_ | sure, OE doesnt have a nice learning curve |
| 20:23 | dv_ | but it is the one I am most familiar with and has worked best for me so far |
| 20:23 | jnettlet | it has been a while. last time I used it was for my N770 |
| 20:24 | dv_ | well, things have changed a lot. the whole layering thing etc. |
| 20:25 | jnettlet | exactly, when I started playing with it yesterday I realized it wasn't going to be the quick and dirty project I had planned out in my head. |
| 20:25 | dv_ | I do prefer the layering though. much cleaner. BSP developers can concentrate on one BSP layer and do not have to battle with upstream |
| 20:26 | dv_ | also helps build performance since it does not have to parse 100000 recipes |
| 20:27 | dv_ | well, gotta go now. good luck and ttyl |
| 20:27 | jnettlet | I agree with the methodology. |
| 20:27 | jnettlet | thanks. ttyl |