1. meta-freescale@lists.yoctoproject.org
  2. Messages
   Date   
Re: No IMAGE_CMD defined for IMAGE_FSTYPES

Ekaterini Voulgari <sdi1100002@...>
 

On 18/10/19 1:32 π.μ., Dionevã Milbrath Krolow wrote:
Hello,

Replace "sdcard" by "wic".

Sdcard is format obsolete.

Regards,

Dionevã M. Krolow


De: meta-freescale-bounces@... <meta-freescale-bounces@...> em nome de Ekaterini Voulgari <sdi1100002@...>
Enviado: quinta-feira, 17 de outubro de 2019 10:31
Para: meta-freescale@... <meta-freescale@...>
Assunto: [meta-freescale] No IMAGE_CMD defined for IMAGE_FSTYPES
 
Hello,

I want to move a layer from korgoth to warrior.

The error is:

/poky/meta-openembedded/meta-python/recipes-core/images/meta-python-ptest-image.bb:
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid
type name or missing support class
ERROR:
/poky/meta-openembedded/meta-python/recipes-core/images/meta-python-image-base.bb:
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid
type name or missing support class
ERROR:
/poky/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb:
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid
type name or missing support class
ERROR: Failed to parse recipe:
/poky/meta-openembedded/meta-python/recipes-core/images/meta-python-ptest-image.bb

In file "/meta-fsl-arm/classes/image_types_fsl.bbclass" there is a
function "IMAGE_CMD_sdcard ()" at line 308. I am thinking perhaps I need
to find where is the IMAGE_CMD in the newest meta-freescale layer since
meta-fsl-arm is deprecated?

The board is MYirTech's MYS-6ULX (IoT) and Yocto is warrior version.


--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale

thanks Dionevã, the error is gone and the image is building. Here's what I changed just for the record:


The 'sdcard' string was found in the vendor's machine.conf:

    UBOOT_CONFIG[sd] = "mys_imx6ull_14x14_emmc_config,sdcard"


in machine/includes as:

   SOC_DEFAULT_IMAGE_FSTYPES = "sdcard.gz ext3 ubi ubifs"


and in distro.conf as:

   IMAGE_FSTYPES = "tar.bz2 tar.xz ext4 sdcard"


so I have made these naive changes to local.conf:


IMAGE_FSTYPES_remove= "sdcard.gz sdcard"
IMAGE_FSTYPES_append = "wic"
UBOOT_CONFIG_remove = "sdcard"
UBOOT_CONFIG_append = "wic"

SOC_DEFAULT_IMAGE_FSTYPES_remove = "sdcard.gz"
SOC_DEFAULT_IMAGE_FSTYPES_append = "wic"



Katerina
Which Linux distribution for building FSL-BSP ?

Guillaume Betous <guillaume.betous@...>
 

Hi,

I'm planning to build a full system on imx6 (based on solidrun imx6 SOM). I read the FSL-BSP documentation but I could not find any advice concerning the distribution (which means basically gcc version).

Is Ubuntu 18.04 LTS ok ? Or which one would be used as a reference ?

Thank you,

Regards,

gUI
No IMAGE_CMD defined for IMAGE_FSTYPES

Ekaterini Voulgari <sdi1100002@...>
 

Hello,

I want to move a layer from korgoth to warrior.

The error is:

/poky/meta-openembedded/meta-python/recipes-core/images/meta-python-ptest-image.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid type name or missing support class
ERROR: /poky/meta-openembedded/meta-python/recipes-core/images/meta-python-image-base.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid type name or missing support class
ERROR: /poky/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard' - possibly invalid type name or missing support class
ERROR: Failed to parse recipe: /poky/meta-openembedded/meta-python/recipes-core/images/meta-python-ptest-image.bb

In file "/meta-fsl-arm/classes/image_types_fsl.bbclass" there is a function "IMAGE_CMD_sdcard ()" at line 308. I am thinking perhaps I need to find where is the IMAGE_CMD in the newest meta-freescale layer since meta-fsl-arm is deprecated?

The board is MYirTech's MYS-6ULX (IoT) and Yocto is warrior version.
Re: meta-freescale Sumo release?

Matt
 

Hi Andrey,

Thank you for the answers. They are very helpful. I think the master branch should work.

