**** BEGIN LOGGING AT Wed Aug 24 02:59:58 2016 Aug 24 12:28:07 We don't have eudev configured to search for firmware someone other than /lib/firmware, do we? Aug 24 17:08:59 Tartarus: no Aug 24 17:17:45 khem: It's just not working for me, so I gave up and compiled the firmware blobs I need in Aug 24 17:18:06 khem: Next stupid question, krogoth should have an optimized (arm) memcpy by default, yes? Aug 24 17:18:33 it does as long as the kernel version is 'high enough' Aug 24 17:18:55 I can't remember if Kergoth had it set high enough to use all the optimized code or if it was only partially optimized Aug 24 17:19:29 Ug, it depends on kernel version? Aug 24 17:22:01 Tartarus: yes, memcpy was always optimized for long time Aug 24 17:22:10 don't remember if this is arm or not, but one of the archs the optimization calls into the kernel for that kind of optimization, but its kernel version specific Aug 24 17:22:30 Tartarus: there was a regression during 2.17 timeframe where cortex-a8 regressed but cortex-a9 worked ok Aug 24 17:22:59 fray: they all use HW_CAPS Aug 24 17:23:07 to decide which one to use Aug 24 17:23:19 Hmm, ok Aug 24 17:24:48 How do I check HW_CAPS? Aug 24 17:24:53 Tartarus: whats your h/w sub-family Aug 24 17:25:09 imx6 Aug 24 17:25:17 And 3.0.x FSL kernel :( Aug 24 17:25:25 Tartarus: ugh ok Aug 24 17:25:38 dont they support 3.14 now on imx6 ? Aug 24 17:25:47 or 4.1 Aug 24 17:25:49 Oh, they do Aug 24 17:25:52 I'm doing customer work Aug 24 17:26:21 I hate customers Aug 24 17:27:42 Tartarus: OK, if you dump your binary with readelf -A it should show HW_CAPS Aug 24 17:28:17 on target.. Aug 24 17:28:37 yay for giant chroot on usb stick Aug 24 17:29:02 see http://lxr.free-electrons.com/source/arch/arm/include/asm/hwcap.h Aug 24 17:29:22 Tartarus: you can just check one app Aug 24 17:29:28 Yeah Aug 24 17:30:12 So, crap Aug 24 17:30:17 I should see NEON spelled out plainly Aug 24 17:30:18 Right? Aug 24 17:31:17 Odd: Computing transaction...error: Can't install nativesdk-python-mako-1.0.1-r0@x86_64_nativesdk: no package provides /opt/fsl-qoriq/2.0/sysroots/x86_64-fslsdk-linux/usr/bin/env Aug 24 17:31:34 this is Jethro based fsl "sdk" Aug 24 17:32:29 Tartarus: yes Aug 24 17:34:10 OK, I've got a few good next steps then Aug 24 17:34:11 interesting, the /opt/fsl... path is completely bogus Aug 24 17:34:24 Having the $customer code built with a quite ancient Linaro toolchain is part of the issue Aug 24 17:34:30 I see NEON on /bin/bash Aug 24 17:34:33 And not their stuff Aug 24 17:35:23 * Tartarus craps out a new SDK, digs up his patch from a bit ago to use that instead to build stuff, moves on Aug 24 17:41:07 Tartarus: Linaro did some backports from upstream toolchain components so you may get different behaviors Aug 24 17:41:16 when you switch to internal toolchain Aug 24 17:41:23 what version of gcc is it ? Aug 24 17:43:43 4.7-2013.04-20130415 Aug 24 17:50:32 Tartarus: most likely there are backports that makes differences in that version, now a days its not that much delta Aug 24 17:51:02 Yeah Aug 24 17:51:10 But long term they're moving forward Aug 24 17:51:14 Tartarus: that version works well ? Aug 24 17:51:17 I just need to show that X/Y/Z do in fact get better Aug 24 17:51:35 Depending on your definition of well :) Aug 24 17:51:53 I mean newer stuff regresses compared to that ? Aug 24 17:51:57 or not Aug 24 17:53:08 I'm seeing about a 25% speed drop in their secret sauce, compared to what's done today Aug 24 17:53:25 perf shows various oddities as being what's eating a larger share of cpu% than before Aug 24 17:53:43 ie I bet in the old version whatever mumbojumbo they have from Linaro is doing NEON memcpy Aug 24 17:53:44 We are not Aug 24 17:53:55 (as readelf -A says no, no NEON to use here!) Aug 24 17:54:13 Moving to krogoth from jethro did "fix" the wchar related problem I saw Aug 24 17:54:48 I'm hoping that rebuilding the secret sauce with a modern compiler (and linking vs our stuff too) will get the expected hw caps Aug 24 17:56:29 so the app is precompiled ? Aug 24 17:59:16 It's outside of OE Aug 24 17:59:33 (And shall remain, I don't want to torture app developers with OE) Aug 24 18:00:02 using the SDK to compile the app should be fairly painless for developers Aug 24 18:02:22 Right Aug 24 18:03:05 It treats the Linaro one like that today and I can pop in an OE one instead with just a few changes Aug 24 18:03:30 I'm picking and choosing my battles wrt upgrading stuff here with their system Aug 24 18:03:50 ie I can't use another compiler for their kernel today unless I want to debug why that causes the kernel to shit the bed Aug 24 18:04:02 And since they want to move up, in due time, there's no reason to Aug 24 18:13:37 Tartarus: for tests see if the app can be compiled with OE sdk Aug 24 18:13:44 and makes any differnece Aug 24 18:14:11 intrinsics have changed especially on arm Aug 24 18:14:36 its using hard-float I assume ? Aug 24 18:15:34 I've built it with jethro Aug 24 18:15:45 as part of previous experiments Aug 24 18:15:56 And, uh, it's a long story ;) Aug 24 18:26:51 ok try it with krogoth since that seems to fix one of your poblem Aug 24 19:44:48 khem: Tag_Advanced_SIMD_arch: NEONv1 should cause NEONv1 memcpy to be used, right? Aug 24 20:24:50 Anyone use packages for keeping toolchains built in bitbake up to date or know if it's posible? It would be pretty convenient to just call "smart upgrade" when new packages have been added to the feed. Aug 24 20:35:22 Tartarus: yes Aug 24 20:36:35 Rallis: is it form SDK ? Aug 24 21:10:07 khem: we build meta-toolchain-qt5 Aug 24 21:25:23 do you use package management ? Aug 24 22:36:09 khem: we use rpms **** ENDING LOGGING AT Thu Aug 25 02:59:58 2016