Re: questions on the cross-compiler

Re: questions on the cross-compiler

[Lisa.Hsu]

With the help from Kevin Kissell,  I've found out that  the compilation
directives "set .mips3[4]" were turned on before cpu_probe() and cpu_probe
() functions in my head.S file.  This is the reason why I've got that wrong
code generated although I've specified mip1 in the gcc options.

I 've temporarily used #define to add "set .mips1" in the code to fix the
problem.   My question now,  is: how can we make the kernel code flexible
to free from the problem of the one that I've got?

Thanks,

Lisa



                                                                                                                   
                    "Kevin D.                                                                                      
                    Kissell"             To:     <Lisa.Hsu@taec.toshiba.com>                                       
                    <kevink@mips.        cc:                                                                       
                    com>                 Subject:     Re: questions on the cross-compiler                          
                                                                                                                   
                    01/05/01                                                                                       
                    11:14 AM                                                                                       
                                                                                                                   
                                                                                                                   




> Thanks so much for replying my email.   From the specs file, I did see
> -U__mips64 which means it was undefined.

But undefining the symbol __mips64 is not really the same
thing as setting the internal compiler state to generate mips1,
mips2, or whatever.  In assembler code, one can generally
control this with something like ".set mips1"  or "set .mips1"
(I forget the semantics), but I didn't think that the code generator
or assembler paid any attention to __mips64 or any other
compile-time symbol.

> We have another reference board uses the same processor but is running in
> little-endian.  I've checked the gcc -v output on it and compare with
mine.
> The options are the same but it correctly generated "addiu" instruction
> instead of the wrong "daddiu" instruction.   I've tried to configure to
> little-endian and re-compiled.  The result of the "la" instruction still
> the same.  So the tool chain is not the problem.

At some level, there is an option being fed to the tool
chain in one environment that is not being supplied in
the other.  The behavior you are seeing is completely
correct behavior for 64-bit code generation, but 64-bit
is not normally the default.  *Something* is turning it on,
either in the gcc specs, a makefile or make-include file,
or in the source code itself.  It's not out of the question,
by the way, that your source code is really doing this
to you.  Is there a "mips3" or "mips4" string anywhere
in the head.S file, or in anything it includes?  It may be
that there's some set of conditional compilation directives
such that a .mips3 directive is being turned on by mistake
for your particular platform.  It wouldn't be the first time I
came across Linux kernel code that was allegedly for MIPS
in general, but which was in fact specific to R4000-and-above
CPUs.

> The gcc -v listed out all the options as shown in my original email under
> #3.  Do you know what else I can check?

Well, you can eliminate the specs file and compiler defaults
as suspects if you just generate a file containing just the "la"
instruction  and run "gcc-mips -c foo.S" with no fancy flags,
includes, or make artifacts, and see what instructions it generates.

