Change -mcpu option for VR41xx

Change -mcpu option for VR41xx

[Yoichi Yuasa]

Hi Ralf,

We need to change -mcpu in order to use an instruction peculiar to VR4100.
The option of -mcpu changes with versions of binutils.

If it is limited to some versions, I can be corresponded using check_gcc.
Can you tell me some versions of binutils?

Yoichi

Re: Change -mcpu option for VR41xx

[Ralf Baechle]

On Mon, Feb 24, 2003 at 09:07:55PM +0900, Yoichi Yuasa wrote:

> We need to change -mcpu in order to use an instruction peculiar to VR4100.
> The option of -mcpu changes with versions of binutils.
> 
> If it is limited to some versions, I can be corresponded using check_gcc.
> Can you tell me some versions of binutils?

Binutils starting with about 2.10 should support -mcpu=4100.

  Ralf

Re: Change -mcpu option for VR41xx

[Yoichi Yuasa]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Hi Ralf,

On Mon, 24 Feb 2003 21:21:46 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Mon, Feb 24, 2003 at 09:07:55PM +0900, Yoichi Yuasa wrote:
> 
> > We need to change -mcpu in order to use an instruction peculiar to VR4100.
> > The option of -mcpu changes with versions of binutils.
> > 
> > If it is limited to some versions, I can be corresponded using check_gcc.
> > Can you tell me some versions of binutils?
> 
> Binutils starting with about 2.10 should support -mcpu=4100.

I checked about some binutils.

binutils -mcpu option for VR4100 series

2.10:
        * VR4100
        * vr4100
        * 4100
        * mips64vr4100
        * r4100

2.11:
2.12:
2.13:
        * VR4100
        * 4100
        * mips64vr4100
        * r4100

In addition for the VR4100 series, there is an -m4100 option.

As for us, it is best to use the following option.

GCCFLAGS        += -mcpu=r4100 -mips2 -Wa,-m4100,--trap

Would you apply this patch to CVS?

Thanks,

Yoichi

[-- Attachment #2: vr41xx-makefile-v24.diff --]
[-- Type: text/plain, Size: 474 bytes --]

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile
--- linux.orig/arch/mips/Makefile	Fri Feb 21 03:53:37 2003
+++ linux/arch/mips/Makefile	Tue Feb 25 12:27:57 2003
@@ -66,7 +66,7 @@
 GCCFLAGS	+= -mcpu=r4300 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_VR41XX
-GCCFLAGS	+= -mcpu=r4600 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r4100 -mips2 -Wa,-m4100,--trap
 endif
 ifdef CONFIG_CPU_R4X00
 GCCFLAGS	+= -mcpu=r4600 -mips2 -Wa,--trap

[-- Attachment #3: vr41xx-makefile-v25.diff --]
[-- Type: text/plain, Size: 721 bytes --]

diff -aruN --exclude=CVS --exclude=.cvsignore linux.orig/arch/mips/Makefile linux/arch/mips/Makefile
--- linux.orig/arch/mips/Makefile	Fri Jan 24 10:26:58 2003
+++ linux/arch/mips/Makefile	Tue Feb 25 12:40:23 2003
@@ -57,7 +57,7 @@
 cflags-$(CONFIG_CPU_TX39XX)	+= -mcpu=r3000 -mips1
 cflags-$(CONFIG_CPU_R6000)	+= -mcpu=r6000 -mips2 -Wa,--trap
 cflags-$(CONFIG_CPU_R4300)	+= -mcpu=r4300 -mips2 -Wa,--trap
-cflags-$(CONFIG_CPU_VR41XX)	+= -mcpu=r4600 -mips2 -Wa,--trap
+cflags-$(CONFIG_CPU_VR41XX)	+= -mcpu=r4100 -mips2 -Wa,-m4100,--trap
 cflags-$(CONFIG_CPU_R4X00)	+= -mcpu=r4600 -mips2 -Wa,--trap
 cflags-$(CONFIG_CPU_TX49XX)	+= -mcpu=r4600 -mips2 -Wa,--trap
 cflags-$(CONFIG_CPU_MIPS32)	+= -mcpu=r4600 -mips2 -Wa,--trap

Kernel 2.4.20

[jeff]

Dear All,
    I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx
So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
to test this kernel when the kernel entry is 0x801xxxxx?

Thanks for everyone's help

Jeff @ Coventive

Kernel 2.4.20

[jeff]

Dear All,
    I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx
So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
to test this kernel when the kernel entry is 0x801xxxxx?

Thanks for everyone's help

Jeff @ Coventive

Re: Kernel 2.4.20

[Thiemo Seufer]

jeff wrote:
> Dear All,
>     I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
> In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx

That's just normal, the entry is variable.

> So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
> to test this kernel when the kernel entry is 0x801xxxxx?

The entry address is encoded in the ELF header at the beginning of vmlinux
(as it is for all other ELF executables). The header's layout can be found
e.g. in linux/include/linux/elf.h.


Thiemo

RE: Kernel 2.4.20

[jeff]

Dear Thiemo,
    Thanks for your quickly response.
I try to modify the /arch/mips/ld.script.in or /arch/mips/kernel/head.S
but still can't work (entry is changed but kernel can't work). Do I make
any mistake?

Thanks

Jeff @ Coventive

-----Original Message-----
From: Thiemo Seufer [mailto:ica2_ts@csv.ica.uni-stuttgart.de]
Sent: Tuesday, February 25, 2003 4:03 PM
To: jeff
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.20


jeff wrote:
> Dear All,
>     I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
> In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx

That's just normal, the entry is variable.

> So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
> to test this kernel when the kernel entry is 0x801xxxxx?

The entry address is encoded in the ELF header at the beginning of vmlinux
(as it is for all other ELF executables). The header's layout can be found
e.g. in linux/include/linux/elf.h.


Thiemo

RE: Kernel 2.4.20

[jeff]

Dear Thiemo,
    Thanks for your quickly response.
I try to modify the /arch/mips/ld.script.in or /arch/mips/kernel/head.S
but still can't work (entry is changed but kernel can't work). Do I make
any mistake?

