Raspberry Pi serdev driver never reaches probe function - c

I want to write a minimal serdev Linux driver on a Raspberry Pi. Therefore I have to enable the kernel option SERIAL_DEV_CTRL_TTYPORT, but I don't know how. I have tried various options, but my Kernel Module never reaches the Probe function...
Here is what I got already:
I tried to enable the option by changing the /boot/cmdline.txt to:
SERIAL_DEV_CTRL_TTYPORT SERIAL_DEV_CTRL_TTYPORT=y SERIAL_DEV_CTRL_TTYPORT=yes root=PARTUUID=8d696e29-02 rootfstype=ext4 fsck.repair=yes rootwait modules-load=dwc2,g_ether
The device tree overlay:
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835";
fragment#0 {
target = <&uart0>;
status = "okay";
__overlay__ {
my_device {
compatible = "brightlight,echodev";
status = "okay";
};
};
};
};
The Kernel Module:
#include <linux/module.h>
#include <linux/init.h>
#include <linux/serdev.h>
#include <linux/mod_devicetable.h>
#include <linux/property.h>
#include <linux/platform_device.h>
#include <linux/of_device.h>
/* Meta Information */
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Johannes 4 GNU/Linux");
MODULE_DESCRIPTION("A simple serdev example");
/* Declate the probe and remove functions */
static int dt_probe(struct serdev_device *serdev);
static void dt_remove(struct serdev_device *serdev);
static struct of_device_id my_driver_ids[] = {
{
.compatible = "brightlight,echodev",
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, my_driver_ids);
static struct serdev_device_driver my_driver = {
.probe = dt_probe,
.remove = dt_remove,
.driver = {
.name = "echodev",
.of_match_table = my_driver_ids,
},
};
/**
* #brief This function is called on loading the driver
*/
static int dt_probe(struct serdev_device *serdev) {
printk("my_serdev - Now I am in the probe function!");
return 0;
}
/**
* #brief This function is called on unloading the driver
*/
static void dt_remove(struct serdev_device *serdev) {
printk("my_serdev - Now I am in the remove function\n");
}
module_serdev_device_driver(my_driver);
Do you have any tips?
UPDATE 1:
I checked my Kernel .config file and found out, that CONFIG_SERIAL_DEV_CTRL_TTYPORT is already set and enabled. I double checked it with
pi#raspberrypi:~ $ sudo modprobe configs
pi#raspberrypi:~ $ gzip -d /proc/config.gz --stdout | grep SERIAL_DEV
CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
But then, why does my module never reaches the probe function???
Best regards,
Johannes

Ok, I got it, but I don't know exactly why it is working know.
When posting this example, I used dtoverlay to load the device tree overlay:
sudo dtoverlay testoverlay.dtbo
When doing so, I couldn't reach the probe function. Then I copied my overlay to /boot/overlays and added it to /boot/config.txt:
dtoverlay=testoverlay
And after a reboot, I inserted my kernel module and it reached the probe function. Does anyone know why this works now but not before?

Related

How can I get the 'root' boot arg in kernel space?

I am writing a driver and I need to know what disk/partition contains the root filesystem. This can be viewed from userspace using:
cat /proc/cmdline
root=/dev/mmcblk0p1
How can I get the value of root in kernel space?
In order to get the dev_t for the device where your filesystem root is mounted, you can use a strategy similar to what the stat() syscall does. The only exception is that you are not working with __user buffers, so you'll need to use slightly different APIs.
In short, you want to:
Call kern_path() to get a struct path for the path "/".
Call vfs_getattr() passing that path to get a struct kstat.
Check the ->dev member of the struct kstat, which is the root device (dev_t).
If you want, you can also use bdget() to find the block device corresponding to the obtained dev_t, then use bdevname() to get its name (e.g. sda1).
This translates to the following:
struct path root_path;
struct kstat root_stat;
struct block_device *root_device;
char root_device_name[BDEVNAME_SIZE];
kern_path("/", 0, &root_path);
// KERNEL > 4.10
// vfs_getattr(&root_path, &root_stat, STATX_BASIC_STATS, AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW);
// KERNEL <= 4.10
vfs_getattr(&root_path, &root_stat);
pr_info("root device number is 0x%08x; major = %d, minor = %d\n", root_stat.dev, MAJOR(root_stat.dev), MINOR(root_stat.dev));
root_device = bdget(root_stat.dev);
bdevname(root_device, root_device_name);
pr_info("root device name: %s, path: /dev/%s\n", root_device_name, root_device_name);
bdput(root_device);
path_put(&root_path);
Some notes:
I did not do any kind of error checking in the above example, but you most definitely should! See the complete example below.
kern_path() seems to take LOOKUP_* flags defined in linux/namei.h as
second argument, but passing a default value of 0 is also ok.
Likewise, vfs_getattr() takes STATX_* flags defined in linux/stat.h as
third arg. The stat() syscall passes STATX_BASIC_STATS, but passing 0
should be fine too here since we do not need to know anything other
than the device (->dev field), which seems to get populated
regardless of flags. I could not test this though since my kernel is <= 4.10, and these flags are necessary only for kernel > 4.10.
Working example
Here's a complete example of a working kernel module which does the above also applying proper error checking.
// SPDX-License-Identifier: GPL-3.0
#include <linux/kernel.h> // printk(), pr_*()
#include <linux/module.h> // THIS_MODULE, MODULE_VERSION, ...
#include <linux/init.h> // module_{init,exit}
#include <linux/types.h> // dev_t
#include <linux/kdev_t.h> // MAJOR(), MINOR(), MKDEV()
#include <linux/path.h> // struct path
#include <linux/namei.h> // kern_path(), path_put()
#include <linux/stat.h> // struct kstat, STATX_*
#include <linux/fs.h> // vfs_getattr(), struct block_device, bdget(),...
#include <uapi/linux/fcntl.h> // AT_*
#ifdef pr_fmt
#undef pr_fmt
#endif
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
static int __init findrootdev_init(void)
{
struct path root_path;
struct kstat root_stat;
struct block_device *root_device;
char root_device_name[BDEVNAME_SIZE];
int err = 0;
pr_info("init\n");
err = kern_path("/", 0, &root_path);
if (err) {
pr_err("kern_path error %d\n", err);
goto kern_path_fail;
}
// KERNEL > 4.10
// err = vfs_getattr(&root_path, &root_stat, STATX_BASIC_STATS,
// AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW);
// KERNEL <= 4.10
err = vfs_getattr(&root_path, &root_stat);
if (err) {
pr_err("vfs_getattr error %d\n", err);
goto vfs_getattr_fail;
}
pr_info("root device number is 0x%08x; major = %d, minor = %d\n",
root_stat.dev, MAJOR(root_stat.dev), MINOR(root_stat.dev));
root_device = bdget(root_stat.dev);
if (!root_device) {
pr_err("bdget failed\n");
err = -1;
goto bdget_fail;
}
if (!bdevname(root_device, root_device_name)) {
pr_err("bdevname failed\n");
err = -1;
goto bdevname_fail;
}
pr_info("root device name: %s, path: /dev/%s\n",
root_device_name, root_device_name);
bdevname_fail:
bdput(root_device);
bdget_fail:
vfs_getattr_fail:
path_put(&root_path);
kern_path_fail:
return err;
}
static void __exit findrootdev_exit(void)
{
// This function is only needed to be able to unload the module.
pr_info("exit\n");
}
module_init(findrootdev_init);
module_exit(findrootdev_exit);
MODULE_VERSION("0.1");
MODULE_DESCRIPTION("Silly test module to find the root device and its name.");
MODULE_AUTHOR("Marco Bonelli");
MODULE_LICENSE("GPL");
Compiling and loading the above module with insmod generates this output in dmesg:
[12664.685699] findrootdev: init
[12664.685703] findrootdev: root device number is 0x00800003; major = 8, minor = 3
[12664.685706] findrootdev: root device name: sda3, path: /dev/sda3
[12671.671038] findrootdev: exit

What is the use of of_device_id and i2c_device_id?

I was understanding an I2C driver for adxl34x sensor.
If I only keep of_device_id, my probe does not gets called, but if I include i2c_device_id probe gets called.
I checked for some explanation but I get to know that i2c_device_id is used for legacy purpose or board file matching.
Here I am using device tree.
How is it possible that i2c_device_id is making the device recognised?
Is there a dependency in I2C drivers to use both i2c_Device_id and of_device_id??
here is my understanding on this top
id_table is used for legacy i2c devices. See in this code
static const struct i2c_device_id *i2c_match_id(const struct i2c_device_id *id,
const struct i2c_client *client)
{
while (id->name[0]) {
if (strcmp(client->name, id->name) == 0)
return id;
id++;
}
return NULL;
}
There is no device id table reference, while of_device_id
/**
* of_match_device - Tell if a struct device matches an of_device_id list
* #ids: array of of device match structures to search in
* #dev: the of device structure to match against
*
* Used by a driver to check whether an platform_device present in the
* system is in its list of supported devices.
*/
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
if ((!matches) || (!dev->of_node))
return NULL;
return of_match_node(matches, dev->of_node);
}
Uses dev->of_node
So its safe to say both mechanism are isolated and does not depend on each other.
Then why my driver is not getting probed by only using this,
/*
static const struct i2c_device_id adxl34x_id[] = {
{ "adxl345", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, adxl34x_id);
*/
#ifdef CONFIG_OF
static const struct of_device_id adxl34x_of_id[] = {
/*
* The ADXL346 is backward-compatible with the ADXL345. Differences are
* handled by runtime detection of the device model, there's thus no
* need for listing the "adi,adxl346" compatible value explicitly.
*/
{ .compatible = "adi,adxl345", },
/*
* Deprecated, DT nodes should use one or more of the device-specific
* compatible values "adi,adxl345" and "adi,adxl346".
*/
{ .compatible = "adi,adxl34x", },
{ }
};
MODULE_DEVICE_TABLE(of, adxl34x_of_id);
#endif
static struct i2c_driver adxl34x_driver = {
.driver = {
.name = "adxl34x",
//.pm = &adxl34x_i2c_pm,
.of_match_table = of_match_ptr(adxl34x_of_id),
},
.probe = adxl34x_i2c_probe,
.remove = adxl34x_i2c_remove,
//.id_table = adxl34x_id, /*commented i2c_device_id*/
};
Here are some links that I have gone through in order to get some understanding
https://patches.linaro.org/patch/16873/
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/131965.html
https://i2c.wiki.kernel.org/index.php/OF_Modalias
I understood that first of_* style match will happen, then i2c_device_id type match.
In my case, then how of_* is not able to bind then?
Why i2c_device_table is needed if its legacy thing?
You are right. It is true that you need to pass id_table along with the driver structure for I2C if you are using probe callback.
This is because the earlier I2C driver framework used older style of probe function signature that required i2c_device_id to be passed as the second parameter. However, this has now been replaced with i2c_probe_new callback whose function signature shows that it no more needs i2c_device_id parameter anymore.
Here is a link to this code change for reference:
https://elixir.bootlin.com/linux/v5.16.9/source/include/linux/i2c.h#L281

