How to Test Yocto for i.MX6

[#1]

Join FSL-community-bsp project: https://lists.yoctoproject.org/listinfo/meta-freescale

In order to test Yocto Project for i.MX6 or any other supported board please follow the instructions pointed by FSL Community BSP.

In order to download the source code, please follow this instructions FSL Community BSP.

With the downloaded source code, you can follow the steps from this training: Yocto Training - HOME

If you face a problem, please, send an email to https://lists.yoctoproject.org/listinfo/meta-freescale

This page made sense when there was not other tutorial to point people on how to download and build the very first image using Yocto Project tools for i.MX family boards. Today, FSL Community BSP has become a complete environment with its own landing page (FSL Community BSP) and a collaborative community around meta-freescale mailing list. I encourage you to register in meta-freescale mailing list.

I configured this document to be closed for new comments. In case of any issue or bug, please, send an email to meta-freescale.

[OtavioSalvador]

The splash customization can be done in different parts of the system; in O.S. Systems' Yocto BSP we do it in U-Boot and PSplash.

For PSplash you look at

poky - Poky Build Tool and Metadata

[jcpep]

Hi Otavio,

How can I use PSplash to have my own logo on splash screen? I read a few things about adding my own layer, but I didn't find any clear and complete guide about this. I tried adding my own layer anyway, but I can't build anything.

[OtavioSalvador]

You need to have the bbappend and generate the image (and convert it to .h file). Check the source code, it is all there.

[teddyzhang]

hi, daiane,

     I'm trying to build test image "bitbake fsl-image-test" for sabrelite board and get error message of fetching sourcecode packages like below: (I tried them times and always fail out on them)

/workspace/software/repository/freescale/yocto_rootfs/sources/meta-openembedded/meta-oe/recipes-benchmark/lmbench/lmbench_3.0-a9.bb, do_fetch

  /workspace/software/repository/freescale/yocto_rootfs/sources/meta-openembedded/meta-oe/recipes-benchmark/tiobench/tiobench_0.3.3.bb, do_fetch

[leoschwab]

This post probably deserves its own topic, but this was where I started on this journey, so here it is:

I have successfully built and booted an 'imx6dlsabresd' image using these instructions (on Linux Mint 15, BTW), and now I need to start "designing" the build environment that everyone else will be using for our project. Trouble is, Yocto seems to resist attempts at understanding its structure and how to integrate with it. Documentation fragments are spread over a number of sources, and there are many seeming contradictions.

For example, when following the Yocto Project instructions on creating a new BSP layer (using the yocto-bsp command), the resulting files look nothing like what's already present in the meta-fsl* directories. Further, when yocto-bsp asks me what kernel I want to use, 3.0.35 is not one of the presented options, suggesting that the FSL material is somehow not visible to the standard tools.

And then there's this page, which suggests a full BSP layer is not necessary, and I can get away with a generic layer.

In short, what seems to be eluding me is the Yocto "philosophy" -- how to know when to add/delete stuff by creating a new BSP layer, a new generic layer, a .bbappend file, or by modifying IMAGE_INSTALL_append (or EXTRA_IMAGE_FEATURES).  I'm not even sure if what I'm trying to define constitutes a "BSP," a "machine," or a "distro."

Ultimately, what I want to have is a well-defined pile of Our Stuff(TM), which is easily used with, but kept separate from, the Community stuff (so that everything can be cleanly pulled down via a 'repo' manifest). Pointers to philosophical tracts and/or working examples would be especially welcome.

[LeonardoSandova]

Hi Leo,

You raised a interesting topic. I have been involved for several months into the Yocto Framework, and I can understand the confusion you have. The easy answer would be 'it depends what you want to do', but of course this does not help at all. What I have been documenting is the minimal way to create a layer using the tool yocto-layer, which is much simpler that yocto-bsp. Both server for different purposes but at the end yocto-bsp will create a layer with many more stuff already configured for you (although I have not tried that tool, but I will soon).

The main question is, what are you trying to do? As mentioned in the tutorial, creating a layer is recommended if

* you want to modify a recipe (.bbappend)

* you want to create a recipe (.bb)

* you want to create a new image. IMAGE_INSTALL_append and EXTRA_IMAGE_FEATURES are ways to add packages to images and you can use them on the current images, but it is much better to create a layer, then do all modifications there. Just make sure your new image name is different as the existing ones.

In case you want to create a new Freescale based machine and you do not want to use the same layer as the rest (meta-fsl-arm-extra), you can create your own. At some point, you would like to expose your work to the world, and all your work will fit easily on this layer. In the other hand, meta-fsl-arm-extra is an excellent example on how the coupling is done with meta-fsl-arm.

For the repo script, there is way to indicate using a local default.xml, so you can add your git repo there.

I will post more slides soon. Good luck!

Leo

[leoschwab]

I'm still formulating a proper response to your very thoughtful post.  However, yesterday I discovered the docs for Poky, on which Open Embedded, Yocto, and FSL Community are built.  For some odd reason, the Poky docs are making much more sense to me; maybe they'll help others as well.

Poky Handbook

As an example, supplying the argument '-DDD' to bitbake generates a massive amount of debug information which, believe it or not, brought me infinitesimally closer to understanding how the thing works, mostly by following the messages related to providers.

[daiane_angolini]

I´m glad you´ve been able to understand yocto. The learning curve is not that easy. But I´m sure you´ll like it at the end.

leoschwab, keep in mind that Poky handbook is "out of date". It´s from 2010, and any "current" documentation is now under yoctoproject.org

[leoschwab]

Daiane Angolini wrote:

Leo Schwab, keep in mind that Poky handbook is "out of date".  [ ... ]

Yes, I'm starting to notice that -- specific examples in the Poky doc don't correspond to what's in the tree I have, and it looks like several things got renamed.  But the Yocto docs are irritatingly guilty of this as well, and do a much poorer job (to my eyes) of explaining the underlying concepts.  So I'm still reading the Poky doc to better get at the concepts Bitbake is trying to embody, and then revert to the Yocto docs when I want to know something specific.

Right now, we're using a SABRE-SD board to get started, and will be prototyping applications on it.  However, the final HW will be significantly different (no display, for example).  So I'm of the belief that I'll need:

• Build and development environment for SABRE board,
• Build and development environment for final board,
• Possible emulated environment for app developers, since boards will be scarce initially (it's possible they could get away with developing on a generic PC, since Linux apps should be (*cough*) just a recompile to ARM),
• A distinct tree to place our mods to the Community config (assuming they can't live in the same place as:)
• A distinct tree to place our apps.

Did I mention I'm new at being a buildmeister :-) ?

[teddyzhang]

teddyzhang 2013-7-8 上午12:55

hi, daiane,

     I'm trying to build test image "bitbake fsl-image-test" for sabrelite board and get error message of fetching sourcecode packages like below: (I tried them times and always fail out on them)

/workspace/software/repository/freescale/yocto_rootfs/sources/meta-openembedded/meta-oe/recipes-benchmark/lmbench/lmbench_3.0-a9.bb, do_fetch

  /workspace/software/repository/freescale/yocto_rootfs/sources/meta-openembedded/meta-oe/recipes-benchmark/tiobench/tiobench_0.3.3.bb, do_fetch

the answer for myself as below:

1. Set http_prxoy,ftp_proxy....to do the fetch. Or...

2. Look up into the reference manual to get the items "how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server". Or...

3. Download the packages yourself and put them on $POKY/downloads/ and then touch $(PackageName).done to workaround.

[daiane_angolini]

Hi leoschwab

I agree! I don't like yocto reference manual either! I think it's too complex and too deep.

I think your plan is great! If you feel like, you may upstream your board or some of your apps, if you think it can be public. Otherwise, I would create one BSP layer (with pieces used by your board that makes it alive, the board support package), and one APP layer (with your applications recipes and any image customization)

What is "buildmeister"? I was not able to find a definition for it, but I figured out there are lots of apps :smileysilly:

[daiane_angolini]

Hi teddyzhang,

I'm not sure if lmbench and tiobench are still available at that versions/repositories. If they are not needed to your test, please go to

https://github.com/Freescale/meta-fsl-demos/blob/master/recipes-fsl/packagegroup/packagegroup-fsl.bb

and remove lines: 75, 82

then you can build your image until the end

[Joerg-SH]

Meister is a German word, like master Diane :smileywink:

[daiane_angolini]

oh! :smileygrin: thanks :smileywink:

[teddyzhang]

thank you，I've got it.

[pavanpatil]

Hi Otavio,

I am working on the imx6q_sabrelite board and building the fsl-image-gui image using freescale yocto project source code.I want to exclude some of the recipe from available fsl-image-gui image.i am using the bitbake for creation of the image.how can i exclude the recipe of particular packages?can i do the changes in existing layer?

I tried to exclude recipe using hob, my package compilation is successful but after my that while building image hob is giving me following error...

Hob Exception - Error running command '['matchFile', 'hob-image.bb']': Traceback (most recent call last):

  File "/home/pavan/fsl-community-bsp/sources/poky/bitbake/lib/bb/command.py", line 68, in runCommand

    result = command_method(self, commandline)

  File "/home/pavan/fsl-community-bsp/sources/poky/bitbake/lib/bb/command.py", line 210, in matchFile

    return command.cooker.matchFile(fMatch)

  File "/home/pavan/fsl-community-bsp/sources/poky/bitbake/lib/bb/cooker.py", line 1142, in matchFile

    raise NoSpecificMatch

NoSpecificMatch

this was my first build using yocto and its workflow is quite difficult to understand?

Thanks

[OtavioSalvador]

I'd make a layer for your project / company and write a new image recipe there. This allow for easy maintenance and avoid the need of forking.

I didn't try HOB so I cannot help here.

Yes; the workflow is a little difficult to understand but you'll get used to it ;-)

[Joerg-SH]

I want to build a Image with openssh and not with dropbear. That seams nearly impossible !?

[OtavioSalvador]

Sure it is possible, and it is even easy. All you must to do is to read the right documentation :smileywink:

http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#usingpoky-extend-customimage-i...

I think this will gonna help you :smileywink:

[Joerg-SH]

Ok it works to add open ssh.

I did not know thats dropbear is automatic removed from the image. Or are there differences between the branches. I used dylan for my last builds. not shure what i used before. I could see via hob that all images set to open ssh when it is set via extraimagefeature in local.config

[Joerg-SH]

by the way. Is some working on machine layer for the new mars board? i ordered 2 pices :smileywink:

[OtavioSalvador]

Not that I am aware of; please push them to add support to Yocto and put them in contact with me if they need help or consultancy for it.

[Joerg-SH]

I have no contact to embest. MarS Board thats the Board, looks nice :smileyhappy:

[Joerg-SH]

If wrote to them, I hope they will do.

[leoschwab]

Okay, I've got a concrete problem for ya :-) ...

I've sorta-kinda worked out a way to specify image recipes, involving the following:

• Create a new generic layer (which here I'll call meta-belis3) using yocto-layer,
• Create a machine configuration by making a copy of imx6dlsabresd.conf into meta-belis3/conf/machine/belis3.conf. I also removed 'bluetooth' from MACHINE_FEATURES ('cause our machine won't have it).
• Create the directories meta-belis3/recipes-core/images in my layer, and copy core-image-minimal.bb into it as fiat-lux.bb.
• Edit fiat-lux.bb to add "python" to IMAGE_INSTALL.
• Inside the build directory, add the layer meta-belis3 to conf/bblayers.conf; and change conf/local.conf's MACHINE to 'belis3'.
  

So far, so what -- 'bitbake fiat-lux' gets me a build with python in it.

So the next thing I wanted to do was add the Dropbear SSH server.  So, inside meta-belis3/recipes-core/images/fiat-lux.bb, I added:

IMAGE_FEATURES = "ssh-server-dropbear"

Re-run bitbake, and indeed dropbear gets added to the image.  However, I can no longer login -- something prints an error message about the shadow password being mismatched (or something).

"Hmm," thinks I, "I guess dropbear has an undocumented dependency on 'shadow'," so inside fiat-lux.bb, I added 'shadow' to IMAGE_INSTALL.  'shadow' indeed gets added, but I still can't login, this time with no error message.

I unpacked the tar.bz2 image file, and found that /etc/shadow shows root with an empty password; but /etc/passwd shows root with a password field of '*'.

If I rebuild the image without dropbear, but leave shadow in, then I can login fine -- /etc/shadow has an empty password, and /etc/passwd shows a password field of 'x'.

So....  What's the deal?

[OtavioSalvador]

Hello Leo,

I think you're missing "debug-tweaks" in IMAGE_FEATURES.

Check if it does fix your problem.

Regards

[leoschwab]

OtavioSalvador wrote:

I think you're missing "debug-tweaks" in IMAGE_FEATURES.

Check if it does fix your problem.

That worked!  (Would be nice to know why.)  Thank you kindly!

[OtavioSalvador]

You can check Yocto manual about the available features.

Regards,

[leoschwab]

THIS:

https://www.yoctoproject.org/tools-resources/presentations/working-kernel

A step-by-step walkthrough of setting up layers and custom config options for a kernel, going from zero to BSP in less than 40 pages.  It's proving to be a big help so far...

[jcpep]

Hello,

I am working on a fsl-image-test Yocto image built with dylan sources. I would like to disable the splash screen appearing at boot (with the Yocto logo and the progress bar), but browsing the web didn't give me any answer?

How could I do it ?

Regards

[OtavioSalvador]

You just need to drop 'splash' from IMAGE_FEATURE.    

[leoschwab]

I think I'm seeing part of the problem.  Near as I can tell (and feel free to beat me about the head and shoulders with polite corrections), the docs over at the Yocto project reflect the most current version and features of the Yocto system.  However, it appears the FSL layers were created using an earlier version of Yocto.

As such, if you were to attempt to modify the config of the linux-imx kernel by, for example, creating a linux-imx_3.0.35.bbappend file and put inside it a line reading, "SRC_URI += "file://enable-pcie.cfg" to pick up a configuration fragment, you might spend a day poring over bitbake debug logs wondering why Yocto was ignoring you.  And you might ultimately discover that the .bb and .bbappend files in the FSL layers look almost, but not entirely, unlike what the current Yocto docs describe.

And then, depressedly Googling for solutions, you might happen upon fragment of a thread in a mailing list which hinted in the most oblique way that the "kernel config file fragment" feature was new to Yocto 1.4, causing you to wonder to yourself, "Self, I wonder if the FSL recipes were put together using an earlier syntax?"  Whereupon you'd copy-paste one of the .bbappend files under the FSL layers and have it specify a complete defconfig using the syntax, "SRC_URI_append_defconfig = " file://defconfig".

...And then the kernel finally built the way you wanted.

Does this sound vaguely plausible?  Or am I overthinking things again?

[OtavioSalvador]

Hello Leo,

More or less. In fact I plan in future to move to linux-yocto system but currently it is too hard to make it. Freescale kernels are old (2.6.35.3 and 3.0.35) and it is difficult to share work with linux-yocto at this moment. So we opted to use a simpler recipe for now.

Nothing force people to use linux-yocto or not so it is a decision, not something related to being outdated or not.

Regards,

[Joerg-SH]

MarS Boards are here, looks nice a function is pretty :smileywink: Now I need Yocto support for it :smileywink:

The support of embest didn't answers.

[OtavioSalvador]

Good luck! :-)

[Joerg-SH]

What I have to read to learn to build my own machine layer?

[LeonardoSandova]

I have made a really short intro to Yocto: i.MX Yocto: Freescale Yocto Project Tutorial

For your specific question, as a starting point take a look here: presentations/yocto/layer.md at master · lsandoval/presentations · GitHub

[Joerg-SH]

I could not open the pdf

  yocto_tutorial.pdf (264.3 K)  IN DER WARTESCHLANGE  

[LeonardoSandova]

Yes, I am seeing the same message (but in english), I am looking into that issue. You can create the whole pdf, just follow these instructions: lsandoval/presentations · GitHub

Leo

[Joerg-SH]

make brakes with errors

joerg@Ubuntu-ws:~/presentations$ make

make -C tools

make[1]: Entering directory `/home/joerg/presentations/tools'

make -C bash

make[2]: Entering directory `/home/joerg/presentations/tools/bash'

make[2]: Nothing to be done for `all'.

make[2]: Leaving directory `/home/joerg/presentations/tools/bash'

make -C git

make[2]: Entering directory `/home/joerg/presentations/tools/git'

pandoc --offline -s -t slidy -o basics.html basics.md

pandoc: --offline is deprecated. Use --self-contained instead.

pandoc: user error (https not supported)

make[2]: *** [basics.html] Error 1

make[2]: Leaving directory `/home/joerg/presentations/tools/git'

make[1]: *** [git] Error 2

make[1]: Leaving directory `/home/joerg/presentations/tools'

make: *** [tools] Error 2

[pavanpatil]

HI All,

how do i exclude the any package recipe from existing meta-openembedded layer or any other layers without using hob?I am facing issue with hob.

i want to remove fio recipe from ~/sources/meta-openembedded/meta-oe/recipe-benchmark/fio the yocto source code?

[LeonardoSandova]

Sorry Joerg. I have fixed some makefile issues. Please 'git pull' and 'make -f makefile_pdf'. The output file should be on yocto/yocto_tutorial.pdf.

Leo

[LeonardoSandova]

Remove the fio string on ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb and bake again.

Leo

[Joerg-SH]

ok thanks, thats works

Joerg

[pavanpatil]

thanx Leo..it works..

Pavan

[OtavioSalvador]

Changing the recipe is not the best alternative; the best way is you to create an image specific for your needs and add the packages you need.

[leoschwab]

OtavioSalvador wrote:

Changing the recipe is not the best alternative; the best way is you to create an image specific for your needs and add the packages you need.

Which brings us back to my earlier lament about Yocto being about as clear and intelligible as the Voynich Manuscript.  "Obviously" you would want to create your own layer and image recipe(s).  What's not at all obvious is how to do that.  It's taken me over three weeks of constantly staring at this gobbledegook to achieve even basic competence.  I2C devices?  SPI devices?  Setting up an Agilent logic analyzer?  Pfah! the work of merest trivia.  But this Yocto stuff is just line noise...

...Blergh.  That having been said:

In my case, I'm setting up a layer for our board.  Right now it targets the SABRE-SD board, but will evolve to cover our Shiny New Thing(TM).  To that end, I created a new layer using the command 'yocto-layer create <layer_name>'.  It will ask you a series of questions; the defaults are probably okay.  This command just creates a layer directory; it makes no other changes to your environment (so if you mess it up, you can just delete the directory and start over).  When the command completes, you will have a layer directory that contains nothing but scaffolding (i.e. it doesn't do anything yet).

At this point, you're pretty much resigned to copy-pasting other files from the Yocto distribution into your new layer and modifying them.  In my case, I copied the recipe for the core-image-minimal target into my layer and started hacking on it.  Assuming your new layer is named meta-belis3:

mkdir -p sources/meta-belis3/recipes-core/images

cp sources/poky/meta/recipes-core/images/core-image-minimal.bb sources/meta-belis3/recipes-core/images/foobar.bb

At this point, load the newly copied foobar.bb into your favorite editor and start hacking on it.  Almost certainly you'll be adding packages to the IMAGE_INSTALL variable.

Once you're ready to try something, go into your build directory.  Edit the conf/bblayers.conf file to include your newly-created layer, along these lines:

BBLAYERS = " \

${BSPDIR}/sources/poky/meta \

[ ...blah, blah, blah... ]

${BSPDIR}/sources/meta-fsl-demos \

${BSPDIR}/sources/meta-belis3 \  # <-- Your new layer appended here.

"

Now the bitbake tool can see your new layer.  Now tell bitbake to process your new build recipe:

$ bitbake foobar

At this point, something will happen.  If you're very lucky, it will be what you wanted to happen.

Wish I could offer deeper, more meaningful insight, but this is about as much understanding as I've managed to acquire so far.

[OtavioSalvador]

Hello Leo,

This is the right process; I don't use yocto-bsp tool and make the files by hand but this is the general process.

The good thing is after you have your layer it is trivial to keep it update and include new stuff.

I understand Yocto is confusing to start with but it is pleasant to work once you get used to it. I often do custom BSPs for customers and the layer system, even looking confusing at the beginning, is what allow us to support a huge number of customers with a very small team.

Regards,

[daiane_angolini]

The special thing about Yocto is that everyone hates it so much! (Otavio, please, don´t read this :smileysilly:)

I can say I hated it from the deep of my heart for about 6 months until I start to "accept" it.

Now, (after one year and a half and 2 imx releases) I can say I almost understand it. I almost like it.

[OtavioSalvador]

Ok DaianeAngolini... I must agree with you :-)