Error inserting kernel module on target device - linux

I have written a basic kernel module which creates a thread and then starts the thread.
I am compiling the kernel module for Beagle bone black board and i have the kernel source code for Beagle bone black.
The kernel module source code(kmodule.c) and Makefile is given below.
/**kmodule.c**/
#include<linux/module.h>
#include<linux/kernel.h>
#include<linux/kthread.h>
#include<linux/types.h>
#include<linux/sched.h> //For wake_up_process()
static struct task_struct *th_handler = NULL;
static s32 thread_function(void *pdata);
static s32 __init thread_module_init(void)
{
th_handler = kthread_create(thread_function,NULL,"test_thread");
if(!IS_ERR_OR_NULL(th_handler))
{
wake_up_process(th_handler);
}
pr_info("%s done.",__FUNCTION__);
return 0;
}
static void __exit thread_module_deinit(void)
{
pr_info("%s done.",__FUNCTION__);
}
static s32 thread_function(void *pdata)
{
pr_info("Inside thread function.");
}
MODULE_LICENSE("GPL");
MODULE_VERSION("0.1");
MODULE_AUTHOR("Author name");
MODULE_DESCRIPTION("Description");
/**Makefile**/
export ARCH=arm
export CROSS_COMPILE=~/cross_compiler/arm-linux-gnueabi- #Cross compiler for Beagle Bone black
BBB_KERNEL_SRC_PATH=~/bbb_kernelsrc #Kernel source path for Beagle bone black.
obj-m += threadmodule.o
threadmodule-objs := kmodule.o
all:
make -C $(BBB_KERNEL_SRC_PATH) M=$(PWD) modules
clean:
make -C $(BBB_KERNEL_SRC_PATH) M=$(PWD) clean
The kernel module builds fine without errors and .ko file is generated.
When i insert the kernel module on Beagle bone board black i get the following error.
insmod: ERROR: could not insert module threadmodule.ko: Invalid
parameters
Also dmesg|tail -20 output:
threadmodule: disagrees about version version of symbol wake_up_process
threadmodule: Unknown symbol wake_up_process(err -22)
Any idea why this error is coming.
Beagle bone black kernel source version : 4.19.94

Related

Simple GPIO Device Tree Example for Beaglebone Black Deb 10.3

My goal is to write a simple .dts file (to be compiled to .dtbo using DT 1.4.4) to configure a GPIO output on boot on a Beaglebone Black Rev C running Debian 10.3
I intend to place the .dtbo in /lib/firmware and then specify it in /boot/uEnv.txt
I understand some parts of the .dts file and have tried decompiling exisiting .dtbo files in /lib/firmware/ for guidance but none of them are a simple GPIO output example. A lot of online resources involve make and make install but I believe DT should be able to handle it by now right?
I was able to get the following to compile but with issue:
/* dtc -O dtb -o BB-P8_13-LED.dtbo -b 0 -# BB-P8_13-LED-00A0.dts */
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone-black";
/* identification */
part-number = "BB-P8_13-LED";
version = "00A0";
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.13", /* GPIO_23 */
/* the hardware ip uses */
"gpio23";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_gpio23_pin: pinmux_bb_gpio23_pin {
pinctrl-single,pins = < 0x024 0x07 >; /*P8_13 GPIO23 MODE7*/
};
};
};
fragment#1 {
target = <&gpio23>;
__overlay__ {
leds {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_gpio23_pin>;
compatible = "gpio-leds";
P8_13 {
label = "P8_13";
default-state = "on";
};
};
};
};
};
Q: Why does loading this .dtbo in /boot/uEnv.txt cause all other GPIOs to disappear from /sys/class/gpio/? I thought fragment0 was for excluding a single gpio, not all of them.
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-P8_13-LED-00A0.dtbo
Q: Where are the files for controlling the GPIO (for testing) or rather what can I add to my .dts file so the gpio23 still appears in /sys/class/gpio or even /sys/class/leds? Ultimately I want to be able to control this GPIO with Node-RED.
Q: Do I need to be consistent with my use of P8.13 vs. P8_13? I think I'm mixing up terminology used in .dts files that get compiled with make vs DT.
Q: I think my fragment#1 P8_13 child node is missing something to specify the gpio bank and active high/low setting. Something like "gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;" Where can I look to research which bank GPIO23 is in? What does the '19' mean in that statement?
So Dr. Derek Molly did a really nice job of laying this out and I was able to use the example in his repo. Here is a page he made for explaining how to configure GPIO at boot using Device Tree Overlays:
http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/
Even though his solution is for kernel 3.8 I was able to get the following to compile on 4.19
/* dtc -O dtb -o BB-P8_13-LED-00A0.dtbo -b 0 -# BB-P8_13-LED-00A0.dts */
/dts-v1/;
/plugin/;
/{
compatible = "ti,beaglebone-black";
part-number = "BB-P8_13-LED";
version = "00A0";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
pinctrl_test: BB-P8_13-LED {
pinctrl-single,pins = <
0x024 0x27 /* P8_13 9 PULLUP ENABLED OUTPUT MODE7 - The LED Output */
>;
};
};
};
fragment#1 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_test>;
status = "okay";
};
};
};
};
All that needs to be edited for a different GPIO pin is the "0x024" (address offset) and the "0x27" to set various aspects of the GPIO like pullup vs. pulldown and pinmux mode. Derek Molly has an older version of his guide which has the table for building the pinmux binary values (that need to be converted to hex): http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
Most of the information is available in the Beaglebone SRM which I should probably read at some point.
The .dts file in my first answer did not fix my problem. GPIO P8_13 still boots as an input. After more digging and testing I have discovered it is NOT possible to make a GPIO direction survive a reboot. It will always boot to the default and the best you can do is enable a pullup or pulldown resistor to keep the pin high or low until a custom service file (or program) can write to /sys/class/gpio/gpioXXX/direction. I even tried decompiling am335x-boneblack.dtb, editing it, and re-compiling with no luck.
This is sad and incredibly frustrating. What good is an output that flickers during reboot? Guess I'll have to compensate with fancy external circuitry.
Per the original question, you can author a dts file where the GPIO remains in /sys/gpio/class/. See the article I wrote below for an example that works this way.
https://takeofftechnical.com/beaglebone-black-led-control/