My understanding is the hardware vendor will also release the hardware specific meta data layer for every Poky release. NXP will have a meta-freescale release for a corresponding Poky release. For example, a Sumo release for a matching Poky Sumo release, a Thud release for a matching Poky Thud release, ...etc. I wonder if any NXP people can comment on this?


Matt

-----Original Message-----
From: Andrey Zhizhikin [mailto:andrey.z@...]
Sent: Tuesday, October 15, 2019 12:10 AM
To: Tsai, Matt <matt.tsai@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] meta-freescale Sumo release?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Fri, Oct 11, 2019 at 11:46 PM Tsai, Matt <matt.tsai@...> wrote:

Hi Andrey,
Hey Matt!


Thank you the reply.
No problem!


I picked the sumo branches from both Poky and meta-freescale for P2020 RDB. They were the stable branches at the time I started.
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.
org_cgit_cgit.cgi_poky_log_-3Fh-3Dsumo&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz
6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&
m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=tFW4BjXOlwqT5eJaa01zw7
NvdKZP45ST9uukMSDfbts&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.o
rg_cgit_cgit.cgi_meta-2Dfreescale_log_-3Fh-3Dsumo&d=DwIBaQ&c=q6k2DsTcE
GCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjg
QI-UHuV1XU&m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=0HqN1HqM_yf
2v_u5Mgb6vB8HfB_vStW_HgzczUUOf6M&e=
You would need couple of additional layers to build the image for your target... This is listed in:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Freescale_fsl-2Dcommunity-2Dbsp-2Dbase&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=4sZnuDGORKEsyLqh1mMD8yUoagsqGoBPY-ZYBZroWhk&e=


I was looking for a release note or annoucement for meta-freescale sumo branch:
Something like this: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_pipermail_yocto-2Dannounce_2018-2DMay_000136.html&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=PWjdCntDioGPIGFJTDw_uOdZtnalXIFav_19V7liRDo&e= from Poky for the sumo release.
Or something like this: https://urldefense.proofpoint.com/v2/url?u=http-3A__freescale.github.io_doc_release-2Dnotes_2.4_&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=-V4Jj4z4wbkp5GyoA26TtCzrz8wwdlVl5pQp_AgdUnI&e= from meta-freescale for the sumo release. However, Rocko is the latest release I could find.
I do not think that NXP would make an announcement for other releases in a form you're expecting it to be, but even if they would - you're not limited to that release, and can always try to build your image from either the master branch or any stable branches that you're interested in. Bottom line is I guess for this point NXP people should comment here.

- What is the difference between the meta-freescale reporitory you referred to (on Github) and the yoctoproject.org GIT repository?
I believe Github is the place of origin for the meta-freescale development, and Yocto Project is a mirror of it.

- If meta-freescale has no plan to release "sumo", what are the releases after "rocko" that supports P2020 RDB? And where I can find a release note (annoucement), or plan if it is not released yet?
Did you try to build off the latest "master" branch? This should have a support for QorIQ platforms (have a look at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Freescale_meta-2Dfreescale_blob_master_recipes-2Dkernel_linux_linux-2Dqoriq-5F4.19.bb&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&m=KbOgzcbRmc5C-dMbLgYwD7UH59CTtJIzy5UokfSPNN4&s=p8N9xZk6tqilEdvN52WU63zJg7UeSj4CkWhpNWlxxkc&e=
for example).

What you would need to do here is to look at the manifest file that NXP provided for sumo, deduct all remotes and layers from it (meta-fresscale, meta-freescale-distro, meta-freescale-3rdparty, etc.), put them together and run the build.



Thank you,


Matt
-- andrey
Re: meta-freescale Sumo release?

Andrey Zhizhikin
 

On Fri, Oct 11, 2019 at 11:46 PM Tsai, Matt <matt.tsai@...> wrote:

Hi Andrey,
Hey Matt!


Thank you the reply.
No problem!


I picked the sumo branches from both Poky and meta-freescale for P2020 RDB. They were the stable branches at the time I started.
https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=sumo
http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/log/?h=sumo
You would need couple of additional layers to build the image for your
target... This is listed in:
https://github.com/Freescale/fsl-community-bsp-base


