Hi All,
I’m new here and not familiar with the format of this forum, so I hope I’ve posted this under the right categories.
I appologise in advance because I’m sure you’ve heard this plenty of times but: I’m having trouble building a kernel.
If you are pressed for time you can cut to the chase by looking for the marker in chapter 5 below.
** 1. Background of this project: **
This is part of a commercial project which, if it bares fruit, we will be publishing as open source. At the moment I’m putting a lot of my own time into it to try and get us through the initial pain barrier and prove the concept.
The project involves generating and receiving audio signals, for which we will be building dedicated hardware. I need to write a driver for this audio interface.
** 2. The end goal: **
I need to write a driver to transport two channels of audio in full duplex over the I2S interface on the Beaglebone black to an external DAC and ADC. In theory this should be simple (it should just be a modification of the existing audio driver), but the instructions are a bit vague.
In order to be able to experiment with the driver, I want to be able to compile it as a module and load it into the kernel running on the Beaglebone Black. I would also like the option of compiling in.
** 3. The immediate goal: **
On order to work with kernel drivers, I wanted a complete set of kernel sources that matched my running system. While I should not need to build the entire kernel to compile my driver (because I can build this as a module), it seemed reasonable that being able to compile a working kernel would prove that my build environment was correct.
What I’m trying to achieve is the ability to compile a kernel (and matching modules) identical to those already in the distribution, as a starting point for modification.
Hope this makes sense so far.
** 4. The problems: **
While I’ve found plenty of instructions on-line regarding how to build a kernel for the BBB, they all seem to be different. So I suppose the crux of my question is how is the kernel for the Debian distribution actually built?
** 5. My latest failure: **
On a desktop machine, I cloned Robert Nelson’s repository
git clone https://github.com/RobertCNelson/linux-stable-rcn-ee
I then checked out the source matching the kernel running on the beaglebone into a new branch called ‘tmp’
(uname -r on the beaglebone reports 4.4.54-ti-r93)
cd ./linux-stable-rcn-ee
git checkout 4.4.54-ti-r93 -b tmp
I asked git to ignore its own hidden files when exporting
echo .gitattributes export-ignore > .gitattributes
echo .gitignore export-ignore >> .gitattributes
git add -f .gitattributes
git commit -m “Ignoring .git on archive”
And then exported the working tree, to give a “traditional” tarball of the kernel source tree, about 600MB in size
git archive --format tar --output …/linux-src.tar HEAD
I then copied this tarball to the beaglebone and unpacked it into /usr/src/linux
The beaglebone was running a fresh installation of the disk image bone-debian-8.7-iot-armhf-2017-03-19-4gb
I then created a directory under /root for the output of the build process, so that I could see what it has done, and to keep the source tree clean.
mkdir /root/kbuild
cut to the chase:
Now, there was no .config in the root of the source tree, and no directory of example configs supplied with it. I therefore ran
make O=/root/kbuild menuconfig
and accepted the defaults. This generated a .config as expected.
I have a feeling this may be a problem. Surely building the correct kernel depends upon a specific configuration, but I couldn’t see any instruction as to where to find one.
I then proceeded as normal with
make O=/root/kbuild zImage
make O=/root/kbuild install
Obviously, install complained because I hadn’t built the modules, but this shouldn’t matter because the freshly built zImage should be identical to that already in /boot.
The freshly-compiled kernel was installed as
/boot/vmlinuz-4.4.54
whereas the original was
/boot/vmlinuz-4.4.54-ti-93
When I attempted to boot the new kernel, I got nothing. No boot messages, not even a video signal.
Now I’m obviously misunderstanding something, and it’s probably quite simple. However I’m baffled by the multitude of slightly different HOWTOs, out-of date documentation and instructions that don’t match the systems they’re describing.
Thanks for reading this long post - I’d really appreciate any advice.
Tom.