Patched J1939 header files don't show up in SDK

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Patched J1939 header files don't show up in SDK

2,076 Views
craigdenson
Contributor II

We applied the J1939 patch for socketCAN which builds just fine, and the built kernel announces can J1939 SAE support at bootup. but when we build the sdk, using bitbake image -c populate_sdk, the modified kernel headers are NOT in .../usr/include/linux. We're currently building a 3.0.35 kernel, but it appears that the recipe for linux-libc-headers ignores whatever header files you've got in the linux-imx build and fetches the headers from source.

I've floundered around looking at how to get this to work, but if anyone knows how to get patched kernel headers into the sdk, I'd be much obliged.

After reading the Yocto docs and searching gmane.linux.embedded.yocto.meta-freescale, it seems like bitbake <image> -c populate_sdk should do what I want, but it doesn't.

"Use bitbake <image> -c populate_sdk. This method has significant advantages over the previous method because it results in a toolchain installer that contains the sysroot that matches your target root filesystem. "

I tested bitbake meta-toolchain and that gives me similar results.  Based on comments on the gmane mailing list from OtavioSalvador and others, it seems as though this is intentional, but to me it seems entirely wrong. I haven't tried the ADT installer method, but have little hope that will give different results.

Thanks,

Craig

0 Kudos
5 Replies

1,164 Views
OtavioSalvador
Senior Contributor II

For this you need to install the kernel-dev package into the toolchain.

1,164 Views
craigdenson
Contributor II

ok that works, headers are in sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/src/kernel/include/linux/can/j1939.h, etc.

I still don't completely understand the rationale, though, for separating the pre-assembled libc headers from patched kernel headers. Most of the comments on gmane seemed to revolve around eliminating unnecessary rebuilds; what is required to move patched/changed headers into linux-libc-headers? Shouldn't there be a linux-libc-headers-dev package?

0 Kudos

1,164 Views
OtavioSalvador
Senior Contributor II

The problem rely in API and ABI compatibility. The short version of this is that changing libC headers can imply different set of supported syscalls onto Linux so if we make it to use the machine kernel header it'd make all packages which depends on libC headers machine specific and it'd hurt build time and other consequences.

1,164 Views
craigdenson
Contributor II

ok, I think I get it: in effect the entire set of rpms or ipks would need to be rebuilt. For those of us who are only dealing with a single machine, that's a large one-time hit; for those supporting and testing multiple platforms that would be a very large hit.

0 Kudos

1,164 Views
craigdenson
Contributor II

Thanks for the reply, I'll kick off a build to test this. Navigating all the possibilities of Yocto is daunting even given the large amount of documentation.

0 Kudos