Third party toolchain, kernel, bootloader

Third party toolchain, kernel, bootloader

[Robert Berger]

Hi,

I'm working on a couple of projects trying to use yocto and it boils
down to the fact, that the packages and the package management (with a
few tweaks) are very valuable.

On the other hand "just to give it a try" it's a major effort to add
kernel and bootloader to poky and moreover the gcc which comes with poky
is not always what I need in terms of stability but also features (need
e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
vendor provided kernel and bootloader.

What I'm after is to add some packages from poky to some 3rd party
rootfs. One major problem I have is the dependency on libc6 (>= 2.12)
Usually I have some older versions of libc6: e.g. libc-2.8.so.

For the projects I'm currently working on kernel and bootloader are
already compiling/running and tested and I would like to add packages
like qt-embedded to the various rootfs.

To achieve this I would need a mechanism to use a 3rd party toolchain
with poky (and maybe to skip the build steps for kernel and boot loader).

Is this something yocto/poky was made for, or am I totally off?
Am I the only one who has such kind of problems?
How are others tackling these kind of problems?

Please advise,

Regards,

Robert


..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
only): Don't do it yet." - M.A. Jackson (not the singer)

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: Third party toolchain, kernel, bootloader

[Darren Hart]

On 05/05/2011 11:28 PM, Robert Berger wrote:
> Hi,
> 
> I'm working on a couple of projects trying to use yocto and it boils
> down to the fact, that the packages and the package management (with a
> few tweaks) are very valuable.
> 
> On the other hand "just to give it a try" it's a major effort to add
> kernel and bootloader to poky and moreover the gcc which comes with poky
> is not always what I need in terms of stability but also features (need
> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
> vendor provided kernel and bootloader.


We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
specific feature? Hitting a particular bug?


> What I'm after is to add some packages from poky to some 3rd party
> rootfs. One major problem I have is the dependency on libc6 (>= 2.12)
> Usually I have some older versions of libc6: e.g. libc-2.8.so.
> 
> For the projects I'm currently working on kernel and bootloader are
> already compiling/running and tested and I would like to add packages
> like qt-embedded to the various rootfs.


Is the third party rootfs built using an older version of poky or oe?


> To achieve this I would need a mechanism to use a 3rd party toolchain
> with poky (and maybe to skip the build steps for kernel and boot loader).
> 
> Is this something yocto/poky was made for, or am I totally off?
> Am I the only one who has such kind of problems?
> How are others tackling these kind of problems?


From the above I'm getting the impressions you're trying to build
package with a recent yocto for a much older image that might have even
been built with something other than yocto (or poky).

I wouldn't expect that to work. The package names, dependency names,
distribution policy, libc version (as you noticed) will fight you the
whole way.

Please elaborate if I'm misinterpreting what you are trying to do.

--
Darren

> 
> Please advise,
> 
> Regards,
> 
> Robert
> 
> 
> ..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
> only): Don't do it yet." - M.A. Jackson (not the singer)
> 
> My public pgp key is available at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
> 
> 
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Third party toolchain, kernel, bootloader

[Robert Berger]

Hi,

On 05/06/2011 08:09 PM, Darren Hart wrote:
> 
> 
> On 05/05/2011 11:28 PM, Robert Berger wrote:
>> Hi,
>>
>> I'm working on a couple of projects trying to use yocto and it boils
>> down to the fact, that the packages and the package management (with a
>> few tweaks) are very valuable.
>>
>> On the other hand "just to give it a try" it's a major effort to add
>> kernel and bootloader to poky and moreover the gcc which comes with poky
>> is not always what I need in terms of stability but also features (need
>> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
>> vendor provided kernel and bootloader.
> 
> 
> We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
> specific feature? Hitting a particular bug?

I'm hitting a problem regarding some compiler options, but dont't have
access to my test system at the moment.

> 
> 
>> What I'm after is to add some packages from poky to some 3rd party
>> rootfs. One major problem I have is the dependency on libc6 (>= 2.12)
>> Usually I have some older versions of libc6: e.g. libc-2.8.so.
>>
>> For the projects I'm currently working on kernel and bootloader are
>> already compiling/running and tested and I would like to add packages
>> like qt-embedded to the various rootfs.
> 
> 
> Is the third party rootfs built using an older version of poky or oe?

No.

> 
> 
>> To achieve this I would need a mechanism to use a 3rd party toolchain
>> with poky (and maybe to skip the build steps for kernel and boot loader).
>>
>> Is this something yocto/poky was made for, or am I totally off?
>> Am I the only one who has such kind of problems?
>> How are others tackling these kind of problems?
> 
> 
> From the above I'm getting the impressions you're trying to build
> package with a recent yocto for a much older image that might have even
> been built with something other than yocto (or poky).

Your guess is absolutely right. I have no idea with what the roofs were
built with.

> 
> I wouldn't expect that to work. The package names, dependency names,
> distribution policy, libc version (as you noticed) will fight you the
> whole way.
> 
> Please elaborate if I'm misinterpreting what you are trying to do.

I am actually trying to solve 2 problems here:

Problem 1)
I want to get a sato rootfs on the TechNexion twister TAM-3517.
Bootloader and custom kernel are provided by TechnNexion based on some
BSP by TI. Rootfs will be provided by poky. I'll tell you more details
about my issues as soon as I'll have access to my test system.