i2c driver boot up - raspbian

I'm relative new to device drivers on linux.
What im trying to achieve is that on boot-up of my Raspberry an external RGB driver will receive an i2c command so you can see a LED light up at boot.
My approach is trying to accomplish this via a kernel module that will be loaded at bootup.
I tried a lot of things to achieve this, but at the moment I feel like I have a knowledge gap. Maybe someone can help me? (note that its not a hardware issue, from user space I can send commands to the device.)
My kernel module code is as following:
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/regmap.h>
MODULE_AUTHOR ("Niels");
MODULE_DESCRIPTION("driver rgb led");
MODULE_LICENSE("GPL");
/*CAT3626 control registers*/
#define CAT3626_ADDRESS 0x66
#define CAT3626_ENA 0x03
#define CAT3626_REGA 0x00
#define CAT3626_REGB 0x01
#define CAT3626_REGC 0x02
struct cat3626 {
struct device *dev;
struct regmap * regmap;
};
enum {
cat3626,
};
static const struct of_device_id cat3626_dt_ids[] = {
{ .compatible = "onsemi,cat3626", .data = (void *)cat3626},
{ }
};
MODULE_DEVICE_TABLE(of, cat3626_dt_ids);
static const struct i2c_device_id cat3626_id[] = {
{"cat3626",cat3626},
{ }
};
MODULE_DEVICE_TABLE(i2c, cat3626_id);
static const struct regmap_config regmap_config = {
.reg_bits = 8,
.val_bits = 8,
};
static int cat3626_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct cat3626 *cat3626;
const struct of_device_id *match;
int ret;
cat3626 = devm_kzalloc(&client->dev, sizeof(struct cat3626), GFP_KERNEL);
if (!cat3626){
return -ENOMEM;
}
dev_set_drvdata(&client->dev, cat3626);
cat3626->dev = &client->dev;
cat3626->regmap = devm_regmap_init_i2c(client, &regmap_config);
if (IS_ERR(cat3626->regmap)) {
dev_err(cat3626->dev, "regmap allocation failed\n");
return PTR_ERR(cat3626->regmap);
}
i2c_set_clientdata(client, cat3626);
match = of_match_device(cat3626_dt_ids, &client->dev);
if (!match) {
dev_err(&client->dev, "unknown device model\n");
return -ENODEV;
}
ret = i2c_smbus_write_byte_data(client, CAT3626_ENA, 0x30); /* write LED C on*/
ret = i2c_smbus_write_byte_data(client, CAT3626_REGC, 19); /* write mA*/
return ret;
}
static struct i2c_driver cat3626_driver = {
.driver = {
.name = "cat3626",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(cat3626_dt_ids),
},
.probe = cat3626_probe,
.remove = cat3626_remove,
.id_table = cat3626_id,
};
module_i2c_driver(cat3626_driver);
Here is the makefile:
ifneq ($(KERNELRELEASE),)
obj-m := hiber_rgb_driver.o
else
KERNELDIR ?= \
/lib/modules/`uname -r`/build/
PWD := `pwd`
default:
$(MAKE) -C $(KERNELDIR) \
M=$(PWD) modules
endif
clean:
rm -f *.ko *.o Module* *mod*
In the /boot/config.txt file I have added this:
dtoverlay = i2c-gpio, bus = 80, i2c_gpio_delay_us = 2, i2c_gpio_sda = 44, i2c_gpio_scl = 45.
In addition I made a custom dtoverlay:
/dts-v1/;
/plugin/;
/ {
fragment#0 {
target = <&i2c80>;
__overlay__ {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
cat3626: cat3626#66 {
compatible = "onsemi,cat3626";
reg = <0x66>;
clock-frequency = <400000>;
};
};
};
};
Unfortunalty on boot-up nothing happens.
All I get from the bootup dmesg is the following:
rgb_driver: loading out-of-tree module taints kernel
Anyone can give me any help, or a maybe a different approach to achieve my goal?
Thanks in advance!
A couple of things to look at - a tainted kernel is often feature-reduced and you probably don't want to go there if you don't have to. I'd try to solve the tainting issue. I've built kernel modules as standalones and not hit the taint issue. You may wish to revisit your makefile, this is a more standard module-building makefile with a couple of wrinkles as, of course, you are crossing compiling -
PWD = $(shell pwd)
obj-m += hiber_rgb_driver.o
all:
make ARCH=arm CROSS_COMPILE=$(CROSS) -C $(KERNEL) SUBDIRS=$(PWD) modules
clean:
make -C $(KERNEL) SUBDIRS=$(PWD) clean
and build it with something like -
make KERNEL=<LINUX_SOURCE_DIR> CROSS=<TOOLCHAIN_DIR>/bin/arm-linux-gnueabihf-
So there is that.
Next, your device probe stuff looks interesting. I don't have time to debug it for you, but I'd suggest adding some printk's in there to verify the probe is getting hit. If it is, then great, it's just a matter of figuring out why you are not 'matching'. If it is not getting hit, then read on ..
As you probably know, i2c buses are a little special when it comes to device probing. There is no real automated or magical probing that would normally happen on say a PCI bus. Instead you need to build out a device tree that the kernel can walk at boot-time to complete all of the probes.
I see that you've created an overlay snippet. You need to make sure that thing is compiled into a '.dtb' byte code binary that the kernel can parse and then put in the correct place in your boot media where grub can find it.
You may also need to update your device's master dtb to refer to this overlay, so that the kernel knows where it might go. Think of the device's dtb as being an artificial christmas tree, and the overlay as a limb that could be attached at some point in the future - you'll need to specify the attachment points in the device dtb. I wish that I could be more precise here, but hope sets you off in the correct direction on this point at least.

