**** BEGIN LOGGING AT Mon Feb 10 02:59:58 2020 Feb 10 07:42:15 good morning Feb 10 07:43:22 morning Feb 10 07:53:56 I have a recipe which puts a .a library in ${D}${libdir}, headers in ${D}${includedir}/ and .pc files in ${D}${libdir}/pkgconfig. That works fine with other recipes, but when I build a sysroot based on an image which includes packages which depend on that recipe, none of those files end up in the final sysroot. Why's that? Feb 10 07:55:45 mort, sounds like those are files that go in the -dev package Feb 10 07:55:56 yeah Feb 10 07:56:18 mort, your image includes packages that DEPENDS on that recipe ? DEPENDS is just build-time dependencies Feb 10 07:56:39 but SDKs are for being able to build software, right? Feb 10 07:56:56 they contain headers and .pc files and whatnot for other packages Feb 10 08:00:38 mort: Static library generation, for most cases, is now disabled by default in the Poky distribution. Disabling this generation saves some build time as well as the size used for build output artifacts. Feb 10 08:01:43 mckoan: this is a custom recipe though which only generates a static library; I suppose I should probably tell bitbake that I want static libraries for this package? Feb 10 08:03:29 mort: see DISABLE_STATIC Feb 10 08:04:25 mort, if none of the packages in your image RDEPENDS on your custom package, i guess it wont be in the SDK. maybe you need to explicitly add it to the image Feb 10 08:07:22 kroon: why would SDK generation care about RDEPENDS? Isn't RDEPENDS for runtime stuff, while the SDK exclusively deals with build time? Feb 10 08:08:45 mort, SDK contains everything needed to build against the libraries in the image. If your library isn't in the image, there is no need to put dev files for it in the SDK Feb 10 08:09:34 I suppose Feb 10 08:10:30 mort, you can always list extra packages that go only in the SDK Feb 10 08:11:33 mort, TOOLCHAIN_TARGET_TASK iirc Feb 10 08:14:52 does that variable go in the image recipe? Feb 10 08:15:32 mort, yes Feb 10 08:16:00 mort, append your custom -dev package to it Feb 10 08:19:48 the package is called libwebrtc; if I add only libwebrtc-dev, it complains that it depends on libwebrtc, if I add libwebrtc (or both libwebrtc and libwebrtc-dev), it complains that libwebrtc has no installation candidate Feb 10 08:20:04 I suppose I should make the recipe somehow add the .a file to the -dev package Feb 10 08:21:08 well, that wouldn't fix the fact that libwebrtc-dev depends on libwebrtc and libwebrtc (rightfully?) has no installation candidate Feb 10 08:24:05 mort, you might need ALLOW_EMPTY_${PN} = "1" in your recipe Feb 10 08:24:27 just found that in a stackoverflow answer actually, trying to build that now Feb 10 08:24:38 mort, so that you at least get an empty libwebrtc Feb 10 08:25:03 though since the recipe file technically changed, it's recompiling libwebrtc, and that's like 3000 C++ files so it's gonna take a while Feb 10 08:25:20 nvm, it didn't do a clean build, neat Feb 10 08:25:56 yeah bitbake is pretty neat Feb 10 08:26:48 it makes sense to allow an empty libwebrtc package, "%-dev depends on %" is a reasonable rule and there's nothing for libwebrtc to contain Feb 10 08:26:57 I suspect I may need to add -staticdev and not just -dev though Feb 10 08:27:32 mort, right Feb 10 10:01:02 uh, setting SDKPATH doesn't seem to work Feb 10 10:03:00 I'm doing `SDKPATH := "/opt/${DISTRO}/${PN}-${SDK_VERSION}" in the image bb file, and eventually, populate_sdk fails because it's unable to find `/build/tmp/work/ev2-poky-linux//1.0-r0/sdk/image/opt//<(PN)-(SDK_VERSION)>/sysroots/x86_64-pokysdk-linux/usr/lib/locale` Feb 10 10:05:28 `/build/tmp/work/ev2-poky-linux/1.0-r0/sdk/image/opt//<(SDK_VERSION)>/sysroots/x86_64-pokysdk-linux/usr/lib/locale/` exists, so it seems like some things are ignoring the SDKPATH? That's the path which would be populated by default if I hadn't touched SDKPATH Feb 10 10:16:03 mort, that one is set using a regular assignment in bitbake.conf, so I'd guess setting it to a custom value is not (yet) supported Feb 10 10:16:43 hmm, the docs say "Defines the path offered to the user for installation of the SDK that is generated by the OpenEmbedded build system. The path appears as the default location for installing the SDK when you run the SDK's installation script. You can override the offered path when you run the script." Feb 10 10:17:00 I don't know exactly which script it's talking about, but it seems to be designed to be overridden at least Feb 10 10:20:37 ohh, "the script" means the actual generated sdk install script Feb 10 10:25:23 that kind of sucks though, the default value of /opt// is kind of useless for us since we have three quite different images under the same distro name Feb 10 15:05:53 Jin^eLD: how close are you to submitting patches for meta-rockchip? Feb 10 15:06:28 hehe, I subscribed to the ML about 5 minutes ago and am writing a mail as we speak, good timing ;) Feb 10 15:06:47 actually I wanted to clarify some things first, because the patches should be "generic" and I stumbled upon stuff Feb 10 15:07:07 we could discuss here or would you prefer the ML? Feb 10 15:07:18 here's good Feb 10 15:07:33 OK, so one thing that I noticed is again wic related Feb 10 15:07:49 the include for those boards uses wic/rk3288-boot.wks Feb 10 15:08:06 JPEW: ^^ Feb 10 15:08:07 but the resulting fstab is kind of wrong, because without an --ondisk parameter Feb 10 15:08:16 wic will come up with its own device name Feb 10 15:08:31 so in the fstab postprocess by wic it all is based on /dev/sdaX Feb 10 15:09:33 the correct way for emmc would be something like: Feb 10 15:09:36 --ondisk mmcblk1 Feb 10 15:09:47 while for sd card images we should be passing --ondisk mmcblk0 Feb 10 15:10:14 I guess you can already see the problematic that comes from this: the common include of wic/rk3288-boot.wks... Feb 10 15:10:51 how would you go about it? Feb 10 15:11:24 locally I simply created my own wks file that is not using the include, but copied the contents of rk3288-boot.wks into it and added the --ondisk parameter as needed Feb 10 15:11:55 but I am not sure how a "nice" generic solution would look like i.e. for a patch? Feb 10 15:12:57 it would have been nice if we were able to pass variables in a .wks Feb 10 15:13:21 Jin^eLD: i haven't really dug into wic (yet) and it was JPEW who did all the wic stuff, i'm hoping he might chime in Feb 10 15:13:23 then some parameters, like boot args or device names could be tuned dymamically Feb 10 15:13:43 or maybe this could be a generic question to the mailing list Feb 10 15:13:55 yeah I think we had a short talk with JPEW here on friday Feb 10 15:14:25 but he was actually thinking that rburton was the wic guy, but rburton told us that he was not :) Feb 10 15:14:31 there are other boards, such as beagleboard, that have uSD and eMMC and build images for both, but offhand i'm not sure if it's one image or two Feb 10 15:14:48 that means *you're* the wic person! congrats :-) Feb 10 15:14:51 do you remember which layers they live in? Feb 10 15:15:14 https://layers.openembedded.org/layerindex/branch/master/machines/?q=beagle&search=1 Feb 10 15:15:28 lol heh, first time I used wic was... last week! we were stuck on a much older Yocto earlier so we had an own class that was dd'ing and partitioning itself Feb 10 15:15:54 but I guess discussing the wic toping on the ml would indeed be good Feb 10 15:16:02 which is what meta-rockchip was doing up until JPEW came along at the end of december Feb 10 15:17:12 hmm, seems like beagleboard is not using wic Feb 10 15:17:34 that is, if I am looking at the right conf Feb 10 15:18:07 yes, i was just noticing as well that meta-ti isn't using wic Feb 10 15:20:22 I think that'd be a good starting point: I'll ask on the ML about wic and variables, describing the scenario that we are facing Feb 10 15:20:47 and then we can go from there Feb 10 15:21:27 I don't think it makes sense for me to just go ahead and hack something without knowing the direction Feb 10 15:22:00 okay. the reason i was asking about patches is because i have a cleanup patch i'm about to post Feb 10 15:22:09 but if you were close, i would wait Feb 10 15:22:46 ah.. what I have so far mostly adds another machine.conf and a wks, so I dont think it would interfere in any way Feb 10 15:23:00 thanks for thinking about it though :) Feb 10 15:23:09 but I guess you can just go ahead, I'll rebase easily Feb 10 15:23:45 the README file should/might collide Feb 10 15:24:08 I did not touch that one yet, I usually leave the readmes for the very last step Feb 10 15:24:45 me not being ready is mostly due to what I found out regarding wic last friday and not knowing how to go about it in a generic way Feb 10 15:25:08 the meta-yocto-bsp layer supports beagleboard, uses wic, and has an --ondisk parameter: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/wic/beaglebone-yocto.wks Feb 10 15:25:34 but then again, it's not trying to support multiple machines with clever includes Feb 10 15:26:00 hmm but thats still interesting, I should try taht Feb 10 15:26:12 note: --ondisk mmcblk Feb 10 15:26:15 its not saying if its 0 or 1 Feb 10 15:26:25 yes, i thought that was funny Feb 10 15:26:44 however our problem is also that we need to add it to the bootloader line Feb 10 15:26:53 and it really needs to be the correct one there Feb 10 15:27:18 i.e. root=/dev/mmcblk0p7 or root=/dev/mmcblk1p7 Feb 10 15:27:28 depending on the sdcard or emmc image Feb 10 15:28:45 https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/wic/genericx86.wks.in Feb 10 15:28:54 who proesses the .in file? Feb 10 15:29:17 I assume thats being used to set the $EFI_PROVIDER Feb 10 15:29:19 part /boot --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --ondisk sda --label msdos --active --align 1024 Feb 10 15:29:25 nice! looks like you've found wic parameter passing Feb 10 15:30:12 oh hmm let me look at the wic class again Feb 10 15:30:53 I think you are right Feb 10 15:30:57 and look at the machine files Feb 10 15:31:06 conf/machine/intel-corei7-64.conf:WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot", "systemd-bootdisk-microcode.wks.in", "grub-bootdisk-microcode.wks.in", d)}" Feb 10 15:31:37 well thats not the same Feb 10 15:31:44 this is still OE level processing, setting the WKS_FILE variable Feb 10 15:32:19 I got more curious about the .in file, if that would allow var processing inside the wks Feb 10 15:32:24 then we could stisll use that rk3288 include Feb 10 15:32:27 *still Feb 10 15:32:30 but you could choose a wks file based on some criteria, and have wks files preparted for either case? Feb 10 15:32:51 either way, sounds like a step forward Feb 10 15:33:54 yes, true, that could be used to "select" either an sdcard wks or an emmc wks Feb 10 15:34:14 if ext == '.in' and os.path.exists(wks_file): Feb 10 15:34:19 that what I am looking at a swell Feb 10 15:34:31 its just not clear to me what exactly is being done differently in that case Feb 10 15:35:14 or does bb.parse do the magic? Feb 10 15:35:31 pfft, it's all magic! Feb 10 15:35:38 ...and witchcraft Feb 10 15:35:47 https://i.imgur.com/iZcUNxH.gif Feb 10 15:35:51 :> Feb 10 15:36:06 lol! Feb 10 15:36:59 actually JPEW and me did talk about another var on which the wks selection could depend (without having seen that intel wks example yet), but we were not sure how to present that Feb 10 15:37:16 because it would kind of extend the functionality i.e. introduce a new configuration parameter Feb 10 15:37:52 a configuration parameter which would be specific to the meta-rockchip layer and maybe not obvious for others Feb 10 15:38:48 that being said, even if it turns out that wic can process dynamic wks files - we'd still need to set the root param dynamically Feb 10 15:41:38 what's your view on this? should we go with RK_ROOT_DEVICE="mmcblk1" or something like that? if wic could process that - that'd be the solution Feb 10 15:42:04 if not then it would have to carry more meaning, like "sdcard" or "emmc" so that the appropriate .wks could be selected Feb 10 15:42:26 the class file talks about WICVARS Feb 10 15:42:53 yes, from the comment I understand that those vars are being written to some .env file Feb 10 15:43:08 I assume that this will define the wics environment when generating the image Feb 10 15:43:59 oh, it's a pre-set list Feb 10 15:44:11 yes, its in the class where you found the .in part Feb 10 15:44:14 just further up Feb 10 15:45:01 my assumption is that bitbake dumps the values of these variables into a file that wic can read and use Feb 10 15:46:14 although I was not able to grep out where someone would add EFI_PROVIDER to WICVARS Feb 10 15:46:19 so not sure how that works Feb 10 15:46:37 I guess I'll make a few tests tonight and we'll see, maybe all we need is already there Feb 10 15:47:42 Ya, sorry. I didn't think the --ondisk parameter did anything :( Feb 10 15:47:55 I didn't look hard enough apparently :) Feb 10 15:47:58 hey JPEW, are we nerd-sniping you again? =) Feb 10 15:48:03 sigh, more digging. but that always leads to understanding, which is nice Feb 10 15:49:10 JPEW: I came upon it when reading the wic docs, it said it modifies the fstab on the resulting image based on this param, then when I wondered why one of the partitions I added does not show up as mounted on the target I realized where the /dev/sda is coming from... Feb 10 15:49:19 I've seen the .in file processing which could be used, the thing I wasn't clear on was if the variables applied to include files Feb 10 15:49:47 Jin^eLD: Ah, ya. That would do it. Feb 10 15:50:13 I guess I'll just try this processing thing out Feb 10 15:50:30 if it works it'd be enough to define an overridable variable for the root parameter in the machine.conf Feb 10 15:50:51 that would spare us from having separate wks files for sd/emmc Feb 10 15:51:14 Jin^eLD: Ya, that could work... worth a try Feb 10 15:51:35 then the hardest thing would be to come up with a meaningful name for that variable ;) Feb 10 15:52:27 there are only 2 hard things in computer science... Feb 10 15:53:33 :) Feb 10 15:53:43 whats the other one btw? Feb 10 15:54:18 cache invalidation Feb 10 15:54:22 and off-by-one errors Feb 10 15:54:41 https://www.reddit.com/r/ProgrammerHumor/comments/6hbrfg/the_two_hardest_things_in_computer_science_are/ Feb 10 15:55:37 lol, the onion one is good.. and true Feb 10 15:56:34 bbl Feb 10 19:08:10 re Feb 10 19:08:25 tlwoerner, JPEW: it works! its indeed only necessary to rename the wks file to .in Feb 10 19:08:34 then you can use any variable set by OE Feb 10 19:08:41 and it gets correctly processed Feb 10 19:09:02 so we can pass the root device and don't have to split the wks for sdcard/emmc Feb 10 19:09:22 and we can also keep the generic rk3xx include part Feb 10 19:09:42 if we could agree on the naming I could prepare a patch Feb 10 19:10:31 i.e. naming for the root device, I would then use it in the wks.in for the --ondisk parameter and for the kernel command line Feb 10 19:11:02 is there any policy for layer specific configuration variable names? Feb 10 19:13:04 BOOT_DEVICE? RK_BOOT_DEVICE? RK_ROOT_DEVICE? Feb 10 20:05:47 did anyone had the chance to play around with swupdate and a double-copy setup? I am wondering if I should disable extlinux.conf and use the u-boot env or not Feb 10 20:25:21 Jin^eLD: Does it correctly do expansion down into the included files? Feb 10 20:36:21 crap... I did a cleanall on the image to be sure, of course after that it failed... Feb 10 20:36:23 so it doesn't Feb 10 20:37:23 I wonder why it did not notice that earlier in the incremental build Feb 10 20:39:29 doh... Feb 10 20:39:45 if I copy the contents of the include in the wks.in then it works consistently Feb 10 20:42:24 so overall, the idea with the variable would work well, but only if we drop the common rk3288-boot.wks include and paste its contents into the tinker-board.wks.in Feb 10 20:42:46 on the bright side: thre is no need for separate wks files for sdard/emmc/tinker-board-s Feb 10 20:46:02 Jin^eLD: where are you thinking of drawing the line between constant and variable? Feb 10 20:46:23 what exactly do you mean? Feb 10 20:47:12 I would not expect wic to handle all the complex ways that bitbake can handle as in @bb.util or whatever style of things Feb 10 20:47:23 if that was your question? Feb 10 20:48:18 actually the only thing that does not work is expansion of those variables in an included wks, but it does work in the top wks.in Feb 10 20:48:29 unless it's changed recently, .wks.in was implemented by the metadata, literally using expand(), so it can do anything in a variable reference that can be done in a recipe, including ${@}. wic gets a generated .wks created from the .wks.in Feb 10 20:48:31 I even tried doing something like include bla.wks.in but that does not help Feb 10 20:48:44 kergoth: oh cool, good to know Feb 10 20:48:58 are you going to do "mmcblk${ROOT_DEVICE}p1" or "mmcblk${ROOT_DEVICE}" or "${ROOT_DEVICE}" ? Feb 10 20:49:02 which is why includes wouldn't work, it'd have to be done in wic, or be specifically handled in the metadata, i.e. automatically substitute away the .wks.in to .wks on the include lines when writing .wks Feb 10 20:49:20 but yeah, as tlwoerner indicates, you have to figure out exactly what parameters it accepts Feb 10 20:49:39 kergoth: got it, that explains why it does not work in included wks'es Feb 10 20:50:19 tlwoerner: oh... actually I used ROOT_DEVICE = "mmcblk0", but you are right, could be just the number Feb 10 20:50:32 would be a worthwhile enhancement to support inclusion of .wks.in by also processing those templates, recursively Feb 10 20:50:57 tlwoerner: for wic to work correctly partition can not be part of it, wic will append the p1/p2 etc itself Feb 10 20:51:09 Jin^eLD: ah Feb 10 20:51:36 i've used ${@} in .wks.in before by adding conditional partitions for persistent user data for read-only-rootfs setups, particularly combined with swupdate Feb 10 20:52:00 i.e. based on a distro feature Feb 10 20:52:01 kergoth: swupdate is what I am hacking at the moment :) Feb 10 20:52:06 ah, nice Feb 10 20:52:14 trying a double-copy update setup Feb 10 20:53:46 kergoth: is wks using those bitbake python classes, i.e. could it make use of the expand function from the bbclass or does it need to be a standalone implementation outside? Feb 10 20:53:57 or rather, wic, not wks Feb 10 20:54:35 * Jin^eLD is looking at the code Feb 10 20:54:51 seems to be independent of bitbake Feb 10 20:56:25 https://github.com/openembedded/openembedded-core/blob/9e7b38c61c6b84b7f137c733ac5da9414025693d/meta/classes/image_types_wic.bbclass#L63-L87 Feb 10 20:57:10 literally just runs getVar() on the contents of the .wks.in, from the do_write_wks_template task which runs betwen do_image_wic and do_image Feb 10 20:57:22 so has access to anything that'd be available in that task context Feb 10 20:57:57 (the indirection of reading the .wks.in at parse time and expanding and using it in the task is there to ensure that the task re-runs if any variables used by the .wks.in change) Feb 10 20:57:58 well, I am looking at the code of the wic script itself and it tries to expand lines using val = get_bitbake_var(key) Feb 10 20:58:30 if the main script expands correctly Feb 10 20:58:45 its not clear to me why it can't do the same on the included files since the env should still be the same, the one of the main script Feb 10 20:58:58 but I guess I'd have to have a closer look, not really familiar with any of it Feb 10 20:59:20 that wouldn't be use of .wks.in via WKS_FILE, presumably that's supported in any .wks? does sound more generic, indeed Feb 10 20:59:55 ok wait... maybe I am misunderstanding one thing: how is the wic file being generated? purely within OE with the help of those classes or is the scripts/wic tool being used? Feb 10 21:00:11 or is the scripts/wic tool a standalone thing just for checking/listing etc those generated wic files outside OE? Feb 10 21:00:16 yes, and yes Feb 10 21:00:28 do_image_wic will call out to wic create to create the image if you're using wic in IMAGE_FSTYPES Feb 10 21:00:36 but it could also be used externally if you'd rather do that Feb 10 21:00:47 i expect most use the image type nowadays, though it likely depends on the use case Feb 10 21:00:55 ok, so the place to hack would actually be the scripts/wic script, since its used by the bbclasses Feb 10 21:01:45 .wks.in -> .wks is in the metadata before wic is called, but it sounds like wic has its own more generic support that doesn't need that at all, if that's the case maybe the former could be dropped Feb 10 21:02:31 my understanding was that wks.in writes out an "env" file and passes it to wic Feb 10 21:03:38 at least that was my impression by looking at the image_types_wic.bbclass Feb 10 21:05:05 so it kinda seemed to me that when wic is being called, it should get all the expanded vars and just use them... so not sure why it does not do that when it processes includes Feb 10 21:05:36 probably worth debugging it a bit Feb 10 21:05:51 probably something minor Feb 10 21:06:31 (famous last words) Feb 10 21:06:46 tlwoerner: :)))) Feb 10 21:08:35 its up there with "It should work" Feb 10 21:12:43 you guys are very motivating =) Feb 10 21:12:53 (this is probably called - experience) Feb 10 21:12:58 :) Feb 10 21:17:27 .env has nothing to do with .wks.in. the .env is written regardless of use of .wks.in or .wks, and is used to pass the vars wic needs to create the image, not those used in the .wks.in Feb 10 21:17:44 image_types_wic.bbclass handles both .wks.in and .wks, only a small part of it is the former specifically Feb 10 21:18:27 and the .enc flie written only contains a specific list of the vars it needs for image construction, i.e image size Feb 10 21:18:30 env, rather Feb 10 21:19:14 kergoth: that's what I was about to write... there is some parallelism in the config there... the .in processing solely in the class and WICVARS being passed to wic Feb 10 21:19:32 so when I add my variables to WICVARS everything works Feb 10 21:19:43 i.e.: Feb 10 21:19:47 RK_ROOT_DEVICE ?= "mmcblk1" Feb 10 21:19:49 WICVARS_append = " RK_ROOT_DEVICE" Feb 10 21:21:39 in this case I probably do not even need to name my wks file wks.in since its enough to pass the variable via the .env Feb 10 21:21:47 and no need to process it twice Feb 10 21:22:36 so I guess the special handling of .in in the class was done just to simplify usage for the common case... i.e. so people don't have to think of adding their custom variables to WICVARS Feb 10 21:22:54 but this simplification breaks wks includes Feb 10 21:23:05 which is probably not a too common case Feb 10 21:24:01 so from what I see, there isn't really a bug/missing feature anywhere, one just needs to understand how it works and use it correctly... Feb 10 21:24:34 not saying this double-expanding is not confusing :) but I do understand the motivation/why its there Feb 10 21:25:45 nice, that's good to know Feb 10 21:26:17 i don't think it always did the per-line expansion, it's possible .wks.in preceded that Feb 10 21:26:46 kergoth: you mean it accepting the .env file is a newer feature? Feb 10 21:27:13 I had my wic crash-course just recently, so can't tell :) Feb 10 21:27:18 the env file was always used, but i'm not sure it was always used to expand the lines. that is, they were use dto create the image, not necessarily referenced within the line i the .wks Feb 10 21:27:28 not 100% sure on that though Feb 10 21:27:59 at least if it did do it at the time, i didn't know it, or i wouldn't have bothered writing the .wks.in support :) Feb 10 21:28:02 tlwoerner: I think for meta-rockchip we can avoid wks.in alltogether and just add the root device variable to WICVARS and use it in the wks directly... Feb 10 21:28:10 kergoth: :) Feb 10 21:28:23 tlwoerner: so we'd be back at the naming question ;) Feb 10 21:30:24 tlwoerner: to come back to what we talked about earlier, we can either use a device number and have --ondisk mmcblk${ROOT_DEVNUM} in the wic or specify the full device (I'd prefer that as its clearer) i.e. --ondisk ${ROOT_DEVICE} where ROOT_DEVICE is mmcblk1 or mmcblk0 Feb 10 21:30:47 the p0-p7 is added by wic itself Feb 10 21:31:30 Jin^eLD: yes, i prefer the full device... in the off-chance it changes in the future, or for some odd corner-case we can't think of right now Feb 10 21:32:06 as you say, in a config file saying SOMEVAR=mmcblk0 will be more obvious to a user than SOMEVAR=0 Feb 10 21:32:16 yep, +1 Feb 10 21:32:37 so for the var naming? just ROOT_DEVICE? RK_ROOT_DEVICE? Feb 10 21:32:47 RK288_ROOT_DEVICE? Feb 10 21:33:20 is it applicable to rk3399-boot.wks as well? Feb 10 21:33:57 i prefer it to be layer-namespaced (i.e. prefixed with RK_ or similar) Feb 10 21:34:17 most rockchip boards have uSD and eMMC Feb 10 21:35:00 so lets go with RK_ROOT_DEVICE then? or BOOT_DEVICE? man..those naming decisions... :) Feb 10 21:35:10 i.e. RK_BOOT_DEVICE Feb 10 21:35:20 yes RK_BOOT_DEVICE Feb 10 21:35:26 ok cool Feb 10 22:15:39 Sounds good to me FWIW :) Feb 10 22:16:27 :> preparing a patch Feb 11 00:20:09 tlwoerner, JPEW: sent out the patches, I converted all other machines confs to make use of that new var as well, kinda feld more appropriate to keep everysthing consistent, I hope that's OK Feb 11 00:20:29 otherwise I'll hear from you if anything needs tuning/fixing :) Feb 11 00:20:31 nite **** ENDING LOGGING AT Tue Feb 11 02:59:57 2020