**** BEGIN LOGGING AT Thu Feb 09 02:59:57 2012 Feb 09 04:50:22 khem, thanks Feb 09 06:36:31 hello Feb 09 06:37:06 I'm working with angstrom, so its not really openembedded, but maybe somebody can still help me Feb 09 06:37:34 I configured the kernel to support SLIP and recompiled it Feb 09 06:37:47 then I flashed my dev. kit with the new uImage Feb 09 06:38:03 but I cannot find the slattach command Feb 09 06:38:27 which is supposed to be part of SLIP support Feb 09 07:37:25 jerrycornelius: slattach is user space so you'd need to add the package that contains this prog (assuming there is one; if not you have to write a recipe for it yourself) Feb 09 07:37:38 recompiling the kernel will not give the userspace tools Feb 09 07:37:49 Thanks Feb 09 07:37:58 slattach is in net-tools so I will install this one Feb 09 07:38:08 also Feb 09 07:38:16 I have a bit of a problem with kernel modules Feb 09 07:38:39 even when I enable them at kernel compile time, I don't have /lib/modules Feb 09 08:02:30 jerrycornelius: if you build the kernel packages are generated for all modules but you need to install them explicitly (or add them to your image) Feb 09 08:03:08 I see... Feb 09 09:02:39 good morning Feb 09 10:30:48 hi all Feb 09 10:32:25 hi pb_, all Feb 09 10:45:27 hi all Feb 09 11:02:02 hi florian pb_ bluelightning mckoan all Feb 09 11:24:44 hi florian, eFfeM_work Feb 09 12:50:28 :) Feb 09 13:28:49 hi wondering anyone know to debugged my board network interface i now unable to ping its loopback interface Feb 09 14:49:09 * bluelightning has joined the gta04 group buy Feb 09 14:49:43 great! Feb 09 14:49:49 oh, very good Feb 09 14:49:51 how much are they? Feb 09 14:50:38 http://www.handheld-linux.com/wiki.php?page=GTA04 Feb 09 14:50:53 they are a little on the expensive side, but I really like what the project has done Feb 09 14:51:02 I never expected they'd get this far Feb 09 14:51:39 btw: already supported in meta-smartphone.. Feb 09 14:52:05 JaMa: cool :) Feb 09 14:52:23 yeah, that does sound quite impressive Feb 09 14:52:34 JaMa: I talked to Nikolaus and another guy at FOSDEM, I told them I knew you Feb 09 14:53:12 ah social networks in real life :) Feb 09 14:53:27 heh Feb 09 14:53:56 I almost bought one outright but then I figured getting the group buy off the ground was probably better for them long term Feb 09 14:54:05 I'll have to see if I can find my gta01 to steal its case. :-} Feb 09 14:54:24 yeah, assuming all works out I'll be using my gta01 case Feb 09 14:55:07 well, not that I can really afford one this month, but in theory I should get my bonus sometime between now and the end of march. Feb 09 14:55:19 bluelightning: I would like gta04 much more if there is new case soon, slyon already made his with shapeways (copy of original design) Feb 09 14:55:26 so I hope to see some mods soon :) Feb 09 14:56:06 JaMa: I saw their larger case on the stand... won't win any awards but for industrial applications with the larger battery it would be quite good Feb 09 14:59:06 hmm, I should start buying gta01's on ebay Feb 09 14:59:13 then resell the cases at a profit Feb 09 14:59:59 hmm, ebay has screen protectors Feb 09 15:00:26 yeah, no actual devices that I could find Feb 09 15:00:36 heh Feb 09 15:00:41 you beat me to it :) Feb 09 15:11:45 bluelightning: hehe.. seems I know where to test kexecboot on GTA04 ;) Feb 09 15:16:16 * pb_ stabs useradd.bbclass Feb 09 15:57:00 pb_: what issues are you having? Feb 09 15:58:15 just that it's started hauling shadow into my images again. Feb 09 15:59:57 I think shadow itself might have gotten a bit more toxic as well which might be part of my problem. Feb 09 16:13:03 bluelightning: i put that kirkwood layer for oe-core up on github: https://github.com/kelvinlawson/meta-kirkwood Feb 09 16:13:27 bluelightning: thanks for the pointers last week Feb 09 16:14:06 icanicant: awesome, will add it to the layer index Feb 09 16:14:10 :) Feb 09 16:14:24 currently only tested on the Netgear Stora platform, haven't had a Sheevaplug handy yet Feb 09 16:15:16 bluelightning: ace, cheers for updating the layer index Feb 09 16:18:51 icanicant: if I get some time next week I can test it with a borrowed one Feb 09 16:19:02 otavio: as koen described consoleKit broken anyway, I'm fine with systemd support enabled and I guess less people will override this behavior then vice-versa Feb 09 16:19:46 otavio: and it's not first place to assume systemd enabled (xserver-nodm-init) Feb 09 16:27:51 bluelightning: my sheeva should be back this week anyway, but ta for the offer Feb 09 16:28:24 bluelightning: I've a couple of sheva here under the dust Feb 09 16:28:31 pb_: at least you don't have weird sstate-cache issues with useradd =) Feb 09 16:28:47 could you remind me the link for layer index, please? Feb 09 16:29:19 initSloupceCastka(); Feb 09 16:29:20 mckoan: http://www.openembedded.org/wiki/LayerIndex Feb 09 16:29:23 ups Feb 09 16:29:25 http://www.openembedded.org/index.php?title=Special%3ASearch&search=layer&go=Go Feb 09 16:30:25 msm: heh, true enough Feb 09 16:30:46 bluelightning, icanicant: thx, I just needded any meta-stuff to test oe-core on real hw Feb 09 16:31:24 althought I've gaot a plenty of Atom boards here Feb 09 16:35:41 * mckoan just neet to complete a UVP5150 Camera port on PXA270 though Feb 09 16:37:38 Wow, people are still using that :) Feb 09 16:40:05 JaMa: so just prepare a patch the way you want it and I put it in my tree and do the pull request. Feb 09 16:41:18 broonie: some company are as slow as a sloth Feb 09 16:55:12 otavio: ping Feb 09 16:56:24 whoa, that exploded in my face a bit. Anyone know why I'd get this stuff when building SDK? http://paste2.org/p/1899026 Feb 09 16:57:03 the only difference from what I've been doing is that I put two machine builds into the same TMPDIR Feb 09 16:57:08 instead of separating them Feb 09 16:58:13 ouch armv4 Feb 09 16:58:14 mckoan: would be interested to hear back if you do try out the meta-kirkwood layer. i will try to find time to check it on sheeva first though, to save you any heartache. there shouldn't be much difference from this netgear box though. Feb 09 16:59:12 hbeck try a normal image Feb 09 16:59:19 icanicant: I will try it on the TX71 platform Feb 09 16:59:22 and than look whats wrong in your task Feb 09 16:59:32 likewise: pong Feb 09 16:59:57 woglinde just before this I built the same thing for a different machine target, so the task should work Feb 09 16:59:57 icanicant: I'd like to do that but I have to prepare a oe-core build system from scratch Feb 09 17:00:00 otavio: thanks Feb 09 17:00:15 otavio: you ponged (sp?) today Feb 09 17:00:20 pinged Feb 09 17:00:28 likewise: yes Feb 09 17:00:37 likewise: talk to you privately Feb 09 17:03:56 likewise: TK71? i don't see a CONFIG_MACH option for that in the Marvell kernel Feb 09 17:17:43 likewise: hey howdy Feb 09 17:19:25 icanicant: warp.com, think i had patches for it in OpenEmbedded classic Feb 09 17:19:31 khem: hi there Feb 09 17:20:01 attending ELC ? guess not Feb 09 17:22:45 likewise: how is new iMX treating you Feb 09 17:25:43 khem: let's say its manufacturer is treating me not at all Feb 09 17:26:28 khem: but we are connecting the FPGA next monday and add no-3D-glasses required stuff to it later Feb 09 17:27:54 cool Feb 09 17:29:24 likewise: i see it (CONFIG_MACH_TK71). it's not present in the Marvell kernel (which my meta layer is using for now) or the standard kernel. a simple patch I guess. Feb 09 17:29:58 icanicant: what is the marvell kernel? open git? Feb 09 17:30:28 I used the openrd kernel at some point for the sheeva. Feb 09 17:30:50 khem: ah I wish... Feb 09 17:37:04 likewise: http://git.marvell.com/?p=orion.git;a=summary Feb 09 17:38:34 icanicant: the dead branches tree :) Feb 09 17:40:02 likewise: will add a yocto 3 recipe eventually but initial version of the layer uses the marvell one. Feb 09 17:50:49 talk to you guys layer, have to run. cya Feb 09 17:53:52 Hi, When creating your own layer, is it possible to provide *.inc files as well (in addition to *.bb and .*bbappend)? Feb 09 17:54:40 yes Feb 09 17:56:13 JaMa: Do you know how? via the layer.conf? Feb 09 17:56:39 kenws: same way as you would do Feb 09 17:56:43 in core layer Feb 09 17:57:04 Crofton: hey Feb 09 17:57:09 are you at Connect ? Feb 09 17:57:18 no Feb 09 17:57:20 Ettus :) Feb 09 17:57:22 have you been to connect? Feb 09 17:57:26 ok. Feb 09 17:57:26 I did crash the reception Feb 09 17:57:37 thats good. I could not make it Feb 09 17:57:59 kenws: it's just normal file you include/require in your .bb files, what's hard is to append something to existint .inc files Feb 09 17:58:01 I have to balance out since I will be out next week too :) Feb 09 17:58:09 least my boss forgets me :) Feb 09 17:58:11 Crofton: ericben: would really appreciate you testing the patches I sent out if you can Feb 09 17:59:04 for qt? Feb 09 17:59:04 kenws: when including them make sure you include the layer relative path Feb 09 17:59:26 kenws: and your layer should appear before others in BBPATH Feb 09 17:59:27 Crofton: yep Feb 09 17:59:36 JaMa: khem: Ok, thanks. I guess I don't understand which paths are already being searched for *inc files Feb 09 17:59:54 kenws: BBPATH and in order Feb 09 18:00:10 aah Feb 09 18:00:44 so it can happen that your .bb gets picked from your layer since you have PRIORITY higher than others Feb 09 18:00:56 but .incs and classed follow bbpath Feb 09 18:01:17 bluelightning, do you have them somewhere I can pull them? Feb 09 18:01:29 it will be hard though, build machine is in VA and I am in CA Feb 09 18:01:44 Crofton: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/qmake-target Feb 09 18:02:11 Crofton: I realise it's a tough time with ELC being imminent Feb 09 18:02:50 khem: So, instead of using 'BBPATH := "${BBPATH}:${LAYERDIR}"' in the layer.cong one could just switch the two to prefer the files from the layer over what's in oe-core? Feb 09 18:04:20 kenws: BBPATH .= ":${LAYERDIR}" Feb 09 18:04:22 is better Feb 09 18:06:18 khem: hm, but I guess this put the ${LAYERDIR} at the very end which is inconsistent to the order of the bb files Feb 09 18:07:09 kenws: yes in BBLAYERS specify oe-core meta layer as last Feb 09 18:08:04 its matter of convention how you want to arrange them on order. I prefer that top layer I want should be first in BBLA Feb 09 18:08:08 YERS Feb 09 18:08:51 why would I want to have the system search for *.bb files in my layer first but for *.inc in oe-core? Feb 09 18:09:11 so in conf/bblayers.conf I do BBLAYERS = " mylayer otherlayerIcare oe-core" Feb 09 18:09:20 khem, we had good success in getting started on the python module bbfiles last night... Feb 09 18:09:22 yep Feb 09 18:09:24 if I have overrides Feb 09 18:09:35 ka6sox: amen Feb 09 18:10:36 kenws: in layers you have BBPATH .= ":${LAYERDIR}" generally Feb 09 18:10:43 khem: I don't quite understand why this is better than just having BBPATH and BBFILES in the same order... ? Feb 09 18:11:24 or rather, such that BBPATH is prepended by each layer Feb 09 18:12:16 bluelightning: yes its same order .= is appending Feb 09 18:14:34 khem: but it seems that in your bblayers.conf you prepend your layer rather than append Feb 09 18:15:25 bluelightning: ideally BBFILE_PRIORITY should be either nuked or make to act for .inc and classes as well Feb 09 18:15:40 right now it confuses quite a lot Feb 09 18:17:21 khem: yes, I think kergoth agrees Feb 09 18:17:22 khem: no luck on the multimachine sdk thus far, but I think our solution is just going to be to build them separately but change SDK_NAME from ${DISTRO}/${TARGET_ARCH}/ to something slightly more specific. Feb 09 18:17:49 khem: we should probably address this in a discussion, but I worry that we have more pressing issues to work on atm Feb 09 18:18:09 Any idea how to select the more-specific, but still most generic possible instead of TARGET_ARCH? Specific case being the difference in arm chips for the ones with no FP support vs ones that have hardware FP support Feb 09 18:21:26 hbeck: yes use ${DISTRO}/${MULTIMACH_ARCH}/ Feb 09 18:21:40 Hm, right now I'm struggling on how to provide things like 'conf/distro/include/tcmode-${TCMODE}.inc' by an external layer Feb 09 18:22:01 kenws: why do you need that Feb 09 18:22:26 kenws: try to use as much as possible from oe-core Feb 09 18:22:44 whenever you feel an urge to override a class of .inc think twice :) Feb 09 18:23:49 you can create such a file /conf/distro/include/tcmode-.inc Feb 09 18:24:20 this may not be the best example since TCMODE is either internal or external Feb 09 18:24:22 thats it Feb 09 18:24:29 and both are covered in oe-core Feb 09 18:24:37 khem: I've got a tcmode-external-linaro.inc that sets the preferred providers to "external-linaro-toolchain". That is to allow the user to use TCMODE = "external-linaro" in the local.conf Feb 09 18:25:07 no, it's either default or external-csl : ) Feb 09 18:25:13 kenws: ok TCMODE=external-linaro Feb 09 18:25:28 hey khem, random question - does oe-core fix the silliness with tzcode/tzdata where the recipe name would have to change every time that thing was updated at the source? Feb 09 18:25:29 yes thats what I meant broadly Feb 09 18:26:36 hbeck: yes its still same but better since you only move one file Feb 09 18:26:43 khem: if the user specifies TCMODE = "external-csl" it would pull in the wrong recipes. That's why I added meta/conf/distro/include/tcmode-external-linaro.inc. And I'd like to move that to the external layer Feb 09 18:26:58 kenws: sure. Feb 09 18:27:22 kenws: you can do that Feb 09 18:27:57 khem: ok, thanks. I'll check if bitbake finds it when putting it into /conf/distro/include/ Feb 09 18:28:47 kenws: it will provided BBPATH has your layer appearing before oe-core Feb 09 18:28:57 in this case probably it wont matter Feb 09 18:29:07 since there is no duplicate copy in oe-core Feb 09 18:29:15 (since it doesn't collide with te existing ones) Feb 09 18:29:18 ok, i think i got it Feb 09 18:29:20 thanks! Feb 09 18:29:25 np Feb 09 18:31:07 cool,it seems to work! Feb 09 18:58:20 re Feb 09 19:24:46 hi khem Feb 09 19:38:03 woglinde: howdy Feb 09 19:39:55 kenws: is meta-linaro available somewhere other then your harddrive? Feb 09 19:42:50 hi hrw Feb 09 19:45:07 hrw: how is it going. :) Feb 09 19:45:17 hrw: my boss wanted me back in hut Feb 09 19:45:34 there are some burning fires at work :) Feb 09 19:45:35 khem: goes ok Feb 09 19:45:47 visit at computer history museum was quite nice Feb 09 19:45:47 khem hehe Feb 09 19:45:58 hrw: when you leave for NY Feb 09 19:46:15 hrw: did you get a chance to see all the old computers ! Feb 09 19:47:01 yeah mountain view Feb 09 19:47:11 read about in the ieee magazin Feb 09 19:47:14 I think Feb 09 19:47:15 did you see that huge 4Meg disk drum :) right now that drum can host 1000 cell phones each with 64gig ram Feb 09 19:47:19 err flash Feb 09 19:47:47 woglinde: yes its amazing. I volunteered there when I did not have kids Feb 09 19:48:09 khem uhm what did you do? Feb 09 19:48:22 cleaned the floors lol Feb 09 19:48:30 khem: tomorrow 22:30 from sfo Feb 09 19:48:30 lol Feb 09 19:48:35 you kidding Feb 09 19:48:46 no I was working on restoring a tape drive for PDP 11 Feb 09 19:48:55 with a friend Feb 09 19:49:04 I knew nothing about PDP Feb 09 19:49:36 hrw: OK. I might squeeze in some time tomorrow and come over to say bye bye Feb 09 19:50:28 khem: we have demo friday at 16:00 where you can see some demos of things linaro related Feb 09 19:51:37 they have PDP-1/-8/-11 Feb 09 19:52:15 pdp-1 got restored to working condition and they were even able to restore backups from magnetic cores Feb 09 19:52:19 crazy stuff Feb 09 19:56:54 hrw: yeah we could play spacecraft on pdp 11 Feb 09 19:57:41 khem: spacewar you mean? Feb 09 19:58:27 sorry yes Feb 09 20:00:43 ok, time to go for next session Feb 09 20:04:36 its funny at times I type butbake instead of bitbake Feb 09 20:04:53 and in retrospect its sometimes behaves like buttbake Feb 09 20:05:57 03Ulf Samuelsson  07master * r1dcec0cd96 10openembedded.git/recipes/schroedinger/schroedinger_1.0.11.bb: (log message trimmed) Feb 09 20:05:58 schroedinger: Bump version to 1.0.11 Feb 09 20:05:58 schroedinger depends on orc (Oil Runtime Compiler) Feb 09 20:05:58 With the current version of schroedinger (1.0.9) Feb 09 20:05:58 orc must have revision 0.4.11 or earlier. Feb 09 20:05:58 As of 0.4.12, a stdint.h header is removed, breaking Feb 09 20:05:58 the schroedinger build, and thus oe-classic which is now Feb 09 20:06:07 03Ulf Samuelsson  07master * rf5626cb812 10openembedded.git/recipes/fakeroot/ (4 files in 2 dirs): Feb 09 20:06:08 fakeroot(-native)_1.18.2.bb: Bump version Feb 09 20:06:08 Earlier fakeroot recipes are not longer available Feb 09 20:06:08 at the download source. Feb 09 20:06:08 Upgrade to latest version. Feb 09 20:06:08 Signed-off-by: Ulf Samuelsson Feb 09 20:06:40 woglinde: in oe-core now you can build core-image-sato qt4e-demo-image with uclibc Feb 09 20:06:50 woglinde: and they work as well. Feb 09 20:07:14 sometimes they seem to be zappier than eglibc Feb 09 20:12:36 khem: wow, that is pretty amazing :-) Feb 09 20:18:28 khem I know it from the simpad Feb 09 20:18:47 uclibc felt a lot more responsive than glibc Feb 09 20:19:05 khem we should make some mesureaments and make a talk out of it Feb 09 20:32:21 woglinde: yes Feb 09 20:32:35 woglinde: I always mean to do that but never end up Feb 09 20:45:31 hrw: I just got it working a few hours ago - I can send you a mail if you want. Till now it supports the binary toolchain only and it wont work without a small patch applied to oe-core Feb 09 20:50:05 hrw: here is the patch: http://people.linaro.org/~kwerner/oe-core/tmp/eglibc-locale.patch Feb 09 20:51:17 (since the linaro binary toolchain has no i18n) Feb 09 20:52:11 kenws: if [ -e ${LOCALETREESRC}/${bindir}/* ]; then Feb 09 20:52:14 does that work well Feb 09 20:52:40 oh, good catch Feb 09 20:52:45 the shell would expand it Feb 09 20:53:08 I only tested it without anything being there Feb 09 20:53:11 hm Feb 09 20:53:51 to be sure build eglibc before and after and compare the contents Feb 09 20:54:06 ideally you can also choose to build the OE provided eglibc Feb 09 20:54:23 khem: you mean without using the binary toolchain, right? Feb 09 20:54:31 yes for test correct Feb 09 20:54:36 ok Feb 09 20:54:48 I mean with binary toolchain do you ship a libc ? Feb 09 20:54:54 thats second part Feb 09 20:55:28 if not then you can use the one OE provided so you use prebuilt toolchain to build it Feb 09 20:55:43 I'd love oe to build the eglibc when building with a binary toolchain (and kergoth want's that too) but I haven't managed to get it working that way Feb 09 20:55:49 you have to develop it a bit since with CSL we always took their libc Feb 09 20:56:03 kenws: should be easy Feb 09 20:56:37 currently the recipes for the csl just copy the glibc from the binary toolchain Feb 09 20:57:07 yes it does Feb 09 20:57:15 but you dont have to do it like CSL does Feb 09 20:57:21 I tried to remove the bits that "provide" the libc Feb 09 20:57:55 you can drop linux-libc-headers virtual/${TARGET_PREFIX}libc-for-gcc virtual/libc virtual/libintl virtual/libiconv glibc-thread-db virtual/linux-libc-headers from PROVIDES Feb 09 20:58:00 and that should be it Feb 09 20:58:23 it didn't work (unfortunately I can't remeber the exact failure) Feb 09 20:58:33 but I'll give it a try again tomorrow Feb 09 20:58:47 (it's 10pm over here) Feb 09 20:58:50 : ) Feb 09 20:58:51 yes you have to fix packaging Feb 09 20:59:02 khem: ok, any hints on that? Feb 09 20:59:03 kenws: keine problem Feb 09 20:59:08 hehee Feb 09 20:59:56 kenws: actually I have to look at linaro prebuilt toolchain so comment Feb 09 21:00:25 CSL packages stuff in multilib format which is lot more complex for OE taste Feb 09 21:00:33 khem: I just uploaded it to: http://people.linaro.org/~kwerner/oe-core/tmp/linaro-oe-layer/ Feb 09 21:00:35 does linaro do same ? Feb 09 21:00:46 khem: found out that MULTIMACH_ARCH produces some undesired paths for the cross-sdk stuff (e.g. /opt/distro/i686-armv4t-sdk instead of /opt/distro/armv4t) Feb 09 21:00:57 using BASE_PACKAGE_ARCH seems to work Feb 09 21:00:57 It's quite a hack I have to admit Feb 09 21:01:56 evening all Feb 09 21:02:01 hi pb Feb 09 21:02:01 snowing again, it seems Feb 09 21:02:09 pb lucky Feb 09 21:02:16 hi woglinde Feb 09 21:02:20 hbeck: yes Feb 09 21:02:29 kenws: the layer looks good. Feb 09 21:02:33 at least you have no law to clean the ways at front of you house Feb 09 21:02:59 kenws: we can make it so that you only provide compiler/binutils externally and it builds eglibc internally Feb 09 21:03:02 heh, right Feb 09 21:03:27 woglinde: are their laws for such things in DE Feb 09 21:03:33 pb do you have a sleigh for your daughter? Feb 09 21:03:37 khem yes Feb 09 21:03:41 ugh Feb 09 21:03:49 if you dont clean them and somebody get hurts Feb 09 21:03:57 govenments never stop Feb 09 21:03:59 they can suite you Feb 09 21:04:16 they keep producing laws after laws Feb 09 21:04:34 there is a sentence from the 20ies i very much like Feb 09 21:04:40 it goes like this Feb 09 21:04:40 I bet there is a law that you can not use red color windows Feb 09 21:04:44 :) Feb 09 21:05:07 woglinde: no, I should get one Feb 09 21:05:26 if a german falls, he first search someone he can sue Feb 09 21:05:59 well California has something similar thats why I have to buy home insurance with a huge liability covered Feb 09 21:06:20 its snowing in california? Feb 09 21:06:23 so if some drunkard gets entangled in my fence who knows Feb 09 21:06:41 woglinde: in some parts yes but not where I live Feb 09 21:06:46 it never snows here Feb 09 21:06:59 I think MA, at least, has laws that require you to shovel snow off the pavement in front of your own property. Feb 09 21:07:16 so it isn't just a german thing :-} Feb 09 21:07:43 here in the UK, somewhat weirdly, it is the reverse: people are worried that if they try to clear the snow and then someone has an accident, they will get sued for not doing it right. Feb 09 21:07:47 pb_: could be .. governments are same everywhere Feb 09 21:07:53 all they know is make laws Feb 09 21:07:58 pb yes ;) Feb 09 21:08:00 whereas, if they don't do anything at all, they are not liable Feb 09 21:08:19 hah Feb 09 21:08:24 khem: ok, any hints would be appreciated. : ) I'll try to to remove the libc (and friends) from "PROVIDES" again and adjust the files that get copied by the do_install task Feb 09 21:08:35 kenws: sure Feb 09 21:09:16 kenws: I have to look into contents of linaro binaries Feb 09 21:09:22 I mean tar Feb 09 21:09:31 the url can be found in the recipde Feb 09 21:09:35 recipe Feb 09 21:09:39 kenws: ok Feb 09 21:10:00 kenws: what do u use to build toolchain ? ct-ng or something else Feb 09 21:10:11 yep Feb 09 21:10:20 ct-ng oic Feb 09 21:10:24 a tweaked crosstool ng Feb 09 21:10:33 as always Feb 09 21:10:40 : ) Feb 09 21:19:36 this is micheals ct-ng branch: https://code.launchpad.net/~linaro-toolchain-dev/crosstool-ng/linaro Feb 09 21:23:09 kenws: so question is what you care about more Feb 09 21:23:22 and I guess you care about compiler and may be binutils Feb 09 21:23:41 eglibc is just a support hack as far as binary toolchain is considered right ? Feb 09 21:24:02 or do you have special hacks for eglibc as well that are important Feb 09 21:35:28 khem: yes, mostly about the compiler. As stated earlier it would be great to have eglibc compiled by the cross toolchain rather than using (copying) the one provided by the external binary toolchain Feb 09 21:36:17 I'm a bit confused by the difference (if any real one) in ARMv7 vs ARMv7a, specifically as used in the machine tune files (tune-cortexa8.inc) Feb 09 21:36:56 good nite Feb 09 21:43:49 hbeck: one sets -march=armv7 and the other -march=armv7-a Feb 09 21:45:28 I don't know why OE disables -ftree-vectorize though Feb 09 21:47:34 kenws: right, I get that. not sure why one would choose to hit arch-armv7.inc first rather than arch-armv7a.inc (which then requires v7). I'm not finding much on the ARM site as to the difference there Feb 09 21:48:33 this is all in relation to what I was asking about earlier with building SDKs, we want to build for ARM that supports hardware floating point at the lowest set possible (v6? v7? v7a?) Feb 09 21:49:36 It got a bad reputation :) Feb 09 21:50:31 hbeck: if you want the lowest architecture which supports VFP, that would probably be armv5. Feb 09 21:50:59 I think you could actually get vfp with v4T but that architecture is enough of a rarity nowadays that you can probably ignore it. Feb 09 21:51:12 yeah ARM site doesn't even mention v4 :P Feb 09 21:51:22 looking here... http://www.arm.com/products/processors/technologies/instruction-set-architectures.php Feb 09 21:52:26 seems like we'd want to grab support for VFP v3 Feb 09 21:52:32 which means armv7 Feb 09 21:52:42 but then I'm back to ??? on v7 against v7a Feb 09 21:53:19 seems like this guy http://osdir.com/ml/beagleboard/2012-01/msg00165.html was asking the same question I was Feb 09 21:53:30 or that I am trying to :-/ Feb 09 21:53:47 although we aren't using the angstrom repos Feb 09 21:56:25 well, afaik, armv7 is just the common subset between armv7-a, armv7-r and armv7-m. Feb 09 21:56:35 or, possibly only armv7-a plus armv7-r. Feb 09 21:56:58 do you want to target the v7-r cpus? I assume you probably do not want to target the v7-m ones. Feb 09 21:57:08 * Crofton arm should be shot for having so many possible combinations ..... Feb 09 21:58:12 if you're using oe then I would guess you probably only care about armv7-a. Feb 09 21:58:30 what are they differences? Feb 09 21:58:46 v7-m is microcontrollers, only thumb mode and (iirc) no memory management. Feb 09 21:58:57 kenws: vectorization was crapped in gcc 4.5 and we still use it in production distros Feb 09 21:59:05 kenws: there are posts about it on ml Feb 09 21:59:20 v7-a is application processors, i.e. cortex-aN, which is what most folks using armv7 on OE are probably targetting Feb 09 21:59:33 we really need a good way to test the various toolchains so we can decide what is best for what archs Feb 09 21:59:39 pb_, thanks Feb 09 21:59:55 v7-r is realtime. I don't know so much about those but they are all about deterministic timings so again probably no mmu Feb 09 22:01:35 khem: Isn't OE compiled using -O2 by default (vectorizer disabled)? Feb 09 22:02:20 pb_ thanks Feb 09 22:02:35 kenws: some apps may not Feb 09 22:05:59 khem: You mean in case the recipe specifies -O3? I saw a recipe doing it the other way round by adding a no-vectorization.patch that explicitly sets that flag (I think it was sysklogd) Feb 09 22:07:06 * kenws needs to drop off to get some sleep %) Feb 09 22:07:12 pb_: yes armv7 is least common denominator Feb 09 22:07:21 from gcc pov anyway Feb 09 22:12:52 pb_: interesting armv7-r is somewhere inbetween no mmu and mmu Feb 09 22:12:54 Memory Protection Unit (MPU), controlled by CP15 Feb 09 22:12:54 registers. The MPU does not support virtual addressing. Feb 09 22:13:36 At the Application level, the difference between the ARMv7-A and ARMv7-R memory systems is transparent Feb 09 22:24:00 yeah, it does access control but no translation Feb 09 22:24:13 which means no tlb, so no timing jitter due to tlb refill Feb 09 22:25:09 the v7a/r/m thing isn't actually all that new, they had the same three strands as far back as arm9e. arm926 was the "application" processor, arm946 was the "realtime" one and arm966 was the "embedded" one. Feb 09 22:25:48 and, in a sense, the a/r/m labels are a bit more meaningful than "2", "4" and "6" so I suppose it is an improvement :-) Feb 09 22:26:17 I think the mmu was totally redesigned for armv7-a Feb 09 22:27:05 ah so that was the theory behind the numbers Feb 10 01:36:22 would anyone have experience in getting the smbus extension for python to compile? **** ENDING LOGGING AT Fri Feb 10 02:59:57 2012