**** BEGIN LOGGING AT Sun Jan 24 02:59:57 2021 Jan 24 03:01:07 jonesv[m]: the best would be to use an host supported by yocto Jan 24 03:01:59 jonesv[m]: I suggest you kas, it's a build tool for bitbake-based project which provide a container as well Jan 24 11:34:22 jonesv[m]: I confirm your issue is because the compiler is too recent to compile 3.18 Jan 24 11:41:08 Isn't Ubuntu supported? I have been using arch for years, but I installed Ubuntu for work (to have the same setup as my colleagues). Not sure how I feel about having yet another distro 😁. I mean, I'm new to yocto, not to Linux. I would hope I can manage my host if I understand what yocto requires 😊 Jan 24 11:41:38 jonesv[m]: you may have some luck by first merging 3.18.140 Jan 24 11:42:14 the issue is not the compiler from your host but the cross compiler that is built by YP Jan 24 11:42:50 Right but I would not expect kas to solve that Jan 24 11:43:45 no, kas wuill not solve that Jan 24 11:44:00 Just because I'm curious, I'll try the PREFERRED_VERSION, I wonder if yocto can build any version of gcc-cross I mention there 😁. If that doesn't work I'll try merging 3.18.140 Jan 24 11:46:17 I think that you will actually need to do both Jan 24 12:06:43 ```NOTE: versions of gcc-cross-arm available: 10.2.0 Jan 24 12:06:43 NOTE: preferred version 4.8% of gcc-cross-arm not available (for item virtual/arm-poky-linux-gnueabi-g++)``` Jan 24 12:06:43 So I'm guessing yocto does not build the toolchain automatically, does it? Jan 24 12:06:52 * jonesv[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/EywdIfABKzXVVmNbkcZLXgIg/message.txt > Jan 24 12:13:37 Oh, yocto has `meta/recipes-devtools/gcc/gcc-cross_10.2.bb` only. It means I'll probably stuggle to get it to build an older gcc Jan 24 12:21:05 I'm trying to make a minimal image without any services running, but packagegroup-base pulls in DISTRO_FEATURE packages. What is the distinction between IMAGE_FEATURES and DISTRO_FEATURES? In this case I still want the availability of the DISTRO_FEATURES, not just in this specific image. Jan 24 12:22:01 My general understanding is that a distro is the collective set of functionality, while image is the specific instance of it. Or subset if you like. Jan 24 12:23:48 So perhaps the way to do this is to actually create a new minimal distro for this specific image? Jan 24 12:24:10 @ jonesv[m]: typically there is one (sometimes also more) version/s of the toolchain with a specific yocto version Jan 24 12:25:10 @ jonesv[m]: any specific reason you want to build with some ancient cross gcc? Jan 24 12:25:54 @sveinse: we have 3 orthogonal concepts: IMAGE, DISTRO and MACHINE Jan 24 12:27:28 @sveinse: https://docs.yoctoproject.org/singleindex.html#term-IMAGE_FEATURES Jan 24 12:27:52 @sveinse: https://docs.yoctoproject.org/singleindex.html#ref-features-image Jan 24 12:28:02 RobertBerger: Exactly, but in this case they're not completely orthogonal. Well, technically its not yocto that mix them, but packagegroup-base.bb in poky does. Jan 24 12:28:50 @sveinse: orthogonal meaning you can change one without affecting the others. Jan 24 12:29:18 https://docs.yoctoproject.org/singleindex.html#term-DISTRO_FEATURES Jan 24 12:29:21 RobertBerger: yes. And packagegroup-base includes packages dependent on DISTRO_FEATURES, hence you change one the other is affected Jan 24 12:29:26 https://docs.yoctoproject.org/singleindex.html#ref-features-distro Jan 24 12:29:41 Wait a bit. Jan 24 12:30:40 let's say you enable ptest (which is enabled by default). This means ptest packages are installed in your distro Jan 24 12:31:37 Well, lets use zeroconf, that's in my list Jan 24 12:32:27 On which list? DISTRO_FEATURES? Jan 24 12:33:27 I guess you have meta-openembedded networking layer then Jan 24 12:33:42 So, I have a distro that shall support zeroconf, so DISTRO_FEATURES has zeroconf in it. But I now want to make a minimal image, but without running avavhi-daemon. My image is using packagegroup-base as the fundamental package to include and thus avahi comes along since its pulled in by DISTRO_FEATURES Jan 24 12:33:46 Because with 10.2 I get this "Assembler messages: .err encountered", and abelloni was suggesting that it could be because I need an older compiler for my downstream kernel v3.18.31 (also abelloni mentioned that I would possibly need to update to v3.18.140) Jan 24 12:34:22 "Assembler messages: .err encountered" is not your only issue Jan 24 12:34:32 log2.h doesn't compile either Jan 24 12:34:52 @ jonesv[m]: I guess you should either patch your ancient kernel or use a very old Yocto/OE version Jan 24 12:34:57 oh, I hadn't seen that Jan 24 12:35:17 log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' Jan 24 12:35:32 later on, this ends up being a forbideen warning Jan 24 12:35:38 forbidden Jan 24 12:35:55 @jonesv[m]: You can search for recipes here: https://layers.openembedded.org/layerindex/branch/master/recipes/ Jan 24 12:38:20 @jonesv[m]: I would say zeroconf is enabled by default in DISTRO_FEATURES and you need to include the other layer to have the recipe for it Jan 24 12:39:31 @jonesv[m]: pulseaudio.inc: ${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 'avahi', '', d)} Jan 24 12:40:40 So when package-group pulls in packages based on DISTRO_FEATURES, that independence of DISTRO and IMAGE is lost. DISTRO isn't just determine features, it also controls packages, which I would have hoped could be completely and orthogonally controlled by IMAGE. There are two ways around this: a) Build a new custom distro or b) Not use packagegroup-base and replace it with own implementation. None which I Jan 24 12:40:46 truly like :( Jan 24 12:41:01 s/package-group/packagegroup-base/ Jan 24 12:42:08 @sveinse: if you include pulseaudio in your image and zeroconf is enabled in DISTRO_FEATURES you get avahi pulled in ;) Jan 24 12:42:48 Jep, and that's unfortunate Jan 24 12:43:11 You can remove DISTRO_FEATURES if you like Jan 24 12:43:29 it's a list and you remove elements from it Jan 24 12:44:05 Then I'm making new distro without a feature, which implies that the feature packages might not be available for installation later Jan 24 12:44:21 Can I guarantee that two distros will be compatible? Jan 24 12:44:35 OK, I owe an explaination here: Jan 24 12:45:19 So I'm using this downstream kernel because I thought it would be my best chance of having something running at all on the device. But maybe I can try with a 5.x kernel and flash that there... Jan 24 12:45:59 @jonesv[m]: Which device is that? Jan 24 12:46:27 Want to build a minimal image with very little functions. No services, just the very basic. But opkg shall work so the user can install avahi and other DISTRO_FEATURES enabled functions from a packagepool. So the DISTRO_FEATURES are being built, not just included in this particular image. Thus wanting to captialize on the orthogonality between IMAGE and DISTRO Jan 24 12:46:48 It's a Parrot Skycontroller3. A wifi remote controller for remote-controlled planes/drones Jan 24 12:47:23 @sveinse: Did you try to build a core-image-minimal? Jan 24 12:47:24 Well it's the RC for the Parrot drones, actually. But as a learning project with Yocto, I wanted to create my own image for that thing and use it for my RC plane 😀 Jan 24 12:48:25 @jonesv[m]: which chip is it here? Jan 24 12:49:01 Qualcomm apq8009 Jan 24 12:49:10 hehe ;) Jan 24 12:49:38 And it also says msm8909, I'm not sure what apq8009/msm8909 means, to be honest Jan 24 12:49:53 Is that bad? 😕 Jan 24 12:50:08 Hmm it's quad-core Arm Cortex-A7 so you might at least be able to boot a shell there ;) Jan 24 12:51:20 The thing is that I only have USB access to it (I can't have a serial connection to see how the kernel boots). So I have to setup my image with a dhcp server, such that I can SSH over USB when it's booted. Let's be honest, probably it won't boot at all and I'll never manage to connect Jan 24 12:51:46 That's why I wanted their downstream kernel. I thought it would give me more chances to actually get it to boot Jan 24 12:52:12 @jonesv[m]: Is there anything useful here? search qcom https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts?h=v5.10.10 Jan 24 12:52:41 I could do my project on an RPi or pocketbeagle (yocto build fine there), but that Skycontroller3 is a nice piece of hardware, cheap and mass-produced. Would be cool if there was an open-source way to use it :) Jan 24 12:53:39 for RPI you have a meta-rpi layer Jan 24 12:54:09 There are some qcom dts, but not for apq8009 or msm8909. But in the downstream kernel I have a dts for that device. Can't I reuse it? Jan 24 12:54:24 pocketbeagle should work. I have a problem to get the serial console to work reliably with it Jan 24 12:54:30 Yes I know, and that works fine 😊. But that won't boot on my Skycontroller 😀 Jan 24 12:54:40 Sure it's a different chip Jan 24 12:54:57 I don't think a device tree for you ancient kernel will work on a 5.x kernel. Jan 24 12:55:02 your Jan 24 12:55:04 So I'm learning Yocto with pocketbeagle and rpi. And I was hoping to learn BSP with the Skycontroller Jan 24 12:55:32 Do you have a more recent kernel which is supposed to work? Jan 24 12:56:03 No, what they publish (and therefore I guess what they deploy on their device) is 3.18 Jan 24 12:58:21 Maybe this works? https://wiki.paparazziuav.org/wiki/Howto.crosscompile_for_parrot_drones Jan 24 12:58:58 But it's 3.4.11 Jan 24 13:00:39 Yes it's apparently not for the Skycontroller3. And that would not be Yocto, right? Jan 24 13:01:21 RobertBerger: I'll figure out a way around this. Thanks! Jan 24 13:02:00 But that's another question I have: say I want to keep their kernel without building it myself (I guess it's on their `boot` partition), and I just want to deploy my rootfs on their `system` partition. Can I do that without compiling the kernel at all? I mean, to build my rootfs, I suppose Yocto needs to have the kernel sources, right? Jan 24 13:04:50 @jonesv[m]: I never tried this on a "classic" Linux system, but this definitely works with containers. You can use a dummy kernel there. Jan 24 13:05:24 But what about packages that depend on the linux-headers? linux-headers are related to the kernel sources, aren't they? Jan 24 13:05:46 If my package was built with linux-headers version 5.x, and the kernel runs 3.x, I'll have issues, won't I? Jan 24 13:07:30 jonesv[m]: Well yes, but the linux-headers are not related to the kernel version in Yocto ;) It's separate packages. Jan 24 13:08:28 jonesv[m]: Think about it like you build an SDK and you don't need to build a new SDK if you want to build a new kernel version. Jan 24 13:08:48 right Jan 24 13:09:17 jonesv[m]: Or, say you have kernel and device tree over tftp and rootfs of nfs and change the kernel or the rootfs independently Jan 24 13:09:56 So maybe I could just try to use a dummy kernel, still build for apq8009/cortexa7 and try to deploy my rootfs, hoping that the bootloader/kernel are on the `boot` partition and will successfully mount my rootfs on the `system` partition? Jan 24 13:10:33 jonesv[m]: you might even be lucky that it works with the old kernel, since glibc, even if it calls a system call, which does not exist in your old kernel might try to call an alternative syscall which works Jan 24 13:11:00 Can you boot with a rootfs over nfs? Jan 24 13:11:21 I guess you don't have networking. Jan 24 13:12:04 I mean only wifi networking and I am not sure how will this will work with NFS Jan 24 13:12:06 I have adb access (to get a root shell or to push stuff there), and I can reboot it in fastboot mode (where I flash the boot, recovery and system images) Jan 24 13:12:21 Oh I can connect it to my computer over wifi, yes Jan 24 13:13:15 Hmm this sounds like Android ;) Jan 24 13:13:41 haha yes, they used to have Android on their RCs, and they moved to linux, but apparently they kept the Android tooling Jan 24 13:13:52 OMG Jan 24 13:15:10 But once I `adb shell` onto that thing, I'm in a normal linux environment. It just isn't the classic beginner-setup for yocto, I guess :D Jan 24 13:16:41 I can already connect to it and hack around. But I was hoping to get a nice and clean yocto BSP for it. But it seems like I should give up on that Jan 24 13:18:50 I looked at yocto commit d9aabf9639510fdb3e2ccc21ba5ae4aa9f6e4a57, which "gcc: Drop 4.8". But that came with tons of patches, I am not even sure if I could write my own recipe building gcc-cross 4.8. And if I did, it does not tell me that it would successfully build my kernel. Jan 24 13:19:17 @ jonesv[m]: You could use some ancient Yocto version Jan 24 13:19:38 And still that would not necessarily allow me to build an image for both rpi and this device, since my rpi would run on a new kernel with a new gcc, and this device on an old kernel with an old gcc Jan 24 13:20:13 @ jonesv[m]: I guess I would first try to patch the old kernel to build with a recent gcc and in case this is too tricky use an ancient yocto version Jan 24 13:20:26 right Jan 24 13:21:10 I'm not so much into using an ancient yocto because at this point I can just hack around on the device and use yocto on an rpi. Jan 24 13:21:39 Patching the old kernel would be nicer, but I would not even know where to start about those "Assembler message: .err encountered" Jan 24 13:22:35 And unfortunately, apq8009 is not supported by yocto (given this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts?h=v5.10.10) Jan 24 13:23:49 And I definitely won't know how to write my own dts for that device (is it called "mainlining apq8009"?) Jan 24 13:24:32 Well, I think it's time for me to give up. I already spent enough weekends on that thing, and now it truly feels hopeless 😅 Jan 24 13:38:53 @jonesv[m]: "And unfortunately, apq8009 is not supported by yocto" it's not yocto, but this is the upstream kernel Jan 24 13:39:32 right, yes :) Jan 24 13:40:39 @jonesv[m]: If you google for "linux kernel for apq8009" you find something from qualcomm for Android Jan 24 13:41:02 you think I could try to use their dts? Jan 24 13:43:48 jonesv[m]: I managed to avoid Android so far, so I have no idea for which kernel version that is and did not search any further. Jan 24 13:44:12 jonesv[m]: If you want to have some fun like that, you could try to make your own BSP for your Raspi ;) Jan 24 13:44:59 jonesv[m]: Or be pocketbeagle. I guess I would have something for the pocketbeagle, but with my crappy serial console adapter I can't really work properly. Jan 24 13:45:07 Or the Jan 24 13:45:43 I have spent days reading the meta-raspberrypi BSP and https://github.com/e-ale/meta-pocketbeagle, so it would be cheating. That's not "from scratch", I almost know them by heart now 😀 Jan 24 13:45:56 Hehe Jan 24 13:46:03 Which Raspi do you have? Jan 24 13:46:12 jonesv[m]: table / multimedia board from qualcomm ? do you have their SDK Jan 24 13:47:28 BTW I had to patch it for gatesgarth (probably did not do it properly, though), but it seems like it is working with my pocketbeagle: https://github.com/e-ale/meta-pocketbeagle/pull/5. Are you using your own layer for it? Jan 24 13:47:48 jonesv[m]: pocketbeagle: of course with a 5.10 kernel and u-boot and a wic file and so on. Jan 24 13:48:17 I don't have their SDK. What's `table /multimedia board`? Are you saying that the apq8009 is for that? In my case it's in a Parrot Skycontroller3 Jan 24 13:48:53 RPi Zero W, RPi 2, RPi 3, RPi 4 😀 Jan 24 13:49:20 @jonesv[m]: So make your own BSP with "upstream only for the RPi4 ;) Jan 24 13:49:46 jonesv[m]:yes basically a qualcomm multimedia tablet board Jan 24 13:50:22 so might want to hunt for a qualcom apq8009 sdk / dts Jan 24 13:50:23 @jonesv[m]: Make a BSP which works both on the RPi 2 and the pocketbeagle - same binaries except for boot loader and device tree Jan 24 13:50:25 oh, that's an idea. "Upstream only" meaning `linux-yocto`, or meaning using the upstream kernel instead of `linux-yocto`? Not sure if `linux-yocto` is upstream or not 😆 Jan 24 13:50:46 @jonesv[m]: kernel from kernel.org Jan 24 13:51:28 aha, so if I got the dts from qualcomm for upstream linux, I could then write my BSP. Is that correct? Jan 24 13:51:28 @jonesv[m]: of course you can use the yocto kernel recipes. Jan 24 13:51:43 Sounds good! I'll try that! Jan 24 13:52:35 jonesv[m]: basically its an android device right, google apq8009 dts Jan 24 13:52:43 jonesv[m]: hint: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/configs/multi_v7_defconfig?h=v5.10.10 Jan 24 13:53:06 grab the dts and review which kernel rev its in then check the most recent yocto kernel sources, it might already be there Jan 24 13:56:25 right Jan 24 13:57:18 That's for the rpi/pocketbeagle project, right? Use this instead of what's provided by meta-raspberrypi (I mean, don't use meta-raspberrypi at all is the exercise, I think :D) Jan 24 13:58:04 @jonesv[m]: yep for the kernel. You will need to make a few other adjustments to make it boot as well, I guess Jan 24 13:58:47 @jonesv[m]: meta-raspberrypi does not use the upstream kernel ;) Jan 24 13:59:28 @jonesv[m]: for bonus points try also the raspi 4 - there the boot process is "interesting" Jan 24 14:01:50 I am not sure I follow. Given that apq8009 is not here, doesn't it mean that it won't be in the yocto kernel sources? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts?h=v5.10.10 Jan 24 15:39:23 jonesv[m]: i dont think your looking in the right place try arm64 Jan 24 15:39:26 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/qcom?h=v5.10.10 Jan 24 15:40:55 apq8009 is not there either 🤔. But also it's an armv7, isn't it? Jan 24 16:23:08 @ jonesv[m]: I think with the right device tree you might be able to boot it with upstream. Jan 24 16:27:13 Right. But then I need a serial output to see what's happening. I'm trying to find if there is a way to do that, but I think I'll quickly get out of my depth (I've read tutorials where people use an oscilloscope to try to find the tx/gnd pins to connect to, that's too low-level for me) Jan 24 16:37:24 I think I won't get that thing to work, but that's an interesting learning experience 😀. I'm a software engineer, coming from much higher level than all that. It's good to learn 😊 Jan 24 21:10:59 jonesv[m]: you could use meta-linaro-toolchain **** ENDING LOGGING AT Mon Jan 25 02:59:57 2021