corsepiu at faw.uni-ulm.de
Wed Nov 29 15:53:14 UTC 2000
Patrick Kelsey wrote:
> We use two mips variants - 64-bit orion processors such as the R4700 and
> a 32-bit processor based on IDT's RC32300 (a 32-bit mips core with no fpu
> and a mutt isa: mips2 + non-64-bit mips4 + a few special insns like mad,
> msub, etc.). The orion processors are supported directly by the mips64orion
> targets in the gnu tools and in RTEMS. To support the 32300-based processor
> under RTEMS, we added minor patches to the mips64orion cpu-specific files in
> the distribution. Originally we used a hacked version of the mips64orion
> gnu tools, but we are moving to a separate gcc/binutils/newlib target that
> we have created for the 32300 to circumvent some fundamental problems with
> the former approach. So now we have two sets of tools built -
> mips64orion-rtems-gcc et. al and mips32300-rtems-gcc et. al, with their
> corresponding newlibs. The question is what is the best way to add support
> for building RTEMS with the mips32300 toolset? The idea is that I would be
> able to run either of these two commands:
> bit_rtems mips64orion some_bsp
> bit_rtems mips32300 some_other_bsp
> and the configure process would select the appropriate toolset
> (mips64orion-rtems-* or ) and the appropriate cpu-specific
> subdirs. Currently, it seems that the name of the cpu-specifc subdir has to
> be the same as the cpu name used to form the toolset prefix.
Almost, things are a little more complicated.
> Perhaps there
> should be separate ways to specify the cpu-specifc subdir name and the tool
> prefix to accomodate situations like this.
The subdirs' names are derived by configure scripts calling
config.sub with the target's canonicalization tripple passed as
argument to it.
Manually invoking config.sub:
sh ./config.sub mips32300-rtems
I.e. config.sub thinks mips32300 is part of a mips643200 cpu family
=> RTEMS configuration would search for mips643200 subdirs
> Or am I missing something?
No, you're basically right, but there is one indirection more than
you might have expected.
More information about the users