linux/meta-fsl-arm.git/classes, branch jethro

mfgtool-initramfs-image.bbclass: Fix parsing when using a barebox based machine

2016-04-23T15:02:10+00:00

When building for cfa100xx machines, for meta-fsl-arm-extra, the parsing is aborted with: ,---- | ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry | 'barebox.mxsboot-sdcard' - possibly invalid type name or missing | support class | ERROR: Failed to parse recipe: | .../sources/meta-fsl-arm/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb `---- This error was caused by the image not providing all the filesystem types as in fact it generates a Gzipped CPIO filesystem and does not inherit the default ones. To solve the error we ought to include the override for 'mxs' SoC family so the right setting is used as well in this set of SoCs. Change-Id: If6e657793ed7af07decac217f6b3371fad1f521c Signed-off-by: Otavio Salvador

EULA: Update to LA_OPT_BASE_LICENSE v10 November 2015

2016-02-11T20:09:48+00:00

Signed-off-by: Lauren Post Signed-off-by: Otavio Salvador

fsl-vivante-kernel-driver-handler.bbclass: Postpone defconfig changes

2016-02-11T20:08:56+00:00

The defconfig changes should be done later in the process so the .config file is generated, using any other mean, and mangled to respect the distribution setting regarding the module use or not. Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Fix image generation for i.MX 6UltraLite

2015-10-22T12:40:09+00:00

When the i.MX 6UltraLite (mx6ul) was separated from the SoC family mx6 (commit 24396b28f0137464cd82b9a19f705c1db180ead2) it started to create invalid sdcard images. This is because of SDCARD_GENERATION_COMMAND no more being triggered. The solution in this moment is add a mx6ul override for the SDCARD_GENERATION_COMMAND definition. Signed-off-by: Felipe Provenzano Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Use FAT 32 for images larger than 512MB

2015-10-16T18:15:16+00:00

Refers to the following commit of poky for more detail. commit 722430a488f39bf583e4a557a254fb84fae4d0a7 Author: Darren Hart Date: Wed Dec 12 14:39:15 2012 -0800 bootimg: Use FAT 32 for images larger than 512MB Fixes [YOCTO #2138] Signed-off-by: Tzu-Jung Lee Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Fail if a Device Tree file is missing

2015-10-16T16:59:23+00:00

When generating the rootfs we need to include all the referenced Device Tree files. The code were gracefully checking if the file existed before building the image however the expected behavior is to fail. As consequence of this change, if someone is using a very old kernel (no Device Tree based) and tries to generate an image, it will fail until the machine definition is changed to not list Device Tree files for installation. Currently all machines supported by meta-fsl-arm BSP are consistent for the default kernel in use however custom BSP may need to be changed accordingly. Change-Id: I548c65c61dfefe24154a455d097032b1598b14d3 Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Refactor boot image duplicated code

2015-10-16T16:59:18+00:00

The code which copies the boot scripts and Device Tree files is duplicated across the different image types. This patch reworks this code to avoid this duplication. Change-Id: Ib9405067a5419e1b295dfac9e3d3bd9b896d424e Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: make mkfs.vfat use FAT32 in all cases

2015-10-02T22:33:15+00:00

as otherwise FAT16 might be used, which seems quite outdated and can cause issues in certain environments (e.g. older versions of U-Boot) Change-Id: I2d89ad235084c4a1289fae180df043a2f9e05e63 Signed-off-by: Frieder Schrempf Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Fix DeviceTree copy for FAT partition

2015-09-24T16:57:31+00:00

The rootfs generation script now runs outside of the deploy directory so the code need to use the full path for the installed files. This fixes the rootfs generation process so the files are copied to the FAT partition, allowing the system to boot. Signed-off-by: Otavio Salvador Tested-by: Daiane Angolini

fsl-vivante-kernel-driver-handler.bbclass: Handle Vivante kernel driver provider

2015-09-22T21:54:21+00:00

Enable the kernel to provide or not the Vivante kernel driver and dynamically set the proper providers per machine. The following options are supported: MACHINE_HAS_VIVANTE_KERNEL_DRIVER_SUPPORT Machine does or does not have support for the Vivante kernel driver, options are: 0 - machine does not have Vivante GPU driver support 1 - machine has Vivante GPU driver support MACHINE_USES_VIVANTE_KERNEL_DRIVER_MODULE Machine uses the Vivante kernel driver as module, options are: 0 - enable the builtin kernel driver module 1 - enable the external kernel module Signed-off-by: Otavio Salvador