linux/meta-fsl-arm.git/classes, branch dora-next

image_types_fsl.bbclass: Support i.MX25 platforms

2013-11-03T23:39:54+00:00

Signed-off-by: Gary Thomas

fsl-eula-unpack: add FSL_EULA_FILE to vardepsexclude

2013-10-28T12:13:20+00:00

FSL_EULA_FILE is defined with :=, which means it contains a full absolute path to the layer directory. If this is allowed to make it into the task checksum, it becomes impossible to use the shared states for these recipes without having meta-fsl-arm in the exact same path in the filesystem it was in when the sstate archives were created. Add FSL_EULA_FILE to do_unpack[vardepsexclude]. Signed-off-by: Christopher Larson

fsl-dynamic-packagearch.bbclass: Dynamically set package architecture

2013-09-25T18:28:34+00:00

This allow to easy reuse of binary packages among similar SoCs. The usual use for this is to share SoC specific packages among different boards. The class can be used to share GPU packages for i.MX53 boards (as all them share the AMD GPU) and i.MX6 based boards (as all them share Vivante GPU). It inspects the database and identify if the package provides or depends on one of subarch provided values and if it does, it sets the PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the machine specific filter, it sets it to MACHINE_ARCH. This reduces the amount of packages we build, for example in case of core-image-x11 we: $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l 75 So we reuse 75 binaries; these would be build otherwise. It being dynamically set or statically set it has following benefits: * correctness: it is easier to ensure the system behaves as expected * correctness for non-tracked recipes: new recipes, if depending on virtual/kernel or GPU has the right architecture choosen, without a .bbappend file for them * safeness: non-expert users get a more adequate behavior as the complexity of choosing the right architecture is simplified for them * easy maintenance: it is easier for me, as maintainer, to maintain a code which decides what to do than having hundreds of bbappend files for it Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8 Signed-off-by: Otavio Salvador

image_types_fsl: mxs: Add support for a barebox bootstream

2013-08-29T19:14:22+00:00

Change-Id: Ibe7afdd6e4c2f5db73b42cf6b39df9756bdb9fb8 Signed-off-by: Alexandre Belloni

image_types_fsl.bbclass: Add vf60 SoC family support

2013-07-29T17:00:13+00:00

The Vybrid SoCs use same image layout as other i.MX so use it. Change-Id: I0e1de1b917aed249196bef463ae1017c65254ef5 Signed-off-by: Otavio Salvador

image_types_fsl.bbclass: Add support for kernel image types

2013-04-24T13:11:03+00:00

Use the KERNEL_IMAGETYPE variable, making the class configurable for all supported kernel image types. This patch is tested with a 3rd-party board and a sabrelite board. Signed-off-by: S. Fricke

image_types_fsl.bbclass: fix partition type for SD card boot partition

2013-03-26T12:36:09+00:00

Create first partition on SD card as fat32. As boot.img is formatted as vfat, this will ensure information in partition table matches actual partition type. Signed-off-by: Vladan Jovanovic

image_types_fsl.bbclass: Fix deploy of mxsboot-sdcard image

2013-03-07T13:06:16+00:00

The mxsboot-sdcard image is the current way we use to generate the U-Boot bootstream blob during image generation however Yocto image system enforces some naming schema so the symbolic links does work and we weren't following those. This patch uses the '${IMAGE_NAME}' variable and the proper image suffix so the symbolic links now fully work. Fixes [YOCTO #3871]. Change-Id: I7f96dcdd58e0a726b8084c1f87ff10732fe259df Signed-off-by: Otavio Salvador

image_types_fsl: Fix .dtb file deploy

2012-12-21T18:48:24+00:00

.dtb file is copied to 'Boot' partition, the same partition uImage is placed. Now, more than one .dtb can be copied, if board conf file determinates more than one .dts file. Signed-off-by: Daiane Angolini

image_types_fsl.bbclass: Add support to install boot scripts

2012-12-12T17:29:38+00:00

Some machines might want to provide boot scripts for use. This now can be accomplished using BOOT_SCRIPTS variable in following format: : Thus any file in deploy directory can be installed in the boot partition of the sdcard, easily. Change-Id: Ic1eafd2be3559b5c9da43dcc6f54f1b480dbc647 Signed-off-by: Otavio Salvador