I'm trying to figure out how to convince Yocto to build gcc using my local GIT source rather than standard location it uses.
By default the recipe to build GCC located in meta/recipes-devtools/gcc/gcc_5.2.bb. It includes gcc-5.2.inc, which points to
BASEURI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
as the location of the code.
Based on BitBake's documentation, I've created my own layer and gcc_5.2.bbappend append file. bitbake-layers show-appends shows that the system properly recognized the append file.
However, what this gcc_5.2.bbappend append file need to do to replace the source path? I've tried changing SRC_URI directly, prepending it with my own path. But it always stays the same and attempts to access the specified above path.
My original assumption that the /gcc/gcc_5.2.bb have to appended was incorrect. I've corrupted the specified above BASEURI to consistently cause an error. Running bitbake with -D option showed that there is a different recipe called gcc-source_5.2.bb that actually controls the source file acquisition and it had to be appended.
Related
I am trying to build a system (Yocto based project) using bitbake and one of the steps is that it needs to retrieve an archive.zip file with a hex file in it from a Jenkins instance somewhere and install that somewhere within the kernel.
The problem now is that I have get a bitbake error on the do_fetch step of this precise recipe.
File: '/cache/downloads/firmware-17.zip' has sha256 checksum 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 when 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[sha256sum] = "6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9"
As you can see the expected checksum is identical between what bitbake reads and expects so I don't really understand what to do at the moment.
What I have already tried is:
Ensure that bitbake does a full clean build.
Bump the repository where archive.zip originates from so that the hash isn't the problem.
What I haven't tried yet is:
Manually download the firmware and place it in the /downloads folder of bitbake and mark the recipe as 'fetched' but since it is running in docker that is not a viable solution really.
Has anybody come across something like this?
I suspect there is a stray space in the value set in your recipe. The message hints at that with "9c9 was" showing a double space.
I use Yocto Zeus to build an embedded Linux for my board. So far I need to replace the /etc/ssh/sshd_config with my custom one.
Unfortunately I couldn't find any useful information about that. Just found some help on the Internet.
I've created a custom layer and add an recipe as following:
sources
mylayer
mylayer-recipes
recipes-connectivity
openssh
openssh_%.bbappend
openssh
sshd_config
openssh_%.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://sshd_config"
after this I've try to rebuild the image
bitbake core-image-minimal
But nothing happens. No error and no change of the sshd_config file in the image.
What I do wrong? Actually I only want to replace the system /etc/ssh/sshd_config with the custom one, nothing else.
Ok, I've finally solved the issue. It's turned out that I haven't follow the full path to the *.bb but only the top level although the doc says "...This implies that you must have the supporting directory structure set up that will contain any files or patches you will be including from the layer." in the 5.1.5. Using .bbappend Files section. So the final folders structure looks like this:
sources
mylayer
mylayer-recipes
openssh
openssh_%.bbappend
openssh
sshd_config <----- the file that replaces the original one
poky
recipes-connectivity
openssh
openssh_8.0p1.bb
openssh
sshd_config <----- the original file
....
i.e. I just added folder openssh to mylayer-recipes folder and now that works as expected
I like to disable and enable some pins in my RPi project.
These are GPIO 6, GPIO 5 and GPIO 26. I like to use these PINs in my own kernel driver.
For this project I connect a simple electric board via the GPIOs. The minimal system is build via yocto. I like to change the device tree file to disable/enable GPIOs.
I need to change or make my own dts file. For that I think I will need to:
find the original RPi dts
patch it or create my own dts
add it to the layer.conf
add file to the kernel recipe via append
How can I do this? or where can I find the sources?
Actually I am struggling to find the dts files for the RPi2 I am using. I was checking the "raspberrypi2-poky-linux-gnueabi" recipe results(and do not find any files).
I do not find any tutorial how to setup yocto + meta-raspberrypi + own dts. it would be great if we can figure out the necessary steps.
I'm not convinced this question has been well answered, so let me take a few minutes and document what I've done to add device tree overlays to my yocto builds.
This is a multi-problem process.
I'm going to make a few assumptions:
* You source your oe-init-build-env in a shell, and do your bitbake builds manually in a terminal (or you know how to do it with equivalent tooling)
* You know (or are already learning) the basics of device trees...
Start with your own meta layer. Mine is out on github.
You'll need to create an *-overlay.dts source file. You can start with a simple place holder, and stuff it (quite literally) anywhere on your system. We'll import it to your meta layer in the next step using bitbake to do some of the staging and what-not for us.
recipetool appendsrcfile -wm rpi /path/to/your-layer-meta virtual/kernel /path/to/your-overlay.dts 'arch/${ARCH}/boot/dts/overlays/your-overlay.dts
At this point, you should end up with a recipes-kernel/linux directory with an appropriate bbappend targeting the $MACHINE type of -wm (rpi, as above), ready to copy the device tree source file into the proper spot for bitbake to find it when it building the kernel. But it still won't be included in your kernel build.
We need to add the overlay reference to the KERNEL_DEVICETREE variable, in places that will cover the scopes of: linux, bootfiles, and the sdcard_image-rpi.bbclass from meta-raspberrypi.
In the linux bbappend created in step 3, add KERNEL_DEVICETREE += "overlays/your-overlay.dtbo" to make the linux kernel build include your dts as something to compile into a dtbo.
To make the sdcard_image-rpi.bbclass copy the file, you'll need to add KERNEL_DEVICETREE =+ "overlays/your-overlay.dtbo" to your image recipe.
To make the overlay active, you'll need to create a recipes-bsp/bootfiles/rpi-config_git.bbappend whereyou can append a do_deploy step to add the dtoverlay=your line to config.txt.
I use my layer for more than one project, so I felt OK with having the dts compile with every kernel but only copy it to images where my image recipe added it to the KERNEL_DEVICETREE. For further insurance that I don't get these things interferring in images I don't want them in, my rpi-config append has a test to see if I should add the dtoverlay line to the config.txt
Of course, this was all assuming you were going to use your own home-grown DTS without starting from a kernel-sourced one. The process would be largely the same, but you'd be able to patch the existing, or copy it, or whatever you want to do in your linux recipe.
I hope this helps! I know it's an old question.
First you need to find the kernel used on your yocto project, the recipe is linux-raspberry.bb or something like linux-*.bb. The preferred kernel is probably set in your local.conf or machine.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberry"
This is indirectly set via "meta-raspberrypi/conf/machine/include/rpi-default-providers.inc" which is included via "rpi-base.inc"
Once found, take a look at the recipe, clone the git repository of the kernel, on the right branch, and reset at the right SRCREV.
Once downloaded, the dts files are in /path/of/my/kernel/linux-raspberry/arch/arm/boot/dts/. You can find the name of the devicetree file used in the kernel recipe, local.conf or machine.conf, with the variable KERNEL_DEVICETREE = "..."
For the meta-raspberry and rpi2 selected, the dts files can be found in <path to build dir>/linux-raspberrypi2-standard-build/source/arch/arm/boot/dts/. The source dir is a linked dir to the git sources.
You can add a new dtb by creating dtsi/dts files (don't forget to add it in the Makefile).
Create a patch, add it to the kernel recipe:
SRC_URI += "file://0001-mypatch.patch"
and put the patch file like this in your meta
├── files
│ └── 0001-mypatch.patch
└── linux-raspberry.bb
Modify the KERNEL_DEVICETREE variable to add your new dtb.
Now you can bitbake your kernel/image, your new dtb will be created.
I'm using ccache with git-worktree. So many of the same files are shared across multiple directories. Problem is that ccache doesn't check if the file is the same, and is compiled again. Is there a ccache option that would allow it to check the cache across multiple source directories?
ccache (by default since version 3.3) adds the current working directory to the hash if -g is used, which only makes it possible to get cache hits within the same source directory. Another similar issue is if you use absolute paths in compiler arguments, then you need to use the base_dir configuration setting.
More details from the "Compiling in different directories" section in the ccache manual:
If you build with -g (or similar) to add debug information to the object file, you must either:
use the -fdebug-prefix-map=old=new option for relocating debug info to a common prefix (e.g. -fdebug-prefix-map=$PWD=.); or
set hash_dir = false.
If you use absolute paths anywhere on the command line (e.g. the source code file path or an argument to compiler options like -I and -MF), you must to set base_dir to an absolute path to a “base directory”. ccache will then rewrite absolute paths under that directory to relative before computing the hash.
I'm currently trying to build poky-tiny for imx6ulevk (using the BSP Yocto Project Environment provided by NXP).
I first followed the Quick Start Guide, tested and everything worked just fine. I then went to the usual local.conf file (/build/conf/local.conf) and changed the DISTRO variable to poky-tiny.
In poky-tiny distro file (/sources/poky/meta-yocto/conf/distro/poky-tiny.conf), I changed the virtual/kernel in the variable PREFERRED_PROVIDER_virtual/kernel to linux-imx and the PREFERRED_VERSION_linux-imx to 3.14.38 which is compatible (I think).
I finally added to the local.conf the variable IMAGE_FSTYPES with the value tar.bz2 ext3 sdcard.
At this point I tried to build using:
bitbake core-image-minimal
this runs without any problems. But it doesn't generate sdcard image or any u-boot images as is expected. The only files generated are:
core-image-minimal-imx6ulevk-20160517152114.rootfs.cpio.gz
core-image-minimal-imx6ulevk-20160517152114.rootfs.manifest
core-image-minimal-imx6ulevk.cpio.gz
core-image-minimal-imx6ulevk.manifest
modules-imx6ulevk.tgz
zImage
zImage--3.14.38-r0-imx6ul-14x14-evk-20160517152114.dtb
zImage--3.14.38-r0-imx6ul-14x14-evk-csi-20160517152114.dtb
zImage--3.14.38-r0-imx6ulevk-20160517152114.bin
zImage-imx6ul-14x14-evk-csi.dtb
zImage-imx6ul-14x14-evk.dtb
zImage-imx6ulevk.bin
And I got stuck without knowing how to deploy to the imx6ulevk. What did I do wrong? Why is yocto not generating the usual sdcard image?
If anyone gets this what worked for me was the following:
Turns out poky-tiny for imx6ulevk does not create sdcard images normally. So what you need to do, once you build it with a proper kernel, is to manually create a bootable sdcard. This can be done by using gparted cleaning everything in it and adding 2 partitions, then proceed as follow:
1 - First you use gunzip in the file core-image-minimal-imx6ulevk-...-rootfs.cpio.gz.
2 - Call cpio on the generated file: cpio -i -vd < core-image-minimal...-.cpio
3 - You just generated the root file system copy everything into one of the partitions.
4 - the zImage...* files are the generated kernel for the poky-tiny distro. Copy all but the symbolic links to the second partition. You might need to rename the files (I had to) if you're not sure what to rename to, first build regular poky using sdcard image and check out the proper names.
That's pretty much it, you should be able to boot imx6ulevk using the provided files.