[RFC PATCH] add sparc support to CT-NG
Sam Ravnborg
sam@ravnborg.org
Thu Dec 30 19:00:00 GMT 2010
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
More information about the crossgcc
mailing list