I have inherited a device / code base / quality process that only allows deploying packages supported by yocto. I'm exploring options for replacing RabbitMQ with mqtt on our devices, but several of the services in the code base require message headers so I would prefer to adopt mqttv5. I see that mosquitto has finally released an mqttv5 server (mosquitto 2.x). I'm new to yocto, so I'm curious what is the time frame for yocto to support mosquitto 2.X? Is there a better place to ask this question, such as a yocto discussion community or mailing list?
Hard to say when the recipe will be updated but its no magic to adjust a recipe for a newer version by yourself:
Get the last available recipe. In case of mosquitto its for version 1.6.12
Rename recipe to match the wanted version: mosquitto_1.6.12.bb => mosquitto_2.0.3.bb and move it to the correct layer
Download the appropriate archive (mosquitto-2.0.3.tar.gz)
Determine the md5 and sha256 checksum of the archive and change them within the recipe (might also be needed for license file if that changed)
bitbake
In most of the cases this is all but it might be needed to take some further changes because the dependencies of the new version are different or patch files are not compatible anymore.
Related
I've set successfully my Yocto build to patch one of the standard kernel modules, and I'd like to make it possible to update that (and possibly some others in the future) module only on the target system using kernel modules RPM file. The only problem is that the patched module is marked with the exact same revision as the original one, so the only way to update would be to force reinstall of all kernel modules.
Is there any way to manually change PR or a similar version-related parameter for a specific kernel module, or maybe tweak the Yocto project in some other way, so the RPM file built upon it would recognize that module as the only one in need of update?
I am very new to embedded Linux and am working with buildroot. We have a DNP3 library that is very old and would like to upgrade from 2.3 to 3.1. I do not know where to even start.
Can someone point me to a tutorial or instructions on how to upgrade an existing library or package?
It's not explained explicitly in the Buildroot manual, but updating a package is:
finding the package directory (e.g. package/dnp3);
change the version number in the dnp3.mk file;
download the package with make dnp3-source;
this will give an error because of a missing hash: note the hash and update it in dnp3.hash.
Of course, often that is not enough because the updated package has new dependencies, or it has to be patched to be able to build it in cross-compilation, or various other issues.
I have a custom board with imx6dl chip and peripherals. I have compiled u-boot, zImage and rootfs from examples provided by manufacturer. But when i try to build yocto from git repo with latests releases, it fails to run (some drivers not working, board is loading and display interface, but touchscreen is not working for ex.),
Is there any way to include precompiled binaries zImage, u-boot and device table to bitbake recipes? I'm very new to yocto project, and only need to get bootable image with working drivers and qt5.
If you have a working boot chain (e.g. u-boot, kernel and device tree) that you have built out-of-yocto, then you might try building a rootfs only. This requires two main settings, to be made in your local.conf to get started. Please don't firget that this is just a starting point, and it is highly advised to get the kernel/bootloader build sorted out really soon.
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy to have no kernel being built, and something like MACHINE="qemuarm" to set up an armv7 build on poky later than version 3.0. The core-image-minimal target should at least be enough to drop you in a shell for starters, and then you can proceed from there.
Additionally, it might be qorth asking the board vendor or the yocto community (#yocto on the freenode server) if they know about a proper BSP layer. FSL things are quite nicely supported these days, and if your board is closely related to one of the well-known ones, you've got a high chance that meta-freescale just does the trick nicely.
Addition:
#Martin pointed out the mention of Qemu is misleading. This is just the easiest way to make Yocto build a userland for the armv7-architecture which the imx6dl is based on. The resulting root filesystem should be sufficiently compatible to get started, before moving on to more tuned MACHINE configuration.
System Info:
MongooseIM version: 3.0.0
Installed from: pkg
Erlang/OTP version: 18
Ubuntu 16.04
I am having trouble creating a standard base for a custom module. I want to create a simple hello world program as outlined in the documentation for ejabberd.
However, I cannot get it to work for MongooseIM. Are there any instructions for how to do this? As a beginner I am just looking for building blocks to creating my own modules, and everything I look at is a little too complex for what I am trying to achieve at the moment.
Here is the code for my module: (taken from ejabberd) https://docs.ejabberd.im/developer/extending-ejabberd/modules/#mod-hello-world
And here is my log error:
I have added the following line in my config file with all other running modules:
{mod_hello_world, []}
I am assuming it has something to do with the compilation and there being no .beam file created for the modules as well as some syntax errors specific to MongooseIM. I am also unfamiliar with documentation for compiling modules when using a pre-built pkg as opposed to installing from source.
DISCLAIMER: I'm a MongooseIM developer working for Erlang Solutions.
The link you posted hints at the answer to the immediate question:
If you compiled ejabberd from source code, you can copy that source code file with all the other ejabberd source code files, so it will be compiled and installed with them. If you installed some compiled ejabberd package, you can create your own module dir, see Managing Your Own Modules.
MongooseIM (a.k.a. MIM) does not support the latter method of managing modules, i.e. it's not possible to drop source code into some predefined location when MIM is installed from a package and let it just compile and run the module. If we want to write a custom module, we have to build MongooseIM from source.
To be precise, we don't have to build the whole server from source and package it ourselves. We have to, however, clone the repository, place the new module source there (due to build time requirements like header files) and build it there. Once we get a .beam file of the new module we can just drop it into an installed MongooseIM's code path.
To be even more precise, let's say we have installed MIM from mongooseim_3.0.0-1~ubuntu~artful_amd64.deb available from the Downloads page at erlang-solutions.com, therefore we want to build a module compatible with 3.0.0:
Clone MIM: git clone https://github.com/esl/mongooseim
cd mongooseim
git checkout 3.0.0
Place mod_hello_world.erl under ./src/
rebar3 compile
Once rebar3 finishes get ./_build/default/lib/mongooseim/mod_hello_world.beam and copy to the target host where we installed MIM from a package.
Please note, though, that an example taken straight from ejabberd documentation might not work "as is" in MongooseIM. In this simple module, for example, we'll not be able to include logger.hrl as MongooseIM doesn't have such a header file - we would have to -include("mongoose_logger.hrl"). instead.
A project I've inherited uses a very old version of buildroot, but I'd like to change it to use a feature that was added only in a later buildroot release.
Is there a straightforward way of updating a buildroot setup to use a later release?
e.g. if I save out a defconfig file and import that in a later buildroot release, would that just work, or are there practical reasons why not? Are there additional configuration files I'd need to carry across (e.g. kernel, busybox, etc)? Thanks!
No.
In fact, it's worse that that.
You can start by using a newer Buildroot version with your old default configuration file, but you will need to check the resulting configuration carefully for deprecated packages and packages whose versions are not compatible with whatever application software you might be adding to the Buildroot filesystem. The names of some packages (e.g. opencv) change over time, so you need to eyeball the resulting .config file to make sure that all of the packages that you need are there.
If you build a toolchain or Linux kernel in Buildroot (commonly done but not generally good practice), then you need to make sure that the new configuration is set to build the old version of the kernel and compiler. These might be too old to build some of the packages in the newer version of Buildroot.
If you upgrade your kernel at the same time that you upgrade Buildroot, then you need to port your old kernel config file to the new kernel version. Since the kernel configuration options change frequently, you will probably need to start from defconfig for your board and then use make menuconfig to manually add the configs that you need.
Busybox is a bit less volatile, so there is a chance that your old config will work.
If your old Buildroot configuration uses postbuild or postimage scripts, you will need to review them, but my guess is that they will not need any changes.
You should allocate at least a week for this work, maybe more, depending on the complexity of the configuration. Remember that if you are forced to use an older vendor kernel due to patches for a specific SoC, for example, the Freescale 2.6.33.9 kernel for the BSC9131, then the upgrade that you want to do might not be possible without doing six to twelve months of work to port the vendor's kernel patches to a newer kernel version.
Cheers.