Problem 2)
I want to get webkit with or without QT on top of directfb on various
set-top boxes - toolchains and rootfs are by third parties - I have no
idea how these development environments were built.
Kernel and boot loader and rootfs are running, tested and happy.
Here is my "naive" way of thinking:
In order to add webkit I will either need to build all packages and
dependencies needed (and that's a lot) from scratch or tell poky to use
a certain toolchain+libs and reuse poky/oe recipes to build the packages
I need (with some tweaks I guess).

Regards,

Robert



> 
> --
> Darren
> 
>>
>> Please advise,
>>
>> Regards,
>>
>> Robert
>>
>>
>> ..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
>> only): Don't do it yet." - M.A. Jackson (not the singer)
>>
>> My public pgp key is available at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>>
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
> 

Re: Third party toolchain, kernel, bootloader

[Xianghua Xiao]

why not try Angstrom directly? Yocto, while it builds for Beagleboard
xM somehow, is still very much a x86/ATOM distribution.

At this moment, Angstrom is the best for ARM, the second choice will
be TI's Arago, Arago has yet to be ported to the new OE framework.

I use both Angstrom and Arago for product devel on ARM. If I use
x86/ATOM I will likely choose Yocto though.

Xianghua

On Sat, May 7, 2011 at 2:42 PM, Robert Berger
<gmane@reliableembeddedsystems.com> wrote:
> Hi,
>
> On 05/06/2011 08:09 PM, Darren Hart wrote:
>>
>>
>> On 05/05/2011 11:28 PM, Robert Berger wrote:
>>> Hi,
>>>
>>> I'm working on a couple of projects trying to use yocto and it boils
>>> down to the fact, that the packages and the package management (with a
>>> few tweaks) are very valuable.
>>>
>>> On the other hand "just to give it a try" it's a major effort to add
>>> kernel and bootloader to poky and moreover the gcc which comes with poky
>>> is not always what I need in terms of stability but also features (need
>>> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
>>> vendor provided kernel and bootloader.
>>
>>
>> We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
>> specific feature? Hitting a particular bug?
>
> I'm hitting a problem regarding some compiler options, but dont't have
> access to my test system at the moment.
>
>>
>>
>>> What I'm after is to add some packages from poky to some 3rd party
>>> rootfs. One major problem I have is the dependency on libc6 (>= 2.12)
>>> Usually I have some older versions of libc6: e.g. libc-2.8.so.
>>>
>>> For the projects I'm currently working on kernel and bootloader are
>>> already compiling/running and tested and I would like to add packages
>>> like qt-embedded to the various rootfs.
>>
>>
>> Is the third party rootfs built using an older version of poky or oe?
>
> No.
>
>>
>>
>>> To achieve this I would need a mechanism to use a 3rd party toolchain
>>> with poky (and maybe to skip the build steps for kernel and boot loader).
>>>
>>> Is this something yocto/poky was made for, or am I totally off?
>>> Am I the only one who has such kind of problems?
>>> How are others tackling these kind of problems?
>>
>>
>> From the above I'm getting the impressions you're trying to build
>> package with a recent yocto for a much older image that might have even
>> been built with something other than yocto (or poky).
>
> Your guess is absolutely right. I have no idea with what the roofs were
> built with.
>
>>
>> I wouldn't expect that to work. The package names, dependency names,
>> distribution policy, libc version (as you noticed) will fight you the
>> whole way.
>>
>> Please elaborate if I'm misinterpreting what you are trying to do.
>
> I am actually trying to solve 2 problems here:
>
> Problem 1)
> I want to get a sato rootfs on the TechNexion twister TAM-3517.
> Bootloader and custom kernel are provided by TechnNexion based on some
> BSP by TI. Rootfs will be provided by poky. I'll tell you more details
> about my issues as soon as I'll have access to my test system.
>
> Problem 2)
> I want to get webkit with or without QT on top of directfb on various
> set-top boxes - toolchains and rootfs are by third parties - I have no
> idea how these development environments were built.
> Kernel and boot loader and rootfs are running, tested and happy.
> Here is my "naive" way of thinking:
> In order to add webkit I will either need to build all packages and
> dependencies needed (and that's a lot) from scratch or tell poky to use
> a certain toolchain+libs and reuse poky/oe recipes to build the packages
> I need (with some tweaks I guess).
>
> Regards,
>
> Robert
>
>
>
>>
>> --
>> Darren
>>
>>>
>>> Please advise,
>>>
>>> Regards,
>>>
>>> Robert
>>>
>>>
>>> ..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
>>> only): Don't do it yet." - M.A. Jackson (not the singer)
>>>
>>> My public pgp key is available at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>>>
>>>
>>> _______________________________________________
>>> poky mailing list
>>> poky@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/poky
>>
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>

