I have a vendor-provided standard Yocto build I need to customize.
In particular I cannot modify too much the basic filesystem (/bin /sbin /usr/bin /usr/sbin ...) because it gets installed in a quite full NAND Flash.
If I want to add something "non trivial" I need to move it somewhere else (e.g.: /usr/local or /opt) in a brand new filesystem (e.g.: on SD storage) and later mount it in the "right place".
How can I "relocate" a standard package to be built in some other place?
Example: If I want to add "native" compilation to my system I need to add something like IMAGE_INSTALL_append = " packagegroup-core-buildessential" somewhere (e.g.: in .../poky/build/conf/local.conf).
This will fail because of full partition (unsurprisingly). I can force production of packages (.ipk, in my case) but those will try to install in the same place (and fail because filesystem is a readonly squashfs and it would be too small even if writable) hence the question:
How do I tell a standard packagegroup should be put in another location (e.g.: usr/local)?
Specific pointers to documentation would be welcome; I tried searching the Mega-Manual, but I didn't find the right spell to use.
Related
I'm trying to build my own yocto_meta-layer based on the imx6ulevk and in ./meta-fsl-bsp-release/imx/meta-sdk/conf/distro/include/fsl-imx-preferred-env.inc I found something weird:
PREFERRED_PROVIDER_virtual/kernel_mx6ul = "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx6sll = "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx7 = "linux-imx"
So i was wondering what does the last *_word (i.e. PREFERRED_PROVIDER_virtual/kernel_*) means?
a) Does it is a way to set a virtual/kernel parser depending on the machine?
b) If [a] is yes, how do i know which name to put? or what part of the machine_name.conf i need to choose?
PREFERRED_PROVIDER_<recipe-name>_<machine-name> means this variable applies to mentioned recipe AND the respective MACHINE only. This is a common sighting in distro layers. In this particular case, the freescale layer is telling bitbake which Linux kernel recipe to choose depending on the MACHINE you either set in local.conf or pass via command line. More info here.
So the answer to a) is yes.
The answer to b) is that you should not bother with changing the PREFERRED_PROVIDER for the Linux kernel unless you really know what you're doing (i.e, writing a kernel recipe from scratch). Even if you have a custom board you're unlikely to change the virtual/kernel provider. You'd likely want to follow the BSP maintainer's recommendation. What you need to do is set a proper MACHINE, and the bitbake will take care of the rest.
For example if your MACHINE is mx6ul, invoking bitbake virtual/kernel is the same as bitbake linux-imx. The former is best practice, as you call that in Yocto regardless of the machine.
I'm afraid reading the docs is the best way to fully grasp Yocto. The good thing is that it's documented really well. You'd probably want to start from the development manual and the bitbake link above, before diving into the mega manual.
The suffix underscore '_' followed by a string means that the variable, PREFERRED_PROVIDER_virtual/kernel in this case is "overridden". bitbake will use this assignment when the OVERRIDES variable contains that particular string, such as "imx6ul".
Many times, if not all, the SoC architecture is set in the MACHINEOVERRIDES variable in the machine.conf, to define what the SoC is on the board. That consequently gets assigned to OVERRIDES in some yocto/bitbake recipe elsewhere.
The Conditional Syntax (Overrides) section in the bitbake manual [1] specifically talks about how this affects the variable expansion.
a.) If we were being strict with the terminology used by Yocto, it would be no. The "machine" per-se correlates to a board, such as "imx6ulevk". The overrides you have there more generally pertain to an SoC architecture (a chip). You may have many boards running the imx6ul for example. In this case it would pertain to all "machines" running that particular SoC (as defined by your machine in MACHINEOVERRIDES).
b.) Anything appearing in the colon delimited OVERRIDES variable is fair game. You can use the machine name because Yocto does in fact append the MACHINE name to it as well. But it doesn't really make sense to do that because you have a dedication machine.conf file for you to make a hard definition such as PREFERRED_PROVIDER_virtual/kernel = "something" if you really want a machine/board specific kernel selection. NXP did this in their distro layer to apply to many machines (aka boards) all at once.
Hint: to see what these variables expand out to, run bitbake -e virtual/kernel
These overrides are one of the most powerful features of bitbake. For example if you want to override the source revision of you linux-imx kernel build you can put something like SRCREV_pn-linux-imx = "something" in your local.conf. See if you can grep the recipe sources to find out how this works!
References:
[1] https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides
I have a custom machine layer based on https://github.com/jumpnow/meta-wandboard.
I've upgraded the kernel to 4.8.6 and want to add X11 to the image.
I'm modifying to image recipe (console-image.bb).
Since wandboard is based on i.MX6, I want to include the xf86-video-imxfb-vivante package from meta-fsl-arm.
However, it fails complaining about inability to build kernel-module-imx-gpu-viv. I believe that happens because xf86-video-imxfb-vivante DEPENDS on imx-gpu-viv which in turn RDEPENDS on kernel-module-imx-gpu-viv.
I realize that those dependencies have been created with meta-fsl-arm BSP and vanilla Poky distribution. But those things are way outdated for wandboard, hence I am using the custom machine layer with modern kernel.
The kernel is configured to include the Vivante DRM module and I really don't want the kernel-module-imx-gpu-viv package to be built.
Is there a way to exclude it from RDEPENDS? Can I somehow swear my health to the build system that I will take care of this specific run-time dependency myself?
I have tried blacklisting 'kernel-module-imx-gpu-viv' setting PNBLACKLIST[kernel-module-imx-gpu-viv] in my local.conf, but that's just a part of a solution. It helps avoid build failures, but the packaging process still fails.
IIUC you problem comes from these lines in img-gpu-viv recipe:
FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS} ${libdir}/libGAL_egl${SOLIBS}"
FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV} ${includedir}/HAL"
RDEPENDS_libgal-mx6 += "kernel-module-imx-gpu-viv"
INSANE_SKIP_libgal-mx6 += "build-deps"
I would actually qualify this RDEPENDS as a bug, usually kernel module dependencies are specified as RRECOMMENDS because most modules can be compiled into the kernel thus making no separate package at all while still providing the functionality. But that's another issue.
There are several ways to fix this problem, the first general route is to tweak RDEPENDS for the package. It's just a bitbake variable, so you can either assign it some other value or remove some portion of it. In the first case it's going to look somewhat like this:
RDEPENDS_libgal-mx6 = ""
In the second one:
RDEPENDS_libgal-mx6_remove = "kernel-module-imx-gpu-viv"
Obviously, these two options have different implications for your present and future work. In general I would opt for the softer one which is the second, because it has less potential for breakage when you're to update meta-fsl-arm layer, which can change imx-gpu-viv recipe in any kind of way. But when you're overriding some more complex recipe with big lists in variables and you're modifying it heavily (not just removing a thing or two) it might be easier to maintain it with full hard assignment of variables.
Now there is also a question of where to do this variable mangling. The main option is .bbappend in your layer, that's what appends are made for, but you can also do this from your distro configuration (if you're maintaining your own distro it might be easier to have all these tweaks in one place, rather than sprayed into numerous appends) or from your local.conf (which is a nice place to quickly try it out, but probably not something to use in longer term). I usually use .bbappend.
But there is also a completely different approach to this problem, rather than fixing package dependencies you can also fix what some other package provides. If for example you have a kernel configured to have imx-gpu-viv module built right into the main zimage you can do
RPROVIDES_kernel-image += "kernel-module-imx-gpu-viv"
(also in .bbappend, distro configuration or local.conf) and that's it.
In any case your approach to fixing this problem should reflect the difference between your setup and recipe assumptions. If you do have the module, but in a different package, then go for RPROVIDES, if you have some other module providing the same functionality to libgal-mx6 package then fix libgal-mx6 dependencies (and it's better to fix them, meaning not only drop something you don't need, but also add things that are relevant for your setup).
Let's say I'm writing a program, and I want it to follow the XDG Base Directory Specification for where it puts its files (app foo uses $XDG_CONFIG_HOME/foo as the directory for configuration files if XDG_CONFIG_HOME is set and non-blank, or ~/.config/foo, or fails with an error if the home directory can't even be resolved).
Is there a correct/specified behavior for the situation where for example XDG_CONFIG_HOME is set and non-blank, but that directory doesn't exist? Or if there is no such variable, and ~/.config doesn't exist? Is it expected that my program attempt to create it? Or is the non-existance of that directory considered an error on the environment's/system's part, and my program should avoid doing anything about it (just bail with an error)?
Note: I'm not asking if I should create ~/.config/foo - obviously that's a yes; I'm asking if I should create ~/.config itself, if it doesn't exist.
(To be more pedantic: obviously some program should create them - the question is whether it's solely the system's/desktop's/user's job to do so, or if any program should try creating the relevant directories if they don't exist?)
I've tried reading the XDG Base Directory Specification, which says that when attempting to write its files, the program may create the requisite directory, but it's unclear if this is referring to just the application's specific/"personal" sub-directory in the XDG base directories, or if this is meant for the XDG base directories themselves.
P.S. Usually I have a good idea of what tags to use, but here I'm really uncertain: please edit this post or suggest improvements to give it proper tags.
From the XDG Base Directory Specification:
If, when attempting to write a file, the destination directory is
non-existant an attempt should be made to create it with permission
0700. If the destination directory exists already the permissions should not be changed. The application should be prepared to handle
the case where the file could not be written, either because the
directory was non-existant and could not be created, or for any other
reason. In such case it may chose to present an error message to the
user.
I would interpret this so application should try to create the XDG base directory (or any directory required for the destination) and only display an error if it is unable to do so.
I've settled on my own answer after a few years of thinking:
never create non-standard base XDG directories, but
it may be okay to automatically create the standard XDG base directories, and
you should automatically create any of your application's subdirectories within the base directories.
I think it can be good to be automatically helpful, but it is also very important to not worsen a user's mistakes.
If I write XDG_DATA_HOME=~/.locals/hare in my environment variable configuration, I might have wanted that, but it's much more likely that I made a typo of ~/.local/share. So the most helpful, least disruptive, and least wrong thing to do in that case is to report the lack of the requested XDG base directory.
So, if the user has specified a custom XDG base directory, and that base directory does not exist, never try to create it. Don't put your user in a situation where for example next to their standard ~/.config directory they get a ~/.configs or ~/.comfig directory which also contains some of their configurations, until one day they fix the typo and suddenly their programs behave as if they were reset to the defaults. This is a situation where early detection of mistakes is the most helpful thing to do in the long run, so tell the user immediately "this doesn't exist".
But if the user has not asked for a custom base directory, and you're about to use the known, standard location, then it's fine to try to automatically create it, if you ensure you only create it with reasonable ownership, permissions, and so on.
Finally, when the base XDG directory exists, most apps should probably make their own subdirectory inside that, and you definitely should create that app-specific directory, and any other subdirectories inside that one, automatically.
I have some images that are only relevant on a particular platform (let's say some are only for intel core and others are only for sabrelite).
Is it possible that the image automatically sets the MACHINE variable for the build, independently of the local.conf ?
If not, can I at least make the image refuse to build for other machines ?
I tried to do some googling but of course "yocto image selects machine" or similar requests only return generic Yocto tutorials.
Thanks.
No, an image can't influence which machine you're building for.
Background: In OpenEmbedded the concepts of a machine, an image, and a distro iare supposed to be orthogonal to each other. I.e. any image should be buildable for any combination of distro and machine. (Of course, that might not always be true in practice though).
You can make the image refuse to build by setting
COMPATIBLE_MACHINE = "macha"
in your image recipe.
Another idea, if the images are pretty similar, would be to only install the machine specific packages if the image is being built for the correct machine. This can easily be done by:
IMAGE_INSTALL_append_macha = " package1 package2"
Note the leading space in the string. (_append doesn't prepend your string with a space).
This latter part, is what is normally done. Restricting an image to a particular machine is something that's rarely done, at least in public layers.
Note: macha is the imagined name of the machine.
To add packages depending on machine, you could use the python function base_contains or base-conditional. E.G. bitbake-how-to-add-package-depending-on-machine
There is COMPATIBLE_MACHINE = " " for input in the recipe to check for compatible machine.
building-yocto-image-for-dragonboard-410c-how-to-build-chromium
I need to add the MCP7941X RTC linux kernel driver to custom HW with a TMS320DM368 DaVinci processor running embedded-linux 2.6. It seems this can be accomplished by adding one or more patches to the DS1307 RTC driver. As a linux newbie I've not added a patch to the kernel before but I am guessing what I need to do is make a plain text file from this, add the file to kernel/patches, and add a line to install the patch to the series file. I am also concerned about the following notes in this link:
patch depends on:
rtc: ds1307: comment and format cleanup 38f0a1072f
rtc: ds1307: simplify irq setup code f5af1f6ffe
rtc: ds1307: refactor chip_desc table c0920a32b7
Do these notes mean that I need to find and also add these patches to kernel/patches or should I be able to find a single latest and greatest patch that includes the MCP7941X?
Welcome to the sometimes frustrating but always challenging world of Linux kernel patch juggling! Unless you find someone who's already done what you're trying to do, you're pretty much on your own to apply these patches and test the results. Yes, those lines likely indicate patches that must be applied before the patch in question will apply cleanly, but it's easy enough to figure it out.
You didn't say where you got your kernel or what it is based on, nor how you are building it. But if you're just building a 2.6 kernel manually from the command line, I don't think patches are applied automatically. But patches are easy enough to apply and test out. Something like:
$ cd top/level/kernel/dir
$ patch -p1 < your.patch
Note that often you can just feed patch the e-mail without having to format anything. Just try it. patch is smart enough to find the actual formatted patch within the e-mail.
You can use the quilt tool to apply patches to a query. The man page and web searches should make that easy.
Unfortunately, as I said, unless you happen to find someone who already has done that, you won't know the results until you try it and test it. That's the nature of open source.
Finally, in case you don't speak 'git', those 10-digit hex numbers after those patches in the dependency list above refer to git "commits" also called "hashes". Of course, they refer to some specific git kernel repository that isn't identified in your e-mail. Again, the man pages for git and the internet should guide you there.
And as sawdust pointed out, if you don't already have the driver configured into your kernel, you might need to add it using 'make menuconfig' in the kernel configuration. And if the driver isn't there, well, that's another story altogether, and my book "Embedded Linux Primer" has a section detailing how to add config snippets to the kernel build system to add new drivers that aren't already present in your kernel tree.
Good luck.