On Sun, Oct 23, 2011 at 11:24 AM, Stuart Hughes <[email protected]> wrote: > Hi Jon, > > This stuff is processed in config/userspace/toolchain.lkc which should > be included in the BSP's config/platform/_target_/main.lkc file. > > Maybe whoever made this platform forgot to add it into the list of > toolchains for that platform? Which platform do you have selected?
Embedded Artists board with the NXP LPC3131 > > Regards, Stuart > > On 21/10/11 15:05, [email protected] wrote: >> On Fri, Oct 21, 2011 at 4:01 AM, Stuart Hughes <[email protected]> wrote: >>> 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 >> >> I'm not getting the () Custom option when the NXP toolchains are enabled. >> >> I just did a cvs update >> >>> >>> 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? >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > -- Jon Smirl [email protected] _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
