I am trying to create a set of linux driver modules under yocto. The drivers are fundamentally very similar but for reasons of hardware, have a separate source file for each interface resulting in a set of N modules. All of the drivers share functionality which is contained in set of separate files.
What I would like is that all the module source files and the set of shared files share a directory (or the latter are in a subdirectory) and that the yocto recipe generates a module from each driver source resulting in N separate modules from the one recipe.
Is this feasible or can anyone suggest an alternative that does not require replication of the shared files for each module?
Related
I am writing a bitbake recipe to deploy a third party pre-built tool, similar to this wiki page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
However, I have a Release and Debug pre-build versions of the tool available as *.so files. How do I distinguish inside the recipe which one of both build types I shall deploy?
Thanks and regards,
Martin
You can have two different virtual recipes each with their own .so file. This then warrants a selection in a configuration file (with PREFERRED_PROVIDER_virtual/my-recipe), so either in a machine or distro configuration file. This is probably preferred if you consider having release and debug distros.
A second option is to install the libraries in two different paths, in two different PACKAGES (use FILES_my-package for that) and make them RCONFLICTS_my-package each other to be sure they can't both be in the rootfs. After that, you could write a pkg_postinst_my-package() task specific to each package that actually move the library from the "different" path to the intended one. This will be run both at build time when creating the rootfs and at runtime on first boot, so you need to make sure to exclude one or the other (it's usually done by checking if ${D} exists, which does at build time but not runtime).
c.f.: http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#post-installation-scripts
If you can manage to have both libraries installed in your rootfs and select the one you want with the LIBRARY_PATH environment variable, a simple recipe, with two packages with each library in a different location, will be sufficient.
I created a Bitbake recipe that does two things: 1) build an out-of-tree kernel module, and 2) copy files into the target root filesystem.
Part 2) uses the update-alternatives class to choose which files to copy based on the package that's being installed, ie, ${PN}-package, similar to the way the "linux-firmware" recipe works.
I also use EXTRA_OEMAKE (as part of the modules class) to pass variables down to the Makefile for the module I'm building. What I would like to do is to select different variables in EXTRA_OEMAKE based on which package is specified, ie, package1, package2, etc.
Is there a way to do this, or can anyone suggest any alternatives?
In Bitbake I can build e.g. the Linux Kernel with bitbake virtual/kernel or U-Boot with bitbake virtual/bootloader.
Where do those "virtual/..." terms come from?
I used find for patters such as "virtual/kernel" in the poky directory, but there are nearly infinite results and I don't know where to search.
Can I e.g. direct virtual/bootloader to a custom recipe when I might have programmed an own bootloader?
From bitbake user-manual
As an example of adding an extra provider, suppose a recipe named
foo_1.0.bb contained the following:
PROVIDES += "virtual/bar_1.0"
The recipe now provides both "foo_1.0" and "virtual/bar_1.0". The "virtual/" namespace is often used to denote
cases where multiple providers are expected with the user choosing
between them. Kernels and toolchain components are common cases of
this in OpenEmbedded.
Sometimes a target might have multiple providers. A common example is
"virtual/kernel", which is provided by each kernel recipe. Each
machine often selects the best kernel provider by using a line similar
to the following in the machine configuration file:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
Go to your meta-layer/conf/machine/here you can find macros.
your-meta-layer/recipes-bsp/barebox(or U-boot) here you can find bootloader recipes(.bb).
I followed the instructions given in the link: http://blog.avirtualhome.com/how-to-compile-a-new-ubuntu-11-04-natty-kernel/ for building a custom kernel and booting it. Everything works fine, except that when building it, I used the option skipmodule=true (as given in this link), so I guess the modules are not built for this kernel. So I have two questions:
How do I build only the modules for my flavor, now that I have the rest of the kernel built? 'make modules' will build it for generic flavor only, if I'm not wrong.
Also does it require me to build the entire kernel source, 'fakeroot debian/rules binary-i5' (i5 is my custom falvor), each time I make a change to one of my modules?
Thanks.
1) To build a linux kernel module for a specific kernel from the module source directory do:
make -C {path-to-kernel-source} M=`pwd` modules
The -C option tells is used to point to the kernel source tree where it finds the kernel's top-level Makefile. The M=`pwd` option points it to the module source directory, where it builds the 'modules' target.
2) Nope, its not necessary to build the source kernel. Either having the kernel source tree or the kernel headers suffice.
I am working on a module that I would like to have two backends, a Module(::PerlArray) and Module::PDL (which can will depend on Module). Both need access to a functions.c/.h file for building. This file has the rather complicated logic needed for the module. Rather than distribute it separately with each module, is there some way to keep it with the Module::PP on the system and then add it to the appropriate build flags in EU::MM or M::B (given the complexity here probably the latter)?
To put it more visually
--Module--
Module.pm
Module/PerlArray.pm
Module/PerlArray.xs (#include functions.h
#include perlarray_backend.h)
Module/src/functions.c
Module/src/perlarray_backend.c
Module/inc/functions.h
Module/inc/perlarray_backend.h
--Module::PDL--
Module/PDL.pm
Module/PDL.xs (#include functions.h /*from Module*/
#include pdl_backend.h)
Module/src/pdl_backend.c
Module/inc/pdl_backend.h
and the compilation makes functions.o and links. I'm sure I can figure out how to set the flags appropriately but how can I make Module keep the functions.c file while installing, and how can I then find it when installing Module::PDL? Is there some location I can place the functions.c/.h?
Have you looked at DBI? It does what you suggest: it installs some .h file(s) that the DBD drivers can #include in their XS code, as well as a library that the DBD drivers can call.
Modules should be independently installable. That is, providing I have the pre-requisite Perl modules installed (but not necessarily still lying around in source form), then it should be possible to install all the modules in one distributed tar file without reference to the source for any other module.
You have options. One is to have a single source directory create several distributed tar balls, and they can each have a copy of the shared function.[ch] in the distributed source.
The other main option is to bundle both modules into a single distributed tar ball.