I was looking for a release note or annoucement for meta-freescale sumo branch:
Something like this: https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html from Poky for the sumo release.
Or something like this: http://freescale.github.io/doc/release-notes/2.4/ from meta-freescale for the sumo release. However, Rocko is the latest release I could find.
I do not think that NXP would make an announcement for other releases
in a form you're expecting it to be, but even if they would - you're
not limited to that release, and can always try to build your image
from either the master branch or any stable branches that you're
interested in. Bottom line is I guess for this point NXP people should
comment here.

- What is the difference between the meta-freescale reporitory you referred to (on Github) and the yoctoproject.org GIT repository?
I believe Github is the place of origin for the meta-freescale
development, and Yocto Project is a mirror of it.

- If meta-freescale has no plan to release "sumo", what are the releases after "rocko" that supports P2020 RDB? And where I can find a release note (annoucement), or plan if it is not released yet?
Did you try to build off the latest "master" branch? This should have
a support for QorIQ platforms (have a look at
https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-qoriq_4.19.bb
for example).

What you would need to do here is to look at the manifest file that
NXP provided for sumo, deduct all remotes and layers from it
(meta-fresscale, meta-freescale-distro, meta-freescale-3rdparty,
etc.), put them together and run the build.



Thank you,


Matt
-- andrey
Re: meta-freescale Sumo release?

Matt
 

Hi Andrey,

Thank you the reply.

I picked the sumo branches from both Poky and meta-freescale for P2020 RDB. They were the stable branches at the time I started.
https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=sumo
http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/log/?h=sumo

I was looking for a release note or annoucement for meta-freescale sumo branch:
Something like this: https://lists.yoctoproject.org/pipermail/yocto-announce/2018-May/000136.html from Poky for the sumo release.
Or something like this: http://freescale.github.io/doc/release-notes/2.4/ from meta-freescale for the sumo release. However, Rocko is the latest release I could find.

- What is the difference between the meta-freescale reporitory you referred to (on Github) and the yoctoproject.org GIT repository?
- If meta-freescale has no plan to release "sumo", what are the releases after "rocko" that supports P2020 RDB? And where I can find a release note (annoucement), or plan if it is not released yet?


Thank you,


Matt

-----Original Message-----
From: Andrey Zhizhikin [mailto:andrey.z@...]
Sent: Friday, October 11, 2019 2:48 AM
To: Tsai, Matt <matt.tsai@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] meta-freescale Sumo release?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hey Matt,

On Thu, Oct 10, 2019 at 9:16 PM Tsai, Matt <matt.tsai@...> wrote:
...

I could not find any documentation and announcement for a Sumo release on meta-freescale and Freescale documentation Github.
Freescale Github contains a sumo branch
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Freescale_meta-2Dfreescale_tree_sumo&d=DwIBaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=LfbDghM-XW_5RT-h77pAoNBiz4zBr-sjgQI-UHuV1XU&m=R0X_hJDcCODrBwVU9b_M1xTLZi8FRWqMg56DLMI4wc0&s=4-iQ8j3eS2bceupldZESlC3vYkrBPFnYqDeFOVJJgag&e= ), so you should be able to build off of that. You should also pick up a corresponding sumo from meta-freescale-distro and meta-freescale-3rdparty.

Has meta-freescale Sumo ever been released? If yes, where I can find the release documentation? If not, what is the release plan and where the information can be found?
What exact release announcement and documentation you're referring to?
From what I see, sumo branch is present in all layers necessary to build the Freescale distro.

Besides, what is your motivation to use the sumo branch? It is already quite old, and is at least 2 stable branches behind (thud and warrior) with one more (3.0) underway. Maybe you should consider to switch to the latest here as I do not believe that sumo has any "release plan"
anymore.


Thank you in advance!
Matt
-- andrey
Re: meta-freescale Sumo release?

Andrey Zhizhikin
 

Hey Matt,

On Thu, Oct 10, 2019 at 9:16 PM Tsai, Matt <matt.tsai@...> wrote:
...

I could not find any documentation and announcement for a Sumo release on meta-freescale and Freescale documentation Github.
Freescale Github contains a sumo branch
(https://github.com/Freescale/meta-freescale/tree/sumo), so you should
be able to build off of that. You should also pick up a corresponding
sumo from meta-freescale-distro and meta-freescale-3rdparty.

Has meta-freescale Sumo ever been released? If yes, where I can find the release documentation? If not, what is the release plan and where the information can be found?
What exact release announcement and documentation you're referring to?
From what I see, sumo branch is present in all layers necessary to
build the Freescale distro.

Besides, what is your motivation to use the sumo branch? It is already
quite old, and is at least 2 stable branches behind (thud and warrior)
with one more (3.0) underway. Maybe you should consider to switch to
the latest here as I do not believe that sumo has any "release plan"
anymore.


Thank you in advance!
Matt
-- andrey
Re: meta-freescale Sumo release?

Matt
 

Hi all,

 

Does anyone know the answers to the questions I asked last week? Or any pointers to where the questions may be answered? Any help is much appreciated. Thank you for the help!

 

From: meta-freescale-bounces@... [mailto:meta-freescale-bounces@...] On Behalf Of Tsai, Matt
Sent: Friday, October 4, 2019 5:00 PM
To: meta-freescale@...
Subject: [meta-freescale] meta-freescale Sumo release?

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi all,

 

I could not find any documentation and announcement for a Sumo release on meta-freescale and Freescale documentation Github.

 

Question:

Has meta-freescale Sumo ever been released? If yes, where I can find the release documentation? If not, what is the release plan and where the information can be found?

 

 

Thank you in advance!

 

 

Matt

 
Re: Using Qt EGLFS without wayland DISTRO_FEATURES on i.MX8

Diego Rondini
 

Hi Karim,


On 09/10/2019 10:12, Karim ATIKI wrote:
Hi Diego,

No, this is not a shortcoming, afaik.
Current iMX8 config does not support, and will not support eglfs.
Wayland /XWayland is the alternative to use.

And even if your DISTRO_FEATURES contains wayland or xwayland, eglfs in PACKAGECONFIG will raise an error during the build.

However, OpenGL ES 1,2 and 3 is still supported by Qt on IMX8.

Thank you for your reply.


I think EGLFS is supported on i.MX8, as Boundary Devices is providing a Boot2Qt image which uses Qt EGLFS:

https://boundarydevices.com/boot2qt-embedded-qt5-image-and-toolchain-for-nitrogen8m-and-8m-mini/


Also I don't have issues in thud when building qtbase with both wayland and eglfs in PACKAGECONFIG.


My question is still: is it possible to build qtbase with eglfs but without wayland in PACKAGECONFIG?


Otherwise I will just use qtbase with eglfs and wayland and not use the wayland support.


Regards,

Diego
Re: Using Qt EGLFS without wayland DISTRO_FEATURES on i.MX8

Atiki Karim
 

Hi Diego,

No, this is not a shortcoming, afaik.
Current iMX8 config does not support, and will not support eglfs.
Wayland /XWayland is the alternative to use.

And even if your DISTRO_FEATURES contains wayland or xwayland, eglfs in PACKAGECONFIG will raise an error during the build.

However, OpenGL ES 1,2 and 3 is still supported by Qt on IMX8.


Karim.

De : meta-freescale-bounces@... <meta-freescale-bounces@...> de la part de diego.ml <diego.ml@...>
Envoyé : mardi 8 octobre 2019 16:19
À : meta-freescale <meta-freescale@...>
Objet : [meta-freescale] Using Qt EGLFS without wayland DISTRO_FEATURES on i.MX8
 
Hi,

As far as I understand it is currently impossible to build qtbase with "eglfs" in PACKAGECONFIG without also having "wayland" in DISTRO_FEATURES in a build for an i.MX8. Is this correct?


This is my reasoning:
1) the currently available i.MX8 SOCs all have "imxgpu3d":
https://github.com/Freescale/meta-freescale/blob/master/conf/machine/include/imx-base.inc#L79
2) this means that qtbase PACKAGECONFIG_GL will be "gles2":
https://github.com/Freescale/meta-freescale/blob/master/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%25.bbappend#L22
3) so imx-gpu-viv will be required to provide "virtual/libgles2". imx-gpu-viv then requires "wayland" as a DISTRO_FEATURE
https://github.com/Freescale/meta-freescale/blob/master/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc#L56

Is this a shortcoming of how imx-gpu-viv libraries are provided by NXP?

Thank you,
Diego


--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale
Using Qt EGLFS without wayland DISTRO_FEATURES on i.MX8

Diego Rondini
 

Hi,

