I had a question about adding a new machine in Yocto.
I am trying to add both a new layer in Yocto, and a new machine. The machine is based on Atmels SAMA5D27-SOM1-EK-SD evaluation board. I want to enable another UART for this board.
I cloned the kernel source for this board (linux-at91) and added another DTS file based off of at91sama5d27-som1-ek-sd.dts file. I made the changes to enable UART0. I then added this new DTS file to the Makefile in linux-at91/arch/arm/boot/dts . I made a patch to save these changes.
I'm using meta-atmel layer and was following instructions outlined here to build the image for this board.
I have defined another layer that will act as the new Yocto layer that defines my custom machine. I have added some .bbappend files in recipes-kernel to add a patch (which adds a new dts file to the linux at91 kernel source) and to add our custom machine as a compatible machine. My understanding was that we could continue to use the definitions in the meta-atmel layer, but add .bbappend files in the meta-axon layer in the same path, and that would apply the changes that we want.
I have done the same for the recipes-bsp directory. In the meta-axon layer, all the .bbappend files in recipes-bsp only add our custom machine to the list of compatible machines.
However, when I go ahead and build, I get this error:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'at91bootstrap-sam-ba'
at91bootstrap-sam-ba was skipped: incompatible with machine axon-ft3-sp-machine (not in COMPATIBLE_MACHINE)
I'm confused because the recipe file that defines at91bootstrap-sam-ba in meta-atmel does not mention any compatible machines, so I would want to use it from the meta-atmel layer without changing it at all. (edited)
It actually does mention compatible machines.
In at91bootstrap-sam-ba recipe[1], you can find the following line:
require at91bootstrap_${PV}.bb
Let's check out in this recipe then[2]:
COMPATIBLE_MACHINE = '(sama5d3xek|sama5d3-xplained|sama5d3-xplained-sd|at91sam9x5ek|at91sam9rlek|at91sam9m10g45ek|sama5d4ek|sama5d4-xplained|sama5d4-xplained-sd|sama5d2-xplained|sama5d2-xplained-sd|sama5d2-xplained-emmc|sama5d2-ptc-ek|sama5d2-ptc-ek-sd|sama5d27-som1-ek|sama5d27-som1-ek-sd|sama5d2-icp-sd|sam9x60ek|sam9x60ek-sd|sama5d27-wlsom1-ek-sd)'
Using bitbake at91bootstrap-sam-ba -e would show you that, indeed, COMPATIBLE_MACHINE is set and would even tell you where it was set.
P.S.: In some cases, it might actually be a good idea for your custom machine to require the original machine on which it is based (e.g. sama5d27-som1-ek-sd) and make the name of the original machine part of MACHINE_OVERRIDES so that you don't have to add a bbappend for each recipe with a COMPATIBLE_MACHINE. Be careful with the order in MACHINE_OVERRIDES, it is evaluated from right to left with rightmost OVERRIDES being of the highest priority. (Use bitbake -e <recipe> to be sure it's correctly set).
[1] https://github.com/linux4sam/meta-atmel/blob/master/recipes-bsp/at91bootstrap/at91bootstrap-sam-ba_3.9.2.bb#L1
[2] https://github.com/linux4sam/meta-atmel/blob/master/recipes-bsp/at91bootstrap/at91bootstrap_3.9.2.bb#L5
Related
I'm pretty new to the yocto project so bear with me if these are trivial problems.
I followed this(https://hub.mender.io/t/preparing-the-yocto-project-environment-from-scratch/801) tutorial and was able to compile a minimal yocto image, flash that image to a SD card and run it on a raspberrypi3.
My next goal is to add the azure device update layer(https://github.com/hiroyha1/meta-azure-device-update)
I cloned the repository to the sources directory and tried to add this layer via bitbake. Since LAYERSERIES_COMPAT was set to "warrior" this failed. I changed that variable to "kirkstone" and updated the syntax in all bb files, basically changing _append/_prepend to :append/:prepend.
Now when I try to run bitbake adu-image-base I get this error:
ERROR: No recipes in default available for:
$MYWORKDIR/sources/meta-azure-device-update/recipes-bsp/u-boot/u-boot-fw-utils_%.bbappend
I searched for this error and found out that sometimes there are "dangling appends". As I found out a fix for that could be to set "BB_DANGLINGAPPENDS_WARNONLY ?= "true"" in the layer.conf.
After running bitbake adu-base-image again the next error is:
ERROR: adu-base-image-1.0-r0 do_rootfs: Could not invoke dnf. [...]
No match for argument: adu-agent-service Error: Unable to find a
match: adu-agent
So I'm pretty stuck here. I think that the dangling appends are the reason for that error - the adu-agent-service isnt build so cannot be packed in the image, for me this makes sense since the root_fs is part of the OTA functionality. My approach would be to revert the "BB_DANGLINGAPPENDS_WARNONLY" change and get this layer to build properly, but I'm struggling to debug this further.
So how can I get this layer to work with the kirkstone release?
P.S if the proposed layer is utterly broken and there is no easy way to get this to work with the kirkstone release a hint would be great.
The part I'm working on is kernel-devsrc, which is in the recipe recipes-kernel.
I want to change one of the source .c files in drivers/usb/serial in kernal-devsrc. From some of the online materials, I need to:
Have my own layer
In the layer, need a recipe with the same name as recipes-kernel (and further more, recipes-kernel/linux)
Add the .bbappend file and patch file.
The problem is: to create a patch file I need to know the 2 git SHAs of before and after the change, but I don't have access to the third party recipes-kernel, how do I get the SHA??
OR, if that is the wrong way to do this, could you point out the right way to do it? Thanks!
NOTE: This is problem is not like this one: How patching works in yocto, which the author has access to the source code (.c and .h files). I DON"T have access to the source code, the yotco kernel I'm working on is from a public git repo, and I am not able to git commit to get the SHA, which is necessary to create the patch file.
So, the way I do it is to use Quilt, follow the steps there then good to go:
https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#using-a-quilt-workflow
I don't need to know the SHA (though I still don't know why others in my organization end up writing SHAs in the patch files and how did they know the SHAs).
The power of Yocto is precisely that it makes it relatively straightforward to patch any existing recipes, without requiring write access to the upstream project source code or Yocto layer.
As a pre-requisite, the project needs to have its own layer to track the patches. Then, the easiest way it to use devtool. The general idea is to:
Create a local sandbox to patch the project: devtool modify RECIPE_NAME (use the name of the target recipe here). This command will create a temporary workspace and print the path to this workspace.
Move to the temporary workspace, apply the needed patches and commit them one by one.
Once all the desired patches have been applied, use devtool finish RECIPE_NAME CUSTOM_LAYER_NAME to save the chances as clean patch files in a bbappend in the custom layer.
Under the hood, devtool modify initializes a (writable) git repository in the sandbox. When devtool finish is invoked, devtool checks the list of extra-commits and saves them as patch files in a .bbappend in the target layer.
I have installed RedHawk 1.10.0 using Ubuntu 14.0.4LTS as described in appendix F of the RedHawk documentation. I also installed standalone IDE from SourceForge
again, as specified in appendix F, chapter 2.5. The IDE comes up looking ok, but here are the problems:
The components list is empty (there are supposed to be a set of pre-defined components). The directory is empty as well on the file system.
When attempting to generate C++ component, I get:
"Exception running "/bin/redhawk-codegen" /bin/redhawk-codegen - template=redhawk.codegen.jinja.cpp.component.pull --checkSupport
In detail, it said: bin/redhawk-codegen":error=2 no such file or directory. The /bin/redhawk-codegen is there under OSSIEHOME. The "pull" template is under: /usr/local/lib/python2.7/dist-packages/redhawk/codegen/jinja/cpp/component.
If I attempt to start Domain Manager I get an error "no domain configuration available".
So for all these problems it is obvious that I need to get a better picture of the expected file layout of all IDE and core RedHawk components. This is not clear from the documentation. Is there a starting point where I can begin debugging "where to find things"?
Regarding your first issue:
When installing for CentOS using the RPMs, a number of components, and devices are pre-packaged into the yum repository. When installing from source, as one must do for Ubuntu in 1.10, the pieces of Redhawk are modular and are installed individually.
The directions from Appendix F walk the user through installing each of the parts that make up the framework. The core, a GPP, bulkio, bustio, and the code generator. This does not include any components or devices (other than the GPP). To install these, you'll need to clone them from their respective git repositories and build and install from source either from the command line, or through the REDHAWK IDE. Building and installing the components from the command line follows the same pattern as the framework, there is a reconf script, which creates the configure script which creates the makefile script. eg. ./reconf; ./configure; make; sudo make install
Regarding your second issue:
These symptoms seem to point to the OSSIEHOME and SDRROOT variables not being set. Make sure that the OSSIEHOME and SDRROOT variables are set in the terminal using "echo $SDRROOT" and "echo $OSSIEHOME" prior to running the IDE. Keep in mind that the environments are unique to each session so, for example, having them set in one bash terminal does not guarantee they are set when launching the IDE from a desktop shortcut. Confirm they are set in your terminal, then launch the IDE from the same terminal.
Regarding your last issue:
This is likely also caused by your second issue. However, if it is not resolved following the above steps, take a look within $SDRROOT/dom/domain There should be two files. One DomainManager.dmd.xml.template and one DomainManager.dmd.xml. If all you have is the template then you need to create the DomainManager.dmd.xml file by copying the template. Then edit it and fill in the id and name fields. The default name is generally REDHAWK_DEV and the id should be a UUID.
I wrote a basic character driver for beagle-bone which prints two message in 1 second interval via a workqueue and a tasklet using printk.
At first i build it as module driver, generated .ko file, load it using insmod command and the print is coming when viewed via dmesg.
Then i built as inbuilt driver and load the uImage and after bootup i checked the dmesg prints. But there is no prints.
In the .config file
CONFIG_MY_DRIVER=y
So its taken as built in driver i think.
How can i confirm whether its actually built in the final image. No error was reported while building.
Is there any additional steps to be done for loading the build in driver.
Please pardon me if i went wrong on any basics. I am really new to linux.
This means that you added it probably somewhere to Kconfig file:
"CONFIG_MY_DRIVER=y"
but, Have you added it to Makefile? It works like that, then kernel during a building an Image, takes all of this directives "CONFIG_*" and use it to build particular source files from Makefile.
Example:
cat fs/ext2/Makefile
ext2-$(CONFIG_EXT2_FS_SECURITY) += xattr_security.o
cat fs/ext2/Kconfig
config EXT2_FS_SECURITY
bool "Ext2 Security Labels"
depends on EXT2_FS_XATTR
so in this example above if your source file is xattr_security.c then you should get xattr_security.o file in fs/ext2 dir, when this is build. You should also see it if your file is build, during a compilation process.
I’m trying to setup SMACK on my system but am having some strange problems.
I have SMACK turned on in my kernel and have added the line:
smackfs /smack smackfs smackfsdef=* 0 0
to my /etc/fstab file. SMACK seems to be enforcing labelled subject/object access as expected. But when I create new files the files do not have the labels of the creating process. Instead the labels are blank.
My kernel version is 3.4.36. My kernel config includes:
CONFIG_NETLABEL=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SMACK=y
CONFIG_DEFAULT_SECURITY_SMACK=y
CONFIG_DEFAULT_SECURITY="smack"
Found the answer to my own question. The yaffs2 file system that my device runs on does not fully support extended attributes for newly created files.