i.MX6QSabreSD board Yocto local source/build

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6QSabreSD board Yocto local source/build

Jump to solution
3,563 Views
zhencongtee
Contributor III

Greetings.

I am new to Yocto, and has been trying hard to understand the underlying concept of the Yocto's bitbaking process and repository structure.

As far as my understanding, for the first time we do a repo sync, then bitbake, it will download the recipes from the repo, and put it in <local folder>/sources.

Then, when baking in process, the actual source code of the components (u-boot, kernel, OS etc.) will be downloaded and put into <local folder>/build/tmp/work/<bsp>/...

Hopefully so far my understanding is still correct.

Ok now the part that confused me come.

I tried to change simple things (add in a line of puts(hello) at the starts) in the u-boot source code inside the <local folder>/build/tmp/work/<bsp>/... folder, and then i did a bitbake -c compile u-boot-imx, and then bitbake u-boot-imx. Then i dd the u-boot image into my SD card and run it on the EVK. My changes applied! The "hello" is printed out when the u-boot runs.

Isn't it the <local folder>/build/tmp/work/<bsp> directory supposed to be the source code downloaded from repo? The recipes in the <local folder>/sources directory points the SRC_URI to a git location. Why does the bitbake not fetching the source code from the git directory, instead it uses the local copy that i make changes in the <local folder>/build/tmp/work/... directory?

Please help. Thank you.

Regards,

ZC

Labels (3)
0 Kudos
1 Solution
2,176 Views
daiane_angolini
NXP Employee
NXP Employee

I would say this is the second pitfall (the first one is fetch problem due to network config)

As far as my understanding, for the first time we do a repo sync, then bitbake, it will download the recipes from the repo, and put it in <local folder>/sources.

The source code downloaded into <local folder>/sources is meta-data. It is the Yocto Project (YP) source code. A bunch of recipes/classes from a lot of different git repositories (see manifest.xml) like poky, meta-openembedded, meta-fsl-arm and so on.

This is the source code when you talk about Yocto Project.

Then, when baking in process, the actual source code of the components (u-boot, kernel, OS etc.) will be downloaded and put into <local folder>/build/tmp/work/<bsp>/...

Before that, a copy of any package source code is placed under downloads folder (your should be <local folder>/download or /opt/freescale/download. This folder is pointed by DL_DIR variable)

When you start a bitbake, bitbake will perform a list of tasks. You can think that the first one it fetch, then you have unpack, and then you have all the other (like patch, configure, complie, ...)

http://www.yoctoproject.org/docs/1.6/bitbake-user-manual

fetch -> downloads folder

unpack -> build/tmp/work/

The important concept you need to understand now it that build/tmp folder is temporary and it is supposed to be used by BitBake and for debug purposes.

You will NOT base your development in this folder.

Hopefully so far my understanding is still correct.

Ok now the part that confused me come.

I tried to change simple things (add in a line of puts(hello) at the starts) in the u-boot source code inside the <local folder>/build/tmp/work/<bsp>/... folder, and then i did a bitbake -c compile u-boot-imx, and then bitbake u-boot-imx. Then i dd the u-boot image into my SD card and run it on the EVK. My changes applied! The "hello" is printed out when the u-boot runs.

BitBake only do_fetch a package in case the previous download is crashed. Otherwise the do_fetch is skipped.

And, the same for do_unpack.

For example, if you change the u-boot source code under build/tmp, and run bitbake -c compile u-boot-imx you are only recompiling, nothing else will be re-done (like configure, for example)

and yes, u-boot.bin is placed in some directory under build/tmp/ but it´s not deployed to tmp/deploy/images/<MACHINE>

So, you can play around with tmp/work source code, but please DO NOT rely your development in that folder!

Isn't it the <local folder>/build/tmp/work/<bsp> directory supposed to be the source code downloaded from repo?

No, it´s only a temporary copy of source code and, depending on your Yocto Project configuration, you may not have it after a BitBake

The recipes in the <local folder>/sources directory points the SRC_URI to a git location. Why does the bitbake not fetching the source code from the git directory, instead it uses the local copy that i make changes in the <local folder>/build/tmp/work/... directory?

Using the local copy under build/tmp/work is a collateral effect and it does not work for every single case.

For package/kernel/u-boot development you should use the traditional toolchain + iterative source code changes you are used to. You can use Yocto Project to tailor your SDK with the toolchain, but if you prefer you can use any other compatible one.

After you have a "release" of your package/kernel/u-boot you include a recipe to it, and then you start to tailor your production image which is the image you will build for your product/goal.

View solution in original post

0 Kudos
4 Replies
2,176 Views
chennurupushpat
Contributor I

HI,

           I was trying to build yacto for Riot board. when i gave bit-bake  command my build  was failed because of this error .

pleas any one can guide me regarding of this error