As far as I understand it is currently impossible to build qtbase with "eglfs" in PACKAGECONFIG without also having "wayland" in DISTRO_FEATURES in a build for an i.MX8. Is this correct?


This is my reasoning:
1) the currently available i.MX8 SOCs all have "imxgpu3d":
https://github.com/Freescale/meta-freescale/blob/master/conf/machine/include/imx-base.inc#L79
2) this means that qtbase PACKAGECONFIG_GL will be "gles2":
https://github.com/Freescale/meta-freescale/blob/master/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%25.bbappend#L22
3) so imx-gpu-viv will be required to provide "virtual/libgles2". imx-gpu-viv then requires "wayland" as a DISTRO_FEATURE
https://github.com/Freescale/meta-freescale/blob/master/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc#L56

Is this a shortcoming of how imx-gpu-viv libraries are provided by NXP?

Thank you,
Diego
Using Qt EGLFS without wayland DISTRO_FEATURES on i.MX8

Diego Rondini
 

Hi,

As far as I understand it is currently impossible to build qtbase with "eglfs" in PACKAGECONFIG without also having "wayland" in DISTRO_FEATURES in a build for an i.MX8. Is this correct?


This is my reasoning:
1) the currently available i.MX8 SOCs all have "imxgpu3d":
https://github.com/Freescale/meta-freescale/blob/master/conf/machine/include/imx-base.inc#L79
2) this means that qtbase PACKAGECONFIG_GL will be "gles2":
https://github.com/Freescale/meta-freescale/blob/master/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%25.bbappend#L22
3) so imx-gpu-viv will be required to provide "virtual/libgles2". imx-gpu-viv then requires "wayland" as a DISTRO_FEATURE
https://github.com/Freescale/meta-freescale/blob/master/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc#L56

Is this a shortcoming of how imx-gpu-viv libraries are provided by NXP?

Thank you,
Diego
Regarding u-boot 2010.03 compilation with gcc 7.3(latest gcc in yocto)

Praveen Reddy
 

Hi All,

When I am compiling u-boot 2010.03 with gcc 7.3 in yocto, It is throwing errors regarding multiple definition of the all extern inline functions in u-boot. It seems this gcc version is not supporting external inline functions.

Below is sample error log

