**** BEGIN LOGGING AT Wed Nov 13 02:59:58 2019 Nov 13 04:04:29 New news from stackoverflow: Cross compile OpenCV with CUDA on x86-64 host for nvidia tk1 (arm) target using Yocto Project? Nov 13 06:20:04 JPEW: sorry did not get your message from yesterday (matrix irc bridge dropping messages). Feel free to squish it into your patch as long as it works correctly ;) Nov 13 09:02:21 Sigh... meta-mingw is not compiling, probably missing a couple of packages. What do I need to add? Nov 13 09:02:42 "a couple of packages" Nov 13 09:02:53 seriously, what did you expect after that problem description? ;-) Nov 13 09:03:12 I have included meta-openembedded/meta-oe, meta-openembedded/meta-networking Nov 13 09:04:08 wertigon: easiest would be to put the relevant error message parts into a pastbin Nov 13 09:05:29 error messages trying to compile nativesdk-gdbm for instance Nov 13 09:05:51 Complain about missing pwd.h Nov 13 09:07:20 and nativesdk-ncurses complains over sys/poll.h Nov 13 09:07:55 and openssl says x86_64-mingw is not a proper cross compiler :P Nov 13 09:11:36 https://pastebin.com/yJUnZHej Nov 13 09:11:44 Is the output I get Nov 13 09:12:02 My hunch is that I need to apt install something on my build machine Nov 13 09:12:40 And oh yeah; thud branch Nov 13 09:15:37 some thoughts: meta-toolchain is deprected, i don't think using it is a good idea. Nov 13 09:16:09 and, *maybe* the problem comes from trying to generate a 32bit-mingw Nov 13 09:16:29 have you tested if the same effect shows up for 64bit? Nov 13 09:17:15 other than that, i can only say, start with poky only, try, add layers one after the other. that stack is rather big after all, hard to say where things go wrong Nov 13 09:18:48 Hmm, yeah, I tried switching to x86_64-mingw Nov 13 09:18:57 From i686-mingw32 Nov 13 09:19:16 But might need a reconfigure of that; not sure Nov 13 09:19:30 Oh, and using thud Nov 13 09:19:58 What are we supposed to use instead of meta-toolchain to build a toolchain? populate_sdk? Nov 13 09:20:19 yep, the recommended way these days is building the sdk Nov 13 09:20:26 Ok :) Nov 13 09:21:04 Planning to do that anyway, just want to get the toolchain to work first. I can populate_sdk without mingw. Nov 13 09:22:29 i think thats the wrong approach. meta-toolchain might be broken where the sdk isn't Nov 13 09:27:08 Will try populate_sdk then Nov 13 09:27:50 But not too hopeful Nov 13 09:28:36 and really, that stack is big. start small, iterate. find out where things stop working Nov 13 09:31:01 letothe2nd: Everything but mingw compiles Nov 13 09:31:08 Already tried it Nov 13 09:32:25 no, i don't think so. what you probably tried is "what compiles for non-mingw" Nov 13 09:32:49 this doesn't mean that things that compile this way still compile for mingw Nov 13 09:34:25 how can I force mingw to reconfigure? Nov 13 09:34:50 hello hello Nov 13 09:37:39 nvm, I just nuke it and rebuild from scratch :P Nov 13 09:38:09 The joys of having a 12 threaded dev machine... Nov 13 09:38:28 And a small dev environment ^^ Nov 13 09:39:40 wertigon: how are you configuring the mingw build Nov 13 09:40:03 and are you use thud of both oe-core and meta-mingw Nov 13 09:42:58 is oe-core same as meta-oe? Nov 13 09:43:51 Configuring - I include layer meta-mingw in bblayers.conf and then MACHINESDK="x86_64-mingw" in local.conf Nov 13 09:45:17 no oe-core is meta/ Nov 13 09:45:41 Hmm, that could be it then Nov 13 09:47:42 Let's see... I pull down entire meta-openembedded from github.com/openembedded Nov 13 09:49:34 So, I get meta-openembedded from that repo Nov 13 09:49:46 Not openembedded-core Nov 13 09:50:39 the mingw layer back in thud was very limited Nov 13 09:51:02 maybe you're hitting the edge of its support Nov 13 09:52:22 so i've just fired a meta-toolchain for mingw here on thud to see what happens, but i also have pilates now so i'll be gone for a bit Nov 13 09:53:06 rburton: It is quite possible, yes Nov 13 09:53:59 rburton: We are following ti release cycle, so thud will soon become next layer. I'll try to include openembedded-core as it's separate layer and report back if it works. Nov 13 09:54:05 that said meta-toolchain is what i expected to work. Nov 13 09:54:17 no, you must have oe-core from somewhere else already Nov 13 09:54:23 Ok Nov 13 09:54:25 you literally can't build without it Nov 13 09:54:36 I see :) Nov 13 09:54:57 Let me check if openembedded branch has been updated from our local repository Nov 13 09:55:16 Had a similar problem with clang Nov 13 09:59:52 So yeah, I am at 2d088d252 and latest thud upstream is 446bd61 Nov 13 10:05:39 Synced myself with upstream; maybe it will fix things, but doubt it. :/ Nov 13 10:06:02 (meta-openembedded which should pull core as well) Nov 13 10:15:42 Hi, is it possible to rewrite a git url? Nov 13 10:16:11 I need to setup a local mirror. But for now i want to rewrite only one git repository Nov 13 10:17:39 GeneralStupid: make a bbappend and modify the SRC_URI, for example Nov 13 10:21:43 letothe2nd: would this also be the solution to modify the configuration of this package? Nov 13 10:22:21 GeneralStupid: depends on what you mean by "configuration" Nov 13 10:22:27 but often, "yes" Nov 13 10:23:26 Another thing to note; each git pull creates it's own mirror, it is possible to clone a new repository from your machine over ssh for instance Nov 13 10:24:39 So you could in theory only clone all repositories. Of course, they will need to be updated manually from time to time Nov 13 10:25:10 at the moment i try to solve this with PREMIRRORS_prepend. But this is not working. There is one repository which is blocked by the Proxy, so i need to mirror only this repo ... Nov 13 10:32:24 Hello, maybe someone could point me in the right direction - I have a yocto project that makes image for raspberry pi CM3, and a bunch of scripts that populate boot partitions etc. It's final time to ditch those scripts and change to wic. On the occasion I'd like to make some modifications to the mount strategy - i.e. I'd like to move /home to separate partition. How can do that? I'd have to use (write) some plugin? Nov 13 10:33:30 any questions welcome, I'm keen to elaborate if somethings unclear Nov 13 10:35:34 New news from stackoverflow: Yocto compiling a desired kernel version and using full of its modules Nov 13 10:41:54 kpo: If you want a simple solution, create a recipe that modifies /etc/fstab Nov 13 10:42:27 kpo: Do you need any files under /home in the image or just an empty partition? Nov 13 10:42:48 In our distro we use overlayfs for this specific task Nov 13 10:43:19 Though not sure how, not responsible for that feature - we have a squashfs for the base file system and then an overlay fs above that Nov 13 10:44:26 Hmm, I might have found one answer to my problem atleast... sudo apt install libc6-dev-armhf-cross :D Nov 13 10:46:58 kpo: You can run `wic help kickstart` to show the available options for each partition entry in a wks file Nov 13 10:47:25 wertigon: paulbarker: unfortunately, I'm creating some custom users using useradd.bbclass, so I can't mount it in fstab as-is Nov 13 10:47:28 You can use `--exclude-path /home` on your root partition and then add a new partition which collects files from `/home` Nov 13 10:56:28 paulbarker: new partition that collects /home from the build image? so it everything will build as-is for now, and then wic when creating the ext4 disk image will mount rootfs without /home, and then can i point to somehow to take just /home of built .ext4 and mount it to another partition? Nov 13 10:57:03 i'm not sure if I understood you correctly Nov 13 10:58:34 kpo: You'll need to create a custom wks file, the part entry for the rootfs will exclude everything under /home, then you'll add another part entry for home Nov 13 10:59:20 If you look at the existing wks file in meta-raspberrypi and at the output of `wic help kickstart` it should make some kind of sense Nov 13 11:08:41 You may need a separate step to create home.ext4 image and then use `part --source rawcopy ...` in your wks file Nov 13 11:11:04 armpit: aren't you supposed to be on vacation? Nov 13 11:34:26 paulbarker: yeah, I've been missing that home.ext4 image, my intuition was pointing me there but I was hoping that something will do this for me automagically :P will dive in, thanks! Nov 13 11:35:48 New news from stackoverflow: IR remote control using LIRC. (NEC) Nov 13 11:37:01 paulbarker: when searching after your suggestions i found this: https://stackoverflow.com/questions/56187209/yocto-create-and-populate-a-separate-home-partition it looks like i can use directory of /home without building separate home.ext4 image: --rootfs-dir=${IMAGE_ROOTFS}/home Nov 13 11:37:16 I'll try it in a minute Nov 13 11:41:21 kpo: let me know if it works, I thought there was a way to do that but I couldn't see it in the docs Nov 13 12:01:52 paulbarker: it will be something more than a minute - i need to fix a little error in wic Nov 13 12:01:57 | WARNING: exit code 1 from a shell command. Nov 13 12:01:58 | ERROR: Function failed: do_image_wic (log file is located at /home/kpo/git/zmorph3-yocto-project/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/zmorph-dev-image/1.0-r0/temp/log.do_image_wic.26815) Nov 13 12:01:59 ERROR: Task (/home/kpo/git/zmorph3-yocto-project/build/../meta-zmorph/images/zmorph-dev-image.bb:do_image_wic) failed with exit code '1' Nov 13 12:02:28 rather that: | output: install: cannot stat '/home/kpo/git/zmorph3-yocto-project/build/tmp/deploy/images/raspberrypi-cm3/bcm2708-rpi-0-w.dtb': No such file or directory Nov 13 12:02:45 the name of dtb changed from 0-w to zero-w :P Nov 13 12:05:54 New news from stackoverflow: YOCTO Change kernel version and select drivers Nov 13 12:41:14 Hmmm, why won't they compile with mingw... Having trouble with: nativesdk-ncurses, nativesdk-libxcrypt, nativesdk-gdbm and nativesdk-openssl Nov 13 12:42:30 nativesdk-curses die on compile error "pwd.h: No such file or directory" Nov 13 12:46:01 nativesdk-libxcrypt has same for netinet/in.h Nov 13 12:47:07 nativesdk-gdbm cannot find pwd.h Nov 13 12:47:20 Sorry, ncurses cannot find sys/poll.h Nov 13 12:54:39 wertigon: fwiw, thud oe-core + thud meta-mingw built meta-toolchain fine here Nov 13 12:56:19 lets try ncurses Nov 13 12:56:22 rburton: like already sugegsted a couple of times, i suspect some part of the layer stack respectively the machine/distro to mess it up. Nov 13 12:56:32 possibly, but thud is old for mingw support Nov 13 12:56:39 yeah that fails here Nov 13 12:56:47 all the good work JPEW had done isn't in that branch Nov 13 12:56:56 Ok, i created my own layer and i used the bbappend. Ist there a way to modify and not override SRC_URI? Nov 13 12:57:03 (and not only append ;) ) Nov 13 12:58:12 rburton: Can I build a simple test image that omits most of my code? E.g. is it possible to build poky-minimal -c populate_sdk? Nov 13 12:58:30 you can build any image for populate_sdk Nov 13 12:58:36 start with meta-toolchain though, that works here Nov 13 12:58:47 Yeah, meta-toolchain fails :P Nov 13 12:58:52 where does that fail Nov 13 12:59:44 Somewhere in mingw, exact place I cannot say more than the packages given above Nov 13 13:00:25 But I have not omitted any layers right now - if I omit everything but meta-openembedded stuff and mingw, it should work yes? Nov 13 13:00:38 well ncurses isn't part of meta-toolchain Nov 13 13:00:40 neither is openssl Nov 13 13:00:52 so what one precisely is failing Nov 13 13:01:18 paulbarker: wee, the way I linked to on stackoverflow worked :) thank you for help! Now, I have to merge it with update system, rauc :) Nov 13 13:01:39 https://pastebin.com/yJUnZHej Nov 13 13:03:39 rburton: Those are the error messages I got last time I tried, right now I did a populate_sdk -k and waiting for that to finish Nov 13 13:03:49 wertigon: looks like something in your distro is adding those to meta-toolchain then Nov 13 13:03:52 as they're not in mine Nov 13 13:04:13 maybe meta-arago is breaking things Nov 13 13:04:35 relatively easy test is to do just poky thud + meta-mingw thud, build the toolchain Nov 13 13:04:52 Hmm, yeah Nov 13 13:04:53 assuming that works - which it should as it works here - then you've at least isolated it to something in your config Nov 13 13:05:02 add meta-arago and see if that breaks Nov 13 13:05:56 Ok, so I basically strip all layers but poky, openembedded and meta-mingw for a starter? Nov 13 13:06:14 Once my current failbuild is complete that is :P Nov 13 13:06:21 09:17 < letothe2nd> other than that, i can only say, start with poky only, try, add layers one after the other. that stack is rather big after all, hard to say where things go wrong Nov 13 13:06:27 literally 4 hours ago Nov 13 13:06:37 Yeah, I know Nov 13 13:06:45 yeah what letothe2nd said :) Nov 13 13:06:54 start from scratch, poky + meta-mingw, new build dir Nov 13 13:06:56 thanks for not listeing. Nov 13 13:06:57 point at your DL_DIR etc Nov 13 13:07:20 set machine to qemuarm, sdk to mingw. Nov 13 13:07:40 letothe2nd: Sorry, thought I was only missing a host package or somesuch, but turned out I was wrong Nov 13 13:07:57 fwiw i'm in two chats simultanously moaning about arago :) Nov 13 13:08:27 Yeah, it isn't the best that yocto provides, this is very true. :) Nov 13 13:08:44 cough not actually yocto cough Nov 13 13:08:59 rburton: even that Nov 13 13:09:09 arago is to yocto what mint is to ubuntu :P Nov 13 13:09:14 lol Nov 13 13:09:22 atleast IMO Nov 13 13:09:24 i tried and explained, nobody listened, won't happen again. Nov 13 13:09:30 wertigon: you are SO wrong. Nov 13 13:09:36 but i'll be silent now. Nov 13 13:10:03 leto: Arago is to yocto what Redhat is to debian? Nov 13 13:12:04 Point is, it is a yocto derivative distribution that kinda bastardizes things for better and worse :P Nov 13 13:12:16 sorry meta-distribution Nov 13 13:18:25 OpenSSL seems to be a known problem at least; https://lists.yoctoproject.org/pipermail/yocto/2018-June/041587.html Nov 13 13:26:43 rburton, any chance of getting a summary of arago issues for denix ? Nov 13 13:27:26 my issues with the ti stuff is poor seperation between bsp, demo-sp, and distro Nov 13 13:41:18 Crofton|work: random cursing at toolchain, debugging now Nov 13 13:46:44 urg meta-linaro I bet Nov 13 13:47:53 Crofton|work: I agree, there is a reason we switched to Yocto and manually pull in ti stuff now, instead of basing all our work on the arago distribution :P Nov 13 13:48:13 Anyhow, build finally done, now to start cutting! Nov 13 13:55:20 Crofton|work: indeed Nov 13 13:55:34 Crofton|work: from a minimal config i can't even make it build anything Nov 13 13:58:25 it is a frustrating situation Nov 13 14:03:59 ERROR: external-linaro-toolchain-2017.11-r0 do_install: oe_multilib_header: Unable to find header bits/floatn.h. Nov 13 14:04:22 sumo oe-core/meta-linaro-toolchain and 2017.11 toolchain tarball Nov 13 14:04:34 obviously doing something wrong but not sure what Nov 13 14:13:02 Ok, by brutally cutting out all ti-related stuff it seems to build just fine; Narrowed it down to one of meta-ti, meta-arago, meta-processor-sdk or our own layer Nov 13 14:14:28 1000 packages left to build however. Nov 13 14:26:34 900 packages left, still going strong :) Nov 13 14:27:05 Building meta-toolchain for qemux86 Nov 13 14:27:49 rburton, ah yes you need to cut out the linaro toolchain Nov 13 14:28:00 In meta-arago Nov 13 14:29:29 rburton: In meta-arago-distro/conf/layer.conf remove linaro-toolchain and meta-optee from LAYERDEPENDS_meta_arago_distro Nov 13 14:30:14 rburton: And in meta-arago-extras/conf/layer.conf remove linaro-toolchain from LAYERDEPENDS_meta-arago-extras Nov 13 14:30:48 don't use external toolchain seems like a best advice thing to me Nov 13 14:31:22 rburton: Yep Nov 13 14:31:32 But unfortunately ti doesn't think so :P Nov 13 14:31:44 Not to mention the linaro toolchain is now deprecated Nov 13 14:33:02 https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a <-- What linaro recommend you get now Nov 13 14:40:36 I mean, there is a reason I'm trying to build mingw; the alternative is to get msbuild to be nice to WSL. Nov 13 14:54:59 wertigon: We used to use the precompiled toolchain per TI's recommendation... swicthed to the OE built one and never looked back Nov 13 14:55:53 Also, as rburton said thud in meta-mingw is old. If it gives you a lot of grief, I'd try master :) Nov 13 14:59:18 JPEW: Yeah, but master seems to want zeus, can I just replace to thud? Nov 13 14:59:20 :) Nov 13 14:59:47 Ok, it is NOT ti at least! Wooh! Nov 13 15:00:49 I will try master if this fails Nov 13 15:01:28 wertigon: Adding "thud" to LAYERSERIES_COMPAT temporarily should let you try it. It might help eliminate some of sources of failure, or it might explode spectacularly :) Nov 13 15:01:30 Crap, clock is ticking... Need to head home soon >_< Nov 13 15:01:53 JPEW: Then I shall try it, it can't get any worse ;) Nov 13 15:05:56 The layers it blew up on; meta-oe, meta-oe/networking, meta-oe/python, meta-oe/gnome, meta-browser, meta-clang, meta-qt5, meta-yocto-bsp, meta-java Nov 13 15:06:49 meta-java, meta-browser and meta-gnome are easy to cut away if necessary. Nov 13 15:07:33 Python too Nov 13 15:07:44 (for SDK that is) Nov 13 15:08:14 clang, yocto-bsp and meta-mingw remain Nov 13 15:08:35 I will attempt to build those tomorrow Nov 13 15:08:40 Good evening! Nov 13 16:06:36 New news from stackoverflow: autoconf unable to find pkg-config (PKG_PROG_PKG_CONFIG failing) Nov 13 16:27:30 how can I debug YP errors with metadata being inconsistent during parsing? I wanted to use sigdata and diff those but unfortuantely it happens before those are created. Any pointers? (I'm not working on it yet, on a colleague's plate atm, just trying to help him with some pointers) Nov 13 16:27:45 letothe2nd: and you'll like to here that this happens with a vendor BSP layer :D Nov 13 16:27:50 hear* Nov 13 16:34:01 metadata being inconsistent = basehash changed during parsing Nov 13 16:53:30 Crofton|work: poor separation of bsp and distro? it is all separated into different layers, how much more separation do you need? please provide specific examples Nov 13 16:59:10 rburton, JPEW: fwiw, passing TOOLCHAIN_TYPE=internal cuts out external linaro/arm toolchain completely. supporting all that is a requirement I cannot avoid and dealing with it and listening to complaints gives me gray hair... Nov 13 17:00:23 denix: That's fair :) I'm glad it does work with the internal TC Nov 13 17:00:48 and demo Nov 13 17:01:08 note I can't get the open cl stuff to build Nov 13 17:01:48 at least have made an image that boots once, unlike Xilinx and their ultra96 borad Nov 13 17:06:13 oe/yocto-savvy users complain that arago is too unorthodox and deviates from pristine Nov 13 17:08:19 and users from the other side of the barricades complain that yocto is too complicated and mind-twisting and demand even more dumbing down Nov 13 17:09:15 denix, common problem :) Nov 13 17:10:15 Crofton|work: that open cl stuff is quite old, based on llvm version that was never in oe-core. it's being worked on to update it to a recent llvm from oe-core - that would allow it to be detached from arago and be in meta-ti bsp only Nov 13 17:10:40 that would be great Nov 13 17:11:13 I would love to offload some gnuradio stuff into the dsps, and that look slike the path of least resistance Nov 13 17:13:05 Crofton|work: the problem may be common, but I'm deadly tired of feces-throwing sessions in public forums - #yocto and yocto list... :( Nov 13 17:13:32 happens Nov 13 17:13:39 should have seen feces throwing at OEDEM Nov 13 17:13:58 There is a lot of frustration with BSP's, not just TI Nov 13 17:14:08 if I knew that was going to happen, I would have sent a proxy Nov 13 17:14:44 on zeus and $random bsp, weston depends on wayland-protocols which provides wayland-protocols.pc in sysroot too according to buildhistory. yet weston fails to find wayland-protocols.pc and it's not in the recipe sysroots. /me splits hair.. Nov 13 17:16:13 Crofton|work, armpit: yeah, I've heard some of it second-hand. I suddenly was glad I missed all that! Nov 13 17:17:13 denix, I just want to throw things for no good reason. I was not there either Nov 13 17:17:48 armpit: lol Nov 13 17:18:11 armpit: you missed oedem??? how come? early vacation? Nov 13 17:18:50 I had to leave after elce for vacation Nov 13 17:20:30 I thought the pitchforks were coming out and going after Bill since he repped a silicon/bs supplier :) Nov 13 17:20:38 How was vacation? Nov 13 17:21:01 armpit: yeah, I recall you mentioning that before... Nov 13 17:21:36 Crofton|work, nice. Nov 13 17:25:08 I have to leave directly after ELC, so I ammy make you my proxy for anything that happens :) Nov 13 17:25:16 Crofton|work: the community is becoming too radical lately, it's rahter sad. used to be a single person we all knew, now it's an entire lynch-mob... Nov 13 17:25:39 It is growing Nov 13 17:25:56 ffs, "bitbake -c cleansstate wayland-protocols && bitbake wayland-protocols" and files appear. sstate not reliable then.. Nov 13 17:26:11 But seriously, we need to set better expectations for BSP's Nov 13 17:27:19 Crofton|work: like what? Nov 13 17:28:51 pass yocto check layer Nov 13 17:29:24 review minutes from OEDEM Nov 13 17:30:32 Crofton|work: the world is changing - new SOCs are getting more complex and heterogeneous, even Linux no longer fits the bill and can support everything as a single/main OS... Nov 13 17:30:59 multiconfig :) Nov 13 17:31:13 You missed aehs29 talk Nov 13 17:31:15 Crofton|work: meta-ti passes yocto check layer - still not good enough Nov 13 17:31:35 Crofton|work: link for the talk? Nov 13 17:31:35 my immediate issue is the one thing I need to do, I couldn't Nov 13 17:31:50 aehs29, got a link handy Nov 13 17:31:52 more requirements: don't break bitbake --runall=fetch, don't break sstate, don't break rm_work Nov 13 17:32:10 * Crofton|work is mining his office to lcear a path to the hunidifier to avoid board carnage Nov 13 17:32:11 Crofton|work: your immediate issue is not BSP related :) Nov 13 17:36:17 from my idiot user POV it is :) Nov 13 17:36:38 fine line between providing access to hw, and blingy demo that sucks in other layers :) Nov 13 17:37:00 If I wanted to do easy stuff, I would use a pi3 Nov 13 18:14:31 denix: Crofton|work https://www.youtube.com/watch?v=mFgiIXv7b5U&list=PLbzoR-pLrL6pamOj4UifcMJf560Ph6mJp&index=50&t=0s Nov 13 18:15:06 aehs29: yeah, found the video, where are the slides? :) Nov 13 18:15:31 Crofton|work: sadly I missed the throwing of feces at oedem, I had to leave just after elce just like armin Nov 13 18:17:11 denix: I think the slides are on the sched webpage for the event, although I'd recommend the video because there was a demo on video and the system wouldnt allow me to upload the presentation with videos Nov 13 18:18:20 denix: so the multiconfig part of the presentation is kind of missed without them Nov 13 18:18:27 denix: https://osseu19.sched.com/event/TLCt/one-build-to-rule-them-all-building-freertos-linux-using-yocto-alejandro-hernandez-xilinx Nov 13 18:18:39 aehs29: thanks Nov 13 18:19:00 aehs29, I'm sure having another BSP peddler in the room would hav espread th eload :) Nov 13 18:21:29 Crofton|work: it's all fun and games, but heckling will cause more harm than good - don't be too surprised if Bill takes TI to debian and abandons yocto ship... :) Nov 13 18:23:27 denix, We can't keep papering over issues Nov 13 18:23:30 aehs29: so, I've looked at mc some time ago when it wasn't mature enough. now glancing over your video I had a question - is mc only configurable from local.conf? is it possible to configure everything entirely in a layer? say, layer.conf Nov 13 18:29:52 Crofton|work: I told you already - majority of customers are NOT yocto-savvy. from Bill's (and rest of mgmt) perspective, yocto is a tool, not a product! Nov 13 18:35:15 and that is the gap the developers need to be working on bridging Nov 13 18:35:55 denix: IIRC, you can put multiconfig files in layers now Nov 13 18:36:44 So, I think you can stuff the pre-canned DSP multiconfig and ancilliary processors in your layer for others to use Nov 13 18:37:01 JPEW: ok, that would be great, need to experiment again with mc - it's been a while since last time Nov 13 18:37:13 denix: It's gotten a lot better Nov 13 18:39:15 JPEW: what about the glue config? having all separate processor configs available is useless, if they are not automatically and properly bound together by BSP layer config... Nov 13 18:40:00 denix: Sorry, not quite sure I follow, can you clarify? Nov 13 18:40:46 If you are treating the DSP as something the YP can build for (vs just include this firmare blob and driver into your image).. then a hetergeneous (multiconfig) may make sense Nov 13 18:41:14 Something I'm currently working on trying to define after OEDEM.. just havn't had time to put the thoughts together and sent it to the oe-architecture mailing list yet Nov 13 18:41:57 JPEW: say, I got all separate configs for DSPs, MCUs and GP cores, how do I now bind them all together into a single SOC machine? Nov 13 18:42:38 fray: yeah, discussing multicore specifically for this - to build pieces of hetergeneous SOC Nov 13 18:43:05 What I'm looking at suggesting is effectively: Nov 13 18:43:11 denix: You can define dependencies between multiconfigs using "mcdepends"... effectively is allows a given task in a recipe from one multiconfig depend on a recipe/task in another multiconfig Nov 13 18:43:12 System (or board) is the local.conf Nov 13 18:43:29 then there are one or more 'multiconfig' .confs for each thing the yocto project can target.. linux, freertos, etc.. Nov 13 18:43:59 the system/board can then (via dependencies) control what is built, and call wic (or other tooling) to assemble the final image for deployment via whatever mechanism.. Nov 13 18:44:08 i.e. sd card, multiple partitions for each component Nov 13 18:44:50 There are lots of ways to use mcdepends; one "simple" way is to make your final image recipe mcdepend on the DSP target binary recipe/task, then shove it into the image in the proper path... but there are better ways also. Nov 13 18:44:51 fray: that's exactly my point - why is the local.conf defines the system/board? it should be conf/machine/.conf Nov 13 18:44:58 add this this the concept of a system (or board) device tree.. the primary local.conf (system machine) can use this and to define the configurations and dependecies dynamically.. Nov 13 18:45:10 local.conf: MACHINE = 'myboard.conf' Nov 13 18:45:24 multiconfig/xilinx_a15.conf Nov 13 18:45:30 multiconfig/xilinx_a72.conf Nov 13 18:45:35 each would have their own 'MACHINE defined'.. Nov 13 18:45:40 fray: A repository that has some multiconfig examples would be great Nov 13 18:45:53 and then local.conf uses dependencies to pull in those based on the system device tree Nov 13 18:45:58 JPEW: yeah, also looking for examples Nov 13 18:46:13 JPEW, first order of business is email to architecture list.. examples will come after we get a few things figured out.. Nov 13 18:46:30 the issue right now is nobody has standard terms for this, so just discussing it people don't understand what we're discussing Nov 13 18:46:55 If I could get over the cold I got right after Lyon, I'd construct and send the initial email to get started.. Nov 13 18:47:08 I gave a talk that had some multiconfig information at the platform security summit.... doesn't look like the video is up yet though. Nov 13 18:47:14 my biggest concern is that multiconfig lives in conf/ and is driven by local.conf, which is all user-owned. I want my BSP layer to define all multiconfig/ files and bind them together by a MACHINE Nov 13 18:47:33 denix, it can certainly work that Nov 13 18:47:52 I've got ideas on how, without any change to bitbake.. Nov 13 18:48:43 MACHINE is the unit of definition for "what is being built".. So a machine is one component of a heterogenous configuration.. I keep hearing them called "sub-machines" or "soc components" or... it's MACHINE.. cause that is the term we have, and we don't want to redefine it.. we just need to clarify it's usage/meaning.. Nov 13 18:48:53 we need a level 'above' machine to define a system or board.. Nov 13 18:48:59 fray: so, what I'm looking for is local.conf only sets MACHINE=soc1 and BSP layer pulls all necessary multiconfig/* files automatically for that MACHINE. then you switch MACHINE=soc2 and BSP pulls another different set of multiconfig/* files automatically Nov 13 18:49:07 that way machine can stand alone.. and the system/board does the things above it Nov 13 18:49:53 board says: I have these 'machines' on it.. and then the appropriate multiconfigs are brought in based on that.. Nov 13 18:50:13 sure, another level to define BOARD that pulls multiple MACHINE configs would also work Nov 13 18:50:15 denix: yeah its gotten a lot better, after I talked with Richard, I think they can be dfined on layer.conf as well Nov 13 18:50:15 I think I know the 'how', but we need to define a few things first Nov 13 18:50:41 and I'm working on fine tuning the multiconfig work to be more user friendly for SOCs Nov 13 18:50:45 hopefully for th next release Nov 13 18:50:53 yup, that will help.. Nov 13 18:51:14 I will merge the multiconfig example on meta-freertos later today btw Nov 13 18:51:26 the big thing for me, is I want it driven (how the 'machines', components of the board, are wired and shared resources to define the settings without having to implement 100 different machines for all possible configurations) Nov 13 18:51:59 thus I want the main board to be able to define the configurations for the machines.. the machines (for this) could be loosely defined, with specific definitions coming from a system/board DTB Nov 13 18:52:36 fray, aehs29: sounds promising Nov 13 18:52:42 i.e. a board has 4 cortex a72 cores.. I don't want 4 machines.. I want 4 multiconfigs to use the same 'machine' with 4 variants (in other the ways these things are wired up) Nov 13 18:53:17 ...4 variants (in only the ways...) Nov 13 18:53:26 let's move the discussion to oe-architecture list Nov 13 18:53:28 I think it would definitely be something useful for heterogeneous archs, which a lot of people are using, probably the most difficult part will be on agreeing on what we'd call it, BOARD, SYSTEM?, SOC?, I'll try to get something working and send an RFC to see what people think Nov 13 18:53:30 I swear this cold is making my typing even worse then normal Nov 13 18:54:03 and with heterogenous computing, I'm leaning toward system.. because it might be multiple "boards" that all share resources.. Nov 13 18:54:58 denix: sounds good Nov 13 18:55:27 denix: just to be clear, you can define multiconfigs in your layer now Nov 13 18:55:28 fray: true, system just seems too generic Nov 13 18:56:07 it does, but in many ways system MIGHT be the right level.. Nov 13 18:56:16 true as well Nov 13 18:56:17 but that's why we need the discussion.. it might turn out board is the right level Nov 13 18:56:24 RP: would that be layer.conf? Nov 13 18:57:00 fray, aehs29: do we need a different entity for system/board? can we re-use MACHINE to be hierarchical? Nov 13 18:57:08 re-use machine Nov 13 18:57:51 we could certainly defined say 'SYSTEM' or 'BOARD', but under the hood, it should just become machine and use the existing machine wiring in everything Nov 13 18:57:59 again, need to figure that out.. Nov 13 18:58:03 denix I think you just asked the right question, I just dont want to break MACHINE functionality Nov 13 18:58:13 fray: yeah, conf/soc.conf to pull conf/a72.conf and conf/dsp.conf and conf/mcu.conf, etc Nov 13 18:58:17 exactly.. I don't want 'sub machines'.. and I don't want to break anything existing Nov 13 18:59:05 on the other hand, multiconfig specifies things like distro, libc, etc... Nov 13 18:59:48 which is exactly what we want.. like I said, heterogeneous computing.. not 'this thing has a .... and we just need Linux to load firmware onto it'.. that is traditional firmware model Nov 13 19:00:12 some cores might be FreeRTOS, some might be musl, and some might be full on glibc like stacks.. (and some might even be containers) Nov 13 19:00:57 but nothing here should prevent a developer from working on a 'piece' of the stack using the right MACHINE and associate configs.. it's the system builder that puts it together Nov 13 19:01:08 * fray needs luck.. bbiab Nov 13 19:03:50 denix: here is a simple example: https://paste.debian.net/1116099/ Nov 13 19:04:36 denix: in this case I've chosen to add multconfigs to a distro, where one even references another subclass. You can then do "bitbake mc:musl:bash" or "bitbake bash" Nov 13 19:05:00 it won't quite work since you need to set TMPDIR to be non-overlapping but you get the idea - its entirely contained in the distro layer Nov 13 19:05:26 denix: you could do something with machines in a BSP in much the same way Nov 13 19:05:57 with some TMPDIR values in the multiconfig, this would work Nov 13 19:07:14 RP: oh, this is nice! so, if I set TMPDIR="tmp-${DISTRO}-${LIBC}" it would separate them properly, right? Nov 13 19:08:11 denix: yes Nov 13 19:10:47 heh, luckily I was already doing it to separate distros and internal/external toolchains... :) Nov 13 19:11:20 can't wait for OEDAM in Texas.. wonder what will be thrown there Nov 13 19:12:08 oh wait, Texas is open carry.. Nov 13 19:12:49 heh Nov 13 19:20:24 RP: is multiconfig/default.conf gets included automatically when mc: prefix is not used? Nov 13 19:28:47 denix: no, local.conf is used Nov 13 19:28:55 armpit: everythings bigger in texas Nov 13 19:29:25 denix: default.conf -> local.conf Nov 13 19:52:19 interesting what i seem to have triggered at YPS/OEDEM. i actually think of meta-ti as one of the "good" BSPs, even tried to use it as explanation vehicle during my doomed live session yesterday Nov 13 19:58:25 ti socs are complex, lots of interesting features to try out Nov 13 19:58:48 LetoThe2nd: ha, never underestimate people's ability to demean everything around! :) Nov 13 20:00:15 the things that really deserve a beating are like, a bsp that forces you to use a baked in distro enable the universe and everything beynod Nov 13 20:00:48 for the bbb i can add meta-ti and set machine. voila, i get a build inluding wic.xz Nov 13 20:01:16 i think we can all agree on more complex cases being more complex, but for starting out it is quite wellbehaved, IMHO. Nov 13 20:02:56 and more complex features are not yet fully or easily supported - see the above discussion on multiconfig for example... Nov 13 20:03:43 yeah and we will always find somebody who thinks this is a major pain point. Nov 13 20:04:17 i tend to get angry if a "bsp" literally only works for exactly one image+distro+machine combination. Nov 13 20:05:30 indeed Nov 13 20:24:35 * armpit gets angry at everything Nov 13 20:25:44 armpit: that sounds bad Nov 13 20:26:07 armpit: that sounds reasonable. Nov 13 20:26:11 * armpit or am I just being German?? Nov 13 20:26:25 denix: as aehs29 says, default is local.conf alone Nov 13 20:27:23 RP: what's multiconfig/default.conf is there for in oe-core? Nov 13 20:27:23 * LetoThe2nd suspect armpit just has had a proper dose of german beverages. Nov 13 20:28:12 denix: there is no default.conf, the default configuration is whatever local.conf would be with no multiconfig file added Nov 13 20:28:12 LetoThe2nd: it's just past noon for armpit - right time to start drinking! Nov 13 20:28:48 denix: :) Nov 13 20:29:26 that was last week. had loads of Piraat Belgian beer on the ship Nov 13 20:30:47 RP: https://git.openembedded.org/openembedded-core/tree/meta/conf/multiconfig/default.conf Nov 13 20:31:11 RP: it's empty, but it's there. I was assuming it would be used when mc: is not specified... Nov 13 20:31:38 armpit: https://70000tons.com ? Nov 13 20:33:20 denix: sorry, you are right. That was added so we could use require in local.conf Nov 13 20:33:27 er, in bitbake.conf Nov 13 20:34:13 denix: otherwise it could have been "include conf/multiconfig/${BB_CURRENT_MC}.conf" which wouldn't have been easy to debug as no failure message about missing files Nov 13 20:34:44 RP: ok, makes sense Nov 13 20:36:20 LetoThe2nd, wait wait wait, when did Metal heads need sunscreen or use a Jacuzzi ? Nov 13 20:37:18 armpit: rule #666 applies to everything, even including cruises. "if it exists, there is a metal version of it." Nov 13 20:39:24 LetoThe2nd, after that cruise, you will be Ferrous Oxide Nov 13 20:39:30 RP: so, I'm now wondering what would happen when some conf/machine/{MACHINE}.conf sets BBMULTICONFIG... Nov 13 20:40:36 denix: that works, thats part of what I'm doing to make it user friednly for heterogeneous archs Nov 13 20:40:53 denix: should be fine Nov 13 20:41:18 aehs29, RP: yeah, I'm also now experimenting in that direction... Nov 13 20:41:47 armpit: :) Nov 13 20:42:32 armpit: i think on a cruise like this theres a *LOT* of fun to be had. Nov 13 21:47:55 * rburton s/master/dunfell/ Nov 13 21:48:38 I was hoping for emojis Nov 13 21:48:56 haha Nov 13 21:49:10 yocto "🤦🏻‍♂️" 3.1 Nov 13 21:49:25 I don't even dare suggesting someone try this with git push to contrib Nov 13 21:49:48 we'll probably have weeks of people and broken clients or something Nov 13 21:49:55 Switched to a new branch '🔥' Nov 13 21:49:59 can i push Nov 13 21:50:00 please Nov 13 21:50:03 rburton: hahaha Nov 13 21:50:42 rburton: I am actually curious what would happen but its a really bad idea Nov 13 21:50:50 well, the internet says it works Nov 13 21:50:51 do they have locals for that ? Nov 13 21:51:56 https://github.com/rossburton/ross-tools/tree/🔥 Nov 13 21:52:10 rburton: http://git.yoctoproject.org/cgit.cgi/poky-config/log/?h=%f0%9f%94%a5 :) Nov 13 21:52:21 http://git.yoctoproject.org/cgit.cgi/poky-config/log/?h=🔥 Nov 13 21:52:23 whoop whoop Nov 13 21:52:54 this could be so bad... :) Nov 13 21:53:20 shockingly tab completion is suboptimal Nov 13 21:53:29 * RP removes that Nov 13 21:53:43 hey, this is pyro Nov 13 21:53:54 lol Nov 13 21:54:02 * RP was thinking that Nov 13 21:54:29 🤺 is warrior Nov 13 21:54:38 disappointed there's no sumo emoji Nov 13 21:55:03 shame there aren't TA kbot emojis Nov 13 21:55:15 is 🌬 good enough for zeus? Nov 13 21:55:46 rburton: can you picture this in meetings? Nov 13 21:55:54 then we can change the docs to emojis too Nov 13 22:02:56 Invalid branch: 🔥 Nov 13 22:05:39 aehs29: if it was poky-config I removed it Nov 13 22:09:34 haha yeah it was Nov 13 22:29:41 RP: what does "Variable key VAR1 (VAL1) replaces original key VAR2 (VAL2)" warning mean and how to resolve it? Nov 13 22:31:12 denix: it means that two variables clashed with differing values and bitbake isn't sure you meant to do that Nov 13 22:31:27 denix: stop them clashing? ;-) Nov 13 22:31:49 RP: heh, that's what I'm trying to do :) Nov 13 22:32:28 denix: its where you'd have something like FOO${PN} and FOO${BPN} and they clash when PN == BPN Nov 13 22:33:19 FOO${PN} = "A", FOO${BPN} = "B", should it be A or B? Nov 13 22:34:49 RP: hmm, it seems for me it happens when either PN or BPN are not set Nov 13 22:35:48 FOO${X} = "A", FOO${Y} = "B" and then only X is set, I get warning avout FOO${X} clashing with FOO Nov 13 22:49:19 denix: hmm, its possible the check is too sensitive Nov 13 22:49:39 Its also possible its expanding ${X} to "" I guess Nov 13 22:49:50 whether it should be, good question Nov 13 22:49:56 kergoth: do you remember what this should do? Nov 13 22:51:32 That shouldn't be the case, our expansion never expands an undefined variable to the empty string, i don't think key expansion was handled specially.. an undefined var should be left as is Nov 13 22:53:28 kergoth: that would be what I'd have said without looking at the code Nov 13 22:54:46 RP, kergoth: ok, thanks. let me look into it a bit closer then... Nov 13 22:56:12 denix: I just checked and it is using the standard expand call so it should not be turning it into "" unless that variable is set to something Nov 13 22:56:22 well, set to that Nov 13 22:57:46 armpit: I backported that fetcher bug that people all suddenly seem to be running into to the stable bitbake branches. Nov 13 22:58:00 well, the fix Nov 13 22:58:13 perhaps we should backport more bugs Nov 13 23:05:15 hi Nov 13 23:13:39 Is there a way with wic to put something at a specific location? Nov 13 23:13:57 right now, I'm using size, which seems very hackish Nov 13 23:14:12 RP, I noticed that.. thanks Nov 13 23:14:32 you want me to backport more bugs? Nov 13 23:14:45 I can do that ; ) Nov 13 23:14:48 armpit, I thought that is what you did? Nov 13 23:15:05 yep Nov 13 23:16:33 RP, it comes down to the idea of community support.. etc. I will keep it in mind Nov 13 23:17:01 Crofton|work, if it wasn't for S/W we wouldn't have any bugs Nov 13 23:28:03 armpit: nice work with the manual QA tests btw Nov 13 23:28:06 jonmason: what exactly do you mean "put something at a specific location"? write some binary stream at a specific offset in the image? Nov 13 23:30:57 yes Nov 13 23:31:03 right now, I have things like this Nov 13 23:31:14 part spl --source rawcopy --sourceparams="file=fip.bin" --ondisk mmcblk0 --no-table --align 4 --size 7M Nov 13 23:31:29 so that the next part is at the offset I want Nov 13 23:33:38 jonmason: does that make file-fip,bin be written at 7M offset in the image? Nov 13 23:34:19 well, its the next thing that needs to be at the 8M offset Nov 13 23:34:24 It's really hacky Nov 13 23:34:46 I think there are hard coded offsets in u-boot/ATF that are expecting certain offsets Nov 13 23:37:18 * armpit thinks jonmason and denix need bigger Arms ; ) Nov 13 23:37:56 RP, thanks Nov 13 23:38:12 armpit: I have Yocto image booting on the solidrun lx2k Nov 13 23:38:18 16x A72 Nov 13 23:38:58 this thing might be powerful enough to do some small builds Nov 13 23:39:05 and we need a bigger armpit to go with those Arms... :) Nov 13 23:39:22 thus the reason why I am asking. Lots of hacks in the pre-Linux boot Nov 13 23:39:59 I'll push the meta layer tomorrow and cringe while everyone flays me for the ugly hacks I did to get it working Nov 13 23:40:44 wedding anniversary, gotta go Nov 13 23:40:49 jonmason: yeah, one of our platform's ROM expects to load SPL from a specific hardcoded offset on MMC, hence my questions Nov 13 23:41:22 denix: yes, I expect this is the "answer". Just making sure I'm not making a fool of myself :) Nov 13 23:42:26 jonmason: heh :) if you find a better/proper way, please let me know Nov 13 23:55:24 jonmason, don't be an armpit Nov 13 23:57:16 heh Nov 14 02:28:13 My Build Appliance (systemd) cant start console inside VirtualBox/Qemu... Nov 14 02:47:43 Anybody run Build Appliance with systemd ? It can't start console on ttyS0 **** ENDING LOGGING AT Thu Nov 14 02:59:58 2019