Re: Third party toolchain, kernel, bootloader

[Robert Berger]

Hi,

On 05/08/2011 01:10 AM, Xianghua Xiao wrote:
> why not try Angstrom directly? Yocto, while it builds for Beagleboard
> xM somehow, is still very much a x86/ATOM distribution.

As far as I'm concerned yocto is fine for the Beagle-XM as long as you
don't care about graphics and video and according to TI Mr. Angstrom
himself (hi Koen) is working on yocto as well.

Well I'm __NOT__ working on any x86/Atom project or board for various
reasons, but with MIPS big and little endian, ARM and PPC (which could
be covered by yocto) and also with SH and more exotic things. So I'm
trying to find a solution, which can be used for all of the projects I'm
working on (and as you see I have some funny ideas which i would like to
be covered)
Yocto is still young and open (it's not just x86/Atom) and has lots of
potential.

> 
> At this moment, Angstrom is the best for ARM, the second choice will
> be TI's Arago, Arago has yet to be ported to the new OE framework.

I played with Angstrom and will play for the graphics/video stuff with
Arago, but think that Linaro, which is folded into yocto is the way to
go for ARM. The vendors and board manufacturers need to understand that
it's too much effort to maintain vendor trees and will need to push
their stuff upstream towards mainline.

> 
> I use both Angstrom and Arago for product devel on ARM. If I use
> x86/ATOM I will likely choose Yocto though.

As I said, I did not use x86/Atom for embedded projects so far and don't
think this will happen in the near future - unless Intel donates some
boards for me to play with;)

Regards,

Robert

