Hi Wayne,
The rootfs/usr/include/... area is populated as packages build. This is
the area where packages should share public interfaces to their resources.
In the case of the kernel, this area (rootfs/usr/include/linux) should
be the public userspace/linux header interface. So you need to decide
whether or not these headers should be accessible from userspace (take a
look at the existing BSP where you got this from to see what they do).
If this is not for userspace (for example some kernel module), then it's
acceptable to reference headers from rpm/BUILD/linux/.... however if
you need to do this, the using package should make sure to set the
dependency for kernel headers, for example if you look at
config/userspace/packages.lkc you'll see iproute needs the internal
kernel header and is set as follows:
config PKG_IPROUTE
depends CAP_HAS_MMU
depends !KERNEL_NONE
select PKG_KERNEL_WANT_HEADERS
bool "iproute(2)"
Regards, Stuart
On 27/06/11 17:30, Wayne Tams wrote:
Hi,
When I look at a more verbose gcc output, I can see that the build is
searching /ltib/rootfs/usr/src/linux/include. I didn't realise that
the RFS was something I had to consider when the packages were being
built, I just thought the build files came from the elsewhere. Right,
please bare with me, am I right in saying
that /ltib/rootfs/usr/src/linux/include is populated during the kernel
build and then the packages are built against that location. So really
what I need to be doing is figuring out at what point ipu.h and
mxcfb.h should be copied into the RFS and how this act is achieved.
Thanks for the assistance so far, very much a learning process for me.
Regards
Wayne
On Mon, Jun 27, 2011 at 4:49 PM, Stuart Hughes <[email protected]
<mailto:[email protected]>> wrote:
Hi Wayne,
Looking at the output you posted, lines 84/85 seem to be the root
of the problem:
In file included from mxc_ipu_hl_lib.c:45:
mxc_ipu_hl_lib.h:96:23: error: linux/ipu.h: No such file or
directory
mxc_ipu_hl_lib.h:97:25: error: linux/mxcfb.h: No such file or
directory
You need to make sure that these headers are available in your
kernel source tree, and that they get installed into the
rootfs/usr/src/linux/include area. I'm assuming that they're
something that should be publicly exported? (check in the original
BSP if you can).
Alternatively, you could access them by adding a -I to
rpm/BUILD/linux, however that's not really a good idea if the
using package is userspace (it should not be groping around the
internal kernel headers).
Regards, Stuart
On 27/06/11 15:08, Wayne Tams wrote:
Hi Stuart,
Your advice helped and I have managed to build a kernel using the
kernel source from the SoM BSP. I had to do some tweaking as LTIB
fails the build at imx-lib. This may be outside your remit but I
am wondering if you can over a suggestion on how to fix this
problem, the log is located here,
http://pastebin.com/Btb1mN58 lines 84 and 85 don't make any sense
to me as I have added them from the Freescale BSP to my BSP but
the build still can't find them.
Thanks
Wayne
On Wed, Jun 22, 2011 at 9:04 AM, Stuart Hughes <[email protected]
<mailto:[email protected]>> wrote:
Hi Wayne,
I was the main (almost only) developer of LTIB back when I
worked at Freescale. At the time I left, aside from some
unpublished BSPs, the tools were the same. I'm not sure what
has happened since I left (over 2 years ago), but I would say
that if their BSP does what you want, stick with that; if not
then Savannah CVS may be better in terms of getting help (if
you are a customer of Freescale's they may help too).
To help you with this question you really need to send a
patch (diff) showing what you've changed and also the output
of any failure messages.
So far as the ltib kernel config processing goes, here's how
it works:
1. First build: use the one in config/platform/_target_/
named in the choice selected when you run ./ltib -m config
(or the one named in the config/platform/_target_/defconfig
if you don't change anything).
2. Once the kernel has been built, an updated kernel .config
file will be placed in
config/platform/_target_/_kernel_config_name.dev. The reason
for this is that:
* Running the kernel configuration parser can (will)
change the input kernel config file
* You may have selected other options (if you ran: ./ltib
-p kernel --configure
There is some useful documentation on the website:
http://ltib.org (the FAQ) and also in the doc directory in
the LTIB source tree. It's worth scanning that for ideas.
Bottom line; send a patch/actual output and the people on
this list may be able to see what the issue is and help you.
Regards, Stuart
On 21/06/11 14:40, Wayne Tams wrote:
Hi Stuart,
Thanks for the the reply, please bare with me, I'm new to
LTIB and embedded Linux.
I first tried changing the default toolchain, kernel source
and toolchain prefix in LTIB, with the default kernel
configuration, the build failed.
This failure might have something to do with the kernel
config, it would appear that the config that had been used
isn't that of the default config from the kernel source. If
I were to 'make menuconfig' the kernel source the menu that
appears has a list of different options when compared to the
kernel menuconfig that LTIB starts up. I had a look at
main.lkc but I don't quite understand why LTIB is ignoring
the default .config for the kernel and appears to be using
some other .config, i.e I'm not sure which config is being used?
Would I be better dumping the freescale version of LTIB and
using the CVS version, is there any difference except for
the supported platforms?
Thanks
Wayne
On Tue, Jun 21, 2011 at 8:46 AM, Stuart Hughes <[email protected]
<mailto:[email protected]>> wrote:
Hi Wayne,
Making the changes are easy. Basically you need to edit
the config/platform/_target_/main.lkc file to refer to
the toolchain/kernel you want to use. Make sure to copy
also the correct TOOLCHAIN_FLAGS etc from the existing
BSP using those assets.
The main thing you'll need to do is to test.
Regards, Stuart
On 20/06/11 16:49, Wayne Tams wrote:
Hi,
Is it difficult to integrate kernel source and a
tool-chain into LTIB from another BSP. The reason I ask
is that I am using an i.MX53 based SoM and the build
tools are bad and I really like using LTIB, my exposure
coming from using LTIB with the i.MX53QSB.
I can see from the Freescale provided LTIB that I could
select custom kernel source and a custom toolchain,
what are likely outcomes if I were to change these? Do
I need to be digging deeper and look at modifying other
files?
Regards
Wayne
_______________________________________________
LTIB home page:http://ltib.org
Ltib mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/ltib
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/ltib
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/ltib
