* Third party toolchain, kernel, bootloader @ 2011-05-06 6:28 Robert Berger 2011-05-06 17:09 ` Darren Hart 0 siblings, 1 reply; 9+ messages in thread From: Robert Berger @ 2011-05-06 6:28 UTC (permalink / raw) To: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-06 6:28 Third party toolchain, kernel, bootloader Robert Berger @ 2011-05-06 17:09 ` Darren Hart 2011-05-07 19:42 ` Robert Berger 0 siblings, 1 reply; 9+ messages in thread From: Darren Hart @ 2011-05-06 17:09 UTC (permalink / raw) To: gmane; +Cc: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-06 17:09 ` Darren Hart @ 2011-05-07 19:42 ` Robert Berger 2011-05-07 22:10 ` Xianghua Xiao 2011-05-09 17:39 ` Robert Berger 0 siblings, 2 replies; 9+ messages in thread From: Robert Berger @ 2011-05-07 19:42 UTC (permalink / raw) To: poky 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-07 19:42 ` Robert Berger @ 2011-05-07 22:10 ` Xianghua Xiao 2011-05-08 15:29 ` Robert Berger 2011-05-09 17:39 ` Robert Berger 1 sibling, 1 reply; 9+ messages in thread From: Xianghua Xiao @ 2011-05-07 22:10 UTC (permalink / raw) To: gmane; +Cc: poky 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-07 22:10 ` Xianghua Xiao @ 2011-05-08 15:29 ` Robert Berger 0 siblings, 0 replies; 9+ messages in thread From: Robert Berger @ 2011-05-08 15:29 UTC (permalink / raw) To: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-07 19:42 ` Robert Berger 2011-05-07 22:10 ` Xianghua Xiao @ 2011-05-09 17:39 ` Robert Berger 2011-05-09 17:57 ` Koen Kooi 1 sibling, 1 reply; 9+ messages in thread From: Robert Berger @ 2011-05-09 17:39 UTC (permalink / raw) To: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-09 17:39 ` Robert Berger @ 2011-05-09 17:57 ` Koen Kooi 2011-05-09 20:21 ` Robert Berger 0 siblings, 1 reply; 9+ messages in thread From: Koen Kooi @ 2011-05-09 17:57 UTC (permalink / raw) To: gmane; +Cc: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-09 17:57 ` Koen Kooi @ 2011-05-09 20:21 ` Robert Berger 2011-05-09 21:18 ` Darren Hart 0 siblings, 1 reply; 9+ messages in thread From: Robert Berger @ 2011-05-09 20:21 UTC (permalink / raw) To: poky 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Third party toolchain, kernel, bootloader 2011-05-09 20:21 ` Robert Berger @ 2011-05-09 21:18 ` Darren Hart 0 siblings, 0 replies; 9+ messages in thread From: Darren Hart @ 2011-05-09 21:18 UTC (permalink / raw) To: gmane; +Cc: poky 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-05-09 21:18 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-06 6:28 Third party toolchain, kernel, bootloader Robert Berger 2011-05-06 17:09 ` Darren Hart 2011-05-07 19:42 ` Robert Berger 2011-05-07 22:10 ` Xianghua Xiao 2011-05-08 15:29 ` Robert Berger 2011-05-09 17:39 ` Robert Berger 2011-05-09 17:57 ` Koen Kooi 2011-05-09 20:21 ` Robert Berger 2011-05-09 21:18 ` Darren Hart
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.