Undefined symbols in hello world C++ kernel module

I have added C++ support to the Linux kernel version 4.14.41, compiled it and booted using the kernel successfully. I can check the correctness of the C++ module by inserting a LKM. This is the module that I am trying to load:
#include<c++/begin_include.h>
#include<linux/module.h>
#include<linux/kernel.h>
#include<c++/end_include.h>
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("LKM in c++");
MODULE_AUTHOR("MOOL");
class hello
{
public:
hello();
void hi();
};
void hello::hi()
{
printk("Hello world!! \n");
}
hello::hello()
{
printk("Constructor is being called \n");
}
extern "C"
{
static int __init test_classes_init()
{
class hello obj;
obj.hi();
printk("Module inserted:\n");
return 0;
}
static void __exit test_classes_fini()
{
printk("Module removed:\n");
}
module_init(test_classes_init);
module_exit(test_classes_fini);
}
The Makefile:
obj-m = helloworld.o
KVERSION=$(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
When I enter the make command, the helloworld.ko is generated with the warnings
WARNING: "begin_fini" [/home/jai/Downloads/helloworld/helloworld.ko] undefined !
WARNING: "end_init" [/home/jai/Downloads/helloworld/helloworld.ko] undefined !
WARNING: "begin_init" [/home/jai/Downloads/helloworld/helloworld.ko] undefined !
But when I try to insert it using insmod helloworld.ko, the undefined symbol error occurs.
dmesg:
loading out-of-tree module taints kernel
Unknown symbol begin_init (err 0)
Unknown symbol end_init (err 0)
Unknown symbol begin_fini (err 0)
These begin_init, end_init and begin_fini are defined in lib/gcc/crtstuff.c (which was ported into the kernel). These functions are declared as extern in both crtstuff.c and linux/module.h. This module.h is being included in the helloworld module above, but still, those symbols become undefined. So, How can I make those functions defined?
Your kernel C++ implementation is incomplete. You will have to implement global constructor and destructor support (processing of .init_array and .fini_array sections properly), or stop using these C++ features in the source code. This needs cooperation from the kernel module loader. Changes to the startup code will not work because the startup code is not linked into kernel modules.

Wemos - oled sparkfun print text does not display

I'm using a led matrix shield (http://www.wemos.cc/Products/oled_shield.html) with a wemos. I'm using Arduino IDE.
The exemples work perfectly (https://github.com/wemos/D1_mini_Examples/tree/master/04.Shields/OLED_Shield/Use_SparkFun_Library)
But when I try to print text, the screen remains empty. Here is my code
#include <Wire.h>
#include <SFE_MicroOLED.h> // Include the SFE_MicroOLED library
#define PIN_RESET 255
#define DC_JUMPER 0
MicroOLED oled(PIN_RESET, DC_JUMPER);
void setup()
{
oled.begin();
oled.clear(ALL);
oled.clear(PAGE);
oled.display();
oled.setFontType(0);
oled.setCursor(0, 0);
oled.print("Hello, world");
oled.display();
}
void loop()
{
}
Any idea ?
I solved the issue. I modified SFE_MicroOLED lib.
The fonts are loaded in the program memory (via PROGMEM directive). This makes the code fail on wemos.
I remove PROGMEM directive on a fork of this lib (https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library)
I just check if the arch is ARDUINO_ESP8266_NODEMCU
https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library/blob/master/src/util/7segment.h#L37 (idem for all other font files in the same folder)

Howto Write to the GPIO Pin of the CM108 Chip in Linux?

The CM108 from C-Media has 4 GPIO pin that you can access via a hid interface.
Using the generic write function in Windows I was able to write to the gpio pins.
However I'm trying to do the same thing in Linux without success.
The linux kernel detect the device as a hidraw device.
Note: I was able to read from the device, just not write. (I've run the app as root just to make sure it wasn't a permission issue).
I got this working, here's how.
I needed to create a new linux hid kernel mod. (it wasn't that hard)/*
/*
* Driver for the C-Media 108 chips
*
* Copyright (C) 2009 Steve Beaulac <steve#sagacity.ca>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation, version 2.
*/
/*
* This driver is based on the cm109.c driver
*/
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
#define DRIVER_VERSION "20090526"
#define DRIVER_AUTHOR "Steve Beaulac"
#define DRIVER_DESC "C-Media 108 chip"
#define CM108_VENDOR_ID 0x0d8c
#define CM108_PRODUCT_ID 0x000c
#ifdef CONFIG_USB_DYNAMIC_MINORS
#define CM108_MINOR_BASE 0
#else
#define CM108_MINOR_BASE 96
#endif
/*
* Linux interface and usb initialisation
*/
static int cm108_hid_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
ret = hid_parse(hdev);
if (ret) {
dev_err(&hdev->dev, "parse failed\n");
goto error;
}
ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
if (ret) {
dev_err(&hdev->dev, "hw start failed\n");
goto error;
}
return 0;
error:
return ret;
}
static struct hid_device_id cm108_device_table[] = {
{ HID_USB_DEVICE (CM108_VENDOR_ID, CM108_PRODUCT_ID) },
/* you can add more devices here with product ID 0x0008 - 0x000f */
{ }
};
MODULE_DEVICE_TABLE (hid, cm108_device_table);
static struct hid_driver hid_cm108_driver = {
.name = "cm108",
.id_table = cm108_device_table,
.probe = cm108_hid_probe,
};
static int hid_cm108_init(void)
{
return hid_register_driver(&hid_cm108_driver);
}
static void hid_cm108_exit(void)
{
hid_unregister_driver(&hid_cm108_driver);
}
module_init(hid_cm108_init);
module_exit(hid_cm108_exit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
used This makefile
obj-m += cm108.o
and compile the module
make -C /lib/modules/`uname -r`/build/ M=`pwd` EXTRAVERSION="-generic" modules
sudo make -C /lib/modules/`uname -r`/build/ M=`pwd` EXTRAVERSION="-generic" modules_install
depmod -a
I had to modify the modules.order file so that my module would get queried before the generic hid linux module.
This modules make sure that the hidraw uses Interface 2.
Then I can use fopen to read and write to the GPIO pin of the CM108 chip.
BTW: when writing you need to write 5byte the 1st byte is used for the HID_OUTPUT_REPORT
Most hardware in Linux is accessible as a file. If the driver created a hardware node for it on the file-system, you're in luck. You will be able to write to it using regular file routines. Otherwise, you may need to do some assembly magic, which may require you to write a kernel module to do it.
Here is a complete example of how to write to the CM108/CM119 GPIO pins on Linux.
https://github.com/wb2osz/direwolf/blob/dev/cm108.c
You don't need to run as root or write your own device driver.
I have the opposite problem. I'm trying to figure out how to do the same thing on Windows.

Resources