---/build/tmp/work/tng-poky-linux-gnuspe/u-boot-qoriq/2018.03+fslgit-r0/u-boot-2010.03/include/asm/bitops.h:256: multiple definition of `find_next_zero_bit'
hello_world.o:/home/praveen/tng-bsp/build/tmp/work/tng-poky-linux-gnuspe/u-boot-qoriq/2018.03+fslgit-r0/u-boot-2010.03/include/asm/bitops.h:256: first defined here
libstubs.a(stubs.o): In function `ext2_test_bit':
---/build/tmp/work/tng-poky-linux-gnuspe/u-boot-qoriq/2018.03+fslgit-r0/u-boot-2010.03/include/asm/bitops.h:330: multiple definition of `ext2_test_bit'
hello_world.o:/home/praveen/tng-bsp/build/tmp/work/tng-poky-linux-gnuspe/u-boot-qoriq/2018.03+fslgit-r0/u-boot-2010.03/include/asm/bitops.h:330: first defined here

below is piece of code from bitops.h from where error is coming

extern __inline__ int ext2_test_bit(int nr, __const__ void * addr)
{
    __const__ unsigned char    *ADDR = (__const__ unsigned char *) addr;

    return (ADDR[nr >> 3] >> (nr & 7)) & 1;
}

coming Any idea what is wrong and how to fix the problem?

Is it the right place to ask question about freescale u-boot compilation in yocto.

Thanks

Praveen Reddy P
meta-freescale Sumo release?

Matt
 

Hi all,

 

I could not find any documentation and announcement for a Sumo release on meta-freescale and Freescale documentation Github.

 

Question:

Has meta-freescale Sumo ever been released? If yes, where I can find the release documentation? If not, what is the release plan and where the information can be found?

 

 

Thank you in advance!

 

 

Matt

 
Adding a python package

gokhannsahin@gmail.com
 

Hi everyone,
I want to add a python package that is sqlite3 on imx6sx.
I have tried adding it as an image install parameter but didn't work.
How can I add the specified packages of python by building?
IMAGE_INSTALL_append = "openssh-sftp \
openssh-sftp-server \
sqlite3 \
python-pysqlite \
"
Thank you!
MfgTool bsp building using yocto warrior branch

FrancPalm
 

Hi all,
I need to update mfgtool bsp for a custom board.
Until now I used the bsp mfgtool builded using the dora branch but now a new emmc chip is no more compatible with kernel 3.10 mmc driver.

I'm using now the warrior branch and I'm tring to bitbake the recipe fsl-image-mfgtool-initramfs for MACHINE imx6qdlsabresd without any modifications.

Bitbake give me this error:
You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time

If inside the imx6qdlsabresd.conf I remove the following row the build is executed:
UBOOT_MACHINE ?= "mx6sabresd_defconfig"

With the builded files I've prepared the MfgToolv2 package but when I launch it the mfgtool kernel was not completely executed because stay stuck with following message (ever 30s):
No udc Available!

My question are:
-) The machine config fix is right? I think not because in deploy folder I don't found the u-boot-mfgtool for example.
-) This new yocto branch mfgtool generate files are compatible with MfgToolv2?

Thanks for support
============================
Francesco Palmisano
Re: [PATCH] imx-gpu-viv: fix libvulkan soname issue

Ming Liu <liu.ming50@...>
 

Hi, Max:

Thanks for the review, I think you are absolutely correct, please ignore my patch.

//Ming Liu

Max Krummenacher <max.oss.09@...> 於 2019年10月2日 週三 上午9:51寫道：

Hi Ming

While this fixes the conflict I believe (or hope) that imx-gpu-viv/libvulkan_VSI provides the vulkan ICD (installable client driver) for the Vivante GPU while libvulkan from vulkan_loader provides the vulkan_loader.

So we likely need both shared objects to use vulkan.

I guess the proper fix is to change the soname to something different, preferably in the upstream binary, until then by patching the shared object. I sent a pull request on github.


Max

Am Di., 1. Okt. 2019 um 22:30 Uhr schrieb <liu.ming50@...>:
From: Ming Liu <liu.ming50@...>

Installing the vulkan driver in ${D}${libdir}/vulkan subdirectory is
not a proper fix for the conflict with vulkan-loader. The root cause
of this conflict is that both our libvulkan and vulkan-loader's
libvulkan have a same soname libvulkan.so.1, we should set PRIVATE_LIBS
in this case to fix the conflict. Or else, the soname would still be
detected during package_do_shlibs, and hence will lead to other
dependency problems for the recipes that depending on vulkan-loader.

For instance, this patch fixes a following error:
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa:
| QA Issue: /usr/lib/gstreamer-1.0/libgstvulkan.so contained in package gstreamer1.0-plugins-bad-vulkan requires libvulkan.so.1()(64bit),
| but no providers found in RDEPENDS_gstreamer1.0-plugins-bad-vulkan? [file-rdeps]
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Signed-off-by: Ming Liu <liu.ming50@...>
---
 recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
index ef10c96..e75ada0 100644
--- a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
+++ b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
@@ -233,12 +233,7 @@ do_install () {
     ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so

     if [ "${IS_MX8}" = "1" ]; then
-        # Install the vulkan driver in a sub-folder. When installed in the same
-        # folder as the vulkan loader layer library, an incorrect linkage is
-        # created from libvulkan.so.1 to our library instead of the loader
-        # layer library.
-        install -d ${D}${libdir}/vulkan
-        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/vulkan/libvulkan_VSI.so
+        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/libvulkan_VSI${SOLIBS}
     fi
     for header in ${GLES3_HEADER_REMOVALS}; do
         rm -f ${D}${includedir}/GLES3/${header}
@@ -307,9 +302,9 @@ FILES_libgbm-imx_mx8           = "${libdir}/libgbm${SOLIBS} ${libdir}/gbm_viv${S
 FILES_libgbm-imx-dev_mx8       = "${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h ${libdir}/libgbm${SOLIBSDEV}"
 RDEPENDS_libgbm-imx_append_mx8 = " libdrm"

-FILES_libvulkan-imx = "${libdir}/vulkan/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
-FILES_libvulkan-imx-dev = "${includedir}/vulkan ${libdir}/vulkan/libvulkan_VSI${SOLIBSDEV}"
-INSANE_SKIP_libvulkan-imx += "dev-deps dev-so"
+FILES_libvulkan-imx = "${libdir}/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
+FILES_libvulkan-imx-dev = "${includedir}/vulkan"
+PRIVATE_LIBS_libvulkan-imx = "libvulkan.so.1"

 FILES_libopenvx-imx = "${libdir}/libOpenVX${SOLIBS} ${libdir}/libOpenVXC${SOLIBS} ${libdir}/libOpenVXU${SOLIBS}"
 FILES_libopenvx-imx-dev = "${includedir}/VX ${libdir}/libopenVX${SOLIBSDEV}"
--
2.7.4

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [PATCH] imx-gpu-viv: fix libvulkan soname issue

Max Krummenacher
 

Hi Ming

While this fixes the conflict I believe (or hope) that imx-gpu-viv/libvulkan_VSI provides the vulkan ICD (installable client driver) for the Vivante GPU while libvulkan from vulkan_loader provides the vulkan_loader.

So we likely need both shared objects to use vulkan.

I guess the proper fix is to change the soname to something different, preferably in the upstream binary, until then by patching the shared object. I sent a pull request on github.


Max

Am Di., 1. Okt. 2019 um 22:30 Uhr schrieb <liu.ming50@...>:

From: Ming Liu <liu.ming50@...>

Installing the vulkan driver in ${D}${libdir}/vulkan subdirectory is
not a proper fix for the conflict with vulkan-loader. The root cause
of this conflict is that both our libvulkan and vulkan-loader's
libvulkan have a same soname libvulkan.so.1, we should set PRIVATE_LIBS
in this case to fix the conflict. Or else, the soname would still be
detected during package_do_shlibs, and hence will lead to other
dependency problems for the recipes that depending on vulkan-loader.

For instance, this patch fixes a following error:
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa:
| QA Issue: /usr/lib/gstreamer-1.0/libgstvulkan.so contained in package gstreamer1.0-plugins-bad-vulkan requires libvulkan.so.1()(64bit),
| but no providers found in RDEPENDS_gstreamer1.0-plugins-bad-vulkan? [file-rdeps]
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Signed-off-by: Ming Liu <liu.ming50@...>
---
 recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
index ef10c96..e75ada0 100644
--- a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
+++ b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
@@ -233,12 +233,7 @@ do_install () {
     ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so

     if [ "${IS_MX8}" = "1" ]; then
-        # Install the vulkan driver in a sub-folder. When installed in the same
-        # folder as the vulkan loader layer library, an incorrect linkage is
-        # created from libvulkan.so.1 to our library instead of the loader
-        # layer library.
-        install -d ${D}${libdir}/vulkan
-        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/vulkan/libvulkan_VSI.so
+        mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/libvulkan_VSI${SOLIBS}
     fi
     for header in ${GLES3_HEADER_REMOVALS}; do
         rm -f ${D}${includedir}/GLES3/${header}
@@ -307,9 +302,9 @@ FILES_libgbm-imx_mx8           = "${libdir}/libgbm${SOLIBS} ${libdir}/gbm_viv${S
 FILES_libgbm-imx-dev_mx8       = "${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h ${libdir}/libgbm${SOLIBSDEV}"
 RDEPENDS_libgbm-imx_append_mx8 = " libdrm"

-FILES_libvulkan-imx = "${libdir}/vulkan/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
-FILES_libvulkan-imx-dev = "${includedir}/vulkan ${libdir}/vulkan/libvulkan_VSI${SOLIBSDEV}"
-INSANE_SKIP_libvulkan-imx += "dev-deps dev-so"
+FILES_libvulkan-imx = "${libdir}/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
+FILES_libvulkan-imx-dev = "${includedir}/vulkan"
+PRIVATE_LIBS_libvulkan-imx = "libvulkan.so.1"

 FILES_libopenvx-imx = "${libdir}/libOpenVX${SOLIBS} ${libdir}/libOpenVXC${SOLIBS} ${libdir}/libOpenVXU${SOLIBS}"
 FILES_libopenvx-imx-dev = "${includedir}/VX ${libdir}/libopenVX${SOLIBSDEV}"
--
2.7.4

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale
[PATCH] imx-gpu-viv: fix libvulkan soname issue

liu.ming50@...
 

From: Ming Liu <liu.ming50@...>

Installing the vulkan driver in ${D}${libdir}/vulkan subdirectory is
not a proper fix for the conflict with vulkan-loader. The root cause
of this conflict is that both our libvulkan and vulkan-loader's
libvulkan have a same soname libvulkan.so.1, we should set PRIVATE_LIBS
in this case to fix the conflict. Or else, the soname would still be
detected during package_do_shlibs, and hence will lead to other
dependency problems for the recipes that depending on vulkan-loader.

For instance, this patch fixes a following error:
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa:
| QA Issue: /usr/lib/gstreamer-1.0/libgstvulkan.so contained in package gstreamer1.0-plugins-bad-vulkan requires libvulkan.so.1()(64bit),
| but no providers found in RDEPENDS_gstreamer1.0-plugins-bad-vulkan? [file-rdeps]
| ERROR: gstreamer1.0-plugins-bad-1.14.imx-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Signed-off-by: Ming Liu <liu.ming50@...>
---
recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
index ef10c96..e75ada0 100644
--- a/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
+++ b/recipes-graphics/imx-gpu-viv/imx-gpu-viv-6.inc
@@ -233,12 +233,7 @@ do_install () {
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so

if [ "${IS_MX8}" = "1" ]; then
- # Install the vulkan driver in a sub-folder. When installed in the same
- # folder as the vulkan loader layer library, an incorrect linkage is
- # created from libvulkan.so.1 to our library instead of the loader
- # layer library.
- install -d ${D}${libdir}/vulkan
- mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/vulkan/libvulkan_VSI.so
+ mv ${D}${libdir}/libvulkan-${backend}.so ${D}${libdir}/libvulkan_VSI${SOLIBS}
fi
for header in ${GLES3_HEADER_REMOVALS}; do
rm -f ${D}${includedir}/GLES3/${header}
@@ -307,9 +302,9 @@ FILES_libgbm-imx_mx8 = "${libdir}/libgbm${SOLIBS} ${libdir}/gbm_viv${S
FILES_libgbm-imx-dev_mx8 = "${libdir}/pkgconfig/gbm.pc ${includedir}/gbm.h ${libdir}/libgbm${SOLIBSDEV}"
RDEPENDS_libgbm-imx_append_mx8 = " libdrm"

-FILES_libvulkan-imx = "${libdir}/vulkan/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
-FILES_libvulkan-imx-dev = "${includedir}/vulkan ${libdir}/vulkan/libvulkan_VSI${SOLIBSDEV}"
-INSANE_SKIP_libvulkan-imx += "dev-deps dev-so"
+FILES_libvulkan-imx = "${libdir}/libvulkan_VSI${SOLIBS} ${libdir}/libSPIRV_viv${SOLIBS}"
+FILES_libvulkan-imx-dev = "${includedir}/vulkan"
+PRIVATE_LIBS_libvulkan-imx = "libvulkan.so.1"

FILES_libopenvx-imx = "${libdir}/libOpenVX${SOLIBS} ${libdir}/libOpenVXC${SOLIBS} ${libdir}/libOpenVXU${SOLIBS}"
FILES_libopenvx-imx-dev = "${includedir}/VX ${libdir}/libopenVX${SOLIBSDEV}"
--
2.7.4
Re: Sumo bison error

Bas Mevissen
 

On 26-09-19 15:48, Mauro Ziliani wrote:
Hi all.
I'm trying sumo for imx6dlsabresd.
bitbake core-image-minimal give me this error
| ../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."
Maybe some goes wrong with bison
Your problem is most likely with the host system being too new. What do you use to build on?

This is local.conf
MACHINE ??= 'imx6qdlsabresd'
DISTRO ?= 'fslc-x11'
PACKAGE_CLASSES ?= "package_deb"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"
Ans this bblayers.confLCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"
BBFILES ?= ""
BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  \
  ${BSPDIR}/sources/meta-freescale \
  ${BSPDIR}/sources/meta-freescale-3rdparty \
  ${BSPDIR}/sources/meta-freescale-distro \
"
BBLAYERS += " \
  ${BSPDIR}/sources/meta-openembedded/meta-networking \
  ${BSPDIR}/sources/meta-openembedded/meta-python \
  ${BSPDIR}/sources/meta-qt5 \
"
Any idea?
Best regards.
  MZ
821 - 840 of 24910