I would like to replace the standard ntpd that comes with busybox with the full NTP server released in meta-openembedded.
However, I can't find the configuration or Yocto variable that sets that this version of the busybox should not have ntpd.
What is the efficient way to do this? Keep in mind that I can't edit the released Poky layer.
The way I solved is quite simple.
There was a file in my layer called busybox/files/ntpd.cfg with a flag CONFIG_NTPD. I've just set it to n and busybox was without ntpd.
I have in fact done the same to have the complete version of wget. There are 2 steps:
Configure busybox so that it does not provide such executable.
Include the recipe you located in your build.
For the first point the most elegant way is to crate a layer with its bbappend for busybox. You can follow the official example. I would initially check the default configuration. You can go faster by doing it manually like explained here. Either if you create a fragment for your bbappend or you do it manually through the bitbake -c menuconfig busybox. You can check in the sorce code what is the configuration entries that need to be modified.
The second is the easiest part, install ntp recipe either via image recipe or in your local.conf. (IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL variables respectively)
Try to add IMAGE_INSTALL_remove = "ntp" or PACKAGE_EXCLUDE = "ntp" to your local.conf.
Related
If I use the GUI to create a simics project, I can click an all the addons (OSS-Sources, QSP-x86, and so on) and the project's targets dir will contain these subdirs:
cosim qsp-x86 simics-builder-training simics-user-training vacuum workshop-01
If I run
$HOME/simics/simics-6.0.89/bin/project-setup simics-test2
the targets directory only contains
cosim vacuum
What flags do I need to pass to project-setup in order to install all addons?
Also, where can I get such information other than on stack overflow?
I tried reading project-setup -h and tried some of the flags there (e.g. --package-list $HOME/simics/simics-qsp-x86-6.0.44), but nothing worked.
Use the addon-manager in your project to create its own package-list.
cd simics-test2
./bin/addon-manager -C -s ~/simics/simics-qsp-x86-6.0.44
Having a .packagelist file in the installation of Simics Base would make all packages in that list global for that version of Simics Base. Which is not always what you want.
Having project-local .packagelist files gives you the neat option to select exactly which add-on packages you want with a particular version of Simics Base.
ISPM handle all of this for you quite seamlessly. But as Jakob mentioned, it does not add any "global" .packagelist file to the work flow.
I just added a new package to my Yocto build (this one: How do you properly build gpiod applications from Yocto?), and it works fine as long as I am connected to the internet. The problem is that I am now trying to make the tarball needed to support an offline build.
A little bit about the setup: I am running Yocto Zeus. I work in a VM (Ubuntu 18.04) connected to the internet, but our build agents are not on the network, so we host a mirror. I have this mirror mounted on /mnt/download-mirror. I am trying to generate the tarball needed for the mirror on my VM.
This is the Yocto config that I am using:
BB_NO_NETWORK = "0"
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "file:///mnt/download-mirror"
UNINATIVE_URL = "${SOURCE_MIRROR_URL}/uninative/2.7/"
BB_GENERATE_MIRROR_TARBALLS = "1"
SSTATE_MIRRORS = "file://.* file:///mnt/sstate-mirror/PATH"
But when I run Bitbake (I using command bitbake --runall fetch) it completes, but I don't get a tarball for the new package I added. I have looked for this tarball in the poky-downloads folder (the folder I would normally rsync to the mirror server), but it doesn't appear to be there.
Am I missing a configuration or something? I have all the configurations noted in https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3f
EDIT - I also tried setting DL_DIR ?= "/home/gen-ccm-root/Downloads" in my conf file, but my command still said there was nothing to do, so I think the issue might be my bitbake command. I have also tried bitbake -c mi-dev --runall="fetch" where mi-dev is my target (per 7.23.2 in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-effective-mirrors) to no avail.
Hopefully someone can edit this and put in more information as to why, but I did manage to get it to generate a tarball.
Cleaned my VM which entailed deleting the sstate-cache and poky-downloads.
Modify the local.conf to have the following at the end (I think the DL_DIR is optional):
BB_NO_NETWORK = "0"
DL_DIR ="/home/gen-ccm-root/Downloads"
BB_GENERATE_MIRROR_TARBALLS = "1"
Run command: source oe-init-build-env build-dev
Run command: bitbake mi-dev --runonly=fetch
Mount the network share containing the download mirror.
Copy the files over:
sudo rsync -av --ignore-existing --exclude=*.done --exclude=git2 --exclude=svn /home/gen-ccm-root/Downloads/ /mnt/download-mirror/
I will update this as I learn more (I am still kind of a Yocto noob), but the issue appears to be related to a combination of Yocto not reparsing after changing the config, and the fact that the sstate-cache was still accessible and said everything was there.
Wait a bit, with BB_NO_NETWORK it should not go out and fetch stuff from the internet.
If I understand it correctly you want a source mirror for some other build machines locally.
One way would be to share your DL_DIR of the one machine, which sees the internet.
Another way would be to use a source mirror for which you need the BB_GENERATE_MIRROR_TARBALLS = "1" from above.
I use a web server to export my DL_DIR (which also contains the tarballs) and on the machines which should use it I use e.g. in local.conf or site.conf:
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "http://mirror/source_mirror_zeus"
Just as a hint besides the sources you could also export SSTATE via SSTATE_MIRRORS, which will decrease build time a lot.
I have customized buildroot with the new board ( derived from raspberry pi zero ). So my changes are (in-tree):
.config
board/passkeeper/genimage-passkeeper.cfg
board/passkeeper/post-build.sh
board/passkeeper/post-image.sh
board/passkeeper/rootfs_overlay/etc/init.d/S41passkeeper
board/passkeeper/rootfs_overlay/etc/mdev.conf
board/passkeeper/rootfs_overlay/etc/udhcpd.conf
configs/passkeeper_defconfig
output/build/linux-custom/.config
Now, reading the documentation - I am a bit confused on how to put all these things into the separate folder via BR2_EXTERNAL. Also I'm not sure how do I move the linux configuration from output/build/linux-custom/.config
make linux-update-defconfig BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=/tmp/passkeeper/linux/linux-config
results in
Unable to perform linux-update-defconfig when using a defconfig rule
Can somebody please provide step-by-step guide on that?
[You are asking two questions. I will answer only the question about saving the linux .config file; the other question is too generic.]
You need to set the appropriate options in menuconfig, not just override on the command line, otherwise they are inconsistent.
The process complete for creating a linux defconfig based on a pre-existing in-tree defconfig is the following. You have already done steps 1, 2 and 3.
In the Buildroot configuration, select BR2_LINUX_KERNEL_USE_DEFCONFIG or BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG.
Run make linux-menuconfig and adapt the linux configuration to your needs.
Build and test, iterate over 2 until you have the configuration you want.
In the Buildroot configuration, switch to BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG and set BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE to the place where you want to save it (typically board/passkeeper/linux.config or $(BR2_EXTERNAL_PASSKEEPER)/board/passkeeper/linux.config if you are using an external).
Run make linux-update-defconfig. It is essential you do this before doing anything else, otherwise Buildroot will complain that the file doesn't exist.
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 am having an issue where a recipe i'm using no longer has the variable libdir defined. It appears to only have libdir_native.
This recipe i'm using is poco-1.7.5 for Morty from openembedded so I assume the recipe should work properly.
As a result of the missing libdir variable none of the installed files are being packaged which is screwing up my build.
In the short term i've been able to fix the problem by creating an append file which makes libdir = "${libdir_native} but this doesn't seem like it should be necessary.
The only thing I can think of is that the Bitbake.conf file is not being source properly by Bitbake (or the wrong .conf is being used).
Any suggestions would be appreciated.
Based on the comments this seems to be the problem: Poco upstream installs libraries into /usr/lib/ but the yocto packaging expects them to be in ${libdir} which may be different from /usr/lib/.
The most common reason (for cmake recipes) for this is that the upstream project does not support CMAKE_INSTALL_LIBDIR. Check if the upstream build system has some alternative means for specifying libdir -- this is surprisingly common with cmake projects. If not, you could add support for CMAKE_INSTALL_LIBDIR in the upstream build system (and add a patch to your recipe).
An alternative hack would be to add a do_install_append() that checks if ${libdir} is not /usr/lib/, and moves everything from ${D}/usr/lib/ to ${D}${libdir} in that case.