which "arch" subdirectory to use?

[mzimmers]

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.

[Robert Nelson]

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,

--
Robert Nelson
https://rcn-ee.com/

[mzimmers]

On Wednesday, June 21, 2017 at 3:38:11 PM UTC-6, RobertCNelson wrote:

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.

[Robert Nelson]

On Wed, Jun 21, 2017 at 4:44 PM, mzimmers <mzim...@gmail.com> wrote:
>
>
> On Wednesday, June 21, 2017 at 3:38:11 PM UTC-6, RobertCNelson wrote:
>>
>>
>> Are you passing ARCH=arm ??
>
>
> No. I'm just trying to do the example on this page: here

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.

[mzimmers]

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.

[Robert Nelson]

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

[mzimmers]

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.

[mzimmers]

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...

[mzimmers]

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.

...

[Robert Nelson]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a11a503f-20f2-4f19-99f0-45e3fd2e7db6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

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.

[William Hermans]

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.

[William Hermans]

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.

[mzimmers]

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

[William Hermans]

On Wed, Jun 21, 2017 at 7:34 PM, mzimmers <mzim...@gmail.com> wrote:

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.

[mzimmers]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Thu, Jun 22, 2017 at 11:25 AM, mzimmers <mzim...@gmail.com> wrote:
> 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....

[William Hermans]

mzimmers, Which version of gcc are you using ?

[mzimmers]

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.

[William Hermans]

Yeah, ok, seemed like the obvious question to ask, but maybe too obvious ;)

[mzimmers]

Hey, I'm open to any and all ideas. It seems so strange that I'm getting a seg fault in the client code, though...that does make me suspicious of the compiler version vs. the headers, etc.

How do people go about debugging kernel code, anyway? I gather that gdb isn't much of an option. Do we just litter the code with printk statements like we did when we were freshmen in college?

mz

[William Hermans]

On Thu, Jun 22, 2017 at 12:54 PM, mzimmers <mzim...@gmail.com> wrote:

Hey, I'm open to any and all ideas. It seems so strange that I'm getting a seg fault in the client code, though...that does make me suspicious of the compiler version vs. the headers, etc.

How do people go about debugging kernel code, anyway? I gather that gdb isn't much of an option. Do we just litter the code with printk statements like we did when we were freshmen in college?

mz

Naw, theres a special way to compile a kernel that will allow it to be run as though it's just another executable. This way, you can run the kernel on top of the Linux you're already running in order to debug it.

[Roberts Maria]

--------------------------------------------
On Fri, 6/23/17, William Hermans <yyr...@gmail.com> wrote:

Subject: Re: [beagleboard] which "arch" subdirectory to use?
To: beagl...@googlegroups.com
Date: Friday, June 23, 2017, 3:50 AM

--

For more options, visit http://beagleboard.org/discuss

---

You received this message because you are subscribed to the
Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails
from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo1-Yr1Z8QoVDJ7_zfn0q6W35QR7zy27ren9xVn%2BM8MgQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Se introduce in tara Romaneasca cultivarea rapitei pentru fabricarea uleiului. 14 febr. - Fondarea la Bucuresti a .Asociatiei literare a Romaniei . 2 14 dec. - Se pun bazele la Paris ale Societatii studentilor romani .1845- Mare foamete in Irlanda. -Texasul este reunit cu Statele Unite ale Americii.

[John Syne]

You need a kernel aware JTAG debugger like Lauterbach. This will allow you to debug u-boot, kernel code, including all the drivers as they are loaded, etc. It is expensive, but it is the gold standard for kernel/driver debugging. 

TI have Code Composer Studio that will do some debugging of the kernel using a blackhawk JTAG adapter, but CCSV7 has several limitations as they no longer support kernel aware debugging (dropped after CCSV4). It is somewhat helpful and a lot less expensive ($99) than Lauterbach.

I hope this helps. 

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f34faaa9-9be9-47a1-b5a7-9c502f47acb6%40googlegroups.com.

[mzimmers]

Hi, John - thanks for the reply. I don't believe, however, that I'll need to use JTAG, at least not for this specific example. 

