**** BEGIN LOGGING AT Mon May 11 02:59:57 2020 May 11 12:13:37 I'm in the process of upgrading from warrior til dunfell and I have run into an issue about a missing Manifest (manifest-x86_64_x86_64-nativesdk-initramfs.packagedata). This happens for a simple recipe I have for creating a package with kernel fitimage including ramdisk. May 11 12:32:30 Hello, i'm relatively new to yocto, so sorry if the question feels dumb. I have the task at work to get sound output working with the development board for the variscite var-som-mx7. The output driver is a max98357a and is to be controlled via i2s. Now the problem is i have never compiled a kernel before, though i have good knowledge of electronics and basic knowledge of computers and linux. I have the kernel source repo from variscite (linux-imx) and i just May 11 12:32:30 need to know what modules i have to load to get this driver working. Also i need to adjust the device tree source file, which i am able to decompile and inspect, but it is unclear to me how i need to describe my driver hardware. Any help would be appreciated :D May 11 12:35:04 samsi: first and foremost, don't variscite happen to provide a proper bsp layer? May 11 12:36:04 Thank you for the quick answer. What is a BSP layer? May 11 12:36:47 samsi: because just "having" the source means that you will at least have to create a modified recipe for it, and probably some (minor) patching to get the device tree right. May 11 12:36:47 samsi: a "Board Support Package" Layer May 11 12:37:05 samsi: sounds like you might want to spend some time watching https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj to understand some things :) May 11 12:40:20 there seems to be two BSP layers from variscite, meta-variscite-imx and meta-variscite-fsl. Pick your poison if you don't already have one May 11 12:40:30 https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/sound/max98357a.txt for the DT May 11 12:41:24 Ahh okay. Thanks for the playlist, will start watching :) May 11 12:42:11 https://elixir.bootlin.com/linux/latest/source/sound/soc/codecs/max98357a.c this the driver May 11 12:42:55 https://elixir.bootlin.com/linux/latest/source/sound/soc/codecs/Makefile#L409 this the config option you want enabled in the defconfig May 11 12:43:17 i found the DT too, but am i correct that i have to place the example in the root of the device tree? And how does it know which GPIO to use? May 11 12:43:30 if the bsp deserves its name the module should be built anyways and hapefully enabled in the DT too. May 11 12:43:52 whats a BSP good for besides otherwise? May 11 12:44:12 The max98357a is external and not on the dev board, soooo May 11 12:44:28 Letothe2nd: we have a BSP which works only in one very specific configuraiton. But "it works" you know :) May 11 12:44:44 (not *our* BSP though) May 11 12:44:47 qschulz: hehe May 11 12:45:04 samsi: in that case, what qschulz said. May 11 12:45:48 samsi: i guess you want to watch at least #1, #2, #5, #6 and #7 :) May 11 12:46:11 enrich with some reading of the dev- and kernel-manuals :) May 11 12:46:22 samsi: see the small string starting with &? That;s a phandle, it refers to some other DeviceTree node, in that case the gpio controller. Then the numbers following that are dependent on the gpio controller (hooray), but usually the gpio number, and if there are banks, maybe the bank number, then the gpio number in the bank May 11 12:46:30 note that it's optional though ;) May 11 12:47:07 qschulz: now please add a link to the bindings description file and we're set :) May 11 12:47:19 Letothe2nd: Will do, my current knowledge is definitely not enough. May 11 12:47:36 Letothe2nd: I've done it, first thing :) May 11 12:48:09 qschulz: ah perfect :) May 11 12:49:11 samsi: if it's connected via i2s as google is telling me, you'll need to put the device tree node in the correct i2s controller node May 11 12:49:46 qschulz: Ah okay, thanks for the clarification. But then that applies only to the sdmode gpios, so how exactly does the kernel know on which gpio it is? Is it jsut looking for it and hoping it finds it? May 11 12:49:48 samsi: and give the address on the i2s bus by using reg = ; (replace addr with the hex value of the addr, and it needs to be surrounded with <>) May 11 12:50:12 qschulz: Ahh, well that makes sense May 11 12:50:27 samsi: and you need to provide the correct pinmuxing for the max DT node May 11 12:50:39 make sure everything invovled in this has a status = okay May 11 12:56:46 I think i will get it to work. Compile the BSP yocto with the correct driver, add the driver to the correct i2s bus in the DT, and i'm good to go, right? May 11 12:57:12 refresh my memory its IMAGE_INSTALL_append += " packagegroup-core-ssh-openssh openssh-sftp-server" for systemd May 11 12:57:34 so sshd actually works May 11 12:58:45 Anyone who have built gcc-cross with go support in Yocto? May 11 13:01:42 Just adding go to the LANGUAGES list in gcc-cross triggers errors with the standard header files. This error is not triggered when building with LANGUAGES set to default c and c++. May 11 13:06:16 smurray: and pinmuxing of the i2s lines if need be but more or less yes. https://bootlin.com/training/embedded-linux/ and https://bootlin.com/training/kernel/ maybe if you're supposed to start working heavily with the kernel (the materials are free access) May 11 13:06:23 samsi: ^ May 11 13:38:52 anyone here who can maybe help me out with this question? https://stackoverflow.com/q/61673614/5144291 May 11 13:39:07 or tell me how wrong i am for wanting it ;) May 11 13:42:06 topisani: Looks fine. If you machine config sets a variable your recipe will be able to see the value when that machine is selected May 11 13:42:27 You can use `bitbake -e ` to dump the variable data and confirm how everything is set May 11 13:42:34 topisani: its not exactly impossible, but probably requires some bunch of scripting to grab things from the environment and put them into the openocd configuration May 11 13:43:26 Letothe2nd: i am using openocd to flash an mcu from the pi, so i just write an openocd.cfg file in one of my recipes May 11 13:43:41 paulbarker: lol thanks, didn't think it would be that simple May 11 13:44:42 paulbarker: did you just make somebody happy by shoing "bitbake -e"? May 11 13:45:23 Letothe2nd: Stranger things have happened May 11 13:45:28 i knew about bitbake -e, but for some reason i didnt expect the machine config file to just be able to set arbitrary env vars May 11 13:46:01 paulbarker: ok, you got a point there. :) May 11 13:47:11 topisani: that the big difference between conf files and recipes. May 11 13:47:20 ah May 11 13:47:20 https://twitter.com/TheYoctoJester/status/1217166071519744000 May 11 13:47:53 ill recite that each night before i go to bed May 11 13:48:34 please do so. May 11 13:49:33 actually, i tried that but it doesnt work - are the variables set within the do_install functions still? May 11 13:51:02 i have `OPENOCD_SWCLK_PIN = "16"` in my machine cfg, and `sed -i 's//$OPENOCD_SWCLK_PIN/' ...` in `do_install` in my recipe, but the variable doesnt seem to be set in there May 11 13:51:48 do i need to do something special to have the variable available in do_install? May 11 13:52:57 topisani: Try ${OPENOCD_SWCLK_PIN}. Also try using it outside single quotes. Probably just needs a tweak like that so it expands correctly May 11 13:53:36 sorry, its in "s already, and it works if i just set the variable on the line abovwe May 11 13:55:31 just gonna try a few more things, lemme see May 11 13:56:34 alright, you're right, the issue is somewhere else, thanks for your help! May 11 13:56:47 good old echo always reveals the truth May 11 14:02:01 paulbarker: so, the brackets ${XXX} fixed the issues. Why? is there something special to how variables are expanded from the recipes? May 11 14:02:42 topisani: I actually can't remember, I always use ${XXX} out of habit these days May 11 14:03:23 bitbake substitutes the variables before writing out the shell script instead of exporting them into the environment May 11 14:03:29 right, ill stick to that then. Because $XXX works fine in shell scripts outside of bitbake, but i think i hit that issue with something else too recently May 11 14:03:38 ah, right, figured it was something like that May 11 14:03:45 You can confirm by looking at the run.do_install file for your recipe May 11 14:03:49 and bitbake only understands it with braces i assume May 11 14:03:55 oh yeah, nice tip! May 11 14:04:14 I'll be in `tmp/work////temp/run.do_install` May 11 14:06:36 paulbarker: https://twitter.com/TheYoctoJester/status/1259847307681574922 May 11 14:07:40 Letothe2nd: Haha. That's a silly typo May 11 14:09:05 paulbarker: those are the best ones. May 11 14:14:49 jonmason: Are you around? I have a few questions about meta-arm May 11 14:17:25 JPEW: yes? May 11 14:18:12 How stable can i expect poky's master/master-next to be? I'd really like to be able to use GCC 10, and dont mind being a bit on the bleeding edge, as long as its useable by some vague definition... May 11 14:18:35 jonmason: I've been trying to unify a few of the BSP layers to pull TF-A from meta-arm, so I have a few updates to that recipe (patches will be posted soon). May 11 14:19:03 jonmason: The one annoyance I haven't figured out the best way to solve if the dependency on meta-python (for optee) May 11 14:19:07 topisani: Usually master is pretty stable but gcc 10 will likely break things and it'll take a little time for them to get fixed. Helping with testing is much appreciated though! May 11 14:19:07 JPEW: Cool. We are about to cut dunfell release. So, if you can get those out ASAP it would be good May 11 14:20:06 JPEW: What's the issue? Python makes it the image too fat? May 11 14:20:42 paulbarker: alright, ill give it a go then when its merged to master - really impressed by the fast adoption! May 11 14:20:56 jonmason: It's just a little annoying to make a BSP layer (which will depend on meta-arm) *have* to pull in meta-python May 11 14:22:44 jonmason: Wasn't sure if we could use BBFILES_DYNAMIC to make optee optional on meta-python (or if theres a way to PACKAGECONFIG out the meta-python parts of optee and do the same thing). May 11 14:26:29 jonmason: TF-A patches sent May 11 14:26:34 JPEW: I'd have to look into it, as I'm not sure about what exactly the dependency is and if it can be cut out as necessary. Can you email the meta-arm mailing list? May 11 14:27:05 JPEW: Thanks. I have pending TF-A2.2 and 2.3 coming out soon May 11 14:27:40 jonmason: I sent a 2.3 recipes as part of my series (had to have it fix a reboot issue with RK3399) May 11 14:28:20 JPEW: The joys of week long internal reviews :) May 11 14:29:59 jonmason: Fun! The only part I'm not sure about is the MBEDTLS support; I'm not sure how to test that (or if I even have a board that can test it( May 11 14:30:33 JPEW: the last review comment I got was that the MBEDTLS version was too old for 2.3 ;-) May 11 14:33:23 JPEW: meta-rockchip patches in 5... 4... 3... ;-) May 11 14:36:56 tlwoerner: Yep, once jonmason merges mine into meta-arm :) May 11 14:41:30 jonmason: I almost think it would be better if upstream TF-A pulled in mbedtls as a git submodule May 11 14:42:07 jonmason: Actually, not almost. I would be better :) May 11 14:42:19 s/I/It/ May 11 14:42:28 JPEW: patches always welcome ;-) May 11 14:43:11 but I would hold off on something that big until dunfell branch is cut, which ETA is Friday May 11 15:06:44 topisani: stuff only merges once its build on the autobuilders so you shouldnt' suddenly find yourself in a system that won't even build (assuming you stick to oe-core). however it will change rapidly underneath you. May 11 15:16:51 I don't understand how POSTINST_INTERCEPTS* work in warrior: first, POSTINST_INTERCEPTS_PATHS was added in thud, but it is still not documented in ref-variables.xml in dunfell; then its content seems to be ignored, "bitbake -e" says POSTINST_INTERCEPTS is set from image-postinst-intercepts.bbclass, and adding traces to PackageManager._initialize_intercepts() confirms it was set previously, but if I add traces to image-postinst-intercepts.bbclass May 11 15:16:51 they don't get into the logs (is that linked to it being an event handler ?), which makes the thing a bit tricky to debug May 11 15:17:00 any hint ? May 11 18:28:40 RP: sent a v3 which should address all issues you reported May 11 18:28:48 so far May 11 18:35:20 morning all May 11 18:35:47 khem: thanks, those are the ones we've seen so far May 11 18:35:52 hi blue May 11 18:35:57 hi bluelightning! :) May 11 18:36:02 somewhere we had a wiki page listing YP/OE users, but I'm having trouble finding it atm May 11 18:36:07 anyone know where it is? May 11 18:36:41 bluelightning: https://wiki.yoctoproject.org/wiki/Project_Users ? May 11 18:36:58 RP: thanks May 11 18:44:32 bluelightning: the list on that page looks pretty complete for companies that are active contributors to the project. But for companies that are users of the project for development, it is quite incomplete. In all my years of supporting clients using Yocto to build products most wanted to remain quiet about it. May 11 18:44:46 RP: I tried your suggestion for pulling multiconfig packages into images/sdk by adding feeds and adding package to IMAGE_INSTALL. I added extra feeds to PACKAGE_ARCHS (but cross is in the same nativesdk anyway). in all cases bitbake says "Nothing RPROVIDES but something depends on it". any clues? May 11 18:46:28 denix: Did I not say PACKAGE_INSTALL? May 11 18:47:32 sakoman: its definitely incomplete but we wanted to write down a list of all the ones we can list May 11 18:47:41 sakoman: if there are any you can add... May 11 18:49:47 RP: I believe it was IMAGE_INSTALL, but I can try PACKAGE_INSTALL too :) May 11 18:50:25 RP: looks like the same error May 11 18:52:45 denix: have a look at the assignments and see if you can find the one which it installs but doesn't RDEPEND upon May 11 19:13:52 RP: I'll ping a few clients and see if they'd like to be added May 11 20:15:29 sakoman: thanks! May 11 20:56:22 RP: looks like my fix worked: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1019 May 11 21:23:56 hi! May 11 21:27:14 i have used all patches from here https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/systemd/systemd/ but still gatting error http://paste.org.ru/?8432c4 May 11 21:27:37 in custom linux, not yocto May 11 22:44:27 zeddii: nice and green, cool :) May 11 23:10:07 cronolio:https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch might be interesting May 11 23:10:29 RP: yup. will try one variant of the change tomorrow and then send my queue. May 11 23:10:48 cronolio: maybe also add gshadow to PACKAGECONFIG **** ENDING LOGGING AT Tue May 12 03:00:16 2020