**** BEGIN LOGGING AT Wed Nov 07 02:59:59 2018
Nov 07 08:44:16 <yocti> New news from stackoverflow: How to re-generate yocto SDK in deploy folder <https://stackoverflow.com/questions/53185960/how-to-re-generate-yocto-sdk-in-deploy-folder>
Nov 07 09:44:29 <yocti> New news from stackoverflow: lib32-ncurses not installing into rootfs <https://stackoverflow.com/questions/53186500/lib32-ncurses-not-installing-into-rootfs>
Nov 07 09:58:08 <jofr> I can't seem to get rid of the NOTE complaining that there are multiple providers available for my "virtual/appmod" and that I should consider defining a PREFERRED_RPROVIDER for it. I've gone so far as to put the two lines right in my image-recipe, and it still complains: PREFERRED_RPROVIDER_virtual/appmod = "appmod-molly" [\n] RDEPENDS_${PN} = "virtual/appmod"
Nov 07 09:58:15 <jofr> Am I missing something obvoius?
Nov 07 09:58:19 <jofr> obvious?
Nov 07 10:07:23 <erbo> jofr: It should go into global configuration (like local.conf or distro conf) and not a recipe
Nov 07 10:08:19 <erbo> oh wait, I was missing the R as in RPROVIDERS
Nov 07 10:11:14 <jofr> I reverted my change back to imageA.bb IMAGE_INSTALLing appmod-A, and imageB.bb IMAGE_INSTALLing appmod-B.
Nov 07 10:12:51 <jofr> Both images require an image-common.bb and I was trying to IMAGE_INSTALL my "virtual/appmod" in there, and then just defining a different provider for each of the other images that depend on it..
Nov 07 10:13:57 <jofr> Also tried having my image-common.bb RDEPEND on virtual/appmod, but it had the same effect.
Nov 07 10:16:02 <erbo> jofr: have you tried setting it in global configuration instead of in a recipe scope?
Nov 07 10:16:59 <erbo> But then I guess it doesn't fit your usecase
Nov 07 12:35:48 <zagor> I'm writing a recipe for a cmake-based package, and I'm running into the sysroot /not/exist issue. this feels like it is solved generically somewhere, but I fail to find where/how.
Nov 07 12:39:13 <zagor> the specific issue I have is that the cross-compiler does not find libc and libcc header files such as cstdint and assert.h
Nov 07 12:40:05 <zagor> since its' sysroot is set to /not/exist
Nov 07 12:40:53 <zagor> this can be configured per-package, but that would be a huge duplication of code and I also don't see packages doing that. so what is it I should do?
Nov 07 12:51:39 <OutBackDingo> ok whats a FIT image ?
Nov 07 12:57:59 <Crofton> kernel glued to device tree and possibly rootfs
Nov 07 12:58:06 <Crofton> all the cool kids use them now
Nov 07 13:14:00 <jofr> I'm using a custom in-house build-system (.....don't ask...) to build a package. It supports a "threads" argument, similar to make's "-j". Is it considered bad practice to use multiple threads for a recipe like that?
Nov 07 13:15:15 <jofr> Because bitbake does it's own threading/forking and builds multiple packages simultaneously.. That's why I'm wondering about it..
Nov 07 13:20:35 <neverpanic> jofr: Nope, bitbake parallelizes on multiple levels, by building multiple recipes at the same time and by executing tasks in parallel while building those recipes.
Nov 07 13:33:36 <rburton> zagor: the cmake file is overwriting the provided cc/cflags/ldflags
Nov 07 13:33:40 <rburton> as they have the path to the right sysroot in
Nov 07 13:34:08 <zagor> rburton: are they set in the environment?
Nov 07 13:34:22 <zagor> environment variables, I mean
Nov 07 13:34:52 <rburton> zagor: a toolchain file is used to set CMAKE_C_COMPILER and CMAKE_C_FLAGS
Nov 07 13:34:56 <rburton> (see cmake.bbclass
Nov 07 13:35:43 <zagor> ok. thanks!
Nov 07 13:45:20 <yocti> New news from stackoverflow: conflicting requests error while building SDK <https://stackoverflow.com/questions/52877506/conflicting-requests-error-while-building-sdk>
Nov 07 14:15:26 <yocti> New news from stackoverflow: NTP daemon on Yocto Krogoth <https://stackoverflow.com/questions/53190937/ntp-daemon-on-yocto-krogoth>
Nov 07 14:23:38 <jofr> neverpanic: Ok, but does that mean that there is a variable I can use to pass the number of threads to the sub-buildsystem?
Nov 07 14:31:56 <rburton> we pass PARALLEL_MAKE to make calls
Nov 07 14:31:57 <rburton> PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
Nov 07 14:32:25 <rburton> it's sad that -j is in there, because it means everyone has to replicate the logic to rip out the -j
Nov 07 14:33:17 <rburton> oh, that's right, someone fixed this already
Nov 07 14:33:26 <rburton> oe.utils.parallel_make() will give you the number
Nov 07 14:33:51 <rburton> and a helper function below
Nov 07 14:33:57 <rburton>     e.g. if PARALLEL_MAKE = "-j 10", parallel_make_argument(d, "-n %d") will return "-n 10"
Nov 07 14:35:29 <rburton> can't help think that a proper fix would be to redefine PARALLEL_MAKE as '-j ${BB_NUM_SUBTASKS}' or similar, default that to cpu_count, deprecate PARALLEL_MAKE, then fix everyone else to use BB_NUM_SUBTASKS instead of parsing PARALLEL_MAKE
Nov 07 14:44:14 <rburton> actually that seems like a totally sensible thing to do.  PARALLEL_MAKE will exist but the recommendation will be to set BB_NUM_SUBTASKS or something instead.  the default is just 'number of cores' now so fewer people set it than before
Nov 07 14:45:33 <yocti> New news from stackoverflow: How to copy content from .repo/manifests during repo sync? <https://stackoverflow.com/questions/52862542/how-to-copy-content-from-repo-manifests-during-repo-sync>
Nov 07 14:51:26 <kergoth> rburton: probably a good idea, yes. repeatedly parsing something make-specific is a bit silly
Nov 07 15:15:15 <armpit> RP rocko-next clean build last night with 4.4 kernel updated. want me to prep QA build run?
Nov 07 15:17:27 <armpit> zeddii, the kernel updates passed AB, I sent patches to list on my changes
Nov 07 15:19:34 <zeddii> cool.
Nov 07 15:48:57 <rondo-de> i'm looking for same actuel good tutorials to build em. linux for rpi64 with WIFI support , have somebody an Idea ?
Nov 07 15:54:46 <donster> Hi All, having some problems getting openssh sshd running under systemd. I'm including ssh-server-openssh to my image features and sshd is being installed on the target. But when I use systemctrl to get a status, it can't.
Nov 07 16:08:39 <stefans__> Hi. I'm having a build error when doing populate_sdk on the same build dir and re-using sstate when changing machine (same arch though):  ERROR: my-image-1.0-r0 do_populate_sdk: The recipe my-image is trying to install files into a shared area when those files already exist. Those files and their manifest location are:  /home/builder/build/tmp/depl
Nov 07 16:08:40 <stefans__> oy/sdk/poky-glibc-x86_64-my-image-cortexa7hf-neon-toolchain-1.0.testdata.json
Nov 07 16:09:40 <stefans__> Basically I'm doing MACHINE=machine1 bitbake my-image && MACHINE=machine1 bitbake my-image -c populate_sdk && MACHINE=machine2 bitbake my-image && MACHINE=machine2  bitbake my-image -c populate_sdk
Nov 07 18:00:24 <RP> armpit: ok, great. I'll do the release bits shortly (ba srcrev bump and check DISTRO_VERSION. Did we set DISTRO_VERSION already?)
Nov 07 18:00:50 <RP> armpit: I'm just a little worried an autobuilder fix made today may have broken some oe-selftests
Nov 07 18:01:33 <armpit> RP, we have not set DISTRO_VERSION
Nov 07 18:02:00 <RP> armpit: right, means I need to find time to concentrate for a few minutes then :)
Nov 07 18:06:53 <armpit> RP, just bumped the distro version
Nov 07 18:07:39 <armpit> I don't believe I can set the build-appliance-image as the hashes wont match
Nov 07 18:08:15 <yates> are there any yocto-supported file systems besides aufs and unionfs that supported "merged" filesystems for read-only and read/write access?
Nov 07 18:08:21 <yates> see https://www.logicsupply.com/explore/io-hub/how-to-build-a-read-only-linux-system/
Nov 07 18:08:44 <yates> it looks like unionfs is not supported for 4.1.15
Nov 07 18:09:33 <yates> correction: aufs is not supported for 4.1.15
Nov 07 18:12:16 <JPEW> yates: overlayfs?
Nov 07 18:13:19 <kergoth> overlayfs seems to be the most common one for folks that want an overlay filesystem, anyway
Nov 07 18:13:28 <kergoth> others use bind mounts, symlinks, or both for writable areas
Nov 07 18:19:28 <yates> ok, thank you
Nov 07 18:30:10 <RP> armpit: thanks, I have scripts for the ba rev
Nov 07 18:30:16 <RP> I wish we could avoid them :/
Nov 07 18:35:59 <rondo-de> i'm looking for same actuel good tutorials to build em. linux for rpi64 with WIFI support , have somebody an Idea ?
Nov 07 18:39:42 <armpit> rondo-de, have you looked at http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/README.md
Nov 07 18:43:03 <rondo-de> armpit, ok thank you
Nov 07 19:16:24 <yocti> New news from stackoverflow: Yocto - Exporting STAGING_KERNEL_BUILDDIR as part of extensible SDK <https://stackoverflow.com/questions/53196165/yocto-exporting-staging-kernel-builddir-as-part-of-extensible-sdk>
Nov 07 19:24:36 <yates> with the techniques like static wear leveling which are implemented by controllers on flash memories these days, does using a read-only filesystem really help with flash lifetime?
Nov 07 19:25:33 <yates> or rather, something like an overlay filesystem where there is a writeable area and a read-only area?
Nov 07 19:26:24 <yates> at the end of the day, the underlying device doesn't care about filesystems, it just manages the blocks, right?
Nov 07 19:27:24 <yates> https://en.wikipedia.org/wiki/Wear_leveling#Comparison
Nov 07 19:42:15 <yates> or said another way, overlayfs won't help flash lifetime UNLESS the writeable filesystem is on another device (e.g., tmpfs). correct?
Nov 07 19:52:30 <kergoth> yes
Nov 07 19:52:53 <kergoth> but read-only rootfs buys other functionality as well, particularly for recovery and avoiding filesystem damage, etc
Nov 07 19:53:14 <kergoth> also extremely useful if you're going to set up a dual-partition swupdate mechanism or similar
Nov 07 19:53:42 <kergoth> i.e. it downloads an updated image, flashes it to whichever rootfs isn't currently booted, then reboots onto the new one, leaving the old as a fallback in case it fails
Nov 07 20:02:57 <yates> i don't see how a read-only fs helps with that, per se
Nov 07 20:03:03 <yates> but ...
Nov 07 20:04:03 <yates> i can see where having an extra partition acting as the writable portion of an overlayfs would be most convenient, so that you could upgrade without wiping away your nv data
Nov 07 20:11:20 <litb> hello folks
Nov 07 20:11:41 <litb> i successfully built the poky-linux for my zedboard zynq board and booted from it.
Nov 07 20:12:07 <litb> now i want to add n FPGA part to the design. I want to use u-boot-SPL (not Xilinx FSBL)
Nov 07 20:13:17 <bluelightning> any known issues for the 2.6 release notes?
Nov 07 20:13:18 <litb> what's the recommended way to do this? I am about to create a new layer "meta-myfpga", and put TCL scripts and recipes there which build the HDF file, and specify for the recipes that they provide this file for the meta-xilinx layer (I think it has a u-boot-xlnx recipe that can take this HDF file)
Nov 07 20:13:26 <bluelightning> ^^ rburton RP
Nov 07 20:13:30 <litb> is this the recommended approach? or am I doing it all-wrong?
Nov 07 20:13:59 <bluelightning> litb: that seems reasonable
Nov 07 20:20:12 <Crofton> litb, so there are ps7_init.c,h fils from vivaado
Nov 07 20:20:39 <Crofton> I forget exactly how they are added to u-boot at th em moment
Nov 07 20:20:41 <litb> i think that there is that file, and then there's the bitfile
Nov 07 20:20:50 <Crofton> which et of layers are ytu using?
Nov 07 20:20:53 <litb> but then there's also a "hdf" file which somehow contains both
Nov 07 20:21:12 <Crofton> look at the u-boot recipe and see if that source has ps7 files
Nov 07 20:21:30 <litb> meta-xilinx, meta and meta-xilinx/meta-xilinx-bsp
Nov 07 20:22:34 <Crofton> sumo?
Nov 07 20:22:47 <litb> Crofton, it has none
Nov 07 20:22:58 <Crofton> what branch?
Nov 07 20:23:27 <litb> git status says "Your branch is up to date with 'origin/sumo'."
Nov 07 20:23:32 <Crofton> ok
Nov 07 20:23:58 <litb> Crofton, i did a find, and there's a ps7_init_gpl.c/h in ./recipes-bsp/platform-init/platform-init/picozed-zynq7/ps7_init_gpl.h
Nov 07 20:24:13 <Crofton> hmm
Nov 07 20:24:59 <litb> however I'm using the zedboard. but maybe they just use that init file for all boards. on the other hand, the vanilla core-image-minimal with meta-xilinx doesn't include an fpga bitstream, so maybe they have a prebaked boot.bin file with the FSBL somewhere?
Nov 07 20:26:31 <Crofton> ps7 files setup mio and ddr ontroller, tends to be baord spcific :)
Nov 07 20:29:15 <litb> hm i see
Nov 07 20:30:30 <litb> Crofton, ah i found one in the build directory
Nov 07 20:30:38 <litb> ./tmp/work/x86_64-linux/u-boot-mkimage-native/1_2018.01-r0/git/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
Nov 07 20:31:35 <litb> this seems to indicate that the image it created for me actually already uses u-boot spl. otherwise it would create the image with bootgen instead of mkimage
Nov 07 20:34:11 <litb> Crofton, my target for this experiment is to have a framebuffer device working in the FPGA that sends encoded output to the HDMI of the zedboard and has KMS drivers for the linux host to communicate to it
Nov 07 20:34:11 <Crofton> so likely in mainline u-boot
Nov 07 20:34:20 <litb> hm i see
Nov 07 20:34:37 <Crofton> did you make any changes to mio (not likely) maybe fpga clocks?
Nov 07 20:34:49 <Crofton> the defaulty ps7 files may just work
Nov 07 20:37:58 <litb> Crofton, ah i think i found it here: build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/u-boot-xlnx/v2018.01-xilinx-v2018.1+gitAUTOINC+949e5cb9a7-r0/git/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
Nov 07 20:38:11 <litb> so it's in the GIT repository
Nov 07 20:38:33 <litb> Crofton, i didn't do any FPGA design works yet
Nov 07 20:51:39 <RP> bluelightning: we need to highlight the number of CVEs coming onto the release branch post release
Nov 07 20:52:14 <bluelightning> RP: ok, I guess I should get Tracy to collect a list?
Nov 07 20:52:30 <bluelightning> tgraydon: ^
Nov 07 20:53:51 <tgraydon> RP, bluelightning, do we just need a count or do we need to capture what they are as well?
Nov 07 20:54:47 <tgraydon> RP. bluelightning: I am assuming we want to include this info in the release notes in some fashion, yeah?
Nov 07 20:55:43 <bluelightning> tgraydon: we should put it in the known issues, and IMHO I think we should list all the ones we at least have patches for (assuming we aren't also aware of others)
Nov 07 20:56:55 <tgraydon> bluelightning: gotcha.
Nov 07 20:57:07 <bluelightning> tgraydon: thanks!
Nov 07 20:59:58 <tgraydon> bluelightning: I've got to run off to an appointment shortly. Be gone for a bit, but will work on this once I get back. Just FYI.
Nov 07 21:00:22 <bluelightning> ok no worries
Nov 07 21:01:01 <RP> bluelightning, tgraydon: you can get an idea of the list from master-next
Nov 07 21:02:16 <tgraydon> RP: should I be using master-next to generate this list or use the thud branch. I would guess I want everything from the RC revision we built to HEAD on thud?
Nov 07 21:02:30 <tgraydon> RP: or is master-next going to be closer to the truth?
Nov 07 21:02:45 <bluelightning> tgraydon: I already have the list of CVEs that is fixed, RP means the list of issues not yet fixed in thud
Nov 07 21:03:11 <bluelightning> s/is/are/
Nov 07 21:03:43 <tgraydon> bluelightning: ah, gotcha. These fixes are not on thud yet. Was thinking we were saying they had been pushed to thud at this point.
Nov 07 21:04:16 <RP> tgraydon: not yet, but master-next CVEs will be going into thud imminently
Nov 07 21:04:35 <bluelightning> RP: for the next point release though right ?
Nov 07 21:04:57 <tgraydon> bluelightning, RP: got it. Will work on this this afternoon, based off master-next.
Nov 07 21:04:59 <RP> bluelightning: yes. THe release notes should say they're being queued on the branch though ready
Nov 07 21:05:12 <RP> bluelightning, tgraydon: btw, halstead and I discovered our sstate release artefacts have been bust for a number of releases :(
Nov 07 21:06:10 <tgraydon> RP: yuck. Have we root caused that yet and fixed it?
Nov 07 21:09:21 <RP> tgraydon: autobuilder issues and the new autobuilder code will do better
Nov 07 21:10:01 <tgraydon> RP: cool.
Nov 07 21:26:14 <armpit> truth... what is truth
Nov 07 21:27:06 <RP> bluelightning: any idea why https://autobuilder.yoctoproject.org/typhoon/#/builders/28/builds/189 would happen?
Nov 07 21:27:26 <RP> bluelightning: $ oe-selftest -r recipetool.RecipetoolAppendsrcTests.test_recipetool_appendsrcfile_basic in the same build directory passed
Nov 07 21:28:52 <bluelightning> RP: er... looks like there's a lot going wrong with that build :(
Nov 07 21:29:04 <armpit> RP so is master-next the thud-next or should it be pruned ?
Nov 07 21:29:05 <RP> bluelightning: its stable sumo :/
Nov 07 21:29:14 <armpit> sumo... /me sighh
Nov 07 21:29:20 <RP> armpit: the first part of it is
Nov 07 21:29:58 <RP> armpit: sorting thud-next is next on my list after rocko which is after figuring out whether we broke the autobuilder. I think we didn't and this is some sumo bug :/
Nov 07 21:30:11 * armpit sumo passed for me.. WT heck
Nov 07 21:30:23 <RP> armpit: hence my worry we broke something
Nov 07 21:30:31 <RP> armpit: but I think it is sumo
Nov 07 21:31:01 <armpit> well, I can pull things in for thud-next in the normal process to filter out other master-next
Nov 07 21:31:16 <armpit> thud-nmut process
Nov 07 21:32:08 <RP> armpit: thud-next is up to http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=2535ec060d85d76685237e42375d0a1fd34a8bc0
Nov 07 21:32:18 <RP> armpit: or was what I was thinking anything
Nov 07 21:32:22 <RP> er, thinking anyway
Nov 07 21:32:34 <RP> armpit: some things at the end of -next are untested
Nov 07 21:32:55 <armpit> k
Nov 07 21:33:22 <armpit> should I look into sumo ?
Nov 07 21:33:32 <armpit> while you look into thud?
Nov 07 21:33:44 <armpit> rocko is the next in for QA
Nov 07 21:33:50 <RP> armpit: We probably need to rerun that sumo build. I suspect some early test fail took out the others
Nov 07 21:34:30 <armpit> I will fire off a sumo build and look at that
Nov 07 21:35:14 <armpit> sumo has some time to settle. thud next ie cve's higher prio
Nov 07 21:36:43 * armpit contrib/sumo-next 
Nov 07 21:36:59 <RP> armpit: can you glance at the rocko branches and see if they look right?
Nov 07 21:37:04 <RP> armpit: if so, I'll run the build
Nov 07 21:38:03 <armpit> rocko looks good
Nov 07 21:38:34 <armpit> even though I had to ++++ firefox to read it ; )
Nov 07 21:40:08 * RP fires
Nov 07 21:40:30 * RP feels he should be firing pyro
Nov 07 21:40:49 <armpit> so sanity reasons ?
Nov 07 21:40:59 <RP> armpit: sanity reasons?
Nov 07 21:41:22 <armpit> you said pyro.. its in community supported
Nov 07 21:41:41 <RP> armpit: just word association, pyro and fire
Nov 07 21:41:51 <armpit> hehe
Nov 07 21:42:21 <armpit> I will re-run stable/sumo-next for a base line on the sumo status
Nov 07 21:42:29 <armpit> later todaey
Nov 07 21:42:58 <RP> armpit: just fyi michael and I are in the same physical location this week so we've been working on AB stuff for that reason
Nov 07 21:43:15 <armpit> I have a pyro US TSA story to tell you later
Nov 07 21:43:39 * armpit wife was not happy
Nov 07 21:43:51 <RP> random facts - sources for OE-Core come in at 3.7GB and sstate for the 2.5.1 release build is 265GB
Nov 07 21:44:25 <RP> armpit: pyro and TSA likely isn't a good combination and we're both likely on watch lists now ;-)
Nov 07 21:45:00 <armpit> C4 and TNT
Nov 07 21:45:22 <armpit> alarms... not a goog thing
Nov 07 21:45:43 <RP> armpit: I think you're trying not to travel? :)
Nov 07 21:49:15 <Crofton> RP, undisclosed location?
Nov 07 21:50:06 <RP> Crofton: I did not disclose it but it isn't exactly a secret
Nov 07 21:50:37 <Crofton> old joke :)
Nov 07 21:50:48 <Crofton> Dick Cheney and his undisclosed location
Nov 07 21:51:34 <RP> Crofton: I clearly missed that one...
Nov 07 21:52:26 <Crofton> https://www.yahoo.com/news/blogs/upshot/cheney-reveals-his-undisclosed-location.html
Nov 07 21:54:07 <armpit> Crofton, I am Dick Cheney
Nov 07 21:55:17 <armpit> Crofton, you thought the stores at the "Hanging Bat" where crazy.. there are more
Nov 07 22:01:18 <RP> armpit: at least this rocko build has a nice hot sstate cache :)
Nov 07 22:01:43 <RP> and it appears to have an sstate release directory which has the right files in it
Nov 07 22:04:25 <armpit> hot sstate.. I was looking for fiery sstate. the better of the best sstate ; )
Nov 07 22:05:29 <armpit> lava sstate???
Nov 07 22:05:52 <armpit> I think we can graph that
Nov 07 22:06:29 <armpit> RP is halstead wear shorts yet?
Nov 07 22:08:03 <derek_> HI, Something went wrong with source extraction - the devtool-source class was not active or did not function correctly, I always got this error, when I use command  "devtool modify syslinux-native"
Nov 07 22:08:29 <derek_> anyone met this error before?
Nov 07 22:25:24 <RP> armpit: he commented it feels much colder than Edi here
Nov 07 22:29:01 <armpit> RP, as you have told me.. just wondering if he is growing a thinker skin
Nov 07 22:29:32 <RP> armpit: he's only been here a few days
Nov 07 23:30:39 <RP> armpit: sumo build can go, or -next will be ready shortly
**** BEGIN LOGGING AT Wed Nov 07 23:30:56 2018
Nov 07 23:33:57 <RP> armpit: looks like the release artefact collection for rocko is bust :/
Nov 07 23:34:10 <RP> (for beaglebone-yocto)
Nov 07 23:34:12 * armpit sigh
Nov 07 23:35:32 <RP> armpit: we can rerun those I guess
Nov 07 23:36:58 * armpit scratches head over reproducibility... should be the same... 
Nov 07 23:41:42 * armpit wonders how to make thing better for release time???
Nov 07 23:42:15 * armpit pub time
Nov 08 00:20:00 <khem> armpit: play some pubg
Nov 08 00:26:50 <la_croix_> Hi, I'm new to this, and I have a few questions about the best way to load modules in a yocto build
Nov 08 00:27:41 <la_croix_> Would anybody have a minute to give me some advice?
Nov 08 00:34:22 <la_croix_> Anybody around?
Nov 08 01:28:03 <khem> la_croix_: sure, is it a in-kernel module or external
Nov 08 01:59:26 <la_croix_> It's i2s support. Essentially I want to follow these instructions: https://learn.adafruit.com/adafruit-i2s-mems-microphone-breakout/raspberry-pi-wiring-and-test
Nov 08 02:01:04 <la_croix_> khem sorry I only just saw this
Nov 08 02:03:54 <khem> is it for rpi ?
Nov 08 02:04:03 <la_croix_> Yes
Nov 08 02:05:09 <khem> la_croix_: set ENABLE_I2C = "1" in local.conf
Nov 08 02:06:31 <la_croix_> This is i2s, not i2c... Does that matter?
Nov 08 02:07:57 <khem> ah it would
Nov 08 02:10:46 <la_croix_> Yes, it seems as though i2s is not included in standard raspbian distro (which I believe yocto replicates for this board), hence the patch
Nov 08 02:13:41 <khem> la_croix_: I think the module is already part of rootfs
Nov 08 02:14:51 <la_croix_> In that case wouldn't lsmod reveal it? Currently it doesn't list it
Nov 08 02:17:01 <khem> can you create a file /etc/modules-load.d/snd.conf with content
Nov 08 02:17:10 <khem> snd-soc-bcm2835-i2s
Nov 08 02:17:19 <khem> and reboot the box ?
Nov 08 02:17:28 <khem> then do lsmod | grep i2s
Nov 08 02:18:37 <la_croix_> rebooting
Nov 08 02:19:39 <la_croix_> That comes back empty
Nov 08 02:20:01 <la_croix_> In fact, lsmod only contanis nfsd and ipv6
Nov 08 02:20:49 <khem> can you try find /lib/modules/ -name "*i2s*"
Nov 08 02:21:11 <la_croix_> empty again
Nov 08 02:21:24 <khem> ok so it seems your build has not included modules at all
Nov 08 02:21:31 <khem> how did you build this image ?
Nov 08 02:22:37 <la_croix_> Following the instructions on the mender site: https://docs.mender.io/1.6/artifacts/building-mender-yocto-image
Nov 08 02:23:30 <la_croix_> It is build on core-img-full-cmdline, with a couple of layers for rpi and mender, as well as one for activating dhcp
Nov 08 02:23:36 <khem> did you build core-image-full-cmdline?
Nov 08 02:23:41 <khem> ok
Nov 08 02:25:29 <khem> can you add IMAGE_INSTALL_append = " kernel-modules " in local.conf and rebuild the image ?
Nov 08 02:25:45 <khem> once you do that then it will include all modules in image
Nov 08 02:26:04 <la_croix_> yep, one minute
Nov 08 02:26:10 <khem> then you can follow the instructions I gave above to autoload the module
Nov 08 02:30:54 <la_croix_> Ok, so if I then want to push these out to a load or rpis as mender artifacts, should I be activating i2s in a layer, or do I need to edit the rootfs following the instructions that you have above?
Nov 08 02:33:07 <OutBackDingo> anyoone done initramffs with a pi 3 ?
Nov 08 02:36:47 <khem> la_croix_: you can enable it in meta-data
Nov 08 02:38:08 <khem> la_croix_: in local.conf add KERNEL_MODULE_AUTOLOAD_append = " snd-soc-bcm2835-i2s "
Nov 08 02:38:24 <khem> that will ensure that its automatically inserted on boot
Nov 08 02:38:38 <khem> OutBackDingo: yes
Nov 08 02:39:08 <OutBackDingo> khem: ok im seriously struggling with initramfs on a pi ... so whhats the hhint
Nov 08 02:39:59 <OutBackDingo> ive read a bunch or raspbian docs oin it... but doesnt seem to be much in the way of yoccto docs
Nov 08 02:40:05 <la_croix_> Great, thanks
Nov 08 02:40:33 <OutBackDingo> khem: basically i have uboot enabled on a core-image-weston boots fine
Nov 08 02:40:43 <khem> OutBackDingo: did you go through https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#image-with-initramfs
Nov 08 02:40:48 <OutBackDingo> now id like to get initramffs uup for ccryptffs
Nov 08 02:41:09 <OutBackDingo> yes and thhats not whats clear
Nov 08 02:41:39 <khem> whats not clear
Nov 08 02:42:17 <OutBackDingo> whats needed for config.txt and cmdline.txt ?
Nov 08 02:42:26 <OutBackDingo> khem: as in i get an initrd
Nov 08 02:42:31 <OutBackDingo> well initramfs
Nov 08 02:42:51 <khem> nothing
Nov 08 02:43:05 <khem> did you follow the intructions as listed ?
Nov 08 02:44:05 <khem> it wont build a final SD card image with just kernel+initramfs
Nov 08 02:44:23 <khem> but it will build SD-card image with kernel+inittramfs+rootfs
Nov 08 02:44:44 <khem> you can use that to flash the SD card
Nov 08 02:45:02 <khem> when you boot it will ignore rootfs on SD card
Nov 08 02:47:10 <OutBackDingo> khem: this ERROR: ParseError at /home/dingo/WESTON/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc:23: unparsed line: 'kernel_configure_variable BLK_DEV_INITRD y'
Nov 08 02:48:21 <khem> add it to do_configure_prepend() function
Nov 08 02:50:25 <OutBackDingo> fsck me..... unclear in the doc
Nov 08 02:50:38 * OutBackDingo thhinks his brain is fried
Nov 08 02:53:18 <OutBackDingo> khem: still failing
Nov 08 02:53:48 <khem> OutBackDingo: yeah the doc needs some update I have sent a patch
Nov 08 02:53:51 <OutBackDingo> https://pastebin.com/qNnUAP9M
Nov 08 02:55:16 <khem> yeah the second change about adding INITRAMFS variable should be done in local.conf and not in linux-raspberrypi.inc
Nov 08 02:56:02 <OutBackDingo> #$@%^$#^@$%#$%
Nov 08 02:56:08 * OutBackDingo thinks OMG
Nov 08 02:57:04 <OutBackDingo> i should have knoown this
Nov 08 02:57:21 <OutBackDingo> quite diffferent then innitramfs on moosst other devices
Nov 08 02:57:47 <khem> https://github.com/agherzan/meta-raspberrypi/commit/7c649bf0dab6c9334401422a98dc148073abbc3c
Nov 08 02:59:19 <OutBackDingo> khem: so... do i need to generate thhe image first ?
Nov 08 02:59:55 <khem> OutBackDingo: once you set the vars correctly just do bitbake core-image-base
Nov 08 02:59:57 <OutBackDingo> `INITRAMFS_IMAGE = "<name for your initramfs image>"` < is looking for a path to an already generated image ?
**** ENDING LOGGING AT Thu Nov 08 02:59:59 2018