**** BEGIN LOGGING AT Thu Apr 15 02:59:56 2021 Apr 15 03:37:26 khem: ah, interesting Apr 15 07:14:01 yo dudX Apr 15 08:44:09 hi there, shouldn't it be sufficient to use INSTALL_IMAGE_remove += "package-name" to test dropping out one package of an image build? Apr 15 08:44:40 if i do that, i end up getting errors from the image build that tries to copy config files regarding that 'removed' package Apr 15 08:45:04 anything else needed to remove a package from an image? Apr 15 08:45:21 or do i have to run a complete clean build Apr 15 08:45:24 ? Apr 15 09:01:03 how to get into uboot menu? i want to use tftp for booting image Apr 15 09:03:49 sahilgg: usually by pressing some key on the serial console. if not, then read the documentation of the board. Apr 15 09:12:30 creich: first, it'd be IMAGE_INSTALL_remove and not INSTALL_IMAGE. Second, this applies only to "top-level" recipes, the ones that are **explicitly** included in the image via IMAGE_INSTALL variable Apr 15 09:13:08 "top-level" package* sorry Apr 15 09:15:43 qschulz: yeah, sry for the typo.. i did IMAGE_INSTALL_remove in my local.conf. and yes, i removed on that explicitly got added using IMAGE_INSTALL Apr 15 09:16:14 but i theory that should work, right? if not, i'd expect something else is wrong with the configuration Apr 15 09:16:21 if it is not a "top-level" package, you need to modify the recipes that are adding said package as a dependency, it can be either in RDEPENDS, DEPENDS or RRECOMMENDS. One easy way is to add said package to PACKAGE_EXCLUDE in your loca.lconf and see what fails to "build" Apr 15 09:16:39 if you don't want any package of a given recipe, the easiest way is just to remove the recipe and see what fails to build Apr 15 09:17:27 if it is a "top-level" package but is also in RDEPENDS/RRECOMMENDS/DEPENDS of another recipe/package then you need to modify those too Apr 15 09:17:54 those = the recipes that have RDEPENDS/RRECOMMENDS/DEPENDS on the package/recipe you don't want Apr 15 09:17:56 makes sense. I'll check for dependencies Apr 15 09:18:01 thx for the hint :) Apr 15 10:07:12 Can you attach a machine specific task to ROOTFS_POSTPROCESS_COMMAND? ROOTFS_POSTPROCESS_COMMAND_mymachine overwrites the default variable. Apr 15 10:07:59 Hi, when the state cache is used, I only get log files for the setscene task. How can I see the log of the last build? I think it would be nice to have the build log as part of the sstate-cache, and a "cached_log" directory as part of the build when the cache is used Apr 15 10:09:08 Guest9820: ROOTFS_POSTPROCESS_COMMAND_append_mymachine ? (qschulz to the rescue) Apr 15 10:09:28 hi, how to default shared library providers? looks like some odd package stole some python shared libraries in my build and QA check "QA Issue: python3-rpm rdepends on bla but isn't a build DEPENDS" fails. Which log or database would have the shared lib providers? Apr 15 10:11:06 Guest9820: LetoThe2nd: can confirm, that is the way to do it, don't forget the leading space Apr 15 10:12:02 Scorpi: I'm not sure you can, because the tasks are obviously not re-run so Yocto would need to store logs in the sstate-cache and it's already pretty big :p Apr 15 10:12:48 mcfrisk: oe-pkgdata-util find-path '*myshlib.so*' will return the package providing this lib if it's been built, otherwise happy hunting :) Apr 15 10:12:53 qschulz: I think space wouldn be a big issue as logfiles usually compress well Apr 15 10:13:59 qschulz: speaking of which, is there a tool to manage the state cache, e.g. find old and unused cache items? Apr 15 10:16:31 qschulz: found it, by looking at the offending bla package, it shipped a private libpopt.so.0 which now suddenly overrides the real shared lib from popt. it's in a funny non-default path but bitbake doesn't seem to care since it's not marked is private lib Apr 15 10:18:39 Scorpi: bitbake-dumpsig and bitbake-diffsigs Apr 15 10:19:18 Scorpi: ah sorry, didn't read til the end. Mmmm I think there might be a script somewhere in poky but I usually use `find -atime +30 -delete` Apr 15 10:19:32 at least a few of us here do it Apr 15 10:19:40 okay, thanks Apr 15 10:19:43 (some even have this in a cronjob) Apr 15 10:24:03 i have a bbappend for linux-firmware where i do PACKAGES =+ " ${PN}-foo" with FILES_${PN}-foo, but all of my new firmware files are part of linux-firmware and no linux-firmware-foo package is created. is the linux-firmware recipe somehow special? Apr 15 10:25:47 it looks like as if PACKAGES is ignored Apr 15 10:26:16 but when i run bitbake -e linux-firmware > vars.txt. i see linux-firmware-foo in the PACKAGES variable Apr 15 10:27:42 derRichard: the order is wrong :) Apr 15 10:27:52 ah no, my bad Apr 15 10:28:01 hmm, why does shared lib RDEPENDS magic look into all binaries offered by recipes, not just the ones in the default shared library paths? https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#automatically-added-runtime-dependencies Apr 15 10:28:22 @qschulz @LetoThe2nd Thanks! Apr 15 10:28:51 derRichard: what's inside the PACKAGES variable? Apr 15 10:29:07 qschulz: one moment, i can share the bb file Apr 15 10:29:17 just need to censor the vendor name^^ Apr 15 10:30:22 derRichard: just go for cat vars.txt | grep ^PACKAGES= Apr 15 10:32:02 https://paste.debian.net/plainh/a25e9469 Apr 15 10:32:16 beside of tons of other linux-firmware packages, i see in PACKAGES also linux-firmware-xxx Apr 15 10:33:06 all looks good to me except, that FILES_${PN}-xxx seems to have no effect and fw.bin goes into linux-firmware instead of linux-firmware-xxx Apr 15 10:33:40 derRichard: you did NOT do PACKAGES =+ " ${PN}-foo" but PACKAGES_append Apr 15 10:33:48 which is completely different Apr 15 10:33:53 yes, i just changed it Apr 15 10:33:54 so indeed, the order is wrong Apr 15 10:33:55 oh? Apr 15 10:34:17 which order? Apr 15 10:34:42 PACKAGES =+ prepends directly, PACKAGES_append appends later after everything is done (but before _remove is evaluated) Apr 15 10:34:46 derRichard: in PACKAGES Apr 15 10:35:14 files are put on the first package whose FILES_${PN} matches their path Apr 15 10:35:39 the "first package" being determined from the PACKAGES variable, from leftmost to rightmost Apr 15 10:36:11 hm, i had that already. when printing the PACKAGES variable i see linux-firmware-xxx being first Apr 15 10:36:23 let me try again without hackery Apr 15 10:36:35 you are **appending** to PACKAGES, therefore linux-firmware package (which probably has a glob pattern to match everything that hasn't been added in previous packages) will take your file and there'll be nothing left to match in your linux-firmware-xxx Apr 15 10:37:24 yes, i understand that _append is wrong Apr 15 10:37:40 but with PACKAGES =+ i see the same problem Apr 15 10:37:57 i'm rebuilding now woth =+ just to be sure Apr 15 10:38:30 maybe some other .bbappend messes with linux-firmware's PACKAGES variable? hmmm Apr 15 10:40:10 just printed the PACKAGES variable, linux-firmware-xxx is first and linux-firmware is last. sounds about right to me Apr 15 10:42:53 in vars.txt i see also: FILES_linux-firmware-xxx=" /lib/firmware/xxx/fw.bin " Apr 15 10:42:56 makes sense too Apr 15 10:45:44 derRichard: at that point, you'll have to dig into the original linux-firmware recipe and what's done exactly, maybe there's some automate process of some sort, I don't know Apr 15 10:46:05 also... you don't need to make a bbappend for this firmware, especially since you add your own firmware by hand Apr 15 10:46:11 qschulz: thanks, i can do that myself. just wanted to make sure i'm on the right track Apr 15 10:46:14 just create your own recipe from scratch just for this firmware Apr 15 10:46:51 derRichard: BTW, most of the time, instead of PACKAGES =+, PACKAGE_BEFORE_PN += works fine and is a bit more easy to read and less error prone (IMO) Apr 15 10:47:25 so, this is the wrong approach? https://github.com/100askTeam/meta-imx/blob/zeus-5.4.24-2.1.0/meta-bsp/recipes-kernel/linux-firmware/linux-firmware_%25.bbappend Apr 15 10:47:30 now you can guess on what bsp i am ;) Apr 15 10:48:41 derRichard: yes, this seems like a wrong approach to me Apr 15 10:48:54 * derRichard takes a note Apr 15 10:49:27 while using pip install xxx i am getting ssl error so i added trusted list it got install. but while using python request too i am getting requests.exceptions.SSLError .. i added verify=False to do its work. any way to avoid these errors from base? Apr 15 10:49:40 derRichard: https://github.com/100askTeam/meta-imx/blob/zeus-5.4.24-2.1.0/meta-bsp/recipes-kernel/linux-firmware/linux-firmware_%25.bbappend#L75 smh Apr 15 10:50:44 derRichard: why don't you take https://source.codeaurora.org/external/imx/meta-imx directly? Apr 15 10:54:33 qschulz: i showed you the first file google found Apr 15 10:54:55 i take my copy of meta-imx form the internal git... Apr 15 10:59:43 derRichard: aaaah, then just create your own recipe then :) Apr 15 11:00:40 but can i still use MACHINE_FIRMWARE then in my machine? Apr 15 11:03:47 derRichard: can you point me to where this is defined/used, I don't think it is in vanilla poky/oe-core? Apr 15 11:04:22 jesus chist, i hate vendor stuff so much... Apr 15 11:04:30 let me see after lunch :-) Apr 15 11:07:37 conf/machine/include/imx-base.inc:MACHINE_EXTRA_RRECOMMENDS += "${MACHINE_FIRMWARE}" Apr 15 11:07:43 in meta-freescale Apr 15 11:07:45 is not that bad Apr 15 11:08:05 now i realize also that any recipe can do it, i thought MACHINE_FIRMWARE is special. m( Apr 15 11:08:20 qschulz: thanks a lot for pushing me into the right direction! Apr 15 11:13:34 derRichard: my pleasure, happy hacking :) Apr 15 11:56:47 qschulz: i gave the bbappend appraoch another try because i wanted to see why i didn't work. after a bitbake -c cleanall linux-firmware all worked like charm o_O Apr 15 12:03:47 derRichard: that is... concerning :) Apr 15 12:05:41 qschulz: well, isn't the first time that cleanall did wonders when hitting yocto issues Apr 15 12:09:47 don't use cleanall Apr 15 12:10:02 it takes forever as it has to purge sstate too Apr 15 12:10:14 -Cunpack would most likely have forced a rebuild Apr 15 12:37:25 Hello, I would like to know how to bbappend the do_install_append_class-nativesdk() in the bison recipe with a bbappend file? I would like to add PATH variable in the create_wrapper Apr 15 13:14:14 vygu2: do_install_append_class-nativesdk_append() ? Apr 15 13:14:23 well not even Apr 15 13:14:36 do_install_append_class-nativesdk would work fine too if I'm not mistaken Apr 15 13:21:00 I would like to add PATH=\$PATH:${bindir} to create_wrapper to find m4 files Apr 15 14:06:14 Hi, I was wondering if I can nest bitbake variables, e.g. something like: Apr 15 14:06:14 ${PN}_REV ?= "${AUTOREV}" Apr 15 14:06:15 and then when checking out I would use rev=${${PN}_REV} Apr 15 14:06:15 Idea is to allow per package redefinition of revision Apr 15 14:18:22 eFfeM1: that means you want to modify ${PN}_REV somewhere right? Apr 15 14:18:39 so that it is not the default AUTOREV Apr 15 14:19:31 qschulz what I want do do is AUTOREV, but I want to have the possibility to override the hash for a release build; Apr 15 14:20:08 so while developing I'd like to use AUTOREV and while making the release I want to specify the hash so later on I can reproduce the release build Apr 15 14:41:40 ok, found out the hard way that it has to be Apr 15 14:41:41 SRCREV = "${AUTOREV}" Apr 15 14:41:41 I cannot even call it SRC_REV and append a rev=${SRC_REV} to my git URI Apr 15 14:42:42 eFfeM1: you also need PV to use SRCPV IIRC, the docs explain that anyway Apr 15 14:43:23 yeah I have added this to my recipe Apr 15 14:43:23 PV = "1.0+git${SRCPV}" Apr 15 14:43:55 and with SRCREV that works but with SRC_REV and rev=${SRC_REV} it does not work Apr 15 14:44:06 eFfeM1: just have a conf file somewhere where you define SRCREV_pn-recipea = "${AUTOREV}" PV_pn-recipea = "1.0+git${SRCPV}" Apr 15 14:44:26 **include** (and NOT require) this file Apr 15 14:44:34 then for your releases, delete the file Apr 15 14:44:36 and voila Apr 15 14:46:20 and you define all your recipe's SRCREV and PV in there Apr 15 14:46:38 (yes, you need pn- in front, it is not a typo) Apr 15 14:46:54 qschulz, ah ok, do you have two conf files (a different one for release with hashes in it) ? Apr 15 14:47:18 eFfeM1: no, I suggest you update the recipe so that it points to the correct revision Apr 15 14:47:45 eFfeM1: and we don't use AUTOREV at all, we use externalsrc for development and/or devtool Apr 15 14:48:21 qschulz understood the rev part, I assume you do use SRCREV ?= in the recipe then Apr 15 14:48:36 eFfeM1: that's exactly what I was thinking about Apr 15 14:48:43 you probably need SRCREV ?= indeed Apr 15 14:48:50 I'm unaware of externalsrc and have never used devtool Apr 15 14:49:50 There has been at least one talk about CI/CD with Yocto at a Yocto project Summit Apr 15 14:50:01 so you might want to check it out :) Apr 15 14:51:32 qschulz will do, I've been away from yocto/oe for several years, so I'm not really up to speed with the latest things Apr 15 14:54:19 hello guys ! I'm using a distro with systemd Apr 15 14:56:03 I want to put some configuration file /opt/lib/systemd/network Apr 15 14:56:11 instead of /lib/systemd/network Apr 15 14:56:40 i've tried putting symbolink links but it doesn't work.. any suggestion ? Apr 15 14:57:47 11:47 < derRichard> now you can guess on what bsp i am ;) Apr 15 14:57:47 11:48 < qschulz> derRichard: yes, this seems like a wrong approach to me Apr 15 14:57:47 11:48 * derRichard takes a note Apr 15 14:58:43 chrysh: hm? Apr 15 14:59:10 hm, hm Apr 15 15:02:29 oh, and by the way: https://twitter.com/TheYoctoJester/status/1382687655591256064 Apr 15 15:03:28 derRichard: oops, layer 8 error. Apr 15 15:03:54 but also, some imx* board I guess Apr 15 15:04:21 yeah, i work a lot for imx6 and 8 systems Apr 15 15:04:32 s/for/with/ Apr 15 15:05:14 many do that these days. Apr 15 15:05:15 why not 7? xD Apr 15 15:06:40 * LetoThe2nd curses RP for making him read up on Honister Pass / Wikipedia now *during* worky hours. Apr 15 15:07:43 Hey imx6 people ;) Apr 15 15:07:57 LetoThe2nd: heh. Keeps things interesting :) Apr 15 15:08:05 Nobody on imx7? what a pitty Apr 15 15:08:11 Did you try tiptop on a recent kernel with imx6 - arm32? Apr 15 15:08:25 chrysh: imx7 was much less popular than imx6 and 8 Apr 15 15:08:47 chrysh: we do have a product based on imx7d though, any specific question? Apr 15 15:09:15 RP: i keep on learning so many completely useless things. now i know where in the uk the most rain fell, and that it was on my birthday 6yrs ago. now what use can i put that knowledge to? Apr 15 15:10:04 LetoThe2nd: you were the sunshine of that day but as all things need to be balanced, it poured rain in the UK Apr 15 15:10:52 qschulz: no, I am just making jokes because we had a lot of trouble with imx7 in my previous company Apr 15 15:11:09 qschulz: that must be the most hilarous and cheesy compliment i've ever received over IRC. great job! Apr 15 15:11:44 * qschulz blushes Apr 15 15:12:20 qschulz: hi5 - lo5 - fistbump Apr 15 15:12:30 is there a better description of the tmp/work directory structure than this? http://git.yoctoproject.org/cgit.cgi/poky/plain/README.structure?h=blinky Apr 15 15:12:59 yates: doesn't the ref manual go into details? Apr 15 15:13:05 chrysh: we don't use upstream kernel though, very outdated NXP kernel. But outside of a very nasty bug in the code handling suspend to RAM, I think it was mostly fine? Though to be fair, I didn't work a lot on that product Apr 15 15:13:17 Morning Folks Apr 15 15:13:17 I am looking for some help with cmake, which in the past I avoided! Don't judge the fact that install is trying to do some compilation, but I think that's part of the problem. Apr 15 15:13:17 Ceph tries to build some python binding C code during the install phase and it's not finding the core libraries and crt related objects. Apr 15 15:13:17 It seems to be searching in the recipe-sysroot-native area instead of the recipe-sysroot directory, the top level toolchain.cmake does have the correct sysroot pointing to recipe-sysroot Apr 15 15:13:29 RP: i'll take a look Apr 15 15:13:56 yates: i would probably say that this document is even more misleading that helping... you know, "blinky" Apr 15 15:14:13 yates: blinky is very very old now! Apr 15 15:14:32 Some people have nostalgy, what can I say Apr 15 15:14:59 I liked the pacman era, that was pre yocto Apr 15 15:15:26 doh. Apr 15 15:16:25 i liked Missile Command, myself.. Apr 15 15:16:48 (yes folks, I really did play the original MC game at the arcades...) Apr 15 15:18:13 lim_{ - \approach\infty} = old guy Apr 15 15:20:22 https://www.youtube.com/watch?v=nokIGklnBGY Apr 15 15:26:44 to ship a systemd foo.mount unit and enable it by default, should I bbappend systemd-conf or should I write a new package? Apr 15 15:28:26 vdl: new package recipe Apr 15 15:31:34 Hey all. I was wondering if anyone could point me in the right direction - I am adding psplash to my IMAGE_INSTALL_append but psplash-start complains that /usr/bin/psplash doesn't exist. Neither does psplash-default but these are in fact compiled in the tmp directory. Using core-image-minimal on dunfell Apr 15 15:38:42 qschulz: thanks Apr 15 15:42:18 escalion: oe-pkgdata-util find-path '/usr/bin/psplash' Apr 15 15:42:34 then add the package that provides this binary to your image via IMAGE_INSTALL Apr 15 15:42:45 if there's none, happy hunting :) Apr 15 15:42:57 * LetoThe2nd so totally misreads that nickname as"escalation" each and every time. Apr 15 15:43:23 LetoThe2nd: sign of old age Apr 15 15:43:53 did you play Missile Command too? Apr 15 15:45:00 nope. Apr 15 15:49:42 qschulz: awesome, thanks for the pointer. I'll try it as soon as chromium has finished rebuilding! Apr 15 15:51:02 LetoThe2nd: In voice enabled games plenty make the same mistake! Apr 15 15:52:07 mmm now that think about it, psplash-start should explicit the runtime dependency (RDEPENDS_${PN}-start I assume) on the package which provides /usr/bin/psplash Apr 15 15:52:11 escalion: ^ Apr 15 15:54:34 qschulz, psplash-start is a service file installed by psplash_git. The strange thing is that there is a line that clearly deletes /usr/bin/psplash "rm -f ${D}${bindir}/psplash" this is in psplash_git.bb in poky/meta/recipes-core Apr 15 16:04:22 escalion: binaries are created per SPLASH_IMAGES and their package names are listed in SPLASH_INSTALL if I am not mistaken Apr 15 16:05:14 escalion: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/psplash?id=d3de5f7308b4a42b809884119a670af5bedde38f Apr 15 16:06:21 qschulz: these .mount units are the systemd equivalent of what wic could do for you (editing the fstab with boot and data partitions). Would you consider these units a recipes-core package or preferably a recipes-bsp? Apr 15 16:07:31 vdl: potato potato :) Apr 15 16:07:52 honestly, the name of the directory does not matter much ;) Apr 15 16:10:04 qschulz: I know, it's just that it gives me a better insight on how to organize the code, I'm not sure it these basic mount points are part of the bsp or part of an image Apr 15 16:10:56 * vdl creates an recipes-qschulz directory Apr 15 16:12:38 I have a 10 year old SOM based on the TI-AM33xx... they still have an old ubuntu 10.04 vm with a toolchain that builds linux 2.6!!! I thought about converting it to yocto Apr 15 16:12:50 that is, until I saw how old the kernel is Apr 15 16:13:19 ecdhe: I hope you're using a container at least to build everything Apr 15 16:13:21 ecdhe: am33xx have excellent upstream support Apr 15 16:13:27 I have the kernel config they recommended, but I'm not sure how much of that stuff would still be applicable Apr 15 16:13:32 (kernel and u-boot for sure) Apr 15 16:13:39 ecdhe: assume none ;) Apr 15 16:14:01 you'll need to create a device tree for your SoM+carrier board though Apr 15 16:14:08 qschulz: I switched to barebox for am335x, works like a charm Apr 15 16:14:31 but once done, upstream kernel + upstream yocto + upstream bootloader Apr 15 16:14:35 the dream Apr 15 16:14:50 Would it be better to jump from 2.6 straight to 5.10, or should I do incremental upgrades? Apr 15 16:14:52 vdl: that works too, I don't use that often, U-Boot has cannibalized the industry market Apr 15 16:15:24 ecdhe: straight, the jumps anyway are going to be painful if there's some hacks or very specific features added by the vendor Apr 15 16:16:17 ecdhe: I'd keep a build system clean with both buildable at any time, the 2.6 kernel and a vanilla upstream kernel, try to boot the upstream kernel, fixup everything until it does what the 2.6 did Apr 15 16:17:40 qschulz: not really, U-boot just became the reference bootloader mainly for arm, but it's awful. Thing is there was nothing better until barebox slowly started adding proper support for more and more platforms. Apr 15 16:18:37 switching to barebox is honestly one of the very first steps I consider when working on a board. I can't stand u-boot scripting and their code.. Apr 15 16:19:06 vdl: the point is, the market share of barebox cannot be compared to U-Boot's Apr 15 16:19:35 but one of my former colleague was an avid supporter of barebox :) Apr 15 16:19:53 vdl, qschulz: It's just a boot loader. That's like vim vs. emacs ;) Apr 15 16:20:55 RobertBerger: now imagine the immense majority of people are using emacs. And a vendor provides vim only, would they be happy :) ? Apr 15 16:21:27 @qschulz: I know a couple of such vendors ;) Apr 15 16:22:22 RobertBerger: the british "a couple" or the american :p ? Apr 15 16:22:28 qschulz: good spot. I'll add a SPLASH_IMAGES variable to my local.conf and test it out Apr 15 16:22:29 @qschulz: and tend to replace it with the other solution ;) Apr 15 16:22:35 thanks! Apr 15 16:22:44 escalion: good luck! Apr 15 16:23:00 Up next my rngd cpu hog investigation >.> Apr 15 16:24:57 Not looking forward to this *searches racking for a JTAG adaptor" Apr 15 16:26:56 yeah have fun scripting "just a boot loader", you'll quickly appreciate the work done on barebox Apr 15 16:38:36 vdl: If only bootloaders could be as simple as they are on microcontrollers :D Apr 15 16:39:25 escalion: sure. Sometimes I'm not sure to get the point of the second stage bootloaders, but well Apr 15 16:40:23 vdl: It's because of early initialisation memory limits. Basically you have to enable access to that memory, so you need a smaller bootloader to enable the memory and jump to it. Basically Apr 15 16:41:45 escalion: I guess it's cleaner to separate this step into a separate binary, but in most cases that can simply be part of the main bootloader, right? Apr 15 16:43:36 vdl: Depends on the size of the bootloader I guess. You can genuinely boot an x86 system in a ~20 lines of assembly, in this case you don't need a second stage. Apr 15 16:44:55 I'm all for separation of concerns when writing software, but sometimes people get a little carried away and end up making things more complicated than they were before Apr 15 16:47:51 I'll look over barebox later. I've stuck with u-boot because it's easy to get going (unlike when I first started using it), but open to change if it has genuine advantages Apr 15 16:48:40 Other thing to remember is often there is a 'hidden' stage which is built into the ROM of the CPU by the vendor Apr 15 16:49:05 So you sometimes end up with 3 stages of bootloader Apr 15 16:53:54 sgw1: if the toolchain.cmake file has the correct sysroot, I'm wondering if do_install overrides something Apr 15 16:53:57 escalion: barebox was "u-boot v2" to start with. It started as u-boot with a cleaner integration of upstream drivers and dts, and a more unix-y env (you have files, scripts and a really shell). Apr 15 16:55:22 so if I already have uboot working from a vendor why would I switch to barebox? Apr 15 16:56:33 alejandrohs: great suggestion. I tried running the cmake command in a devshell and the "all" target worked (used by compile) but the install target still failed. So maybe it's cmake itself Apr 15 16:57:33 vdl: the bootrom loads a very small bootloader into SRAM whose goal is to initialize DRAM and then load the full-featured bootloader. This wouldn't be an issue if the SRAM was big enough. The thing is, SRAM is darn expensive and more or less useless once you've booted into Linux, so the smaller the better. Apr 15 16:58:26 I'm sure I'm missing details, but that's the big overview of the boot process Apr 15 16:58:35 ^ this Apr 15 17:03:10 if only everyone agreed on the smaller the better :> Apr 15 17:03:18 qschulz: but yes, you're totally right Apr 15 17:05:15 ecdhe: if you have a working vendor bootloader and you don't need customization at the bootloader level, don't change. You *might* want to change if you need to customize it, like advanced scripting, recovery or boot logic, etc. Apr 15 17:09:24 vdl: I'm curious now, what kind of usecase you have to require advanced scripting? Apr 15 17:11:18 qschulz/vdl: i believe the "very small bootloader" is called the SPL (Secondary Program Loader) in some systems. from there it loads u-boot. this is the way our freescale/nxp imx6 processor board from varscite worked, for example. Apr 15 17:13:18 Variscite Apr 15 17:19:20 now i'm wondering: is u-boot discarded (overwritten) when linux boots? Apr 15 17:22:35 RP: you missed https://lists.openembedded.org/g/openembedded-core/message/150438?p=,,,20,0,0,0::Created,,khem,20,2,0,82107633 and https://lists.openembedded.org/g/openembedded-core/message/150405?p=,,,20,0,0,0::Created,,khem,20,2,0,82058865 onto master-next Apr 15 17:24:39 yates: yes SPL is its name Apr 15 17:24:53 sometimes you have a TPL too, don't remember why but eh Apr 15 17:26:22 ad-infinitum... Apr 15 17:26:24 yates: U-Boot loads at some place in DRAM, then U-Boot loads the kernel/dtb/initramfs whatever, at some other places in DRAM (where the user tells it to put the files; meaning you could break U-Boot at runtime if you're not careful) Apr 15 17:27:27 (this btw was used for an attack with huge images because U-Boot used to wrap the DRAM, so once you reach the max address, it was starting from the min address which is usually where U-Boot is, or something along those lines) Apr 15 17:27:52 Once the kernel is load in DRAM, you jump to it and where U-Boot was can be safely used for anything else Apr 15 17:28:05 loaded* Apr 15 17:29:15 qschulz: interesting Apr 15 17:30:26 qschulz: you sound like you have experience in writing bootloaders. Apr 15 17:31:36 khem: I'm not sure we need the go url change? I missed the systemd bit, yes Apr 15 17:39:23 RP: I think using https is better isnt it regardless ? Apr 15 17:39:38 we can also do it as a followup maybe Apr 15 17:44:42 RP: I sent a followup Apr 15 17:44:48 just changing SRC_URI Apr 15 17:48:41 khem: ok, thanks Apr 15 19:34:13 is there a way to get https://sourceware.org/gdb/onlinedocs/gdb/MiniDebugInfo.html in yocto? Apr 15 19:34:31 i'm trying to see if there's a simple way to get useful backtraces without full debug packages.. Apr 15 19:45:51 mischief: breakpad is an option Apr 15 19:50:50 including a client library in every program is a nonstarter Apr 15 19:56:15 also we don't (currently) save debug packages for built images. that is why having the minimum useful info already in the image would be good. Apr 15 19:59:44 as for the debug, if you do save this stuff from your build artifacts, it doesn't get deployed (for proprietary use this is protective and) it keeps space smaller as well in the deployed filesystems.. Apr 15 20:00:08 you can always debug (cross) WITHOUT the debug symbols on the target.. (threads need to have the thread library on the target, but that is I think the only limitation) Apr 15 20:00:38 If you don't mind debug on the target, then there are ways to limit the debug info, but I'm not sure anyone has made it generic (within the scope of YP) yet Apr 15 20:04:07 no, we can't debug on target at all Apr 15 20:05:18 whats ideal for us is automatic backtraces in logs (which we can read) and i believe implementing minidebuginfo (the link i posted above) would get us that without full symbols installed Apr 15 20:05:37 we dont even have room for full symbols installed :/ Apr 15 20:07:05 mischief: I'd say that implementing that wouldn't be too hard Apr 15 20:09:30 RP: i'm a bit of a noob on yocto internals, but fwict it would require overriding a ton of functionality in package.bbclass Apr 15 20:12:51 mischief: well, yes, but definitely doable. Apr 15 20:30:56 this isn't exactly a yocto question, but the image built with it has inconsistent USB bus numbering, and I'm wondering how to make it more consistent. Apr 15 20:32:14 dont rely on enumeration order? Apr 15 20:32:15 It has both ehci and ohci controllers, and sometimes ehci is bus 1 and sometimes it is bus 2. Apr 15 20:39:55 I mean, I hear what you're saying, mischief, but this feels like /dev/ttyS0 changing to /dev/ttyS1 on a reboot. I'm okay with not relying on _enumeration_ order, but the order of the bus designations seems like it should be constant. On a normal laptop it is tied to PCI bus numbering, and they are consistent. Apr 15 20:47:00 I wonder if /dev/modules-load.d/* happens before udev/systemd loads other modules... Apr 15 21:01:11 /dev/modules-load.d/ ? Apr 15 21:01:59 systemd (systemd-modules-load.service) is precisely what reads modules-load.d Apr 15 21:02:44 you could maybe control order by handling module probe order yourself, but really, i would avoid trying to rely on the order Apr 15 21:23:49 sorry, /etc/modules-load.d/ Apr 15 21:23:52 it's been a long day Apr 15 21:26:01 It just feels like such a superfluous thing, the arbitrary order. I can use udev to handle device mapping, say, so that a rs232<->USB device plugged into port 1 maps to /dev/ttyWhatever1, but I can't write rules to do this based on bus and port number. Apr 15 21:26:10 because the bus number changes on me. Apr 15 21:26:46 So do I write two sets of udev rules? Calculate which bus is which and rewrite the rules? Apr 15 23:49:26 fullstop: I think systemd had done some work in making the device names consistent Apr 16 00:06:12 khem: I created a modules-load.d conf file and load the ohci driver first, which seems to keep things consistent. Apr 16 00:07:01 another approach would be perhaps to write a udev rule which would name it when its detected Apr 16 00:07:05 then order wont matter Apr 16 00:11:56 khem: what do you mean by "it" ? Apr 16 00:12:40 If I have a udev rule which maps a usb serial device on bus 1 port 1 to something, bus 1 must remain bus 1. I don't think that you can give a bus a name. Apr 16 00:23:00 right yeah **** ENDING LOGGING AT Fri Apr 16 03:00:29 2021