**** BEGIN LOGGING AT Thu Aug 28 02:59:58 2014 Aug 28 06:29:57 morning all Aug 28 06:43:42 evenub' guvnor Aug 28 07:50:32 khem: gm. I'm diffing the compiler logs and I see some other strange things... Aug 28 07:51:26 the 'bad' logs contains i.e. "Using built-in specs." Aug 28 07:51:56 and another strange token ì-ILIBRARY_PATH' Aug 28 07:52:11 -ì ofc ;) Aug 28 07:53:23 what is happening here...? Aug 28 09:13:06 Hi all. it's a bit of a kernel related question. I have a working system with a specific platform. Now, I have another newer platform and when I boot the system with the previous working firmware, I got the following kernel error messages Aug 28 09:13:20 2014-08-28T16:52:20.846828+00:00 x86 kernel: i2c i2c-0: new_device: Instantiated device pca9554 at 0x3c 2014-08-28T16:52:20.846836+00:00 x86 kernel: pca953x 0-003c: failed reading register 2014-08-28T16:52:20.846842+00:00 x86 kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. 2014-08-28T16:52:20.846843+00:00 x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) 2014-08-28T16 Aug 28 09:13:28 ups. that's not so readible. Aug 28 09:13:33 x86 kernel: i2c i2c-0: new_device: Instantiated device pca9554 at 0x3c Aug 28 09:13:37 x86 kernel: pca953x 0-003c: failed reading register Aug 28 09:13:41 x86 kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Aug 28 09:13:43 pastebin please Aug 28 09:13:45 x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) Aug 28 09:13:48 x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) Aug 28 09:13:49 x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) Aug 28 09:13:50 x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) Aug 28 09:13:50 not spamming the channel Aug 28 09:14:09 woglinde, you are talking to me? Aug 28 09:14:54 yes Aug 28 09:15:27 ok. I copied the log to the following location Aug 28 09:15:28 http://pastebin.com/0TFkCdki Aug 28 09:15:44 Basically I got the following error: x86 kernel: i2c i2c-0: Failed to register i2c client pca9554 at 0x3c (-16) Aug 28 09:15:58 what could be the reason, or where should I start from? Aug 28 09:16:03 what you understand about firmware? Aug 28 09:16:16 it's oe firmware Aug 28 09:16:52 you mean the linux kernel and it its driver not some binary blog a specific driver needs, right? Aug 28 09:17:30 I meant binary blob of course Aug 28 09:18:28 so, I have a system in which I run oe. This works fine and I already have some applications added Aug 28 09:18:37 so, now I got another hardware Aug 28 09:19:06 I thought that I can just simply use the same oe firmware that I generate from the first system Aug 28 09:19:13 however I got the error that I mentioned Aug 28 09:19:18 so you can not Aug 28 09:19:27 you mention drivers but I use AMD in both Aug 28 09:19:37 so fglrx should be the same I suppose Aug 28 09:19:41 why can't Aug 28 09:19:57 if you never learned to driver with manual gear, how will you drive a newer car with it Aug 28 09:20:27 if they are both equipped with manual gear, I can use why not? Aug 28 09:20:40 read my hint again Aug 28 09:20:54 you mean kernel config? Aug 28 09:21:00 did you read the technical manual? Aug 28 09:21:07 so I need to configure the system with the new hardware? Aug 28 09:21:12 did you looked up if the i2c devices changed? Aug 28 09:21:20 nope Aug 28 09:21:30 actually that's my querstion. I don't know where to start Aug 28 09:21:43 reading the technical manual Aug 28 09:21:58 should I compare them, I mean previous system and the new one Aug 28 09:22:01 and you may end up asking on the kernel-ml or i2c-driver mailing list Aug 28 09:22:11 because its some bug in the i2c driver Aug 28 09:22:21 aha Aug 28 09:22:31 but tell me this Aug 28 09:22:36 when I run ubuntu on it Aug 28 09:22:41 it starts up fine Aug 28 09:22:54 so, I am thinking that it is a sort of config issue? Aug 28 09:23:23 not at all Aug 28 09:23:35 maybe you have a newer or older kernel on ubuntu Aug 28 09:23:37 so, how come ubuntu starts up then? Aug 28 09:23:40 compare the versions Aug 28 09:23:40 aha Aug 28 09:23:47 that's sure differnt Aug 28 09:23:52 I use very old kernel in my firmware Aug 28 09:24:02 *sigh* Aug 28 09:24:12 I do not like the kernel called firmware Aug 28 09:24:44 yes but I have linux kernel which is old Aug 28 09:24:53 and I have a firmware build on top of this with oe Aug 28 09:25:34 *sigh* and I do not like called linux + os called firmware Aug 28 09:25:54 how do you call it then Aug 28 09:26:09 only os? Aug 28 09:26:14 yes Aug 28 09:26:18 ok Aug 28 09:26:35 so I will read the technical manual first Aug 28 09:26:41 and hope to find some stuff there Aug 28 09:26:44 thanks a lot Aug 28 09:26:44 hm if ubuntu runs Aug 28 09:26:56 yes Aug 28 09:26:57 why not try the same kernel revision Aug 28 09:27:06 that's a big problem with oe :) Aug 28 09:27:12 I am using an old one Aug 28 09:27:13 which might be available in oe Aug 28 09:27:24 hm it is not a problem of oe Aug 28 09:27:27 no but I will give it a try now Aug 28 09:27:32 it is your problem using such an old kernel Aug 28 09:27:36 indeed Aug 28 09:27:44 thanks for remindir :D Aug 28 09:28:13 besides the seucrity issuse you proably have with older kernels Aug 28 09:28:35 indeed Aug 28 09:28:40 but that's my plan to change it Aug 28 09:28:47 so perhaps I should start from there Aug 28 09:28:48 thanks Aug 28 11:15:36 JaMa: have you tried multimachine builds recently? Was all fine? Aug 28 15:08:15 how do we clean tmp/image/machine dir ? Aug 28 15:09:25 kbouhara: rm -rf tmp/image/machine ;-) Aug 28 15:24:54 is there any recommended way to have a glibc build in OE ? Aug 28 15:25:09 (build/link everything against glibc instead of eglibc) Aug 28 15:26:33 test khem's patchset he sent today :) Aug 28 15:29:18 and then realize there's no difference between (e)glibc Aug 28 15:40:58 eglibc and glibc are the same code base for the same version string.. Aug 28 15:41:08 eglibc allows for some cross compilation (locale) that glibc traditionally hasn't.. Aug 28 15:41:45 it also allows for you to reconfigure the APIs available (breaking the library ABI with existing systems as a side effect) to create a smaller libc.. (similar to uclibc).. 'glibc' doesn't have that without Khem's patches Aug 28 15:47:35 RP_: any comments on the rest of udev-cache changes? sorry for being short with you about the forking stuff, but I wanted to make sure it got broken down into measurables Aug 28 16:05:57 rtollert: thanks for the reminder, I need to read that mail properly Aug 28 16:09:36 koen: actually there is one single version I might want a glibc on this system Aug 28 16:09:51 I might need to run a blob Aug 28 16:10:10 but then I only need to have a gnulibc, I dont need to rebuild everything Aug 28 18:40:52 RP: uninative looks quite promising Aug 28 19:22:45 kergoth: I keep reading it a un-initiative and thinking "that's not a real word" Aug 28 20:44:26 khem: the issue is gcc-cross-arm Aug 28 20:44:40 it encode the first machine sysroot found Aug 28 20:46:28 in --with-gxx-include, -with-sysroot, --with-build-sysroot Aug 28 20:47:05 maybe we should clear MACHINEOVERRIDES? Aug 28 20:48:43 it seems to me those wrong paths are in EXTRA_OECONF_PATHS Aug 28 20:49:20 I'm pulling now master Aug 28 21:24:17 ant__: hmmm you have to make sure klcc uses TOOLCHAIN_OPTIONS Aug 28 21:24:24 to set sysroot Aug 28 21:24:43 when was it changed? Aug 28 21:25:35 its not changed Aug 28 21:25:39 but its the general way Aug 28 21:25:41 RP helped me to fix klcc-cross on 2014-05-04 Aug 28 21:25:53 so you can reuse it across sstate Aug 28 21:25:59 back then we already had an unique gcc-cross for arm iirc Aug 28 21:26:09 not anymore Aug 28 21:26:19 http://cgit.openembedded.org/meta-openembedded/commit/meta-initramfs/recipes-devtools?id=55b09e522ca88c0c0b2dd7a36e4861a1cf6ca9c6 Aug 28 21:26:21 ^ Aug 28 21:26:57 back then the issue was it did not rebuild for multi-machine builds within the same arch Aug 28 21:27:34 never had problems when there was a gcc-cross for each arm variant Aug 28 21:29:03 I'm rebuilding today's master, let see Aug 28 21:29:50 khem, I see the MACHINE sysroot in gcc-cross-arm..that cannot be right Aug 28 21:30:17 it was simply taking the first Aug 28 21:30:29 the first built I mean Aug 28 21:38:21 khem, it is compiling, though I see nothing changed in configure log Aug 28 21:38:23 --with-gxx-include-dir=/oe/oe-core/build/tmp-eglibc/sysroots/collie/usr/include/c++/4.9.1 --with-sysroot=/oe/oe-core/build/tmp-eglibc/sysroots/collie --with-build-sysroot=/oe/oe-core/build Aug 28 21:38:44 /tmp-eglibc/sysroots/collie Aug 28 21:39:02 it hardcodes MACHINE Aug 28 21:45:16 I don't grasp it...EXTRA_OECONF_PATHS refers to STAGING_DIR_TARGET so how can it be used for armv4 and armv5te? **** ENDING LOGGING AT Fri Aug 29 02:59:58 2014