Phytec Yocto Reference Manual

Add to my manuals
47 Pages

advertisement

Phytec Yocto Reference Manual | Manualzz

Yocto Reference Manual

GCC replaces it by the sysroot path

(here /opt/yogurt/i.MX6-PD15.3-rc/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/).

See the manpage of GCC for more information.

The variables $CFLAGS and $CXXFLAGS contain the compiler debug flag '-g' by default. This includes debugging information in the binary and makes it bigger. Those should be removed in the production image. If you create a

Bitbake recipe, the default behaviour is to turn on '-g', too. The debugging

symbols are used in the SDK rootfs to be able to get debugging information when invoking GDB from the host. Before installing the package to the target rootfs, Bitbake will invoke strip on the program which removes the debugging symbols. They are not found nor required on the target root filesystem per default.

6.8.5 Working with Kernel Modules

You will come to the point where you either need to set some options for a kernel module or you want to blacklist a module. Those things are handled by udev and go into *.conf files in /etc/modprobe.d/*.conf.

If you want to specify an option at buildtime, there are three relevant variables. If you just want to auto load a module which has e.g. no auto load capabilities, add it to

KERNEL_MODULE_AUTOLOAD += "your‐module"  either in the kernel recipe or in the global variable scope.

If you need to specify options for a module you can do so with:

KERNEL_MODULE_AUTOLOAD += "your‐module" 

KERNEL_MODULE_PROBECONF += "your‐module"  module_conf_your‐module = "options your‐module  parametername=parametervalue" 

If you want to blacklist a module from auto loading, you can do it intuitively with:

KERNEL_MODULE_AUTOLOAD += "your‐module" 

KERNEL_MODULE_PROBECONF += "your‐module"  module_conf_your‐module = "blacklist your‐module" 

6.8.6 Working with udev

Udev (Linux dynamic device management) is a system daemon that handles dynamic device

management in /dev.

It is controlled by udev rules that are located in /etc/udev/rules.d/ (sysadmin configuration space) and /lib/udev/rules.d/ (vendor provided).

36 © PHYTEC Messtechnik GmbH 2016 L-813e_3

Here is an example of an udev rule file:

Working with Poky and Bitbake

# file /etc/udev/rules.d/touchscreen.rules 

# Create a symlink to any touchscreen input device 

SUBSYSTEM=="input", KERNEL=="event[0‐9]*", ATTRS{modalias}=="input:*‐ e0*,3,*a0,1,*18,*", SYMLINK+="input/touchscreen0" 

SUBSYSTEM=="input", KERNEL=="event[0‐9]*", ATTRS{modalias}=="ads7846", 

SYMLINK+="input/touchscreen0" 

See

http://www.freedesktop.org/software/systemd/man/udev.html

for more details about the syntax and usage. To get the list of attributes for a specific device that can be used in an udev rule you can use the udevadm info tool. It prints all existing attributes of the device node and its parents. The key value pairs from the output can be copied and pasted into a rule file. Some examples: target$ udevadm info ‐a /dev/mmcblk0  target$ udevadm info ‐a /dev/v4l‐subdev25  target$ udevadm info ‐a ‐p /sys/class/net/eth0 

After changing an udev rule, you have to notify the daemon about that. Otherwise your changes are not reflected. Use the following command: target$ udevadm control ‐‐reload‐rules 

While developing udev rules you should monitor the events in order to see when devices are de- or attached to the system. Use: target$ udevadm monitor 

Furthermore it is very useful to monitor the system log in another shell, especially if the rule executes external scripts. Execute: target$ journalctl ‐f 

You cannot start daemons or heavy scripts in a RUN attribute. See

http://www.freedesktop.org/software/systemd/man/udev.html#RUN{type}

This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.

Starting daemons or other long-running processes is not appropriate for

udev; the forked processes, detached or not, will be unconditionally killed

after the event handling has finished.

You can use the special attribute ENV{SYSTEMD_WANTS}="service-

name.service" and a systemd service instead. See

http://unix.stackexchange.com/questions/63232/what-is-the-correct-way-towrite-a-udev-rule-to-stop-a-service-under-systemd

.

© PHYTEC Messtechnik GmbH 2016 L-813e_3 37

advertisement

Was this manual useful for you? Yes No
Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement

Table of contents