>
> Thanks and Best Regards,
>
> Lisa
>
>
>
>
>                     "Kevin D.
>                     Kissell"             To:
<Lisa.Hsu@taec.toshiba.com>
>                     <kevink@mips.        cc:
>                     com>                 Subject:     Re: questions on
the
cross-compiler
>
>                     01/04/01
>                     11:47 PM
>
>
>
>
>
>
> Hi Lisa,
>
> Sounds like someone has set the default compiler/assembler
> options in gcc to default to 64-bit ISA code generation, which
> is rather unusual.  Normally, the default should be "mips1",
> which is the lowest-common-denominator 32-bit ISA of the
> R2000/R3000.  The TX39 is more like MIPS II, in fact.  In
> general, in gcc this is controlled by a command line option:
>
> -mips1      R2000/3000/3081
> -mips2      R6000.  R39xx should be a subset
> -mips3      Basic 64-bit: R4x00
> -mips4      R5000/8000/10000/12000
> -mips32    New 32-bit ISA standard
> -mips64    New 64-bit ISA standard
> -mips16    Compressed ISA
>
> So you either need to figure out where in the gcc configuration
> this is being set to "mips3", "mips4", or "mips64" (check the
> specs file that you will find by running "gcc -v"), or you need
> to make -mips1 or -mips2 explicit in your makefile.
>
>             Regards,
>
>             Kevin K.
>
> ----- Original Message -----
> From: <Lisa.Hsu@taec.toshiba.com>
> To: <linux-mips@oss.sgi.com>
> Sent: Friday, January 05, 2001 2:44 AM
> Subject: questions on the cross-compiler
>
>
> >
> > Dear All,
> >
> > I am working on our TX39xx(32-bit MIPS) reference board .  The problem
> > occurs in the assembly code generation for "la" instruction.
> >
> > The line,  "la t3, mips_cputype" ,  generated the following two
assembly
> > codes:
> >
> >      lui          $t3,0x8019
> >      daddiu   $t3,$t3,14712    <---- my system crashed at this 64-bit
> > instruction
> >
> > I would like to know why the "daddiu" instruction is generated instead
of
> > "addiu" for MIP1 code.
> >
> > The following lists my development environment:
> > 1. Cross compiler:  binutils-mips-linux-2.8.1-1.i386 and
> > egcs-mips-linux-1.0.3a-2.i386
> > 2. Linux Kernel source:  linux-2.2.13-20000211
> > 3. The gcc command line display by specify -v option:
> >
> > gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
> > /usr/lib/gcc-lib/mips-linux/egcs-2.90.29/cpp -lang-asm -v
> > -I/work/adhawk/linux-2.2.13-20000211/include -undef -$ -D__ELF__
> -D__PIC__
> > -D__pic__ -Dunix -Dmips -DR3000 -DMIPSEB -Dlinux -D__ELF__ -D__PIC__
> > -D__pic__ -D__unix__ -D__mips__ -D__R3000__ -D__MIPSEB__ -D__linux__
> > -D__unix -D__mips -D__R3000 -D__MIPSEB -D__linux -Asystem(linux)
> > -Asystem(posix) -Acpu(mips) -Amachine(mips) -D__ASSEMBLER__
> -D__OPTIMIZE__
> > -Wall -Wstrict-prototypes -D__LANGUAGE_ASSEMBLY -D_LANGUAGE_ASSEMBLY
> > -DLANGUAGE_ASSEMBLY -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int
> > -D_MIPS_FPSET=16 -D_MIPS_ISA=_MIPS_ISA_MIPS1 -D_MIPS_SIM
=_MIPS_SIM_ABI32
> > -D_MIPS_SZINT=32 -D__SIZE_TYPE__=unsigned int -D__SSIZE_TYPE__=int
> > -D__PTRDIFF_TYPE__=int -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32
> -D_MIPS_SZLONG=3
> 2
> > -D_MIPS_SZPTR=32 -U__mips64 -U__PIC__ -U__pic__ -D__KERNEL__ -DADHAWK
> > head.S
> >
> > I am quite new to the Linux world.  There are definitely something that
I
> > did not setup properly.  If anyone know the reason, your help is highly
> > appreciated.  Also, what are the latest and stable tool-chain for MIP1
> > big-endian development?
> >
> > Thanks,
> >
> > Lisa Hsu
> >
> > Multimedia Application Group
> > TAEC, Toshiba
> > 408-526-2771
> > lisa.hsu@taec.toshiba.com
> >
> >
>
>
>
>

Re: questions on the cross-compiler

[Maciej W. Rozycki]

On Fri, 5 Jan 2001 Lisa.Hsu@taec.toshiba.com wrote:

> With the help from Kevin Kissell,  I've found out that  the compilation
> directives "set .mips3[4]" were turned on before cpu_probe() and cpu_probe
> () functions in my head.S file.  This is the reason why I've got that wrong
> code generated although I've specified mip1 in the gcc options.
> 
> I 've temporarily used #define to add "set .mips1" in the code to fix the
> problem.   My question now,  is: how can we make the kernel code flexible
> to free from the problem of the one that I've got?

1. Don't use "set .mips*" unless absolutely needed.  The right ISA level
is already set via a compiler option depending on the host CPU selected
upon kernel configuration.

2. If you can't avoid "set .mips*" for some reason, then always restore
the default state after the relevant code, either by ".set mips0" or by
".set push" and ".set pop". 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: questions on the cross-compiler

[Kevin D. Kissell]

> > With the help from Kevin Kissell,  I've found out that  the compilation
> > directives "set .mips3[4]" were turned on before cpu_probe() and
cpu_probe
> > () functions in my head.S file.  This is the reason why I've got that
wrong
> > code generated although I've specified mip1 in the gcc options.
> >
> > I 've temporarily used #define to add "set .mips1" in the code to fix
the
> > problem.   My question now,  is: how can we make the kernel code
flexible
> > to free from the problem of the one that I've got?
>
> 1. Don't use "set .mips*" unless absolutely needed.  The right ISA level
> is already set via a compiler option depending on the host CPU selected
> upon kernel configuration.

Lisa's underlying problem may be that there isn't a Config
option for the R39xx CPUs, and she's ended up getting an
R4000 (or whatever) configuration by default.

At some point specific support for the R3900 features
(MIPS II ISA, seperate hardware interrupt vector, etc.)
should go into the kernel, but for the moment, you should
make sure that when you do the initial "make config"
(or xconfig or menuconfig or whatever) you select an
R3000 CPU.  You won't get it by default.  You may
also need to hack the head.S code to detect an R39xx PrID
value and replace it with an R3000  value before it gets used
by the kernel.  Otherwise, you may need to generate additional
cases/conditionals for R3900 wherever you see R3000 called
out in the existing code.  If your kernel base has my cpu_probe()
in C, adding R39xx support will be much easier, but while
I *think* I set it up such that, if the R4K_EXCEPTION_MODEL
option bit isn't set, the kernel assumes an R3K model, I never
tested that option - not having any R3xxx platforms in
the lab!

            Kevin K.

Re: questions on the cross-compiler

[Kevin D. Kissell]

> > With the help from Kevin Kissell,  I've found out that  the compilation
> > directives "set .mips3[4]" were turned on before cpu_probe() and
cpu_probe
> > () functions in my head.S file.  This is the reason why I've got that
wrong
> > code generated although I've specified mip1 in the gcc options.
> >
> > I 've temporarily used #define to add "set .mips1" in the code to fix
the
> > problem.   My question now,  is: how can we make the kernel code
flexible
> > to free from the problem of the one that I've got?
>
> 1. Don't use "set .mips*" unless absolutely needed.  The right ISA level
> is already set via a compiler option depending on the host CPU selected
> upon kernel configuration.

Lisa's underlying problem may be that there isn't a Config
option for the R39xx CPUs, and she's ended up getting an
R4000 (or whatever) configuration by default.

At some point specific support for the R3900 features
(MIPS II ISA, seperate hardware interrupt vector, etc.)
should go into the kernel, but for the moment, you should
make sure that when you do the initial "make config"
(or xconfig or menuconfig or whatever) you select an
R3000 CPU.  You won't get it by default.  You may
also need to hack the head.S code to detect an R39xx PrID
value and replace it with an R3000  value before it gets used
by the kernel.  Otherwise, you may need to generate additional
cases/conditionals for R3900 wherever you see R3000 called
out in the existing code.  If your kernel base has my cpu_probe()
in C, adding R39xx support will be much easier, but while
I *think* I set it up such that, if the R4K_EXCEPTION_MODEL
option bit isn't set, the kernel assumes an R3K model, I never
tested that option - not having any R3xxx platforms in
the lab!

            Kevin K.

Re: questions on the cross-compiler

[Maciej W. Rozycki]

On Fri, 5 Jan 2001, Kevin D. Kissell wrote:

> Lisa's underlying problem may be that there isn't a Config
> option for the R39xx CPUs, and she's ended up getting an
> R4000 (or whatever) configuration by default.

 It's easy to add right options for yet another CPU -- see
arch/mips/Makefile.  Anyway, for the mips port (as opposed to mips64)
you'll never get anything beyond "-mips2" passed to the toolchain. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: questions on the cross-compiler

[Jay Carlson]

Kevin D. Kissell writes:

> Lisa's underlying problem may be that there isn't a Config
> option for the R39xx CPUs, and she's ended up getting an
> R4000 (or whatever) configuration by default.
>
> At some point specific support for the R3900 features
> (MIPS II ISA, seperate hardware interrupt vector, etc.)
> should go into the kernel,
[...]

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/mips/r39xx/?cvsroot
=linux-vr

The TX3912 is supported by the Linux VR kernel tree.  I'm not sure it's been
tested in a while, but kernel sources from a few months ago run nice on my
VTech Helio.

Jay

RE: questions on the cross-compiler

[Jay Carlson]

Kevin D. Kissell writes:

> Lisa's underlying problem may be that there isn't a Config
> option for the R39xx CPUs, and she's ended up getting an
> R4000 (or whatever) configuration by default.
>
> At some point specific support for the R3900 features
> (MIPS II ISA, seperate hardware interrupt vector, etc.)
> should go into the kernel,
[...]

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/mips/r39xx/?cvsroot
=linux-vr

The TX3912 is supported by the Linux VR kernel tree.  I'm not sure it's been
tested in a while, but kernel sources from a few months ago run nice on my
VTech Helio.

Jay

Compiling MILO on big-emdian

[Michael Shmulevich]

Hello all,

I was compiling a milo-0.27 lately on i586 machine for mips32 platform.
I am using binutils 2.8.1 egcs1.0.3a, and glibc 2.0.6. I am using some custom
MIPS board
with QED RM5261 processor. I use patched 2.2.14 kernel which is known to compile
and run on my hardware.

./configure went smoothly, but at a build time I started to get problems. First,
I got missing <asm/pica.h>. After a short search I have found one in annals of
the Internet.

This didn't really help me, because finally I got an assembler errors for
libstand/cachectl.o:

[michaels@kobie libstand]$ make
mips-linux-gcc -Wall -O2 -mips2 -Wa,-mips3 -mcpu=r4400 -D__KERNEL__
-DLOADADDR=0x80600000 -DKERNELBASE=0x80000000 -DVERSION=0.27 -DDEBUG=1
-DBOOTMETHOD_ARC -nostdinc
-I/usr/local/lib/gcc-lib/mips-linux/egcs-2.90.29/include
-I/home/michaels/atlas/rg.mips/linux/include -I../libstand/include
-I../libarc/include -c cachectl.S -o cachectl.o
cachectl.S: Assembler messages:
cachectl.S:58: Error: absolute expression required `li'
cachectl.S:59: Warning: Instruction cache requires absolute expression
cachectl.S:60: Warning: Instruction cache requires absolute expression
cachectl.S:61: Warning: Instruction cache requires absolute expression
cachectl.S:62: Warning: Instruction cache requires absolute expression
cachectl.S:63: Warning: Instruction cache requires absolute expression
cachectl.S:64: Warning: Instruction cache requires absolute expression
cachectl.S:65: Warning: Instruction cache requires absolute expression
cachectl.S:66: Warning: Instruction cache requires absolute expression
<and many more like these>

Line 58 is
 li t1,CACHELINES-1
Line 59 is
  cache Index_Writeback_Inv_D,32(t0)

and obviously CACHELINES is not defined anywhere, not even within the kernel
source tree. At least not my patched 2.2.14. Also, I am confused what causes
cache to go crazy on Index_Writeback_Inv_D ...

So, if anyone has ideas, plase forward them on.
Also, I wonder if there is a public CVS repository for milo or any other
"authoritative" storage.

Thanks in advance,
Michael.

Re: Compiling MILO on big-emdian

[Ralf Baechle]

On Sun, Jan 07, 2001 at 05:33:10PM +0200, Michael Shmulevich wrote:

> I was compiling a milo-0.27 lately on i586 machine for mips32 platform.

The answer is easy - don't use Milo; it's not used since a loooong time
for any of the supported systems anymore.

  Ralf

Re: Compiling MILO on big-emdian

[Michael Shmulevich]

Ralf,

Thank you for reply.
I wonder if I can take the initialization routines from it to use in my
custom flash bootloader?
I do not mean "cut & paste" bu rather ideas. I need a loader that will copy
the kernel with a
ramdisk from flash to ram and start the kernel. I saw that there is
something similar in milo.

By the way, how do supported machines boot nowadays? Lilo?

Thanks,
michael.

Ralf Baechle wrote:

> On Sun, Jan 07, 2001 at 05:33:10PM +0200, Michael Shmulevich wrote:
>
> > I was compiling a milo-0.27 lately on i586 machine for mips32 platform.
>
> The answer is easy - don't use Milo; it's not used since a loooong time
> for any of the supported systems anymore.
>
>   Ralf