| 00:25.09 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
| 01:16.12 | *** join/#oe liamMT1 (~Liam@173-164-164-245-SFBA.hfc.comcastbusiness.net) |
| 01:35.54 | *** join/#oe dijenerate (~dijenerat@65.166.241.213) |
| 01:45.22 | *** join/#oe methril (~methril@189.27.129.165.dynamic.adsl.gvt.net.br) |
| 01:55.09 | *** join/#oe brolin (~brolin@190.250.118.144) |
| 02:01.40 | *** join/#oe fraxinath (~quassel@pD9537652.dip.t-dialin.net) |
| 02:06.43 | *** join/#oe devzero_ (devzero@xdsl-89-0-158-215.netcologne.de) |
| 02:53.57 | *** part/#oe incandescant (~joshual@c-24-21-159-20.hsd1.or.comcast.net) |
| 03:51.05 | *** join/#oe mikey_w (~mike@pool-74-110-218-2.rcmdva.fios.verizon.net) |
| 04:14.51 | *** join/#oe mario-go` (~user@67.205.85.241) |
| 04:47.51 | *** join/#oe hufnus (~hufnus@69-12-177-67.dsl.static.sonic.net) |
| 05:13.23 | *** join/#oe Jay7 (jay@95-29-173-107.broadband.corbina.ru) |
| 05:33.42 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 05:37.12 | *** join/#oe 77CAAX6C5 (~weechat@83.151.21.119) |
| 05:48.02 | *** join/#oe sakoman_ (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
| 05:48.58 | *** join/#oe DJWillis (djwillis@cpc3-bath5-2-0-cust220.aztw.cable.virginmedia.com) |
| 05:58.49 | *** join/#oe rschus (~rschus@248.118.101.84.rev.sfr.net) |
| 06:25.59 | *** join/#oe sgw (~sgw@71.193.189.117) |
| 06:53.28 | JaMa | khem: do you have a sec? |
| 07:02.40 | *** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 07:03.50 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:20.37 | *** join/#oe soltys (soltys@83.168.118.74) |
| 07:28.26 | *** join/#oe celston (~chris@188-220-141-241.zone11.bethere.co.uk) |
| 07:30.04 | *** join/#oe soltys (soltys@83.168.118.74) |
| 07:37.56 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:48.13 | *** join/#oe TheUni (~theuni@xbmc/staff/theuni) |
| 07:54.53 | *** join/#oe kobe_ (203a22e3@gateway/web/freenode/ip.32.58.34.227) |
| 07:55.36 | kobe_ | can anybody tell me what 'task-base-extended' is. I searched through all recipes and could not find what it is or what it does... |
| 07:57.25 | *** join/#oe univac (~univac@148.81.171.50) |
| 07:57.53 | *** part/#oe univac (~univac@148.81.171.50) |
| 08:02.35 | *** join/#oe Jay7 (jay@95.29.102.219) |
| 08:17.42 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 08:23.15 | *** join/#oe woglinde (~heinold@f052236071.adsl.alicedsl.de) |
| 08:30.55 | *** join/#oe woglinde (~heinold@f052064191.adsl.alicedsl.de) |
| 08:32.20 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
| 08:34.43 | kobe_ | helloow? |
| 08:35.06 | woglinde | moo |
| 08:38.36 | *** join/#oe dijenerate (~dijenerat@204.212.240.159) |
| 08:44.05 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:56.52 | bluelightning | hi all |
| 08:57.20 | woglinde | hi bluelightning |
| 09:00.25 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 09:01.57 | woglinde | hi gnutoo |
| 09:03.48 | GNUtoo|laptop | hi |
| 09:06.21 | GNUtoo|laptop | woglinde, btw it's not related to oe directly but it seem that the bug with the maps in navit not finding my town has been solved(maptool issue) |
| 09:06.58 | woglinde | yes |
| 09:06.59 | woglinde | good |
| 09:07.44 | GNUtoo|laptop | yes it's very good |
| 09:09.48 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 09:09.57 | *** join/#oe pepermint (~pepermint@host35-89-dynamic.5-87-r.retail.telecomitalia.it) |
| 09:13.31 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 09:18.42 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 09:20.16 | *** join/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 09:28.49 | *** part/#oe davidlt (~davidlt@78-60-130-17.static.zebra.lt) |
| 09:33.11 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 09:42.35 | *** join/#oe fraxinas (~quassel@pD9533DAA.dip.t-dialin.net) |
| 09:56.04 | *** join/#oe woglinde_ (~heinold@f052067028.adsl.alicedsl.de) |
| 10:03.39 | *** join/#oe obi_ (~obi@unaffiliated/obi) |
| 10:08.55 | GNUtoo|laptop | hi, I've issues in shr-core |
| 10:08.57 | GNUtoo|laptop | it says: |
| 10:09.10 | GNUtoo|laptop | | /tmp/ccHnAgUE.s:275: Error: lo register required -- `add pc,r3,#(0xffff0fc0-0xffff0fff)' |
| 10:09.16 | GNUtoo|laptop | I remember thoses address |
| 10:09.20 | GNUtoo|laptop | it's cmpxchg |
| 10:09.52 | GNUtoo|laptop | at least 0xffff0fc0 is cmpxchg |
| 10:10.29 | GNUtoo|laptop | JaMa, any idea? |
| 10:10.37 | GNUtoo|laptop | it's from that package: |
| 10:10.52 | GNUtoo|laptop | eglibc-initial-2.13-r9+svnr14157 |
| 10:11.19 | GNUtoo|laptop | oops I lost the console log |
| 10:11.27 | GNUtoo|laptop | anyway it was in libc-start or something like that |
| 10:19.55 | GNUtoo|laptop | http://www.pastie.org/2289074 |
| 10:20.11 | GNUtoo|laptop | oops forget that paste |
| 10:27.56 | ensc|w | GNUtoo|laptop: that's because armv5te is now compiled with -mthumb :( |
| 10:32.31 | ensc|w | it's a bad choice that -mthumb and -mthumb-interwork are now specified in the TUNE_CCARGS |
| 10:37.44 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 10:37.47 | *** join/#oe woglinde (~heinold@g225144223.adsl.alicedsl.de) |
| 10:38.08 | GNUtoo|laptop | sorry, connection issues(wifi far away+vpn) |
| 10:38.30 | GNUtoo|laptop | ensc|w, ok http://www.pastie.org/2289076 here I see -mthumb |
| 10:38.40 | GNUtoo|laptop | the target is om-gta02 which is armv4t |
| 10:38.46 | GNUtoo|laptop | should I add that: |
| 10:38.58 | GNUtoo|laptop | ARCHITECTURE_arm = "ARM" |
| 10:39.02 | GNUtoo|laptop | or something like that |
| 10:39.11 | GNUtoo|laptop | I don't remember the exact syntax off hand |
| 10:39.51 | GNUtoo|laptop | ARM_INSTRUCTION_SET = "arm" |
| 10:39.53 | GNUtoo|laptop | rather |
| 10:40.56 | JaMa | GNUtoo|laptop: yes it's known.. |
| 10:41.59 | GNUtoo|laptop | ok |
| 10:42.02 | GNUtoo|laptop | then I'll wait |
| 10:42.11 | JaMa | GNUtoo|laptop: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-July/007069.html |
| 10:42.52 | JaMa | GNUtoo|laptop: I won't be here for next week+weekend.. so if you're using oe-core-contrib/shr, feel free to update it when it's fixed in master |
| 10:45.31 | JaMa | GNUtoo|laptop: the problem is that ARM_INSTRUCTION_SET is no longer respected by new tune-* |
| 10:45.58 | GNUtoo|laptop | ah ok ouch |
| 10:46.22 | JaMa | but I was able to build n900 image yesterday after few more changes.. |
| 10:46.28 | GNUtoo|laptop | ok nice |
| 10:46.38 | JaMa | do rebuild from scratch.. |
| 10:47.07 | JaMa | as package arch is changed from armv7a to armv7a-vfp-neon |
| 10:47.26 | GNUtoo|laptop | I didn't build for n900 yet |
| 10:48.21 | GNUtoo|laptop | so there is armv7a without neon? |
| 10:48.25 | GNUtoo|laptop | like for palm-pre? |
| 10:48.29 | GNUtoo|laptop | (it seem to have a broken neon) |
| 10:49.17 | ensc|w | real bug is in eglibc's libc/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h |
| 10:49.26 | GNUtoo|laptop | ok |
| 10:49.47 | GNUtoo|laptop | the userspace part of cmpxchg kernel implementation |
| 10:52.25 | JaMa | GNUtoo|laptop: you can limit tunables from machine config, but configs in meta-palm weren't updated and seems wrong now |
| 10:54.40 | GNUtoo|laptop | ok |
| 10:58.05 | GNUtoo|laptop | can I put TUNENAME_pn-eglibc = "armv4" in local.conf? |
| 10:58.14 | *** join/#oe pepermint (~pepermint@host35-89-dynamic.5-87-r.retail.telecomitalia.it) |
| 11:03.42 | JaMa | better to wait for proper solution, if you can play with n900 for now |
| 11:04.29 | GNUtoo|laptop | ok |
| 11:04.52 | GNUtoo|laptop | I'm out of space for building for oe.dev anyway |
| 11:06.26 | JaMa | removed oe.dev workdir already.. |
| 11:08.27 | GNUtoo|laptop | ok |
| 11:11.49 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 11:16.41 | *** join/#oe woglinde (~heinold@g225147142.adsl.alicedsl.de) |
| 11:38.28 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 11:40.21 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:10.06 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:21.02 | *** join/#oe valhalla (~valhalla@81-174-23-132.dynamic.ngi.it) |
| 12:35.20 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:39.20 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 12:52.26 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 12:59.44 | *** join/#oe mrAlmond (~gbergamo@82.193.2.131) |
| 13:00.13 | *** join/#oe timtimred (~meh@host86-179-43-121.range86-179.btcentralplus.com) |
| 13:00.20 | mrAlmond | Hi, I'm trying to compile valgrind using yocto for my ARM board but I get "ERROR: Nothing PROVIDES 'valgrind'" |
| 13:00.29 | mrAlmond | the recipe exists in recipe-devtools |
| 13:01.53 | *** join/#oe rsalveti (~rsalveti@201.82.65.93) |
| 13:01.53 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
| 13:02.07 | JaMa | mrAlmond: COMPATIBLE_HOST = '(i.86|x86_64).*-linux' |
| 13:02.24 | JaMa | mrAlmond: if you're building it for arm then you need newer version which supports arm (not yet in oe-core) |
| 13:02.30 | woglinde | yes valgrind dont work this good enough on arm |
| 13:02.33 | woglinde | maybee its changed |
| 13:02.35 | woglinde | find out |
| 13:02.50 | mrAlmond | 3.6.1 should support ARM |
| 13:03.05 | mrAlmond | yocto version is 3.6.0 |
| 13:03.12 | JaMa | ah 3.6* should support it |
| 13:03.29 | JaMa | so test it without COMPATIBLE_HOST and if it works, report with patch removing COMPATIBLE_HOST |
| 13:03.49 | mrAlmond | ok tnx!! |
| 13:04.22 | JaMa | there was discussion on oe-devel ML few months back.. strange that ther is also COMPATIBLE_HOST in oe.dev.. |
| 13:06.00 | mrAlmond | configure: error: Unsupported host architecture. Sorry |
| 13:06.15 | mrAlmond | so probably we need to integrate 3.6.1 |
| 13:06.25 | woglinde | mrAlmond yes go on |
| 13:06.56 | mrAlmond | from the valgrind site : 16 February 2011: valgrind-3.6.1, for X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, X86/Darwin and AMD64/Darwin (Mac OS X 10.5 and 10.6) is available. (release notes). |
| 13:07.19 | mrAlmond | I will try to integrate it |
| 13:12.12 | mrAlmond | why does valgrind depends on virtual/libx11 ? |
| 13:16.14 | Crofton | maybe it has a ui? |
| 13:16.35 | Crofton | look at the packaging, it is possible the x and non x parts get packaged seperately also |
| 13:16.46 | woglinde | alleyoop is a nice gui to valgrin |
| 13:16.48 | woglinde | d |
| 13:16.52 | woglinde | which uses qt I think |
| 13:16.56 | mrAlmond | Crofton : ok tnx |
| 13:17.30 | mrAlmond | uhm...checking for a supported CPU... no (arm) configure: error: Unsupported host architecture. Sorry |
| 13:17.42 | mrAlmond | looks like something here is wrong |
| 13:17.54 | mrAlmond | also with 3.6.1 |
| 13:18.16 | Crofton | urg do we have a var for /usr/etc ... |
| 13:19.10 | pb_ | don't think so |
| 13:19.20 | pb_ | iirc, /usr/etc isn't in FHS and no modern systems use it |
| 13:19.34 | Crofton | heh |
| 13:19.37 | woglinde | yeah |
| 13:19.45 | Crofton | gnuradio sticks some files in there |
| 13:19.47 | Crofton | stupid files |
| 13:19.48 | woglinde | <PROTECTED> |
| 13:20.03 | pb_ | ah. well, gnuradio should stop doing that. heh. |
| 13:20.20 | mrAlmond | looks like it supports armv7 but no "arm" |
| 13:20.27 | pb_ | if they're config files, they should go in /etc. if they're random data, they should go in /usr/share/gnuradio. |
| 13:20.51 | Crofton | yeah, for now ${prefix}/etc? |
| 13:20.57 | Crofton | I will bitch at upstream |
| 13:21.06 | pb_ | that would probably work |
| 13:23.53 | *** join/#oe cminyard (~cminyard@pool-173-57-155-71.dllstx.fios.verizon.net) |
| 13:24.56 | *** join/#oe B_Lizzard (~havoc@athedsl-427031.home.otenet.gr) |
| 13:27.01 | *** join/#oe kakashi__ (~kakashi@41.141.147.34) |
| 13:27.35 | ensc|w | why are the TUNE_CCARGS using '-mtune=' instead of '-mcpu='? |
| 13:29.09 | *** join/#oe lumag (~lumag@nat-rup.mentorg.com) |
| 13:31.09 | kakashi__ | hello , please i wanna to start learning about embedded system(General), but i dont know yet how to start. should i kearning electronic ?? or just programming language?? if yes what kind ?? |
| 13:31.16 | *** join/#oe galak (~galak@192.88.168.35) |
| 13:34.06 | ant_work | depends on you...about engineering the hw? about building it? about OS? about software? there are many fields of work needing different backgrounds |
| 13:34.44 | *** join/#oe lumag (~lumag@nat-rup.mentorg.com) |
| 13:34.53 | ant_work | ideally you would know it all :p |
| 13:36.29 | kakashi__ | hhh why not ? hehe |
| 13:37.13 | mrAlmond | ok valgrind 3.6.1 compiles for arm with a small stupid patch to configure.in |
| 13:37.20 | mrAlmond | I'm going to try it ;-) |
| 13:37.44 | *** join/#oe jayabharath (~jayabhara@nat/ti/x-uwcsimzhymdtzwlh) |
| 13:37.51 | kakashi__ | i think that i wanna to start embedded systems (linux) |
| 13:42.39 | *** join/#oe lumag (~lumag@nat-rup.mentorg.com) |
| 13:45.49 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 13:46.41 | woglinde | kakashi__ lot of people clai this |
| 13:46.43 | woglinde | claim |
| 13:46.58 | woglinde | mrAlmond hm oha |
| 13:46.59 | *** join/#oe sgw1 (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
| 13:48.13 | kakashi__ | so??? what do you advise me in this case??? i know programming on C and python and i use linux well. can you avise me something??? |
| 13:49.04 | woglinde | lol |
| 13:49.17 | woglinde | so you already learnded embedded linux |
| 13:50.12 | mrAlmond | kakashi__ start learn about cross compiling |
| 13:50.12 | woglinde | what should I advise |
| 13:50.23 | woglinde | got an embedded linux board |
| 13:50.33 | woglinde | and try to get it run |
| 13:50.33 | mrAlmond | like the beagle board |
| 13:50.41 | woglinde | mrAlmond he dont need |
| 13:50.46 | woglinde | he only need oe |
| 13:51.17 | mrAlmond | yes but knowing about cross compiling helps you in understanding how oe works |
| 13:51.32 | mrAlmond | and sometimes could save your a** ;-) |
| 13:54.15 | pb_ | morning kergoth |
| 13:55.30 | pb_ | ensc|w: presumably so that you can have -mtune= and -march= be different, which isn't a bad idea. -mcpu= is just a shorthand for the combination of those two flags so there is no advantage in using it, particularly. |
| 13:57.16 | kergoth | hey |
| 14:00.27 | ensc|w | pb_: -mcpu select the most aggressive optimization by allowing instructions which are available for this cpu only |
| 14:00.47 | ensc|w | but there can be different -march for a -mcpu |
| 14:01.14 | ensc|w | e.g. -mcpu=cortex-m3 allows -march=arm7-m and armv7-r (?) |
| 14:01.24 | pb_ | ensc|w: I'm not quite sure I understand what you're saying. but, -mcpu=foo is precisely equivalent to -mtune=foo -march=<arch of foo> |
| 14:01.41 | ensc|w | pb_: no |
| 14:02.07 | ensc|w | foo can have multiple archs |
| 14:02.46 | *** join/#oe Openfree^ (~Ofreer@124.78.152.213) |
| 14:02.53 | pb_ | not in gcc's model of the world. each cpu has exactly one arch, and for cortex-m3 it's 7M. |
| 14:03.09 | pb_ | see arm-cores.def |
| 14:05.11 | pb_ | oh, actually, it does look as though -mcpu= can have a few other side effects as well, for example -mcpu=cortexm3 enables -mfix-cortex-m3-ldrd but -mtune=cortex-m3 doesn't. |
| 14:05.43 | *** join/#oe devzero_ (devzero@xdsl-89-0-95-225.netcologne.de) |
| 14:08.35 | pb_ | but, apart from that, it doesn't seem as though there is any interesting difference. if you have an example of an optimisation that happens with -mcpu=cortex-m3 but not with -march=armv7-m -mtune=cortex-m3 then I'd be interested to see it. |
| 14:15.46 | mrAlmond | woglinde: I think I'm missing debuginfo in my rootfs : http://pastebin.com/Y84rUndX |
| 14:15.57 | mrAlmond | How can I install them? |
| 14:18.15 | *** join/#oe CosmicPenguin (~nobody@soa.codeaurora.org) |
| 14:18.55 | ensc|w | pb_: ah ok, I confused it with binutils where you can request special architecture extensions |
| 14:19.11 | ensc|w | nevertheless, -mcpu is a stronger optimization than -mtune |
| 14:19.30 | pb_ | it is stronger than -mtune alone, but no stronger than -mtune+-march (which is what oe currently uses) |
| 14:19.57 | pb_ | swapping the -mtune+-march for -mcpu would not make anything better (as far as I can tell) and would force the two things to match which is not always desirable |
| 14:23.20 | woglinde | mrAlmond install the -dbg packages |
| 14:23.40 | pb_ | for example, back in familiar 0.8 days we used to build with -march=armv4 -mtune=pxa255, and that combination doesn't correspond to any -mcpu setting. |
| 14:25.07 | mrAlmond | woglinde : tnx |
| 14:25.43 | *** join/#oe hbeck (~hbeck@69.41.94.155) |
| 14:34.20 | *** join/#oe timtimred (~meh@host86-181-251-156.range86-181.btcentralplus.com) |
| 15:40.13 | *** join/#oe ibot (~ibot@rikers.org) |
| 15:40.13 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Bugtracker: http://bugs.openembedded.org and http://tinderbox.openembedded.org for compile issues | Repository: git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro mirror | This is not a distro or machine support channel |
| 15:40.21 | khem | err to *not* default to thumb |
| 15:41.12 | lumag | khem: that seems a strange workaround. |
| 15:41.14 | khem | in the new tuning context armv5te has different semantics which is kind of confusing |
| 15:41.55 | lumag | khem: what about other boxes which also support thumb? |
| 15:42.01 | lumag | s/boxes/cores/ |
| 15:42.24 | lumag | And how would you select thumb if that's requested by machine/etc.? |
| 15:42.31 | khem | lumag: as strange it may look its only conveying to enable thumb feature |
| 15:42.38 | khem | not conveying that thumb is available |
| 15:42.55 | khem | thats a bit confusing |
| 15:43.20 | khem | since usually people when see armv5te would think ok core has thumb available |
| 15:43.36 | khem | but in the new tune stuff this means use thumb instruction set |
| 15:44.28 | lumag | Then probably we should drop all thumb setting in features and switch back to plain ARM_INSTRUCTION_SET handling. |
| 15:44.55 | lumag | As this question is not only limited to 926, armv5 and (e.g.) xscale. |
| 15:45.30 | khem | lumag: well its not bad only trouble is it matches a familiar term which has different meanin |
| 15:46.20 | khem | so you have to differentiate between armv5te in general context and armv5te in TUNE_FEATURES context |
| 15:46.29 | khem | may be thumb was not denoted by t |
| 15:47.44 | pb_ | khem: that would be a workaround, but it is clearly not a good solution |
| 15:48.13 | pb_ | arm926ejs is, as a matter of fact, an armv5te core and I think it is (at the very best) confusing if you have to avoid mentioning the "t" to not get everything built as thumb |
| 15:48.59 | khem | I agree |
| 15:49.06 | pb_ | and that doesn't fix the armv4/t issue, so we still need a real fix for that which would have to be done differently |
| 15:49.07 | khem | but thats how it is set as of now |
| 15:49.20 | pb_ | sure, but I think the current situation is just broken. |
| 15:49.42 | khem | yes I think these patches should have been toasted a bit |
| 15:49.46 | khem | before applying |
| 15:50.27 | khem | armv4 does not have thumb so we should be ok there right |
| 15:51.13 | pb_ | right, it's armv4t that is fundamentally busted |
| 15:51.14 | khem | lumag: I am testing these patches on nslu2be |
| 15:51.34 | khem | and using thumb mode |
| 15:51.36 | khem | lets see |
| 15:52.04 | lumag | khem: ok |
| 15:53.06 | ant_work | khem: I see you have a linux.inc in nslu2be (between other strange things). Should we fix it and have one in meta-oe? |
| 15:53.19 | ant_work | I'll send klibc for meta-oe later |
| 15:53.34 | lumag | khem: regarding armv5te/armv5e/thumb. Maybe it's better to introduce special hook NO_THUMB ?= "no", which can be set to yes by several packages. And then filter out -mthumb if it's set? |
| 15:53.56 | ant_work | khem ofc I meant in meta-nslu2 |
| 15:54.24 | khem | ant_work: yes I this should be updated havent done that |
| 15:54.34 | khem | ant_work: I will take patches |
| 15:55.22 | khem | lumag: I think filtering out thumb from TUNE_FEATURES in recipes is satisfactory |
| 15:57.13 | lumag | khem: I think it should be handled in some .conf/.bbclass, depending on variable sent in recipe. Is it what you mean? |
| 16:00.29 | khem | pb_: hmmm w.r.t. armv4t yeah I think in general how thumb is glued in is probably not right way |
| 16:00.54 | khem | pb_: thumb should not be tied to tune features here |
| 16:01.27 | khem | lumag: as I have done it in patch |
| 16:01.39 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 16:01.57 | khem | more I think about these arm tune files more broken they look |
| 16:01.59 | *** join/#oe lumag (~lumag@nat-rup.mentorg.com) |
| 16:03.48 | ant_work | maybe RP will pull a rabbit out of hat |
| 16:04.19 | ant_work | (don't see how) |
| 16:04.26 | *** join/#oe incandescant (~incandesc@134.134.137.73) |
| 16:04.31 | kergoth | heh, seems like that whole rework should have sat on a branch a bit longer |
| 16:04.45 | pb_ | sat somewhere, yeah |
| 16:05.26 | kergoth | <PROTECTED> |
| 16:05.26 | kergoth | <PROTECTED> |
| 16:05.26 | kergoth | <PROTECTED> |
| 16:05.29 | kergoth | anyone ever seen this one? |
| 16:05.41 | kergoth | the perl binary in the directory it was in is executable |
| 16:05.46 | kergoth | scratches head |
| 16:05.49 | khem | pb_: TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}" |
| 16:05.53 | khem | is the real problem |
| 16:06.31 | pb_ | well, yeah, maybe. I think that line is reasonable on its face, it's how thumb gets into ${TUNE_FEATURES} that is arguably bogus |
| 16:06.40 | khem | pb_: so we have to have another features called "usethumb" or something |
| 16:06.44 | khem | and check it as well |
| 16:07.02 | pb_ | to some extent it depends on what you define as "tuning". clearly bigendian and thumb are not "tune" flags in the conventional sense but the word seems to have been slightly repurposed here. |
| 16:07.06 | khem | then thumb would imply that core supports it and usethumb will imply we actually want to use it |
| 16:07.31 | khem | its configuration more than tuning imo |
| 16:08.03 | khem | right now we are not differentiating between having thumb and enabling it |
| 16:08.09 | pb_ | right |
| 16:08.23 | khem | we say if we have it just use t |
| 16:08.35 | pb_ | and, really, it's only armv4t where it matters. the rest is just configuration flipping. |
| 16:08.46 | khem | and I think usethumb should be a distro feature |
| 16:09.00 | pb_ | yes, it certainly needs to be under distro control |
| 16:09.10 | khem | pb_: well for armv5t we will still use armv5 for march |
| 16:09.16 | pb_ | right, but that doesn't matter |
| 16:09.25 | pb_ | -march=armv5 does allow bx and blx |
| 16:09.25 | khem | not much yes |
| 16:09.39 | lumag | does it? |
| 16:09.42 | khem | and interworking |
| 16:09.48 | lumag | and will it allow thumb code? |
| 16:09.52 | pb_ | lumag: no |
| 16:10.19 | pb_ | iirc, bx "works" but only for branching to arm code, it can't actually switch to thumb |
| 16:10.28 | khem | imo we should be able to use march=armv5te if we know core is armv5te |
| 16:10.31 | pb_ | but that's fine, it's enough to build interworking-capable binaruies |
| 16:10.35 | pb_ | s/uies/ies/ |
| 16:12.16 | pb_ | khem: yeah, though I don't think it makes any practical difference |
| 16:12.24 | lumag | But what about building thumb-default binaries? |
| 16:12.50 | lumag | I mean, I though if we have armv5te, we default to build thumb code by default, aren't we? |
| 16:12.59 | pb_ | Right now? Yes. |
| 16:15.21 | lumag | And if we default to armv5 for all armv5te we will default to arm code, weren't we? |
| 16:15.54 | pb_ | Yes. I don't quite see what you're trying to say, though. |
| 16:18.19 | *** join/#oe sgw (~sgw@71-20-17-213.war.clearwire-wmx.net) |
| 16:18.20 | lumag | pb_: Did I understood you correctly, that you proposed to make all armv5te cores to select -march=armv5? |
| 16:18.56 | pb_ | no, I don't think I was proposing that |
| 16:19.01 | *** join/#oe rob_w (~bob@ppp-93-104-9-90.dynamic.mnet-online.de) |
| 16:19.23 | pb_ | that would clearly be silly because it would make it impossible to use -mthumb even if you wanted to. |
| 16:19.53 | pb_ | I think I did say to khem that, if you weren't generating thumb code, there was no practical difference between -march=armv5 and -march=armv5t |
| 16:19.59 | lumag | pb_: then I'm sorry, I misunderstood you. |
| 16:20.06 | pb_ | (but note that armv5 and armv5e are not quite the same thing either) |
| 16:20.13 | ant_work | remebers the disappoint when taking first figures arm vs. thumb1 on limited devices |
| 16:20.31 | ant_work | at one point we moved to thumb |
| 16:20.51 | pb_ | what were you disappointed about? |
| 16:20.52 | ant_work | no real advantages on pxa25x |
| 16:21.06 | pb_ | oh, that's strange. on the openmoko units it was quite a win. |
| 16:21.07 | ant_work | slower benchmarks even |
| 16:21.13 | *** join/#oe jilles (jilles@unaffiliated/jilles) |
| 16:21.16 | ant_work | on zaurus / opie bench |
| 16:21.36 | ant_work | same disappoint uclibc vs. eglibc vs. glibc |
| 16:21.46 | ant_work | not that big differences |
| 16:21.52 | ant_work | in size |
| 16:22.11 | ant_work | sure, if you build monster-images it matters |
| 16:22.20 | pb_ | strange, I think you must be in some parallel universe |
| 16:22.20 | pb_ | heh |
| 16:22.44 | ant_work | no, talking about console-images or even initramfs, initially uclibc |
| 16:23.01 | ant_work | it was really more buzz than other on Zaurus |
| 16:23.21 | pb_ | let me see if I can find my gta01 thumb benchmarks again |
| 16:24.32 | ant_work | pb_: maybe I did the size comparison during the unfortunate debug overhaul (-g) |
| 16:24.44 | ant_work | couple of years ago |
| 16:25.01 | JaMa | khem: with your patch eglibc cannot find ./x86_64-linux/usr/bin/armv4t-oe-linux-gnueabi.gcc-cross-initial/arm-oe-linux-gnueabi-gcc |
| 16:25.15 | JaMa | khem: I guess it's looking in ./x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial |
| 16:26.06 | pb_ | <PROTECTED> |
| 16:27.02 | ant_work | pb, heh, corgi plugin, really starting on the bad foot :) |
| 16:27.17 | pb_ | I'm not sure if I had any newer results than that, those were the only ones I could immediately find in the archives. |
| 16:27.35 | pb_ | but, I certainly didn't find it significantly slower |
| 16:27.54 | pb_ | and I think a 12% size reduction is something I would count as an advantage |
| 16:30.40 | ant_work | I can find only this discussion offhand http://ibot.rikers.org/%23oe/20081201.html.gz |
| 16:30.52 | ant_work | about this savings, I found approx 10% for thumb and 30% for uclibc images (console-image even 50%) |
| 16:31.41 | ant_work | against glibc/arm |
| 16:31.56 | ant_work | so we are there: 10-12% |
| 16:32.24 | pb_ | yeah, sounds about right |
| 16:36.11 | *** join/#oe Heinervdm (~thomas@pD9E12ED7.dip.t-dialin.net) |
| 16:36.53 | ant_work | pb_: http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg02703.html |
| 16:45.28 | *** join/#oe pretec (~Matthias@port-92-195-131-229.dynamic.qsc.de) |
| 16:47.46 | ant_work | that's why I was disappointed |
| 16:51.49 | *** part/#oe vanner (~vanner@195.91.241.19) |
| 16:52.40 | *** join/#oe sgw (~sgw@71-20-17-213.war.clearwire-wmx.net) |
| 16:53.58 | khem | JaMa: yes that patch wont work |
| 16:54.38 | khem | JaMa: I am testing the patch you posted basically ARM_THUMB_M_OPT = "${@['-mthumb', '-mno-thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) != 'arm']}" |
| 16:55.07 | khem | so we dont have to worry about thumb1 or thumb2 |
| 16:57.28 | JaMa | khem: it looks like passing -mno-thumb everywhere :/ just checked expat/run.do_configure.. |
| 16:57.45 | lumag | khem: arm-angstrom-linux-gnueabi-gcc: No such file or directory during eglibc configuration |
| 16:58.00 | lumag | No. eglibc-initial |
| 16:58.16 | JaMa | lumag: that's what I reported on ML too |
| 16:58.39 | khem | lumag: yeah that patch wont work |
| 16:59.24 | khem | hrm I have those inverted |
| 16:59.26 | JaMa | does armv4t override still work? |
| 16:59.33 | JaMa | PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb" |
| 17:00.11 | fray | I'm back BTW.. I'm trying to catch up with things now |
| 17:00.18 | ant_work | keep on |
| 17:00.21 | ant_work | bbl |
| 17:02.43 | JaMa | khem: btw in your patch you're appending twice to TUNE_CCARGS :) |
| 17:06.16 | khem | JaMa: that patch is bogus |
| 17:06.54 | JaMa | and _armv4t override no longer works :/ |
| 17:06.58 | khem | fray: arm tuning neds some attentions |
| 17:07.13 | khem | it had done multiple fractures for arm |
| 17:07.28 | khem | I am currently testing few patches which address some of the issues |
| 17:07.32 | khem | but may not be all |
| 17:08.02 | khem | fray: currently it has to differentiate between having thumb and using it |
| 17:09.01 | fray | yes.. |
| 17:09.19 | fray | It's ARM and no interworking (capable).. ARM and interworking capable and ARM & Thumb are the three combinations right? |
| 17:10.59 | lumag | BTW: if I try to login to patchwork, it says that my account is inactive. How should I fix that? |
| 17:14.28 | lumag | khem, JaMa : eglibc-initial still fails here even after your patch |
| 17:15.04 | JaMa | lumag: khem's or mine? |
| 17:15.46 | lumag | It tried to build eglibc-initial in the work/armv5e-angstrom-linux-gnueabi dir (note the lack of t). Is that expected? |
| 17:16.02 | lumag | JaMa, both :) You've sent identical patches IIUC. |
| 17:16.05 | khem | JaMa: your patch is ok I would have compared != arm |
| 17:16.14 | khem | lumag: mine is wrong |
| 17:16.15 | JaMa | lumag: hmm you still have old khem's old patch? |
| 17:16.35 | khem | lumag: pop out the old patch yet |
| 17:16.38 | JaMa | lumag: you need only 8867 |
| 17:17.07 | lumag | So I should drop 8861? |
| 17:17.07 | JaMa | lumag: and be aware of my reply there.. |
| 17:17.30 | JaMa | lumag: yes, you have to drop 8861 |
| 17:18.26 | lumag | JaMa, Ok, will try. |
| 17:19.44 | *** join/#oe joelagnel (~joel@nat/ti/x-bbnrdihctrayuwsx) |
| 17:21.50 | *** join/#oe sgw (~sgw@71-20-17-213.war.clearwire-wmx.net) |
| 17:32.42 | *** join/#oe denix0 (~denix@pool-108-18-140-4.washdc.fios.verizon.net) |
| 17:39.50 | kergoth | er.. what the hell is the point of OECMAKE_BUILDPATH. it looks like a lame reimplementation of ${B} |
| 17:40.01 | Crofton|work | hmm |
| 17:40.07 | Crofton|work | I use that |
| 17:40.18 | kergoth | B already exists as the way to differentiate between build and source dirs |
| 17:40.36 | kergoth | not often used, but its there, and the cd will be done for you as it's listed in the dirs flag of the tasks |
| 17:40.47 | kergoth | iirc, anyway |
| 17:40.49 | Crofton|work | kergoth, naext time I play with a cmake recipe, I'll try setting OECMAKE_BUILDPATH to B |
| 17:40.58 | kergoth | cool |
| 17:41.01 | *** join/#oe kobe_ (b274a561@gateway/web/freenode/ip.178.116.165.97) |
| 17:41.22 | kergoth | at one point i was trying to default enabling use of separate B for autotools recipes.. i should poke at that again |
| 17:41.38 | kergoth | there's some hiccups with recipes that alter the sources with sed, etc and don't operate against ${S} directly.. |
| 17:41.49 | kergoth | one of these days |
| 17:42.15 | kobe_ | does anybody know of an OpenEmbedded-based distribution that uses X.org, Qt and OpenGL on x86 machines? |
| 17:43.27 | kergoth | okay,this is weird. i have a perl do_install failure that occurs every time i run the task, but if i drop into a devshell and source the run script, it succeeds |
| 17:43.31 | kergoth | wipes and tries again |
| 17:58.16 | khem | kobe_: look around in angstrom |
| 17:58.29 | khem | kobe_: all those bits can be put together in an image for sure |
| 17:58.45 | khem | qte4-x11-image or something |
| 18:03.51 | Tartarus | kergoth: fwiw, I think some of the OECMAKE_BUILDPATH stuff being lame is because cmake is kinda lame :( |
| 18:04.09 | kergoth | Tartarus: perhaps, but afaict all it does is a cd in configure/compile, same thing B does |
| 18:04.11 | kergoth | shrugs, will see |
| 18:04.16 | kergoth | hmm |
| 18:04.30 | kergoth | this perl thing is reliable. fails every time in do_install, works every time from devshell |
| 18:04.33 | *** join/#oe pepermint (~pepermint@host35-89-dynamic.5-87-r.retail.telecomitalia.it) |
| 18:04.52 | Tartarus | yeah, I just don't know if it's an always obeyed kind of thing |
| 18:04.55 | kergoth | the odd thing is re-running do_install from bitbake keeps failing, its not a race |
| 18:05.00 | lumag | gtg now, bye! |
| 18:05.07 | kergoth | must be something different contextually between the two |
| 18:05.08 | kergoth | hmm |
| 18:06.32 | lumag_afk | khem: eglibc compiled on xscale (armv5te) |
| 18:06.36 | kergoth | can't be pseudo, its handled the same for all tasks.. |
| 18:06.37 | kergoth | hmm |
| 18:06.54 | khem | lumag_afk: cool |
| 18:17.57 | *** join/#oe timtimred (~meh@host86-181-254-13.range86-181.btcentralplus.com) |
| 18:22.14 | *** join/#oe nschle85 (~nschle85@m83-187-200-199.cust.tele2.ee) |
| 18:36.15 | joelagnel | Will doing a bitbake -c configure -f for a recipe also invalidate compile and install stages so that they're redone next time I bitbake? |
| 18:37.10 | joelagnel | yes it would |
| 18:40.16 | *** join/#oe kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 18:43.16 | kobe_ | ok, thanks |
| 18:59.04 | Crofton | mickeyl, ping |
| 18:59.08 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 19:15.19 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 19:15.32 | mickeyl | Crofton: pong |
| 19:15.40 | mickeyl | Crofton: shall we make our ad-hoc meeting now?= |
| 19:16.21 | Crofton | Maybe should wait until next week, no sign of florian |
| 19:16.30 | mickeyl | hmm, ok. |
| 19:16.31 | Crofton | I need to run out also |
| 19:16.35 | mickeyl | k |
| 19:25.05 | *** join/#oe nitink (~nitink@nat/intel/x-whjrcztswsmghrup) |
| 19:35.11 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 19:35.24 | joelagnel | What's the easiest way for me to install the output (binaries) of a recipe to a root-fs without having to opkg install the many ipk packages it generates? |
| 19:36.05 | Tartarus | well, that's pretty darn easy |
| 19:36.11 | joelagnel | Would rsync'ing the contents of work/../image be ok ? :) |
| 19:36.11 | Tartarus | but, ipk can be extracted w/ ar -x |
| 19:36.16 | Tartarus | or whatever the dpkg unpack tool is |
| 19:36.26 | Tartarus | ok for what? |
| 19:36.34 | Tartarus | images are created w/ a 'fake root' method |
| 19:36.35 | joelagnel | s/ok/correct |
| 19:36.41 | Tartarus | so you can't use them on the target |
| 19:36.46 | Tartarus | as perms will be all wrong |
| 19:36.52 | joelagnel | recipe generates too many ipks |
| 19:37.11 | Tartarus | why do you say that? |
| 19:37.16 | Tartarus | many ipks are good |
| 19:37.22 | Tartarus | it means fine grained control on the target |
| 19:37.47 | joelagnel | I might be missing something here, but is it harder to opkg install alot of ipks individually |
| 19:37.58 | joelagnel | *isnt |
| 19:39.36 | Tartarus | Well, it's optional bits in the other packages |
| 19:39.53 | Tartarus | Can you step back and describe the high level problem you're trying to solve, please? |
| 19:40.05 | joelagnel | sure |
| 19:40.45 | joelagnel | Let me take an example, there's a recipe for example 'gst-plugins-good_0.10.28.bb' |
| 19:41.00 | joelagnel | and rebuilding it generates a lot of "gst-plugin-*" recipe |
| 19:41.00 | kergoth | joelagnel: why would you want to install all the ipks from a recipe? you really need development files, debugging, documentation.. it makes no sense |
| 19:41.12 | kergoth | does it not also emit a virtual package which depends on all of those? |
| 19:41.13 | joelagnel | kergoth, for quick testing |
| 19:41.14 | kergoth | most such recipes do |
| 19:42.07 | joelagnel | kergoth, what is it called typically |
| 19:42.22 | kergoth | that depends on the recipe |
| 19:43.06 | kergoth | I'm just not seeing the use case here. If you're testing things specifically, then you kn ow what you're testing. If you aren't, you don't need them all. |
| 19:44.13 | joelagnel | kergoth, ok I describe my usecase |
| 19:44.44 | joelagnel | I upgraded libv4l2 and rebuilt it, now I need to rebuild and install all dependent gstreamer plugins |
| 19:45.30 | joelagnel | rebuilding is fine, but I was thinking of an easier way to install them all at once onto my root filesystem |
| 19:45.36 | joelagnel | does that make sense? |
| 19:47.45 | joelagnel | (hope it does) |
| 19:49.26 | kergoth | still not seeing why you need to install them all. wouldn't you just need to install the ones you already have installed? |
| 19:49.35 | kergoth | in which case a shell script + opkg list is your friend |
| 19:52.44 | joelagnel | kergoth, sure that seems reasonable |
| 19:53.15 | kergoth | shrugs |
| 19:56.13 | *** join/#oe pretec (~Matthias@port-92-195-131-229.dynamic.qsc.de) |
| 20:00.23 | *** join/#oe pb_ (~pb@mail.pbcl.net) |
| 20:00.29 | woglinde | re pb |
| 20:13.07 | khem | pb_: hmmm so now we have the image creation problemyou commented on that |
| 20:14.01 | khem | Unknown package 'opkg'. |
| 20:15.23 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:20.17 | *** join/#oe pretec (~Matthias@port-92-195-131-229.dynamic.qsc.de) |
| 20:24.45 | pb_ | khem: oh, hm. I haven't heard of that exact failure. |
| 20:24.48 | pb_ | hi woglinde |
| 20:26.25 | *** join/#oe lumag (~lumag@ppp89-110-1-250.pppoe.avangarddsl.ru) |
| 20:26.47 | lumag | Hello |
| 20:27.13 | pb_ | hi lumag |
| 20:28.09 | joelagnel | I got it to work now, thanks all for help |
| 20:30.56 | woglinde | joelangel what? |
| 20:31.14 | lumag | Hmmm. Why eglibc builds packages for armv5te (in my case) but installs data in machine sysroot? |
| 20:32.47 | lumag | If it's by design or it's again some misbehaviour? |
| 20:32.53 | *** join/#oe ant__ (~andrea@host192-250-dynamic.1-79-r.retail.telecomitalia.it) |
| 20:33.23 | khem | lumag: sysroot is denoted using machine-libc |
| 20:33.34 | khem | lumag: that should be fine |
| 20:35.32 | lumag | I quite don't get it. I'm building a eglibc package which is not machine specific. It builds lots of arch packages. Then why populate machine sysroot? Won't it be logical to populate arch sysroot? |
| 20:36.01 | khem | lumag: actually there is one sysroot per machine |
| 20:36.16 | khem | and common packages will get populated from sstate |
| 20:36.35 | khem | so if you were to say have two machines which both have xscale |
| 20:36.56 | khem | then it would build the packages once and populate them into two sysroots |
| 20:37.09 | khem | machA and machB |
| 20:37.29 | khem | but they will be built only once |
| 20:37.58 | lumag | Hmm. I remember that when I asked to build packages first for tosa and then for c7x0, eglibc (and some other packages) were rebuilt. |
| 20:38.05 | lumag | I'll retry this now just to be sure. |
| 20:38.21 | khem | if they are common at arch level they should not be rebuilt |
| 20:38.28 | khem | but if they have machine specific stuff |
| 20:38.31 | khem | then they will be |
| 20:38.47 | *** join/#oe hufnus (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:39.54 | ant__ | lumag: in oe-dev only collie was needing toolchain rebuild. this is expected behavior I'd say |
| 20:40.26 | lumag | ant__: that's logical, as collie is armv4 |
| 20:40.46 | ant__ | yes, when I built for the pxa devices same toolchain was used |
| 20:41.18 | *** join/#oe hufnus (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:41.38 | ant__ | ahem.. is there any floating patch for eglibc in the meantime? |
| 20:41.49 | khem | ant__: yes there are |
| 20:42.20 | *** join/#oe hufnus (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:42.22 | ant__ | reading ML |
| 20:42.59 | *** join/#oe hufnus (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 20:52.38 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 20:55.01 | lumag | That's strange. I asked OE to build eglibc for c7x0 and it actually recompiled something. At least I saw it rebuilding eglibc and gcc at least |
| 20:56.50 | lumag | I had eglibc built for tosa. And now I asked bitbake to build eglibc for c7x0. And I actually see it rebuilding gcc-cross-initial now. |
| 20:59.00 | lumag | eglibc indeed seems to be unpacked from sstate. |
| 21:03.20 | *** join/#oe galak (~galak@192.88.168.35) |
| 21:14.25 | lumag | but gcc was rebuilt |
| 21:21.31 | khem | lumag: c7x0 is xscale ? |
| 21:21.53 | ant__ | yes, pxa25x |
| 21:23.04 | khem | where is .conf file for machine |
| 21:23.09 | khem | in layers |
| 21:23.16 | ant__ | meta-zaurus |
| 21:23.32 | ant__ | in meta-smartphones |
| 21:25.44 | khem | lumag: so its xscale le ? |
| 21:27.16 | lumag | khem: yes. Both are pxa25x xscale le |
| 21:27.29 | lumag | khem: otherwise I won't use them for this testing. |
| 21:27.35 | khem | lumag: then they should be able to share the toolchain |
| 21:28.29 | khem | it does checksumming and if it sees differences it might rebuild but generally it should not |
| 21:28.39 | *** join/#oe hillct (~hillct@cpe-174-109-192-021.nc.res.rr.com) |
| 21:28.58 | khem | lumag: btw. oe-core should be buildable for arm now |
| 21:29.27 | woglinde | *g* |
| 21:29.31 | khem | this is cobblework we have to fix the tune for arm once again |
| 21:30.13 | ant__ | I've launched a rebuild with the last patches |
| 21:33.32 | *** join/#oe GNUtoo|laptop (~gnutoo@host186-56-dynamic.180-80-r.retail.telecomitalia.it) |
| 21:39.23 | lumag | khem: thanks. BTW: why does your patch for features-arm-thumb adjust TUNE_CCARGS twice? |
| 21:39.54 | khem | lumag: that patch was bogus |
| 21:40.15 | lumag | khem. oops. interpreted diff in the wrong way. |
| 21:40.25 | lumag | sorry |
| 21:41.18 | lumag | btw: i still see no patch for the intltool for perl (command line too long in virtclass-native case). |
| 21:41.40 | lumag | Ah. It wasn't submitted to oe-core ML. |
| 21:44.36 | fray | for the thumb stuff on arm.. please see the emails I an Phil Blundell sent today |
| 21:57.23 | *** join/#oe Artox (~Artox@pD957CE9F.dip.t-dialin.net) |
| 21:57.57 | ant__ | JaMa|Off: ping |
| 22:01.41 | *** join/#oe kristoffer (~kristoffe@c-b5d8e555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 22:10.05 | ant__ | khem: util now build is fine. armv5te everywhere |
| 22:10.11 | lumag | khem: something seem wrong here. I've built eglibc for tosa, then built eglibc for c7x0. Now I asked to build gcc for tosa and bitbake started rebuilding eglibc again! |
| 22:10.30 | ant__ | heh |
| 22:11.03 | ant__ | btw I've targeted poodle to mix up the dogs a bit :) |
| 22:11.16 | khem | lumag: hmm rm_work ? |
| 22:11.48 | lumag | khem: yes. Angstrom setup-scripts. Does it mess things? |
| 22:12.25 | khem | lumag: it did in the past but I thought we fixed it |
| 22:12.34 | *** join/#oe gkwhc (~me@unaffiliated/gkwhc) |
| 22:12.38 | *** part/#oe gkwhc (~me@unaffiliated/gkwhc) |
| 22:13.03 | lumag | fray: in your mail does 'interworking-capable chips' cover plain armv4 (no thumb) scripts |
| 22:13.10 | lumag | ? |
| 22:13.32 | lumag | khem: I can try checking things w/o rm_work, but later. |
| 22:14.08 | lumag | I'll probably have to do a full rebuild, or just disabling rm_work will do the trick? |
| 22:14.40 | fray | the Phil's response covers that and I responded back about supporting non-thumb compatible armv4's.. |
| 22:14.45 | fray | are there any new ones being built? |
| 22:15.00 | ant__ | lumag: here arm-angstrom-linux-gnueabi-gcc -march=armv5te -mno-thumb -mthumb-interwork -mtune=xscale -mthumb-interwork -mno-thumb --sysroot= |
| 22:15.09 | ant__ | as you said |
| 22:15.18 | *** join/#oe egonzalez_ergio (~emiliano@190.49.58.129) |
| 22:15.23 | lumag | ok |
| 22:15.41 | ant__ | twice |
| 22:15.50 | fray | if there are no new designs on armv4 (no thumb capable).. then does oe-core need to support them? (I lean toward no).. current oe does.. any a distro based on oe-core can add their own tunings that don't have thumb interworking and such for non-armv4 thumb cpus.. |
| 22:16.05 | ant__ | lumag, that was eglibc |
| 22:16.07 | fray | to me it all comes down to build/support expectations and costs of maintenance |
| 22:16.21 | khem | fray: there are lot of oe-users who use strongARM based systems |
| 22:16.35 | *** part/#oe egonzalez_ergio (~emiliano@190.49.58.129) |
| 22:16.51 | khem | fray and many of them are oe developers |
| 22:16.55 | fray | yes.. but do we need a strong arm tune in oe-core, or can it be external -- or will those users want to stay on the OE they're already using? |
| 22:17.19 | fray | even meta-oe can have a strong-arm tune.. its oe-core I'm concerned with |
| 22:17.24 | khem | I dont mind where it stays as long as oe-core facilitate it |
| 22:17.44 | khem | ideally its better suited in oe-core |
| 22:17.51 | khem | since its a core piece |
| 22:17.53 | lumag | fray: I don't say that one should support _everything_, but supporting StrongARM seems logical to me. That's still one of the 'lowest common' platforms in use. |
| 22:17.56 | fray | I don't know why it can't be facilitated in oe-core -- but actually having non-thumb iterwork in oe-core is where I'm concerned |
| 22:18.29 | fray | lumag, in my world (mostly commerical products) we havn't seen strongarm in many years.. the "oldest" designs are 920t based |
| 22:18.50 | fray | the occasionaly 920t seems to still crop up.. but it's about 1 or 2 a year.. |
| 22:19.19 | fray | thats why I question the need (in oe-core, not in distributions based on oe-core) for strongarm and other non-interwork compatible chips |
| 22:19.24 | ant__ | khem: here eglibc did build |
| 22:19.26 | khem | fray: as I said |
| 22:21.03 | khem | there are people who have feeds build on oe for these devices |
| 22:21.04 | lumag | fray: there are no real non-interwork compatible chips, I think. |
| 22:21.21 | khem | new products no |
| 22:21.27 | fray | but oe, as a distribution is oe-core + meta-oe |
| 22:21.32 | ant__ | lumag: you're working on a collie (strongarm) qemu emulation, isn't? |
| 22:21.39 | fray | oe-core is a "distribution-less" base (self contained though) |
| 22:22.34 | lumag | ant__, kind of. I provided basic support for StrongARM cores (some coproc instructions not finished yet) and basic device set to get kernel to boot till "Can't mount root". |
| 22:22.37 | khem | fray the tune logic is ok largely |
| 22:22.45 | khem | we can tweak it for armv4 and armv4t |
| 22:22.48 | khem | a bit |
| 22:23.18 | ant__ | hm..khem... eglibc did build but failed do_install... lemme see |
| 22:23.22 | fray | so what I would expect at this point is something like armv4t and armv4t_thumb (tune names)..... |
| 22:23.33 | fray | the _thumb one would enable thumb instructions by default |
| 22:23.37 | khem | fray: yes |
| 22:23.47 | fray | they both would honor the arm_instruction_set as an override.. |
| 22:23.55 | lumag | ant__, when I'll build the rootfs, I'll try to implement more devices/etc. |
| 22:23.56 | khem | although I am not totally conviced by identifying thumb |
| 22:24.00 | khem | in packages |
| 22:24.03 | fray | I prefer that the output pkgarch though be identifiable |
| 22:24.05 | khem | since they can be so mixed |
| 22:24.28 | fray | I just havn't seen the code mixed in packages.. hand optimized applications -- sure.. just not recipe/packages level |
| 22:24.30 | khem | fray there are static libs which are in ARM and they link into some binary which is thumb |
| 22:24.36 | khem | what would oyu call it ? |
| 22:24.51 | khem | eglibc is build arm |
| 22:24.55 | fray | khem, well recent changes to the system have made it that you'll be able to build w/o any static libs.. :P |
| 22:24.57 | khem | libgcc is built arm |
| 22:25.00 | *** join/#oe gurumelo (~mari@unaffiliated/gurumelo) |
| 22:25.02 | khem | libgcc.a goes into everything |
| 22:25.16 | khem | you cant avoid libgcc.a |
| 22:25.20 | fray | yes.. but whats the default on the system? |
| 22:25.24 | khem | with latest gcc |
| 22:25.30 | ant__ | argh.. why do I get linux-3.0+3.1rc-h ?? |
| 22:25.39 | khem | so having thumb in package names is misnomer\ |
| 22:26.51 | khem | fray: people might think its completely thumb code which wont be true |
| 22:27.27 | fray | the -recipe- is thumb code.. |
| 22:27.34 | fray | the executables are mostly (if not all thumb).. |
| 22:27.41 | khem | packages arent recipes |
| 22:27.48 | fray | recipes -> packages |
| 22:28.06 | ant__ | khem: eglibc is sane, some other issue pulls now linux 3.0 iun my build... |
| 22:28.15 | khem | how so ? when they link a static lib which is arm |
| 22:28.28 | ant__ | ERROR: Task 612 (/oe/setup-scripts/sources/meta-texasinstruments/recipes-kernel/linux/linux_3.1.bb, do_fetch) failed with exit code '1' |
| 22:28.35 | fray | why are the static lib arm? |
| 22:28.51 | fray | (other then libgcc and libc.a) why are we linking static libs |
| 22:29.00 | khem | libgcc can not be built thumb e.g. |
| 22:29.06 | khem | it has catch 22 |
| 22:29.20 | khem | where gcc ask for a ligbcc function |
| 22:29.26 | khem | when building libgcc |
| 22:29.32 | fray | then there is no way to build a "different" armv4_thumb binary.. |
| 22:29.58 | fray | point is I want information in the arch to tell me what the thing is I'm looking at, so I can make smart decisions based on it |
| 22:30.14 | khem | I understand that |
| 22:30.15 | fray | so if libgcc can't ever be thumb.. then it won't matter,, |
| 22:30.42 | fray | libc_shared.a (I think thats the libc chunk) can be compiled thumb in some circumstances.. this is the only outlier that I know of |
| 22:30.51 | fray | other static libs become distro specific.. I'm not worried about those.. |
| 22:31.17 | lumag | hmmm. klibc? |
| 22:32.01 | fray | each libc is different for this.. |
| 22:32.15 | khem | fray lets have armv4 armv4t_thumb armv4t armv5 armv5_thumb and so on |
| 22:32.49 | fray | so we're in general agreement at least on the names and interworking is enabled in all cases (except armv4) |
| 22:32.51 | khem | so 't' remains with the arm arch as it is and packageness is denoted with _thumb |
| 22:33.01 | khem | yeah |
| 22:34.15 | khem | or may be armv4t_t1 |
| 22:34.39 | khem | and armv7_t2 armv7_t1 armv7 |
| 22:35.00 | fray | AFAIK, nobody would every do an armv7_t1 |
| 22:35.11 | khem | althogh I would have preferred a single letter |
| 22:35.29 | khem | like t e h etc |
| 22:35.40 | khem | armv4tt |
| 22:35.56 | khem | doesnt sound bad just like a typo |
| 22:36.58 | ant__ | khem: somehow the TI kernel recipe spreads everywhere even with DEFAULT_PREFERENCE = "-99". Lacks COMPATIBLE_MACHINE = "(beagleboard)" |
| 22:37.20 | ant__ | linux_3.1.bb |
| 22:37.33 | khem | ant__: you have to lock kernel for your machine |
| 22:37.47 | khem | then it wont hit you |
| 22:38.57 | ant__ | I see, I guess the recipe was not intended to behave like that, anyway |
| 22:39.36 | *** join/#oe Artox (~Artox@pD957CE9F.dip.t-dialin.net) |
| 22:39.38 | *** join/#oe phdeswer (~philippe@a83-245-252-47.elisa-laajakaista.fi) |
| 22:40.33 | ant__ | from the scroll: WARNING: For recipe libgcc, the following files were installed but not shipped in any package: |
| 22:40.33 | ant__ | WARNING: /usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a |
| 22:41.38 | khem | that should be rm -rf'ed |
| 22:42.01 | Artox | mhm |
| 22:43.05 | fray | anyway, I'll work on a revised ARM set.. but I'm not yet sure when I'll get to it.. :( |
| 22:44.00 | khem | fray: I think what we have right now is workable so there is some respite |
| 22:44.24 | fray | ok |
| 22:44.49 | *** join/#oe sgw (~sgw@71-20-17-213.war.clearwire-wmx.net) |
| 22:47.22 | lumag | ant__, did you understand, how to disable ti linux? |
| 22:48.32 | ant__ | yes, set compatible_machine |
| 22:48.42 | ant__ | like in linux_3.0.bb |
| 22:49.27 | lumag | Thanks. However I can't understand, why it's selected despite DEFAULT_PREFERENCE being -99 |
| 22:49.50 | ant__ | he |
| 22:50.08 | khem | because its the highest version I guess |
| 22:50.35 | khem | for your virtual/kernel |
| 22:50.37 | ant__ | hm..should have happened with e.g. linux_git thgen |
| 22:51.03 | lumag | So it will be supported for beagle no matter of DEF_PREF? That's strange. |
| 22:51.49 | lumag | s/supported/selected/ |
| 22:59.21 | ant__ | DEFAULT_PREFERENCE in the recipe has lower priority than PREFERRED_VERSION |
| 22:59.44 | ant__ | at least, it was like that |
| 23:01.00 | ant__ | lumag: anyway, within a couple of weeks and we'll have the missing 3.1 defconfigs ;) |
| 23:01.53 | ant__ | after do_savedefconfig I don't expect many changes btw 2.6.39 and 3.1 |
| 23:03.35 | lumag | ant__, that still doesn't tell me why that recipe was selected. |
| 23:04.13 | ant__ | the issue iare the layers |
| 23:04.29 | ant__ | you have to imagine it flattened |
| 23:04.52 | ant__ | but yes, default preference case is strange |
| 23:05.08 | ant__ | w/out setting pref. vers. |
| 23:06.16 | ant__ | in the past there was a note about the many virtual/kernel providers when we still had 2.4 cruft |
| 23:06.38 | ant__ | now it doesn't see any conflict, it's all 'linux' |
| 23:07.27 | lumag | in the past I disliked having preferred_version for linux/u-boot, as chaging versions there would mean long reparsing of all recipes |
| 23:11.58 | ant__ | true |
| 23:12.41 | ant__ | well, I see lot of warnings unpackaged file scrolling... :/ |
| 23:13.07 | ant__ | this is console-image (Angstrom) |
| 23:14.19 | ant__ | 0ur QA task-force will take care |
| 23:16.14 | lumag | I remember from some university course, that QA errors either are fatal, or are ignored. |
| 23:16.32 | ant__ | ^_^ |
| 23:17.53 | ant__ | glib2, gtk+, ... |
| 23:22.48 | ant__ | avahi |
| 23:42.27 | *** join/#oe bluelightning (~paul@cpc9-lewi14-2-0-cust183.2-4.cable.virginmedia.com) |
| 23:42.27 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 23:42.57 | *** join/#oe egonzalez_ergio (~emiliano@190.49.58.129) |
| 23:49.24 | ant__ | lumag: rebuilding now poodle->c7x0 |
| 23:49.32 | lumag | ant__, :) |
| 23:49.43 | ant__ | I'm logging to see what rebuilds |
| 23:50.07 | *** join/#oe Artox_ (~Artox@pD957DCCB.dip.t-dialin.net) |
| 23:56.34 | ant__ | wow, anything is getting rebuilt for the moment |
| 23:59.07 | ant__ | only machine-specific |