WARNING: Failed to fetch URL http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/fsl-gpu-sdk-1.1.bin/libfslcodec-3.0.11.bin;fsl-eula=t..., attempting MIRRORS if available

ERROR: Fetcher failure: Fetch command failed with exit code 8, output:

http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/fsl-gpu-sdk-1.1.bin/libfslcodec-3.0.11.bin:

2014-08-05 15:18:07 ERROR 404: Not Found.

ERROR: Function failed: Fetcher failure for URL: 'http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/fsl-gpu-sdk-1.1.bin/libfslcodec-3.0.11.bin;fsl-eula=t...'. Unable to fetch URL from any source.

ERROR: Logfile of failure stored in: /home/teju/fsl-arm-yocto-bsp/build/tmp/work/riotboard-poky-linux-gnueabi/libfslcodec/3.0.11-r0/temp/log.do_fetch.18930

ERROR: Task 1615 (/home/teju/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-multimedia/libfslcodec/libfslcodec_3.0.11.bb, do_fetch) failed with exit code '1'

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

Waiting for 0 running tasks to finish:

Summary: 1 task failed:

  /home/teju/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-multimedia/libfslcodec/libfslcodec_3.0.11.bb, do_fetch

Summary: There was 1 WARNING message shown.

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

0 Kudos
2,176 Views
daiane_angolini
NXP Employee
NXP Employee

As I know Riot does not have suport added on any public yocto layer.

Please, contact the person who provided you the instructions to download the source code.

(or double check your SRC_URI from your recipe, because the URL is wrong)

0 Kudos
2,177 Views
daiane_angolini
NXP Employee
NXP Employee

I would say this is the second pitfall (the first one is fetch problem due to network config)

As far as my understanding, for the first time we do a repo sync, then bitbake, it will download the recipes from the repo, and put it in <local folder>/sources.

The source code downloaded into <local folder>/sources is meta-data. It is the Yocto Project (YP) source code. A bunch of recipes/classes from a lot of different git repositories (see manifest.xml) like poky, meta-openembedded, meta-fsl-arm and so on.

This is the source code when you talk about Yocto Project.

Then, when baking in process, the actual source code of the components (u-boot, kernel, OS etc.) will be downloaded and put into <local folder>/build/tmp/work/<bsp>/...

Before that, a copy of any package source code is placed under downloads folder (your should be <local folder>/download or /opt/freescale/download. This folder is pointed by DL_DIR variable)

When you start a bitbake, bitbake will perform a list of tasks. You can think that the first one it fetch, then you have unpack, and then you have all the other (like patch, configure, complie, ...)

http://www.yoctoproject.org/docs/1.6/bitbake-user-manual

fetch -> downloads folder

unpack -> build/tmp/work/

The important concept you need to understand now it that build/tmp folder is temporary and it is supposed to be used by BitBake and for debug purposes.

You will NOT base your development in this folder.

Hopefully so far my understanding is still correct.

Ok now the part that confused me come.

I tried to change simple things (add in a line of puts(hello) at the starts) in the u-boot source code inside the <local folder>/build/tmp/work/<bsp>/... folder, and then i did a bitbake -c compile u-boot-imx, and then bitbake u-boot-imx. Then i dd the u-boot image into my SD card and run it on the EVK. My changes applied! The "hello" is printed out when the u-boot runs.

BitBake only do_fetch a package in case the previous download is crashed. Otherwise the do_fetch is skipped.

And, the same for do_unpack.

For example, if you change the u-boot source code under build/tmp, and run bitbake -c compile u-boot-imx you are only recompiling, nothing else will be re-done (like configure, for example)

and yes, u-boot.bin is placed in some directory under build/tmp/ but it´s not deployed to tmp/deploy/images/<MACHINE>

So, you can play around with tmp/work source code, but please DO NOT rely your development in that folder!

Isn't it the <local folder>/build/tmp/work/<bsp> directory supposed to be the source code downloaded from repo?

No, it´s only a temporary copy of source code and, depending on your Yocto Project configuration, you may not have it after a BitBake

The recipes in the <local folder>/sources directory points the SRC_URI to a git location. Why does the bitbake not fetching the source code from the git directory, instead it uses the local copy that i make changes in the <local folder>/build/tmp/work/... directory?

Using the local copy under build/tmp/work is a collateral effect and it does not work for every single case.

For package/kernel/u-boot development you should use the traditional toolchain + iterative source code changes you are used to. You can use Yocto Project to tailor your SDK with the toolchain, but if you prefer you can use any other compatible one.

After you have a "release" of your package/kernel/u-boot you include a recipe to it, and then you start to tailor your production image which is the image you will build for your product/goal.

0 Kudos
2,176 Views
jimmychan
NXP TechSupport
NXP TechSupport

Hi DaianeAngolini, would you please help this question? Many thanks.

0 Kudos