Thanks

Jeff @ Coventive

-----Original Message-----
From: Thiemo Seufer [mailto:ica2_ts@csv.ica.uni-stuttgart.de]
Sent: Tuesday, February 25, 2003 4:03 PM
To: jeff
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.20


jeff wrote:
> Dear All,
>     I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
> In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx

That's just normal, the entry is variable.

> So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
> to test this kernel when the kernel entry is 0x801xxxxx?

The entry address is encoded in the ELF header at the beginning of vmlinux
(as it is for all other ELF executables). The header's layout can be found
e.g. in linux/include/linux/elf.h.


Thiemo

Re: Kernel 2.4.20

[Thiemo Seufer]

jeff wrote:
> Dear Thiemo,
>     Thanks for your quickly response.
> I try to modify the /arch/mips/ld.script.in or /arch/mips/kernel/head.S

This won't help. The entry address is where the linker happens to
place the entry function. It may vary even for slight differences
in Kernel compilation.

> but still can't work (entry is changed but kernel can't work).

What does "can't work" mean? What happens exactly?

What sort of bootloader are you using? Normally it is able to
handle ELF properly, which makes this thing work automatically.

> Do I make any mistake?

Sounds so.


Thiemo

RE: Kernel 2.4.20

[jeff]

Dear Thiemo,
    We modified the head.S and the kernel_entry change to 0x80000798
(check from System.map) and we download this kernel to RAM address
0x80000000 and jump to 0x8000798 to execute. It show EXCEPTION...
And our bootloader will not handle ELF file format. But after build the kernel
image, we got two image, vmlinux and vmlinux.binary. vmlinux is FLE file
format and vmlinux.binary is only data (check by file). We download 
vmlinux.binary to test.

Regards,

Jeff

-----Original Message-----
From: Thiemo Seufer [mailto:ica2_ts@csv.ica.uni-stuttgart.de]
Sent: Tuesday, February 25, 2003 4:33 PM
To: jeff
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.20


jeff wrote:
> Dear Thiemo,
>     Thanks for your quickly response.
> I try to modify the /arch/mips/ld.script.in or /arch/mips/kernel/head.S

