derekmolloy / exploringbb Goto Github PK

I am trying to use the example in chapter 9 pg365 to bind BBBSerialServer to ttyGS0

I have disabled serial-getty
Compiled BBBSerialServer.c and created a custom service to bind BBBSerialServer to ttyGS0

This service status shows that it is enabled and running on boot. However, when I connect via serial COMxx, it shows the standard " enter login ", which, when logged in, goes to a ttyGS0 terminal and not directly to BBB Serial Server ( demonstrated in figure 9-21 ).

Is this actually the correct behaviour? If so, how would I communicate with the server?

serial connection: baud-115200, databits-8, stopbits-1, parity-None, flow control-Xon/Xoff
implicit LF in every CR is set also

if I disabled the service + run the server directly , it also double outputs and doesn't recognise commands. (the server code is unedited)

hi,
I am using Adafruit Ultimate GPS breakout module to interface with the beaglebone black. I am using UART 4 for that, but while running after compile it won't show any output. I changed the port name to "dev/ttyO4" in serial.h file.
thank you!!!

Hi Derek,
I'm working through your LKM examples and I think that a bug might have found its way into the Makefiles of the project.
I'm using debian version 4.4.91-ti-r133.
As an example:
:~/exploringBB/extras/kernel/hello$
For me, with your Makefile

obj-m+=hello.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
# make -C /usr/src/linux-headers-$(shell uname -r) M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean

does not work. It results in: *** No rule to make target 'modules'. Stop
I think the first line in all: must be as I pointed out in the outcommented line below your code
Also "make clean" results in: *** No rule to make target 'clean'. Stop.

Excuse me if your code is right and I did something wrong as I'm a beginner with linux, C and beaglebone.

By the way: Thank you very much for your excellent work.
Is there a new edition of your book, using newer kernels, in work?
Kind regards
Roland

I did everything as advised. Did git clone https://github.com/derekmolloy/exploringBB.git
And then, just before diving into the meat of the reference kernel driver, I wrote several versions of the script, the latest shown here:
[vuser@fedora29-ssd ebbchar]$ ls -al
total 784
drwxr-xr-x. 3 vuser vboxusers 4096 Apr 3 17:55 .
drwxr-xr-x. 9 vuser vboxusers 4096 Apr 3 14:52 ..
-rw-r--r--. 1 vuser vboxusers 91 Apr 3 14:52 99-ebbchar.rules
-rw-r--r--. 1 vuser vboxusers 8629 Apr 3 14:52 ebbchar.c
-rw-r--r--. 1 vuser vboxusers 319816 Apr 3 16:56 ebbchar.ko
-rw-r--r--. 1 vuser vboxusers 431 Apr 3 16:56 .ebbchar.ko.cmd
-rw-r--r--. 1 vuser vboxusers 646 Apr 3 16:56 ebbchar.mod.c
-rw-r--r--. 1 vuser vboxusers 104680 Apr 3 16:56 ebbchar.mod.o
-rw-r--r--. 1 vuser vboxusers 30709 Apr 3 16:56 .ebbchar.mod.o.cmd
-rw-r--r--. 1 vuser vboxusers 216896 Apr 3 16:56 ebbchar.o
-rw-r--r--. 1 vuser vboxusers 38017 Apr 3 16:56 .ebbchar.o.cmd
-rw-r--r--. 1 vuser vboxusers 5 Apr 3 14:52 .gitignore
-rwxr-xr-x. 1 vuser vboxusers 101 Apr 3 17:55 loop.sh
-rwxr-xr-x. 1 vuser vboxusers 102 Apr 3 16:59 loop.sh~
-rw-r--r--. 1 vuser vboxusers 194 Apr 3 14:52 Makefile
-rw-r--r--. 1 vuser vboxusers 87 Apr 3 16:56 modules.order
-rw-r--r--. 1 vuser vboxusers 0 Apr 3 16:56 Module.symvers
-rwxr-xr-x. 1 vuser vboxusers 18848 Apr 3 16:56 test
-rw-r--r--. 1 vuser vboxusers 1787 Apr 3 14:52 testebbchar.c
drwxr-xr-x. 2 vuser vboxusers 4096 Apr 3 16:56 .tmp_versions
[vuser@fedora29-ssd ebbchar]$ pwd
/home/vuser/projects2/C_coding/lkm/exploringBB/extras/kernel/ebbchar
[vuser@fedora29-ssd ebbchar]$ cat loop.sh
#!/bin/bash
for (( c=1; c<=5000; c++ ))
do
sudo insmod ebbchar.ko
sudo rmmod -f ebbchar
done
[vuser@fedora29-ssd ebbchar]$

