I'm trying to configure a kernel in a Yocto build environment (bitbake virtual/kernel -c menuconfig), and for some reason the new terminal that opens when running it simply runs a full compilation of the kernel and then exits, instead of simply opening the config menu.
This used to work with the same metas in the jethro branch, but now it doesn't with krogoth.
Does anyone have any idea what could cause it?
I think I found the problem, it appears that a custom implementation of the 'do_menuconfig' python function in the vendor meta layer (classes/*.bbclass), stuck around from an older version.
Simply removing that function and thus letting the default 'do_menuconfig' function run instead seemed to do the trick.
Related
SO!
Let's say I have a number of settings (GCC compiler 9.3.0 built from source, as the distribution I have to use has a very old one, along with environment setup) for a new Kit in QtCreator.
I have managed to setup an environment for compilation and execution of compiled binaries, and made a script to make it work (like qmake -nocache -recursive/make/sudo make install, direct execution of g++, and other stuff).
One thing that script can't do at the moment, is that it cannot create a kit for QtCreator with new compilers and environment being set as required, so after running a script, its user has to go through setting it up himself through GUI, which is bad, because this can cause misconfiguration.
This thing I'm trying to create is going to be used by around ~200 people in my company, so leaving readme.txt with instructions just doesn't go well enough for me - I don't want running around fixing missing "{" and "}" in Environment description in created Kits, and other stuff.
Are there ways to create Kits for QtCreator automatically from command line? Maybe, there's some files to edit?
I've looked into this one a few years back (I wanted to do something similar for registering Buildroot toolchains automatically in QtCreator), and I was unable to find an off the shelf solution. So i think there are 2 ways to implement this:
a) Implementing a command line utility the manipulate the ~/.config/QtProject/qtcreator/{toolchains,profiles}.xml files. Maybe by (re)using the existing C++ implementation within QtCreator, or just re-implement it ie. in Python. Back than I didn't start to work on this as there was no real business need.
b) Switching to qbs, as qbs has support for setting up toolchains from the command line ( see: https://doc.qt.io/qbs/cli-setup-toolchains.html)
If you decide to go with solution a), please let me know and maybe we can partner up to implement it.
Check out the command line sdktool bundled with QtCreator:
The SDK tool can be used to set up Qt versions, tool chains, devices
and kits in Qt Creator.
There still is a lot of knowledge about Qt Creator internals required
to use this tool!
I haven't tried it yet, but I did find the executable under Tools/QtCreator/libexec/qtcreator subdirectory of the Qt Creator installation directory. ./sdktool --help works for me under Linux.
I've found various kernel configs in kernel/configs/q.
When I alter them, and run mm in kernel/msm-4.14 the kernel is not rebuilt.
Where do I edit the kernel config, such that a kernel rebuild is forced when mm is run?
The kernel is built separately from the Android platform first. Then the Android platform build system is pointed at where the kernel image is located, using the TARGET_PREBUILT_KERNEL environment variable.
Here is an outline of how I usually configure and build. I have done it this way for both Android 9 and 10, for various vendors. The scheme I use is mentioned in the docs here. Non-Google kernels usually don't come with version control (repo), I don't know what you're dealing with so I'll cover both.
Configuring the kernel
For repo-checkout kernels, you do the config in build/build.config. Basically, after defconfig was taken as basis, you use the ${KERNEL_DIR}/scripts/config tool to alter the config. This usually looks as follows:
POST_DEFCONFIG_CMDS="check_defconfig && update_config"
function update_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d CONFIG_SOMETHING_I_DISABLE \
-e CONFIG_SOMETHING_I_ENABLE \
--set-val CONFIG_FOO = 123
}
If you don't have a repo-checkout kernel, locations and details may differ but the basic idea is usually the same: Find/Create the script that kicks of the build, and add invocations of the config tool after making defconfig.
Run the config tool by its own to see full options and more info on its usage, but the above is usually all you need. Beware: If you make syntactically-correct invalid changes (e.g. enable symbols of which the dependencies are not met), the build system will NOT complain and ignore these changes silently. If you face this situation, e.g. use menuconfig to find out what's wrong, as it shows dependencies.
Building AOSP / Making boot.img
After you've built your kernel, you will have Image.lz4 in out/.../dist (or Image.gz in out/.../private/msm-google/arch/arm64/boot). You go to your Android source, and in addition to the usual things (source build/envsetup.sh, lunch) you point the build system at the image you built, e.g. export TARGET_PREBUILT_KERNEL=/path/to/Image.lz4. Then just start the build normally, e.g. make bootimage or m droid.
Note that for Android 10 at least in some cases, you'll have to copy over the kernel modules from out/.../dist too, since the new kernel can't load the old ones. With this part, I am having problems myself at the moment. I think they have to be copied to device/VENDOR/DEVICE (e.g. google/coral-kernel), you may also copy your kernel image there btw, since the original prebuilt one also is there by default. The problem is that at least in my case, the new kernel modules were not copied to device after all.
I'm following the instructions here: https://github.com/symless/synergy-core/wiki/Compiling for compiling on OSX. I've "finished" everything. But I don't understand what to do to install synergy once the compiler has completed? I was expecting a nice output directory somewhere with a synergy.app or something in it. Am I missing something? I've used the GUI method using QT to compile the code as I didnt scroll down far enough initially to realise you can do it on the command line. But either way I've managed to get to the end of the instructions for compiling and I'm a little lost now.
Thanks
Once it's compiled, Synergy binaries are outputted to the build/bin directory inside whatever directory you cloned the Synergy source to (it was ~/git/synergy-core in my case).
You can run ~/git/synergy-core/build/bin/synergy (replacing with whatever your path is) to start the Synergy configuration UI which lets you configure your server or client as desired.
Use Case:
I am developing a IoT Linux system for my Raspberry Pi. Read Only rootfs is not an option, because I want to upgrade executables on the fly. What I thought is my solution: I develop a tool which can sign ELF-Files (Linux executables and libraries). It signes the sections with some pub/priv key, saves the signature into a section and checks the file before executing it (like DigSig but with the help of openssl-lib). The library loader(glibc) is also modified to check all linux ".so"-libraries before loading it. At the end I want to publish the project and my solution under an open source license. Currently it is not finish and far away from stability.
Develoment state:
ELF-File Sign tool is finished.
Kernel is modified (new security module / own syscall function to check elf-binary signature).
Glibc is modified and patched for my local source.
Quemu is patched to support my new syscall.
Yocto environment is set up. And the image runs on my RaspberryPi 2 test machine.
So far so good. I have the feeling I am very close to my solution.
Now I need to:
Make Yocto / bitbake enable that ALL ELF-Files are signed after the build process. Best would be if the rpm-files have already the signed ELF-files included. And the signing process would be done by one recipe for all the other packages. (So I do not want to create a post installation script which modifies only the files on the root folder).
After searching hours in google and checking the documentation of yocto I have no solution. It would be very great if someone can help me.
I think you can customize package.bbclass in poky/meta/classes, in particular, split_and_strip_files function helps to strip every files
oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)
You can add signing then add your custom tools in poky/meta/lib/oe/package.py
Im playing around with buildroot together with linaro 2016.11 for arm.
Im actually building the latest Linux Kernel for the i.MX6 Processors.
So far so good.
I have setup the buildroot config with
$ make makeconfig
I have configured an external toolchain (the linaro one). I also configured the uboot to be built. In the uboot section, i had to choose the appropriate board name for the defconfig.
Now the problem:
I have done a full make which was successfull without any errors.
After that, i have changed the uboot board name to something which does not exist in the source. Just to make sure everything is working correct.
i have restartet the build process with
$ make uboot-rebuild
to my confusion, the build was sucessfull. After a deeper look to the shell commands, i saw, that the new config was just ignored. I have tried everything without success. It only rebuilds correctly after i do a
$make clean
$make
but this will build the whole thing again and it takes a lot of time.
I hope someone could help me with that and give me some hint.
Thanks.
make <pkg>-rebuild rebuilds the package without applying a new configuration, so what happens is correct.
After changing the U-Boot configuration you have to run make uboot-reconfigure. This command first applies the configuration, then it does the same actions as uboot-rebuild.
See also the Buildroot manual, section Understanding how to rebuild packages.