> 
> Xianghua
> 
> On Sat, May 7, 2011 at 2:42 PM, Robert Berger
> <gmane@reliableembeddedsystems.com> wrote:
>> Hi,
>>
>> On 05/06/2011 08:09 PM, Darren Hart wrote:
>>>
>>>
>>> On 05/05/2011 11:28 PM, Robert Berger wrote:
>>>> Hi,
>>>>
>>>> I'm working on a couple of projects trying to use yocto and it boils
>>>> down to the fact, that the packages and the package management (with a
>>>> few tweaks) are very valuable.
>>>>
>>>> On the other hand "just to give it a try" it's a major effort to add
>>>> kernel and bootloader to poky and moreover the gcc which comes with poky
>>>> is not always what I need in terms of stability but also features (need
>>>> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
>>>> vendor provided kernel and bootloader.
>>>
>>>
>>> We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
>>> specific feature? Hitting a particular bug?
>>
>> I'm hitting a problem regarding some compiler options, but dont't have
>> access to my test system at the moment.
>>
>>>
>>>
>>>> What I'm after is to add some packages from poky to some 3rd party
>>>> rootfs. One major problem I have is the dependency on libc6 (>= 2.12)
>>>> Usually I have some older versions of libc6: e.g. libc-2.8.so.
>>>>
>>>> For the projects I'm currently working on kernel and bootloader are
>>>> already compiling/running and tested and I would like to add packages
>>>> like qt-embedded to the various rootfs.
>>>
>>>
>>> Is the third party rootfs built using an older version of poky or oe?
>>
>> No.
>>
>>>
>>>
>>>> To achieve this I would need a mechanism to use a 3rd party toolchain
>>>> with poky (and maybe to skip the build steps for kernel and boot loader).
>>>>
>>>> Is this something yocto/poky was made for, or am I totally off?
>>>> Am I the only one who has such kind of problems?
>>>> How are others tackling these kind of problems?
>>>
>>>
>>> From the above I'm getting the impressions you're trying to build
>>> package with a recent yocto for a much older image that might have even
>>> been built with something other than yocto (or poky).
>>
>> Your guess is absolutely right. I have no idea with what the roofs were
>> built with.
>>
>>>
>>> I wouldn't expect that to work. The package names, dependency names,
>>> distribution policy, libc version (as you noticed) will fight you the
>>> whole way.
>>>
>>> Please elaborate if I'm misinterpreting what you are trying to do.
>>
>> I am actually trying to solve 2 problems here:
>>
>> Problem 1)
>> I want to get a sato rootfs on the TechNexion twister TAM-3517.
>> Bootloader and custom kernel are provided by TechnNexion based on some
>> BSP by TI. Rootfs will be provided by poky. I'll tell you more details
>> about my issues as soon as I'll have access to my test system.
>>
>> Problem 2)
>> I want to get webkit with or without QT on top of directfb on various
>> set-top boxes - toolchains and rootfs are by third parties - I have no
>> idea how these development environments were built.
>> Kernel and boot loader and rootfs are running, tested and happy.
>> Here is my "naive" way of thinking:
>> In order to add webkit I will either need to build all packages and
>> dependencies needed (and that's a lot) from scratch or tell poky to use
>> a certain toolchain+libs and reuse poky/oe recipes to build the packages
>> I need (with some tweaks I guess).
>>
>> Regards,
>>
>> Robert
>>
>>
>>
>>>
>>> --
>>> Darren
>>>
>>>>
>>>> Please advise,
>>>>
>>>> Regards,
>>>>
>>>> Robert
>>>>
>>>>
>>>> ..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
>>>> only): Don't do it yet." - M.A. Jackson (not the singer)
>>>>
>>>> My public pgp key is available at:
>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>>>>
>>>>
>>>> _______________________________________________
>>>> poky mailing list
>>>> poky@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/poky
>>>
>>
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>

..."Beware of bugs in the above code; I have only proved it correct, not
tried it." - Donald Knuth, in a memo to Peter Van Emde Boas titled
"Notes on the van Emde Boas construction of priority deques: An
instructive use of recursion"

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: Third party toolchain, kernel, bootloader

[Robert Berger]

Hi Darren,

> On 05/06/2011 08:09 PM, Darren Hart wrote:
>>
>>
>> On 05/05/2011 11:28 PM, Robert Berger wrote:
>>> Hi,
>>>
>>> I'm working on a couple of projects trying to use yocto and it boils
>>> down to the fact, that the packages and the package management (with a
>>> few tweaks) are very valuable.
>>>
>>> On the other hand "just to give it a try" it's a major effort to add
>>> kernel and bootloader to poky and moreover the gcc which comes with poky
>>> is not always what I need in terms of stability but also features (need
>>> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
>>> vendor provided kernel and bootloader.
>>
>>
>> We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
>> specific feature? Hitting a particular bug?

It looks like I'm hitting a compiler/configuration bug.

1) I build everything for the beagle.
2) I use this kernel (vendor supplied 2.6.32):
wget -O xuk-src.tar.bz2
http://www.technexion.com/index.php/support-center/downloads/arm-cpu-modules/tam-3517/389-xuk-src-tar/download
3) I use this kernel config:
wget ftp://ftp.denx.de/pub/os-images/debian-6.0/arm/twister-kernel.config
4)
source tmp/environment-setup-armv7a-poky-linux-gnueabi
export ARCH=arm
export CROSS_COMPILE=arm-poky-linux-gnueabi-
make menuconfig
make -j2 uImage
...
*** End of Linux kernel configuration.
*** Execute 'make' to build the kernel or try 'make help'.