This won't help. The entry address is where the linker happens to
place the entry function. It may vary even for slight differences
in Kernel compilation.

> but still can't work (entry is changed but kernel can't work).

What does "can't work" mean? What happens exactly?

What sort of bootloader are you using? Normally it is able to
handle ELF properly, which makes this thing work automatically.

> Do I make any mistake?

Sounds so.


Thiemo

RE: Kernel 2.4.20

[jeff]

Dear Thiemo,
    We modified the head.S and the kernel_entry change to 0x80000798
(check from System.map) and we download this kernel to RAM address
0x80000000 and jump to 0x8000798 to execute. It show EXCEPTION...
And our bootloader will not handle ELF file format. But after build the kernel
image, we got two image, vmlinux and vmlinux.binary. vmlinux is FLE file
format and vmlinux.binary is only data (check by file). We download 
vmlinux.binary to test.

Regards,

Jeff

-----Original Message-----
From: Thiemo Seufer [mailto:ica2_ts@csv.ica.uni-stuttgart.de]
Sent: Tuesday, February 25, 2003 4:33 PM
To: jeff
Cc: linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.20


jeff wrote:
> Dear Thiemo,
>     Thanks for your quickly response.
> I try to modify the /arch/mips/ld.script.in or /arch/mips/kernel/head.S

This won't help. The entry address is where the linker happens to
place the entry function. It may vary even for slight differences
in Kernel compilation.

> but still can't work (entry is changed but kernel can't work).

What does "can't work" mean? What happens exactly?

What sort of bootloader are you using? Normally it is able to
handle ELF properly, which makes this thing work automatically.

> Do I make any mistake?

Sounds so.


Thiemo

Re: Kernel 2.4.20

[Thiemo Seufer]

jeff wrote:
> Dear Thiemo,
>     We modified the head.S and the kernel_entry change to 0x80000798
> (check from System.map) and we download this kernel to RAM address
> 0x80000000 and jump to 0x8000798 to execute.

By adding a pre_kernel_entry() there, I guess.

> It show EXCEPTION...
> And our bootloader will not handle ELF file format. But after build the kernel
> image, we got two image, vmlinux and vmlinux.binary. vmlinux is FLE file
> format and vmlinux.binary is only data (check by file). We download 
> vmlinux.binary to test.

One more guess: The conversion to binary lost some important section.


Thiemo

Re: Kernel 2.4.20

[Jun Sun]

On Tue, Feb 25, 2003 at 03:58:51PM +0800, jeff wrote:
> Dear All,
>     I am trying to porting NEC Vr4131 platform from 2.4.16 to 2.4.20 but I found some problem.
> In kernel 2.4.16, the kernel entry is 0x80002470 but the kernel entry in 2.4.20 is 0x801xxxxx
> So my problem is how to change the kernel entry from 0x801xxxxx to be 0x8000xxxx? or how 
> to test this kernel when the kernel entry is 0x801xxxxx?
>

Change LOADADDR to 0x80002000 in arch/mips/Makefile.  If you
want to learn more about it, see 

http://linux.junsun.net/porting-howto/porting-howto.html#chapter-directory

Jun
 

Re: Change -mcpu option for VR41xx

[Maciej W. Rozycki]

On Tue, 25 Feb 2003, Yoichi Yuasa wrote:

> binutils -mcpu option for VR4100 series
> 
> 2.10:
>         * VR4100
>         * vr4100
>         * 4100
>         * mips64vr4100
>         * r4100
> 
> 2.11:
> 2.12:
> 2.13:
>         * VR4100
>         * 4100
>         * mips64vr4100
>         * r4100

 They are case insensitive, which is why the redundancy was removed.

> In addition for the VR4100 series, there is an -m4100 option.

 Which is deprecated and scheduled for removal in the future.

> As for us, it is best to use the following option.
> 
> GCCFLAGS        += -mcpu=r4100 -mips2 -Wa,-m4100,--trap
> 
> Would you apply this patch to CVS?

 The trunk version of gas only supports "-m4100" and "vr4100" (but leading
letters are dropped if no exact match happens) for "-mcpu=" (which is also
deprecated), "-march=" and "-mtune=".  Additionally it supports "vr4111",
"vr4111", "vr4120", "vr4130" and "vr4181".  I suggest you go for: 

GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,--trap

for now as other options may trigger an error depending on the version of
tools used ("-mcpu=" is passed down to gas).

 I think we'll soon have to cook up a run-time gcc check for what is
accepted and use the "-march=" and "-mtune=" options preferably and
failing that, revert to legacy options like above.

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

Re: Change -mcpu option for VR41xx

[Yoichi Yuasa]

On Tue, 25 Feb 2003 14:18:38 +0100 (MET)
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On Tue, 25 Feb 2003, Yoichi Yuasa wrote:
> 
> > binutils -mcpu option for VR4100 series
> > 
> > 2.10:
> >         * VR4100
> >         * vr4100
> >         * 4100
> >         * mips64vr4100
> >         * r4100
> > 
> > 2.11:
> > 2.12:
> > 2.13:
> >         * VR4100
> >         * 4100
> >         * mips64vr4100
> >         * r4100
> 
>  They are case insensitive, which is why the redundancy was removed.
> 
> > In addition for the VR4100 series, there is an -m4100 option.
> 
>  Which is deprecated and scheduled for removal in the future.
> 
> > As for us, it is best to use the following option.
> > 
> > GCCFLAGS        += -mcpu=r4100 -mips2 -Wa,-m4100,--trap
> > 
> > Would you apply this patch to CVS?
> 
>  The trunk version of gas only supports "-m4100" and "vr4100" (but leading
> letters are dropped if no exact match happens) for "-mcpu=" (which is also
> deprecated), "-march=" and "-mtune=".  Additionally it supports "vr4111",
> "vr4111", "vr4120", "vr4130" and "vr4181".  I suggest you go for: 
> 
> GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,--trap
> 
> for now as other options may trigger an error depending on the version of
> tools used ("-mcpu=" is passed down to gas).

With the following versions.
I cannot compile with an instruction peculiar to VR4100, if there is no -m4100.

GNU ld version 2.12.90.0.1 20020307
GNU ld version 2.12.1

We need to add -m4100 option.

GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,-m4100,--trap

>  I think we'll soon have to cook up a run-time gcc check for what is
> accepted and use the "-march=" and "-mtune=" options preferably and
> failing that, revert to legacy options like above.

Thanks,

Yoichi

Re: Change -mcpu option for VR41xx

[Maciej W. Rozycki]

On Wed, 26 Feb 2003, Yoichi Yuasa wrote:

> >  The trunk version of gas only supports "-m4100" and "vr4100" (but leading
> > letters are dropped if no exact match happens) for "-mcpu=" (which is also
> > deprecated), "-march=" and "-mtune=".  Additionally it supports "vr4111",
> > "vr4111", "vr4120", "vr4130" and "vr4181".  I suggest you go for: 
> > 
> > GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,--trap
> > 
> > for now as other options may trigger an error depending on the version of
> > tools used ("-mcpu=" is passed down to gas).
> 
> With the following versions.
> I cannot compile with an instruction peculiar to VR4100, if there is no -m4100.
> 
> GNU ld version 2.12.90.0.1 20020307
> GNU ld version 2.12.1
> 
> We need to add -m4100 option.
> 
> GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,-m4100,--trap

 Strange, what does `gcc -v -mcpu=vr4100 -mips2 -Wa,--trap -xassembler -c
/dev/null -o /dev/null' say to you? 

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

Re: Change -mcpu option for VR41xx

[Yoichi Yuasa]

On Wed, 26 Feb 2003 13:18:40 +0100 (MET)
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On Wed, 26 Feb 2003, Yoichi Yuasa wrote:
> 
> > >  The trunk version of gas only supports "-m4100" and "vr4100" (but leading
> > > letters are dropped if no exact match happens) for "-mcpu=" (which is also
> > > deprecated), "-march=" and "-mtune=".  Additionally it supports "vr4111",
> > > "vr4111", "vr4120", "vr4130" and "vr4181".  I suggest you go for: 
> > > 
> > > GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,--trap
> > > 
> > > for now as other options may trigger an error depending on the version of
> > > tools used ("-mcpu=" is passed down to gas).
> > 
> > With the following versions.
> > I cannot compile with an instruction peculiar to VR4100, if there is no -m4100.
> > 
> > GNU ld version 2.12.90.0.1 20020307
> > GNU ld version 2.12.1
> > 
> > We need to add -m4100 option.
> > 
> > GCCFLAGS	+= -mcpu=vr4100 -mips2 -Wa,-m4100,--trap
> 
>  Strange, what does `gcc -v -mcpu=vr4100 -mips2 -Wa,--trap -xassembler -c
> /dev/null -o /dev/null' say to you? 