[vuser@fedora29-ssd ebbchar]$ ./loop.sh
./loop.sh: line 6: 5825 Segmentation fault sudo insmod ebbchar.ko
rmmod: ERROR: could not remove 'ebbchar': Device or resource busy
rmmod: ERROR: could not remove module ebbchar: Device or resource busy
^C
[vuser@fedora29-ssd ebbchar]$

After about 100 cycles, the kernel ooooops. And the whole system began to be unresponsive. Browser does not work... I'll try to capture dmesg and post here:

[ 4131.382433] EBBChar: Initializing the EBBChar LKM
[ 4131.382436] EBBChar: registered correctly with major number 511
[ 4131.382442] EBBChar: device class registered correctly
[ 4131.382512] EBBChar: device class created correctly
[ 4131.411171] EBBChar: Goodbye from the LKM!
[ 4131.443761] EBBChar: Initializing the EBBChar LKM
[ 4131.443765] EBBChar: registered correctly with major number 511
[ 4131.443775] EBBChar: device class registered correctly
[ 4131.443841] EBBChar: device class created correctly
[ 4131.471791] EBBChar: Goodbye from the LKM!
[ 4131.502473] EBBChar: Initializing the EBBChar LKM
[ 4131.502476] EBBChar: registered correctly with major number 511
[ 4131.502483] ------------[ cut here ]------------
[ 4131.502484] kernel BUG at mm/slub.c:305!
[ 4131.502489] invalid opcode: 0000 [#1] SMP PTI
[ 4131.502492] CPU: 3 PID: 5827 Comm: insmod Tainted: G OE 5.0.5-200.fc29.x86_64 #1
[ 4131.502493] Hardware name: Hewlett-Packard HP EliteBook 840 G1/198F, BIOS L71 Ver. 01.46 07/20/2018
[ 4131.502498] RIP: 0010:__slab_free+0x1e2/0x3d0
[ 4131.502499] Code: 8b 54 24 30 48 89 4c 24 28 e8 da fb ff ff 4c 8b 54 24 28 85 c0 0f 85 67 fe ff ff 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 49 3b 5c 24 28 75 ab 48 8b 44 24 30 49 89 4c 24 28 49 89 44
[ 4131.502501] RSP: 0018:ffffbe5cc1d83b20 EFLAGS: 00010246
[ 4131.502503] RAX: ffffa0014079bf60 RBX: 00000000802a0029 RCX: ffffa0014079bf60
[ 4131.502504] RDX: ffffa0014079bf60 RSI: ffffef984d01e6c0 RDI: ffffa00142403680
[ 4131.502505] RBP: ffffbe5cc1d83bc8 R08: 0000000000000001 R09: ffffffff82957905
[ 4131.502506] R10: ffffa0014079bf60 R11: 0000000000000001 R12: ffffef984d01e6c0
[ 4131.502508] R13: ffffa0014079bf60 R14: ffffa00142403680 R15: ffffef984d01e6e0
[ 4131.502509] FS: 00007f558223b280(0000) GS:ffffa001428c0000(0000) knlGS:0000000000000000
[ 4131.502511] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4131.502512] CR2: 000055ef4b528e98 CR3: 00000002187c6006 CR4: 00000000001606e0
[ 4131.502513] Call Trace:
[ 4131.502519] ? log_store+0x200/0x280
[ 4131.502522] ? __kmalloc_track_caller+0x170/0x210
[ 4131.502526] ? kobject_set_name_vargs+0x1e/0x90
[ 4131.502529] kobject_put+0x85/0x1a0
[ 4131.502532] kobject_add_internal+0xcc/0x270
[ 4131.502535] kset_register+0x41/0x60
[ 4131.502539] __class_register+0xcc/0x190
[ 4131.502541] __class_create+0x4c/0x80
[ 4131.502543] ? 0xffffffffc118b000
[ 4131.502546] ebbchar_init+0x72/0x1000 [ebbchar]
[ 4131.502550] do_one_initcall+0x46/0x1c3
[ 4131.502554] ? free_unref_page_commit+0x9b/0x110
[ 4131.502558] ? _cond_resched+0x15/0x30
[ 4131.502560] ? kmem_cache_alloc_trace+0x154/0x1d0
[ 4131.502563] do_init_module+0x5a/0x210
[ 4131.502565] load_module+0x2096/0x22d0
[ 4131.502569] ? ima_post_read_file+0xf4/0x100
[ 4131.502572] ? __do_sys_finit_module+0xa8/0x110
[ 4131.502574] __do_sys_finit_module+0xa8/0x110
[ 4131.502577] do_syscall_64+0x5b/0x160
[ 4131.502580] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 4131.502582] RIP: 0033:0x7f5582355efd
[ 4131.502583] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5b 7f 0c 00 f7 d8 64 89 01 48
[ 4131.502584] RSP: 002b:00007ffde2369ae8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 4131.502586] RAX: ffffffffffffffda RBX: 000055ef4b5257b0 RCX: 00007f5582355efd
[ 4131.502587] RDX: 0000000000000000 RSI: 000055ef49872346 RDI: 0000000000000003
[ 4131.502588] RBP: 000055ef49872346 R08: 0000000000000000 R09: 00007f5582421020
[ 4131.502590] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
[ 4131.502591] R13: 000055ef4b527e90 R14: 0000000000000000 R15: 0000000000000000
[ 4131.502592] Modules linked in: ebbchar(OE+) fuse ccm xt_CHECKSUM ipt_MASQUERADE tun bridge stp llc devlink nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables vboxpci(OE) vboxnetadp(OE) ip6table_filter vboxnetflt(OE) ip6_tables vboxdrv(OE) sunrpc vfat fat arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 iwlmvm videobuf2_common mei_wdt iTCO_wdt crct10dif_pclmul iTCO_vendor_support crc32_pclmul videodev mac80211 media ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf iwlwifi snd_hda_codec_idt snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_hda_codec cfg80211 snd_hda_core
[ 4131.502617] snd_hwdep snd_seq joydev snd_seq_device hp_wmi snd_pcm sparse_keymap wmi_bmof i2c_i801 rtsx_pci_ms lpc_ich memstick snd_timer rfkill mei_me snd mei soundcore hp_accel lis3lv02d input_polldev pcc_cpufreq hp_wireless tpm_infineon binfmt_misc amdgpu chash amd_iommu_v2 gpu_sched i915 radeon rtsx_pci_sdmmc mmc_core kvmgt mdev vfio kvm irqbypass i2c_algo_bit drm_kms_helper ttm crc32c_intel drm serio_raw rtsx_pci e1000e wmi video [last unloaded: ebbchar]
[ 4131.502636] ---[ end trace ca5576a9f61c90ba ]---
[ 4131.502638] RIP: 0010:__slab_free+0x1e2/0x3d0
[ 4131.502640] Code: 8b 54 24 30 48 89 4c 24 28 e8 da fb ff ff 4c 8b 54 24 28 85 c0 0f 85 67 fe ff ff 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 49 3b 5c 24 28 75 ab 48 8b 44 24 30 49 89 4c 24 28 49 89 44
[ 4131.502641] RSP: 0018:ffffbe5cc1d83b20 EFLAGS: 00010246
[ 4131.502642] RAX: ffffa0014079bf60 RBX: 00000000802a0029 RCX: ffffa0014079bf60
[ 4131.502644] RDX: ffffa0014079bf60 RSI: ffffef984d01e6c0 RDI: ffffa00142403680
[ 4131.502645] RBP: ffffbe5cc1d83bc8 R08: 0000000000000001 R09: ffffffff82957905
[ 4131.502646] R10: ffffa0014079bf60 R11: 0000000000000001 R12: ffffef984d01e6c0
[ 4131.502647] R13: ffffa0014079bf60 R14: ffffa00142403680 R15: ffffef984d01e6e0
[ 4131.502649] FS: 00007f558223b280(0000) GS:ffffa001428c0000(0000) knlGS:0000000000000000
[ 4131.502650] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4131.502651] CR2: 000055ef4b528e98 CR3: 00000002187c6006 CR4: 00000000001606e0

