Hi I would like to download in a bitbake recipe on every build from a http:// address! At the moment I am just able to download on the first build. Does anybody knows how I can force Yocto how to download on every build?
Assuming the download happens in do_fetch, this should do the trick:
do_fetch[nostamp] = "1"
From the bitbake docs:
[nostamp]: When set to "1", tells BitBake to not generate a stamp file for a task, which implies the task should always be executed.
Related
I'm trying to use GNU autotools to configure, make, and install a program. I'm running into problems when I configure and make the program inside a GitLab job. It builds without errors, the problem is when I try to run the binary I built in the test jobs it errors out saying the binary doesn't exist because the config file still has the absolute path from the build job? Can I update the config.h without recompiling? I just need to be able to use the binary without errors?
Is there a way to rebuild boot.scr script without cleaning entire project?
I removed old boot.scr script and don't know how to genegrate new one (only make clean helps)
Variable BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE is set.
make uboot-dirclean uboot-tools-dirclean didn't help.
I found that the mkimage script that creates boot.scr is called from the uboot-tools install rule, but even if I clear uboot-tools boot.scr no longer generates
The accepted answer is correct, but there is easier way. The boot.scr is compiled by host-uboot-tools, not uboot-tools, thus you just need to execute this:
make host-uboot-tools-rebuild
If you dirclean host-uboot-tools it will rebuild your script. The reason is that mkimage (which generates the script) is called in the HOST_UBOOT_TOOLS_INSTALL_CMDS function in the uboot-tools.mk file.
As your personal script is in your external buildroot directory and you will probably want to iterate writing and testing it quickly you will want to make it every time. There is a way to do this each time you run make. No cleaning of anything is required. The post image script is the key.
For example, create your post-image.sh script and specify it in your defconfig file.
BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL)/board/RK3308/post-image.sh"
In that post-iamge.sh script, run the command to generate your boot script, here is an example :
# Generate the uboot script
$ubootName/tools/mkimage -C none -A arm -T script -d $BR2_EXTERNAL_RK3308_PATH/board/RK3308/boot.cmd $BINARIES_DIR/boot.scr
Each time you run make, the boot.scr will be regenerated.
If you want to see all of this in context, here is an external buildroot repo for the rk3308 chipset.
This is the post-image.sh file.
This is the definition of that file in the defonconfig file.
U-Boot provides the tool mkimage. In Debian based distributions it is in package u-boot-tools. Given that you have a file boot.txt with your script commands you can create boot.scr with
mkimage -T script -n 'My fancy title' -d boot.txt boot.scr
I am working to enable the kexec support in my propriety Linux distribution and I would like to debug the kexec tools in user space. I am adding debug prints in the kexec.c that's located in buildroot/output/build/kexec-2.0.15/kexec/kexec.c, but if I do an incremental build with make, it doesn't look like the kexec binary has been updated. If I rebuild everything from scratch with make all, the source code kexec.c has been overridden and I don't see my changes. My guess is that every full build re-extracts the kexec package and that is why my changes are not taking affect.
How do I solve this issue?
Try to use "make kexec-rebuild".
If you only want to restart the build process of a package from its
compilation step, you can run make <package>-rebuild [...]. It will restart the compilation and installation of
the package, but not from scratch: it basically re-executes make and
make install inside the package, so it will only rebuild files that
changed.
[...]
Internally, Buildroot creates so-called stamp files to keep track of
which build steps have been completed for each package. They are
stored in the package build directory,
output/build/-/ and are named .stamp_.
The commands detailed above simply manipulate these stamp files to
force Buildroot to restart a specific set of steps of a package build
process.
(from the Buildroot manual, section Understanding how to rebuild packages -- I suggest you read the whole section)
Also, look at your build log. If you don't see a line like
>>> kexec 2.0.16 Building
then the kecxec package hasn't been (re)built.
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
So some background, I'm installing Node on a host server, but it's a grid server not a server that's solely for my website.
The grid server doesn't have a root user/ administrative powers. So to install node I found this workaround: http://iantearle.com/blog/media-temple-grid-and-nodejs . It's a Linux Grid server, I've never used Linux so if someone could explain to me what the commands mean, especially: ./configure --prefix=~/opt/
Lastly I followed the steps but when I try to run the node command in the server it says node:command not found - which is why I'm trying to understand the steps. Thanks
To explain the process:
Configure
The configure script is responsible for getting ready to build the software on your specific system. It makes sure all of the dependencies for the rest of the build and install process are available, and finds out whatever it needs to know to use those dependencies.
Unix programs are often written in C, so we’ll usually need a C compiler to build them. In these cases the configure script will establish that your system does indeed have a C compiler, and find out what it’s called and where to find it.
Make
Once configure has done its job, we can invoke make to build the software. This runs a series of tasks defined in a Makefile to build the finished program from its source code.
The tarball you download usually doesn’t include a finished Makefile. Instead it comes with a template called Makefile.in and the configure script produces a customised Makefile specific to your system.
3.Make Install
Now that the software is built and ready to run, the files can be copied to their final destinations. The make install command will copy the built program, and its libraries and documentation, to the correct locations.
--prefix=~/opt/ -> will set the build directory to /home/yourhome/opt directory.
Now if you didnt get errors while doing those 3 steps explained above make sure you did the following:
nano ~/.bash_profile
export PATH=~/opt/bin:${PATH}
nano is a text editor and you are opening .bash_profile file with it.
you need to add export PATH=~/opt/bin:${PATH} in that file and save it using ctrl+x
Then restart your terminal.
Specified github repository for nodejs is outdated. use the following link instead.
git clone https://github.com/nodejs/node.git
P.S node:command not found usually happens when the program is not installed correctly or it's executable isnt in your terminal's PATH variable.