**** BEGIN LOGGING AT Tue Aug 14 03:00:02 2018 Aug 14 10:16:05 bluelightning: thanks, giving it a try now with prependig to BBPATH instead of appendig Aug 14 16:59:29 bluelightning: that worked, thanks Aug 14 16:59:52 pespin: great :) Aug 14 17:00:03 * bluelightning wonders if that's in the FAQ Aug 14 17:11:22 it is now: https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_override_a_bbclass_file.3F Aug 14 18:35:34 3 Aug 14 20:35:34 khem, hi Aug 14 20:36:14 strongarm/collie builds fine with gcc8 / TUNE_FEATURES = "arm armv4" Aug 14 20:36:55 pespin: bbpath operates like PATH. first file found is the one used. which is why it needs to be before, rather than after, to override Aug 14 20:59:11 ant_home: good to hear ! finally gcc8 is panning out ok even for older arches Aug 14 21:04:30 khem, looking now for the strongarm feature, disappeared in the years? Aug 14 21:05:40 ah .. Aug 14 21:06:04 f7bb2d4cf18c tune-*: use mcpu instead of mtune for ARM tunes Aug 14 21:06:17 -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mtune=strongarm1100', '', d)}" Aug 14 21:06:17 +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'strongarm', ' -mcpu=strongarm1100', '', d)}" Aug 14 21:06:17 Aug 14 21:06:47 khem, should I go ahead and optimize it? Aug 14 21:07:54 I understand RP concerns but these were valid 10years ago, today there aren't feeds for armv4/5 that I know of Aug 14 21:08:52 ant_home: The real question is whether these flags actually make any real difference Aug 14 21:10:31 probably in some cases, I can do limited benchmarking on these devices Aug 14 21:12:13 the big issue is that after gcc9 support for armv4/5 will be ditched afaik, so I try to give the last finishing now... Aug 14 21:12:50 ant_home: it effectively reverts part of http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/machine/include/tune-xscale.inc?id=54ee29e56348a11667fd368714c0462ba58a3647 :/ Aug 14 21:18:08 RP: iirc JaMa was working on the SHR feeds at the time. Other feeds did bitrot Aug 14 21:19:06 ant_home: right, but trying to create more efficient feeds would still be desirable for those devices? Aug 14 21:19:58 well, what I can do is to build test images. The rare developers would want the best flags Aug 14 21:20:41 so the idea of feed is vague: where? which distro? maintainers? etc.. Aug 14 21:21:20 what we really do is to build and test on device because qemuarm cannot be trusted ;) Aug 14 21:22:01 ant_home: I just don't like being in a situation where patches flip something back and forth. 2012 is longer ago that I thought from memory but this is something people keep trying to push both ways Aug 14 21:22:18 ant_home: I do like real hardware tests too fwiw Aug 14 21:23:13 RP: there are no xscale devices in oe-core, nor strongarm Aug 14 21:23:25 should I move the tune files in meta-handheld? Aug 14 21:25:20 ant_home: no Aug 14 21:26:51 ant_home: you could actually just override the default tune in the machine before you include the file to be honest Aug 14 21:27:11 ant_home: I'm not sure that is much better as that would undermine what JaMa was trying to achieve though Aug 14 21:29:10 RP: it was all around feeds size and build time Aug 14 21:30:04 surely not about optimization Aug 14 21:32:15 ...and in fact the gcc bug blocking xscale was years old and nobody protested loudly... Aug 14 21:32:22 ant_home: Its really a question of what the defaults should be - optimised for the single lone developer or helping the distro maintainer Aug 14 21:33:12 RP: I agree with you, it is just that as of today there are no feeds nor distros Aug 14 21:33:13 We took a patch to help people building distros with OE. Now you want to make some of the system reflect the distro and some the single lone developer - your change makes the system inconsistent for your own personal priorities :/ Aug 14 21:33:55 RP: don't get me wrong Aug 14 21:33:58 ant_home: I actually wish there were feeds Aug 14 21:35:06 RP: the benefits should be measured, I don't expect miracles Aug 14 21:39:19 ant_home: I just had a look in a book from the shelf I've not looked at in a while. I think xscale doesn't have extra instructions but it does have a fairly unique pipleline cache architecture Aug 14 21:39:40 ant_home: The optimisations from that xscale option are therefore mostly likely from instruction ordering Aug 14 21:40:49 I ws lurking in gcc code recently, chasing for armv5e align bug, there I have seen there are many diffs btw xscale and i.e. iwmmxt Aug 14 21:42:20 ant_home: the differences that matter are generic armv5te verses xscale Aug 14 21:42:38 sure, afair these are less Aug 14 21:42:50 iwmmxt has extra instructions so there will be differences there Aug 14 21:42:57 ok Aug 14 21:42:57 https://bugs.launchpad.net/gcc-linaro/+bug/662720/comments/1 Aug 14 21:43:35 ant_home: I believe the differences between xscale and armv5te are minor to the point of not being worthwhile Aug 14 21:43:40 RP: I think back then you ought have benchmarked that for OpenZaurus Aug 14 21:44:06 ant_home: would have loved to have done. Sadly available time... Aug 14 21:44:28 :) Aug 14 21:45:01 ant_home: I was looking at a C760 the other day with fond memories Aug 14 21:52:24 I plan to make it boot linux5 then archive... Aug 14 22:01:33 ant_home: I think yes you should Aug 14 22:06:20 RP, for fun, reverting that patch for the strogarm: Aug 14 22:06:29 Parsing of 1465 .bb files complete (0 cached, 1465 parsed). 2091 targets, 151 skipped, 0 masked, 0 errors. Aug 14 22:06:29 Removing 114 recipes from the armv4 sysroot: 100% |##############| Time: 0:00:03 Aug 14 22:06:29 Removing 113 recipes from the collie sysroot: 100% |#############| Time: 0:00:02 Aug 14 22:06:29 N Aug 14 22:07:15 Sstate summary: Wanted 754 Found 3 Missed 751 Current 215 (0% match, 22% complete) Aug 14 22:07:24 same core-image-base Aug 14 22:07:36 ant_home: not surprising in the slightest Aug 14 22:07:42 heh Aug 14 22:09:46 khem, you mean putting tune in the bsp layer? Aug 14 22:11:09 change the tunes in oe-core Aug 14 22:12:28 if I read the comments of Martin again, the feeds are shared only for Aug 14 22:12:29 armv4t: arm920t, arm9tdmi armv5te: arm926ejs, xscale armv7a-neon: cortexa8, cortexa9 Aug 14 22:13:02 the rest using own DEFAULTTUNE Aug 14 22:13:16 so no way to share feeds Aug 14 22:13:48 well, the other patch does force -mcpu instead of -mtune ... Aug 14 22:13:49 ant_home: one easyish experiment would be to build and compare binaries built with armv5te, arm926ejs and xscale - see if they really are different Aug 14 22:14:42 RP: I did a similar test: gcc7 did miscompile kernel for zaurus but not for versatile... Aug 14 22:15:05 same for align traps: versatile/qemuarm does not use DSP so LDRD was not used Aug 14 22:15:15 there are realy diferences... Aug 14 22:15:59 do you have a suggestion for a bench from meta-benchmarkin for 64MiB ram? Aug 14 22:16:34 I can get some figures Aug 14 22:32:18 RP: khem: I'll send the sibling patch for DEFAULTTUNE strongarm so you'll decide on both :] Aug 14 22:33:40 ant_home: thanks, just what I need... Aug 14 22:36:49 RP: is'nt OE the best/more optimized/hyped toolchain on the table? Aug 14 22:38:54 ant_home: totally, and nothing stops you configuring this like that... Aug 14 22:39:36 heh, 'others' were laughing last semester while I was struggling with align traps... Aug 14 22:39:55 they were just building for armv5t, without DSP ... Aug 14 22:42:19 RP: I think decisions about optimizing feeds are at DISTRO level while the core should provide best/optimized toolchain Aug 14 22:42:43 at least for obsoleted devices Aug 14 22:43:27 ant_home: and how does someone decide when something is obsoleted? Aug 14 22:43:38 part of me just wants to give in, take the patch and have an easy life Aug 14 22:43:44 well, from the number of contributions? Aug 14 22:43:53 the other part of me knows that if I do, this will come up again in the future Aug 14 22:45:47 please read carefully the last part of th ecommit message Aug 14 22:46:45 ant_home: The bit about the lack of public feeds? I did read it and comprehend it Aug 14 22:46:57 sorry, JaMa's comment Aug 14 22:47:15 a11bdc36a1be1 Aug 14 22:47:42 back then afair the issue was with cortex*, some with hardfpu, etc Aug 14 22:49:02 armv4 and armv5 were just incidentally involved Aug 14 22:50:58 ant_home: I don't really read it that way Aug 14 22:51:28 since oe-core qemuarmis armv5 Aug 14 22:52:17 arm926ejs is different from xscale Aug 14 22:52:35 I don't see th epoint there, only that some distro had armv5te feeds Aug 14 22:53:03 (sorry for the typos, kid washed my laptop with cola...) Aug 14 22:53:22 it's all sticky Aug 14 22:54:06 as for armv4, the only device I know of in OE is collie Aug 14 22:54:26 h3600 recently, for a while Aug 14 22:54:37 both strongarm Aug 14 22:55:08 ant_home: qemuarm is v5e iirc which is not compatible with v5te Aug 14 22:55:35 yes, i.e. did not suffer of musl bug :) Aug 14 22:56:02 ant_home: so there was a good reason not to put it in the same feeds as the other devices Aug 14 23:00:18 RP: if one needs generic armv5e binaries can then use the qemuarm feeds Aug 14 23:02:00 here all was lowered one step to the bottom Aug 14 23:02:19 to the common ancestor arch Aug 14 23:02:57 again, I do understand why it was done back then Aug 14 23:03:36 RP: btw, we are not in hury...good news is all these combinations do compile and run fine :) Aug 14 23:04:26 ant_home: I just went and looked at the gcc sources. xscale does appear to mainly change the instruction timings Aug 14 23:04:44 afair there is a different multi_ Aug 14 23:05:18 I'd be happy to measure, I am now eager Aug 14 23:08:18 libc bench maybe? Aug 14 23:09:40 never tried th ebench of meta-oe, only the opie ones, long ago :) Aug 14 23:11:06 * ant_home battling with t h key sequences on dirty kb Aug 14 23:11:45 ant_home: I'm not sure where you'd show up the differences... Aug 14 23:12:59 I have seen around filesystem benchmarks and knowing how readdir is prone to optimization I can imagine a distinct difference Aug 14 23:13:24 in one case uing LDRD instead of two LDR Aug 14 23:13:44 this is one of xscale cases Aug 14 23:14:23 tomorrow is holiday, Iìll try to measure something... Aug 14 23:14:45 now better to wash kb and go to bed Aug 14 23:14:47 gn Aug 14 23:22:24 Linux Kernel Developer | Full-time/Permanent | Redmond WA Aug 14 23:22:29 anyone interested :) Aug 15 00:41:27 khem, is that at microsoft? Aug 15 00:46:30 seems so Aug 15 02:30:40 is that is the case, they will need to include "bsod" app **** ENDING LOGGING AT Wed Aug 15 02:59:59 2018