Bug 7518

Summary:	Build multiple machines in the same bitbake invocation
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Tyler Hall <tylerwhall>
Component:	configuration	Assignee:	Richard Purdie <richard.purdie>
Status:	RESOLVED FIXED	QA Contact:	Libertad <libertad.gonzalez.de.la.cruz>
Severity:	enhancement
Priority:	High	CC:	frederico.cadete, jose.perez.carranza, tim.orling
Version:	unspecified
Target Milestone:	2.2 M3
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description Tyler Hall 2015-03-25 23:07:24 UTC

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.

Comment 1 Richard Purdie 2015-03-26 09:25:24 UTC

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.

Comment 2 Richard Purdie 2016-06-27 22:03:44 UTC

I have multi-config on a branch and it basically works. Targeting M2 for the merge.

Comment 3 Richard Purdie 2016-08-24 15:36:53 UTC

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=218b81acb682bf0006afeb1a5c7bc4adf0549796

Specific bugs can be opened for specific issues from here.