kernel headers on prebuilt armhf image

Can anybody tell me how to install kernel headers on the prebuilt armhf images (available at www.armhf.com)? Thanks.

apt-get install source kernel-source?

the traditional "kernel headers" package on arm is still worthless...
Grab the kernel patch + config based on (uname -r) from
http://rcn-ee.net/deb/

Regards,

Thank you sir.

Sorry for being an idiot, but I guess I should go ahead and ask - will the kernel patch allow me to compile a kernel module on the BBB? I tried to compile dvbhdhomerun (in connection with another post I made on this board) last night, but it failed due to the lack of a /build directory.

I think the directory was /lib/modules/bone-15 3.x.x/build

Hello,

sorry for cross-posting this to the beaglebone group, too, but on earlier versions of the kernel (e.g. 3.2.x), you distributed a second .deb in addition to the kernel image, which was called kernel-headers-xxx and included the module.symvers file from the build, which allowed people to compile modules right on the Beaglebone without needing to recompile the entire kernel first.

However, newer kernel .debs (like the current 3.8.x kernels) don’t have this headers .deb anymore. Is there any other way to obtain a module.symvers for your kernel builds, other than re-compiling the kernel ourselves?

Many thanks,
Georg

Well other then the "nice" symlink fix in the kernel header's deb, the
package was pretty much useless as only a limited set of things would
actually build against it.. (aka: more things failed with missing
includes) I've since elected to stop uploading that *.deb and just
have users build from source, till more of the arm multiplatorm stuff
gets mainline and the package works for everyone..

Regards,

I understand.

However, how about just distributing the module.symvers for each release by itself then? I agree that the headers .deb wasn’t all that useful, but with the module.symvers, you could download the official kernel source, apply your patch, and then set up the build environment for the modules without needing to re-compile the entire kernel in order to build a 1000-line-ish module. module.symvers is really the only thing I’m missing right now.

I think the Raspbian folks do it like this, e.g. they keep the module.symvers for their kernel releases in their git, so that you can setup your build environment easily.

Please think about it, I’d really appreciate it.

So some background, every "target family" omap / omap-psp /imx that i
build, the kernel is separated into three versions, stable, testing &
experimental... For the bone it's on omap-psp/stable, for the bone
black it's omap-psp/testing... Someday 'testing' will be pushed on
'stable' for the omap-psp tree, and eventually it'll get switched to
the omap/multi arm tree..

So taking a look at my shell script that actually builds the kernel's
on the farm hardware, i was only uploading the kernel headers in the
"stable" case. I thought i had disabled it for all.. Humm, so I just
enabled it again for stable/testing release's..

Regards,

Thank you!! I’ll go ahead and cross-compile your am33x-v3.8 branch for now and switch back to my previous workflow for future releases that’ll have the headers .deb again.

Again sorry to be a simpleton here. Am I correct in thinking based on the following statements that I can recompile the kernel that is currently on my BBB (bone-15 3.8.x) and then be able to build the kernel module on the BBB directly? Thanks again.:

"I’ve since elected to stop uploading that *.deb and just have users build from source, till more of the arm multiplatorm stuff
gets mainline and the package works for everyone… " - rcn

and

“I agree that the headers .deb wasn’t all that useful, but with the module.symvers, you could download the official kernel source, apply your patch, and then set up the build environment for the modules without needing to re-compile the entire kernel in order to build a 1000-line-ish module. module.symvers is really the only thing I’m missing right now.” -georg