$ mipsel-linux-gcc -v -mcpu=vr4100 -mips2 -Wa,--trap -xassembler -c /dev/null -o /dev/null
Reading specs from /usr/local/lib/gcc-lib/mipsel-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
 /usr/local/mipsel-linux/bin/as -EL -mips2 -mcpu=vr4100 -v -KPIC --trap -o /dev/null /dev/null
GNU assembler version 2.12.90.0.1 (mipsel-linux) using BFD version 2.12.90.0.1 20020307 Debian/GNU Linux

Yoichi

Re: Change -mcpu option for VR41xx

[Maciej W. Rozycki]

On Thu, 27 Feb 2003, Yoichi Yuasa wrote:

> $ mipsel-linux-gcc -v -mcpu=vr4100 -mips2 -Wa,--trap -xassembler -c /dev/null -o /dev/null
> Reading specs from /usr/local/lib/gcc-lib/mipsel-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
>  /usr/local/mipsel-linux/bin/as -EL -mips2 -mcpu=vr4100 -v -KPIC --trap -o /dev/null /dev/null
> GNU assembler version 2.12.90.0.1 (mipsel-linux) using BFD version 2.12.90.0.1 20020307 Debian/GNU Linux

 Ah, I see how it happens now -- "-mipsN" has a higher priority than
"-mcpu=" (but lower than "-march=") so in this case "-mips2" overrides
"-mcpu=vr4100".  How about:

GCCFLAGS	+= -mcpu=vr4100 -Wa,--trap

then?

 Ralf, it seems the "-mcpu=XXXX -mipsN" settings are contradicting and
XXXX is ignored (I don't see it as my gcc translates "-mcpu=XXXX" into
"-march=XXXX -mtune=XXXX" as a step towards transiting to 3.x).  I think
the following settings would be more reasonable:

GCCFLAGS	+= -mabi=32 -mcpu=XXXX	# for the 32-bit kernel

GCCFLAGS	+= -mabi=n64 -mcpu=XXXX	# for the 64-bit kernel

(additional processor-specific flags skipped).  Is that supported by the
oldest version of binutils you want to support?

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

Re: Change -mcpu option for VR41xx

[Yoichi Yuasa]

Hi,

On Thu, 27 Feb 2003 13:05:02 +0100 (MET)
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On Thu, 27 Feb 2003, Yoichi Yuasa wrote:
> 
> > $ mipsel-linux-gcc -v -mcpu=vr4100 -mips2 -Wa,--trap -xassembler -c /dev/null -o /dev/null
> > Reading specs from /usr/local/lib/gcc-lib/mipsel-linux/2.95.4/specs
> > gcc version 2.95.4 20011002 (Debian prerelease)
> >  /usr/local/mipsel-linux/bin/as -EL -mips2 -mcpu=vr4100 -v -KPIC --trap -o /dev/null /dev/null
> > GNU assembler version 2.12.90.0.1 (mipsel-linux) using BFD version 2.12.90.0.1 20020307 Debian/GNU Linux
> 
>  Ah, I see how it happens now -- "-mipsN" has a higher priority than
> "-mcpu=" (but lower than "-march=") so in this case "-mips2" overrides
> "-mcpu=vr4100".  How about:
> 
> GCCFLAGS	+= -mcpu=vr4100 -Wa,--trap
> 
> then?

That is fine.
However, the following warning is displayed.

Warning: The -mcpu option is deprecated.  Please use -march and -mtune instead.

