Yes that's been possible for quite a long time now (possibly going back to OE- classic).
Cheers, Paul On Tue, 01 Dec 2015 17:48:26 Daniel. wrote: > Hmmm that seems to fit as a glove to me, is that possible on Daisy? > > Regards, > - dhs > > 2015-12-01 17:30 GMT-02:00 Paul Eggleton <[email protected]>: > > On Tue, 01 Dec 2015 11:27:19 Daniel. wrote: > >> Hi Saul, thanks for your reply > >> > >> 2015-11-30 21:29 GMT-02:00 Saul Wold <[email protected]>: > >> > On Mon, 2015-11-30 at 17:25 -0200, Daniel. wrote: > >> >> Hi, > >> >> > >> >> I have one kernel tree where I keep all my modules in-tree. Inside > >> >> kernel I have two FOO_defconfig and BAR_defconfig which are > >> >> configurations for FOO-board and BAR-board. On Yocto I have > >> >> core-layer, FOO-bsp layer and BAR-bsp layer. At core-layer I have > >> >> linux-custom.bb file which has the URI for kernel tree with a dummy > >> >> defconfig. At FOO-bsp and BAR-bsp a have a .bbappend that adds a > >> >> folder with the right defconfig for each board. > >> >> > >> >> My doubt is: I have two .bbappends, on two distinct layers being > >> >> applied at same time? Both layers are pointed at > >> >> build/conf/bblayers.conf. > >> > > >> > So you are including both your BSP Layers in the bblayers, that will > >> > probably cause problems based on your description above. > >> > > >> > Another option is to look at using overrides and have 1 layer that > >> > supports both boards if they are similar and share other items. > >> > > >> >> How can I have sure to pick up the right defconfig at build time? > >> >> > >> >> I've tried to delete core-layer and have two kernel recipes with > >> >> distinct names, but Yocto complains about two recipes being selected > >> >> at same time for build (because of virtual/kernel feature or > >> >> something > >> >> alike). So I want to keep one kernel recipe and select the right > >> >> defconfig based on MACHINE value. > >> > > >> > You can use PREFERRED_PROVIDER_virtual/kernel to have multiple > >> > alternate kernel present and set it in your <machine>.conf to select > >> > the kernel you want. > >> > > >> > If your kernel recipe does not inherit kernel.bbclass you will need to > >> > set PROVIDES > >> > > >> > You should also be sure to set COMPATIBLE_MACHINE for each machine > >> > > >> >> Both defconfig are present on arch/arm/configs. Can I overwrite > >> >> do_config()? Is that safe? About the .bbappends: Should be two > >> >> .bbappends on same .bb file be avoided? > >> > > >> > You can use a do_config_prepend() to deal with moving the correct > >> > defconfig. > >> > >> Yeah I'm doing that. As you suggested I removed the .bbappend files and > >> have one recipe that support both machines, the config prepend looks > >> like this: > >> > >> do_configure_prepend() { > >> > >> case "${MACHINE}" in > >> > >> enlace-imx6) > >> bbnote "Using csi_enlace_imx6_defconfig" > >> cp -v ${S}/arch/arm/configs/csi_enlace_imx6_defconfig > >> ${S}/defconfig > >> > >> ;; > >> > >> pharosserver-imx6) > >> > >> bbnote "Using csi_pharosserver_imx6_defconfig" > >> > >> cp -v ${S}/arch/arm/configs/csi_pharosserver_imx6_defconfig > >> > >> ${S}/defconfig > >> > >> ;; > >> > >> esac > >> > >> } > > > > We do already have functionality that avoids the need for custom scripting > > like this. > > > > Unless you really need the defconfigs in-tree, the typical way to achieve > > this is to add "file://defconfig" to SRC_URI, then have defconfig files > > for each of the machines under subdirectories named the same as the > > machine. So your directory structure would look like this: > > > > .../recipes-linux/linux-something/linux-something_versionnumber.bb > > .../recipes-linux/linux-something/linux-something/enlace-imx6/defconfig > > .../recipes-linux/linux-something/linux-something/pharosserver-imx6/defcon > > fig > > > > Cheers, > > Paul > > > > -- > > > > Paul Eggleton > > Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
