| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 00:41 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 00:48 | |
| khem | RP: kergoth The gcc11 reproducibility issue is due to use of git SHA1 id in S, It would not happen for proper releases, however I think the check to replace debug-maps can be fixed | 00:59 |
|---|---|---|
| khem | and made mode robust, I Will send a patch | 01:00 |
| *** dplascen <dplascen!~Daniela_P@2806:103e:18:28ac:6910:47ab:74b7:f1df> has joined #yocto | 01:04 | |
| *** kpo_ <kpo_!~kpo@gl218-35.master.pl> has quit IRC | 01:39 | |
| *** kpo_ <kpo_!~kpo@gl218-35.master.pl> has joined #yocto | 01:40 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:40 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:53 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:54 | |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 01:55 | |
| *** otavio_ <otavio_!~otavio@200-180-244-11.user3p.brasiltelecom.net.br> has quit IRC | 01:56 | |
| *** chrysh <chrysh!~chrysh@someserver.de> has quit IRC | 01:56 | |
| *** chrysh <chrysh!~chrysh@someserver.de> has joined #yocto | 01:56 | |
| *** malinus <malinus!~malinus@unaffiliated/malinus> has quit IRC | 01:56 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC | 01:57 | |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has joined #yocto | 01:57 | |
| *** otavio_ <otavio_!~otavio@200-180-244-11.user3p.brasiltelecom.net.br> has joined #yocto | 01:58 | |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 01:59 | |
| *** nvmd <nvmd!~nvmd@177.30.111.232> has quit IRC | 02:03 | |
| *** malinus <malinus!~malinus@172.245.158.16> has joined #yocto | 02:03 | |
| *** malinus is now known as Guest12620 | 02:04 | |
| kergoth | khem: ah, interesting | 02:37 |
| *** dplascen <dplascen!~Daniela_P@2806:103e:18:28ac:6910:47ab:74b7:f1df> has left #yocto | 02:38 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has quit IRC | 02:42 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has joined #yocto | 02:43 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has quit IRC | 02:52 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 02:53 | |
| *** ahadi <ahadi!~ahadi@i5E86AFEB.versanet.de> has quit IRC | 02:59 | |
| *** ahadi <ahadi!~ahadi@i5E86AE61.versanet.de> has joined #yocto | 03:05 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-bkvmyogdusegrzxs> has quit IRC | 03:28 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 03:38 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 03:38 | |
| *** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 03:39 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 03:47 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:48 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 03:50 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:52 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 04:07 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 04:07 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 04:34 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 04:37 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 04:57 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 04:59 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 05:02 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 05:05 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 05:07 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 05:07 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 05:14 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 05:16 | |
| *** vineela <vineela!vtummala@nat/intel/x-gucvgqkjewmnlwcj> has quit IRC | 05:19 | |
| *** creich <creich!~creich@p200300f6af4d0510c07b9b6b83cbf090.dip0.t-ipconnect.de> has joined #yocto | 05:25 | |
| *** jobroe <jobroe!~manjaro-u@p579eb275.dip0.t-ipconnect.de> has joined #yocto | 05:27 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 05:27 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 05:29 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 05:29 | |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 05:32 | |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 05:34 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 05:35 | |
| *** linums <linums!~linums@apn-94-44-255-109.vodafone.hu> has joined #yocto | 05:35 | |
| *** Guest12620 <Guest12620!~malinus@172.245.158.16> has quit IRC | 05:37 | |
| *** Guest12620 <Guest12620!~malinus@unaffiliated/malinus> has joined #yocto | 05:37 | |
| *** Guest12620 is now known as malinus | 05:38 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ggsiukwzalxqppmz> has joined #yocto | 05:39 | |
| *** agust <agust!~agust@pd95f13e5.dip0.t-ipconnect.de> has joined #yocto | 05:58 | |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has quit IRC | 06:04 | |
| LetoThe2nd | yo dudX | 06:14 |
| *** cdgarren <cdgarren!2fe34aa7@047-227-074-167.res.spectrum.com> has quit IRC | 06:19 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 06:38 | |
| *** rcoote <rcoote!~rcoote@2a02:908:692:81c0:5431:696e:2c99:3f4a> has joined #yocto | 06:39 | |
| *** frsc <frsc!~frsc@26-74-142-46.pool.kielnet.net> has joined #yocto | 06:45 | |
| *** fl0v0 <fl0v0!~fvo@i59F44EC2.versanet.de> has joined #yocto | 06:55 | |
| *** pankaj347 <pankaj347!9d2daadf@157.45.170.223> has joined #yocto | 06:56 | |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has joined #yocto | 07:06 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:11 | |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has joined #yocto | 07:17 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 07:22 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:22 | |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 07:24 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:27 | |
| *** kpo_ <kpo_!~kpo@gl218-35.master.pl> has quit IRC | 07:31 | |
| creich | hi there, shouldn't it be sufficient to use INSTALL_IMAGE_remove += "package-name" to test dropping out one package of an image build? | 07:44 |
| creich | if i do that, i end up getting errors from the image build that tries to copy config files regarding that 'removed' package | 07:44 |
| creich | anything else needed to remove a package from an image? | 07:45 |
| creich | or do i have to run a complete clean build | 07:45 |
| creich | ? | 07:45 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-127-66.ssp.dialog.net.pl> has joined #yocto | 07:49 | |
| *** sahilgg <sahilgg!b6ed879b@182.237.135.155> has joined #yocto | 07:50 | |
| sahilgg | how to get into uboot menu? i want to use tftp for booting image | 08:01 |
| LetoThe2nd | sahilgg: usually by pressing some key on the serial console. if not, then read the documentation of the board. | 08:03 |
| qschulz | 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 | 08:12 |
| qschulz | "top-level" package* sorry | 08:13 |
| creich | 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 | 08:15 |
| creich | but i theory that should work, right? if not, i'd expect something else is wrong with the configuration | 08:16 |
| qschulz | 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" | 08:16 |
| qschulz | 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 | 08:16 |
| *** ericbutters <ericbutters!5b3d7226@gateway/web/cgi-irc/kiwiirc.com/ip.91.61.114.38> has joined #yocto | 08:16 | |
| qschulz | 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 | 08:17 |
| qschulz | those = the recipes that have RDEPENDS/RRECOMMENDS/DEPENDS on the package/recipe you don't want | 08:17 |
| creich | makes sense. I'll check for dependencies | 08:17 |
| creich | thx for the hint :) | 08:18 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 08:18 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:18 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:18 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 08:21 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:21 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 08:27 | |
| *** falk0n[m] <falk0n[m]!falk0nmatr@gateway/shell/matrix.org/x-izvwdaakcbmuynyb> has quit IRC | 09:00 | |
| *** phoenix <phoenix!d53dd19e@213.61.209.158> has joined #yocto | 09:04 | |
| *** phoenix is now known as Guest9820 | 09:04 | |
| Guest9820 | Can you attach a machine specific task to ROOTFS_POSTPROCESS_COMMAND? ROOTFS_POSTPROCESS_COMMAND_mymachine overwrites the default variable. | 09:07 |
| Scorpi | 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 | 09:07 |
| LetoThe2nd | Guest9820: ROOTFS_POSTPROCESS_COMMAND_append_mymachine ? (qschulz to the rescue) | 09:09 |
| mcfrisk | 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? | 09:09 |
| qschulz | Guest9820: LetoThe2nd: can confirm, that is the way to do it, don't forget the leading space | 09:11 |
| qschulz | 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 | 09:12 |
| qschulz | mcfrisk: oe-pkgdata-util find-path '*myshlib.so*' will return the package providing this lib if it's been built, otherwise happy hunting :) | 09:12 |
| Scorpi | qschulz: I think space wouldn be a big issue as logfiles usually compress well | 09:12 |
| Scorpi | qschulz: speaking of which, is there a tool to manage the state cache, e.g. find old and unused cache items? | 09:13 |
| mcfrisk | 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 | 09:16 |
| qschulz | Scorpi: bitbake-dumpsig and bitbake-diffsigs | 09:18 |
| qschulz | 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` | 09:19 |
| qschulz | at least a few of us here do it | 09:19 |
| Scorpi | okay, thanks | 09:19 |
| qschulz | (some even have this in a cronjob) | 09:19 |
| derRichard | 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? | 09:24 |
| derRichard | it looks like as if PACKAGES is ignored | 09:25 |
| derRichard | but when i run bitbake -e linux-firmware > vars.txt. i see linux-firmware-foo in the PACKAGES variable | 09:26 |
| qschulz | derRichard: the order is wrong :) | 09:27 |
| qschulz | ah no, my bad | 09:27 |
| mcfrisk | 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 | 09:28 |
| Guest9820 | @qschulz @LetoThe2nd Thanks! | 09:28 |
| qschulz | derRichard: what's inside the PACKAGES variable? | 09:28 |
| derRichard | qschulz: one moment, i can share the bb file | 09:29 |
| derRichard | just need to censor the vendor name^^ | 09:29 |
| qschulz | derRichard: just go for cat vars.txt | grep ^PACKAGES= | 09:30 |
| derRichard | https://paste.debian.net/plainh/a25e9469 | 09:32 |
| derRichard | beside of tons of other linux-firmware packages, i see in PACKAGES also linux-firmware-xxx | 09:32 |
| *** sahilgg76 <sahilgg76!b6ed879b@182.237.135.155> has joined #yocto | 09:32 | |
| derRichard | 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 | 09:33 |
| *** Guest9820 <Guest9820!d53dd19e@213.61.209.158> has quit IRC | 09:33 | |
| qschulz | derRichard: you did NOT do PACKAGES =+ " ${PN}-foo" but PACKAGES_append | 09:33 |
| qschulz | which is completely different | 09:33 |
| derRichard | yes, i just changed it | 09:33 |
| qschulz | so indeed, the order is wrong | 09:33 |
| derRichard | oh? | 09:33 |
| derRichard | which order? | 09:34 |
| qschulz | PACKAGES =+ prepends directly, PACKAGES_append appends later after everything is done (but before _remove is evaluated) | 09:34 |
| qschulz | derRichard: in PACKAGES | 09:34 |
| qschulz | files are put on the first package whose FILES_${PN} matches their path | 09:35 |
| qschulz | the "first package" being determined from the PACKAGES variable, from leftmost to rightmost | 09:35 |
| derRichard | hm, i had that already. when printing the PACKAGES variable i see linux-firmware-xxx being first | 09:36 |
| derRichard | let me try again without hackery | 09:36 |
| qschulz | 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 | 09:36 |
| derRichard | yes, i understand that _append is wrong | 09:37 |
| derRichard | but with PACKAGES =+ i see the same problem | 09:37 |
| derRichard | i'm rebuilding now woth =+ just to be sure | 09:37 |
| derRichard | maybe some other .bbappend messes with linux-firmware's PACKAGES variable? hmmm | 09:38 |
| *** snikulov <snikulov!~snikulov@109.252.49.163> has joined #yocto | 09:39 | |
| derRichard | just printed the PACKAGES variable, linux-firmware-xxx is first and linux-firmware is last. sounds about right to me | 09:40 |
| *** roussinm1 <roussinm1!~mroussin@bras-base-qubcpq0336w-grc-47-76-71-204-197.dsl.bell.ca> has joined #yocto | 09:42 | |
| derRichard | in vars.txt i see also: FILES_linux-firmware-xxx=" /lib/firmware/xxx/fw.bin " | 09:42 |
| derRichard | makes sense too | 09:42 |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 09:45 | |
| qschulz | 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 | 09:45 |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 09:45 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-47-76-71-204-197.dsl.bell.ca> has quit IRC | 09:46 | |
| qschulz | also... you don't need to make a bbappend for this firmware, especially since you add your own firmware by hand | 09:46 |
| derRichard | qschulz: thanks, i can do that myself. just wanted to make sure i'm on the right track | 09:46 |
| qschulz | just create your own recipe from scratch just for this firmware | 09:46 |
| qschulz | 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) | 09:46 |
| derRichard | 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 | 09:47 |
| derRichard | now you can guess on what bsp i am ;) | 09:47 |
| qschulz | derRichard: yes, this seems like a wrong approach to me | 09:48 |
| * derRichard takes a note | 09:48 | |
| sahilgg | 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? | 09:49 |
| qschulz | 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 | 09:49 |
| qschulz | derRichard: why don't you take https://source.codeaurora.org/external/imx/meta-imx directly? | 09:50 |
| *** linums <linums!~linums@apn-94-44-255-109.vodafone.hu> has quit IRC | 09:54 | |
| derRichard | qschulz: i showed you the first file google found | 09:54 |
| *** linums <linums!~linums@catv-89-133-16-128.catv.broadband.hu> has joined #yocto | 09:54 | |
| derRichard | i take my copy of meta-imx form the internal git... | 09:54 |
| *** pankaj347 <pankaj347!9d2daadf@157.45.170.223> has quit IRC | 09:57 | |
| qschulz | derRichard: aaaah, then just create your own recipe then :) | 09:59 |
| derRichard | but can i still use MACHINE_FIRMWARE then in my machine? | 10:00 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 10:03 | |
| qschulz | derRichard: can you point me to where this is defined/used, I don't think it is in vanilla poky/oe-core? | 10:03 |
| derRichard | jesus chist, i hate vendor stuff so much... | 10:04 |
| derRichard | let me see after lunch :-) | 10:04 |
| derRichard | conf/machine/include/imx-base.inc:MACHINE_EXTRA_RRECOMMENDS += "${MACHINE_FIRMWARE}" | 10:07 |
| derRichard | in meta-freescale | 10:07 |
| derRichard | is not that bad | 10:07 |
| derRichard | now i realize also that any recipe can do it, i thought MACHINE_FIRMWARE is special. m( | 10:08 |
| derRichard | qschulz: thanks a lot for pushing me into the right direction! | 10:08 |
| *** linums <linums!~linums@catv-89-133-16-128.catv.broadband.hu> has quit IRC | 10:09 | |
| *** snikulov <snikulov!~snikulov@109.252.49.163> has quit IRC | 10:10 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 10:10 | |
| *** linums <linums!~linums@apn-94-44-255-109.vodafone.hu> has joined #yocto | 10:10 | |
| qschulz | derRichard: my pleasure, happy hacking :) | 10:13 |
| *** dreyna <dreyna!~dreyna@2601:646:4201:e280:d901:f7e5:fabb:39ac> has joined #yocto | 10:19 | |
| *** dreyna <dreyna!~dreyna@2601:646:4201:e280:d901:f7e5:fabb:39ac> has quit IRC | 10:23 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC | 10:44 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 10:45 | |
| *** sahilgg <sahilgg!b6ed879b@182.237.135.155> has quit IRC | 10:49 | |
| *** sahilgg76 <sahilgg76!b6ed879b@182.237.135.155> has quit IRC | 10:51 | |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has quit IRC | 10:52 | |
| *** SinthuRaja <SinthuRaja!31cfcfec@49.207.207.236> has joined #yocto | 10:53 | |
| derRichard | 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 | 10:56 |
| qschulz | derRichard: that is... concerning :) | 11:03 |
| *** la_croix <la_croix!~la_croix@cpc117350-walt24-2-0-cust237.13-2.cable.virginm.net> has joined #yocto | 11:04 | |
| derRichard | qschulz: well, isn't the first time that cleanall did wonders when hitting yocto issues | 11:05 |
| rburton | don't use cleanall | 11:09 |
| rburton | it takes forever as it has to purge sstate too | 11:10 |
| rburton | -Cunpack would most likely have forced a rebuild | 11:10 |
| *** fl0v0 <fl0v0!~fvo@i59F44EC2.versanet.de> has quit IRC | 11:14 | |
| *** fl0v0 <fl0v0!~fvo@i59F44EC2.versanet.de> has joined #yocto | 11:14 | |
| *** linums <linums!~linums@apn-94-44-255-109.vodafone.hu> has quit IRC | 11:33 | |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has joined #yocto | 11:33 | |
| *** vygu2 <vygu2!9eff70c2@gateway/web/cgi-irc/kiwiirc.com/ip.158.255.112.194> has joined #yocto | 11:34 | |
| vygu2 | 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 | 11:37 |
| *** jobroe <jobroe!~manjaro-u@p579eb275.dip0.t-ipconnect.de> has quit IRC | 12:03 | |
| *** jobroe <jobroe!~manjaro-u@p579eb275.dip0.t-ipconnect.de> has joined #yocto | 12:04 | |
| qschulz | vygu2: do_install_append_class-nativesdk_append() ? | 12:14 |
| qschulz | well not even | 12:14 |
| qschulz | do_install_append_class-nativesdk would work fine too if I'm not mistaken | 12:14 |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has joined #yocto | 12:17 | |
| vygu2 | I would like to add PATH=\$PATH:${bindir} to create_wrapper to find m4 files | 12:21 |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has quit IRC | 12:22 | |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has joined #yocto | 12:32 | |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 12:32 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:d1f0:3d22:af09:7ac5> has joined #yocto | 12:42 | |
| *** cdgarren <cdgarren!2fe34aa7@047-227-074-167.res.spectrum.com> has joined #yocto | 12:54 | |
| *** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has joined #yocto | 12:59 | |
| eFfeM1 | Hi, I was wondering if I can nest bitbake variables, e.g. something like: | 13:06 |
| eFfeM1 | ${PN}_REV ?= "${AUTOREV}" | 13:06 |
| eFfeM1 | and then when checking out I would use rev=${${PN}_REV} | 13:06 |
| eFfeM1 | Idea is to allow per package redefinition of revision | 13:06 |
| *** vygu2 <vygu2!9eff70c2@gateway/web/cgi-irc/kiwiirc.com/ip.158.255.112.194> has quit IRC | 13:06 | |
| qschulz | eFfeM1: that means you want to modify ${PN}_REV somewhere right? | 13:18 |
| qschulz | so that it is not the default AUTOREV | 13:18 |
| eFfeM1 | qschulz what I want do do is AUTOREV, but I want to have the possibility to override the hash for a release build; | 13:19 |
| eFfeM1 | 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 | 13:20 |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 13:23 | |
| *** Sona <Sona!51aad934@h-170-217-52.A357.priv.bahnhof.se> has joined #yocto | 13:27 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-147-152.home.otenet.gr> has quit IRC | 13:30 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-140-86.home.otenet.gr> has joined #yocto | 13:32 | |
| *** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto | 13:33 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 13:34 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 13:37 | |
| *** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC | 13:39 | |
| eFfeM1 | ok, found out the hard way that it has to be | 13:41 |
| eFfeM1 | SRCREV = "${AUTOREV}" | 13:41 |
| eFfeM1 | I cannot even call it SRC_REV and append a rev=${SRC_REV} to my git URI | 13:41 |
| qschulz | eFfeM1: you also need PV to use SRCPV IIRC, the docs explain that anyway | 13:42 |
| eFfeM1 | yeah I have added this to my recipe | 13:43 |
| eFfeM1 | PV = "1.0+git${SRCPV}" | 13:43 |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 13:43 | |
| eFfeM1 | and with SRCREV that works but with SRC_REV and rev=${SRC_REV} it does not work | 13:43 |
| qschulz | eFfeM1: just have a conf file somewhere where you define SRCREV_pn-recipea = "${AUTOREV}" PV_pn-recipea = "1.0+git${SRCPV}" | 13:44 |
| qschulz | **include** (and NOT require) this file | 13:44 |
| qschulz | then for your releases, delete the file | 13:44 |
| qschulz | and voila | 13:44 |
| qschulz | and you define all your recipe's SRCREV and PV in there | 13:46 |
| qschulz | (yes, you need pn- in front, it is not a typo) | 13:46 |
| eFfeM1 | qschulz, ah ok, do you have two conf files (a different one for release with hashes in it) ? | 13:46 |
| qschulz | eFfeM1: no, I suggest you update the recipe so that it points to the correct revision | 13:47 |
| qschulz | eFfeM1: and we don't use AUTOREV at all, we use externalsrc for development and/or devtool | 13:47 |
| eFfeM1 | qschulz understood the rev part, I assume you do use SRCREV ?= in the recipe then | 13:48 |
| qschulz | eFfeM1: that's exactly what I was thinking about | 13:48 |
| *** Jonek <Jonek!531f2c90@83.31.44.144.ipv4.supernova.orange.pl> has quit IRC | 13:48 | |
| qschulz | you probably need SRCREV ?= indeed | 13:48 |
| eFfeM1 | I'm unaware of externalsrc and have never used devtool | 13:48 |
| qschulz | There has been at least one talk about CI/CD with Yocto at a Yocto project Summit | 13:49 |
| qschulz | so you might want to check it out :) | 13:50 |
| eFfeM1 | 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 | 13:51 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 13:52 | |
| *** thekappe <thekappe!c65a42b1@198.90.66.177> has joined #yocto | 13:53 | |
| thekappe | hello guys ! I'm using a distro with systemd | 13:54 |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-140-86.home.otenet.gr> has quit IRC | 13:54 | |
| *** SinthuRaja <SinthuRaja!31cfcfec@49.207.207.236> has quit IRC | 13:56 | |
| thekappe | I want to put some configuration file /opt/lib/systemd/network | 13:56 |
| thekappe | instead of /lib/systemd/network | 13:56 |
| thekappe | i've tried putting symbolink links but it doesn't work.. any suggestion ? | 13:56 |
| chrysh | 11:47 < derRichard> now you can guess on what bsp i am ;) | 13:57 |
| chrysh | 11:48 < qschulz> derRichard: yes, this seems like a wrong approach to me | 13:57 |
| chrysh | 11:48 * derRichard takes a note | 13:57 |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 13:57 | |
| derRichard | chrysh: hm? | 13:58 |
| LetoThe2nd | hm, hm | 13:59 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 14:00 | |
| *** sakoman <sakoman!~steve@72.173.249.164> has joined #yocto | 14:01 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-133-194.home.otenet.gr> has joined #yocto | 14:01 | |
| LetoThe2nd | oh, and by the way: https://twitter.com/TheYoctoJester/status/1382687655591256064 | 14:02 |
| chrysh | derRichard: oops, layer 8 error. | 14:03 |
| chrysh | but also, some imx* board I guess | 14:03 |
| derRichard | yeah, i work a lot for imx6 and 8 systems | 14:04 |
| derRichard | s/for/with/ | 14:04 |
| LetoThe2nd | many do that these days. | 14:05 |
| chrysh | why not 7? xD | 14:05 |
| * LetoThe2nd curses RP for making him read up on Honister Pass / Wikipedia now *during* worky hours. | 14:06 | |
| RobertBerger | Hey imx6 people ;) | 14:07 |
| RP | LetoThe2nd: heh. Keeps things interesting :) | 14:07 |
| chrysh | Nobody on imx7? what a pitty | 14:08 |
| RobertBerger | Did you try tiptop on a recent kernel with imx6 - arm32? | 14:08 |
| qschulz | chrysh: imx7 was much less popular than imx6 and 8 | 14:08 |
| qschulz | chrysh: we do have a product based on imx7d though, any specific question? | 14:08 |
| LetoThe2nd | 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? | 14:09 |
| qschulz | LetoThe2nd: you were the sunshine of that day but as all things need to be balanced, it poured rain in the UK | 14:10 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-nykcnstetaizhqgz> has joined #yocto | 14:10 | |
| chrysh | qschulz: no, I am just making jokes because we had a lot of trouble with imx7 in my previous company | 14:10 |
| LetoThe2nd | qschulz: that must be the most hilarous and cheesy compliment i've ever received over IRC. great job! | 14:11 |
| * qschulz blushes | 14:11 | |
| LetoThe2nd | qschulz: hi5 - lo5 - fistbump | 14:12 |
| yates | 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 | 14:12 |
| RP | yates: doesn't the ref manual go into details? | 14:12 |
| qschulz | 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 | 14:13 |
| sgw1 | Morning Folks | 14:13 |
| sgw1 | 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. | 14:13 |
| sgw1 | 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. | 14:13 |
| sgw1 | 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 | 14:13 |
| yates | RP: i'll take a look | 14:13 |
| LetoThe2nd | yates: i would probably say that this document is even more misleading that helping... you know, "blinky" | 14:13 |
| RP | yates: blinky is very very old now! | 14:14 |
| qschulz | Some people have nostalgy, what can I say | 14:14 |
| RP | I liked the pacman era, that was pre yocto | 14:14 |
| yates | doh. | 14:15 |
| yates | i liked Missile Command, myself.. | 14:16 |
| yates | (yes folks, I really did play the original MC game at the arcades...) | 14:16 |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-133-194.home.otenet.gr> has quit IRC | 14:17 | |
| yates | lim_{<curdate> - <birthdate>\approach\infty} = old guy | 14:18 |
| *** marc1 <marc1!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 14:18 | |
| yates | https://www.youtube.com/watch?v=nokIGklnBGY | 14:20 |
| *** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has quit IRC | 14:20 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:26 | |
| vdl | to ship a systemd foo.mount unit and enable it by default, should I bbappend systemd-conf or should I write a new package? | 14:26 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 14:27 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 14:27 | |
| qschulz | vdl: new package recipe | 14:28 |
| *** escalion <escalion!5186599c@mail.osukl.com> has joined #yocto | 14:29 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 14:30 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 14:31 | |
| escalion | 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 | 14:31 |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 14:31 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-133-194.home.otenet.gr> has joined #yocto | 14:33 | |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 14:36 | |
| vdl | qschulz: thanks | 14:38 |
| *** WillMiles <WillMiles!~Will@209.87.231.80> has joined #yocto | 14:39 | |
| qschulz | escalion: oe-pkgdata-util find-path '/usr/bin/psplash' | 14:42 |
| qschulz | then add the package that provides this binary to your image via IMAGE_INSTALL | 14:42 |
| qschulz | if there's none, happy hunting :) | 14:42 |
| * LetoThe2nd so totally misreads that nickname as"escalation" each and every time. | 14:42 | |
| yates | LetoThe2nd: sign of old age | 14:43 |
| yates | did you play Missile Command too? | 14:43 |
| *** jobroe <jobroe!~manjaro-u@p579eb275.dip0.t-ipconnect.de> has quit IRC | 14:44 | |
| LetoThe2nd | nope. | 14:45 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 14:47 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 14:47 | |
| *** WillMiles <WillMiles!~Will@209.87.231.80> has quit IRC | 14:47 | |
| escalion | qschulz: awesome, thanks for the pointer. I'll try it as soon as chromium has finished rebuilding! | 14:49 |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 14:49 | |
| escalion | LetoThe2nd: In voice enabled games plenty make the same mistake! | 14:51 |
| qschulz | 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 | 14:52 |
| qschulz | escalion: ^ | 14:52 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:53 | |
| escalion | 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 | 14:54 |
| *** thekappe <thekappe!c65a42b1@198.90.66.177> has quit IRC | 14:57 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 14:57 | |
| *** frsc <frsc!~frsc@26-74-142-46.pool.kielnet.net> has quit IRC | 14:57 | |
| *** thekappe <thekappe!c65a42b1@198.90.66.177> has joined #yocto | 15:04 | |
| qschulz | escalion: binaries are created per SPLASH_IMAGES and their package names are listed in SPLASH_INSTALL if I am not mistaken | 15:04 |
| qschulz | escalion: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/psplash?id=d3de5f7308b4a42b809884119a670af5bedde38f | 15:05 |
| vdl | 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? | 15:06 |
| qschulz | vdl: potato potato :) | 15:07 |
| qschulz | honestly, the name of the directory does not matter much ;) | 15:07 |
| vdl | 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 | 15:10 |
| *** frsc <frsc!~frsc@26-74-142-46.pool.kielnet.net> has joined #yocto | 15:10 | |
| * vdl creates an recipes-qschulz directory | 15:10 | |
| ecdhe | 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 | 15:12 |
| ecdhe | that is, until I saw how old the kernel is | 15:12 |
| vdl | ecdhe: I hope you're using a container at least to build everything | 15:13 |
| qschulz | ecdhe: am33xx have excellent upstream support | 15:13 |
| ecdhe | I have the kernel config they recommended, but I'm not sure how much of that stuff would still be applicable | 15:13 |
| qschulz | (kernel and u-boot for sure) | 15:13 |
| qschulz | ecdhe: assume none ;) | 15:13 |
| qschulz | you'll need to create a device tree for your SoM+carrier board though | 15:14 |
| vdl | qschulz: I switched to barebox for am335x, works like a charm | 15:14 |
| qschulz | but once done, upstream kernel + upstream yocto + upstream bootloader | 15:14 |
| qschulz | the dream | 15:14 |
| ecdhe | Would it be better to jump from 2.6 straight to 5.10, or should I do incremental upgrades? | 15:14 |
| qschulz | vdl: that works too, I don't use that often, U-Boot has cannibalized the industry market | 15:14 |
| qschulz | ecdhe: straight, the jumps anyway are going to be painful if there's some hacks or very specific features added by the vendor | 15:15 |
| vdl | 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 | 15:16 |
| vdl | 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. | 15:17 |
| vdl | 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.. | 15:18 |
| qschulz | vdl: the point is, the market share of barebox cannot be compared to U-Boot's | 15:19 |
| qschulz | but one of my former colleague was an avid supporter of barebox :) | 15:19 |
| RobertBerger | vdl, qschulz: It's just a boot loader. That's like vim vs. emacs ;) | 15:19 |
| qschulz | RobertBerger: now imagine the immense majority of people are using emacs. And a vendor provides vim only, would they be happy :) ? | 15:20 |
| RobertBerger | @qschulz: I know a couple of such vendors ;) | 15:21 |
| qschulz | RobertBerger: the british "a couple" or the american :p ? | 15:22 |
| escalion | qschulz: good spot. I'll add a SPLASH_IMAGES variable to my local.conf and test it out | 15:22 |
| RobertBerger | @qschulz: and tend to replace it with the other solution ;) | 15:22 |
| escalion | thanks! | 15:22 |
| qschulz | escalion: good luck! | 15:22 |
| escalion | Up next my rngd cpu hog investigation >.> | 15:23 |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has joined #yocto | 15:23 | |
| escalion | Not looking forward to this *searches racking for a JTAG adaptor" | 15:24 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 15:25 | |
| vdl | yeah have fun scripting "just a boot loader", you'll quickly appreciate the work done on barebox | 15:26 |
| escalion | vdl: If only bootloaders could be as simple as they are on microcontrollers :D | 15:38 |
| vdl | escalion: sure. Sometimes I'm not sure to get the point of the second stage bootloaders, but well | 15:39 |
| escalion | 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 | 15:40 |
| vdl | 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? | 15:41 |
| escalion | 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. | 15:43 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:2d0c:893d:5593:863c> has quit IRC | 15:43 | |
| escalion | 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 | 15:44 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:c6a:9ade:28ad:18c> has joined #yocto | 15:45 | |
| escalion | 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 | 15:47 |
| escalion | Other thing to remember is often there is a 'hidden' stage which is built into the ROM of the CPU by the vendor | 15:48 |
| escalion | So you sometimes end up with 3 stages of bootloader | 15:49 |
| alejandrohs | sgw1: if the toolchain.cmake file has the correct sysroot, I'm wondering if do_install overrides something | 15:53 |
| vdl | 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). | 15:53 |
| ecdhe | so if I already have uboot working from a vendor why would I switch to barebox? | 15:55 |
| sgw1 | 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 | 15:56 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 15:57 | |
| qschulz | 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. | 15:57 |
| qschulz | I'm sure I'm missing details, but that's the big overview of the boot process | 15:58 |
| escalion | ^ this | 15:58 |
| *** escalion <escalion!5186599c@mail.osukl.com> has quit IRC | 16:02 | |
| vdl | if only everyone agreed on the smaller the better :> | 16:03 |
| vdl | qschulz: but yes, you're totally right | 16:03 |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 16:03 | |
| vdl | 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. | 16:05 |
| qschulz | vdl: I'm curious now, what kind of usecase you have to require advanced scripting? | 16:09 |
| *** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 16:10 | |
| yates | 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. | 16:11 |
| yates | Variscite | 16:13 |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 16:13 | |
| *** frsc <frsc!~frsc@26-74-142-46.pool.kielnet.net> has quit IRC | 16:19 | |
| yates | now i'm wondering: is u-boot discarded (overwritten) when linux boots? | 16:19 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 16:20 | |
| khem | 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 | 16:22 |
| qschulz | yates: yes SPL is its name | 16:24 |
| qschulz | sometimes you have a TPL too, don't remember why but eh | 16:24 |
| yates | ad-infinitum... | 16:26 |
| qschulz | 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) | 16:26 |
| qschulz | (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) | 16:27 |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 16:27 | |
| qschulz | Once the kernel is load in DRAM, you jump to it and where U-Boot was can be safely used for anything else | 16:27 |
| qschulz | loaded* | 16:28 |
| yates | qschulz: interesting | 16:29 |
| yates | qschulz: you sound like you have experience in writing bootloaders. | 16:30 |
| RP | khem: I'm not sure we need the go url change? I missed the systemd bit, yes | 16:31 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 16:32 | |
| khem | RP: I think using https is better isnt it regardless ? | 16:39 |
| khem | we can also do it as a followup maybe | 16:39 |
| khem | RP: I sent a followup | 16:44 |
| khem | just changing SRC_URI | 16:44 |
| RP | khem: ok, thanks | 16:48 |
| *** fl0v0 <fl0v0!~fvo@i59F44EC2.versanet.de> has quit IRC | 17:09 | |
| *** thekappe <thekappe!c65a42b1@198.90.66.177> has quit IRC | 17:17 | |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 17:18 | |
| *** nvmd <nvmd!~nvmd@177.30.111.232> has joined #yocto | 17:21 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 17:23 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 17:25 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 17:35 | |
| *** EddyEdgy <EddyEdgy!uid193337@gateway/web/irccloud.com/x-hcysdjpnpuxtdjbg> has joined #yocto | 17:42 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC | 17:43 | |
| *** cdgarren <cdgarren!2fe34aa7@047-227-074-167.res.spectrum.com> has quit IRC | 17:43 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 17:46 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:53 | |
| *** kpo_ <kpo_!~kpo@gl88-35.master.pl> has joined #yocto | 17:55 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 17:56 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@dh207-121-206.xnet.hr> has joined #yocto | 17:57 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 17:58 | |
| *** pharaon2502 <pharaon2502!~manjaro-u@dh207-121-206.xnet.hr> has quit IRC | 17:59 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:01 | |
| *** rcoote <rcoote!~rcoote@2a02:908:692:81c0:5431:696e:2c99:3f4a> has quit IRC | 18:07 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ggsiukwzalxqppmz> has quit IRC | 18:12 | |
| *** EddyEdgy <EddyEdgy!uid193337@gateway/web/irccloud.com/x-hcysdjpnpuxtdjbg> has quit IRC | 18:30 | |
| mischief | is there a way to get https://sourceware.org/gdb/onlinedocs/gdb/MiniDebugInfo.html in yocto? | 18:34 |
| mischief | i'm trying to see if there's a simple way to get useful backtraces without full debug packages.. | 18:34 |
| *** ericbutters <ericbutters!5b3d7226@gateway/web/cgi-irc/kiwiirc.com/ip.91.61.114.38> has quit IRC | 18:42 | |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 18:43 | |
| khem | mischief: breakpad is an option | 18:45 |
| mischief | including a client library in every program is a nonstarter | 18:50 |
| mischief | 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. | 18:56 |
| fray | 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.. | 18:59 |
| fray | 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) | 19:00 |
| fray | 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 | 19:00 |
| mischief | no, we can't debug on target at all | 19:04 |
| *** Sona <Sona!51aad934@h-170-217-52.A357.priv.bahnhof.se> has quit IRC | 19:04 | |
| mischief | 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 | 19:05 |
| mischief | we dont even have room for full symbols installed :/ | 19:05 |
| RP | mischief: I'd say that implementing that wouldn't be too hard | 19:07 |
| mischief | RP: i'm a bit of a noob on yocto internals, but fwict it would require overriding a ton of functionality in package.bbclass | 19:09 |
| RP | mischief: well, yes, but definitely doable. | 19:12 |
| *** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 19:15 | |
| fullstop | 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. | 19:30 |
| mischief | dont rely on enumeration order? | 19:32 |
| fullstop | It has both ehci and ohci controllers, and sometimes ehci is bus 1 and sometimes it is bus 2. | 19:32 |
| fullstop | 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. | 19:39 |
| fullstop | I wonder if /dev/modules-load.d/* happens before udev/systemd loads other modules... | 19:47 |
| mischief | /dev/modules-load.d/ ? | 20:01 |
| mischief | systemd (systemd-modules-load.service) is precisely what reads modules-load.d | 20:01 |
| mischief | you could maybe control order by handling module probe order yourself, but really, i would avoid trying to rely on the order | 20:02 |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 20:08 | |
| fullstop | sorry, /etc/modules-load.d/ | 20:23 |
| fullstop | it's been a long day | 20:23 |
| fullstop | 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. | 20:26 |
| fullstop | because the bus number changes on me. | 20:26 |
| fullstop | So do I write two sets of udev rules? Calculate which bus is which and rewrite the rules? | 20:26 |
| *** smooge <smooge!~smooge@centos/qa/smooge> has left #yocto | 20:32 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 20:48 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 20:48 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 21:10 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 21:20 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:26 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:28 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has quit IRC | 21:38 | |
| *** itseris <itseris!~itseris@d75-157-111-210.bchsia.telus.net> has joined #yocto | 21:39 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:40 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 21:41 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:00 | |
| *** pbb <pbb!~quassel@mail.petabyte.dev> has quit IRC | 22:09 | |
| *** pbb <pbb!~quassel@mail.petabyte.dev> has joined #yocto | 22:10 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:11 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:17 | |
| *** agust <agust!~agust@pd95f13e5.dip0.t-ipconnect.de> has quit IRC | 22:18 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:22 | |
| khem | fullstop: I think systemd had done some work in making the device names consistent | 22:49 |
| *** fury <fury!uid193779@gateway/web/irccloud.com/x-mbssxvsyxsshigmr> has joined #yocto | 22:57 | |
| fullstop | khem: I created a modules-load.d conf file and load the ohci driver first, which seems to keep things consistent. | 23:06 |
| khem | another approach would be perhaps to write a udev rule which would name it when its detected | 23:07 |
| khem | then order wont matter | 23:07 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 23:08 | |
| fullstop | khem: what do you mean by "it" ? | 23:11 |
| fullstop | 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. | 23:12 |
| khem | right yeah | 23:23 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!