Hi Otavio, On 09.03.2015 14:12, Otavio Salvador wrote: > On Mon, Mar 9, 2015 at 5:46 AM, Stefan Agner <[email protected]> wrote: >> The two modules Colibri VF50 and Colibri VF61 are very similar, >> with this generic machine called "colibri-vf" both modules are >> supported. The bootloader default environment expects the Linux >> kernel zImage as well as the device tree files to be located in >> the /boot folder of the root file system. Use IMAGE_INSTALL on >> the machine level to install them into the root file system by >> default. >> >> Signed-off-by: Stefan Agner <[email protected]> >> --- >> conf/machine/colibri-vf.conf | 36 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 36 insertions(+) >> create mode 100644 conf/machine/colibri-vf.conf >> >> diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf >> new file mode 100644 >> index 0000000..f84abbc >> --- /dev/null >> +++ b/conf/machine/colibri-vf.conf >> @@ -0,0 +1,36 @@ >> +#@TYPE: Machine >> +#@NAME: Toradex Colibri VF50/VF61 >> +#@SOC: VF500/VF610 >> +#@DESCRIPTION: Machine configuration for Toradex Colibri VF50/VF61 powered >> by Freescale Vybrid SoC >> +#@MAINTAINER: Stefan Agner <[email protected]> >> + >> +include conf/machine/include/imx-base.inc >> +include conf/machine/include/tune-cortexa5.inc >> + >> +SOC_FAMILY = "vf:vf50:vf60" > I agree with this however this imposes a change in imx-base.inc. > Please change the UBOOT_ENTRYPOINT for vf so it avoids the duplicated > definition. This also needs to add the vf in the SOC_FAMILY of Tower.
Yep, makes sense, will include that change in v2. >> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-toradex" >> +KERNEL_IMAGETYPE = "zImage" >> +KERNEL_DEVICETREE += "vf500-colibri-eval-v3.dtb vf610-colibri-eval-v3.dtb" >> + >> +# U-Boot expects the kernel and device tree directly in /boot of the rootfs >> +IMAGE_INSTALL_append = " kernel-image kernel-devicetree" > Please use: > > === MACHINE_EXTRA_RDEPENDS > A list of machine-specific packages to install as part of the image > being built that are not essential for the machine to boot. However, > the build process for more fully-featured images depends on the > packages being present. "not essential for the machine to boot", well, those are essential... At least for NAND/SD boot. Theoretically its optional since the kernel/device tree can also be fetched over the network, but that's not the common use case. > > This variable affects all images based on `packagegroup-base`, which > does not include the `core-image-minimal` or `core-image-full-cmdline` > images. > > The variable is similar to the `MACHINE_EXTRA_RRECOMMENDS` variable > with the exception that the image being built has a build dependency > on the variable's list of packages. In other words, the image will not > build if a file in this list is not found. Currently I test with core-image-minimal. I guess this won't boot if I use MACHINE_EXTRA_DEPENDS... > > An example is a machine that has WiFi capability but is not essential > for the machine to boot the image. However, if you are building a more > fully-featured image, you want to enable the WiFi. The package > containing the firmware for the WiFi hardware is always expected to > exist, so it is acceptable for the build process to depend upon > finding the package. In this case, assuming the package for the > firmware was called `wifidriver-firmware`, you would use the following > in the `.conf` file for the machine: > > MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware" > -- Stefan -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