>  Ralf, it seems the "-mcpu=XXXX -mipsN" settings are contradicting and
> XXXX is ignored (I don't see it as my gcc translates "-mcpu=XXXX" into
> "-march=XXXX -mtune=XXXX" as a step towards transiting to 3.x).  I think
> the following settings would be more reasonable:
> 
> GCCFLAGS	+= -mabi=32 -mcpu=XXXX	# for the 32-bit kernel
> 
> GCCFLAGS	+= -mabi=n64 -mcpu=XXXX	# for the 64-bit kernel
> 
> (additional processor-specific flags skipped).  Is that supported by the
> oldest version of binutils you want to support?

Thanks,

Yoichi

Re: Change -mcpu option for VR41xx

[Maciej W. Rozycki]

On Thu, 27 Feb 2003, Yoichi Yuasa wrote:

> >  Ah, I see how it happens now -- "-mipsN" has a higher priority than
> > "-mcpu=" (but lower than "-march=") so in this case "-mips2" overrides
> > "-mcpu=vr4100".  How about:
> > 
> > GCCFLAGS	+= -mcpu=vr4100 -Wa,--trap
> > 
> > then?
> 
> That is fine.
> However, the following warning is displayed.
> 
> Warning: The -mcpu option is deprecated.  Please use -march and -mtune instead.

 Does is disappear with "-m4100"?  That would be strange.  And "-mcpu=" is
indeed deprecated, but it works for most versions and "-march=" and
"-mtune=" are too new to be used by everyone.  But as I wrote, we will end
with a test for these options eventually as "-mcpu=" is already removed
from the trunk.  As a result the warning will disappear.

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

Re: Change -mcpu option for VR41xx

[Yoichi Yuasa]

On Thu, 27 Feb 2003 14:07:21 +0100 (MET)
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On Thu, 27 Feb 2003, Yoichi Yuasa wrote:
> 
> > >  Ah, I see how it happens now -- "-mipsN" has a higher priority than
> > > "-mcpu=" (but lower than "-march=") so in this case "-mips2" overrides
> > > "-mcpu=vr4100".  How about:
> > > 
> > > GCCFLAGS	+= -mcpu=vr4100 -Wa,--trap
> > > 
> > > then?
> > 
> > That is fine.
> > However, the following warning is displayed.
> > 
> > Warning: The -mcpu option is deprecated.  Please use -march and -mtune instead.
> 
>  Does is disappear with "-m4100"?

Yes it does.

>  That would be strange.  And "-mcpu=" is
> indeed deprecated, but it works for most versions and "-march=" and
> "-mtune=" are too new to be used by everyone.  But as I wrote, we will end
> with a test for these options eventually as "-mcpu=" is already removed
> from the trunk.  As a result the warning will disappear.

binutils-2.12.90.0.1/gas/config/tc-mips.c has a following part.

  if (mips_arch == CPU_UNKNOWN && mips_cpu != CPU_UNKNOWN)
    {
      ci = mips_cpu_info_from_cpu (mips_cpu);
      assert (ci != NULL);
      mips_arch = ci->cpu;
      as_warn (_("The -mcpu option is deprecated.  Please use -march and "
                 "-mtune instead."));
    }

When I set up following GCCFLAGS,

GCCFLAGS	+= -mcpu=vr4100 -Wa,--trap

the mips_arch is CPU_UNKNOWN and the mips_cpu is CPU_VR4100.
The gas print out warnning.

Yoichi

kernel 2.4.20

[Gurpreet Singh (SCM)]

Hi 

I need to study / install  the RSBAC - ACL model.

The Kernel package I downloaded  is   linux-2.4.20-rsbac-v1.2.2-pre5
I am getting the boot error / message at boot while loading the lilo.
Currently I am having 2.4.7 version Kernel.

Any inupts for the resources for it.. Has any one tried this stuff ?

Thanks in advance 

Gurpreet S 

Re: kernel 2.4.20

[Jan Knutar]

> I am getting the boot error / message at boot while loading the lilo.

It would be highly useful, if you provided more detail about what sort 
of error you are getting. Sounds to me like you made a mistake with 
setting up lilo properly for the new kernel.

Kernel 2.4.20

[David Munn]

Hi All......have been putting Slackware 9.0 onto a 2ghz h/d for use with 
packet......i set it up with all the ax25 progs....libax25...ax25 
utils...ax25 tools  etc and then configured it to use my SB16 soundcard on 
4800 bd.....
when i modprobe soundmodem i get a warning message that the driver could 
corrupt the kernel and also ...no licence....

thought this might be a problem with the Slackware distro but also have this 
Kernel loaded on my Red Hat machine...have checked this one also and found 
the same Warning message when i ...modprobe soundmodem.....

has there been a patch for this problem.....it is not in the 2.4.19 kernel 
.....will have to go back to Red Hat 7.3 to setup my packet machine if there 
isnt...

73s to you all
David Munn
VK4BDJ

RE: Kernel 2.4.20

[Jeremy Utley]

> -----Original Message-----
> From: linux-hams-owner@vger.kernel.org
> [mailto:linux-hams-owner@vger.kernel.org]On Behalf Of David Munn
>
>
>
> Hi All......have been putting Slackware 9.0 onto a 2ghz h/d
> for use with
> packet......i set it up with all the ax25 progs....libax25...ax25
> utils...ax25 tools  etc and then configured it to use my SB16
> soundcard on
> 4800 bd.....
> when i modprobe soundmodem i get a warning message that the
> driver could
> corrupt the kernel and also ...no licence....
>
> thought this might be a problem with the Slackware distro but
> also have this
> Kernel loaded on my Red Hat machine...have checked this one
> also and found
> the same Warning message when i ...modprobe soundmodem.....
>

Nothing to worry about - just some changes in the 2.4.20 kernel that
look for a flag in the kernel module to reflect what license it's
provided
under.  Because this flag is not present, modprobe throws up a warning
message - but the module should still work.

Jeremy

Re: Kernel 2.4.20

[Riley Williams]

Hi David.

 > Hi All...have been putting Slackware 9.0 onto a 2ghz h/d for use
 > with packet...I set it up with all the ax25 progs...libax25...ax25
 > utils...ax25 tools etc and then configured it to use my SB16
 > soundcard on 4800 bd...when I modprobe soundmodem I get a warning
 > message that the driver could corrupt the kernel and also ...no
 > licence....

The warning that the soundmodem driver could corrupt the kernel IS
important. This will be connected with the fact that the kernel
soundmodem driver is depreciated, and regarded as obsolete, with the
current recommendation being to use the user-mode soundmodem tool in
its place.

The warning about no licence is probably a side-effect of that driver
being regarded as obsolete, with the only future patches concerning
it likely to be ones that just strip it out of the kernel altogether.
Indeed, that happened in the 2.5 series some time ago, and there is
no soundmodem driver in the current 2.6-test series as a result. As
Jeremy has already stated, this warning is because of a requirement
that each module state the licence it is released under, and it has
no effect on the functionality of that module.

Best wishes from Riley G7GOD / KB8PPG
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18-Jul-2003

kernel 2.4.20

[gojyo]

I need to patch a 2.4.20 kernel; however, with the last release of cpufreq for 2.4 kernels I have lot of patch errors. In the ftp archive I can't understand which version I need, can you help me please? Which release do I need for 2.4.20 kernel?


_____________________________________________________________
Open a Private 6MB Email account today, for Free!
----- http://www.killamail.com -----

Re: kernel 2.4.20

[Ducrot Bruno]

On Tue, Jan 13, 2004 at 03:10:42AM -0800, gojyo wrote:
> I need to patch a 2.4.20 kernel; however, with the last release of cpufreq for 2.4 kernels I have lot of patch errors. In the ftp archive I can't understand which version I need, can you help me please? Which release do I need for 2.4.20 kernel?

You have 2 solutions:
1- integrate by hand the rejected patch,
2- use cvs with:

cvs -d:pserver:cvs@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot co -rlinux_2_4_old cpufreq

which was done before the new core for 2.4 was updated (first done for
linux-2.4.21 IIRC).

BUT this one is old and contains well known bugs that have been fixed.

If I were you, I will integrate by hand the latest (that should be not
so hard).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.