**** BEGIN LOGGING AT Wed Sep 02 06:33:53 2020 Sep 02 06:44:46 happy coffee ingestion time, dudes! Sep 02 06:45:58 Good morning LetoThe2nd. Did you get ever in touch with arago? Sep 02 06:46:25 depends on your definition of "getting in touch" Sep 02 06:48:18 I try to understand the main difference between arago and yocto. For example I noticed there is no devtool available. I would like to figure out if its worth to port somehow arago/ti-layers to yocto environment **** BEGIN LOGGING AT Wed Sep 02 06:50:25 2020 Sep 02 06:50:52 you probably do not have to "port" anything. arago is just their distro, AFAIK. Sep 02 06:51:07 okay Sep 02 06:51:24 e.g., grab poky, disable the poky layers, add the arago layers, done. thats the way it should be meant to be Sep 02 06:52:30 "similar to yocto, based on openembedded" that needs to be remembered! Sep 02 06:52:56 if you look at this http://arago-project.org/git/projects/?p=oe-layersetup.git;a=blob;f=configs/arago-dunfell-config.txt;h=c9428d9c0783bc5733ea5c8af542ee89315def85;hb=83d2564acbb00a48dc6044f92588ce2c646bff13 there even no need to use their setup script (sorry denix) **** BEGIN LOGGING AT Wed Sep 02 06:54:51 2020 Sep 02 06:55:19 ThomasD13: if it offer something you want/need, sure you can. my personal way would be to just add the layers as noted in the script and start using them. Sep 02 06:56:11 Thanks for your view LetoThe2nd Sep 02 06:56:59 LetoThe2nd: what I don't get is why people keep on claiming it's not Yocto! is it because it's not Poky? Poky is not Yocto! **** BEGIN LOGGING AT Wed Sep 02 06:58:53 2020 Sep 02 06:58:54 denix, you mean me? I compare arago more to poky, since I understand its a "reference distro for TI hardware". Same as poky (for qemu) Sep 02 06:59:15 But I'm not sure if there is maybe some more "black magic" added by TI Sep 02 06:59:40 * LetoThe2nd ponders starting a "black magic matters" meme Sep 02 06:59:48 Oh no :D Sep 02 06:59:54 what black magic? it's all public... Sep 02 07:01:00 yes... black magic in a wider sense. Some stuff which I didnt discover yet, but required that it works somehow in the end **** BEGIN LOGGING AT Wed Sep 02 07:06:37 2020 Sep 02 07:12:41 LetoThe2nd: and thanks to you for all your work! us developers sometimes have hard time talking to users, so your involvement in explaining things is really appreciated!! Sep 02 07:15:50 denix: hi5 Sep 02 07:25:15 Hi! What is intended to be the smallest?: core-image-minimal-initramfs or core-image-tiny-initramfs Sep 02 07:25:52 What is the logical difference or idea behind, respectively? Sep 02 07:30:30 fbre: well by looking at it, one could guess that the tiny incarnation is 1) based on poky-tiny 2) x86 only Sep 02 07:31:13 OTOH, the tiny version seems to be a bit more fine tuned / advanced, the minimal version is more generic / bare bones Sep 02 07:33:50 ah OK thanx. Although it doesn't make a problem to overload COMPATIBLE_HOST = "(i.86|x86_6|aarch64).*-linux" in a core-image-tiny-initramfs.bbappend Sep 02 07:35:11 I just have to tweak its init-live.sh script a bit since we don't have pluggable rootfs media Sep 02 07:38:49 * denix -> zzz Sep 02 08:02:31 Urgs, there is no RT patch for the kernel for the yocto release "warrior" Sep 02 08:03:22 Would be nice if such requirement becomes standard for yocto releases Sep 02 08:06:23 fbre: disagreed: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux?h=warrior Sep 02 08:08:57 hmm, I took a look here: https://source.codeaurora.org/external/imx/imx-manifest/tree/?h=imx-linux-warrior and here https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.19/ Sep 02 08:10:08 fbre: do not blame yocto for whatever freescale/imx support yank out. Sep 02 08:10:24 and here https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.19/older/ Sep 02 08:10:47 ok, sorry. Then it's up to NXP Sep 02 08:12:19 fbre: seriously, i do not care that much where you looked. but i really have to point out that a false accusation of something being not there, and then even the request for it becoming standard (for you, free, or are you a high ranking member that i do not know about yet?) is quite unfortunate. Sep 02 08:13:48 fbre: if you look back a coupe of weeks in your own story here, many hassles have obviously been caused by that imx/codeaurora stuff. go blame your board verndor for pointing you there. Sep 02 08:18:04 I don't want to be offensive. The idea was just because of lack of knowledge NXP has own source copies. I come as NXP user and didn't know what the repo topology is Sep 02 08:19:30 I thought all releases base on the same kernel versions and vendors just put its meta layer on it Sep 02 08:19:38 fbre: i see. in a nutshell: what we care about is on git.yoctopoject.org. if its not there, its up to somebody else to provide/fix it. Sep 02 08:21:02 ...but obviously generic yocto uses different kernel versions than vendor copies do, at least since you have an RT patch but there is not RT patch for NXP's release of warrior Sep 02 08:21:02 and as we've not only had but are having our fair share of board / BSP vendor crap each and everyday here, some folks (and especially me!) am highly reluctant to care about it. those who sell the hardware also get the money. its their duty to support it. not mine. Sep 02 08:22:06 unless somebody pays up, i do absolutely not care about which kernels nxp ships. Sep 02 08:28:44 Well, just see my initial thought as idea for NXP's release "warrior" then. I think the "problem" is now the use of equal names for releases which are not version-identical (but just similar) Sep 02 08:29:23 Equal names for different things lead to such questions here ;-) Sep 02 08:30:13 Your "warrior" is not NXP's "warrior", this is what I've learned now Sep 02 08:31:03 Sorry, if this came offensive. I appreciate your help here very much Sep 02 08:31:23 no. you're mistaken here. the whole point of a BSP *IS* to inject a bootload/kernel/driver combination that makes a certain hardware work. the release name basically states the rest of the package versions and mechanisms you can use. so, our warrior versions are pretty much also those that nxps layers will use and rely on. BUT(!!) this does not apply to the kernel. and thats the point. Sep 02 08:32:48 so whatever a vendor hands you as kernel/bootloader/xxx combination, it is *THEIR* duty to a) support it b) state clearly what it brings, and what it doesn't bring. there is no nitpicking about names here. it is about both the vendor providing proper information, and about the user actually consuming it. Sep 02 08:35:07 e.g., if you're on warrior you'll find a defined set of gcc, binutils, glibc, openssl, and so on and so on. that is what the version defines. Sep 02 08:40:44 I see. Thanx for explaining it! Sep 02 08:42:21 I thought a defined kernel version is also part of the release version labeled with a certain name. Likely this is even mentioned in any readme I have overseen :-D Sep 02 08:42:41 s/overseen/missed Sep 02 08:44:56 nope. you're messing up the scope. of course yocto/Oe ships a specific kernel version with a release. but that does explicitly *NOT* mean that this release can only be used with that kernel version. again, as i already wrote a couple of minutes ago: the whole point of a BSP is to provide a kernel that make the desired hardware work. Sep 02 08:46:32 fbre: as I already pointed out the other day - please turn yourself to meta-freescale community BSP. it has almost all what NXP offers, and it is also closer to OE mainline Sep 02 08:47:12 fbre: if you feel there is an RT kernel missing - feel free to drop PR in meta-freescale to have it integrated. Sep 02 08:47:43 @fbre which NXP chip do you use? Sep 02 08:47:55 @fbre which kernel do you use on this chip? Sep 02 08:48:55 fbre: the assumption about kernel releases from NXP is also not quite correct. what NXP does is: they pick a stable *tag* and drop their patches on top. then it goes to community, where people can up-merge later tags on top of what NXP delivers. Sep 02 08:49:23 in a meantime - NXP pick *another tag*, drop some more patches and release it under their next release Sep 02 08:49:34 @fbre if you use a kind of upstream kernel for your NXP chip you can apply the preempt-rt patch yourself. Sep 02 08:49:52 this one also gets picked up, upmerged - and so the story goes. Sep 02 08:50:32 @fbre https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/ Sep 02 08:50:42 you would be surprised to see that in between 5.4.2 and 5.4.24 (which corresponds to NXP releases 1.0.0 and 2.1.0) there are significant differences in the kernel! Sep 02 08:52:39 zandrey: all the more reasons to not go for the stuff that gets mangled into those codeaurora things, and use vanilla OE/Poky as the base Sep 02 08:53:00 RobertBerger: Currently, 4.14.78 with sumo. I tried several attempts to switch to warrior and zeus. I get the repo according to the NXP docs from repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-[version] -m imx-[version].xml Sep 02 08:53:23 @fbre which chip? Sep 02 08:53:40 RobertBerger: imx8 Sep 02 08:53:45 LetoThe2nd: true! the only poor people that would be left outside though - are those who needs graphics and multimedia from NXP Sep 02 08:53:53 @fbre you need graphics/multimedia and so on? Sep 02 08:54:05 @rber or just headless image? Sep 02 08:54:13 I write to myself ;) Sep 02 08:54:23 zandrey: then they have to either pay for somebody to fix the crap for them, or go bitching to nxp. Sep 02 08:54:44 We are back to the "crappy vendor" discussions. Sep 02 08:54:45 @RobertBerger camera drivers and video4linux Sep 02 08:54:53 zandrey: in this current state we only get to pick up the pieces of the fallout. Sep 02 08:55:06 "or go bitching to nxp" - that would not work... they would probably get that stuff done for themselves, but not all others... :( Sep 02 08:55:14 RobertBerger: did we ever get away from it? Sep 02 08:55:51 Hmm since you don't seem to need the "special NXP sauce" upstream might work. Sep 02 08:55:55 RobertBerger: this were fun times in Lyon... :) Sep 02 08:55:58 zandrey: seriously, thats not my problem. people have to either support the stuff they sell (as they get the money), or people have to buy somewhere else. Sep 02 08:56:22 If end users don't demand anything better that's what you get. Sep 02 08:56:50 The problem is:"What is the alternative?" Sep 02 08:57:02 the point is that endusers and/or nxp obviously think that community support will fix it for free. and thats what i strongly oppose. Sep 02 08:57:26 They should know by now that this is not the case. Sep 02 08:57:49 * LetoThe2nd shurgs. Sep 02 08:58:08 And the community does NOT fix it. It's the consultants who sell the same fix to multiple customers without - without upstreaming. Sep 02 08:58:24 Since upstreaming costs extra. Sep 02 08:58:25 @zandrey: I get the repo according to the NXP docs from repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-[version] -m imx-[version].xml You wrote "please turn yourself to meta-freescale community BSP" but I don't know what you mean what checkout command I should use in your case, if you mean a whole repo or just a Sep 02 08:58:26 specific layer. No real idea of the background Sep 02 08:58:39 Anyways back to @fbre. Sep 02 08:59:07 Actually if you really really really want to use the NXP stuff it works as advertised. Sep 02 08:59:11 LetoThe2nd: totally agree! i'm just trying to advocate the fact that when people managed to get the vendor delivery done which can be used with upstream - they should contribute it back Sep 02 08:59:51 But why don't you try meta-freescale (to build the boot container for you) and some 5.8.x upstream kernel? Sep 02 09:00:16 fbre: i posted the link the other day that you can use Yocto Quick Start Guide, and replace meta-altera in it to meta-freescale Sep 02 09:00:47 Linux version 5.8.5-custom-ml-virt (oe-user@oe-host) (aarch64-resy-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Aug 27 07:31:49 UTC 2020 Sep 02 09:01:17 that way you get "community" BSP, which (with some tweaks) gives you a dunfell OE-Core base + NXP kernel + graphics + MM Sep 02 09:02:33 What zandrey says will work as well. My point against it would be that I would use this ONLY if graphics and multimedia are needed. Sep 02 09:03:30 RobertBerger: exactly! this is really for those folks on the sidewalk, which do require GPU+VPU+IPU stuff from NXP Sep 02 09:05:29 @fbre just for your understanding I am running 5.8.x on an imx8mm (no MM, no graphics, still no SD card) with upstream and this patch, which is mainly device tree stuff: https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/master/recipes-kernel/linux/patch/5.8.x/patches/phyboard-polis-imx8mm/dts/0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch Sep 02 09:08:05 zandrey: yes, you posted the other day (25/08) a link to https://github.com/Freescale/meta-freescale but I replied I do not understand it fully because meta-freescale is just one layer of many layers and I don't understand how I should get it married with my checked out sumo, warrior or zeus release I have checked out from NXP's codeaurora link Sep 02 09:11:14 fbre: if you follow a Quick Build Guide - then it should be straight forward for you to get a working image. that Guide is really well-written, and it takes you through all steps to get started with Yocto. Sep 02 09:12:48 i guess you're missing a concept about Yocto Project in general. it is *not* about cloning the manifest, it is about building your image by utilizing distribution, machine, and image. Sep 02 09:14:03 @fbre I think you lack some basic understanding - I know a trainer ;) Sep 02 09:14:32 this is what LetoThe2nd was pointing you to: you can have a distro from oe-core (poky), but once it comes down to really have it running on your machine (imx8m mini) - then it has to be combined together Sep 02 09:14:57 * LetoThe2nd is off to some js wrangling Sep 02 09:15:18 zandrey: https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf is my guide, especially A1. Quick Start. After that I have a full yocto source tree here I can bitbake. Do you mean I should remove a single layer yocto/sources/meta-freescale with the code I find in your https://github.com/Freescale/meta-freescale ? But what about Sep 02 09:15:19 meta-freescale-3rdparty and meta-freescale-distro and meta-fsl-bsp-release then, is it still a consistent system then? Sep 02 09:16:25 fbre: unless you do not use any vendor board (Variscite, Congatec, etc) - you do not need -3rdparty Sep 02 09:16:37 -distro you would need to have Sep 02 09:17:19 meta-fsl-bsp-release afaik contains manifests for repo tool which are not maintained (maybe...) so i would not pull it in Sep 02 09:17:39 which MACHINE do you have? Sep 02 09:17:44 imx8mmevk? Sep 02 09:18:12 yes Sep 02 09:18:40 RobertBerger: I once attended your training (a few months back) but actually just now I reached the sufficient level of understanding. Actually I would need the whole week again :') Sep 02 09:19:03 in this case - it resides in meta-freescale, so you can even skip the -distro Sep 02 09:19:06 @fbre: Feel free to join Sep 02 09:19:40 @fbre: I also offer "private" training and consulting Sep 02 09:19:41 but if you say: i need graphics - then you should pull meta-freescale-distro in, because that one defines the graphics packages you require Sep 02 09:20:44 fbre: take an offer from RobertBerger - do a recap, he might (maybe) go for discount! :D returning customer... :D Sep 02 09:21:16 @zandrey: Or ask more, since he didn't understand the first attempt ;) Sep 02 09:22:10 RobertBerger: either way - it's your offer! :D Sep 02 09:23:09 Sure - if fbre want one he knows where to find me - he has my contact details. Sep 02 09:24:10 Actually we just use a specific camera driver and video4linux as API to the firmware. No need for most graphics stuff. Sep 02 09:28:48 @fbre As I said I would go for upstream plus whatever would be necessary and the camera driver is yours I guess. Sep 02 09:28:53 it sounds very promising RobertBerger has an imx8mm running with 5.4.x. Probably, I'm gonna email you about that. Just now I'm very in hurry to just get an overlayfs working with that technique of bundling an initramfs image to the kernel. Meanwhile I almost found out how to get that working in the yocto-version "sumo". All attempts to use newer Sep 02 09:28:54 versions currently lead to strange errors during bitbake, and I'm running out of time to tackle a whole distro switch. Sep 02 09:34:19 khem, armpit: Found the bind build issue, its with mutlilib, will fix Sep 02 09:34:20 Currently, I have managed it, based on sumo, to bitbake a kernel with bundled tiny-initrams which contains a hacked init-live.sh script which setups an overlayfs over the whole root filesystem. The only question is currently to get that Image....bin file to the boot partition. IMAGE_BOOT_FILES_append = " Sep 02 09:34:21 ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin" does not have an effect Sep 02 09:34:57 fbre: i have to say that your approach would generally work, but (a) it would lead you to nowhere in regards to keeping your device up-to-date; and (b) you would spend now more efforts to make that combination work rather than switching to what upstream can offer. **** BEGIN LOGGING AT Wed Sep 02 09:36:52 2020 Sep 02 09:37:32 yes, but I have timelines, and the number of errors is too high on my attempts to a whole distro switch. The distro switch to something very much makes sense but too much time-consuming right now