On 08-10-15 03:46, Khem Raj wrote:
On Oct 7, 2015, at 6:05 AM, Mike Looijmans <[email protected]> wrote:
Since our boards needs 'some' bitstream in the FPGA to become somewhat useful,
in the machine.conf I say:
MACHINE_FPGA_BITSTREAM ?= "fpga-image-miami-florida-gen-reference"
MACHINE_EXTRA_RRECOMMENDS = "${MACHINE_FPGA_BITSTREAM} ..."
This puts that into the packagegroup-base-machine RDEPENDS and hence it gets
installed on the board if you don't specify anything else.
However, I want to be able to pick alternative FPGA bitstream providers in the
image recipe. Without having to define a new machine for each and every project…
would IMAGE_FEATURES help ? IMAGE_FEATURE = blue and blue may be car for one
machine and truck for another.
There are virtually unlimited sets of bitstreams. In general, each project
will define its own if it has special tasks for the FPGA, or it'll just just
the default. They are not directly related to the machine - the FPGA is only a
part of it and doesn't run Linux or so.
I did look into that before posting this, but IMAGE_FEATURES must be set from
a fixed list. There is no such list, each layer could add extra FPGA bitstream
recipes.
The trouble here is that the "image" decides which it is going to be. And that
"image" is often not mine to write, so I can't get away with writing my own
image class or recipe.
Currently, I do this by forcing packagegroup-base-machine and
packagegroup-base-distro out of the IMAGE_INSTALL list (for some obscure
reason, building packagegroup-base-distro also results in building the
reference bitstream) and then add MACHINE_EXTRA_RRECOMMENDS directly to the
IMAGE_INSTALL list, so I can set MACHINE_FPGA_BITSTREAM to whichever I'd like
to have in this image.
I was lookign for a way to have the machine configuration inject its packages
into the IMAGE_INSTALL (or similar) list, so it can easily be overridden in an
image recipe.
Bluntly putting IMAGE_INSTALL+="${MACHINE_FPGA_BITSTREAM}" into the machine.conf might
work, but doesn't "feel" quite right. But there's apparently no other way to do this.
An alternative would be to introduce an IMAGE_INSTALL_MACHINE variable that
gets added to the PACKAGE_INSTALL variable in image.bbclass. That would allow
machines to inject their desirables into the image instead. It's a simple
patch, I've pasted it below:
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 86a98bb..90c1c05 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -64,7 +64,8 @@ def check_image_features(d):
IMAGE_INSTALL ?= ""
IMAGE_INSTALL[type] = "list"
-export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL}
${FEATURE_INSTALL}"
+IMAGE_INSTALL_MACHINE ?= ""
+export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL}
${FEATURE_INSTALL} ${IMAGE_IN
PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
# Images are generally built explicitly, do not need to be part of world.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
