* Re: -mcpu vs. binutils 2.13.90.0.18
From: Thiemo Seufer @ 2003-03-18 19:08 UTC (permalink / raw)
To: linux-mips; +Cc: Guido Guenther
In-Reply-To: <20030318174241.GG2613@bogon.ms20.nix>
Guido Guenther wrote:
> On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> > Try
> > -mabi=o32 -march=r5000 -Wa,--trap
> > This may fail if the compiler is very old, though.
> >
> > > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> >
> > This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> > and -mips4 one for -march=r8000.
> Is it correct that -mipsX in contrast to -march=rXXXX has the difference
> of not only selecting a specific CPU instruction set but also an abi
> (o32 or n64)?
Only for old compilers, an only for some cases. :-/
-mipsX is the old method for selecting both CPU and ABI, resembling the way
SGI did it for their toolchain. Then there was the need to support different
CPUs, which led to -mcpu/-mXXXX. The result was an inconsistent mess,
especially -mips2 has multiple overloaded semantics.
> If so wouldn't it be cleaner to remove -mipsX altogether
> and use -march=rXXXX and -mabi=o32, etc?
This would be nice, but older compilers don't have -march/-mtune.
IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.
> The different meanings of these
> options in different toolchain versions confuse me a lot. What is the
> final intended usage of these options?
For usual userland the ABI defines everything needed. This means
No options at all:
Produce, hosted on a single ABI system, a userland binary with the lowest
possible ISA.
-mabi=FOO:
Produce, hosted on a multi ABI system, a userland binary with the lowest
possible ISA for the selected ABI.
Then there are optimizations for different CPUs.
-march=BAR:
Allow opcodes for CPU BAR in addition to the ISA ones.
-mtune=BAZ:
Optimize opcode scheduling for CPU BAZ.
Some embedded systems don't care much about ABI compatibility, they
use also
-mgp32/-mfp32:
Restrict register width to 32 bits on 64 bit CPUs.
Then, there are the backward compatibility options.
-mipsX:
Is an alias for -march=QUUX, where QUUX is the CPU closest to the respective
ISA. Note that this is only backward compatible for the assembler, not for
the compiler which implied some o32 features for -mips2.
-mcpu=XXX, -mYYYY:
Old CPU selection code, mostly gone now. Superseded by -march/-mtune.
For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
Makefile. I don't see a better way around it.
Thiemo
^ permalink raw reply
* Re: -mcpu vs. binutils 2.13.90.0.18
From: Guido Guenther @ 2003-03-18 17:42 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20030318160303.GN13122@rembrandt.csv.ica.uni-stuttgart.de>
On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> Try
> -mabi=o32 -march=r5000 -Wa,--trap
> This may fail if the compiler is very old, though.
>
> > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
>
> This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> and -mips4 one for -march=r8000.
Is it correct that -mipsX in contrast to -march=rXXXX has the difference
of not only selecting a specific CPU instruction set but also an abi
(o32 or n64)? If so wouldn't it be cleaner to remove -mipsX altogether
and use -march=rXXXX and -mabi=o32, etc? The different meanings of these
options in different toolchain versions confuse me a lot. What is the
final intended usage of these options?
-- Guido
^ permalink raw reply
* 2.4.20 SCSI problems on NASRaQ
From: Neurophyre @ 2003-03-18 17:24 UTC (permalink / raw)
To: linux-mips
Hello all. I'm trying to get Debian 3.0r1 working usefully on a
MIPS-based Seagate (Cobalt) NASRaQ. The system uses the same processor
as the Qube 2 and has an integrated 53c860 SCSI controller, which would
appear to be supported by no fewer than three kernel drivers!
I'm compiling the kernel source available at
ftp://ftp.linux-mips.org/pub/linux/mips/kernel/test/linux-2.4.20.tar.gz
WITH Paul Martin's tulip and PCIfun patches applied. I should mention
that the stock 2.4.20 source with the debian kernel-patch-2.4-cobalt
package applied to it presented numerous problems and I had to give up.
The problem is that upon boot (or module installation), I get similar
messages from all three SCSI drivers.
Examples:
sym.0.8.0: IO region 0x10102000[0..127] is in use
or
ncr53c8xx: IO region 0x10102000[0..127] is in use
On boot, the boot process just goes on, but no 'scsi0 blah blah'
printout occurs, and nothing is printed about a tape drive I have
attached to the machine for testing.
When installing as a module (only tested with sym53c8xx driver) the
module installation fails and a message like above is printed to the
serial console.
Doing a 'cat /proc/scsi/scsi' yields
Attached devices: none
no matter what.
Does anyone have any suggestions? We'd really like to modernize the
NASRaQ and still be able to use its SCSI port.
^ permalink raw reply
* Re: -mcpu vs. binutils 2.13.90.0.18
From: Thiemo Seufer @ 2003-03-18 16:03 UTC (permalink / raw)
To: linux-mips; +Cc: Guido Guenther
In-Reply-To: <20030318154155.GF2613@bogon.ms20.nix>
Guido Guenther wrote:
> Hi,
> it seems newer binutils doen't know about -mcpu anymore. Is it correct
> to simply change:
> -mcpu=r5000 -mips2 -Wa,--trap
> to
> -mtune=r5000 -mips2 -Wa,--trap
On newer toolchains this will select r6000 opcodes with r5000 scheduling.
Try
-mabi=o32 -march=r5000 -Wa,--trap
This may fail if the compiler is very old, though.
> for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
and -mips4 one for -march=r8000.
Thiemo
^ permalink raw reply
* -mcpu vs. binutils 2.13.90.0.18
From: Guido Guenther @ 2003-03-18 15:41 UTC (permalink / raw)
To: linux-mips
Hi,
it seems newer binutils doen't know about -mcpu anymore. Is it correct
to simply change:
-mcpu=r5000 -mips2 -Wa,--trap
to
-mtune=r5000 -mips2 -Wa,--trap
for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
Regards,
-- Guido
^ permalink raw reply
* Re: about linux porting on SGI origin 300
From: Soeren Laursen @ 2003-03-18 12:57 UTC (permalink / raw)
To: Florian Laws; +Cc: linux-mips
In-Reply-To: <20030318124653.GB724@void.s.bawue.de>
Ups,
Your are right, Oracle9i is dead on the IRIX
Regards,
Søren,
> On Tue, Mar 18, 2003 at 10:52:49AM +0100, Soeren Laursen wrote:
> > > Can I make this machine DB Server(Oracle 9i) ?
> > Yes, if you run IRIX,
>
> Oracle 9i is available for IRIX?
> Thanks for the info, i thought, Oracle stopped supporting IRIX
> with 8i.
>
> Regards,
>
> Florian
^ permalink raw reply
* Re: about linux porting on SGI origin 300
From: Soeren Laursen @ 2003-03-18 9:52 UTC (permalink / raw)
To: linux-mips; +Cc: whwang
In-Reply-To: <000001c2ed22$6c55f9c0$ef01e2cb@LocalHost>
> Can I make this machine DB Server(Oracle 9i) ?
Yes, if you run IRIX,
Regards,
Søren Laursen
^ permalink raw reply
* Patch to make Db1500 Audio codec recognized
From: Hartvig Ekner @ 2003-03-18 8:17 UTC (permalink / raw)
To: Linux MIPS mailing list
[-- Attachment #1: Type: text/plain, Size: 83 bytes --]
A small patch to make the AMD Db1500 Audio codec correctly recognized.
/Hartvig
[-- Attachment #2: ac97_patch --]
[-- Type: text/plain, Size: 728 bytes --]
Index: ac97_codec.c
===================================================================
RCS file: /home/cvs/linux/drivers/sound/Attic/ac97_codec.c,v
retrieving revision 1.18.2.4
diff -u -r1.18.2.4 ac97_codec.c
--- ac97_codec.c 25 Feb 2003 22:03:09 -0000 1.18.2.4
+++ ac97_codec.c 18 Mar 2003 08:10:53 -0000
@@ -153,6 +153,7 @@
{0x83847608, "SigmaTel STAC9708", &sigmatel_9708_ops},
{0x83847609, "SigmaTel STAC9721/23", &sigmatel_9721_ops},
{0x83847644, "SigmaTel STAC9744/45", &sigmatel_9744_ops},
+ {0x83847652, "SigmaTel STAC9752/53", &default_ops},
{0x83847656, "SigmaTel STAC9756/57", &sigmatel_9744_ops},
{0x83847666, "SigmaTel STAC9750T", &sigmatel_9744_ops},
{0x83847684, "SigmaTel STAC9783/84?", &null_ops},
^ permalink raw reply
* about linux porting on SGI origin 300
From: 황재욱 @ 2003-03-18 7:46 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
I hoe your business prospers.
I have some question about linux-mips.
I have SGI origin 300 (4cpu, 2.5GB mem, FC-AL), but I want to install
Linux on this machine.
Is it possible?
Can I make this machine DB Server(Oracle 9i) ?
Please let me know,,,
Best Regards,,,,
Jaewook hwang
Daelim information & Service CO.
[-- Attachment #2: Type: text/html, Size: 7541 bytes --]
^ permalink raw reply
* about linux porting on SGI origin 300
From: 황재욱 @ 2003-03-18 7:46 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
I hoe your business prospers.
I have some question about linux-mips.
I have SGI origin 300 (4cpu, 2.5GB mem, FC-AL), but I want to install
Linux on this machine.
Is it possible?
Can I make this machine DB Server(Oracle 9i) ?
Please let me know,,,
Best Regards,,,,
Jaewook hwang
Daelim information & Service CO.
[-- Attachment #2: Type: text/html, Size: 7541 bytes --]
^ permalink raw reply
* Re: kernel compilation error on indy with r4600
From: Zhang Fuxin @ 2003-03-16 19:22 UTC (permalink / raw)
To: Arthur Petitpierre; +Cc: linux-mips
In-Reply-To: <20030316011613.766aa81d.arthur.petitpierre@gadz.org>
Arthur Petitpierre wrote:
> Hi,
>
>I've got an Indy whith a r46000 cpu and a Debian installed on it, and when I try to compile a new kernel (with gcc-2.95),
>I do 'make menuconfig', 'make dep' without any problem and when I try 'make vmlinux', I got error as following :
>
>gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.19/include -Wall -Wstrict-prototypes -Wno-trigraphs
>
^^^^^^Are you sure you are using mips gcc? If you are cross-compiling,it
should normally be mips(el)-linux-gcc here
>-O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/src/kernel-source-2.4.19/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
>as: unrecognized option `-mcpu=r4600'
>init/main.c: In function `calibrate_delay':
>init/main.c:199: Internal compiler error:
>init/main.c:199: output pipe has been closed
>make: *** [init/main.o] Error 1
>
>Any solution to fix it. Thanks,
> Arthur
>
>
>
>
>
^ permalink raw reply
* kernel compilation error on indy with r4600
From: Arthur Petitpierre @ 2003-03-16 0:16 UTC (permalink / raw)
To: linux-mips
Hi,
I've got an Indy whith a r46000 cpu and a Debian installed on it, and when I try to compile a new kernel (with gcc-2.95),
I do 'make menuconfig', 'make dep' without any problem and when I try 'make vmlinux', I got error as following :
gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.19/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /usr/src/kernel-source-2.4.19/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
as: unrecognized option `-mcpu=r4600'
init/main.c: In function `calibrate_delay':
init/main.c:199: Internal compiler error:
init/main.c:199: output pipe has been closed
make: *** [init/main.o] Error 1
Any solution to fix it. Thanks,
Arthur
^ permalink raw reply
* RE: Tips on inspecting / debuging cache
From: Adam Kiepul @ 2003-03-14 23:23 UTC (permalink / raw)
To: 'Wayne Gowcher', linux-mips
Hi Wayne,
Enclosed please find routines that I developed for PMC-Sierra RM52x1 and RM7000 processors.
Enjoy!
Adam
# Cache Dump - will dump the cache contents from I or D cache.
# Arguments:
# a0 is 0 for I Cache or 1 for D Cache
# a1 is the pointer to the Tag/States Array. Size is Cache Size / 4. There are 2 words per line.
# a2 is the pointer to the Data Array (size equal to the Cache size, MUST be Set Size aligned)
# Note: For user's convenience the pointers can be in KSeg1 or KSeg0.
#
# The TagHi/TagLo registers are stored in an array pointed to by the 2nd argument.
#
# TagHi_Address(Set, Index) = a1 + Set*(SET_SIZE/4) + 8*Index
# TagLo_Address(Set, Index) = a1 + Set*(SET_SIZE/4) + 8*Index + 4
#
# In case of RM52x1 Caches are 32KB total, 2-way set-associative so SET_SIZE is 16KB.
# With 32B line size there are 16KB/32B = 512 lines per Set.
# Thus:
#
# TagHi_Address(Set, Index) = a1 + Set*4096 + 8*Index
# TagLo_Address(Set, Index) = a1 + Set*4096 + 8*Index + 4
#
# Where Set is 0..1 and Index is 0..511.
#
# Cache Data fields are stored in an array pointed to by the 3rd argument.
#
# Line_Data_Address(Set, Index) = a2 + Set*SET_SIZE + Index*32
#
# In case of RM52x1 it is:
#
# Line_Data_Address(Set, Index) = a2 + Set*16384 + Index*32
#
# Note: The Original Physical Address of a cache line has to be calculated based on Tag and Index.
#
# In case of RM52x1 the Physical Address of the cache line is calculated as follows:
#
# PA = ((TagLo & 0xffffff00) << 4) | ((Index*32) & 0x00000fff)
#
# Note: The PA and Data Field are only valid if the line is marked Valid in the TagLo.
# This means that the State field (TagLo[7:6]) must be 3 for D Cache or 2 for I Cache.
#define C0_TAGLO $28
#define C0_TAGHI $29
#define Index_Load_Tag_I 4
#define Index_Load_Tag_D 5
#define Index_Store_Tag_I 8
#define Index_Store_Tag_D 9
#define Hit_Writeback_I 24
#define Hit_Writeback_D 25
#define Create_Dirty_Exclusive_D 13
#define ICACHE_VALID 2
#define DCACHE_VALID 3
# Now: 1 is for RM52x1 and 0 is for RM7000
#define RM52x1 1
#if RM52x1
#define CACHE_SIZE 0x00008000
#else
#define CACHE_SIZE 0x00004000
#endif
.text
.set noreorder
.set noat
.globl cachedmp
.ent cachedmp
.align 5
cachedmp:
# Switch to K1 (optional for D Cache dumping)
la t0, 1f
li t1, 0x20000000
or t0, t1
jr t0
nop
1:
# Read and Modify the Tags/States
li t0, 0x80000000 # base address for Index cache ops in t0
li t1, 0x80000000+CACHE_SIZE-32 # end address in t1
li at, 0x20000000
or t2, a1, at # convert a1 to a K1 address and put to t2
or a2, at
xor a2, at # make sure pointer in a2 is a K0 address
or t3, a2, zero # copy a2 to t3
L1: bne a0, zero, 1f
nop
cache Index_Load_Tag_I, (t0)
b 2f
nop
1: cache Index_Load_Tag_D, (t0)
2: nop ; nop ; nop ; nop
mfc0 t4, C0_TAGHI
mfc0 t5, C0_TAGLO
sw t4, 0(t2) # preserve the original Tags/States
sw t5, 4(t2)
li t7, 0x1ffff000 # mask for PA[28:12]
and t7, t3 # mask bits of the pointer in t3
srl t7, 4 # t7 is now a Tag for the pointer
#if RM52x1
li t6, 0x0000003f
and t6, t5 # mask off the PTagLo and PState
or t6, t7 # "paste" the Tag value to t6
#else
mtc0 t7, C0_TAGHI # in RM7k the Tag is in TAGHI
li t6, 0xfff0003f
and t6, t5 # mask off the PState
#endif
bne a0, zero, 1f # now set the PState field as valid
nop
b 2f
ori t6, ICACHE_VALID<<6
1: ori t6, DCACHE_VALID<<6
2: mtc0 t6, C0_TAGLO # write the new value to TAGLO
nop ; nop ; nop ; nop
bne a0, zero, 1f
nop
cache Index_Store_Tag_I, (t0) # write back to the cache line states
b 2f
nop
1: cache Index_Store_Tag_D, (t0)
2: addiu t2, 8
addiu t3, 32
bne t0, t1, L1
addiu t0, 32
# For D Cache need to touch the lines in order to set the W bits (make them Dirty)
# We can not use Create_Dirty_Exclusive because it would clear the data fields.
# Therefore we read and store back a word in every line.
beq a0, zero, 1f # Skip for I Cache
nop
or t0, a2, zero
li t1, CACHE_SIZE-32
addu t1, t0
L2: lw t2, (t0)
sw t2, (t0)
bne t0, t1, L2
addiu t0, 32
1:
# Now Write Back the cache contents
or t0, a2, zero
li t1, CACHE_SIZE-32
addu t1, t0
L3: bne a0, zero, 1f
nop
cache Hit_Writeback_I, (t0)
b 2f
nop
1: cache Hit_Writeback_D, (t0)
2: bne t0, t1, L3
addiu t0, 32
jr ra
nop
.end cachedmp
##############################
/* Now: 1 is for RM52x1 and 0 is for RM7000 */
#define RM52x1 1
#if RM52x1
#define CACHE_SIZE 0x00008000
#define SET 2
#else
#define CACHE_SIZE 0x00004000
#define SET 4
#endif
#define SET_SIZE (CACHE_SIZE/SET)
#define INDEX SET_SIZE/32
#define Tag_Array_1 0xa0208000
#define Data_Array_1 0xa0200000
#define Tag_Array_2 0xa0218000
#define Data_Array_2 0xa0210000
unsigned char serial_buffer[250];
CacheDisplay(unsigned long TagsAddr, unsigned long DataAddr)
{ int Set, Index, i;
unsigned long TAGHI, TAGLO, PA, State, Word, *CurrentTags, *CurrentWord;
CurrentTags=(unsigned long *)TagsAddr;
#if RM52x1
CurrentWord=(unsigned long *)DataAddr;
#else
CurrentWord=(unsigned long *)(DataAddr&0xdfffffff);
#endif
/* For RM7k we need to read the written-back data cached just in case it ends up in L2 */
for(Set=0; Set<SET; Set++)
for(Index=0; Index<INDEX; Index++)
{ sprintf(serial_buffer, "\n\rSet: %d, Index: %03d", Set, Index);
dumpstr(serial_buffer);
TAGHI=*CurrentTags++;
TAGLO=*CurrentTags++;
sprintf(serial_buffer, "\n\rTAGHI=0x%08x, TAGLO=0x%08x", TAGHI, TAGLO);
dumpstr(serial_buffer);
#if RM52x1
PA=((TAGLO & 0xffffff00) << 4) | ((Index*32) & 0x00000fff);
#else
PA=((TAGHI & 0xffffff00) << 4) | ((Index*32) & 0x00000fff);
#endif
State=(TAGLO & 0x000000c0)>>6;
sprintf(serial_buffer, "\n\rPA=0x%08x, State=0x%x, Data Words:\n\r", PA, State);
dumpstr(serial_buffer);
for(i=0; i<8; i++)
{ Word=*CurrentWord++;
sprintf(serial_buffer, "%08x ", Word);
dumpstr(serial_buffer);
}
dumpstr("\n\r");
}
}
main()
{
dumpstr("\n\rRunning the cachedmp for D Cache\n\r");
cachedmp(1, Tag_Array_1, Data_Array_1);
CacheDisplay(Tag_Array_1, Data_Array_1);
dumpstr("\n\rRunning the cachedmp for I Cache\n\r");
cachedmp(0, Tag_Array_2, Data_Array_2);
CacheDisplay(Tag_Array_2, Data_Array_2);
}
-----Original Message-----
From: Wayne Gowcher [mailto:wgowcher@yahoo.com]
Sent: Thursday, March 13, 2003 6:13 PM
To: linux-mips@linux-mips.org
Subject: Tips on inspecting / debuging cache
Dear List,
I am wondering if someone could point me towards
articles / source code that would give me a little
insight into how to debug cache problems in mips.
For example , how do I inspect the contents of the
cache ? Are there routines to dump out the contents of
the cache ?
Any help, tips , pointers would be appreciated.
TIA
Wayne
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
^ permalink raw reply
* Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Jeff Baitis @ 2003-03-14 21:57 UTC (permalink / raw)
To: Pete Popov; +Cc: Linux MIPS mailing list
In-Reply-To: <1047677667.18887.162.camel@zeus.mvista.com>
On Fri, Mar 14, 2003 at 01:34:28PM -0800, Pete Popov wrote:
> Yep, I had to do that way back then when I got the same sort of setup
> working. Good job figuring that out :)
>
> Just to confirm, this setup works with the current linux-mips.org plus
> the above info? No other patches are required, correct?
>
> I think I'll start an Alchemy/AMD FAQ or something in my directory and
> put this information there. Thanks!
The patches that I'm using:
Pete's 36bit_addr_2.4.21-pre4.patch
Pete's 64bit_pcmcia.patch
Additionally, I had to apply the patch to include/asm-mips/io.h in order
to get the hermes/orinoco drivers to compile. (I posted this patch earlier, and
someone suggested that the SLOW_DOWN_IO; call was not necessary). Find it below.
I have some other patches applied; they should not affect PCMCIA. I'll check
out clean source and patch it with this bare minimum, and let you know
if something else is required.
Thanks, Pete -- a FAQ about your patches will really help people who are
starting out on the Alchemy platform.
Regards,
Jeff
Index: io.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/io.h,v
retrieving revision 1.29.2.20
diff -u -r1.29.2.20 io.h
--- io.h 25 Feb 2003 22:03:12 -0000 1.29.2.20
+++ io.h 14 Mar 2003 21:50:14 -0000
@@ -332,12 +332,25 @@
SLOW_DOWN_IO; \
} while(0)
°
-#define outw_p(val,port) \
-do { \
- *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
- __ioswab16(val); \
- SLOW_DOWN_IO; \
-} while(0)
+/* baitisj */
+static inline u16 outw_p(u16 val, unsigned long port)
+{
+ register u16 retval;
+ do {
+ retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
+ __ioswab16(val);
+ SLOW_DOWN_IO;
+ } while(0);
+ return retval;
+}
+/*°°
+ * #define outw_p(val,port) \
+ * do { \
+ * *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
+ * __ioswab16(val); \
+ * SLOW_DOWN_IO; \
+ * } while(0)
+ */
°
#define outl_p(val,port) \
do { \
> On Fri, 2003-03-14 at 12:23, Jeff Baitis wrote:
> > Everyone:
> >
> > Thank you very much for helping this green hand get up to speed on the MIPS
> > platform. I have successfully configured card services to work with the
> > current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.
> >
> > There are a few card services options that you will need, in order to replicate
> > my work:
> >
> > 1. The pcmcia_core cis_speed needs to be set to a fairly low value.
> > I have successfully used `modprobe pcmcia_core cis_speed=10` and
> > `modprobe pcmcia_core cis_speed=1.`
> >
> > 2. The PCMCIA memory window must map into the memory window assigned
> > by the PCI device autoconfiguration. Since my `lspci -v` shows:
> >
> > 00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
> > Subsystem: Unknown device 5678:1234
> > Flags: bus master, medium devsel, latency 168, IRQ 1
> > Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> > Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
> > Memory window 0: 40001000-40002000 (prefetchable)
> > Memory window 1: 40400000-407ff000
> > I/O window 0: 00004000-000040ff
> > I/O window 1: 00004400-000044ff
> > 16-bit legacy interface ports at 0001
> >
> > I configured /etc/pcmcia/config.opts as follows:
> >
> > #
> > # Local PCMCIA Configuration File
> > #
> > #----------------------------------------------------------------------
> >
> > # System resources available for PCMCIA devices
> > # remember to modprobe pcmcia_core cis_speed=10
> >
> > include port 0x100-0x4ff, port 0xc00-0xcff
> > include memory 0x40000000-0x40ffffff
> >
> > #-------------------------- eof
>
>
> Pete
>
>
>
--
Jeffrey Baitis - Associate Software Engineer
Evolution Robotics, Inc.
130 West Union Street
Pasadena CA 91103
tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply
* Re: Tips on inspecting / debuging cache
From: Wayne Gowcher @ 2003-03-14 21:53 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20030314202609.A3670@linux-mips.org>
Ralf,
Thanks for the feedback.
I believe my problem is not due to your recent
changes. But thanks for the heads up :)
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
^ permalink raw reply
* Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Pete Popov @ 2003-03-14 21:34 UTC (permalink / raw)
To: baitisj; +Cc: Linux MIPS mailing list
In-Reply-To: <20030314122352.F20129@luca.pas.lab>
On Fri, 2003-03-14 at 12:23, Jeff Baitis wrote:
> Everyone:
>
> Thank you very much for helping this green hand get up to speed on the MIPS
> platform. I have successfully configured card services to work with the
> current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.
>
> There are a few card services options that you will need, in order to replicate
> my work:
>
> 1. The pcmcia_core cis_speed needs to be set to a fairly low value.
> I have successfully used `modprobe pcmcia_core cis_speed=10` and
> `modprobe pcmcia_core cis_speed=1.`
>
> 2. The PCMCIA memory window must map into the memory window assigned
> by the PCI device autoconfiguration. Since my `lspci -v` shows:
>
> 00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
> Subsystem: Unknown device 5678:1234
> Flags: bus master, medium devsel, latency 168, IRQ 1
> Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
> Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
> Memory window 0: 40001000-40002000 (prefetchable)
> Memory window 1: 40400000-407ff000
> I/O window 0: 00004000-000040ff
> I/O window 1: 00004400-000044ff
> 16-bit legacy interface ports at 0001
>
> I configured /etc/pcmcia/config.opts as follows:
>
> #
> # Local PCMCIA Configuration File
> #
> #----------------------------------------------------------------------
>
> # System resources available for PCMCIA devices
> # remember to modprobe pcmcia_core cis_speed=10
>
> include port 0x100-0x4ff, port 0xc00-0xcff
> include memory 0x40000000-0x40ffffff
>
> #-------------------------- eof
Yep, I had to do that way back then when I got the same sort of setup
working. Good job figuring that out :)
Just to confirm, this setup works with the current linux-mips.org plus
the above info? No other patches are required, correct?
I think I'll start an Alchemy/AMD FAQ or something in my directory and
put this information there. Thanks!
Pete
^ permalink raw reply
* Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Jeff Baitis @ 2003-03-14 20:23 UTC (permalink / raw)
To: Pete Popov; +Cc: Linux MIPS mailing list
Everyone:
Thank you very much for helping this green hand get up to speed on the MIPS
platform. I have successfully configured card services to work with the
current linux_2_4 CVS, in conjunction with a TI PCI1510 PCI->CardBus bridge.
There are a few card services options that you will need, in order to replicate
my work:
1. The pcmcia_core cis_speed needs to be set to a fairly low value.
I have successfully used `modprobe pcmcia_core cis_speed=10` and
`modprobe pcmcia_core cis_speed=1.`
2. The PCMCIA memory window must map into the memory window assigned
by the PCI device autoconfiguration. Since my `lspci -v` shows:
00:0d.0 CardBus bridge: Texas Instruments: Unknown device ac56
Subsystem: Unknown device 5678:1234
Flags: bus master, medium devsel, latency 168, IRQ 1
Memory at 40000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=05, subordinate=00, sec-latency=176
Memory window 0: 40001000-40002000 (prefetchable)
Memory window 1: 40400000-407ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
I configured /etc/pcmcia/config.opts as follows:
#
# Local PCMCIA Configuration File
#
#----------------------------------------------------------------------
# System resources available for PCMCIA devices
# remember to modprobe pcmcia_core cis_speed=10
include port 0x100-0x4ff, port 0xc00-0xcff
include memory 0x40000000-0x40ffffff
#-------------------------- eof
Special thanks to Pete for answering so many of my questions.
I hope you find this information useful!
Best regards,
Jeff
--
Jeffrey Baitis - Associate Software Engineer
Evolution Robotics, Inc.
130 West Union Street
Pasadena CA 91103
tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply
* Re: Tips on inspecting / debuging cache
From: Ralf Baechle @ 2003-03-14 19:26 UTC (permalink / raw)
To: Wayne Gowcher; +Cc: linux-mips
In-Reply-To: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
On Thu, Mar 13, 2003 at 06:13:08PM -0800, Wayne Gowcher wrote:
> I am wondering if someone could point me towards
> articles / source code that would give me a little
> insight into how to debug cache problems in mips.
>
> For example , how do I inspect the contents of the
> cache ? Are there routines to dump out the contents of
> the cache ?
Frankly, such code isn't to useful. The problems in the cache code can
be fairly subtle. The only thing that has worked halfway well is reading
the code 1,000 times more after having read it 1,000 times. And because
it's such a nice job, read it another 1000 times when finished.
If you're refering to the current round of cache problems introduced about
three days ago when I eleminated flush_page_to_ram() and replace it
with flush_dcache_page() - the untested quickfix is changing the
definitions of clear_user_page() and copy_user_page() in <asm/page.h> to
flush the data cache after the operation, for example by invoking
flush_cache_all(). This particular problem affects all processors with
virtually indexed data caches except the R4000 and R4000 SC and MC
versions and the R10000 family.
And everybody's favorite question, was this necessary that late in 2.4?
Yes, it was. The new mechanism deals is not only more efficient it also
deals better with aliases between the pagecache and userspace mappings.
Ralf
^ permalink raw reply
* Re: Tips on inspecting / debuging cache
From: Kevin D. Kissell @ 2003-03-14 8:22 UTC (permalink / raw)
To: Wayne Gowcher, linux-mips
In-Reply-To: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
> I am wondering if someone could point me towards
> articles / source code that would give me a little
> insight into how to debug cache problems in mips.
>
> For example , how do I inspect the contents of the
> cache ?
Which MIPS CPU are you using? The CACHE instruction
was introduced with the R4000 CPU as an implementation
dependent feature, and was finally standardized in the MIPS32
and MIPS64 architecture specs. See
http://www.mips.com/publications/processor_architecture.html
In MIPS32, to be able to properly inspect the cache, one needs
a CPU which implements the optional Index_Load_Tag CACHE
operation and has both TagHi/TagLo (required) DataHi/DataLo
(optional) registers. Pre-MIPS32 CPUs may offer the ability
to inspect the cache with variant mechanisms (see your chip
spec), or not at all.
>Are there routines to dump out the contents of
> the cache ?
People write them from time to time, but so far I don't
think anyone has written a "standard" cache dump API
or implementation in the Linux kernel.
Kevin K.
^ permalink raw reply
* Re: Tips on inspecting / debuging cache
From: Kevin D. Kissell @ 2003-03-14 8:22 UTC (permalink / raw)
To: Wayne Gowcher, linux-mips
In-Reply-To: <20030314021308.60082.qmail@web11905.mail.yahoo.com>
> I am wondering if someone could point me towards
> articles / source code that would give me a little
> insight into how to debug cache problems in mips.
>
> For example , how do I inspect the contents of the
> cache ?
Which MIPS CPU are you using? The CACHE instruction
was introduced with the R4000 CPU as an implementation
dependent feature, and was finally standardized in the MIPS32
and MIPS64 architecture specs. See
http://www.mips.com/publications/processor_architecture.html
In MIPS32, to be able to properly inspect the cache, one needs
a CPU which implements the optional Index_Load_Tag CACHE
operation and has both TagHi/TagLo (required) DataHi/DataLo
(optional) registers. Pre-MIPS32 CPUs may offer the ability
to inspect the cache with variant mechanisms (see your chip
spec), or not at all.
>Are there routines to dump out the contents of
> the cache ?
People write them from time to time, but so far I don't
think anyone has written a "standard" cache dump API
or implementation in the Linux kernel.
Kevin K.
^ permalink raw reply
* Tips on inspecting / debuging cache
From: Wayne Gowcher @ 2003-03-14 2:13 UTC (permalink / raw)
To: linux-mips
Dear List,
I am wondering if someone could point me towards
articles / source code that would give me a little
insight into how to debug cache problems in mips.
For example , how do I inspect the contents of the
cache ? Are there routines to dump out the contents of
the cache ?
Any help, tips , pointers would be appreciated.
TIA
Wayne
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
^ permalink raw reply
* Re: Disabling lwl and lwr instruction generation
From: Alan Cox @ 2003-03-14 0:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Ranjan Parthasarathy, Richard Hodges, linux-mips
In-Reply-To: <20030313223529.D30512@linux-mips.org>
On Thu, 2003-03-13 at 21:35, Ralf Baechle wrote:
> Replace those unaligned copies with a word-wise or even bytewise copying.
> Not good for performance but ...
Depends on (src^dest) & 3. Glibc may have the code you need to get it
right, although it will also depend on how smart the cpu cache is - if
you have a write through cache then shift/mask/write in 32/64 chunks
may be fastest
Alan
^ permalink raw reply
* Re: Patches for Au1000: PCI int problem, DB1500 board reset & ethernet
From: Pete Popov @ 2003-03-13 22:50 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
In-Reply-To: <3E70E52E.B6FF1C2A@ekner.info>
> The second patch adds board reset using HW register for DB1500.
OK, that's applicable to all Db boards so I modified the patch and
applied it; might need to cleanup that later (the long ifdef line).
Pete
^ permalink raw reply
* Re: Patches for Au1000: PCI int problem, DB1500 board reset & ethernet
From: Pete Popov @ 2003-03-13 22:45 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
In-Reply-To: <3E70E52E.B6FF1C2A@ekner.info>
On Thu, 2003-03-13 at 12:08, Hartvig Ekner wrote:
> Hi,
>
> The first patch below fixes interrupt setup for DB1500. The PCI interrupts
> were polarized wrongly, causing a deadlock when used.
Applied. Thanks for catching that one. I had tested the Db1500 pci slot
with a graphics card. I guess the interrupt handling doesn't get tested
with a frame buffer driver :)
> The second patch adds board reset using HW register for DB1500.
I want to see if this is applicable to all Db boards before checking it
in.
> The third patch reverses interrupt handling order for RX & TX to
> minimize packet loss in high-load situations.
Applied. Though I wonder about the performance when the target is
transmitting heavily vs receiving.
Pete
>
> /Hartvig
>
>
>
> ______________________________________________________________________
>
> Index: irq.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/irq.c,v
> retrieving revision 1.11.2.14
> diff -u -r1.11.2.14 irq.c
> --- irq.c 26 Feb 2003 21:14:24 -0000 1.11.2.14
> +++ irq.c 13 Mar 2003 19:45:57 -0000
> @@ -430,14 +430,10 @@
> case AU1000_IRDA_RX_INT:
>
> case AU1000_MAC0_DMA_INT:
> -#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1500)
> - case AU1000_MAC1_DMA_INT:
> -#endif
> -#ifdef CONFIG_MIPS_PB1500
> +#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
> case AU1000_MAC1_DMA_INT:
> #endif
> case AU1500_GPIO_204:
> -
> setup_local_irq(i, INTC_INT_HIGH_LEVEL, 0);
> irq_desc[i].handler = &level_irq_type;
> break;
> @@ -446,7 +442,7 @@
> case AU1000_GPIO_15:
> #endif
> case AU1000_USB_HOST_INT:
> -#ifdef CONFIG_MIPS_PB1500
> +#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_DB1500)
> case AU1000_PCI_INTA:
> case AU1000_PCI_INTB:
> case AU1000_PCI_INTC:
> @@ -488,9 +484,9 @@
> case AU1000_RTC_MATCH0_INT:
> case AU1000_RTC_MATCH1_INT:
> case AU1000_RTC_MATCH2_INT:
> - setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
> - irq_desc[i].handler = &rise_edge_irq_type;
> - break;
> + setup_local_irq(i, INTC_INT_RISE_EDGE, 0);
> + irq_desc[i].handler = &rise_edge_irq_type;
> + break;
>
> // Careful if you change match 2 request!
> // The interrupt handler is called directly
>
> ______________________________________________________________________
>
> Index: reset.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/common/reset.c,v
> retrieving revision 1.2.2.8
> diff -u -r1.2.2.8 reset.c
> --- reset.c 11 Dec 2002 06:12:29 -0000 1.2.2.8
> +++ reset.c 13 Mar 2003 19:46:03 -0000
> @@ -111,15 +111,13 @@
> set_c0_config(CONF_CM_UNCACHED);
> flush_cache_all();
> write_c0_wired(0);
> -
> -#ifdef CONFIG_MIPS_PB1500
> - au_writel(0x00000000, 0xAE00001C);
> -#endif
>
> -#ifdef CONFIG_MIPS_PB1100
> +#if defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_DB1500)
> + /* Do a HW reset if the board can do it */
> +
> au_writel(0x00000000, 0xAE00001C);
> #endif
> -
> +
> __asm__ __volatile__("jr\t%0"::"r"(0xbfc00000));
> }
>
>
> ______________________________________________________________________
>
> Index: au1000_eth.c
> ===================================================================
> RCS file: /home/cvs/linux/drivers/net/au1000_eth.c,v
> retrieving revision 1.5.2.15
> diff -u -r1.5.2.15 au1000_eth.c
> --- au1000_eth.c 3 Mar 2003 06:40:30 -0000 1.5.2.15
> +++ au1000_eth.c 13 Mar 2003 20:01:51 -0000
> @@ -1414,8 +1414,11 @@
> printk(KERN_ERR "%s: isr: null dev ptr\n", dev->name);
> return;
> }
> - au1000_tx_ack(dev);
> +
> + /* Handle RX interrupts first to minimize chance of overrun */
> +
> au1000_rx(dev);
> + au1000_tx_ack(dev);
> }
>
>
^ permalink raw reply
* Re: arch/mips/au1000/common/irq.c
From: Jeff Baitis @ 2003-03-13 22:25 UTC (permalink / raw)
To: Dan Malek; +Cc: Pete Popov, linux-mips, Hartvig Ekner
In-Reply-To: <20030313141331.Y20129@luca.pas.lab>
Hartvig's patch has solved my IRQ storm problems. Thank you all very much for
your attention!
Regards,
Jeff
On Thu, Mar 13, 2003 at 02:13:31PM -0800, Jeff Baitis wrote:
> Dan:
>
> I just verified that I get an IRQ storm when I plug a 3.3-volt based SMC
> EPIC/100 network card into the PCI slot of the Au1500. Before I bring the
> interface up, I notice that the driver tries to allocate IRQ 1 (INTA). This is
> the same IRQ that the ill-fated CardBus bridge attempts to use. ;)
>
> As soon as I bring the SMC interface up using ifconfig (and have the interface
> plugged into an active Ethernet network), the IRQ storm ensues.
>
> I'll try Hartvig's patch, look over the irq.c levels, and see how everything
> fares.
>
> Thanks all!
>
> Regards,
>
> Jeff
>
>
> On Thu, Mar 13, 2003 at 01:50:46PM -0500, Dan Malek wrote:
> > Jeff Baitis wrote:
> >
> > > Pete:
> > >
> > > I've got a question concerning irq.c. In intc0_req0_irqdispatch() (linux_2_4
> > > branch) on lines 545 thru 552, the code reads:
> >
> > I'm hacking these functions to use 'clz' and for other updates, so
> > the code will be changing soon, anyway :-) Comment on the next version :-)
> >
> > Thanks.
> >
> >
> > -- Dan
> >
> >
> >
>
> --
> Jeffrey Baitis - Associate Software Engineer
>
> Evolution Robotics, Inc.
> 130 West Union Street
> Pasadena CA 91103
>
> tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
>
>
--
Jeffrey Baitis - Associate Software Engineer
Evolution Robotics, Inc.
130 West Union Street
Pasadena CA 91103
tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox