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
Related
I have built initramfs which I want to use for setting up dm-verity. For testing purposes I don't switch_root and after boot it stays in initramfs. However I need the tool veritysetup. I have it precompiled and copied to /usr/sbin on initramfs, but when I run it on the platform it says - /bin/sh: /usr/sbin/veritysetup: not found. Any ideas how to make it execute?
Yes, I have done this.
For a hint let me first give a simple clue first.
For veritysetup command to work in your initramfs you also need to copy all the dependent libraries (same architecture) to your libs folder inside initramfs.
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.
I'm using Ubuntu Linux.
I've been trying to get the following cscope command to run when I run "make" from my project directory, so it recompiles cscope and gets updated name information when I make my project.
cscope -b -q -U -R
Per my research and a bit of reading, I should be able to get CMake to run a command when you do 'make' by using the add_custom_command function in CMakeLists.txt.
However, many attempts and variations of it, have not been successful. Is it possible to run this as I want it with add_custom_command?
Simply doing this doesn't seem to work:
add_custom_command(OUTPUT
${CMAKE_CURRENT_BINARY_DIR}/cscope.in.out
${CMAKE_CURRENT_BINARY_DIR}/cscope.out
${CMAKE_CURRENT_BINARY_DIR}/cscope.po.out
COMMAND cscope -b -q -U -R)
I've tried using the TARGET overload of add_custom_command as well, and making a custom target with a dependency on either ALL or the main output file of the project, but that doesn't do anything either.
Ideally this would run after the project has been built, if could tell me what I'm doing wrong or if this is at all the way to do this, I'd be grateful?
I've tried using the TARGET overload of add_custom_command as well, and making a custom target with a dependency on either ALL or the main output file of the project, but that doesn't do anything either.
This seems to be the problem - when a CMake commands requires to be passed a target, they refer to the name of a target you've created previously by using any of add_executable, add_library or add_custom_target, which doesn't necessarily map to an actual artifact file generated by the command.
Here's my take on the problem, and it seems to generate the three cscope files in the build directory.
cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
project(te)
add_executable(main main.cpp asdf.cpp)
add_custom_command(TARGET main POST_BUILD COMMAND cscope -b -q -U -R)
Note here that the name of the target here is whatever I've passed as the first argument to the add_executable command.
This is the way I install the config files:
file(GLOB ConfigFiles ${CMAKE_CURRENT_SOURCE_DIR}/configs/*.xml
${CMAKE_CURRENT_SOURCE_DIR}/configs/*.xsd
${CMAKE_CURRENT_SOURCE_DIR}/configs/*.conf)
install(FILES ${ConfigFiles} DESTINATION ${INSTDIR})
But I need to convert one of the xml files before installing it. There is an executable that can do this job for me:
./Convertor a.xml a-converted.xml
How can I automatically convert the xml file before installing it? It should be a custom command or target that installing depends on it, I just don't know how to make the install command depend on it though. Any advice would be appreciated!
Take a look at the SCRIPT version of install:
The SCRIPT and CODE signature:
install([[SCRIPT <file>] [CODE <code>]] [...])
The SCRIPT form will invoke the given CMake script files during
installation. If the script file name is a relative path it will be
interpreted with respect to the current source directory. The CODE
form will invoke the given CMake code during installation. Code is
specified as a single argument inside a double-quoted string.
For example:
install(CODE "execute_process(\"./Convertor a.xml a-converted.xml\")")
install(FILES a-converted.xml DESTINATION ${INSTDIR})
Be sure to checkout the entry for execute_process in the manual. Also be aware that macro expansion inside the CODE parameter can be a bit tricky to get right. Check the generated cmake_install.cmake in your build directory where the generated code will be placed.
I think that your specific case would work better if you were to use a custom command and target like so:
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/a-converted.xml
COMMAND ./Convertor a.xml a-converted.xml
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/Convertor
)
add_custom_target(run ALL
DEPENDS ${CMAKE_BINARY_DIR}/a-converted.xml
COMMENT "Generating a-converted.xml" VERBATIM
)
install(
FILES ${CMAKE_BINARY_DIR}/a-converted.xml
DESTINATION ${INSTDIR}
)
Note: I don't have all the details, so the directories are probably
not exactly what you'd want in your environment, although it's
a good idea to generate files in the ${CMAKE_BINARY_DIR} area.
That way you can be sure that the file a-converted.xml is built at the time you want to install it. Especially, these two rules make sure that if you make changes to the file, it gets recompiled.
Background:
I recently joined a software development company as an intern and am getting used to a new build system. The software is for an embedded system, and lets just say that all building and compiling is done on a buildbox. The building makes use of code generation using xml files, and then makes use of make files, spec files, and version files as well.
We develop on our own comps, (linux - mandriva distro) and build using the following methods:
ssh buildserver
use mount to mount drive on personal computer to the buildserver
set the environment using . ./set_env (may not be exactly that)
cd app_dir/obj (where makefile is)
make spec_clean
make spec_all
make clean
make
The Question:
I am a newbie to Code::Blocks and linux and was wondering how to set up a project file so that it can simply run a script file to execute these commands, instead of actually invoking the build process on my actual computer. Sort of like a pre-build script. I want to pair the execution of this script simply to Ctrl-F9 (build) and capture any output from the above commands in the build log window.
In other words, there is no build configuration or target that the project needs to worry about. I don't even need a compiler installed on my computer! I wish to set this up so that I can have the full features of an IDE.
Appreciate any suggestions!
put your script in a shell script file. E.g.,
#!/bin/sh
mount ... /mnt/path/buildserver
. ./set_env
cd app_dir/obj
make spec_clean
make spec_all
make clean
make
Say you name it as /path/to/my_build_script, then chmod 755 /path/to/my_build_script and invoke the following from your ssh client machine:
script -c ssh buildserver "path/to/my_build_script"
When finish, then check for the file typescript under current directory.
HTH