[meta-fsl-arm][PATCH 1/2] image_types_fsl: Use explit task dependency to boost build

[meta-fsl-arm][PATCH 1/2] image_types_fsl: Use explit task dependency to boost build

[Otavio Salvador]

Instead of depending of all tasks of recipes, we should depend on the
required task so we can start building the rootfs earlier in the build
process and earn some build time gain.

Change-Id: I770afe79edba0320ae697f9bcdaf340fbcb09eeb
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 classes/image_types_fsl.bbclass | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/classes/image_types_fsl.bbclass b/classes/image_types_fsl.bbclass
index 47e8338..39ceb7a 100644
--- a/classes/image_types_fsl.bbclass
+++ b/classes/image_types_fsl.bbclass
@@ -12,7 +12,9 @@ UBOOT_SUFFIX_SDCARD ?= "${UBOOT_SUFFIX}"
 #
 
 # IMX Bootlets Linux bootstream
-IMAGE_DEPENDS_linux.sb = "elftosb-native imx-bootlets virtual/kernel"
+IMAGE_DEPENDS_linux.sb = "elftosb-native:do_populate_sysroot \
+                          imx-bootlets:do_deploy \
+                          virtual/kernel:do_deploy"
 IMAGE_LINK_NAME_linux.sb = ""
 IMAGE_CMD_linux.sb () {
 	kernel_bin="`readlink ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${MACHINE}.bin`"
@@ -37,7 +39,10 @@ IMAGE_CMD_linux.sb () {
 }
 
 # IMX Bootlets barebox bootstream
-IMAGE_DEPENDS_barebox.mxsboot-sdcard = "elftosb-native u-boot-mxsboot-native imx-bootlets barebox"
+IMAGE_DEPENDS_barebox.mxsboot-sdcard = "elftosb-native:do_populate_sysroot \
+                                        u-boot-mxsboot-native:do_populate_sysroot \
+                                        imx-bootlets:do_deploy \
+                                        barebox:do_deploy"
 IMAGE_CMD_barebox.mxsboot-sdcard () {
 	barebox_bd_file=imx-bootlets-barebox_ivt.bd-${MACHINE}
 
@@ -49,7 +54,8 @@ IMAGE_CMD_barebox.mxsboot-sdcard () {
 
 # U-Boot mxsboot generation to SD-Card
 UBOOT_SUFFIX_SDCARD_mxs ?= "mxsboot-sdcard"
-IMAGE_DEPENDS_uboot.mxsboot-sdcard = "u-boot-mxsboot-native u-boot"
+IMAGE_DEPENDS_uboot.mxsboot-sdcard = "u-boot-mxsboot-native:do_populate_sysroot \
+                                      u-boot:do_deploy"
 IMAGE_CMD_uboot.mxsboot-sdcard = "mxsboot sd ${DEPLOY_DIR_IMAGE}/u-boot-${MACHINE}.${UBOOT_SUFFIX} \
                                              ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.uboot.mxsboot-sdcard"
 
@@ -65,8 +71,10 @@ BAREBOX_ENV_SPACE ?= "512"
 # Set alignment to 4MB [in KiB]
 IMAGE_ROOTFS_ALIGNMENT = "4096"
 
-IMAGE_DEPENDS_sdcard = "parted-native dosfstools-native mtools-native \
-                        virtual/kernel ${IMAGE_BOOTLOADER}"
+IMAGE_DEPENDS_sdcard = "parted-native:do_populate_sysroot \
+                        dosfstools-native:do_populate_sysroot \
+                        mtools-native:do_populate_sysroot \
+                        virtual/kernel:do_deploy ${IMAGE_BOOTLOADER}:do_deploy"
 
 SDCARD = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sdcard"
 
-- 
1.9.0

[meta-fsl-arm][PATCH 2/2] u-boot-fslc: Update to v2014.01 based release

[Otavio Salvador]

This updates U-Boot to a v2014.01 based release. It includes following
patches on top of prestine v2014.01 tag:

3fc5045 wandboard: add Future Eletronics 7" WVGA LCD extension board
5aebc94 mx6sl: Adjust fdt_addr to avoid address overlapping
95a98c2 mx6sabresd: Use mmcblk0 for CONFIG_MMCROOT
cd0b4d9 MX6: Add SION flag to ENET_REF_CLK PAD

Change-Id: I2bd74338c2e099b1e09cd504c6e8faefaa68d504
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 ...boot-fslc-mxsboot_2013.10.bb => u-boot-fslc-mxsboot_2014.01.bb} | 6 +++---
 recipes-bsp/u-boot/u-boot-fslc_2013.10.bb                          | 7 -------
 recipes-bsp/u-boot/u-boot-fslc_2014.01.bb                          | 7 +++++++
 3 files changed, 10 insertions(+), 10 deletions(-)
 rename recipes-bsp/u-boot/{u-boot-fslc-mxsboot_2013.10.bb => u-boot-fslc-mxsboot_2014.01.bb} (87%)
 delete mode 100644 recipes-bsp/u-boot/u-boot-fslc_2013.10.bb
 create mode 100644 recipes-bsp/u-boot/u-boot-fslc_2014.01.bb

diff --git a/recipes-bsp/u-boot/u-boot-fslc-mxsboot_2013.10.bb b/recipes-bsp/u-boot/u-boot-fslc-mxsboot_2014.01.bb
similarity index 87%
rename from recipes-bsp/u-boot/u-boot-fslc-mxsboot_2013.10.bb
rename to recipes-bsp/u-boot/u-boot-fslc-mxsboot_2014.01.bb
index 3009ddf..2c0848d 100644
--- a/recipes-bsp/u-boot/u-boot-fslc-mxsboot_2013.10.bb
+++ b/recipes-bsp/u-boot/u-boot-fslc-mxsboot_2014.01.bb
@@ -5,10 +5,10 @@ SECTION = "bootloader"
 DEPENDS = "openssl"
 PROVIDES = "u-boot-mxsboot"
 
-PV = "v2013.10"
+PV = "v2014.01"
 
-SRCREV = "079e214888279518ce061c71238a74a0c3db2c28"
-SRCBRANCH = "patches-2013.10"
+SRCREV = "bce40d36187be1d9165a9a6b9549c4989dcc48ed"
+SRCBRANCH = "patches-2014.01"
 SRC_URI = "git://github.com/Freescale/u-boot-imx.git;branch=${SRCBRANCH}"
 
 S = "${WORKDIR}/git"
diff --git a/recipes-bsp/u-boot/u-boot-fslc_2013.10.bb b/recipes-bsp/u-boot/u-boot-fslc_2013.10.bb
deleted file mode 100644
index e7f100d..0000000
--- a/recipes-bsp/u-boot/u-boot-fslc_2013.10.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-include u-boot-fslc.inc
-
-PV = "v2013.10"
-
-SRCBRANCH = "patches-2013.10"
-
-SRCREV = "31d023bf8f15e6407557f5273c35c6ee3466a77f"
diff --git a/recipes-bsp/u-boot/u-boot-fslc_2014.01.bb b/recipes-bsp/u-boot/u-boot-fslc_2014.01.bb
new file mode 100644
index 0000000..ec0ab00
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-fslc_2014.01.bb
@@ -0,0 +1,7 @@
+include u-boot-fslc.inc
+
+PV = "v2014.01"
+
+SRCBRANCH = "patches-2014.01"
+
+SRCREV = "bce40d36187be1d9165a9a6b9549c4989dcc48ed"
-- 
1.9.0

Vivante softfp with Yocto dora ??

[David Chirgwin]

Hi there,
 
I have a customer who wants to add vivante support to an existing softfp rootfs (their own custom distro).
At the moment I have supplied them a Yocto distro as a proof-of-concept (based on Dora branch, using hardfp).
 
I have seen this post https://community.freescale.com/message/372390#372390 which tells me how to persuade Yocto to use softfp for compilation. But how would I tell Yocto I want the softfp versions of pre-compiled binaries (in particular the vivante drivers)?
 
Is there a setting in conf/local.conf, or do I need a new recipe or something else?
 
All comments very welcome.
 
DaveC


Blue Chip Technology Limited. Chowley Oak Lane, Tattenhall, Chester, Cheshire CH3 9EX Tel: 01829 772000 Registered in England 3110403 Vat No: GB 618 374134

Re: Vivante softfp with Yocto dora ??

[Eric Bénard]

Hi David,

Le Thu, 6 Mar 2014 09:14:38 +0000 (GMT),
David Chirgwin <dchirgwin@bluechiptechnology.co.uk> a écrit :
> I have a customer who wants to add vivante support to an existing softfp rootfs (their own custom distro).
> At the moment I have supplied them a Yocto distro as a proof-of-concept (based on Dora branch, using hardfp).
>  
> I have seen this post https://community.freescale.com/message/372390#372390 which tells me how to persuade Yocto to use softfp for compilation. But how would I tell Yocto I want the softfp versions of pre-compiled binaries (in particular the vivante drivers)?
>  
> Is there a setting in conf/local.conf, or do I need a new recipe or something else?
>  
that's handled in
meta-fsl-arm/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc :
# Skip package if it does not match the machine float-point type in use
python __anonymous () {
        is_machine_hardfp = base_contains("TUNE_FEATURES",
"callconvention-hard", True, False, d) is_package_hardfp =
d.getVar("PACKAGE_FP_TYPE", True) == "hardfp"

        if is_package_hardfp != is_machine_hardfp:
                PN = d.getVar("PN", True)
                PV = d.getVar("PV", True)
                bb.debug(1, "Skipping %s (%s) as machine and package
        float-point does not match" % (PN, PV)) raise
        bb.parse.SkipPackage("Package Float-Point is not compatible
        with the machine") }


Eric

Re: Vivante softfp with Yocto dora ??

[Otavio Salvador]

On Thu, Mar 6, 2014 at 6:14 AM, David Chirgwin
<dchirgwin@bluechiptechnology.co.uk> wrote:
> I have a customer who wants to add vivante support to an existing softfp rootfs (their own custom distro).
> At the moment I have supplied them a Yocto distro as a proof-of-concept (based on Dora branch, using hardfp).
>
> I have seen this post https://community.freescale.com/message/372390#372390 which tells me how to persuade Yocto to use softfp for compilation. But how would I tell Yocto I want the softfp versions of pre-compiled binaries (in particular the vivante drivers)?
>
> Is there a setting in conf/local.conf, or do I need a new recipe or something else?

If you use a Soft-FP build  it will do the right thing for you. Or it
is a bug ;-)

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Vivante softfp with Yocto dora ??

[David Chirgwin]

----- Original Message -----
> From: "Otavio Salvador" <otavio@ossystems.com.br>
> To: "David Chirgwin" <dchirgwin@bluechiptechnology.co.uk>
> Cc: "meta-freescale Mailing List" <meta-freescale@yoctoproject.org>
> Sent: Thursday, 6 March, 2014 12:33:58 PM
> Subject: Re: [meta-freescale] Vivante softfp with Yocto dora ??
> 
> On Thu, Mar 6, 2014 at 6:14 AM, David Chirgwin
> <dchirgwin@bluechiptechnology.co.uk> wrote:
> > I have a customer who wants to add vivante support to an existing
> > softfp rootfs (their own custom distro).
> > At the moment I have supplied them a Yocto distro as a
> > proof-of-concept (based on Dora branch, using hardfp).
> >
> > I have seen this post
> > https://community.freescale.com/message/372390#372390 which tells
> > me how to persuade Yocto to use softfp for compilation. But how
> > would I tell Yocto I want the softfp versions of pre-compiled
> > binaries (in particular the vivante drivers)?
> >
> > Is there a setting in conf/local.conf, or do I need a new recipe or
> > something else?
> 
> If you use a Soft-FP build  it will do the right thing for you. Or it
> is a bug ;-)

Thanks for this. 

I added this line to conf/local.conf :
 
DEFAULTTUNE_mx6 = "cortexa9-neon"

and it all worked after that. :-)

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> 
Blue Chip Technology Limited. Chowley Oak Lane, Tattenhall, Chester, Cheshire CH3 9EX Tel: 01829 772000 Registered in England 3110403 Vat No: GB 618 374134

Re: [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use explit task dependency to boost build

[Daiane.Angolini]

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Wednesday, March 05, 2014 6:09 PM
> To: meta-freescale Mailing List
> Cc: Otavio Salvador
> Subject: [meta-freescale] [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use
> explit task dependency to boost build
> 
> Instead of depending of all tasks of recipes, we should depend on the
> required task so we can start building the rootfs earlier in the build
> process and earn some build time gain.

Cool!

Do you need help to test this?


Daiane
> 
> Change-Id: I770afe79edba0320ae697f9bcdaf340fbcb09eeb
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  classes/image_types_fsl.bbclass | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/classes/image_types_fsl.bbclass
> b/classes/image_types_fsl.bbclass index 47e8338..39ceb7a 100644
> --- a/classes/image_types_fsl.bbclass
> +++ b/classes/image_types_fsl.bbclass
> @@ -12,7 +12,9 @@ UBOOT_SUFFIX_SDCARD ?= "${UBOOT_SUFFIX}"
>  #
> 
>  # IMX Bootlets Linux bootstream
> -IMAGE_DEPENDS_linux.sb = "elftosb-native imx-bootlets virtual/kernel"
> +IMAGE_DEPENDS_linux.sb = "elftosb-native:do_populate_sysroot \
> +                          imx-bootlets:do_deploy \
> +                          virtual/kernel:do_deploy"
>  IMAGE_LINK_NAME_linux.sb = ""
>  IMAGE_CMD_linux.sb () {
>  	kernel_bin="`readlink ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-
> ${MACHINE}.bin`"
> @@ -37,7 +39,10 @@ IMAGE_CMD_linux.sb () {  }
> 
>  # IMX Bootlets barebox bootstream
> -IMAGE_DEPENDS_barebox.mxsboot-sdcard = "elftosb-native u-boot-mxsboot-
> native imx-bootlets barebox"
> +IMAGE_DEPENDS_barebox.mxsboot-sdcard = "elftosb-native:do_populate_sysroot
> \
> +                                        u-boot-mxsboot-
> native:do_populate_sysroot \
> +                                        imx-bootlets:do_deploy \
> +                                        barebox:do_deploy"
>  IMAGE_CMD_barebox.mxsboot-sdcard () {
>  	barebox_bd_file=imx-bootlets-barebox_ivt.bd-${MACHINE}
> 
> @@ -49,7 +54,8 @@ IMAGE_CMD_barebox.mxsboot-sdcard () {
> 
>  # U-Boot mxsboot generation to SD-Card
>  UBOOT_SUFFIX_SDCARD_mxs ?= "mxsboot-sdcard"
> -IMAGE_DEPENDS_uboot.mxsboot-sdcard = "u-boot-mxsboot-native u-boot"
> +IMAGE_DEPENDS_uboot.mxsboot-sdcard = "u-boot-mxsboot-
> native:do_populate_sysroot \
> +                                      u-boot:do_deploy"
>  IMAGE_CMD_uboot.mxsboot-sdcard = "mxsboot sd ${DEPLOY_DIR_IMAGE}/u-boot-
> ${MACHINE}.${UBOOT_SUFFIX} \
> 
> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.uboot.mxsboot-sdcard"
> 
> @@ -65,8 +71,10 @@ BAREBOX_ENV_SPACE ?= "512"
>  # Set alignment to 4MB [in KiB]
>  IMAGE_ROOTFS_ALIGNMENT = "4096"
> 
> -IMAGE_DEPENDS_sdcard = "parted-native dosfstools-native mtools-native \
> -                        virtual/kernel ${IMAGE_BOOTLOADER}"
> +IMAGE_DEPENDS_sdcard = "parted-native:do_populate_sysroot \
> +                        dosfstools-native:do_populate_sysroot \
> +                        mtools-native:do_populate_sysroot \
> +                        virtual/kernel:do_deploy
> ${IMAGE_BOOTLOADER}:do_deploy"
> 
>  SDCARD = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.sdcard"
> 
> --
> 1.9.0
> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
> 

Re: [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use explit task dependency to boost build

[Otavio Salvador]

On Thu, Mar 6, 2014 at 9:44 AM, Daiane.Angolini@freescale.com
<Daiane.Angolini@freescale.com> wrote:
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
>> Sent: Wednesday, March 05, 2014 6:09 PM
>> To: meta-freescale Mailing List
>> Cc: Otavio Salvador
>> Subject: [meta-freescale] [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use
>> explit task dependency to boost build
>>
>> Instead of depending of all tasks of recipes, we should depend on the
>> required task so we can start building the rootfs earlier in the build
>> process and earn some build time gain.
>
> Cool!
>
> Do you need help to test this?

Testing is welcome. I am using it here and added it in the
autobuilder. So far, all seems to be working as expected.

Alexandre, could you try that at your side as well with barebox?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use explit task dependency to boost build

[Alexandre Belloni]

Hi,

On 06/03/2014 at 09:48:55 -0300, Otavio Salvador wrote :
> On Thu, Mar 6, 2014 at 9:44 AM, Daiane.Angolini@freescale.com
> <Daiane.Angolini@freescale.com> wrote:
> >> -----Original Message-----
> >> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> >> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> >> Sent: Wednesday, March 05, 2014 6:09 PM
> >> To: meta-freescale Mailing List
> >> Cc: Otavio Salvador
> >> Subject: [meta-freescale] [meta-fsl-arm][PATCH 1/2] image_types_fsl: Use
> >> explit task dependency to boost build
> >>
> >> Instead of depending of all tasks of recipes, we should depend on the
> >> required task so we can start building the rootfs earlier in the build
> >> process and earn some build time gain.
> >
> > Cool!
> >
> > Do you need help to test this?
> 
> Testing is welcome. I am using it here and added it in the
> autobuilder. So far, all seems to be working as expected.
> 
> Alexandre, could you try that at your side as well with barebox?
> 

I'm probably one month late but I just realized I never replied but
this seems to be working fine :)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com