Thank you,
Zoran

Why is Bit 5 value HIGH mentioned as Output ? Isn't that Input ?

It would be nice to have the Pocket Beagle Pins column on these amazing tables.

Thanks!

Hi Derek. Your book, on page 83 (iBooks version) says “The full description for the BBB device tree source for Linux 3.x.x is available with the source code distribution of this book in the Chapter 3 directory."

But I only see a Hello World program in that directory.

Hi, thanks for the blog about kernel module programming.

I'm studying the code and adapting a bit for my needs but noticed that the line:

should return the size of the message to be read by the user space application. The reason that the included test application doesn't fail is because it does not catch this returned value (0):

, but in any other utility it will not read the message sent by the kernel. Thanks again!

I noticed that the ebbchar produces an segfault due to reliying on \0

Following code:

static ssize_t dev_write(struct file *filep, const char *buffer, size_t len, loff_t *offset){
   sprintf(message, "%s(%zu letters)", buffer, len);   // appending received string with its length
   size_of_message = strlen(message);                 // store the length of the stored message
   printk(KERN_INFO "EBBChar: Received %zu characters from the user\n", len);
   return len;
}

Is faulty, because if gets "a" an input, len will be 1. If I now access the \0, I get an segmentation fault.

printk(KERN_INFO "%c ", *(buffer+1));