Here's my current thinking: I already have a cross-development platform (Qt Creator) set up for the BBB, so I'm going to try to use it to build kernel modules. I know that at a minimum, I'll need the kernel header files, which I can get from RCN's repository. I just have to figure out where to put them on my host so I don't overwrite anything (my host isn't the same Debian version as my BBB).

I welcome any feedback on this idea.

[John Syne]

The way I work is to have the BBB mount rootfs over NFS which resides on my desktop. When I create a Kernel Module, I do the following:

1) I clone Robert’s kernel repo

2) I build the kernel

3) I add my kernel module code

4) I rebuild the kernel

5) I modify Robert’s deploy script to copy the kernel/kernel modules to my NFS share directory

6) I run modprobe <mykernelmodule>

7) If there is a problem; modprobe -r <mykernelmodule>

8) Modify my code an goto step 4

9) Once everything is working, I create a patch and add it to the patches folder and modify Robert’s build script.

By using Robert’s build scripts, you don’t have to worry about kernel headers, compiler versions, etc. It all just works. 

No need for any special tools, just use your favorite editor. I tend to use Eclipse as I can index the entire kernel source code so I can just <cntl> click on any function and it will switch to that function. <alt> left arrow returns to your previous location. This link will show you how to make Eclipse work. 

https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source

I hope this helps.

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b08c6a13-5bd6-4693-a466-9b5596a8e117%40googlegroups.com.

[mzimmers]

Thanks for all the details, John. I'll look into that approach when I get around to more serious kernel programming. Right now, I just want to figure out why this example isn't working for me.

I need to download Robert's header files for the BBB to my host. If I just add a file to sources.list.d, and run apt, will this work, or am I at risk of overwriting my host's files?

[John Syne]

I don’t do this, but I believe you can do this using Multiarch:

https://wiki.debian.org/Multiarch/HOWTO

Now you can install the headers using dpkg -i <headerpkg>

I have copied Robert as he is the best person to answer your question. 

Regards,

John

On Jun 23, 2017, at 1:47 PM, mzimmers <mzim...@gmail.com> wrote:

Thanks for all the details, John. I'll look into that approach when I get around to more serious kernel programming. Right now, I just want to figure out why this example isn't working for me.

I need to download Robert's header files for the BBB to my host. If I just add a file to sources.list.d, and run apt, will this work, or am I at risk of overwriting my host's files?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/83496bd4-9803-45cb-ba72-f9c011adbbaa%40googlegroups.com.

[John Syne]

One thing I forgot, you would use 

dpkg —add-architecture armhf

as Robert builds with Hardware Floating point. 

Regards,

John

On Jun 23, 2017, at 1:47 PM, mzimmers <mzim...@gmail.com> wrote:

Thanks for all the details, John. I'll look into that approach when I get around to more serious kernel programming. Right now, I just want to figure out why this example isn't working for me.

I need to download Robert's header files for the BBB to my host. If I just add a file to sources.list.d, and run apt, will this work, or am I at risk of overwriting my host's files?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/83496bd4-9803-45cb-ba72-f9c011adbbaa%40googlegroups.com.

[mzimmers]

Hi, John - thanks for all the information. I've been reviewing each item in your list to better understand what I'll be doing, and more importantly, why. I'm curious why you'd clone Robert's repository, though, instead of just checking out the latest (stable) copy. Do you really need all the versions/history/etc that comes with a complete clone?

Also, about how much space does that clone need? I'm running on limited resources (my Debian build boots off of a 64GB SSD).

Thanks again. 

[John Syne]

To modify the kernel, you always have to clone one of Robert’s repos, either the ti-linux-kernel or the bb-kernel. The repo allows you to update the kernel as Robert adds fixes/patches. Using GIT, you can see what was changed (gitk) and by whom (git blame <file>). If you are looking for how a function was used or how it is defined (git grep <function>). GIT is your friend and I advise you to take the time to learn how to use this tool. I have my own development branch and then I merge in changes added by Robert  from time to time. 

Regarding your second question, the cloned repo is on your development machine, not on your BB sdcard. When you finish building your kernel, you copy the kernel/modules, etc to your sdcard or nfs share. During development, I include debug symbols, so my kernel is larger than normal. 

One other tool you should learn to use is ftrace. This allows you to trace/log function calls in the kernel/modules. This is very handy when learning how other device drivers work. 

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/86393369-eafd-442e-8884-07fd3fd62b20%40googlegroups.com.

