7518 2015-03-25 23:07:24 +0000 Build multiple machines in the same bitbake invocation 2016-08-24 15:36:53 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration unspecified All Multiple RESOLVED FIXED High enhancement 2.2 M3 1 tylerwhall richard.purdie frederico.cadete jose.perez.carranza tim.orling libertad.gonzalez.de.la.cruz --- --- Yes (doc changes required) oldest_to_newest 49763 0 tylerwhall 2015-03-25 23:07:24 +0000 On complex embedded boards that have multiple SoCs and microcontrollers, it is sometimes necessary to build different images for multiple machines as well as firmware for microcontrollers and package them all into one programmable update file. Currently this requires separate invocations of bitbake with different configuration and an external tool to combine the artifacts from each. Example: A single board containing an x86_64 SoC connected over PCI express to an AArch64 SoC along with an AVR microcontroller. One SoC may be a slave to the other and get its firmware from the primary SoC. The microcontroller is reprogrammed from fimrware stored on the SoC's file system when out of date. Perhaps this could be handled similarly to multilib, where the recipes for the "slave" machines are built using a mechanism like BBCLASSEXTEND. Ideally the recipes would not need to be modified to support this. 49788 1 richard.purdie 2015-03-26 09:25:24 +0000 I've wondered about this for a long time and you're right, the multilib BBCLASSEXTEND mechanism does give us some options. The big challenge is that we've intentionally kept knowledge of MACHINE out of bitbake. Unlike nativesdk/native, when you change MACHINE, the underlying base data store changes directly too. The BBCLASSEXTEND mechanism 'just' requires post processing of the datastore, differing machines requires a completely separate base data stores. The "namespace" of two different machines is identical too (both have 'bash'), unlike something like nativesdk. Yes we could alter all the namespaces for each different machine but it touches a lot more places than nativesdk does. How to pull all this together in a generic scalable way which doesn't overload bitbake and doesn't put "OE specific" knowledge like MACHINE into it is a tough question. You'd also start to get questions like "why can't I do this with multiple DISTROs too?". So yes I like the idea and would love to see it but the details of how are tricky. 63378 2 richard.purdie 2016-06-27 22:03:44 +0000 I have multi-config on a branch and it basically works. Targeting M2 for the merge. 65485 3 richard.purdie 2016-08-24 15:36:53 +0000 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=218b81acb682bf0006afeb1a5c7bc4adf0549796 Specific bugs can be opened for specific issues from here.