Getting undefined references for C functions while making ESP8266 project

I followed this tutorial for installing a Kaa application into an ESP8266, and it worked after a few modifications: https://kaaproject.github.io/kaa/docs/v0.10.0/Programming-guide/Using-Kaa-endpoint-SDKs/C/SDK-ESP8266/
One of the modifications I had to make was to move a line of code in eagle.app.v6.ld because of byte overflow (arrow points to change I made):
...
.irom0.text : ALIGN(4)
{
_irom0_text_start = ABSOLUTE(.);
*(.literal.* .text.*) --> moved from ".text : ALIGN(4){...}"
...
}
...
After I did this I still had some byte overflow, so I modified the original cmake command from the documentation to disable cmake extensions that were taking up space:
cmake \
-DCMAKE_TOOLCHAIN_FILE=../kaa/toolchains/esp8266.cmake \
-DKAA_PLATFORM=esp8266 \
-DCMAKE_BUILD_TYPE=MinSizeRel \
-DWITH_EXTENSION_CONFIGURATION=OFF \
-DWITH_EXTENSION_EVENT=OFF \
-DWITH_EXTENSION_LOGGING=OFF \
-DWITH_EXTENSION_NOTIFICATION=OFF \
-DWITH_EXTENSION_USER=OFF \
-DWITH_ENCRYPTION=OFF \
-DKAA_MAX_LOG_LEVEL=3 ..
Finally, when I ran the make command. it worked. I then created and flashed the binaries into my ESP. Then I reset my ESP with GPIO0 high (so it can boot from flash) and the ESP sent "Hello, Kaa!" into the serial port I was connected to.
Now, however. I am trying to make it so that my ESP8266 connects to my Kaa server and generates an Endpoint Profile, so I need the code to create a transport channel to communicate to both the Bootstrap server and Operations server.
To do this, I tried using the code from Your First Kaa Application that generates fake temp readings and receives the configuration schema and pushes data to my Cassandra server via log appender:
https://kaaproject.github.io/kaa/docs/v0.10.0/Programming-guide/Your-first-Kaa-application/
So in my attempt to do this, I left my directory the same:
CMakeLists.txt
driver/
uart.h
uart.c
ld/
eagle.app.v6.ld
eagle.rom.addr.v6.ld
kaa/
<put Kaa SDK here> --> replaced with new SDK with log and configuration schema
user/
user_main.c
src/
kaa_demo.c --> replaced with new code from "Your First Kaa Application"
I then replaced this code into my kaa_demo.c file:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <time.h>
#include <kaa/kaa.h>
#include <kaa/platform/kaa_client.h>
#include <kaa/kaa_error.h>
#include <extensions/configuration/kaa_configuration_manager.h>
#include <extensions/logging/kaa_logging.h>
#include <kaa/gen/kaa_logging_gen.h>
#include <kaa/platform/kaa_client.h>
#include <kaa/utilities/kaa_log.h>
#include <kaa/platform-impl/common/ext_log_upload_strategies.h>
static int32_t sample_period;
static time_t last_sample_time;
extern kaa_error_t ext_unlimited_log_storage_create(void **log_storage_context_p, kaa_logger_t *logger);
/* Retrieves current temperature. */
static int32_t get_temperature_sample(void)
{
/* For the sake of example, random data is used */
return rand() % 10 + 25;
}
/* Periodically called by Kaa SDK. */
static void example_callback(void *context)
{
time_t current_time = time(NULL);
/* Respect sample period */
if (difftime(current_time, last_sample_time) >= sample_period) {
int32_t temperature = get_temperature_sample();
printf("Sampled temperature: %i\n", temperature);
last_sample_time = current_time;
kaa_user_log_record_t *log_record = kaa_logging_data_collection_create();
log_record->temperature = temperature;
kaa_logging_add_record(kaa_client_get_context(context)->log_collector, log_record, NULL);
}
}
/* Receives new configuration data. */
static kaa_error_t on_configuration_updated(void *context, const kaa_root_configuration_t *conf)
{
(void) context;
printf("Received configuration data. New sample period: %i seconds\n", conf->sample_period);
sample_period = conf->sample_period;
return KAA_ERR_NONE;
}
int main(void)
{
/* Init random generator used to generate temperature */
srand(time(NULL));
/* Prepare Kaa client. */
kaa_client_t *kaa_client = NULL;
kaa_error_t error = kaa_client_create(&kaa_client, NULL);
if (error) {
return EXIT_FAILURE;
}
/* Configure notification manager. */
kaa_configuration_root_receiver_t receiver = {
.context = NULL,
.on_configuration_updated = on_configuration_updated
};
error = kaa_configuration_manager_set_root_receiver(
kaa_client_get_context(kaa_client)->configuration_manager,
&receiver);
if (error) {
return EXIT_FAILURE;
}
/* Obtain default configuration shipped within SDK. */
const kaa_root_configuration_t *dflt = kaa_configuration_manager_get_configuration(
kaa_client_get_context(kaa_client)->configuration_manager);
printf("Default sample period: %i seconds\n", dflt->sample_period);
sample_period = dflt->sample_period;
/* Configure data collection. */
void *log_storage_context = NULL;
void *log_upload_strategy_context = NULL;
/* The internal memory log storage distributed with Kaa SDK. */
error = ext_unlimited_log_storage_create(&log_storage_context,
kaa_client_get_context(kaa_client)->logger);
if (error) {
return EXIT_FAILURE;
}
/* Create a strategy based on timeout. */
error = ext_log_upload_strategy_create(
kaa_client_get_context(kaa_client), &log_upload_strategy_context,
KAA_LOG_UPLOAD_BY_TIMEOUT_STRATEGY);
if (error) {
return EXIT_FAILURE;
}
/* Strategy will upload logs every 5 seconds. */
error = ext_log_upload_strategy_set_upload_timeout(log_upload_strategy_context, 5);
if (error) {
return EXIT_FAILURE;
}
/* Specify log bucket size constraints. */
kaa_log_bucket_constraints_t bucket_sizes = {
.max_bucket_size = 32, /* Bucket size in bytes. */
.max_bucket_log_count = 2, /* Maximum log count in one bucket. */
};
/* Initialize the log storage and strategy (by default, they are not set). */
error = kaa_logging_init(kaa_client_get_context(kaa_client)->log_collector,
log_storage_context, log_upload_strategy_context, &bucket_sizes);
if (error) {
return EXIT_FAILURE;
}
/* Start Kaa SDK's main loop. example_callback is called once per second. */
error = kaa_client_start(kaa_client, example_callback, kaa_client, 1);
/* Should get here only after Kaa stops. */
kaa_client_destroy(kaa_client);
if (error) {
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
I left the CMakeLists.txt file the same:
cmake_minimum_required(VERSION 3.0.2)
project(kaa_demo C)
# Add Kaa SDK directory
add_subdirectory(kaa)
# Add source files
add_library(kaa_demo_s STATIC user/user_main.c driver/uart.c src/kaa_demo.c)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")
if(NOT DEFINED ESP_RTOS_SDK)
set(ESP_RTOS_SDK /opt/Espressif/esp-rtos-sdk)
endif()
# specify include directories
target_include_directories(kaa_demo_s PUBLIC driver)
target_include_directories(kaa_demo_s PUBLIC .)
target_include_directories(kaa_demo_s PUBLIC
${ESP_RTOS_SDK}/extra_include
${ESP_RTOS_SDK}/include
${ESP_RTOS_SDK}/include/lwip
${ESP_RTOS_SDK}/include/lwip/ipv4
${ESP_RTOS_SDK}/include/lwip/ipv6
${ESP_RTOS_SDK}/include/espressif/
)
exec_program(xtensa-lx106-elf-gcc .
ARGS -print-libgcc-file-name
OUTPUT_VARIABLE ESP8266_LIBGCC
)
link_directories(${CMAKE_CURRENT_SOURCE_DIR}/ld)
target_link_libraries(kaa_demo_s PUBLIC
kaac
${ESP_RTOS_SDK}/lib/libfreertos.a
${ESP_RTOS_SDK}/lib/libhal.a
${ESP_RTOS_SDK}/lib/libpp.a
${ESP_RTOS_SDK}/lib/libphy.a
${ESP_RTOS_SDK}/lib/libnet80211.a
${ESP_RTOS_SDK}/lib/libwpa.a
${ESP_RTOS_SDK}/lib/liblwip.a
${ESP_RTOS_SDK}/lib/libmain.a
${ESP_RTOS_SDK}/lib/libssl.a
${ESP_RTOS_SDK}/lib/libhal.a
${ESP8266_LIBGCC}
-Teagle.app.v6.ld
)
file(WRITE ${CMAKE_BINARY_DIR}/blank.c "")
add_executable(kaa_demo ${CMAKE_BINARY_DIR}/blank.c)
target_link_libraries(kaa_demo kaa_demo_s)
I left the user_main.c file the same:
#include <freertos/FreeRTOS.h>
#include <freertos/task.h>
#include "uart.h"
extern int main(void);
static void main_task(void *pvParameters)
{
(void)pvParameters;
main();
for (;;);
}
void user_init(void)
{
uart_init_new();
UART_SetBaudrate(UART0, 115200);
UART_SetPrintPort(UART0);
portBASE_TYPE error = xTaskCreate(main_task, "main_task", 512, NULL, 2, NULL );
if (error < 0) {
printf("Error creating main_task! Error code: %ld\r\n", error);
}
}
I left eagle.app.v6.ld (except for the modification described in the beginning) and eagle.rom.addr.ld, uart.h, and uart.c the same (obtained from github)
So when I change to the build directory and run this cmake command:
cmake \
-DCMAKE_TOOLCHAIN_FILE=../kaa/toolchains/esp8266.cmake \
-DKAA_PLATFORM=esp8266 \
-DCMAKE_BUILD_TYPE=MinSizeRel \
-DWITH_EXTENSION_CONFIGURATION=OFF \
-DWITH_EXTENSION_EVENT=OFF \
-DWITH_EXTENSION_LOGGING=OFF \
-DWITH_EXTENSION_NOTIFICATION=OFF \
-DWITH_EXTENSION_USER=OFF \
-DWITH_ENCRYPTION=OFF \
-DKAA_MAX_LOG_LEVEL=3 ..
I get this: (esp8266 is my username, kaa-app is the main directory that contains: CMakeLists.txt, build, drivers, etc.)
-- Default SDK location will be used: /opt/Espressif/esp-rtos-sdk
-- Toolchain path: /opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf
-- ESP8266 SDK path: /opt/Espressif/esp-rtos-sdk
==================================
BUILD_TYPE = MinSizeRel
KAA_PLATFORM = esp8266
KAA_MAX_LOG_LEVEL = 3
==================================
BOOTSTRAP ENABLED
PROFILE ENABLED
KAA WILL BE INSTALLED TO /usr/local
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/esp8266/Documents/kaa-app/build
So then I run make, and I get this error:
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.example_callback+0x8): undefined reference to `time'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.example_callback+0xc): undefined reference to `difftime'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.example_callback+0x20): undefined reference to `kaa_logging_add_record'
libkaa_demo_s.a(kaa_demo2.c.obj): In function `example_callback':
kaa_demo2.c:(.text.example_callback+0x35): undefined reference to `time'
kaa_demo2.c:(.text.example_callback+0x42): undefined reference to `difftime'
kaa_demo2.c:(.text.example_callback+0x9e): undefined reference to `kaa_logging_add_record'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x10): undefined reference to `srand'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x14): undefined reference to `kaa_configuration_manager_set_root_receiver'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x18): undefined reference to `kaa_configuration_manager_get_configuration'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x1c): undefined reference to `ext_unlimited_log_storage_create'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x20): undefined reference to `ext_log_upload_strategy_create'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x24): undefined reference to `ext_log_upload_strategy_set_upload_timeout'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x28): undefined reference to `kaa_logging_init'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x3a): undefined reference to `time'
libkaa_demo_s.a(kaa_demo2.c.obj):(.text.startup.main+0x40): undefined reference to `srand'
libkaa_demo_s.a(kaa_demo2.c.obj): In function `main':
kaa_demo2.c:(.text.startup.main+0x69): undefined reference to `kaa_configuration_manager_set_root_receiver'
kaa_demo2.c:(.text.startup.main+0x7b): undefined reference to `kaa_configuration_manager_get_configuration'
kaa_demo2.c:(.text.startup.main+0xa5): undefined reference to `ext_unlimited_log_storage_create'
kaa_demo2.c:(.text.startup.main+0xb8): undefined reference to `ext_log_upload_strategy_create'
kaa_demo2.c:(.text.startup.main+0xc5): undefined reference to `ext_log_upload_strategy_set_upload_timeout'
kaa_demo2.c:(.text.startup.main+0xe6): undefined reference to `kaa_logging_init'
collect2: error: ld returned 1 exit status
CMakeFiles/kaa_demo.dir/build.make:120: recipe for target 'kaa_demo' failed
make[2]: *** [kaa_demo] Error 1
CMakeFiles/Makefile2:107: recipe for target 'CMakeFiles/kaa_demo.dir/all' failed
make[1]: *** [CMakeFiles/kaa_demo.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
So it seems that when it tries linking the files it cannot find the new headers I included:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <time.h>
#include <kaa/kaa.h>
#include <kaa/platform/kaa_client.h>
#include <kaa/kaa_error.h>
#include <extensions/configuration/kaa_configuration_manager.h>
#include <extensions/logging/kaa_logging.h>
#include <kaa/gen/kaa_logging_gen.h>
#include <kaa/platform/kaa_client.h>
#include <kaa/utilities/kaa_log.h>
#include <kaa/platform-impl/common/ext_log_upload_strategies.h>
However, the target directory that is included in CMakeLists.txt contains the header files that I need (for the C headers):
${ESP_RTOS_SDK}/extra_include
So I really do not know what I need to add or modify, I am completely stuck. Any help would be much appreciated! Thanks!
For data_collection you have to set -DWITH_EXTENSION_LOGGING=ON .
For esp8266 you have a different "time.h" library /kaa/src/kaa/platform-impl/esp8266/platform that doesn't support the function time(NULL), but support
kaa_time_t kaa_esp8266_get_time(void);

How to create OpenCL context based on the openGL context on mac os x

I am creating a project about particle system on mac os x. I found similar questions on Internet, and my question is the same as How can I create an shared context between OpenGL and OpenCL with glfw3 on OSX?
,but I still haven't solved my problem yet. Please help me, thank you.
This is a part of my code:
CGLContextObj glContext = CGLGetCurrentContext();
CGLShareGroupObj shareGroup = CGLGetShareGroup(glContext);
cl_context_properties props[] =
{
CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE,
(cl_context_properties)kCGLShareGroup,`
0
};
my error messages are :
particles.cpp:522:2: error: ‘CGLContextObj’ was not declared in this scope
CGLContextObj glContext = CGLGetCurrentContext();
particles.cpp:523:2: error: ‘CGLShareGroupObj’ was not declared in this scope
CGLShareGroupObj shareGroup = CGLGetShareGroup(glContext);
particles.cpp:527:2: error: ‘CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE’ was not declared in this scope
CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE,
particles.cpp:528:25: error: ‘kCGLShareGroup’ was not declared in this scope (cl_context_properties)kCGLShareGroup,0
What header files do you include? Location of symbols in header files:
#include <OpenCL/cl_gl_ext.h> for CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE
#include <OpenGL/CGLDevice.h> for CGLGetShareGroup()
#include <OpenGL/CGLCurrent.h> for CGLGetCurrentContext()
Although you could include the header files above, I find it more convenient to just include the following 2 header files:
#include <OpenCL/opencl.h>
#include <OpenGL/OpenGL.h>
Example code:
CGLContextObj gl_ctx = CGLGetCurrentContext();
CGLShareGroupObj gl_sharegroup = CGLGetShareGroup(gl_ctx);
cl_context default_ctx;
cl_context_properties properties[] = {
CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE, (cl_context_properties) gl_sharegroup,
0
};
cl_int err_code;
default_ctx = clCreateContext( properties,
1,
&device, /* cl_device */
[](const char* errinfo, const void* private_info, size_t cb, void* user_data) -> void {
/* context-creation and runtime error handler */
cout << "Context error: " << errinfo << endl;
}, /* C++11, this parameter can be nullptr */
nullptr /*user_data*/,
&err_code);