[mzimmers]

OK, I was really hoping to figure this out for myself, but...how do I clone the bb-kernel repository? Here's what I tried:

- went onto GitHub

- found the URL for Robert's bb-kernel repository

- copied the URL into a "git clone" command and executed it

All I get is a .git subdirector and a few small text files: .gitignore, LICENSE, and README.md. So, I gather that I'm not in the right place...can someone please tell me where I went wrong?

[Robert Nelson]

Well there's 35 branchse:

https://github.com/RobertCNelson/bb-kernel/branches/all

so you pick the one you want to use

git checkout origin/<branch> -b tmp

[mzimmers]

Ah, OK...I missed the "branches" button on the web page. A few follow-up questions, please:

- I neglected to mention that I'm looking for the source code; am I in the correct location?

- it seems that branches are maintained for each version and patch level. Do I need to concern myself with finding the right stuff for the sublevel as well?

-  my BBB is currently running 4.4.48. In my brief browsing, I didn't find mention of this particular version. Would it be advisable to move up to a new version as long as I'm going through this exercise?

Thanks.

[Robert Nelson]

On Tue, Jun 27, 2017 at 12:40 PM, mzimmers <mzim...@gmail.com> wrote:
> Ah, OK...I missed the "branches" button on the web page. A few follow-up
> questions, please:
>
> - I neglected to mention that I'm looking for the source code; am I in the
> correct location?

Yes/No

> - it seems that branches are maintained for each version and patch level. Do
> I need to concern myself with finding the right stuff for the sublevel as
> well?

Yeap

> - my BBB is currently running 4.4.48. In my brief browsing, I didn't find
> mention of this particular version. Would it be advisable to move up to a
> new version as long as I'm going through this exercise?

Actually you are running "4.4.48-ti-r88" so you are in the wrong git project..

Just use yakbuild:

https://github.com/RobertCNelson/yakbuild

git clone https://github.com/RobertCNelson/yakbuild
cd ./yakbuild/
cp recipe.sh.sample recipe.sh

open recipe.sh and edit:

kernel_tag="4.4.68-ti-r106" -> kernel_tag="4.4.48-ti-r88"

then run:

./build_kernel.sh

[John Syne]

I see Robert has answered all your question. Here are some suggestions that might help once you complete the first build. 

After you build, you will find the kernel on the yakbuild/KERNEL folder. This is where you edit your code. Do not “build_kernel.sh” again as this will overwrite any code you edited. Use yakbuild/tools/rebuild.sh to rebuild the kernel with your changes. The output of the build is placed in the yakbuild/deploy folder. You will find an yakbuild/deploy/update.sh which you can customize to copy the files to your NFS share or use yakbuild/deploy/updateSD.sh to update your BBB SDcard.

I recommend that you place your kernel module/driver under the yakbuild/KERNEL/drivers folder. If you create a custom folder, then you need to edit the Makefile and Kconfig files in the drivers folder. Your custom folder must also have a Makefile and Kconfig file. Look at other folders in the drivers folders for examples. 

Alternatively, you could also use the yakbuild/KERNEL/samples folder for your source code. 

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/14051cf1-b93d-4e3c-90ae-2ee63b30599c%40googlegroups.com.

[mzimmers]

Hi, John -

I was indeed able to successfully execute Robert's instructions, so I know how to make the kernel. Useful information for when the time comes for it. I will also note your advice above. Very much appreciated.

This thread has drifted a bit, and so I think I'll close it out. I'll pursue my original question (how to cross build and debug an LKM) in another forum, since I think I've bugged everyone here enough for now.

Thanks to all who participated in this thread...

[John Syne]

Well the purpose of my advise what to show you how to cross compile kernel modules without having to worry about kernel version, kernel headers and compiler versions. By using Robert’s build tool, he does all that for you. Better still, if you use source indexing with Eclipse, you get function code completion and can jump to those function using "ctrl left mouse click” and “alt left arrow” to return to your code. There are also lots of example in the Kernel/samples folder. 

Regards,

John

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4646b453-2069-4d7a-a0f8-30f487caaf98%40googlegroups.com.

[mzimmers]

Hi John -

