**** BEGIN LOGGING AT Mon Jul 09 03:00:02 2018 Jul 09 06:03:24 please install the SDK in a different directory than /home/akash/rpil/rpi-build/tmp where it seems you built the SDK using yocto Jul 09 06:03:38 use something like say /opt/yocto or so Jul 09 14:28:06 are the elements of the CORE_IMAGE_BASE_INSTALL variable packages? Jul 09 14:52:30 rburton_, I found the xf86-input-fbdev failures. is on qemumips64 Jul 09 14:53:19 weird thing is testimage fails but if do runqemu, no problem the testimage passes Jul 09 15:43:41 zeddii: Why does kernel-devsrc DEPENDS on perf? Jul 09 15:44:17 it races with the perf modifications to the source if it doesn't Jul 09 15:45:15 zeddii: but perf doesn't make modifications to the source directly any more does it? Jul 09 15:46:31 I probably missed a patch that changed that. Jul 09 15:46:43 ah yes. I see the copy routine. Jul 09 15:46:59 zeddii: ihttp://git.yoctoproject.org/cgit.cgi/poky/commit/?id=35c75c7773571005678de140589bc79becf6a63f Jul 09 15:47:58 so yah. that can be dropped now. Jul 09 15:48:17 zeddii: I thought I must have been missing something :) Jul 09 15:48:28 naw. I just missed those patches when they came out :D Jul 09 15:48:48 want me to send a v2 single patch ? or were you going to nuke it ? Jul 09 15:49:47 zeddii: single v2 would be helpful as I've not done anything with the patches yet Jul 09 15:49:57 (other than glance at them) Jul 09 15:50:29 will do. I'll do a single patch v2. Jul 09 16:00:50 zeddii: thanks! Jul 09 16:05:52 New news from stackoverflow: Bitbake variables S, B vs. make's VPATH Jul 09 16:19:13 RP: just pushed a mut which has been pruned Jul 09 18:06:11 New news from stackoverflow: Installing Bit Bake Append'ed Packages with DNF cleanly Jul 09 19:56:17 how does the openembedded-layer specify the u-boot it uses? Jul 09 20:43:07 does image creation (via a xyz-image.bb) also create the u-boot (bootloader)? Jul 09 20:44:00 eg. if i have my own xyz-image.bb, and it has "inherit image", does that estalish the kernel as well as u-boot? Jul 09 20:45:10 or am i hopelessly confused? Jul 09 20:45:27 an image will generally pull in a kernel and u-boot, via the dependencies Jul 09 20:47:07 this is swupdate-image.bb from meta-swupdate: https://paste.fedoraproject.org/paste/9MBH8ViWze2e6Ss0HC1CoQ. is there something in that file other than "inherit image" that specifies which u-boot it will use? Jul 09 20:49:40 i am frustrated that, having used yocto for almost 2 years now, i still have this level of confusion on how it works... sorry for driving the channel crazy. Jul 09 20:50:22 memorizing a bazillion details is orthogonal to my mind's preferred way of operating, i.e., via a lot of structure... Jul 09 20:50:29 yocto is kind of complex Jul 09 20:51:08 for example, back in high school, i preferred deriving trig identities from the basics rather than memorizing them... Jul 09 20:51:29 timm1: yes, it is very memory-intensive for the human. Jul 09 20:52:15 too much dependencies to remember easily Jul 09 20:52:16 yates: why would a general 'swupdate' image specify what u-boot to use? that is the choice of the bsp Jul 09 20:53:57 rburton_: yes, i had that thought as well, but evidently to use the u-boot-fw-utils at kernel time, you have to link to a library, libubootenv.a, which is only built during u-boot build Jul 09 20:54:30 luckily what kernel to use is also the BSP's responsibility Jul 09 20:55:28 maybe i've got it wrong, but i thought, at the 30,000-foot level, building the swupdate image (bitbake swupdate) created a pared-down initrd kernel. Jul 09 20:58:42 that image just pulls in the standard kernel Jul 09 21:00:07 rburton_: via the "inherit image"? Jul 09 21:00:32 indirectly yes Jul 09 21:00:43 and i presume also it pulls in the "standard u-boot"? Jul 09 21:01:04 so how do i get it to use my bsp? Jul 09 21:01:27 use your bsp Jul 09 21:01:39 you mean in the layers.conf? Jul 09 21:01:45 no, i mean set MACHINE to your bsp Jul 09 21:01:53 and then your machine config controls what bootloader kernel etc Jul 09 21:09:42 i don't see a "MACHINE = ..." in my standard build, but i do see a "COMPATIBLE_MACHINE = ..." Jul 09 21:09:50 what's the difference? Jul 09 21:13:28 ok, i'm RTFMing. Jul 09 21:14:38 real-time frequency modulating... Jul 09 21:18:10 rburton_: did you mean add MACHINE in the image .bb for swupdate? Jul 09 21:18:27 i did. didn't seem to change anything. Jul 09 21:20:08 swupdate-image.bb Jul 09 21:20:21 under sources/meta-swupdate/recipes-extended/images/ Jul 09 21:42:43 MACHINE is set in local.conf. Jul 09 21:42:59 it's global build configuration, not recipe Jul 09 21:50:13 doh. Jul 09 21:53:56 there was not a local.conf, so i added one in meta-swupdate/conf/local.conf with the MACHINE=. would that be correct? Jul 09 21:57:22 ok, i guess the answer to that is "no." Jul 09 21:57:42 no Jul 09 21:57:53 local.conf is in conf/ in your build directory, and you wouldn't be able to run bitbake without it Jul 09 21:57:54 i made a meta-swupdate/conf/machine folder, then added the file machine-name.conf with the entry "MACHINE = machine-name" Jul 09 22:00:12 ok, so you're saying i shouldn't have to do anything. if i build swupdate in the same build environment as my main image, it should use the same MACHINE Jul 09 22:00:32 that's correct, yes, every build uses the same machine unless you're using multiconfig, which you're probably not Jul 09 22:00:59 every exsecution of bitbake within the same build direcotry, that is Jul 09 22:01:10 yes. Jul 09 22:02:53 ok, well why am i getting buildouts into a different machine? https://paste.fedoraproject.org/paste/caFxuKzFE-R6nCptmXPfrA Jul 09 22:04:13 it looks like for some things bitbake is using armv7at2hf-neon machine, and others the right machine: imx6ul_var_dart Jul 09 22:06:50 why is bitbake ever building things to armv7at2hf-neon?!? Jul 09 22:08:59 ? Jul 09 22:10:55 that's not a machine Jul 09 22:11:23 that's the architecture/tuning Jul 09 22:11:48 some recipes are machine specific, others produce binaries that are compatible with any machine compatible with that tuning Jul 09 22:12:23 kernel, uboot, etc are machine speciifc, most are not Jul 09 22:14:13 it's controlled by PACKAGE_ARCH. recipes which are amchine specific change that from the default Jul 09 22:14:57 i see Jul 09 22:15:20 is PACKAGE_ARCH a .conf setting? Jul 09 22:16:06 no, i bet not. i'll do somereading Jul 09 22:16:08 thanks kergoth Jul 09 22:16:35 no, i just told you by definition it's recipe specific Jul 09 22:16:48 and it's not something you should ever need to set at all, anywhere, with very few exceptions Jul 09 22:19:32 well something is fucked up. Jul 09 22:19:41 it no workie. Jul 09 22:19:58 the link error is listed in my last fpaste Jul 09 22:21:52 the recipe/build is using the env/fw_env.c from the imx6ul_var_dart area which is older than the u-boot in the armv7at2hf-neon area Jul 09 22:22:48 that version of fw_env, which apparently gets rolledinto libubootenv.a, does not have a function fw_env_flush Jul 09 22:23:13 there's no u-boot in the armv7 area at all. that's swupdate's use of u-boot's api Jul 09 22:23:22 it's expecting fw_env_flush to exist, which it doesn't in the u-boot your bsp is using Jul 09 22:23:28 afaict from a quick glance at your paste, anyway Jul 09 22:23:48 - /armv7at2hf-neon-fslc-linux-gnueabi/swupdate/, swupdate, not u-boot Jul 09 22:24:51 tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/swupdate/2018.03-r0/git/bootloader/uboot.c is not part of u-boot?!? Jul 09 22:29:28 i am more confused now.. Jul 09 22:29:33 going home. Jul 09 22:29:51 thanks - have a good evening kergoth et al. Jul 09 22:32:04 so you're saying the source code under armv7at2hf-neon-fslc-linux-gnueabi/swupdate/... is code babic wrote to support swupdate? Jul 09 23:03:36 yates: no, that's nto part of u-boot, that's swupdate's support to set u-boot variables Jul 09 23:04:34 hence 'swupdate'. that's the recipe name involed Jul 09 23:13:42 alimon: FWIW playing with the idea of http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=f65664c23e8fbefc821919c730399c5e099842a5 Jul 09 23:21:04 RP: ok, i will hceck Jul 09 23:21:07 check* Jul 09 23:23:37 RP: i had the same approach, forking when the tests can run by thread, also i remember that some suites modified layers like meta-selftest and causes meta-data problems Jul 09 23:25:02 alimon: hmm, I thought I remembered something like this. We're going to struggle if something really wants to modify layers like that. I guess we may need to teach it to copy first Jul 09 23:25:21 alimon: selftest takes too long now so we need to get this fixed... Jul 09 23:25:56 Time to sleep but I'll probably look further at it tomorrow. Thanks for the reminder about the layer changes... Jul 09 23:26:26 RP: ok, my code is here, http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/oe_selftest_threaded Jul 09 23:26:34 but uses threads... instead of forking Jul 09 23:27:13 alimon: ah, right, yes. I've always found python processes and hard forks easier to deal with... Jul 09 23:28:45 alimon: I probably want http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=alimon/oe_selftest_threaded&id=a704d0eba3504d71e03f3665b6088178359374b3 :) Jul 09 23:28:48 RP: yes anyways there are some logic in the test cases to avoid problems in the meta-data Jul 09 23:32:22 alimon: plenty to think about tomorrow, thanks **** ENDING LOGGING AT Tue Jul 10 03:00:01 2018