Yocto iMX6 camera crash with no camera & Yocto available images

[JohnCannizzo]

Hi All,

I just tried my first Yocto build on the iMX6 SDB.  How easy was that!  GREAT job!!!  After LTIB headaches over the years, it is quite refreshing to follow the instructions, download as instructed, build, have it run to completion without errors, and work first time.  HUGE LEAP FORWARD! THANK YOU, THANK YOU, THANK YOU!!!  For those who haven't tried it, you owe it to yourself...

I was running the fsl-image-gui image, and during my initial playing around, the following appeared on the serial console:

WARNING! power/level is deprecated; use power/control instead

Unhandled fault: imprecise external abort (0x1406) at 0x2bd4c07c

Internal error: : 1406 [#1] PREEMPT SMP

Modules linked in: vivante drm ov5640_camera_mipi ov5642_camera camera_sensor_clock

CPU: 2    Not tainted  (3.0.35-1.1.0+yocto+g21304e1 #1)

PC is at audmux_read_file+0x60/0x2b4

LR is at audmux_read_file+0x30/0x2b4

pc : [<80064498>]    lr : [<80064468>]    psr: 600f0013

sp : b9ca5f38  ip : 8003c5f4  fp : 2bd0ce08

r10: 00001000  r9 : b9ca5f88  r8 : 2bbd1990

r7 : b9ca5f88  r6 : 80aedd0c  r5 : 00000000  r4 : baae4000

r3 : 00000038  r2 : f41d8000  r1 : 80a9fcc8  r0 : 00000000

Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user

Control: 10c53c7d  Table: 4b16804a  DAC: 00000015

Process pool (pid: 757, stack limit = 0xb9ca42f0)

Stack: (0xb9ca5f38 to 0xb9ca6000)

5f20:                                                       00000017 00000000

5f40: bb088a00 00001000 2bbd1990 b9ca5f88 00001000 b9ca4000 00000000 800f5788

5f60: 00000001 800f6c50 00000000 00000000 bb088a00 2bbd1990 00001000 800f5864

5f80: 00000024 00000001 00000000 00000000 2bd0b280 00000000 2bd04050 00000003

5fa0: 80041284 80041100 2bd0b280 00000000 00000017 2bbd1990 00001000 00000000

5fc0: 2bd0b280 00000000 2bd04050 00000003 00000017 00000000 0000492a 2bd0ce08

5fe0: 00000000 2bbd1980 4652eda4 4652edb4 800f0010 00000017 003d90b8 00000000

[<80064498>] (audmux_read_file+0x60/0x2b4) from [<800f5788>] (vfs_read+0x9c/0x140)

[<800f5788>] (vfs_read+0x9c/0x140) from [<800f5864>] (sys_read+0x38/0x70)

[<800f5864>] (sys_read+0x38/0x70) from [<80041100>] (ret_fast_syscall+0x0/0x30)

Code: e5962000 e1a03185 e7925185 f57ff04f (e5962000)

---[ end trace 8dcc996f04add511 ]---

Also, is there a list (other than the directory listing) of what is in each image? For example:

Image Name	Description	Kernel Source / Headers	Feature 2	Feature 3
fsl-image-test	includes HW accelerated gstreamer plugins, some GPU sample applications, and some other test packages (like alsa-utils)	No
fsl-image-gui	includes HW accelerated gstreamer plugins, some GPU sample applications, and some other test packages (like alsa-utils) and HW accelerated X1	No
...	...

Thanks...

[LeonardoSandova]

Great to heard a happy Yocto user! Take a look at this documentation

http://freescale.github.io/doc/release-notes/1.5/index.html#document-index

Leo

[JohnCannizzo]

Hi Leo,

I've spent several hours looking through the documents you suggested, and many of the messages posted on the subject.  I was looking for a list of the available images for Yocto, but have not found a complete listing anywhere.  By "images", I mean (for example) fsl-image-gui, etc.  In the messages, I have found fsl-image-test, fsl-image-gui, fsl-image-gui-sdk, fsl-image-full, fsl-image-lsb-sdk.  However, notes on the project GitHub page indicate the fsl-image-gui-sdk image was removed two months ago.

While my personal need is an image with HW accelerated X11 and kernel headers, I'm sure that all developers would appreciate a list of all the images with the included features, description, etc.  Being able to get an image as close as possible to the actual need with a minimum of searching, and thus minimizing effort implementing features already there, is a huge time and money saver.

You (Freescale) have made a huge leap forward in switching to Yocto.  Thanks for your help...

John

[LeonardoSandova]

Check this Link from DaianeAngolini

https://community.freescale.com/docs/DOC-95421

Also this cmd

$ bitbake-layers show-recipes "*-image-*"

show all images which can be baked.  Some other useful bitbake cmds:

https://community.freescale.com/docs/DOC-94953

[JohnCannizzo]

Hi Leo,

Thanks for the link to Daiane's post, the bitbake command, and the bitbake command post.  Also, Chapter 9 in the Yocto "mega-manual" shows this list:

These recipes reside in the meta/recipes-core/images, meta/recipes-extended/images, meta/recipes-graphics/images, meta/recipes-qt/images, meta/recipes-rt/images, meta/recipes-sato/images, and meta-skeleton/recipes-multilib/images directories within the Source Directory. Although the recipe names are somewhat explanatory, here is a list that describes them:

• build-appliance-image: An example virtual machine that contains all the pieces required to run builds using the build system as well as the build system itself. You can boot and run the image using either the VMware Player or VMware Workstation. For more information on this image, see the Build Appliance page on the Yocto Project website.
• core-image-base: A console-only image that fully supports the target device hardware.
• core-image-minimal: A small image just capable of allowing a device to boot.
• core-image-minimal-dev: A core-image-minimal image suitable for development work using the host. The image includes headers and libraries you can use in a host development environment.
• core-image-minimal-initramfs: A core-image-minimal image that has the Minimal RAM-based Initial Root Filesystem (initramfs) as part of the kernel, which allows the system to find the first “init” program more efficiently.
• core-image-minimal-mtdutils: A core-image-minimal image that has support for the Minimal MTD Utilities, which let the user interact with the MTD subsystem in the kernel to perform operations on flash devices.
• core-image-basic: A console-only image with more full-featured Linux system functionality installed.
• core-image-lsb: An image that conforms to the Linux Standard Base (LSB) specification.
• core-image-lsb-dev: A core-image-lsb image that is suitable for development work using the host. The image includes headers and libraries you can use in a host development environment.
• core-image-lsb-sdk: A core-image-lsb that includes everything in meta-toolchain but also includes development headers and libraries to form a complete standalone SDK. This image is suitable for development using the target.
• core-image-clutter: An image with support for the Open GL-based toolkit Clutter, which enables development of rich and animated graphical user interfaces.
• core-image-gtk-directfb: An image that uses gtk+ over directfb instead of X11. In order to build, this image requires specific distro configuration that enables gtk over directfb.
• core-image-x11: A very basic X11 image with a terminal.
• qt4e-demo-image: An image that launches into the demo application for the embedded (not based on X11) version of Qt.
• core-image-rt: A core-image-minimal image plus a real-time test suite and tools appropriate for real-time use.
• core-image-rt-sdk: A core-image-rt image that includes everything in meta-toolchain. The image also includes development headers and libraries to form a complete stand-alone SDK and is suitable for development using the target.
• core-image-sato: An image with Sato support, a mobile environment and visual style that works well with mobile devices. The image supports X11 with a Sato theme and applications such as a terminal, editor, file manager, media player, and so forth.
• core-image-sato-dev: A core-image-sato image suitable for development using the host. The image includes libraries needed to build applications on the device itself, testing and profiling tools, and debug symbols. This image was formerly core-image-sdk.
• core-image-sato-sdk: A core-image-sato image that includes everything in meta-toolchain. The image also includes development headers and libraries to form a complete standalone SDK and is suitable for development using the target.
• core-image-multilib-example: An example image that includes a lib32 version of Bash into an otherwise standard sato image. The image assumes a "lib32" multilib has been enabled in the your configuration.

The bitbake command (bitbake-layers show-recipes "*-image-*") showed:

=== Available recipes matching *-image-*: ===

core-image-base:

  meta                 1.0

core-image-basic:

  meta                 1.0

core-image-clutter:

  meta                 1.0

core-image-directfb:

  meta                 unknown (skipped)

core-image-lsb:

  meta                 1.0

core-image-lsb-dev:

  meta                 1.0

core-image-lsb-sdk:

  meta                 1.0

core-image-minimal:

  meta                 1.0

core-image-minimal-dev:

  meta                 1.0

core-image-minimal-initramfs:

  meta                 1.0

core-image-minimal-mtdutils:

  meta                 1.0

core-image-rt:

  meta                 1.0

core-image-rt-sdk:

  meta                 1.0

core-image-sato:

  meta                 1.0

core-image-sato-dev:

  meta                 1.0

core-image-sato-sdk:

  meta                 1.0

core-image-weston:

  meta                 1.0

core-image-x11:

  meta                 1.0

fsl-image-gui:

  meta-fsl-demos       1.0

fsl-image-test:

  meta-fsl-demos       1.0

There are differences.  For example, Daiane's post shows an fsl-image-gui-sdk, but bitbake does not report the existence of that image.  I assume bitbake is the most current reference for what images are currently available, and (hopefully) uses the machine configured in local.conf to determine what images to report.  For example, since I need HW accelerated X11 with kernel headers for building my application on the target (iMX6Q Sabre SDB), since there is no fsl-image-gui-sdk, perhaps core-image-sato-sdk is a good starting point?

I hope having this information all in one place helps others...

Thanks again!

[daiane_angolini]

We decided to drop the *-sdk image from community repositories on newer releases.

Mainly because (here, I can only say for myself, not for community) it makes more sense to transform any desired image in a -sdk using commands on your local.conf than support a redundant image.

I understand that everyone wants a image list with a clear description of each one content. But, once you start to work on your stuff, you will for sure create your own image. The community images are only example.

And, I understand you want one complete list with all images all around the world, but, in fact, it does not make sense. Because each image is "hosted" in a different meta layer. For example, core-image-x11 is from poky, and fsl-image-test is from meta-fsl-demos. I tried to collect a list of "most used images" but, in fact, it´s virtually impossible to one person list all possible images around the would.

the main question, in my opinion, is "what do you want to accomplish/achieve"?

[JohnCannizzo]

Hi Daiane,

First, let me say that I am a huge fan of Yocto.  I've been using Freescale parts since Freescale became a company, and this is by far the best set of tools for creating OS images ever!  As I am new to Yocto, and haven't been through all the documentation yet, finding descriptions of pre-built recipes is helpful to early users who are trying to learn Yocto, or are trying a development board out from performance, power, etc. areas before deciding to move toward true product development.  From there, we realize (or should realize) we will need to make our own custom recipes for a final product.

In my particular case, I have an application (several 100K lines of legacy code) that has run on Freescale PowerPC parts for many years.  From a cost and power standpoint, the iMX6 is a much better option, IF the performance is there.  With a pre-production iMX6 and ltib (no hardware accelerators), I got the application running.  We now have a production Sabre SDB, and I was starting the ltib process again with newer libraries to take advantage of hardware acceleration.  It looked like a good time to switch to Yocto, and so far it has been great.  I need kernel headers to build my drivers on the target.  I will then run performance and power tests using our application, and present the results to management.  So in my case, and I'm sure many other people have similar circumstances, I'm looking for the quickest, easiest, lowest cost path to a "proof of concept" before devoting the time and cost into building custom recipes.  That's where having a variety of pre-built recipes can help.

I agree with you about it being an impossible task to document every .bb that exists around the world.  Your "Talking about images" was very helpful, but as I found, these recipes can change, and I now know how to look for existing recipes.  Leo has also been very helpful.  From a customer standpoint, it might be helpful if there were a set of pre-built recipes with descriptions supported by Freescale that customers could access for supported development boards, and I believe that may already exist.

Thanks to you and the entire Yocto team for all your hard work!

[daiane_angolini]

Hi John,

I agree with you, Leo is a very dear friend of mine! <3

It´s very important to me to understand "the customer´s mind". My workflow is completely different from a customer´s workflow. I must understand what is needed to you (and, for me is difficult to just imagine how you work).

I have plans to improve the available images from meta-fsl-demos. But, with bugs, support and docs, it´s been a low priority task. We just released dora and it was a huge work (it looks like every release is harder than the last one, this one I increased the test scope and I improved the Release Notes) But I was thinking about split the huge images into smaller and more focused one.

What image do you feel is missing?

And, do you really use native build? Or it´s only during period of time, just for the proof of concept period?

Oh, I almost forgot! I´ve been working with yocto release/meta-fsl-arm since end of 2011. And you are the first person that say nice words about yocto (at least, the first one I hear/know). So, thanks a lot for your time and your attention to let us know that, for you, yocto has been good.

[JohnCannizzo]

Hi Daiane,

Yes, Leo has been great!  I understand supporting multiple recipes is difficult, and takes away from the real development of Yocto.  I can't speak for all customers, but for me, having larger, more feature complete recipes help demonstrate the processor's capabilities and make it easy to build an application for a proof-of-concept phase.  You probably need those type of images for sales people to demonstrate anyway.  The down side is the time required to bitbake those larger recipes.  I haven't found it to be a problem.  I simply wait until I'm ready to quit for the day, and then start the bitbake.  In the morning, it's ready to go.

Smaller, more focused recipes would be helpful when a project is approved, and a developer is ready to begin working on a product.  For us, Flash memory is fairly low cost, so if we have a few libraries that are not needed, it's not a problem.  We will probably start with the closest matching recipe, and then build from there.  Once the initial bitbake is done, changes seem to bitbake fairly quickly.

So far, the list of available recipes looks good.  The build-appliance and core-image-minimal recipes should work for those who only want the minimal configuration upon which they can build what they want without extra overhead.  These will probably bitbake much faster as well.  I personally will try the core-image-rt and core-image-rt-sdk as soon as possible, since I'm not concerned with Qt.  I agree with the need for the core-image-sato recipes, and with the fsl-image recipes.

You asked about me developing on the target.  I wish I could develop on a PC, but I don't yet for a few reasons.  The last time I tried this on the pre-production iMX6, the cross-compiler didn't exist yet, and even neon support was buggy.  Our application uses old MAKE files that are generated dynamically by a root MAKE, and proceeds several levels deep.  It is a maintenance nightmare!  The drivers require kernel headers, but the MAKE gets confused when building on the PC, and grabs the PC kernel headers.  Now that the cross-complier is available, I'll try to justify the time to convert.  I even started converting to an Eclipse-based build, but it's a very low priority task.  At the very least, I should be able to build most of the application on the PC, and only build the drivers on the target.

Thanks again!

[daiane_angolini]

Thanks John!

[LeonardoSandova]

John,

create an image like this

https://github.com/Freescale/meta-fsl-demos/commit/87233da97fe0ead245773e092acb56faa24f3835

and bake that one.

Leo

[JohnCannizzo]

Hi Leo,

I saved the fsl-image-gui-sdk.bb file locally, and with a new build directory, tried to bitbake it.  That didn't do so well.  As you know, I'm new to Yocto.  So, I decided to bitbake the fsl-image-gui recipe, since it is an include in fsl-image-gui-sdk anyway, and then bitbake fsl-image-gui-sdk.bb.  I did that, using bitbake -b fsl-image-gui-sdk.bb, but received the following:

jc3@jc3-vgn:~/build$ bitbake -b fsl-image-gui-sdk.bb

WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.

Build Configuration:

BB_VERSION        = "1.20.0"

BUILD_SYS         = "i686-linux"

NATIVELSBSTRING   = "Ubuntu-12.04"

TARGET_SYS        = "arm-poky-linux-gnueabi"

MACHINE           = "imx6qsabresd"

DISTRO            = "poky"

DISTRO_VERSION    = "1.5"

TUNE_FEATURES     = "armv7a vfp neon callconvention-hard cortexa9"

TARGET_FPU        = "vfp-neon"

meta             

meta-yocto        = "(nobranch):75bed4086eb83f1d24c31392f3dd54aa5c3679b1"

meta-oe           = "(nobranch):513e7ca20ddd0a5c3b649bf292a67c3e0473d3a8"

meta-fsl-arm      = "(nobranch):3251a7dddde3c00370fb9b10573754e65ed51e6b"

meta-fsl-arm-extra = "(nobranch):6631fbd43c8c597757fe1e27f81a0194c2cc527a"

meta-fsl-demos    = "(nobranch):cd6275042cdd2d87490521f6cbeb65972ed37a66"

NOTE: Preparing runqueue

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

ERROR: Function failed: do_rootfs (log file is located at /home/jc3/build/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui-sdk/1.0-r0/temp/log.do_rootfs.13475)

ERROR: Logfile of failure stored in: /home/jc3/build/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui-sdk/1.0-r0/temp/log.do_rootfs.13475

Log data follows:

| DEBUG: Executing python function rootfs_process_ignore

| DEBUG: Python function rootfs_process_ignore finished

| DEBUG: Executing python function rootfs_runtime_mapping

| DEBUG: Python function rootfs_runtime_mapping finished

| DEBUG: Executing shell function do_rootfs

| Note: configuring RPM platform settings

| Note: configuring RPM system provides

| Note: configuring RPM DB settings

| Note: configuring Smart settings

|

|

|

|

|

|

| Note: adding Smart channel imx6qsabresd (65)

|

|

| Note: adding Smart channel cortexa9hf_vfp_neon_mx6 (60)

|

|

| Note: adding Smart channel cortexa9hf_vfp_neon (55)

|

|

| Note: adding Smart channel all (10)

|

|

| Note: configuring RPM cross-install scriptlet_wrapper

|

| Updating cache...               ######################################## [100%]

|

| Saving cache...

|

| Error: packagegroup-core-sdk not found in the base feeds (imx6qsabresd cortexa9hf-vfp-neon-mx6 cortexa9hf-vfp-neon cortexa9hf-vfp armv7ahf-vfp-neon armv7ahf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all).

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_rootfs (log file is located at /home/jc3/build/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui-sdk/1.0-r0/temp/log.do_rootfs.13475)

ERROR: Task 7 (/home/jc3/build/fsl-image-gui-sdk.bb, do_rootfs) failed with exit code '1'

NOTE: Tasks Summary: Attempted 13 tasks of which 11 didn't need to be rerun and 1 failed.

No currently running tasks (12 of 14)

Summary: 1 task failed:

  /home/jc3/build/fsl-image-gui-sdk.bb, do_rootfs

Summary: There was 1 WARNING message shown.

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

jc3@jc3-vgn:~/build$

As I said, it's early in my Yocto learning curve, and I can already see it is a huge improvement over ltib.  Perhaps there is a better way for me to get the kernel headers into an image than the bitbake -b switch?  As bitbake reports when you use the -b option, it will not resolve dependencies when using -b.  I've not tried to create a custom recipe yet, but that is the inevitable path all of us must take when creating our final product.  There is a lot of documentation, and I'm still trying to get through it.

Pointers would of course be helpful, but I know I need to digest all the documentation to really learn everything Yocto offers and how to get the most out of it.  Most of use using Freescale parts are new to Yocto, so I'm hoping documenting my learning curve here will help others who might be going through the same learning curve.

Thanks...

[LeonardoSandova · Accepted solution]

John, You can create a layer like this

meta-lsandoval/meta-fsl-custom at master · lsandoval/meta-lsandoval · GitHub

To bake an image, drop the -b and the .bb extension, so it would be

$ bitbake fsl-image-gui-sdk

[JohnCannizzo]

Hi Leo,

Worked great, thanks.

I have a question about the kernel header files.  I created the fsl-image-gui-sdk image, and most of the header files are in /usr/include/linux except module.h.  kernel.h is there as expected.  I was going to manually copy module.h to the target, but I'm not sure which I should copy from the kernel build directories:

build/tmp/sysroots/imx6qsabresd/usr/src/kernel/arch/arm/include/asm/module.h  -- or --

/build/tmp/sysroots/imx6qsabresd/usr/src/kernel/include/linux/module.h  -- or -- ???

I'm guessing the later, but thought I would both notify Freescale that module.h file didn't make it into the image, and document this for others...

Thanks again!

[OtavioSalvador]

JohnCannizzo, what are you intending to do? it was not clear from your message.

Do you want to build a module, in target?

[JohnCannizzo]

Hi Otavio,

I was building a driver on the target.  This worked on the pre-production iMX6 silicon using LTIB, and this was my first attempt using Yocto.  Some of the driver-related files weren't put in the image, while some were in the image but not in the same directory as the LTIB-created image.  Rather than do this file-by-file, I'd like to make a list of the kernel header files my application requires and determine if the files are missing from the image, are in the image but in a new directory, or where my application expected them.  My application has required modifications over many kernel versions, and I want to insure my application isn't at fault.

Thank you for looking into this.  It may take a few weeks to respond with more detail, as I have been pulled into testing OpenCV performance on the iMX6 (different part of the same project / product).

Thanks,

John

[OtavioSalvador]

When you need my support, please contact me.    

[LeonardoSandova]

John, I am not sure why that header was not installed. OtavioSalvador any idea?

[JohnCannizzo]

Thanks Leo, I've bookmarked it.  I'm looking for a way to get kernel headers in the image.  I'll review the documentation to see if it's mentioned.

Again, great job!