I understand, and your advice was excellent, and much appreciated. I think that part of the reason I'm spinning my wheels is that I don't know enough about what I'm doing to even properly word the questions. In this particular example, despite everyone's help, I'm no closer to solving the original problem than I was at the outset. It's my lack of knowledge in this area that's the culprit, not the assistance I'm getting.

In any event, it's pretty clear that this isn't a BBB problem. I've tried running it on my host, and the test program blows up on the write statement. So, I'm going to quit pestering the people here about a problem that's proven to be somewhat off-topic.

Thanks again.

[William Hermans]

mz,

You know what I'd do in your shoes ? I'd just setup a development sdcard for your bb, and compile modules natively. on the bb. Much simpler, no hassle, no pain in the butt. Compiling a kernel on a bb may take a few days, but a kernel module should not take very long.

Another thing you should be aware of when it comes to DR Molloy's book. Is that the information is dated, and not how one would go about doing things with current versions of Debian. For instance, with Jessie there are some mechanisms built in now. That allow for much easier cross compiling. With that said, asking anyone on the group here to help you with that process, would be asking too much. But suffice it to say, multi arch on Debian is much better than with previous versions of debian. The best way to start learning with that in my mind is to create, and use an x64 debian virtual machine from something like virtual box. Then just start experimenting with instructions off the web. Until you find a process that works.

Anyway, you just start getting your hands dirty, and experimenting. Then things should eventually start working out. google "cross compile kernel module deb" Then just start reading guides that only talk about armhf, and Debian Jessie. Things to be aware of, is that you'll need to apt-get install <your kernel header sources>, and you'll need to be able to compile those sources from your version of gcc ( gcc --version). The only additional package you'll need to install on that image aside from the kernel headers is build-essential. Unless you need something specific like libusb-dev for USB development, or the like.

[William Hermans]

Then later, once you understand native module development much better, you'll be able to apply that information towards cross compiling much easier. Just be aware, this is not an overnight sort of situation. It could take years to grasp, but if you apply yourself, it'll probably take a lot less time.

[William Hermans]

Ah, something I unintentionally left out. The arch you'll need is armhf. Granted, I'm not 100% sure that even applies to the kernel, or kernel modules.

[mzimmers]

Hey, William...thanks for the pointers. I actually do already have cross-development working (for user space programs). I'm using Qt Creator, and a Linaro toolchain and sysroot. I built Qt for the armhf in order to get the right qmake.conf file, and I can cross-debug using gdbserver on the BBB. So, I've got that going already.

But, as you're aware, cross building for kernel stuff is more involved, and I'm inclined to agree with you that I'm making this a bigger deal than it is. I'm prepared to move on, though I'd really like to know why this example program isn't working. But, as I mentioned, this isn't a BBB problem, so I'm not going to pursue it here.

[William Hermans]

On Thu, Jun 29, 2017 at 10:12 AM, mzimmers <mzim...@gmail.com> wrote:

Hey, William...thanks for the pointers. I actually do already have cross-development working (for user space programs). I'm using Qt Creator, and a Linaro toolchain and sysroot. I built Qt for the armhf in order to get the right qmake.conf file, and I can cross-debug using gdbserver on the BBB. So, I've got that going already.

But, as you're aware, cross building for kernel stuff is more involved, and I'm inclined to agree with you that I'm making this a bigger deal than it is. I'm prepared to move on, though I'd really like to know why this example program isn't working. But, as I mentioned, this isn't a BBB problem, so I'm not going to pursue it here.

Right. You want to know how much I personally cross compile ? Zero. When I was toying around with compiling my own kernel was about the only time. At one point I did setup the Linaro cross tool chain, with code::blocks( IDE ) on Windows and got that working. But IMHO time is much better spent learning how to compile natively, from the command line. Because that information can be used anywhere. Knowing your tool chain from the command line is a must in my opinion. After that, learning a build tool such as make is a must too. Quite honestly though, I hardly ever even use make. Most of my projects are modular in nature, and small applications that communicate with each other through files. Or other means like mqtt outbound to a server somewhere. So basically my whole process starts with writing the code then . . . $ gcc -Wall <source_file> <target_executable_file>

Keeping things modular and small makes life for me much easier . . .Not to be confused with kernel modules of course ;)

[William Hermans]

Missed a -o in there, but hopefully you get the point ;)