Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
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:
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 <address@hidden>
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 <address@hidden>
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 <address@hidden>
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?