Configure Parameters of LED Trigger from Kernel Space

I'm working on an embedded project. Our board is using Linux kernel v3.16.7. I'm working on supporting a couple of peripheral LEDs that monitor activity. I've successfully modified the boot procedure to load the drivers and create sysfs entries in /sys/class/leds/, which is great. I've also attached a oneshot trigger to the leds so I can echo 1 > shot from within /sys/class/leds/actled1\:green/ and the led blinks. Exactly what I want.
However, I want to configure the delays for each LED when I instantiate the driver during boot, and I'm not clear on how to do that. The driver creates sysfs entries in /sys/class/leds/actled1\:green/ called delay_on and delay_off, and I can write to them from userspace to configure the delays, but it should be possible to set their initial values from from kernel space during instantiation. I also want to be able to set the invert parameter (which is just another sysfs entry just like the delays).
How can I configure the parameters of an led trigger when I instantiate the driver from kernel space?
Below is how I instantiate the LED GPIOs. First I set up the structs required:
static struct gpio_led my_leds[] __initdata = {
{
.name = "actled1:green",
.default_trigger = "oneshot"
.gpio = ACTIVITY_LED_GPIO_BASE + 0,
.active_low = true,
},
{
.name = "actled2:red",
.default_trigger = "oneshot"
.gpio = ACTIVITY_LED_GPIO_BASE + 1,
.active_low = true,
},
};
static struct gpio_led_platform_data my_leds_pdata __initdata = {
.num_leds = ARRAY_SIZE(my_leds),
.leds = my_leds,
};
Then, I call this function to create the platform devices:
static int __init setup_my_leds (void)
{
struct platform_device *pdev;
int ret;
pdev = platform_device_alloc("leds-gpio", -1);
if (!pdev) {
return -ENOMEM;
}
ret = platform_device_add_data(pdev,
&my_leds_pdata,
sizeof(my_leds_pdata));
if (ret < 0) {
platform_device_put(pdev);
return ret;
}
ret = platform_device_add(pdev);
if (ret < 0) {
platform_device_put(pdev);
return ret;
}
return 0;
}
The definition for the gpio_led struct is in include/linux/leds.h line 327, and the definition for gpio_led_platform_data is in line 341 of the same file. The definition of platform_device_add_data is in drivers/base/platform.c line 284.
It may be useful to look at the source for the oneshot trigger (drivers/leds/trigger/ledtrig-oneshot.c) in order to answer the question. Also relevant is the "leds-gpio" driver (drivers/leds/leds-gpio.c).
I suspect the answer is somewhere in drivers/base/platform.c and the associated documentation, but I'm not seeing any functions that deal with the data I need.
To address some of the information that I inadvertently left out:
the boot loader sets the kernel arguments, and we can't modify the boot loader. that's fine; the values i want to set are constants and i can hard-code them in.
the driver is baked into the kernel at compile time (and, i presume, loaded by the bootloader) rather than loading a .ko with modprobe later.
i would love a general way to set arbitrary trigger parameters, not only oneshot's delay_on / delay_off. for example, oneshot's invert parameter.
i'm totally fine modifying oneshot / creating new triggers. in fact, once i get it working with oneshot, i'll need to create a new trigger that expands upon oneshot (which is also the reason i need to set arbitrary parameters).
There are a few issues and I think I've found the solutions, but even though you provided a good deal of info, there were some things missing, so I'll enumerate for all possible scenarios, so be patient ...
(1) Getting the initial values you want to set. I presume you have already figured this out, but ... You can get these from kernel cmdline parsing (e.g. you add the values to /boot/grub2/grub.cfg as myleds.delay_on=.... If you're loading via modprobe, you set a module parameter. These could also be a config file as in myleds.config_file=/etc/sysconfig/myleds.conf
(2) You could set them inside your setup_my_leds [except for the recalcitrance of oneshot_trig_activate--which we'll deal with soon enough]. From drivers/base/platform.c:
/**
* arch_setup_pdev_archdata - Allow manipulation of archdata before its used
* #pdev: platform device
*
* This is called before platform_device_add() such that any pdev_archdata may
* be setup before the platform_notifier is called. So if a user needs to
* manipulate any relevant information in the pdev_archdata they can do:
*
* platform_device_alloc()
* ... manipulate ...
* platform_device_add()
*
* And if they don't care they can just call platform_device_register() and
* everything will just work out.
*/
So, with that in mind, let's change your setup function slightly:
static int __init setup_my_leds (void)
{
struct platform_device *pdev;
int ret;
// get initial values you want to set, possibly storing away for later use
my_leds_get_init_values(...);
pdev = platform_device_alloc("leds-gpio", -1);
if (!pdev) {
return -ENOMEM;
}
// Choice (1): set your initial values in my_leds_pdata here
my_leds_set_init_values(&my_leds_pdata);
// NOTE: just does kmemdup and sets pdev->dev.platform_data
ret = platform_device_add_data(pdev,
&my_leds_pdata,
sizeof(my_leds_pdata));
if (ret < 0) {
platform_device_put(pdev);
return ret;
}
// Choice (2): set your initial values in pdev->dev.platform_data here
my_leds_set_init_values(pdev->dev.platform_data);
ret = platform_device_add(pdev);
if (ret < 0) {
platform_device_put(pdev);
return ret;
}
return 0;
}
(3) Unfortunately, since you're using .default_trigger = "oneshot", the above data will get blasted by oneshot_trig_activate in drivers/leds/trigger/ledtrig-oneshot.c. So, we need to deal with that.
Option (A): Assuming you can rebuild the whole kernel as you choose, just modify oneshot_trig_activate in ledtrig-oneshot.c and remove the the lines that use DEFAULT_DELAY. This is only really useful if you know that it's not used by anything else in your system that might need the default values.
Option (B): If you're not allowed to modify ledtrig-oneshot.c, but are allowed to add new triggers to drivers/leds/trigger, copy the file to (e.g.) ledtrig-oneshot2.c and do the changes there. You'll need to change the .name to .name = "oneshot2". The easy way [in vi, of course :-)] is :%s/oneshot/oneshot2/g. You'll also need to add a new entry in the Kconfig and Makefile for this. Then, change your struct definition to use the new driver: .default_trigger = "oneshot2"
Option (C): Assuming you can't [or don't want to] touch the drivers/leds/trigger directory, copy ledtrig-oneshot.c to your driver directory [renaming as appropriate]. Do the edits from option (B) above there. With some trickery in your Makefile, you can get it to build both my_led_driver.ko and ledtrig-oneshot2.ko. You'll need modify your Kconfig, possibly adding a depends on LED_TRIGGERS for the led trigger driver. You could also put the two into separate subdirectories and the individual Makefile/Kconfig might be simpler: my_led/my_driver and my_led/my_trigger
Option (C) would be more work up front, but might be cleaner and more portable in the long run. Of course, you could do option (A) for proof-of-concept, then do option (B), and do the "final ship" as option (C).
An alternate way for when you set the initial values: Remember the comment for my_leds_get_init_values was possibly storing away for later use. You could change oneshot2_trig_activate to call it instead of using DEFAULT_DELAY. I don't like this quite as much and prefer the solutions that simply neuter oneshot_trig_activate's offensive behavior. But, with some testing, you may find that this is the way you have to do it.
Hopefully, the above will work. If not, edit your question with additional info and/or restrictions [and send me a comment], and I'll be glad to update my answer [I've been doing drivers for 40+].
UPDATE: Okay, herein is a fully annotated and modified LED trigger driver that you can use as a drop in replacement for drivers/led/trigger/ledtrig-oneshot.c.
Because the invert parameter can not be passed directly through any standard struct you have access to in your setup function [i.e. it's stored in a private struct inside the trigger driver], remove the "Choice (1)" and "Choice (2)". We'll set them all at once inside the [modified] oneshot_trig_activate.
Also, the init parameters you want must be set up and stored as globals by the my_leds_get_init_values so the trigger driver can find them. That is, there is no way to do this cleanly (e.g. with a pointer to a private struct that gets passed around) as the structs you have access to in setup don't have a field for this. See the top part of the trigger driver for discussion on this.
My first step was to annotate the base driver with descriptive comments. There were no comments in it, except for K&R style for copyright and a single one-liner. My annotations are ANSI ("//") comments.
If I were taking over the driver, I would add these and leave them in. However, my level of comments might be considered "over-commenting" according to the kernel style guide and might be considered "cruft", particularly for a driver that is this straightforward.
Next step was to add the necessary changes. All places that have additions/changes are marked with a comment block that starts with "C:". These are the important places to look. Note that these comments are legitimate candidates to leave in. In other more complex drivers, the level of commenting is up to the author. The "C:" is just to highlight the places for you.
With the annotations, a straight line read through might be easier now. Also, a diff -u might also help. If you've got everything under git, so much the better.
Because of all this, I'd remove the "Option (A)" [direct modification of the original file] and do "Option (B)" or "Option (C)" only.
The trigger driver uses all static definitions, so the global edit I suggested before is not needed. I did do .name = "myled_oneshot";, so you'll need to match that with .default_trigger = "myled_oneshot";. Feel free to use my_leds_whatever to be consistent with your existing naming convention. When I do this for myself, I usually use my initials, so it becomes ce_leds_whatever--YMMV
Anyway, here's the entire modified trigger driver. Note that I've done the editing, but I've not tried to compile/build it.
/*
* One-shot LED Trigger
*
* Copyright 2012, Fabio Baltieri <fabio.baltieri#gmail.com>
*
* Based on ledtrig-timer.c by Richard Purdie <rpurdie#openedhand.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/device.h>
#include <linux/ctype.h>
#include <linux/slab.h>
#include <linux/leds.h>
#include "../leds.h"
// C: we need to get access to the init data populated by the setup function
// we have the "clean way" with a struct definition inside a header file and
// the "dirty way" using three separate int globals
// in either case, the externs referenced here must be defined in the "my_leds"
// driver as global
// C: the "clean way"
// (1) requires that we have a path to the .h (e.g. -I<whatever)
// (2) this would be easier/preferable for the "Option (C)"
// (3) once done, easily extensible [probably not a consideration here]
#ifdef MYLED_USESTRUCT
#include "whatever/myled_init.h"
extern struct myled_init myled_init;
// C: the "ugly way"
// (1) no need to use a separate .h file
// (2) three separate global variables is wasteful
// (3) more than three, and we really should consider the "struct"
#else
extern int myled_init_delay_on;
extern int myled_init_delay_off;
extern int myled_init_invert;
#endif
#define DEFAULT_DELAY 100
// oneshot trigger driver private data
struct oneshot_trig_data {
unsigned int invert; // current invert state
};
// arm oneshot sequence from sysfs write to shot file
static ssize_t led_shot(struct device *dev,
struct device_attribute *attr, const char *buf, size_t size)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct oneshot_trig_data *oneshot_data = led_cdev->trigger_data;
led_blink_set_oneshot(led_cdev,
&led_cdev->blink_delay_on, &led_cdev->blink_delay_off,
oneshot_data->invert);
/* content is ignored */
return size;
}
// show invert state for "cat invert"
static ssize_t led_invert_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct oneshot_trig_data *oneshot_data = led_cdev->trigger_data;
return sprintf(buf, "%u\n", oneshot_data->invert);
}
// set invert from sysfs write to invert file (e.g. echo 1 > invert)
static ssize_t led_invert_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t size)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct oneshot_trig_data *oneshot_data = led_cdev->trigger_data;
unsigned long state;
int ret;
ret = kstrtoul(buf, 0, &state);
if (ret)
return ret;
oneshot_data->invert = !!state;
if (oneshot_data->invert)
led_set_brightness_async(led_cdev, LED_FULL);
else
led_set_brightness_async(led_cdev, LED_OFF);
return size;
}
// show delay_on state for "cat delay_on"
static ssize_t led_delay_on_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
return sprintf(buf, "%lu\n", led_cdev->blink_delay_on);
}
// set delay_on from sysfs write to delay_on file (e.g. echo 20 > delay_on)
static ssize_t led_delay_on_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t size)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
unsigned long state;
int ret;
ret = kstrtoul(buf, 0, &state);
if (ret)
return ret;
led_cdev->blink_delay_on = state;
return size;
}
// show delay_off state for "cat delay_off"
static ssize_t led_delay_off_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
return sprintf(buf, "%lu\n", led_cdev->blink_delay_off);
}
// set delay_off from sysfs write to delay_off file (e.g. echo 20 > delay_off)
static ssize_t led_delay_off_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t size)
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
unsigned long state;
int ret;
ret = kstrtoul(buf, 0, &state);
if (ret)
return ret;
led_cdev->blink_delay_off = state;
return size;
}
// these are the "attribute" definitions -- one for each sysfs entry
// pointers to these show up in the above functions as the "attr" argument
static DEVICE_ATTR(delay_on, 0644, led_delay_on_show, led_delay_on_store);
static DEVICE_ATTR(delay_off, 0644, led_delay_off_show, led_delay_off_store);
static DEVICE_ATTR(invert, 0644, led_invert_show, led_invert_store);
static DEVICE_ATTR(shot, 0200, NULL, led_shot);
// activate the trigger device
static void oneshot_trig_activate(struct led_classdev *led_cdev)
{
struct oneshot_trig_data *oneshot_data;
int rc;
// create an instance of the private data we need
oneshot_data = kzalloc(sizeof(*oneshot_data), GFP_KERNEL);
if (!oneshot_data)
return;
// save the pointer in the led class struct so it's available to other
// functions above
led_cdev->trigger_data = oneshot_data;
// attach the sysfs entries
rc = device_create_file(led_cdev->dev, &dev_attr_delay_on);
if (rc)
goto err_out_trig_data;
rc = device_create_file(led_cdev->dev, &dev_attr_delay_off);
if (rc)
goto err_out_delayon;
rc = device_create_file(led_cdev->dev, &dev_attr_invert);
if (rc)
goto err_out_delayoff;
rc = device_create_file(led_cdev->dev, &dev_attr_shot);
if (rc)
goto err_out_invert;
// C: this is what the driver used to do
#if 0
led_cdev->blink_delay_on = DEFAULT_DELAY;
led_cdev->blink_delay_off = DEFAULT_DELAY;
#endif
led_cdev->activated = true;
// C: from here to the return is what the modified driver must do
#ifdef MYLED_USESTRUCT
led_cdev->blink_delay_on = myled_init.delay_on;
led_cdev->blink_delay_off = myled_init.delay_off;
oneshot_data->invert = myled_init.invert;
#else
led_cdev->blink_delay_on = myled_init_delay_on;
led_cdev->blink_delay_off = myled_init_delay_off;
oneshot_data->invert = myled_init_invert;
#endif
// C: if invert is off, nothing to do -- just like before
// if invert is set, we implement this as if we just got an instantaneous
// write to the sysfs "invert" file (which would call led_invert_store
// above)
// C: this is a direct rip-off of the above led_invert_store function which
// we can _not_ call here directly because we don't have access to the
// data it needs for its arguments [at least, not conveniently]
// so, we extract the one line we actually need
if (oneshot_data->invert)
led_set_brightness_async(led_cdev, LED_FULL);
return;
// release everything if an error occurs
err_out_invert:
device_remove_file(led_cdev->dev, &dev_attr_invert);
err_out_delayoff:
device_remove_file(led_cdev->dev, &dev_attr_delay_off);
err_out_delayon:
device_remove_file(led_cdev->dev, &dev_attr_delay_on);
err_out_trig_data:
kfree(led_cdev->trigger_data);
}
// deactivate the trigger device
static void oneshot_trig_deactivate(struct led_classdev *led_cdev)
{
struct oneshot_trig_data *oneshot_data = led_cdev->trigger_data;
// release/destroy all the sysfs entries [and free the private data]
if (led_cdev->activated) {
device_remove_file(led_cdev->dev, &dev_attr_delay_on);
device_remove_file(led_cdev->dev, &dev_attr_delay_off);
device_remove_file(led_cdev->dev, &dev_attr_invert);
device_remove_file(led_cdev->dev, &dev_attr_shot);
kfree(oneshot_data);
led_cdev->activated = false;
}
/* Stop blinking */
led_set_brightness(led_cdev, LED_OFF);
}
// definition/control for trigger device registration
// C: changed the name to "myled_oneshot"
static struct led_trigger oneshot_led_trigger = {
.name = "myled_oneshot",
.activate = oneshot_trig_activate,
.deactivate = oneshot_trig_deactivate,
};
// module init function -- register the trigger device
static int __init oneshot_trig_init(void)
{
return led_trigger_register(&oneshot_led_trigger);
}
// module exit function -- unregister the trigger device
static void __exit oneshot_trig_exit(void)
{
led_trigger_unregister(&oneshot_led_trigger);
}
module_init(oneshot_trig_init);
module_exit(oneshot_trig_exit);
MODULE_AUTHOR("Fabio Baltieri <fabio.baltieri#gmail.com>");
MODULE_DESCRIPTION("One-shot LED trigger");
MODULE_LICENSE("GPL");
As you can see in ledtrig-oneshot.c, the delay is always initialized with DEFAULT_DELAY. Unfortunately, if you want to be able to configure a different value at startup, this is a mechanism you will have to implement..
As Craig answered it should be from kernel command line options, but there could be a problem with embedded systems where the boot-loader passes the command line parameters and the boot-loaders cannot be modified, they are usually OTP . In that case I see only 2 options
hard coding in the kernel init function
as mac address is stored in eeprom for the nic driver to read, if the values can be stored in a flash (nor) and the value read on boot. This can be done after creating the mtd partitions during kernel boot.

Resources