scripts/kconfig/conf -s arch/arm/Kconfig
  CHK     include/linux/version.h
  SYMLINK include/asm -> include/asm-arm
make[1]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
<stdin>:1523:2: warning: #warning syscall recvmmsg not implemented
  CHK     include/linux/compile.h
  CC      arch/arm/kernel/sysfs_v7.o
/tmp/ccFfYvGD.s: Assembler messages:
/tmp/ccFfYvGD.s:264: Error: selected processor does not support ARM mode
`smc #0'
/tmp/ccFfYvGD.s:306: Error: selected processor does not support ARM mode
`smc #0'
make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
make: *** [arch/arm/kernel] Error 2
make: *** Waiting for unfinished jobs....


That's not very elegant, but I get it to compile like this:

/*
#ifdef CONFIG_ARCH_OMAP34XX
...
*/
#define aux_ctl_store NULL
#define AUX_WR 0
/*
#ifdef CONFIG_ARCH_OMAP34XX
...
*/
#define l2_aux_ctl_store NULL
#define L2AUX_WR 0


Regards,

Robert
...Under a government which imprisons any unjustly, the true place for a
just man is also a prison. -- Henry David Thoreau

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: Third party toolchain, kernel, bootloader

[Koen Kooi]

Op 9 mei 2011, om 19:39 heeft Robert Berger het volgende geschreven:

> Hi Darren,
> 
>> On 05/06/2011 08:09 PM, Darren Hart wrote:
>>> 
>>> 
>>> On 05/05/2011 11:28 PM, Robert Berger wrote:
>>>> Hi,
>>>> 
>>>> I'm working on a couple of projects trying to use yocto and it boils
>>>> down to the fact, that the packages and the package management (with a
>>>> few tweaks) are very valuable.
>>>> 
>>>> On the other hand "just to give it a try" it's a major effort to add
>>>> kernel and bootloader to poky and moreover the gcc which comes with poky
>>>> is not always what I need in terms of stability but also features (need
>>>> e.g. Cortex-A8 support). So I would also need to cook gcc to compile a
>>>> vendor provided kernel and bootloader.
>>> 
>>> 
>>> We build for Beagleboard xM, which is a Cortex-A8. Are you missing a
>>> specific feature? Hitting a particular bug?
> 
> It looks like I'm hitting a compiler/configuration bug.
> 
> 1) I build everything for the beagle.
> 2) I use this kernel (vendor supplied 2.6.32):
> wget -O xuk-src.tar.bz2
> http://www.technexion.com/index.php/support-center/downloads/arm-cpu-modules/tam-3517/389-xuk-src-tar/download
> 3) I use this kernel config:
> wget ftp://ftp.denx.de/pub/os-images/debian-6.0/arm/twister-kernel.config
> 4)
> source tmp/environment-setup-armv7a-poky-linux-gnueabi
> export ARCH=arm
> export CROSS_COMPILE=arm-poky-linux-gnueabi-
> make menuconfig
> make -j2 uImage
> ...
> *** End of Linux kernel configuration.
> *** Execute 'make' to build the kernel or try 'make help'.
> 
> scripts/kconfig/conf -s arch/arm/Kconfig
>  CHK     include/linux/version.h
>  SYMLINK include/asm -> include/asm-arm
> make[1]: `include/asm-arm/mach-types.h' is up to date.
>  CHK     include/linux/utsrelease.h
>  CALL    scripts/checksyscalls.sh
> <stdin>:1523:2: warning: #warning syscall recvmmsg not implemented
>  CHK     include/linux/compile.h
>  CC      arch/arm/kernel/sysfs_v7.o
> /tmp/ccFfYvGD.s: Assembler messages:
> /tmp/ccFfYvGD.s:264: Error: selected processor does not support ARM mode
> `smc #0'
> /tmp/ccFfYvGD.s:306: Error: selected processor does not support ARM mode
> `smc #0'
> make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
> make: *** [arch/arm/kernel] Error 2
> make: *** Waiting for unfinished jobs....

That's a 'feature' of binutils 2.21, either switch to 2.20 or do something like http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=579d8efb3eb25b114de2640d98a511893d2f4841

Re: Third party toolchain, kernel, bootloader

[Robert Berger]

Hi Koen,

On 05/09/2011 08:57 PM, Koen Kooi wrote:
>>  CC      arch/arm/kernel/sysfs_v7.o
>> /tmp/ccFfYvGD.s: Assembler messages:
>> /tmp/ccFfYvGD.s:264: Error: selected processor does not support ARM mode
>> `smc #0'
>> /tmp/ccFfYvGD.s:306: Error: selected processor does not support ARM mode
>> `smc #0'
>> make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
>> make: *** [arch/arm/kernel] Error 2
>> make: *** Waiting for unfinished jobs....
> 
> That's a 'feature' of binutils 2.21, either switch to 2.20 or do something like http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=579d8efb3eb25b114de2640d98a511893d2f4841

I tried something like this in /arch/arm/kernel/Makefile:

plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_sysfs_v7.o :=-Wa,-march=armv7-a$(plus_sec)

... but it's not being picked up.

With V=1 I can not see what's passed to the assembler, only the compiler.

Regards,

Robert


..."What I look forward to is continued immaturity followed by death." -
Dave Barry

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: Third party toolchain, kernel, bootloader

[Darren Hart]

On 05/09/2011 01:21 PM, Robert Berger wrote:
> Hi Koen,
> 
> On 05/09/2011 08:57 PM, Koen Kooi wrote:
>>>  CC      arch/arm/kernel/sysfs_v7.o
>>> /tmp/ccFfYvGD.s: Assembler messages:
>>> /tmp/ccFfYvGD.s:264: Error: selected processor does not support ARM mode
>>> `smc #0'
>>> /tmp/ccFfYvGD.s:306: Error: selected processor does not support ARM mode
>>> `smc #0'
>>> make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
>>> make: *** [arch/arm/kernel] Error 2
>>> make: *** Waiting for unfinished jobs....
>>
>> That's a 'feature' of binutils 2.21, either switch to 2.20 or do something like http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=579d8efb3eb25b114de2640d98a511893d2f4841
> 
> I tried something like this in /arch/arm/kernel/Makefile:
> 
> plus_sec := $(call as-instr,.arch_extension sec,+sec)
> AFLAGS_sysfs_v7.o :=-Wa,-march=armv7-a$(plus_sec)
> 

I believe the fix we used was:
(commit fe297dde5ae8f8bf67d3a87759289a99b48ecb2c angstrom-linux)

$ git show 41ec30ddc42912fec133a533b924e9c56ecda8f9
commit 41ec30ddc42912fec133a533b924e9c56ecda8f9
Author: John Rigby <john.rigby@linaro.org>
Date:   Fri Jan 28 16:40:15 2011 -0800

    OMAP4: enable smc instruction in new assembler versions

    New assemblers need -march=armv7-a+sec on command line or
    .arch_extension sec inline to enable use of the smc instruction.

    This patch uses as-instr to check the latter to conditionally
    enable the former in AFLAGS for files that use smc.

    Checked on both old and new binutils to verify that it does
    not break old versions.

    Signed-off-by: John Rigby <john.rigby@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..ee9ef4f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -26,8 +26,9 @@ obj-$(CONFIG_LOCAL_TIMERS)            += timer-mpu.o
 obj-$(CONFIG_HOTPLUG_CPU)              += omap-hotplug.o
 obj-$(CONFIG_ARCH_OMAP4)               += omap44xx-smc.o omap4-common.o

-AFLAGS_omap-headsmp.o                  :=-Wa,-march=armv7-a
-AFLAGS_omap44xx-smc.o                  :=-Wa,-march=armv7-a
+plus_sec := $(call as-instr,.arch_extension sec,+sec)
+AFLAGS_omap-headsmp.o                  :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_omap44xx-smc.o                  :=-Wa,-march=armv7-a$(plus_sec)

 # Functions loaded to SRAM
 obj-$(CONFIG_ARCH_OMAP2420)            += sram242x.o



> ... but it's not being picked up.
> 
> With V=1 I can not see what's passed to the assembler, only the compiler.
> 
> Regards,
> 
> Robert
> 
> 
> ..."What I look forward to is continued immaturity followed by death." -
> Dave Barry
> 
> My public pgp key is available at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
> 
> 
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel