**** BEGIN LOGGING AT Fri Dec 09 02:59:58 2011 Dec 09 07:05:36 gm Dec 09 07:07:12 morning Dec 09 07:23:47 gm Dec 09 07:29:35 likewise: morning Dec 09 07:56:55 on 11.10 I've installed Psyco both through apt and easy_install, but bitbake still insists I do not have it Dec 09 07:56:58 good morning :) Dec 09 07:58:46 good morning Dec 09 08:05:50 morning! Dec 09 08:46:29 mornin Dec 09 09:10:24 hi khem Dec 09 09:16:46 good morning Dec 09 09:16:48 hi GNUtoo Dec 09 09:21:43 ericben, hi Dec 09 09:29:55 JaMa|Wrk, I've got a lot of it: http://gnutoo.homelinux.org/downloads/people/khem/serial_gcc.txt Dec 09 09:30:15 sounds like a toolchain alignement issue Dec 09 09:31:12 so I'll wait for khem Dec 09 09:56:43 morning all Dec 09 09:56:52 hi bluelightning Dec 09 09:56:59 ao2: hi, thanks for your fixes, will apply them over lunchtime Dec 09 09:58:26 hi bluelightning Dec 09 09:58:33 hi ant_work Dec 09 09:58:39 will apply yours also :) Dec 09 09:59:16 about EXTRA_IMAGECMD, a quick grep revealed ipaq's need some minor fixes Dec 09 09:59:50 if you mind I can send a patch but cannot test Dec 09 10:00:13 bluelightning, thanks Dec 09 11:39:01 how can I change the version of xserver-xorg? I already tryed PREFFERED_VERSION_virtual/xserver and PREFFERED_VERSION_xserver-xorg, version didn't change.. Dec 09 11:46:58 Oh, everything's okay. I make a typo :) Dec 09 12:15:14 GNUtoo: gm Dec 09 12:15:38 GNUtoo: for imx53, you base on angstrom or another distro (to test with)? Dec 09 12:16:01 reisei: let me guess, one F, double R? Dec 09 12:21:06 likewise: you're right Dec 09 12:26:02 Hi everyone Dec 09 12:26:27 I try to build fuse Dec 09 12:26:49 I had compiled it successfully this morning Dec 09 12:27:04 but now it is stuck when it runs fetch command Dec 09 12:27:32 It does not do anything and suspended like waiting an other task Dec 09 12:27:36 like deadlock Dec 09 12:28:11 do you have any idea what it can be cause or any idea how I can debug this case? Dec 09 12:46:33 pumpd tries to renew dhcp lease when I have configured a static ip, with the result that pumpd/avahi gives me a brand new, unwanted dhcp address. anyone seen/heard of this issue before? Dec 09 12:53:33 likewise, angstrom yes Dec 09 12:54:47 GNUtoo: with meta-openembedded layer also? Dec 09 12:55:35 likewise, I don't have the hardware yet tough Dec 09 12:55:55 but last summer we had that for imx51, and below Dec 09 12:56:01 and yes with meta-openembedded Dec 09 12:56:21 I think I also did stuff with the 53 Dec 09 12:56:32 trying to port it to eukrea stuff Dec 09 13:00:16 are there better dhcp clients than pump in oe? Dec 09 13:03:25 03Steffen Sledz  07org.openembedded.dev * r5cd6db7b2f 10openembedded.git/recipes/live555/ (live555_20110314.bb live555_20111120.bb): Dec 09 13:03:25 live555: replace version 20110314 with 20111120 Dec 09 13:03:25 Signed-off-by: Steffen Sledz Dec 09 13:24:42 is there a telnetd in oe-core ? Dec 09 13:30:26 pwgen: in busybox Dec 09 13:30:30 iirc Dec 09 13:53:40 bluelightning, now I can propose my experiment with "mr": http://ao2.it/tmp/oe-ezx-build/README.asciidoc Dec 09 13:56:35 with "mr bootstrap" I get all the pieces needed (layers, bitbake, local.conf and bblayers.conf) and I can start building right away. As aI said I don't really know the alternatives, but this already looks like a very clean approach to me. Dec 09 13:56:51 and .mrconfig is kept under revision control too Dec 09 14:04:34 I just want you all to know the people that wrote boost should never be allowed to chose a build system ever again Dec 09 14:07:02 ah they changed again? Dec 09 14:07:05 lol ouch Dec 09 14:08:21 Crofton :))) Dec 09 14:11:16 I'm trying to find where the build options are docuemented Dec 09 14:11:38 so I can try and avoid depending on icu or whatever is needed with the current build Dec 09 14:12:43 ao2: probably worth posting about it to the mailing list I guess... it looks pretty neat Dec 09 14:13:47 I'm not yet sure whether it offers advantages over other alternatives either though Dec 09 14:14:18 Crofton: so it's not jam anymore but some other crap? I liked the story about the nightmare in the OE boost recipe so much :) Dec 09 14:14:29 although mr looks like it can handle more than just git Dec 09 14:14:31 yeah, the coments in the recipe are classic Dec 09 14:14:34 also, still jam Dec 09 14:14:39 well bjam Dec 09 14:15:13 khem, hi, I've serious toolchain issues: all kernel built with the toolchain that is in SHR have that issue: http://gnutoo.homelinux.org/downloads/people/khem/serial_gcc.txt Dec 09 14:15:14 btw is there any reason why boost native is not staging itself? Dec 09 14:15:16 bluelightning, I'll post to oe-devel right now Dec 09 14:15:20 basically they fails to boot Dec 09 14:15:21 I see it's done on purpose in the recipe Dec 09 14:15:26 it seem to be alignements issues Dec 09 14:16:16 bluelightning, we need to deal with my qt work Dec 09 14:16:17 also in angstrom: gcc-cross-4.5-r44+svnr181733 fails to compile with | .../angstrom/work-shared/gcc-4.5-r44+svnr181733/gcc-4_5-branch/gcc/cp/cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p' Dec 09 14:16:37 I feel like the recipe deliberately buggers qmake for some reason, buy leaves the other tools alone Dec 09 14:16:47 Crofton|work: yes... my plan is to test it building for several archs, if I don't get warnings I'll ack the patch Dec 09 14:17:39 ok Dec 09 14:17:49 just want to make sure we are not waiting on each other Dec 09 14:18:15 I am attempting to build boost without icu atm Dec 09 14:25:01 Crofton|work: I'm going to start testing it now - I had meant to yesterday but got caught up fixing meta-qt3 Dec 09 14:25:06 I saw Dec 09 15:01:29 hi, anyone an idea how to get a writable /dev with squashfs ? (or have syslogd running with squashfs as it wants to create /dev/log) Dec 09 15:01:48 mount devtmpfs at /dev? Dec 09 15:03:52 eFfeM_work, do you want udev/mdev or devtmpfs? Dec 09 15:04:10 pb_ thanks, guess I need that Dec 09 15:04:14 GNUtoo: devtmpfs Dec 09 15:04:24 ok Dec 09 15:17:52 khem: addtask foo. Dec 09 15:17:56 khem: thats it. Dec 09 15:18:13 khem: addtask foo before do_build will get it automatically run by default, as do_build is the BB_DEFAULT_TASK Dec 09 15:23:00 pb_, GNUtoo, almost happy devtmpfs does make /dev writable, but it loosed the /dev entries that I made with my DEVICE_TABLE; is there a way to tell it to keep the old contents of /dev Dec 09 15:23:44 anyone make anything of this? http://pastebin.com/Ng395S72 Dec 09 15:23:45 actually I used to have a static table and was happy with it, but syslogd wants to create the local socket /dev/log Dec 09 15:24:25 ah, I see. could use unionfs, I suppose. Dec 09 15:24:31 eFfeM_work, hmmm it's devtmpfs not mdev Dec 09 15:24:43 which means that it's like devfs from the old kenrels Dec 09 15:24:44 or just create the nodes you need at boot time, or stop syslogd from doing that stuff with /dev/log. Dec 09 15:24:48 no, need to make things small (also therefore no unionfs) Dec 09 15:25:04 in that case, patching syslogd is probably your best option Dec 09 15:26:00 bluelightning, it failed for me too, I did bitbake -k and cleansstate the native version of git and restarted and I guess it worked, it now fails on gcc(for target) Dec 09 15:26:30 pb_: devtmpfs does what I want, guess I'll make the nodes in my init script Dec 09 15:26:39 ok Dec 09 15:29:41 eFfeM_work: why not use the existing solution you have there? :) Dec 09 15:30:06 likewise: what do you mean? Dec 09 15:30:23 I need to add syslog and it creates a local socket in /dev Dec 09 15:30:43 eFfeM_work: yes Dec 09 15:31:11 eFfeM_work: all the platforms support that during development Dec 09 15:32:19 eFfeM_work: I think aufs or unionfs was used, but nowadays devtmpfs will work as well. Dec 09 15:32:27 likewise: syslog works for me on jffs2 but not on squashfs, not sure whether we have many products taht actually use squashfs Dec 09 15:32:43 eFfeM_work: yes since 2005 or so. :) Dec 09 15:33:49 likewise: at least some of our products use jffs2; might also be that the behaviour of syslog is changed; busybox syslog now uses a domain local socket instead of a named fifo Dec 09 15:35:00 eFfeM_work: since 2006, http://cgit.openembedded.org/openembedded/log/?qt=grep&q=squashfs I am quite sure we have a static set of dev nodes on squashfs, and a union mount on top of it. Dec 09 15:35:28 at least during development, see for example HTI10 Dec 09 15:36:12 but I guess investigating devtmpfs is surely worth it. Dec 09 15:36:14 likewise: ok, you know better than I do; actually I'm doing the new RRC so moved to newer kernel, 2011 maintenance branch etc, didn't add unionfs (yet?) actually I'm not too much of a fan of unionfs Dec 09 15:37:20 eFfeM_work: Well, Linux' implementations suck but I think the idea of a union mount is great and very UNIX like. I just hoped they used the FreeBSD approach: mount ... -o union Dec 09 15:38:09 likewise: the idea is indeed pretty neat Dec 09 15:38:26 likewise: btw did it work out with Sal ? Dec 09 15:38:48 eFfeM_work: not yet. Dec 09 15:38:55 eFfeM_work: holidays :) Dec 09 15:39:00 nice Dec 09 15:39:06 actually have 2 days off mon and tue Dec 09 15:39:24 pb_: How does devtmpfs work for you in meta-micro? Dec 09 15:39:49 pretty well, we're using it more or less exclusively nowadays. Dec 09 15:40:04 we = the company you work for? Dec 09 15:40:14 yeah Dec 09 15:40:27 pb_: signing products, right? Dec 09 15:40:33 right Dec 09 15:40:45 digital signage and video players Dec 09 16:10:14 Hi. I've found an error inside a recepie: libtasn1_1.7.bb necessary to build task-gstreamer-ti (for gumstix overo). I've created a patch. How should I release it? Dec 09 16:10:14 Dec 09 16:10:14 Dec 09 16:43:19 Hi. I've found an error inside a recepie: libtasn1_1.7.bb necessary to build task-gstreamer-ti (for gumstix overo). I've created a patch. How should I release it? Dec 09 16:44:27 * kergoth` looks at license parsing firefight Dec 09 16:47:00 kergoth`: that licensing stuff is good Dec 09 16:47:24 yeah, consistent formatting and syntax is a good thing, we just should have fixed the broken ones in the same patchset :) Dec 09 16:47:29 kergoth`: btw. I want the task to spit the run.do_test file but not really run it Dec 09 16:47:35 * kergoth` didn't expect there to be broken ones in the repositories Dec 09 16:48:00 khem: ohh, right. I don't think there's a way to do that, offhand but you could always do it yourself, programmatically, perhaps Dec 09 16:48:02 hmm Dec 09 16:48:35 actually I want the environment that those scripts set and then a script of my own at the end Dec 09 16:48:53 is there is a way I can do that as part of do_compile Dec 09 16:49:12 may be echo this into a new script file will work as well Dec 09 16:49:46 could always just source or run your external script from the shell task? or emit/run an empty task and then source that into your script afterwards, or.. hmmm Dec 09 16:49:48 actually, let me see what all variables I will need Dec 09 16:50:22 I can just generate a .sh script along when I do do_compile Dec 09 16:50:46 set >foo ? hehe Dec 09 16:51:01 Hello, Dec 09 16:52:05 I was looking for help on compiling the Narcissus build of angstrom for Beagle, I downloaded the SDK but there is no makefile or make program, Dec 09 16:52:23 khem, hi Dec 09 16:52:36 dmitry_: the angstrom channel might be a better bet Dec 09 16:52:36 GNUtoo: hello Dec 09 16:52:52 kergoth`: ah, can I do that in do_compile as :) thats so simple Dec 09 16:53:03 :) Dec 09 16:53:26 khem, with the new toolchain, under the SHR distro, on armv7 at least kernels don't boot anymore(nokia900(n900) and crespo(nexus S)) Dec 09 16:53:41 khem, since I've serial console under crespo I captured this: Dec 09 16:53:53 http://gnutoo.homelinux.org/downloads/people/khem/serial_gcc.txt Dec 09 16:54:56 GNUtoo: can you be sure of that ? Dec 09 16:55:15 which delta would it be Dec 09 16:56:21 khem, I'm not sure exactly what bump but kernel defconfig stayed the same Dec 09 16:56:34 JaMa knows more Dec 09 16:56:38 he pointed me to that: Dec 09 16:57:14 Spider-Pork: you'r using oe-classic, send a patch to openembedded-devel@lists.openembedded.org Dec 09 16:57:30 ant_work: thank you Dec 09 16:57:33 it's probably one of linaro patches added to meta-oe (as one was only moved from meta-oe to oe-core) Dec 09 16:57:33 so one of this http://git.openembedded.org/meta-openembedded/commit/?id=2378ee8f21741abd23e434260a88c62cb0e151f1 Dec 09 16:57:50 GNUtoo: are you using 4.6 Dec 09 16:57:55 ant_work: I'm using oe classic Dec 09 16:57:57 I'll check Dec 09 16:58:25 arm-oe-linux-gnueabi-gcc (GCC) 4.6.3 20111117 (prerelease) Dec 09 16:58:34 GNUtoo: ok Dec 09 16:58:44 Spider-Pork: yes, oe-core is up to libtasn1_2.11 Dec 09 16:58:53 Can you revert that and see if that helps Dec 09 16:59:04 ant_work: or disable the new patches Dec 09 16:59:45 ant_work: I'm using this git checkout --track -b overo-2011.03 origin/overo-2011.03 and it use libtasn1_1.17 Dec 09 16:59:59 the problem is in the URL where to fetch the tar.gz Dec 09 16:59:59 GNUtoo: remove these http://pastebin.com/sz1aas6Q Dec 09 17:00:04 and then rebuild your gcc Dec 09 17:00:09 and kernel Dec 09 17:00:12 and see if it boots Dec 09 17:00:39 ok let me re-arrange my desk, I was making an SPI programmer right now Dec 09 17:06:12 cleaning toolchain... Dec 09 17:11:32 kergoth`: set did the job :) Dec 09 17:11:36 nice Dec 09 17:11:44 simplest way is sometimes the best Dec 09 17:12:05 s/sometimes/usually/ Dec 09 17:12:06 :-) Dec 09 17:12:15 kergoth`: actually I might want to prune some of the setting in there Dec 09 17:12:30 it should be simple but no simpler Dec 09 17:12:46 you could always make a python do_compile which calls emit_* from bb.data to get just what you want, and calls the base do_compile Dec 09 17:12:48 if you had to Dec 09 17:12:54 but set|grep might be easier :) Dec 09 17:13:29 kergoth`: yeah i think i will check the env and see what I need then probably I will emit them individually Dec 09 17:27:39 anyone using connman? Dec 09 17:30:57 kind of, I'm in the middle of writing a frontend for it in opie Dec 09 17:31:13 haven't used it alongside the OE recipes yet though Dec 09 17:31:20 bluelightning: look at our qconnman project please Dec 09 17:31:39 bluelightning: I was going to ask you to test our connman recipe changes heh Dec 09 17:33:50 bluelightning: https://github.com/OSSystems/qconnman Dec 09 17:36:52 Is there a document that discusses the shift away from openembedded classic ? Dec 09 17:39:49 awozniak: http://www.openembedded.org/wiki/OpenEmbedded-Core Dec 09 17:40:11 bluelightning:thx Dec 09 17:43:57 bluelightning: it seems packagehistory has issues with versioning Dec 09 17:53:08 otavio: what kind of issues? Dec 09 17:56:05 bluelightning: 1.0-r0 being newer of 1.0-r0.foo.1 Dec 09 17:56:46 otavio: well, we use OE's internal version comparison functions, so if packagehistory reports that then OE considers that to be the case Dec 09 17:57:35 seems wrong to me Dec 09 17:58:04 it considers 1.0-r0 to be newer than 1.0-r0.foo.1? are you sure? that seems quite odd Dec 09 17:59:58 khem, doing what you suggested makes the kernel boot Dec 09 18:00:12 kergoth`: seems so Dec 09 18:02:53 otavio: is that "foo" actually "foo" or something else in your actual observation of this issue? Dec 09 18:04:02 bluelightning: dropbear from current meta-oe is the real use case Dec 09 18:04:02 funnily enough, that really does seem to be true Dec 09 18:04:08 I think that is a bug in bb.utils Dec 09 18:04:28 * otavio is not too drunk Dec 09 18:04:29 heh Dec 09 18:04:32 * otavio is kidding Dec 09 18:04:37 see the code in vercmp_part() which does "if sa and not sb:" etc Dec 09 18:07:36 I'm guessing it was not written in anticipation of things like PR .= ".meta-oe.1" Dec 09 18:08:41 727ce6ffe33a119cb17f7d91b173f11a055eea3c was the checkin in question Dec 09 18:08:45 bluelightning: dpkg --compare-version works for this case Dec 09 18:09:04 otavio: I'm not suggesting it shouldn't be fixed :) Dec 09 18:09:22 bluelightning: I know; I just wanted to point something that works as expected heh Dec 09 18:09:53 it might be useful if we had a similar way to compare versions in a single command like that Dec 09 18:09:57 bluelightning: eh, anyone writing version comparison code *must* consider the case where one version has more components than the other Dec 09 18:10:25 usually the shorter gets logically extended with a filler of some sort, whether that is the empty string or zero or something, whether its *actually* extended doesn't matter Dec 09 18:10:29 afaik, anyway Dec 09 18:10:39 yeah Dec 09 18:10:40 I don't disagree, I didn't write the code in question ;0 Dec 09 18:10:42 ;) Dec 09 18:10:58 I think we may well have stolen that bit from portage Dec 09 18:10:58 I couldn't immediately grasp from denys's description in the mailing list thread what exactly he was trying to accomplish with that patch. Dec 09 18:11:00 not sure Dec 09 18:11:45 of course, python's distutils includes version representation classes, though they're pretty basic. I've wondered in the past if we shouldn't leverage something similar Dec 09 18:11:58 prior to that checkin, the behaviour was just that the longer string was "newer" in the case where one was a substring of the other. Dec 09 18:12:19 that seems like a reasonable behavior Dec 09 18:12:49 I think possibly what denix was trying to accomplish was to stop "1.0-1" from sorting newer than "1.0a" by introducing special behaviour for separators Dec 09 18:13:37 but I think his change is a bit too simple-minded since, if it finds a separator on one side and not the other, it now just assumes that the one with the separator must be older. Dec 09 18:13:55 I think the simplest sane version comparison is to split by allowed separators and/or character class, convert numbers to int, and compare the two lists, with care to ensure the relative lengths are handled sanely Dec 09 18:14:15 ah, indeed Dec 09 18:14:22 yeah, that's what the old algorithm did Dec 09 18:14:49 explode_version() breaks it apart into components and then vercmp_part() just walks along the two lists comparing them until it either finds a difference or falls off the end Dec 09 18:15:12 but, clearly, for denix's case where you are bolting suffixes on the end this was producing wrong results in some cases Dec 09 18:15:17 * kergoth` nods Dec 09 18:15:35 well, I say "clearly", it's not totally obvious to me that the versioning comparison can be well-defined in that situation Dec 09 18:16:11 pb_: the algorithm was following debian versioning guidelines Dec 09 18:16:11 anyway, gotta go home or my wife will be angry Dec 09 18:16:12 later all Dec 09 18:16:43 The P2 "omniversion" scheme used in eclipse in quite interesting. It lets you encode the rules by which a version is separated into its components, as well as length extension handling, into the version string itself Dec 09 18:16:52 denix: it seems that the current algorithm isn't. otavio has a counterexample. Dec 09 18:16:56 so that any version from any arbitrary scheme anywhere can be compared against any other, in theory Dec 09 18:17:01 without need for a central registry Dec 09 18:17:20 quite interesting, I was thinking it could be cool to support something like that at some point, rather than hardcoding a particular scheme/policy into bitbake Dec 09 18:24:51 hmm, quite strange, as I very often do PR_append = "-suffix1" to make it newer Dec 09 18:25:34 note: he said *period* suffix was an issue, not *dash* suffix Dec 09 18:25:36 afaict anyway Dec 09 18:25:48 in my case the suffix is -aragoX, as it's common to append -distroX suffixes in ubuntu and debian... Dec 09 18:26:40 kergoth`: correct, but the code should not treat dot and dash differently - both are in separators var and it checks against it Dec 09 18:27:31 * kergoth` shrugs, points at otavio Dec 09 18:30:15 otavio: can you try .meta-oe1 - i.e. remove the second dot? Dec 09 18:33:50 otavio: another question - is there a "+" in the version? Dec 09 18:35:36 denix: You can easily test it with dropbear from meta-oe Dec 09 18:35:39 denix: from today Dec 09 18:35:45 denix: I pushed a bbappend for it Dec 09 18:35:57 my change was to handle "dot" and "dash" specially to sort lower than "plus". otherwise it should behave as previously Dec 09 18:36:03 ok, let me try Dec 09 18:36:05 denix: and koen noticed that buildhistory complained about it going backwards Dec 09 18:43:52 otavio: do I need a previous version built? Dec 09 18:45:10 denix: without the bbappend Dec 09 18:47:16 it is building .meta-oe.1 for me now Dec 09 18:47:40 the code in BB I fixed is responsible for sorting versions when deciding which one to build Dec 09 18:48:08 if it fails to sort versions of already built packages, then it's not BB problem, but opkg Dec 09 18:48:39 or if it's comparing shared states, I wonder if there is a separate code for that... Dec 09 18:57:13 comparing shared states wouldn't make sense. they're by definition bound to a particular checksum of a particular recipe Dec 09 18:57:20 they aren't installed with a package manager, the particular one is used Dec 09 19:09:23 kergoth`: makes sense Dec 09 19:10:00 I'm wondering if .bbappend could affect this in any way Dec 09 19:10:44 denix: supposely not Dec 09 19:11:04 denix: what concerns me is why koen got the warning from buildhistory with this Dec 09 19:12:05 otavio: can I see the exact warning? is it on the ml? Dec 09 19:13:07 denix: let me see if I have in my backlog Dec 09 19:17:54 denix: no, I don't. :( Dec 09 19:17:56 hi, all! I see, there are only libgles-omap3 bb-files... We'll it be hard to port TI Graphics SDK on omap4? Dec 09 19:18:42 denix: http://pastebin.com/PHckANQ3 Dec 09 19:18:54 denix: Koen pasted it for me. Dec 09 19:28:07 otavio: well, it's definitely not bitbake's issue Dec 09 19:28:15 ERROR: Package version for package dropbear-dbg went backwards which would break package feeds from (0:2011.54-r0 to 0:2011.54-r0.meta-oe.1) Dec 09 19:28:19 ERROR: Function 'buildhistory_emit_pkghistory' failed Dec 09 19:28:42 and 'buildhistory_emit_pkghistory' is in buildhistory.bbclass of oe-core Dec 09 19:29:16 http://cgit.openembedded.org/openembedded-core/tree/meta/classes/buildhistory.bbclass Dec 09 19:33:16 ah, it calls bb.utils.vercmp, my bad. still looking... Dec 09 19:35:04 denix: :( Dec 09 20:41:00 I'm having to clean quite a few -native recipes to due to some perl issue after pulling today Dec 09 20:43:58 I thought that bb.utils.vercmp() had unit tests but that doesn't appear to be the case. I guess we should add some. Dec 09 20:57:27 maybe a future oe-core overlay ? http://developer.palm.com/blog/2011/12/open-source/ ;-) Dec 09 21:07:57 :) Dec 09 21:08:28 ericben: I am still having trouble getting Qt Creator to work with qt files created for the host's sdk. What distrib's SDK do you use that I can try and see if I can figure out my issue? Dec 09 21:09:06 pb_: here's the C code for that, seems to work fine - http://svn.openmoko.org/trunk/src/host/opkg-utils/opkg-compare-versions.c Dec 09 21:10:04 can't see where the issue is in Python counterpart, though... I think I need to clear my head to track it down :) Dec 09 21:27:40 ericben, it's morphis who will be happy..... Dec 09 21:27:56 I hope they will release the modem part of the palm pres Dec 09 21:55:43 What is the commit policy on meta-micro? Dec 09 21:56:13 Should patches go through a mailing list first, be reviewed X times etc? Dec 09 21:56:41 likewise: send patches to oe-devel ml with [meta-micro] prefixed in subject Dec 09 21:57:22 all layers that are hosted on oe.org use oe-devel ml at present and adding the layer name to patch subject to make the differentiation Dec 09 21:57:36 only oe-core patches are sent to oe-core ml Dec 09 22:26:45 khem: thanks Dec 09 22:28:21 likewise: what are you doing with meta-micro Dec 09 22:28:47 khem: experimenting on i.mx53 for a 1080p decoding application Dec 09 22:29:00 likewise: cool. Dec 09 22:29:10 I had this meta-efikamx layer Dec 09 22:29:24 which could be handy for imx Dec 09 22:29:43 https://github.com/kraj/meta-efikamx Dec 09 22:29:55 khem: work on my meta-freescale fork on github, forked from Freescale work. Dec 09 22:29:57 likewise: any patches you have I would be happy to host them here Dec 09 22:30:11 ok ok Dec 09 22:30:14 efikamx is imx51, right? Dec 09 22:30:17 yes Dec 09 22:30:21 but its similar Dec 09 22:30:31 may be I should have called it meta-imx Dec 09 22:30:32 :) Dec 09 22:30:36 should be largely similar. GNUtoo and ericben are also working on 51/53 Dec 09 22:31:02 I have one here which I use for as my streaming player :) Dec 09 22:31:08 khem: we try to officially introduce the tree into the oe or yocto repo's after we cleaned it up Dec 09 22:31:20 ok Dec 09 22:31:33 khem: cool, I have the efikamx as well, sounds like a good application for it! Dec 09 22:32:02 but I dont have any fsl drivers Dec 09 22:32:06 khem: i just hit this problem in the kernel, same as this posting: http://imxcommunity.org/group/imx53quickstartboard/forum/topics/unhandled-fault-alignment-exception-error-booting-freescale-2-6?commentId=4103961%3AComment%3A47840&xg_source=activity&groupId=4103961%3AGroup%3A5816 Dec 09 22:32:09 or libs Dec 09 22:32:25 khem: could you read the response in the end and see if that is correct? Dec 09 22:32:51 khem: I do wonder if it's a kernel bug instead of a toolchain/kernel misconfig. Dec 09 22:33:28 yes thats ok Dec 09 22:34:08 why dont you use the meta-oe toolchain if its cortex-a8 Dec 09 22:34:18 the response is correct? Dec 09 22:34:19 we have all linaro patches in there it should do pretty well Dec 09 22:34:28 yes response seems to be correct Dec 09 22:34:30 I am using the meta-oe toolchain. Dec 09 22:34:52 imho the same issue as GNUtoo reported today Dec 09 22:35:00 http://pastebin.com/4cvdaPz8 Dec 09 22:35:20 that's the function disassembly, I think the offender is @0x34 Dec 09 22:36:43 http://pastebin.com/54EFCf9Q with the C function added Dec 09 22:36:49 yes but that code sounds wrong to me Dec 09 22:36:56 can you send me a small test case Dec 09 22:37:07 khem: I don't see the bug at first sight. Dec 09 22:37:50 jama: gnutoo reported it here or on the ml? Dec 09 22:38:17 GNUtoo: was mentioning something Dec 09 22:38:25 but he did not give me lot of details Dec 09 22:38:39 khem: well, if I can spot what C line is offending, I can create a small test case. Dec 09 22:38:40 he said your last gcc upgrade broke my kernel :) Dec 09 22:38:42 sort of Dec 09 22:38:43 likewise: don't know.. he talked with me about it on #openmoko-cdevel and probably with khem here Dec 09 22:39:15 ok that code seems ok to me if we assume alignment is handled in hw Dec 09 22:40:05 likewise: what are inputs to that function Dec 09 22:40:18 ah nothing void Dec 09 22:40:22 the bottom of second pastebin URL has the C code: void indeed Dec 09 22:41:18 I assume this store fails: str r2, [sp, #6] Dec 09 22:42:37 cons 5|#yocto 6|#gcc 7|RP__ 8|#angstrom 9|hrw] Dec 09 22:42:37 (#oe) Dec 09 22:42:41 ups Dec 09 22:42:47 char options[] = "mode=0755"; Dec 09 22:43:06 likewise: can you make that aligned to 4 Dec 09 22:43:13 and see if changes the code ? Dec 09 22:44:18 yes Dec 09 22:45:53 khem: I hate fixing bugs this way though :) Dec 09 22:46:07 likewise: I am not saying fix it this way Dec 09 22:46:12 khem: but I love doing it in the weekends :) Dec 09 22:46:17 likewise: I was trying to find the cause of it Dec 09 22:47:54 likewise: so if you align that than it makes it aligned right ? Dec 09 22:48:17 khem: dunno yet, I have a hard time following the new assembly: http://pastebin.com/rbkaFLQ9 Dec 09 22:48:29 khem: let me run it just for the sake of it Dec 09 22:49:06 khem: boots without faulting now Dec 09 22:49:20 ok Dec 09 22:50:39 stmia r3!, {r0, r1} Dec 09 22:50:43 thats the change Dec 09 22:51:35 likewise: whats the options you pass to compiler Dec 09 22:54:38 you mean when compiling the kernel, right? oe_runmake uImage CC="ccache arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb --sysroot=/home/leon/sandbox/sidebranch/imx53qsb/openembedded/build/tmp-eglibc/sysroots/imx53qsb" LD="arm-oe-linux-gnueabi-ld --sysroot=/home/leon/sandbox/sidebranch/imx53qsb/openembedded/build/tmp-eglibc/sysroots/imx53qsb" Dec 09 22:54:45 khem, strangely doing what you advised only worked for crespo Dec 09 22:54:49 (nexus S) Dec 09 22:55:29 GNUtoo: Add -mno-unaligned-access Dec 09 22:55:37 to compiler cmdline Dec 09 22:56:27 OT: WebOS will be opensourced? will be interesting to see if we can include it in OE Dec 09 22:56:52 zecke: I already commented on that blog but my comment is pending for moderation :) Dec 09 22:57:15 likewise: I doubt thats the full cmdline Dec 09 22:57:34 likewise: make V=1 object.o Dec 09 22:57:41 what does that show ? Dec 09 23:01:53 khem: ah lovely Dec 09 23:02:15 I basically welcomed them to oe community Dec 09 23:02:22 ccache arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb --sysroot=/home/leon/sandbox/sidebranch/imx53qsb/openembedded/build/tmp-eglibc/sysroots/imx53qsb -Wp,-MD,drivers/base/.devtmpfs.o.d -nostdinc -isystem /home/leon/sandbox/sidebranch/imx53qsb/openembedded/build/tmp-eglibc/sysroots/i686-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3/include... Dec 09 23:02:24 ...-I/home/leon/sandbox/sidebranch/imx53qsb/openembedded/build/tmp-eglibc/work/imx53qsb-oe-linux-gnueabi/linux-imx-2.6.35.3-r2/linux-2.6.35.3/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-mx5/include -Iarch/arm/plat-mxc/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function Dec 09 23:02:24 and suggested to create a layer Dec 09 23:02:26 -declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(devtmp Dec 09 23:02:27 fs)" -D"KBUILD_MODNAME=KBUILD_STR(devtmpfs)" -c -o drivers/base/.tmp_devtmpfs.o drivers/base/devtmpfs.c Dec 09 23:02:29 sorry Dec 09 23:02:42 instead of going out into a forest alone like they did last time Dec 09 23:03:12 likewise: Os is the key here ? Dec 09 23:03:14 :) Dec 09 23:03:37 khem: why, Os illegal in kernel builds? Dec 09 23:03:52 no it is not Dec 09 23:04:10 likewise: I have a small testcase here and I was not able to reproduce the desired effect Dec 09 23:04:26 ok so compiler is trying to avoid a memcpy call basically Dec 09 23:04:50 bbiab: news item I want to see Dec 09 23:06:47 khem: how did you deduce that? Dec 09 23:06:49 GNUtoo: all you should need is add -mno-unaligned-access to kernel Dec 09 23:07:43 likewise: I have a small test case now Dec 09 23:08:41 likewise: I wonder why kernel can not handle the unaligned accesses I know armv7-a allows it Dec 09 23:09:01 so is it that the kernel version you are using does not handle the unaligned accesses ? Dec 09 23:11:17 khem: trying to find that CONFIG item... Dec 09 23:12:01 ARMv6+ accepts unaligned load/store for memory/cpu interface Dec 09 23:12:11 I think kernel doesnt know it in your case Dec 09 23:13:00 khem: you mean the kernel should enable this in the ARM core? Dec 09 23:13:18 khem: but it does not? Dec 09 23:13:21 to disable alignment check The 'A' bit in the CP15 Control Register needs to be clear Dec 09 23:14:19 khem: ok, so the compiler is assuming it can generate unaligned code because it assumes the core is configured to handle it? Dec 09 23:14:30 correct Dec 09 23:14:50 and since you say -march=armv7-a Dec 09 23:15:49 ok, arm is still a bit new for me, too much powerpc in the past Dec 09 23:18:11 performance will be better if unaligned memory access is used on processors which supports it Dec 09 23:19:18 khem: really? that's kind of unexpected to me Dec 09 23:19:37 khem, ok thanks Dec 09 23:19:57 I'll do it tomorrow(too tired right now) Dec 09 23:20:13 make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm EXTRA_CFLAGS=-mno-unaligned-access uImage Dec 09 23:20:17 should do it as well Dec 09 23:22:12 khem: but the real fix is to fix u-boot or the kernel not clearing the A bit? Dec 09 23:23:31 likewise: I would think so Dec 09 23:23:53 since disabling unaligned access is no gain on processors who has support for it Dec 09 23:24:06 what does /proc/cpu/alignment say on target ? Dec 09 23:27:33 khem: I just viewed it on the working kernel, but just cleared the terminal log... Dec 09 23:28:09 I think it only listed the number of traps it handled (2 user faults on alignment, zero elsewhere) Dec 09 23:28:49 khem: any idea how I can inspect CP15 after the kernel crashed? I need a JTAG pod probably, it doesn't seem to be dumped in the kernel oops. Dec 09 23:29:28 likewise: I guess yes jtag Dec 09 23:31:39 but of course I could inspect it on the good kernel Dec 09 23:31:54 I mean the one with the aligned(4) workaround Dec 09 23:34:42 khem: thank you for your insights here, learned a lot about ARM again Dec 09 23:34:56 likewise: btw. I looked into kernel code a bit Dec 09 23:35:02 and it does the right thing it seems Dec 09 23:35:13 but I am looking at linus's tree Dec 09 23:35:38 khem: what part of the kernel source you looked at? the arm init code, or the devtmpfs_init() code? Dec 09 23:36:28 arm init code Dec 09 23:36:41 arch/arm/kernel/setup.c specially Dec 09 23:41:49 likewise: see how __cpu_architecture is set Dec 09 23:43:30 khem: I do not understand why the '__' here? Dec 09 23:44:16 likewise: I think do a kprints around the architecture Dec 09 23:44:26 and the checks where it checks for unaligned access Dec 09 23:45:05 cpu_is_v6_unaligned in arch/arm/mm/alignment.c Dec 09 23:48:08 I'm on 2.6.35.3 (the latest vendor kernel). Yes I know. Trying to go mainline soon... Dec 09 23:48:14 but let me check. Dec 09 23:52:45 I'll put a printk() here: http://lxr.linux.no/#linux+v2.6.35.3/arch/arm/mm/alignment.c#L900 Dec 09 23:54:33 khem: you using oe at work these days? Dec 10 00:00:11 likewise: no :( unfortunately Dec 10 00:00:23 likewise: I am not even using linux more unfortunately Dec 10 00:00:26 but thats life Dec 10 00:01:16 khem: well, I have been out of Linux/OE for a bit as well. (AVR32 with the lightweight IP stack, one of my 10-year old projects). Dec 10 00:01:42 cool something fringe Dec 10 00:02:30 likewise: are you on with OE for new project now Dec 10 00:03:06 khem: yes, well a demonstrator project, my basic aim is to use the i.MX53 video decoders for 1080p MPEG/H.264 Dec 10 00:03:38 likewise: cool, Dec 10 00:03:39 khem: I guess gstreamer, with all the Freescale-specific plugins for their h/w codecs Dec 10 00:03:55 likewise: arm/lnx/oe are my favorites :) Dec 10 00:04:06 khem: what can your imx51 decode as your media player? Dec 10 00:06:39 likewise: you might want to read this thread http://comments.gmane.org/gmane.linux.ports.arm.kernel/117863 Dec 10 00:06:55 likewise: I have ffmpeg Dec 10 00:07:08 no hardware accelaration or any such thing Dec 10 00:07:13 pure software Dec 10 00:08:35 khem: ok, and it can manage 720p ? Dec 10 00:09:01 likewise: yes Dec 10 00:09:40 "If we need that CR bit disabled earlier, then that's what we need to do," Dec 10 00:10:04 that's exactly the problem I think, the bit is disabled too late during boot Dec 10 00:10:12 devtmpfs_init() comes quite early Dec 10 00:10:25 not sure though yet. Dec 10 00:15:11 yes Dec 10 00:15:15 most probably Dec 10 00:15:31 but that thread is long and later moves over to lkml as well Dec 10 00:15:32 :) Dec 10 00:19:39 khem: yes, we are probably chasing a bug long fixed upstream already. The problem is probably that moving to upstream I lose the video driver/codecs/ Dec 10 00:20:23 khem: Linaro is on the job: https://launchpad.net/linaro-landing-team-freescale Dec 10 00:20:50 khem: wouldn't Linaro be a nice employer for you? :) Dec 10 00:21:03 given they do at least arm/lnx stuff Dec 10 00:25:02 likewise: linaro hmm I did consider when they were just starting Dec 10 00:25:08 but did not go further Dec 10 00:25:21 likewise: I think the bug might not have been fixed yet Dec 10 00:25:41 but as a whole disabling unaligned-access in kernel compilation seems ok Dec 10 00:25:49 it seems we wont loose much Dec 10 00:26:34 khem: indeed, otherwise we would have hit more issues Dec 10 00:27:02 I guess arm/linaro guys should fix the kernel accordingly Dec 10 00:27:50 the problem shows when enabling DEVTMPFS in this kernel. That's exactly what GNUtoo also did (I presume) because I know he is using meta-micro, which is using devtmpfs since recently. Dec 10 00:30:43 hmm possible Dec 10 00:31:25 I think we can fire up that thread on arm-lnx list Dec 10 00:31:35 with this new example Dec 10 00:31:51 in our case stack vars are becoming unaligned Dec 10 00:32:18 which they thought was due to fconserve-stack but in our case its not Dec 10 00:32:28 its solely due to unaligned access Dec 10 00:32:41 oh well I better get driving Dec 10 00:32:44 and pick my son up Dec 10 00:32:52 traffic is pretty bad in this part of world Dec 10 00:33:22 I learned that :) Dec 10 00:33:42 the main reason we missed each other when I was over... Dec 10 00:33:54 have a good weekend, thanks for the help here Dec 10 00:36:17 rschus: gm (?) Dec 10 00:36:34 rschus: bed time for me though, cya **** ENDING LOGGING AT Sat Dec 10 02:59:56 2011