| Message ID | 1367570270-2242-1-git-send-email-mjonker@synopsys.com |
|---|---|
| State | Superseded |
| Headers | show |
On 03/05/13 10:37, Mischa Jonker wrote: > This patch eliminates the long "depends on" lines in > toolchain/gcc/Config.in by letting architectures specify > from which GCC version the architecture is supported. > > Architectures that support only one specific version of GCC > should bypass the GCC version selection mechanism. > > Signed-off-by: Mischa Jonker<mjonker@synopsys.com> > --- > arch/Config.in.arm | 6 ++++ > arch/Config.in.powerpc | 7 ++++ > arch/Config.in.x86 | 1 + > toolchain/gcc/Config.in | 73 +++++++++++++++++++++++++++++++++------------- > 4 files changed, 66 insertions(+), 21 deletions(-) Now this looks good! If the 'depends on' statements had been split up into one line per architecture, the - would have been bigger than the +! So this gets my Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> I'm not very excited about the sparcleon situation. But perhaps that architecture can be deprecated? It's not even in our autobuilders AFAIK. Regards, Arnout
Dear Arnout Vandecappelle, On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote: > I'm not very excited about the sparcleon situation. But perhaps that > architecture can be deprecated? It's not even in our autobuilders AFAIK. I think we had one guy interested in the SPARC Leon support. I remember proposing to remove SPARC support entirely, and one person stepped up to say that he was using SPARC Leon stuff. See http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html. I don't think Sam ever sent any patch related to SPARC support. However, Konrad Eisele sent a bunch of SPARC related patches. However, the last SPARC-related patches Konrad has sent have been sent on November 2010. He later sent some other patches (November 2011), but they were kconfig related, and were extensions to the kconfig language, something we're not ready to accept if they are not part of the upstream kconfig code in the Linux kernel. I've added Sam and Konrad in Cc to see if they are still using SPARC support, and whether it's worth adding a sparc sample to our autobuilders. Best regards, Thomas
Hi, On Fri, May 3, 2013 at 6:31 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 03/05/13 10:37, Mischa Jonker wrote: >> >> This patch eliminates the long "depends on" lines in >> toolchain/gcc/Config.in by letting architectures specify >> from which GCC version the architecture is supported. >> >> Architectures that support only one specific version of GCC >> should bypass the GCC version selection mechanism. >> >> Signed-off-by: Mischa Jonker<mjonker@synopsys.com> >> --- >> arch/Config.in.arm | 6 ++++ >> arch/Config.in.powerpc | 7 ++++ >> arch/Config.in.x86 | 1 + >> toolchain/gcc/Config.in | 73 >> +++++++++++++++++++++++++++++++++------------- >> 4 files changed, 66 insertions(+), 21 deletions(-) > > > Now this looks good! If the 'depends on' statements had been split up into > one line per architecture, the - would have been bigger than the +! So this > gets my > > Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > > This patch has been lying around for a while. It will need to be updated a bit because e.g. the gcc package has moved, but other than that are there reasons not to include it? Best regards, Thomas
Hi Sam, Konrad, On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Arnout Vandecappelle, > > On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote: > >> I'm not very excited about the sparcleon situation. But perhaps that >> architecture can be deprecated? It's not even in our autobuilders AFAIK. > > I think we had one guy interested in the SPARC Leon support. I remember > proposing to remove SPARC support entirely, and one person stepped up > to say that he was using SPARC Leon stuff. See > http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html. > > I don't think Sam ever sent any patch related to SPARC support. > > However, Konrad Eisele sent a bunch of SPARC related patches. However, > the last SPARC-related patches Konrad has sent have been sent on > November 2010. He later sent some other patches (November 2011), but > they were kconfig related, and were extensions to the kconfig language, > something we're not ready to accept if they are not part of the > upstream kconfig code in the Linux kernel. > > I've added Sam and Konrad in Cc to see if they are still using SPARC > support, and whether it's worth adding a sparc sample to our > autobuilders. I'm reviving this older thread. Are any of you still interested in SPARC support in buildroot (see above) ? Thanks, Thomas
On 2013-08-06 22:39, Sam Ravnborg wrote: > On Wed, Jul 31, 2013 at 08:53:15AM +0200, Thomas De Schampheleire wrote: >> Hi Sam, Konrad, >> >> On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com> wrote: >>> Dear Arnout Vandecappelle, >>> >>> On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote: >>> >>>> I'm not very excited about the sparcleon situation. But perhaps that >>>> architecture can be deprecated? It's not even in our autobuilders AFAIK. >>> >>> I think we had one guy interested in the SPARC Leon support. I remember >>> proposing to remove SPARC support entirely, and one person stepped up >>> to say that he was using SPARC Leon stuff. See >>> http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html. >>> >>> I don't think Sam ever sent any patch related to SPARC support. >>> >>> However, Konrad Eisele sent a bunch of SPARC related patches. However, >>> the last SPARC-related patches Konrad has sent have been sent on >>> November 2010. He later sent some other patches (November 2011), but >>> they were kconfig related, and were extensions to the kconfig language, >>> something we're not ready to accept if they are not part of the >>> upstream kconfig code in the Linux kernel. >>> >>> I've added Sam and Konrad in Cc to see if they are still using SPARC >>> support, and whether it's worth adding a sparc sample to our >>> autobuilders. >> >> I'm reviving this older thread. >> Are any of you still interested in SPARC support in buildroot (see above) ? > > My SPARC usage is very basic. I use a toolchain build using crosstoll-ng. > I added very basic SPARC support to crosstool-ng for this same purpose. > > And then I have used buildroot to create a minimal rootfs that contains > busybox and almost nothing else. > I use this rootfs to check that the kernel can boot into user-space. > And so far alll effort from my side has been on the kernel side of things, > and for that I have used the same rotfs for more than a year. > > Recently (the last year os so) I have had limited spare time for kernel/sparc > activities - so even on the kernel side not much activity has been seen. > > So I cannot say that I can be considered a SPARC user of buildroot, > considering the limited effort I can put in these days. > So I would hate it - but you cannot justify keeping SPRC support just > because I am hanging around. > > I have added a few more gaisler people - maybe they can say more about > their potential use of buildroot. Hi! We, Aeroflex Gaisler, and customers of ours are actively using buildrot. Our Linux build environment for Leon SPARC systems that we ship to customers are using buildroot. Furthermore, we also have customers that are using buildroot out of the box outside our build environment. So dropping SPARC support for buildroot would be a very bad thing. Thanks Sam for cc:ing some more Aeroflex Gaisler people. Best Regards, Andreas Larsson
On 2013-08-06 22:39, Sam Ravnborg wrote: > On Wed, Jul 31, 2013 at 08:53:15AM +0200, Thomas De Schampheleire wrote: >> Hi Sam, Konrad, >> >> On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com> wrote: >>> Dear Arnout Vandecappelle, >>> >>> On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote: >>> >>>> I'm not very excited about the sparcleon situation. But perhaps that >>>> architecture can be deprecated? It's not even in our autobuilders AFAIK. >>> >>> I think we had one guy interested in the SPARC Leon support. I remember >>> proposing to remove SPARC support entirely, and one person stepped up >>> to say that he was using SPARC Leon stuff. See >>> http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html. >>> >>> I don't think Sam ever sent any patch related to SPARC support. >>> >>> However, Konrad Eisele sent a bunch of SPARC related patches. However, >>> the last SPARC-related patches Konrad has sent have been sent on >>> November 2010. He later sent some other patches (November 2011), but >>> they were kconfig related, and were extensions to the kconfig language, >>> something we're not ready to accept if they are not part of the >>> upstream kconfig code in the Linux kernel. >>> >>> I've added Sam and Konrad in Cc to see if they are still using SPARC >>> support, and whether it's worth adding a sparc sample to our >>> autobuilders. >> >> I'm reviving this older thread. >> Are any of you still interested in SPARC support in buildroot (see above) ? > > My SPARC usage is very basic. I use a toolchain build using crosstoll-ng. > I added very basic SPARC support to crosstool-ng for this same purpose. > > And then I have used buildroot to create a minimal rootfs that contains > busybox and almost nothing else. > I use this rootfs to check that the kernel can boot into user-space. > And so far alll effort from my side has been on the kernel side of things, > and for that I have used the same rotfs for more than a year. > > Recently (the last year os so) I have had limited spare time for kernel/sparc > activities - so even on the kernel side not much activity has been seen. > > So I cannot say that I can be considered a SPARC user of buildroot, > considering the limited effort I can put in these days. > So I would hate it - but you cannot justify keeping SPRC support just > because I am hanging around. > > I have added a few more gaisler people - maybe they can say more about > their potential use of buildroot. [Resending, as my first answer got stuck in moderation queue due to too many people in cc] Hi! We, Aeroflex Gaisler, and customers of ours are actively using buildrot. Our Linux build environment for Leon SPARC systems that we ship to customers are using buildroot. Furthermore, we also have customers that are using buildroot out of the box outside our build environment. So dropping SPARC support for buildroot would be a very bad thing. Thanks Sam for cc:ing some more Aeroflex Gaisler people. Best Regards, Andreas Larsson
diff --git a/arch/Config.in.arm b/arch/Config.in.arm index 2f4c0c8..fd6671d 100644 --- a/arch/Config.in.arm +++ b/arch/Config.in.arm @@ -36,19 +36,25 @@ config BR2_arm1176jzf_s config BR2_cortex_a5 bool "cortex-A5" select BR2_ARM_CPU_MAYBE_HAS_NEON + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_cortex_a8 bool "cortex-A8" select BR2_ARM_CPU_HAS_NEON + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_cortex_a9 bool "cortex-A9" select BR2_ARM_CPU_MAYBE_HAS_NEON + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_cortex_a15 bool "cortex-A15" select BR2_ARM_CPU_HAS_NEON + select BR2_ARCH_HAS_GCC_4_6_PLUS config BR2_fa526 bool "fa526/626" + select BR2_ARCH_HAS_GCC_4_6_PLUS config BR2_pj4 bool "pj4" + select BR2_ARCH_HAS_GCC_4_8_PLUS config BR2_strongarm bool "strongarm sa110/sa1100" config BR2_xscale diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc index 8643efc..cd87b7c 100644 --- a/arch/Config.in.powerpc +++ b/arch/Config.in.powerpc @@ -20,12 +20,16 @@ config BR2_powerpc_440fp bool "440 with FPU" config BR2_powerpc_464 bool "464" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_464fp bool "464 with FPU" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_476 bool "476" + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_powerpc_476fp bool "476 with FPU" + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_powerpc_505 bool "505" config BR2_powerpc_601 @@ -66,10 +70,13 @@ config BR2_powerpc_8548 bool "8548 / e500v2" config BR2_powerpc_e300c2 bool "e300c2" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_e300c3 bool "e300c3" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_e500mc bool "e500mc" + select BR2_ARCH_HAS_GCC_4_4_PLUS endchoice choice diff --git a/arch/Config.in.x86 b/arch/Config.in.x86 index ce30605..a7255b6 100644 --- a/arch/Config.in.x86 +++ b/arch/Config.in.x86 @@ -86,6 +86,7 @@ config BR2_x86_atom select BR2_X86_CPU_HAS_SSE2 select BR2_X86_CPU_HAS_SSE3 select BR2_X86_CPU_HAS_SSSE3 + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_x86_k6 bool "k6" select BR2_X86_CPU_HAS_MMX diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in index f297e73..8d7e2e9 100644 --- a/toolchain/gcc/Config.in +++ b/toolchain/gcc/Config.in @@ -2,56 +2,83 @@ comment "GCC Options" +config BR2_ARCH_HAS_ALL_GCC + bool + default y if !(BR2_ARCH_HAS_GCC_4_4_PLUS || \ + BR2_ARCH_HAS_GCC_4_5_PLUS || \ + BR2_ARCH_HAS_GCC_4_6_PLUS || \ + BR2_ARCH_HAS_GCC_4_7_PLUS || \ + BR2_ARCH_HAS_GCC_4_8_PLUS || \ + BR2_ARCH_HAS_GCC_SNAP_ONLY) + +config BR2_ARCH_HAS_GCC_4_4_PLUS + bool + select BR2_ARCH_HAS_GCC_4_5_PLUS + +config BR2_ARCH_HAS_GCC_4_5_PLUS + bool + select BR2_ARCH_HAS_GCC_4_6_PLUS + +config BR2_ARCH_HAS_GCC_4_6_PLUS + bool + select BR2_ARCH_HAS_GCC_4_7_PLUS + +config BR2_ARCH_HAS_GCC_4_7_PLUS + bool + select BR2_ARCH_HAS_GCC_4_8_PLUS + +config BR2_ARCH_HAS_GCC_4_8_PLUS + bool + select BR2_ARCH_HAS_GCC_SNAP_ONLY + +config BR2_ARCH_HAS_GCC_SNAP_ONLY + bool + config BR2_GCC_NEEDS_MPC bool choice prompt "GCC compiler Version" - default BR2_GCC_VERSION_4_4_X if BR2_sparc_sparchfleon || BR2_sparc_sparchfleonv8 || BR2_sparc_sparcsfleon || BR2_sparc_sparcsfleonv8 - default BR2_GCC_VERSION_4_2_2_AVR32_2_1_5 if BR2_avr32 - default BR2_GCC_VERSION_4_4_7_ARC if BR2_arc + depends on !(BR2_arc || \ + BR2_avr32 || \ + BR2_sparc_sparchfleon || \ + BR2_sparc_sparchfleonv8 || \ + BR2_sparc_sparcsfleon || \ + BR2_sparc_sparcsfleonv8) default BR2_GCC_VERSION_4_7_X help Select the version of gcc you wish to use. - config BR2_GCC_VERSION_4_4_7_ARC - depends on BR2_arc - bool "gcc 4.4.7-arc" - - config BR2_GCC_VERSION_4_2_2_AVR32_2_1_5 - depends on BR2_avr32 - bool "gcc 4.2.2-avr32-2.1.5" - config BR2_GCC_VERSION_4_3_X - depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_cortex_a5 && !BR2_cortex_a8 && !BR2_cortex_a9 && !BR2_cortex_a15 && !BR2_x86_atom && !BR2_powerpc_e300c2 && !BR2_powerpc_e300c3 && !BR2_powerpc_e500mc && !BR2_powerpc_464 && !BR2_powerpc_464fp && !BR2_powerpc_476 && !BR2_powerpc_476fp && !BR2_fa526 && !BR2_pj4 + depends on BR2_ARCH_HAS_ALL_GCC bool "gcc 4.3.x" config BR2_GCC_VERSION_4_4_X - depends on !BR2_arc && !BR2_avr32 && !BR2_cortex_a5 && !BR2_cortex_a15 && !BR2_x86_atom && !BR2_powerpc_476 && !BR2_powerpc_476fp && !BR2_fa526 && !BR2_pj4 + depends on BR2_ARCH_HAS_GCC_4_4_PLUS || BR2_ARCH_HAS_ALL_GCC bool "gcc 4.4.x" config BR2_GCC_VERSION_4_5_X - depends on !BR2_arc && !BR2_avr32 && !BR2_cortex_a15 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_fa526 && !BR2_pj4 + depends on BR2_ARCH_HAS_GCC_4_5_PLUS || BR2_ARCH_HAS_ALL_GCC select BR2_GCC_NEEDS_MPC bool "gcc 4.5.x" config BR2_GCC_VERSION_4_6_X - depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_pj4 + depends on BR2_ARCH_HAS_GCC_4_6_PLUS || BR2_ARCH_HAS_ALL_GCC select BR2_GCC_NEEDS_MPC bool "gcc 4.6.x" config BR2_GCC_VERSION_4_7_X - depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_pj4 + depends on BR2_ARCH_HAS_GCC_4_7_PLUS || BR2_ARCH_HAS_ALL_GCC select BR2_GCC_NEEDS_MPC bool "gcc 4.7.x" config BR2_GCC_VERSION_4_8_X - depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 + depends on BR2_ARCH_HAS_GCC_4_8_PLUS || BR2_ARCH_HAS_ALL_GCC select BR2_GCC_NEEDS_MPC bool "gcc 4.8.x" config BR2_GCC_VERSION_SNAP - depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 + depends on BR2_ARCH_HAS_GCC_SNAP_ONLY || BR2_ARCH_HAS_ALL_GCC select BR2_GCC_NEEDS_MPC bool "gcc snapshot" endchoice @@ -76,10 +103,14 @@ config BR2_GCC_SNAP_DATE config BR2_GCC_VERSION string - default "4.2.2-avr32-2.1.5" if BR2_GCC_VERSION_4_2_2_AVR32_2_1_5 + default "4.2.2-avr32-2.1.5" if BR2_avr32 default "4.3.6" if BR2_GCC_VERSION_4_3_X - default "4.4.7" if BR2_GCC_VERSION_4_4_X - default "4.4.7-arc" if BR2_GCC_VERSION_4_4_7_ARC + default "4.4.7" if (BR2_GCC_VERSION_4_4_X || \ + BR2_sparc_sparchfleon || \ + BR2_sparc_sparchfleonv8 || \ + BR2_sparc_sparcsfleon || \ + BR2_sparc_sparcsfleonv8) + default "4.4.7-arc" if BR2_arc default "4.5.4" if BR2_GCC_VERSION_4_5_X default "4.6.4" if BR2_GCC_VERSION_4_6_X default "4.7.3" if BR2_GCC_VERSION_4_7_X
This patch eliminates the long "depends on" lines in toolchain/gcc/Config.in by letting architectures specify from which GCC version the architecture is supported. Architectures that support only one specific version of GCC should bypass the GCC version selection mechanism. Signed-off-by: Mischa Jonker <mjonker@synopsys.com> --- arch/Config.in.arm | 6 ++++ arch/Config.in.powerpc | 7 ++++ arch/Config.in.x86 | 1 + toolchain/gcc/Config.in | 73 +++++++++++++++++++++++++++++++++------------- 4 files changed, 66 insertions(+), 21 deletions(-)