Re: [RFC PATCH] add sparc support to CT-NG

[Sam Ravnborg <sam at ravnborg dot org>]

On Thu, Dec 30, 2010 at 12:07:56AM +0100, Yann E. MORIN wrote:
> Sam, Konrad, All,
> 
> On Wednesday 29 December 2010 21:59:34 Sam Ravnborg wrote:
> > I needed to build a new set of sparc toolchains.
> > So I took a look at adding sparc support to crosstool-ng.
> > As I have very limited experience in building toolchains
> > my initial attemts failed but I ended up with the
> > following simple patch.
> 
> Yeah! Thanks!
> 
> Anyway, you'll have to SoB your patch, please (I guess you do know
> what a SoB line is! ;-) )
Yup - I will add it when I have a patch-set which I consider ready.

> > Testing so far is only that I can partially build a kernel
> > with both toolchains - they are still building...
> > I will test the sparc kernel later (the 32 bit version).
> 
> OK, I'll wait for your results, then.
Testing so far shows:
gcc 4.4.1 - kernel boots
gcc 4.4.4 - kernel halts in the boot process
gcc 4.5.1 - cannot build a kernel (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)

I will test 4.4.5 and 4.5.2 (saw that Bryan just added 4.5.2).

I have no good way to test userland atm - so no status there.
Need to setup my system so rootfs is via NFS first.

I assume patch can be accepted without userland status.

Do crosstool-ng support some way to mark certain gcc versons as broken?
For leon (a sparc v8 variant) we will need this too as leon is only supported
by a limited set of gcc versions.
I do not expect a 1:1 between working versions and versions which support leon.

> > diff -r 8bcae97e8fd5 config/arch/sparc.in
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/config/arch/sparc.in	Wed Dec 29 21:49:45 2010 +0100
> > @@ -0,0 +1,12 @@
> > +# MIPS specific config options
> > +
> > +config ARCH_sparc
> > +    select ARCH_SUPPORTS_32
> > +    select ARCH_SUPPORTS_64
> > +    select ARCH_DEFAULT_32
> > +    select ARCH_USE_MMU
> > +    select ARCH_SUPPORT_CPU
>               ^^^^^^^^^^^^^^^^
> [Note 1, used below]
> 
> Also, man gcc says that sparc also supports -mtune, so:
>     select ARCH_SUPPORT_TUNE
> 
> > +    help
> > +      The SUN SPARC architecture, as defined by:
> > +        32 bit: http://www.sparc.org/standards/V8.pdf
> > +        64 bit: http://www.sparc.org/standards/SPARCV9.pdf
> > diff -r 8bcae97e8fd5 config/arch/sparc.in.2
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/config/arch/sparc.in.2	Wed Dec 29 21:49:45 2010 +0100
> > @@ -0,0 +1,33 @@
> > +# SPARC specific configuration file
> > +
> > +choice
> > +    bool
> > +    prompt "SPARC Architecture"
> > +
> > +config ARCH_SPARC_V7
> > +    bool
> > +    depends on ARCH_32
> > +    prompt "V7"
> > +    help
> > +      cypress
> > +
> > +config ARCH_SPARC_V8
> > +    bool
> > +    depends on ARCH_32
> > +    prompt "V8"
> > +    help
> > +      supersparc, hypersparc
> > +
> > +config ARCH_SPARC_V9
> > +    bool
> > +    depends on ARCH_64
> > +    prompt "V9"
> > +    help
> > +      ultrasparc, ultrasparc3, niagara, niagara2
> > +
> > +endchoice
> > +
> > +config ARCH_CPU
> > +    default "v7"   if ARCH_SPARC_V7
> > +    default "v8"   if ARCH_SPARC_V8
> > +    default "v9"   if ARCH_SPARC_V9
> 
> Here you 'force' ARCH_CPU, and at the same time [see 1, above], you allow
> the user to set his/her own value.
> 
> And because ARCH_CPU can be set by the user, it gets out of sync with the
> choice menu, just above. For example, the user may want to enter any of
> the 'supported implementations' instead of the generic architecture level,
> such as: cypress (for v7), supersparc or hypersparc (for v8), ultrasparc,
> ultrasparc3, niagara, or niagara2 (for v9), but also may want to use another
> architecture level, eg. sparclite or sparclet, or any of their 4 variants.
> 
> So, I would suggest that the choice menu gets removed, and ARCH_CPU does not
> get any defaults (anyway, if ARCH_CPU is empty, gcc will default to v7, so
> there is a default). That is, remove the sparc.in.2 file altogether.
I have dropped sparc.in.2 as suggested for now - and added ARCH_SUPPORT_TUNE.
Thanks for the insight in how crosstool works. Good stuff to konw.

	Sam

--
For unsubscribe information see http://sourceware.org/lists.html#faq