Re: [meta-fsl-arm-extra][PATCH 3/3] colibri-vf: initial machine for Toradex Vybrid modules

[Stefan Agner <stefan.agner@toradex.com>]

Hi Otavio,

On 09.03.2015 14:12, Otavio Salvador wrote:
> On Mon, Mar 9, 2015 at 5:46 AM, Stefan Agner <stefan.agner@toradex.com> 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 <stefan.agner@toradex.com>
>> ---
>>  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 <stefan.agner@toradex.com>
>> +
>> +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