[RFC PATCH] add sparc support to CT-NG

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Wed Dec 29 23:08:00 GMT 2010


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! ;-) )

> With this I have succeeded building a sparc + sparc64 toolchain.
> I will resumit after addressing any commants.

See below, inlined.

> Note: Menuconfig ask for "Emit assembly for CPU"
> It looked worg to ask for a string - but I have not tried
> to find a way to control it.

This entry is arch-agnostic. Maintaining a list of possible options
would be a nightmare. I tried once, and it is unmaintainable. The
user is expected to know a little bit about the target CPU, so that
he/she is able to fill-in appropriate values.

> Note2: I know Konrad Eisele has done some work to add support
> for sparc to crosstool-ng too (with focus on the leon variants).
> But I failed to locate any pathces - he may have something
> that is preferred over the following set of simple patches.

Let's give him some time, so he can have a chance to comment. :-)

> 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.

> 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.

> diff -r 8bcae97e8fd5 scripts/build/arch/sparc.sh
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/scripts/build/arch/sparc.sh	Wed Dec 29 21:49:45 2010 +0100
> @@ -0,0 +1,10 @@
> +# Compute sparc-specific values
> +CT_DoArchTupleValues() {
> +    # That's the only thing to override
> +    if [ "${CT_ARCH_64}" = "y" ]; then
> +        CT_TARGET_ARCH="${CT_ARCH}64"
> +    else
> +        CT_TARGET_ARCH="${CT_ARCH}"
> +    fi
> +
> +}
> 

Thank you! I'm eager to see your results booting a kernel (and userland?).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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



More information about the crossgcc mailing list