Hi Jon,
I understand your frustration, however if you need NXP kernel patches
integrated etc, you probably need to get a commercial agreement in place
with them or some other entity to do this (or have a program to do this
yourself).
Regarding toolchains, you can use non-LTIB defined toolchains, provided
you are aware of some potential pitfalls.
First of all to do the selection, run:
./ltib -m config
and then select under: "--- Toolchain selection." go to the next line
and select the current toolchain and hit the enter key, you should see
something like this (depending on BSP):
(X) arm gcc-4.2.4 uClibc-0.9.30.1 soft float
( ) Custom
Use the arrow key and select custom and then enter.
You now have these options:
Toolchain (Custom) --->
() Enter the custom toolchain path.
() Enter the toolchain prefix
() Enter any CFLAGS for gcc/g++
For each one, enter the values for your toolchain. For example they
could be:
/opt/z2/usr/local/gcc-4.2.4-uClibc-0.9.30.1-nfp-6/arm-linux-uclibc/usr
arm-linux-uclibc-
-msoft-float
Now save this and then you could try to run: ./ltib
The pitfall I spoke about is that the package baselibs.spec expects the
toolchains to be built and laid out in a particular way. The ones that
are "known" are the CodeSourcery toolchains (of the vintage in LTIB) and
also to some extent uClibc toolchains as were built when I was at
Freescale. If your toolchain is not laid out this way, you'll need to
adjust the paths in the .spec file (you could override this locally in
your config/platform/_target_ directory). BTW: the purpose of baselibs
is to copy the toolchain's target libraries to the target image (rather
than re-building glibc/uclibc) so that you are guaranteed that the libs
you build and run against match.
Regards, Stuart
On 20/10/11 14:41, [email protected] wrote:
On Thu, Oct 20, 2011 at 3:55 AM, Stuart Hughes<[email protected]> wrote:
Hi Jon,
Please don't preach. This is well known, but there are good reasons not to
do this. Mostly it comes down to time and money, a constraint many of us do
have.
Also there are many other reasons why this does not get done, so calm down a
bit. All this stuff is public and there if you wish to use it, otherwise
use something else.
A lot of developers are unaware of how badly this problem can bite
them until they build and ship a product that subsequently gets hacked
because of a security bug. In the past we have wasted large amounts of
money recovering from this problem and want to try and avoid it in the
future.
On the positive side the current state of embedded support is far
better than it was five years ago.
I'm just annoyed since forward porting uboot support for the lpc3130
has turned out to be very complicated. NXP wrote their own two stage
boot system which is proving hard to map onto the model supplied by
current uboot. It can definitely be done but it is significant work.
We want a current kernel and I was able to forward port the NXP kernel
patches in a couple of weeks. But there are changes in the way ARM
ATAGs are passed from uboot into the kernel which are addressed in a
more recent uboot. We are considering switching to a different CPU to
reduce the software load.
A very useful option to add to ltib would be a simple config option to
use the ARM cross compilers already on the system (ie the Linaro ones
in Ubuntu). That would make it much easier to test with the current
compilers. I tried poking around in the scripts to add it but I
couldn't figure out how to do it.
Regards, Stuart
On 19/10/11 14:23, [email protected] wrote:
Please submit any publicly useful changes you make to packages
upstream and don't carry the patches around in ltib for years. I am
spending a month right now trying to forward port the lpc313x uboot
changes up to current uboot. I've already brought the lpc313x changes
up to the current kernel and need a newer uboot to support it. If
those changes had been submitted upstream three years ago when they
were written I wouldn't have to be doing this.
You really want changes submitted upstream. If you don't do it then
you get locked into the version of the program that you patched. You
may think that is saving you work by not having to hassle with the
submission. And that appearance will be true until a security hole is
found and patched in a latter version and your boss tells you that you
have to apply the patch. Now you have a mess. The patch is against a
latter version of the app that doesn't match your source code.
To deal with the mess you either have to create your own private fork
where you apply security patches to your old, patched code (this is a
tower of cards that will fall as more patches accumulate) or you have
to forward port the your initial patch. You could have avoided all of
this by simply submitting the initial patch upstream. I've seen people
change jobs rather than deal with messes created by private forks.
Of course you can choose to ignore the security patches. Do you know
how easy it is to hack something when you have the source code of the
patch fixing the vulnerability?
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/ltib