This will trigger the segfault.

This is due the usage of strlen method, that will count up to the \0, but not include it.

ret = write(fd, stringToSend, strlen(stringToSend)); // Send the string to the LKM

Tested on 5.15.90.1 (on WSL2, with custom compiled kernel, allowing loading of modules)

I can't say if it worked in previous Versions of Linux due to forcing the \0 as allowed space or something, but it seems to got changed

Also Im not an expert, but shouldn't you better rely on len instead of \0? Im critical about the usage of \0 in C

I went through the cmake tutorial and the last example of using the shared or static library is giving me an error in the make step of the process.
$ make
[ 50%] Building CXX object CMakeFiles/libtest.dir/libtest.cpp.o /exploringBB/extras/cmake/usestudentlib/libtest.cpp:1:21: fatal error: Student.h: No such file or directory compilation terminated. CMakeFiles/libtest.dir/build.make:62: recipe for target 'CMakeFiles/libtest.dir/libtest.cpp.o' failed make[2]: *** [CMakeFiles/libtest.dir/libtest.cpp.o] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/libtest.dir/all' failed make[1]: *** [CMakeFiles/libtest.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2

Can someone explain why this is happening?
This is my CMakeLists.txt

cmake_minimum_required(VERSION 2.8.9)
project (TestLibrary)
#For the shared library:
set ( PROJECT_LINK_LIBS libtestStudent.so )
link_directories( ~/exploringBB/extras/cmake/studentlib_shared/build )
#For the static library:
#set ( PROJECT_LINK_LIBS libtestStudent.a )
#link_directories( ~/exploringBB/extras/cmake/studentlib_static/build )
include_directories("~/exploringBB/extras/cmake/studentlib_shared/include")
add_executable(libtest libtest.cpp)
target_link_libraries(libtest ${PROJECT_LINK_LIBS} )

Hi

I have found a issue when using the gpio.waitForEdge() method from the GPIO class. It gives me a Too many files error after the configured linux open files limit when using the method in a loop. I used lsof and detected a lot of anon_inodes. I thought this has to be a problem with epoll. It turned out that the close(epollfd) before close(fd) in waitForEdge() was missing.

Best regards
Tom

Hi Derek,
I found that the overlay EBB-PRU-Example(chp13) doesn't work correctly on newer kernel (4.4.9 bone10). In facts the pruss didn't load correctly (no uio) and also pru_pins didn't work. Making some experiments and looking at the cape-universal overlay I made my personal version of EBB-PRU-Example.dts wich works on kernel 4.4.9 bone10 (not sure if it works on older kernels).
Thank you
EBB-PRU-Example.dts.txt

Most likely (99.99%) the same bug persists in:
https://github.com/derekmolloy/exploringBB/blob/version2/extras/kernel/ebbcharmutex/ebbcharmutex.c

Drawn from: #23

Zoran

Originally posted by @ZoranStojsavljevic in #27 (comment)

Hi, I am trying to poll the GPIO pins and slightly modified the chp06/gpio/tests/test_syspoll.cpp as follows:

#include<iostream>
#include<unistd.h>
#include"GPIO.h"
using namespace exploringBB;
using namespace std;

int main(){
   GPIO outGPIO(44), inGPIO(45);
   inGPIO.setDirection(INPUT);    //button is an input
   outGPIO.setDirection(OUTPUT);  //LED is an output
   for(int i=0;i<100;i++)
   {
      outGPIO.setValue(HIGH);
      usleep(10);
      outGPIO.setValue(LOW);
      cout<< endl <<"toggle done";

      // poll the echo pin to go high
      inGPIO.setEdgeType(FALLING);   //wait for rising edge
      inGPIO.waitForEdge();          //will wait forever
      cout<< endl <<"checkpoint";
      usleep(1000*100);
   }
   return 0;
}

I am unable to debug this problem