On 10/15/19 2:03 PM, Davis Roman wrote:
Hi Joshua,
Thank you for replying.
Since my last email, I enabled BBMULTICONFIG and was able to build
both 32bit and 64bit machine types successfully and so i have both
packages available in their corresponding build folders.
build/tmp-imx6sxsabresd/deploy/rpm/imx6sxsabresd/kernel-4.14.98-r0.imx6sxsabresd.rpm
build/tmp-imx8mmevk/deploy/rpm/imx8mmevk/kernel-4.14.98-r0.imx8mmevk.rpm
I checked out mcdepends however I don't believe this helps me to do
the last piece which is to pull the 64-bit kernel package into my
32-bit image.
According to the yocto docs, mcdepends ensures that imageA is built
only after imageB has finished building (or at least that's how I
understand it).
The documentation might be a little misleading; mcdepends allows a
*task* from one multiconfig to depend on a *task* from another. Using
the image creation task (do_rootfs) is just an example.
I think one way to do what you want is write a recipe that mcdepends on
the do_deploy task from the 64-bit kernel recipe, pulls the deployed
kernel image, repackage it, and then install that recipe's package into
the 32-bit rootfs. There might be other ways that someone knows about
that would be better/cleaner, but that's what I would do.
In parallel, I'm studying a patch that was upstreamed in 2017 for
adding support for multiple kernel packages
(http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143674.html)
This appears to be in line with what I'm looking to do however the
wrinkle is that I'm dealing with two kernels from two different
machine types whereas the patch dealt with two kernels of the same
machine type.
I'm still trying to understand the implications of this. My feeling is
that I need a hybrid approach of bbmulticonfig and the above patch for
adding multiple kernel packages.
Ya, you might be able to do that if your new recipes looks like a kernel
"flavor" described in that patch.... I'm not quite clear on what the
advantage of doing that in this case would be; not that there isn't one
to be had, I just can't see it with a cursory glance :).
Please let me know if you have any thoughts.
Thanks,
Davis
On Fri, Oct 4, 2019 at 10:59 PM Joshua Watt <jpewhac...@gmail.com
<mailto:jpewhac...@gmail.com>> wrote:
On Fri, Oct 4, 2019, 7:04 PM Davis Roman <davis.roma...@gmail.com
<mailto:davis.roma...@gmail.com>> wrote:
Hello,
We're working on a Linux distro for two systems where one is
based on
NXP i.mx6(32-bit,armv7) and the other i.mx8(64-bit,armv8).
I have two machine types defined in Yocto so individually I
can build
either one however our goal is to create a single distro that
can run on both processors.
So the idea is to use
BBMULTICONFIG(https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBMULTICONFIG)
to build two separate images,
1) a 32-bit distro for an i.mx6
2) a 64-bit distro for an i.mx8
and then finally, take the 32-bit distro and add the 64-bit
kernel+modules and u-boot.
---------------------------------------
|--------------------------------------|
|| 32-bit rootfs ||
|--------------------------------------|
|----------------- ----------------- |
|| 32-bit kernel | | 64-bit kernel ||
|----------------- ----------------- |
|----------------- ----------------- |
|| 32-bit u-boot | | 64-bit u-boot ||
|----------------- ----------------- |
---------------------------------------
i.mx6solo i.mx8m mini
We've already tried our existing 32-bit rootfs + 64-bit
kernel/u-boot on the i.mx8 and the system runs.
So in theory, it should just be a matter of getting yocto to
assemble all the pieces together.
I don't have much experience with BBMULTICONFIG so any ideas
or comments on how to proceed would be appreciated.
You are on the right track. Create two multiconfig files one for
each machine, then user mcdepends
(https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#dev-enabling-multiple-configuration-build-dependencies)
to pull the 64 bit kernel, etc. into the 32 bit image.
BBMULTICONFIG is used in local.conf to select which multiconfigs
you want to enable. In your case it would have to list both of the
ones that you define.
Thank you,
Davis
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
