**** BEGIN LOGGING AT Tue Mar 17 02:59:57 2020 Mar 17 09:08:30 n Mar 17 09:08:32 morning Mar 17 19:13:28 zeddii: just converted the ST kernel to a kernel-yocto style recipe; generally worked fine; would be preferable to have a description for KCONF_BSP_AUDIT_LEVEL in the manual Mar 17 19:13:37 I looked for it there first but then found my answers in the .inc Mar 17 19:13:48 manual only mentions that it works now :) but does not tell how or what it is Mar 17 19:17:45 I can arrange for that to happen, or if you can .. can you open a bugzilla and assign it to me ? (bruce ashfield), that way there’s tracking. Mar 17 19:17:54 in the yocto bugzilla that is. Mar 17 19:18:04 sure, thank you, let me do that Mar 17 19:33:28 zeddii: is that OK? https://bugzilla.yoctoproject.org/show_bug.cgi?id=13835 Mar 17 19:34:23 looks good! Mar 17 19:34:31 cool, thx Mar 17 20:33:38 zeddii: how would I reference config fragments that are already in the kernel tree? i.e. git/arch/arm/configs/fragment-01-multiv7_cleanup.config Mar 17 20:34:19 normally I'd put fragments into the SRC_URI but not sure about this case, actually not sure if its some hack that ST did Mar 17 20:37:09 there’s no real way at the moment, no one has asked. I could add it without much effort. Mar 17 20:38:06 thanks for clarifying, I'll copy it out from the source tree then Mar 17 20:38:27 yah. that’s what I’d suggest for now. but I wrote it down, and will hack on it tomorrow. Mar 17 20:38:28 I actually did not check if its a "standard kernel way" of providing fragments inside the tree of if its a vendor thing Mar 17 20:38:45 there’s some support in the mainline kernel now. even some make targets. Mar 17 20:39:17 oh, ok Mar 17 20:39:17 but of course, the yocto stuff predates (and fed into the merge_config script) by many years, so I haven’t changed it in quite some time Mar 17 20:39:29 understood Mar 17 20:39:56 if it's supported in the kernel now then it would surely be cool to have support for it in Yocto as well :> Mar 17 20:40:32 leveraging the in kenrnel stuff is possible, using it completely isn’t. since it is quite different the way it works. Mar 17 20:41:25 not to mention, we couldn’t/wouldn’t have all fragments in the kernel tree itself, since then you’d have to patch them in, etc. Mar 17 20:42:26 to be honest I am not that familiar with all of it, first time I am really trying to use it now, so I just go with whatever you suggest Mar 17 20:43:06 we usually had our kernel in git and updated the in tree defconfig as needed Mar 17 20:43:42 and this time I'm on top of a vendor kernel, so there the defconfig drop-in or fragments are helpful Mar 17 20:43:48 yup. I’ve been there as well. it works, but varying by the build requirements is then the trick. Mar 17 20:43:51 exactly :D Mar 17 20:44:22 for now I am just trying to finish the conversion of the vendor kernel to kernel-yocto, it did build but I seem to be missing some configurations since the kernel crashes :> Mar 17 20:44:23 since if you only carry the fragments, you can follow most of what they may, or may not, change in their defconfig. by appyling on top the values you really care about. Mar 17 20:45:13 I’d do two builds. the original way it was working, copy out the .config, and then your conversion. Mar 17 20:45:16 right.. we'll see what works best for us, but I actually expect us to drop in a whole defconfig is we don't need a lot of the stuff that they have enabled by default Mar 17 20:45:47 if you use the allnoconfig for merge_config, you can start from a clean slate pretty easily. Mar 17 20:45:49 good idea.. well, right now I compared the environments of those builds and saw that I am missing some fragments they used Mar 17 20:46:26 does it matter if fragments are called .config or .cfg? Mar 17 20:46:56 for yocto, yes, at the moment. there’s some python that pulls out .cfg as fragments. it could easily detect both, but again, the predating thing :D Mar 17 20:47:06 right, right :) just asking Mar 17 20:47:21 the thing is, that a vendor defconfig shouldn’t be specifying software constructs for the kernel IMHO. it’s like the OE BSP versus distro versus image split. Mar 17 20:47:45 the entire structure around the fragments is that the board specifies what it needs to boot. software elements should be your choice. Mar 17 20:47:46 the in-tree fragment had a .config extension so I nee to rename it Mar 17 20:47:56 defconfigs blow that up by just jumbling everything together. Mar 17 20:48:06 but that’s me on my soap box ;) Mar 17 20:49:08 no, you are totally right Mar 17 20:49:34 I mean, one needs to be in control of their board/product Mar 17 20:49:45 I mean, why is my BSP vendor telling me I need POSIX_MQUEUE. Mar 17 20:49:51 bugger off, I’ll decide ;) Mar 17 20:49:54 so going with whatever the vendor randomly enables there is probably not the best choice Mar 17 20:49:59 yup. Mar 17 20:49:59 exactly Mar 17 20:50:12 bad example I gave, since it’s probably a default, but you know what I mean. Mar 17 20:50:20 yes :) Mar 17 20:51:21 that one is just stuck in my mind, since 14 years ago I had a priority 1 defect with a customer staring over my shoulder. one our BSPs wasn’t working, because hidden in the trees was *one* defconfig with POSIX_MQUEUE off, and that cripped core functionality. Mar 17 20:51:31 the next morning, we started writing the fragment support :D Mar 17 20:51:54 ah, so that's how it started =) Mar 17 20:52:41 heh nice, now I get BSP warnings for fragments defining the same stuff multiple times Mar 17 20:52:46 that was totally invisble with their original recipe Mar 17 20:53:06 yah. try two defconfigs on teh same src_uri. thousands!! Mar 17 20:53:45 had that bug once Mar 17 20:55:08 luckily there are just a few in this case and most have the same setting - except one :) Mar 17 20:55:24 thing is I was not aware they use fragments at all, they have their kernel in a github repo Mar 17 20:55:55 but they had a non kernel-yocto way of processing fragments in their recipe Mar 17 20:56:06 which I apparently missed Mar 17 20:56:33 yah. that’s why I’ll finally just get the patch from my bugzilla submited next cycle. so we can (hopefully) squash some of the variations. Mar 17 20:56:44 so you may not need the kernel-yocto stuff and just run with theirs. Mar 17 20:56:54 * zeddii won’t be offended ;) Mar 17 20:57:45 hehe, no, I really don't want to run with theirs ,) there are tons and tons of other things in there which just clutter it all and which we don't need anyway Mar 17 20:57:58 converting to yocto style collapses the whole recipe to just a few important lines Mar 17 20:58:04 already did that with their u-boot Mar 17 20:58:48 and don't get me wrong, if someone from ST is reading - I'm happy you do offer openstlinux and a yocto layer ;) Mar 17 20:58:57 cool. will save you pain in the future. Mar 17 20:59:25 heh. don’t worry, I work for a semiconductor now, no one likes our layers either. :D you have to have a thick skin IMHO. Mar 17 20:59:40 hehe Mar 17 21:00:00 well, as long as they are willing to provide something - its better than nothing Mar 17 21:00:05 and can be used as a referene Mar 17 21:00:07 *reference Mar 17 21:00:42 agreed. it’s the folks that think (hope) that the semi BSP/SDK will do everything for them out of the box that are going to be disappointed. Mar 17 21:00:52 using a vendor layer 1:1 is anyway not practical, because each vendor tries to cover all products and all possibilities which in the end results in tons of custom configuration flags and variables that are hard to see through Mar 17 21:01:08 right Mar 17 21:01:40 but then - if you read the vendor docs and howtos, its more or less how its advertised: here is our layer/sdk, you can be happy with it out of the box :> Mar 17 21:02:04 just configure those flags if you need this (long list follows) :) Mar 17 21:02:32 and of course last update was for thud :> Mar 17 21:02:32 it’s a tough balance, that’s for sure. newbies, versus experienced versus what they want to run as high level applciations, etc. Mar 17 21:03:01 imho you can't afford to be a newbie if you want to develop a product Mar 17 21:03:45 at this point, I've seen it all. so nothing surprises me :D Mar 17 21:04:04 I was not saying such case does not exist =) Mar 17 21:04:27 just saying its not one that makes sense... Mar 17 21:04:51 if you don't have the know how - hire the right people or invest time in leaning; everything else will blow up at some opint and will cost more... Mar 17 21:04:57 *learning Mar 17 21:08:04 but enough of that... I guess I'll have to diff the configs now as you suggested.. including those fragments did not help Mar 17 21:51:37 zedii: what is the proper way to use only x.y PV for the kernel and let the third version digit open, i.e. if you update SRCREV which then updates the kernel minor version? Mar 17 21:51:41 is KERNEL_VERSION_SANITY_SKIP="1" the only way to go there? Mar 17 21:51:44 seems hacky Mar 17 21:54:52 hmm. yah, I can’t say that I’ve tried that. I’d just inhibit it. It was really only causing us trouble in some OE core tests when I used to push kernels, and layers would get out of sync. Mar 17 21:55:02 if you know what’s going on in your own config, it can be disabled. Mar 17 21:55:13 for instance, I have it disabled in all my local builds. Mar 17 21:56:41 so there is no "feature" in that sense to keep the PV only as major.mid, or rather - the feature is this sanity check var? Mar 17 21:57:09 my use case was that I was changing the SRCREV in my layer that sits on top of the bsp layer Mar 17 21:57:22 I’d have to go look at the code again, but yah, that’s how I’ve always used it. Mar 17 21:57:23 i.e. was doing that in the .bbappend but the new srcrev bumped the kernel Mar 17 21:57:29 ok, thx Mar 17 21:59:30 you can also just “deltask” the kernel_version_sanity_check Mar 17 22:00:36 but since you can’t bbappend a class, you can’t remimplement it. Mar 17 22:02:56 I was looking for the least invasive way, so I guess going with the sanity check variable is probably the most straightforward option Mar 17 22:03:13 or rethink the appraoch and set the SRCREV in the bsp layer Mar 17 22:03:40 it is trying to warn you of something that could potentially matter, so yah, there may be other options. **** ENDING LOGGING AT Wed Mar 18 02:59:58 2020