**** BEGIN LOGGING AT Sat Jul 15 03:00:04 2017 Jul 15 07:12:54 hey ya'll. i'm a maintainer for dRonin... we make a drone autopilot firmware thingy. have a relatively new variant that can run on pi + a hat, plus may have another arm SBC variant soon Jul 15 07:13:51 right now we run on raspbian + our own PREEMPT_RT kernel in a deb + our own cross-compiled blob, plus a couple other things (can't use the openocd in raspbian's package repo) Jul 15 07:14:46 curious as to what the relative merits are of cross-compiling everything through something like OE. obviously the exposure to raspbian changing something underneath and breaking everything is reduced, and it seems like we might have a nicer blob for users Jul 15 07:14:56 but how much suck do we pick up in exchange etc? ;) Jul 15 07:19:36 also curious if there's any pain relating to pi-specific loader/devicetree hacks that are in raspbian Jul 15 07:19:41 any input people can offer would be greatly appreciated Jul 15 09:38:38 icee: You will gain a lot more control in the sense that you can tweak every component to your liking. At the same time you gain more complexity as you build everything from scratch and you can't just rely on the binary sources from Debian or Raspian. I haven't used OE with RasPi so I can't comment on that. Jul 15 16:40:38 icee: there's a meta-raspberrypi BSP layer that is well maintained, so that handles all the rpi-specific crazy for you Jul 15 16:41:07 icee: the advantage of OE in your situation is that you only have to write your images/recipes/config once, and then just changing MACHINE will rebuild it for a different platform with minimal effort for the port Jul 15 17:29:39 rburton: so i don't understand OE well yet. how careful do i need to be with the actual environment I'm building OE in Jul 15 17:29:53 i'm thinking about reproducibility -- does OE encaps its own cross environment, or does it use the underlying distro? Jul 15 17:30:03 i'm concerned there could be lots of dependencies that I might not capture or capture poorly Jul 15 17:30:28 i think i really want to go this way, just want to convince myself i'm not missing something dumb :P Jul 15 18:03:35 holy crap bitbake is slick :D Jul 15 18:04:01 and i see, kinda inbetween-- looks like it builds all the cross tools with my lcoal build environment-- so the local deps should be .. somewhat minmal Jul 15 19:10:43 OK, i built something Jul 15 19:10:45 where's the image? :P Jul 15 19:10:56 how's the preferred way to start it? :P Jul 15 19:13:35 tmp-glibc/deploy/images/qemuarm/ Jul 15 19:19:48 ah, found runqemu Jul 15 19:20:43 icee: latest release even isolates you from the host almost entirely by removing /usr from $PATH and linking in the bits you need. Jul 15 19:22:04 local deps are just enough to bootstrap Jul 15 19:23:34 woot, i made it work Jul 15 19:23:35 :D Jul 15 19:25:29 rburton: yah, that bootstrapping thing + parallel package fetching and building was one of the slicker things i've seen in awhile :D Jul 15 20:23:51 so to get the packages in meta-oe, i need to clone it separately and then add a reference to it? Jul 15 20:25:39 i want openocd, but it complains it can't find it in core, but it seems to be in meta-oe Jul 15 20:40:01 rburton: OK, i'm a bit confused by what meta-oe is. it seems to be an overlapping set of things of what's in oe-core Jul 15 20:53:44 there's very very little overlap, only what's absolutely necessary. meta-oe is basically the home of recipes for which there isn't a better layer Jul 15 20:55:50 OK, thx Jul 15 20:56:02 i've got things close to working, though i've not looked at board support yet Jul 15 20:56:08 i think i just have one last dumb question i'm stuck on Jul 15 20:56:14 how do i increase the default free space in the image? Jul 15 22:19:10 icee: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE Jul 15 22:19:39 icee: oe-core is the core metadata, other layers such as meta-oe add more recipes. start with core and add others as required. Jul 15 22:35:15 nice :) Jul 16 00:20:18 oe-core is real? I thought it was like the GNU Hurd of OS. Jul 16 00:20:25 * paulg runs Jul 16 01:10:56 hm, some kind of bug. had built a rpi image, then built an rpi2 one.. but the rpi2 one ended up with kernel.img not kernel7.img (different bits and wrong name) Jul 16 01:11:11 after nuking the build dir and sstate-cache it's done the right thing **** ENDING LOGGING AT Sun Jul 16 03:00:00 2017