which "arch" subdirectory to use?

Hi all -

I’m working through one of Dr. Molloy’s examples on building kernel modules. My/his program originally failed to build because I hadn’t defined C_INCLUDE_PATH which now points to /usr/src/lineux-headers-4.4.48-ti-r88/include. Now it’s failing because one of the included files is failing on a file in an asm subdirectory. So…

  1. was I correct in creating C_INCLUDE_PATH?

  2. did I point it to the right place?

  3. am I correct in assuming that I need to add another location to this variable, so it can find the asm subdirectory?

  4. which is the right arch subdirectory for the BBB? I’m guessing arm, but that is just a guess.
    And of course, if I’m somehow going at this all wrong, please so advise.

Thanks for any help.

Are you passing ARCH=arm ??

in theory, the arch assembly directory should be fixed. ( back ported
a builddeb change from the v4.7.0-rc merge cycle)

https://github.com/RobertCNelson/stable-kernel/commit/3a0073dc8a13b0aa955f440d8219d2bb638a44c9

Regards,

Are you passing ARCH=arm ??

No. I’m just trying to do the example on this page: here

The contents of the makefile:

obj-m+=ebbchar.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules
$(CC) testebbchar.c -o test
clean:
make -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) clean
rm test

in theory, the arch assembly directory should be fixed. ( back ported
a builddeb change from the v4.7.0-rc merge cycle)

https://github.com/RobertCNelson/stable-kernel/commit/3a0073dc8a13b0aa955f440d8219d2bb638a44c9

I don’t know what this means. How is my build supposed to “find” the appropriate arch subdirectory?

Thanks.

For completeness, his example should have had an "ARCH=arm"

make ARCH=arm -C /lib/modules/$(shell uname -r)/build/ M=$(PWD) modules

However, he didn't required any arch includes, unlike your project.

Regards,

My project is his project. I’m trying to build the ebbchar.c file included in his repository. I have no idea how this used to work, but it doesn’t now (not on my system anyway).

I added the ARCM=arm to my copy of the Makefile, but I’m still getting the error message. Is this because I have my C_INCLUDE_PATH pointing to the wrong place?

Thanks, Robert.

Yeap looks like you messed something up, as the example just works:

git clone https://github.com/derekmolloy/exploringBB.git
cd ./exploringBB/extras/kernel/ebbchar/

sudo apt install linux-headers-`uname -r`

debian@BeagleBoard-X15:~/exploringBB/extras/kernel/ebbchar$ make
make -C /lib/modules/4.4.68-ti-r108/build/
M=/home/debian/exploringBB/extras/kernel/ebbchar modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.68-ti-r108'
  CC [M] /home/debian/exploringBB/extras/kernel/ebbchar/ebbchar.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC /home/debian/exploringBB/extras/kernel/ebbchar/ebbchar.mod.o
  LD [M] /home/debian/exploringBB/extras/kernel/ebbchar/ebbchar.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.4.68-ti-r108'
cc testebbchar.c -o test

Regards,

I just attempted to replicate your work, and I got a list of compile errors and warnings long enough to overrun my terminal buffer. Any suggestions on how to go about troubleshooting this?

Thanks.

Update: I deleted that C_INCLUDE_PATH variable, and it now works. No idea why it didn’t work the first time.

Thanks for looking…

Another update: when I said “works” below, I should have said “builds.” When I try to run, though, problems occur:

mzimmers@beaglebone:~/exploringBB/extras/kernel/ebbchar$ sudo insmod ebbchar.ko
mzimmers@beaglebone:~/exploringBB/extras/kernel/ebbchar$ ls -l /dev/ebb*
crw------- 1 root root 245, 0 Jun 21 17:36 /dev/ebbchar
mzimmers@beaglebone:~/exploringBB/extras/kernel/ebbchar$ sudo ./test
Starting device test code example…
Type in a short string to send to the kernel module:
xxx
Writing message to the device [xxx].

Message from syslogd@beaglebone at Jun 21 17:36:25 …
kernel:[194752.007878] Internal error: : 1b [#6] SMP ARM

Message from syslogd@beaglebone at Jun 21 17:36:25 …
kernel:[194752.126027] Process test (pid: 4825, stack limit = 0xdc7d2218)

Any suggestions? Thanks.

Well… I would contact the author, obvious something changed since 3.8.13.

mzimmers,

You know, I tried a few different guides when building the kernel and none of them worked until I found Robert’s build guide( 4+ years ago ). In your shoes, I would probably forget about trying to follow DR Molloy’s book in this case, and just use Robert’s guide. Because no one is going to know how to build a kernel for this hardware as well as Robert.

Just in case you do not know already. https://eewiki.net/display/linuxonarm/BeagleBone+Black That guide is for the black, there is one for the white, but don’t know if there is one for the blue, or any of the wireless variants.

mzimmers, additionally, aside from getting hands on experience. Why do you feel compelled to build your own kernel ? If it’s for the learning process, ok I get that. But if you need to build something in . . maybe, but if you’re looking to build a driver module . . . you do not need to rebuild the kernel for that.

Hi, William -

I have no (current) interest in building my own kernel. I’m trying to do Dr. Molloy’s tutorials because I want to learn about writing device drivers for Linux (you may recall an earlier discussion where you encouraged me to go this route in favor of doing bare-metal bit-banging). I’m just trying to get his program to work. I wasn’t aware that I was doing anything in the kernel building area. (Still new to much of this stuff.)

mz

Yeah ok, my bad. I think I misread your initial post. Where you mention
kernel MODULES and not just the kernel.

Hi Robert -

When you say “something changed since 3.8.13” what are you referring to? It appears that the example you ran (successfully) was on 4.4.68 build.

Building =/= Working...

"something" changed, while it didn't break the build, it broke running
it.. So some assumption in that example relies on a 3.8.13
"feature/bug/etc"..

So it's up to you to fix it....

Regards,

mzimmers, Which version of gcc are you using ?

Hi, William - version 4.9.2.

I’ve isolated the problem to the buffer argument passed into dev_write(). Using printk() I can see that the address of the buffer is befffadc (though I have no idea whether that’s a valid address or not). When I attempt to dereference it, though, it seems to fail, as my printk that dereferences buffer never appears.

I was able to debug the test program (running from user space) and I get a segmentation fault on the write to the devices fd. That’s about where I was when I got your message. Not sure what to make of all of this.

Yeah, ok, seemed like the obvious question to ask, but maybe too obvious :wink: