From jsun@mvista.com Wed Aug 2 01:53:05 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA03971; Wed, 2 Aug 2000 01:53:04 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 01:53:04 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id QAA12032; Tue, 1 Aug 2000 16:52:26 -0700 Sender: jsun@hermes.mvista.com Message-ID: <398762B9.D8507860@mvista.com> Date: Tue, 01 Aug 2000 16:52:25 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux@engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: PROPOSAL : multi-way cache support in Linux/MIPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2220 Lines: 71 Ralf, I have got NEC DDB5476 running stable enough that I am comfortable to check in my code. Will you take it? Assuming the answer is yes, there are several issues regarding checking in. I will bring them up one by one. The first issue is multi-way cache support. DDB5476 uses R5432 CPU which has two-way set-associative cache. The problematic part is the index-based cache operations in r4xxcache.h does not cover all ways in a set. I think this is a problem in general. So far I have seen MIPS processors with 2-way, 4-way and 8-way sets. And I have seen them using ether least- significant-addressing-bits or most-significant-addressing-bits within a cache line to select ways. Here is my proposal : . introduce two variables, cache_num_ways - number of ways in a set cache_way_selection_offset - the offset added to the address to select next cache line in the same set. For LSBs addressing, it is equal to 1. For MSBs addressing, it is equal to cache_line_size / cache_num_ways. (It can potentially take care of some future weired way-selection scheme as long as the offset is uniform) . These variables are initialized in cpu_probe(). (Alternatively, I think we should have cpu_info table, that contains all these cpu information. Then a general routine can fill in the based on the cpu id. This can get rid of a bunch of ugly switch/case statements.) . in the include/asm/r4kcache.h file, all Index-based cache operation needs to changed like the following (for illustration only; need optimization) : ----- while(start < end) { cache16_unroll32(start,Index_Writeback_Inv_D); start += 0x200; } +++++ while(start < end) { for (i=0; i< cache_num_ways; i++) { cache16_unroll32(start + i*cache_way_selection_offset, Index_Writeback_Inv_D); } start += 0x200; } ===== What do you think? If it is OK, I can do the patch. The cpu_info table is a nice wish, but I don't think I know enough to do that job yet. Jun From kevink@mips.com Wed Aug 2 10:25:10 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA07458; Wed, 2 Aug 2000 10:25:07 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 10:25:07 +0200 (MET DST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA29838; Wed, 2 Aug 2000 01:23:56 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA15451; Wed, 2 Aug 2000 01:23:52 -0700 (PDT) Message-ID: <008601bffc5b$6714c0a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , , , Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS Date: Wed, 2 Aug 2000 10:26:38 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0083_01BFFC6C.24323180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Length: 21225 Lines: 357 This is a multi-part message in MIME format. ------=_NextPart_000_0083_01BFFC6C.24323180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Rather than re-invent the wheel, please consider the cache descriptor data structures we developed at MIPS to deal with this problem. I believe that the updated cache.h file, and maybe even the cpu_probe.c file, was checked into the 2.2 repository at SGI long ago. There are also a set of initialisation and invalidation routines that key off the cache descriptor structure, but those aren't in the SGI repository (though anyone can get them from ftp.mips.com or www.paralogos.com). The CPU probe logic (also on those sites, and already integrated into several variants because it also supports setting up state needed by the software FPU emulation) is table-based, and for each PrID value, there is a template for the cache characteristics, which can either be taken "as is" or probed, depending on a flag in the descriptor. Since the number of "ways" cannot always be determined by probing, if the number of ways is specified, it is preserved even if a cache probe is performed. I won't attach the full set of cache probe routines (which would only confuse things), but here is the cache data structure definition and the CPU descriptor template table that we use. Regads, Kevin K. -----Original Message----- From: Jun Sun To: linux@cthulhu.engr.sgi.com ; linux-mips@fnet.fr ; ralf@oss.sgi.com Date: Wednesday, August 02, 2000 2:01 AM Subject: PROPOSAL : multi-way cache support in Linux/MIPS >Ralf, > >I have got NEC DDB5476 running stable enough that I am comfortable to >check in >my code. Will you take it? > >Assuming the answer is yes, there are several issues regarding checking >in. >I will bring them up one by one. > >The first issue is multi-way cache support. DDB5476 uses R5432 CPU >which >has two-way set-associative cache. The problematic part is the >index-based cache operations in r4xxcache.h does not cover all ways in a >set. > >I think this is a problem in general. So far I have seen MIPS >processors with >2-way, 4-way and 8-way sets. And I have seen them using ether least- >significant-addressing-bits or most-significant-addressing-bits >within a cache line to select ways. > >Here is my proposal : > >. introduce two variables, > cache_num_ways - number of ways in a set > cache_way_selection_offset - the offset added to the address to >select > next cache line in the same set. For LSBs addressing, >it is > equal to 1. For MSBs addressing, it is equal to > cache_line_size / cache_num_ways. (It can potentially >take > care of some future weired way-selection scheme as long >as > the offset is uniform) > >. These variables are initialized in cpu_probe(). > > (Alternatively, I think we should have cpu_info table, that contains >all > these cpu information. Then a general routine can fill in the based >on > the cpu id. This can get rid of a bunch of ugly switch/case >statements.) > >. in the include/asm/r4kcache.h file, all Index-based cache operation >needs > to changed like the following (for illustration only; need >optimization) : > >----- > while(start < end) { > cache16_unroll32(start,Index_Writeback_Inv_D); > start += 0x200; > } >+++++ > while(start < end) { > for (i=0; i< cache_num_ways; i++) { > cache16_unroll32(start + >i*cache_way_selection_offset, > Index_Writeback_Inv_D); > } > start += 0x200; > } >===== > >What do you think? If it is OK, I can do the patch. The cpu_info table >is a nice wish, but I don't think I know enough to do that job yet. > >Jun ------=_NextPart_000_0083_01BFFC6C.24323180 Content-Type: application/octet-stream; name="cache.h" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cache.h" LyoKICogaW5jbHVkZS9hc20tbWlwcy9jYWNoZS5oCiAqLwovKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICog IDcgRGVjLCAxOTk5LgogKiAgQWRkZWQgZGVmaW5pdGlvbiBvZiBjYWNoZSBkZXNjcmlwdG9yIHN0 cnVjdHVyZS4KICoKICogIEtldmluIEQuIEtpc3NlbGwsIGtldmlua0BtaXBzLmNvbQogKiAgQ29w eXJpZ2h0IChDKSAxOTk5IE1JUFMgVGVjaG5vbG9naWVzLCBJbmMuICBBbGwgcmlnaHRzIHJlc2Vy dmVkLgogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKi8KCiNpZm5kZWYgX19BU01fTUlQU19DQUNIRV9ICiNkZWZp bmUgX19BU01fTUlQU19DQUNIRV9ICgojaWZuZGVmIF9MQU5HVUFHRV9BU1NFTUJMWQovKgogKiBE ZXNjcmlwdG9yIGZvciBhIGNhY2hlCiAqLwoKc3RydWN0IGNhY2hlX2Rlc2MgewogICAgICAgIGlu dCBsaW5lc3o7CiAgICAgICAgaW50IHNldHM7CiAgICAgICAgaW50IHdheXM7CiAgICAgICAgaW50 IGZsYWdzOyAgICAgIC8qIERldGFpbHMgbGlrZSB3cml0ZSB0aHJ1L2JhY2ssIGNvaGVyZW50LCBl dGMuICovCn07CgojZW5kaWYKLyoKICogRmxhZyBkZWZpbml0aW9ucwogKi8KCiNkZWZpbmUgTUlQ U19DQUNIRV9ORUVEU19DT05GSUcJMHgwMDAwMDAwMQojZGVmaW5lIE1JUFNfQ0FDSEVfVklSVFVB TAkweDAwMDAwMDAyICAvKiBWaXJ0dWFsbHkgdGFnZ2VkICovCgovKiBieXRlcyBwZXIgTDEgY2Fj aGUgbGluZSAqLwoKLyogCiAqIEl0IHdvdWxkIGJlIG5pY2UgdG8gbWFrZSB0aGlzIGR5bmFtaWMs IAogKiBiYXNlZCBvbiBtaXBzX2NwdS5kY2FjaGUubGluZXN6LCBidXQKICogaXQgaXMgdXNlZCBm b3IgZml4ZWQtc2l6ZSBzdHJ1Y3R1cmUgYWxsb2NhdGlvbi4KICogU2V0IHRvIGtub3duIG1heGlt dW0gZm9yIE1JUFMgYXJjaGl0ZWN0dXJlLCAzMiBieXRlcy4KICovCgojZGVmaW5lICAgICAgICBM MV9DQUNIRV9CWVRFUyAgMzIKCgojZGVmaW5lICAgICAgICBMMV9DQUNIRV9BTElHTih4KSAgICAg ICAoKCh4KSsoTDFfQ0FDSEVfQllURVMtMSkpJn4oTDFfQ0FDSEVfQllURVMtMSkpCgojZGVmaW5l ICAgICAgICBTTVBfQ0FDSEVfQllURVMgTDFfQ0FDSEVfQllURVMKCiNlbmRpZiAvKiBfX0FTTV9N SVBTX0NBQ0hFX0ggKi8K ------=_NextPart_000_0083_01BFFC6C.24323180 Content-Type: application/octet-stream; name="cpu.h" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cpu.h" LyogJElkOiBjcHUuaCx2IDEuNSAyMDAwLzAyLzE2IDIxOjQ2OjI5IGtldmluayBFeHAgJAogKiBj cHUuaDogVmFsdWVzIG9mIHRoZSBQUklkIHJlZ2lzdGVyIHVzZWQgdG8gbWF0Y2ggdXAKICogICAg ICAgIHZhcmlvdXMgTUlQUyBjcHUgdHlwZXMuCiAqCiAqIENvcHlyaWdodCAoQykgMTk5NiBEYXZp ZCBTLiBNaWxsZXIgKGRtQGVuZ3Iuc2dpLmNvbSkKICoKICovCi8qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgog KiAgNyBEZWMsIDE5OTkuCiAqICBBZGRlZCA0S0MgYW5kIDVLQyBQUl9JRCBjb2RlcywgYW5kIGRl ZmluZWQgbWlwc19jcHUgZGF0YSBzdHJ1Y3R1cmUKICogIGFuZCBmaWVsZCBlbmNvZGluZ3MuCiAq CiAqICBLZXZpbiBELiBLaXNzZWxsLCBrZXZpbmtAbWlwcy5jb20KICogIENvcHlyaWdodCAoQykg MTk5OSBNSVBTIFRlY2hub2xvZ2llcywgSW5jLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKiovCgojaWZuZGVmIF9NSVBTX0NQVV9ICiNkZWZpbmUgX01JUFNfQ1BVX0gKCi8q CiAqIEFzc2lnbmVkIHZhbHVlcyBmb3IgdGhlIHByb2R1Y3QgSUQgcmVnaXN0ZXIuICBJbiBvcmRl ciB0byBkZXRlY3QgYQogKiBjZXJ0YWluIENQVSB0eXBlIGV4YWN0bHkgZXZlbnR1YWxseSBhZGRp dGlvbmFsIHJlZ2lzdGVycyBtYXkgbmVlZCB0bwogKiBiZSBleGFtaW5lZC4KICovCiNkZWZpbmUg UFJJRF9JTVBfUjIwMDAgICAgMHgwMTAwCiNkZWZpbmUgUFJJRF9JTVBfUjMwMDAgICAgMHgwMjAw CiNkZWZpbmUgUFJJRF9JTVBfUjYwMDAgICAgMHgwMzAwCiNkZWZpbmUgUFJJRF9JTVBfUjQwMDAg ICAgMHgwNDAwCiNkZWZpbmUgUFJJRF9JTVBfUjYwMDBBICAgMHgwNjAwCiNkZWZpbmUgUFJJRF9J TVBfUjEwMDAwICAgMHgwOTAwCiNkZWZpbmUgUFJJRF9JTVBfUjQzMDAgICAgMHgwYjAwCiNkZWZp bmUgUFJJRF9JTVBfUjgwMDAgICAgMHgxMDAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2MDAgICAgMHgy MDAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ3MDAgICAgMHgyMTAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2 NDAgICAgMHgyMjAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2NTAgICAgMHgyMjAwCQkvKiBTYW1lIGFz IFI0NjQwICovCiNkZWZpbmUgUFJJRF9JTVBfUjUwMDAgICAgMHgyMzAwCiNkZWZpbmUgUFJJRF9J TVBfU09OSUMgICAgMHgyNDAwCiNkZWZpbmUgUFJJRF9JTVBfTUFHSUMgICAgMHgyNTAwCiNkZWZp bmUgUFJJRF9JTVBfUk03MDAwICAgMHgyNzAwCiNkZWZpbmUgUFJJRF9JTVBfTkVWQURBICAgMHgy ODAwCQkvKiBSTTUyNjAgPz8/ICovCiNkZWZpbmUgUFJJRF9JTVBfNEtDICAgICAgMHg4MDAwCiNk ZWZpbmUgUFJJRF9JTVBfNUtDICAgICAgMHg4MTAwCgojZGVmaW5lIFBSSURfSU1QX1VOS05PV04g IDB4ZmYwMAoKI2RlZmluZSBQUklEX1JFVl9SNDQwMCAgICAweDAwNDAKI2RlZmluZSBQUklEX1JF Vl9SMzAwMEEgICAweDAwMzAKI2RlZmluZSBQUklEX1JFVl9SMzAwMCAgICAweDAwMjAKI2RlZmlu ZSBQUklEX1JFVl9SMjAwMEEgICAweDAwMTAKCgojaW5jbHVkZSA8YXNtL2NhY2hlLmg+CgojaWZu ZGVmICBfTEFOR1VBR0VfQVNTRU1CTFkKLyoKICogQ2FwYWJpbGl0eSBhbmQgZmVhdHVyZSBkZXNj cmlwdG9yIHN0cnVjdHVyZSBmb3IgTUlQUyBDUFUKICovCgpzdHJ1Y3QgbWlwc19jcHUgewoJdW5z aWduZWQgaW50IHByb2Nlc3Nvcl9pZDsKCXVuc2lnbmVkIGludCBjcHV0eXBlOwkJLyogT2xkICJt aXBzX2NwdXR5cGUiIGNvZGUgKi8KCWludCBpc2FfbGV2ZWw7CglpbnQgb3B0aW9uczsKCWludCB0 bGJzaXplOwoJc3RydWN0IGNhY2hlX2Rlc2MgaWNhY2hlOwkvKiBQcmltYXJ5IEktY2FjaGUgKi8K CXN0cnVjdCBjYWNoZV9kZXNjIGRjYWNoZTsJLyogUHJpbWFyeSBEIG9yIGNvbWJpbmVkIEkvRCBj YWNoZSAqLwoJc3RydWN0IGNhY2hlX2Rlc2Mgc2NhY2hlOwkvKiBTZWNvbmRhcnkgY2FjaGUgKi8K CXN0cnVjdCBjYWNoZV9kZXNjIHRjYWNoZTsJLyogVGVydGlhcnkvc3BsaXQgc2Vjb25kYXJ5IGNh Y2hlICovCn07CgojZW5kaWYKCi8qCiAqIElTQSBMZXZlbCBlbmNvZGluZ3MgCiAqLwoKI2RlZmlu ZSBNSVBTX0NQVV9JU0FfSQkJMHgwMDAwMDAwMQojZGVmaW5lIE1JUFNfQ1BVX0lTQV9JSQkJMHgw MDAwMDAwMgojZGVmaW5lIE1JUFNfQ1BVX0lTQV9JSUkJMHgwMDAwMDAwMwojZGVmaW5lIE1JUFNf Q1BVX0lTQV9JVgkJMHgwMDAwMDAwNAojZGVmaW5lIE1JUFNfQ1BVX0lTQV9WCQkweDAwMDAwMDA1 CiNkZWZpbmUgTUlQU19DUFVfSVNBX00zMgkweDAwMDAwMDIwCiNkZWZpbmUgTUlQU19DUFVfSVNB X002NAkweDAwMDAwMDQwCgovKgogKiBDUFUgT3B0aW9uIGVuY29kaW5ncyAKICovIAoKI2RlZmlu ZSBNSVBTX0NQVV9UTEIJMHgwMDAwMDAwMQkvKiBDUFUgaGFzIFRMQiAqLwovKiBMZWF2ZSBhIHNw YXJlIGJpdCBmb3IgdmFyaWFudCBNTVUgdHlwZXMuLi4gKi8KI2RlZmluZSBNSVBTX0NQVV80S0VY CTB4MDAwMDAwMDQJLyogIlI0SyIgZXhjZXB0aW9uIG1vZGVsICovCiNkZWZpbmUgTUlQU19DUFVf NEtUTEIJMHgwMDAwMDAwOAkvKiAiUjRLIiBUTEIgaGFuZGxlciAqLwojZGVmaW5lIE1JUFNfQ1BV X0ZQVQkweDAwMDAwMDEwCS8qIENQVSBoYXMgRlBVICovCiNkZWZpbmUgTUlQU19DUFVfMzJGUFIJ MHgwMDAwMDAyMAkvKiAzMiBkYmwuIHByZWMuIEZQIHJlZ2lzdGVycyAqLwojZGVmaW5lIE1JUFNf Q1BVX0NPVU5URVIgMHgwMDAwMDA0MAkvKiBDeWNsZSBjb3VudC9jb21wYXJlICovCiNkZWZpbmUg TUlQU19DUFVfV0FUQ0gJMHgwMDAwMDA4MAkvKiB3YXRjaHBvaW50IHJlZ2lzdGVycyAqLwojZGVm aW5lIE1JUFNfQ1BVX01JUFMxNgkweDAwMDAwMTAwCS8qIGNvZGUgY29tcHJlc3Npb24gKi8KI2Rl ZmluZSBNSVBTX0NQVV9ESVZFQwkweDAwMDAwMjAwCS8qIGRlZGljYXRlZCBpbnRlcnJ1cHQgdmVj dG9yICovCiNkZWZpbmUgTUlQU19DUFVfVkNFCTB4MDAwMDA0MDAJLyogdmlydC4gY29oZXJlbmNl IGNvbmZsaWN0IHBvc3NpYmxlICovCiNkZWZpbmUgTUlQU19DUFVfQ0FDSEVfQ0RFWCAweDAwMDAw ODAwCS8qIENyZWF0ZV9EaXJ0eV9FeGNsdXNpdmUgQ0FDSEUgb3AgKi8KCiNlbmRpZiAvKiAhKF9N SVBTX0NQVV9IKSAqLwo= ------=_NextPart_000_0083_01BFFC6C.24323180 Content-Type: application/octet-stream; name="cpu_probe.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cpu_probe.c" LyogJElkOiBjcHVfcHJvYmUuYyx2IDEuMTEgMjAwMC8wNy8wNyAwOTowMjozNiBjYXJzdGVubCBF eHAgJCAKICoKICogY3B1X3Byb2JlLmMKICoKICogS2V2aW4gRC4gS2lzc2VsbCwga2V2aW5rQG1p cHMuY29tCiAqIENvcHlyaWdodCAoQykgMTk5OSwyMDAwIE1JUFMgVGVjaG5vbG9naWVzLCBJbmMu ICBBbGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICoKICogIFRoaXMg cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIGRpc3RyaWJ1dGUgaXQgYW5kL29yIG1v ZGlmeSBpdAogKiAgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZSAoVmVyc2lvbiAyKSBhcwogKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24uCiAqCiAqICBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUg aXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCiAqICBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKICogIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg TGljZW5zZQogKiAgZm9yIG1vcmUgZGV0YWlscy4KICoKICogIFlvdSBzaG91bGQgaGF2ZSByZWNl aXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCiAqICB3 aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCBJbmMuLAogKiAgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24gTUEg MDIxMTEtMTMwNywgVVNBLgogKgogKiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICoKICogQyBjb2RlLCBjYWxs ZWQgZnJvbSBzdGFydHVwIHZlY3RvciB0byBkZWNvZGUgdGhlIENQVSBjb25maWd1cmF0aW9uIGFu ZCAKICogc2V0IHVwIHRoZSBtaXBzX2NwdSBkYXRhIHN0cnVjdHVyZSwgdXNlZCBieSB0aGUga2Vy bmVsIHRvIGFic3RyYWN0IG91dCAKICogbW9zdCBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIG9mIE1J UFMgQ1BVcy4KICoKICovCgojaW5jbHVkZSA8YXNtL2NwdS5oPgojaW5jbHVkZSA8YXNtL2Jvb3Rp bmZvLmg+CiNpbmNsdWRlIDxhc20vaW5pdC5oPgoKI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5oPgoK I2lmZGVmIENPTkZJR19DUFVfTUlQUzMyCmV4dGVybiB2b2lkIG1pcHMzMl9jcHVfcHJvYmUodW5z aWduZWQgaW50IHByX2lkKTsKI2VuZGlmCgovKiBkZWNsYXJhdGlvbiBvZiB0aGUgZ2xvYmFsIHN0 cnVjdCAqLwpzdHJ1Y3QgbWlwc19jcHUgbWlwc19jcHUgPSB7UFJJRF9JTVBfVU5LTk9XTiwgQ1BV X1VOS05PV04sIDAsIDAsIDAsCgkJCQl7MCwwLDAsMH0sIHswLDAsMCwwfSwgezAsMCwwLDB9LCB7 MCwwLDAsMH19OwoKLyogU2hvcnRjdXQgZm9yIGFzc2VtYmxlciBhY2Nlc3MgdG8gbWlwc19jcHUu b3B0aW9ucyAqLwoKaW50ICpjcHVvcHRpb25zID0gJm1pcHNfY3B1Lm9wdGlvbnM7CgovKgogKiBD YW5uZWQgZGVzY3JpcHRvcnMgb2YgTUlQUyBDUFVzLiBOb3RlIHRoYXQgZm9yIHRoZSBjb2RlIGJl bG93CiAqIHRvIGZ1bmN0aW9uIGNvcnJlY3RseSwgYSBnZW5lcmljIGRlc2NyaXB0aW9uIHdpdGgg YSBwcm9jZXNzb3JfaWQKICogdmFsdWUgd2l0aCBubyBpbXBsZW1lbnRhdGlvbiBiaXRzIHNldCBt dXN0IGZvbGxvdyBhbnkgZGVzY3JpcHRpb25zCiAqIG9mIGRpc3RpbmN0IHZhcmlhbnQgcmV2aXN0 aW9ucywgaS5lLiBSNDAwMCBtdXN0IHByZWNlZGUgUjQ0MDAsCiAqIFIzMDAwIG11c3QgcHJlY2Vk ZSBSMzAwMEEuICBNYW55IENQVXMgYXJlIG5vdCByZWZsZWN0ZWQgaW4KICogdGhlIGxpc3QuICBO ZXcgZW50cmllcyByZXF1aXJlIHRoZSBhZGR0aW9uIG9mIFBSX0lEIHJlZ2lzdGVyCiAqIGRhdGEg aW4gYXNtL2NwdS5oIGFuZCBhc3NpZ25tZW50IG9mIGEgQ1BVXyBjb2RlIGluIGFzbS9ib290aW5m by5oLgogKiBUaGUgbWlwc19jcHUgc3RydWN0dXJlIGlzIGRlZmluZWQgaW4gYXNtL2NwdS5oIGFu ZCBhc20vY2FjaGUuaC4KICovCgovKgogKiBTb21lIG9wdGlvbnMgYXJlIGNvbW1vbiBhY3Jvc3Mg YWxsIFI0MDAwIGRlcml2YXRpdmVzCiAqLwoKI2RlZmluZSBSNEtfT1BUUyAoTUlQU19DUFVfVExC IHwgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BVXzRLVExCIFwKCQl8IE1JUFNfQ1BVX0NPVU5URVIg fCBNSVBTX0NQVV9DQUNIRV9DREVYICkKCnN0YXRpYyBzdHJ1Y3QgbWlwc19jcHUgX19pbml0ZGF0 YSBtaXBzX2NwdV90ZW1wbGF0ZVtdID0gewoJLyogUjIwMDAgKi8KCXsgUFJJRF9JTVBfUjIwMDAs IAkvKiBQUl9JRCByZWdpc3RlciB2YWx1ZSAqLwoJICBDUFVfUjIwMDAsIAkJLyogS2VybmVsIGlu dGVybmFsIENQVSBpZGVudGlmaWVyICovCgkgIE1JUFNfQ1BVX0lTQV9JLCAJLyogTUlQUyBJU0Eg bGV2ZWwgKi8KCSAgTUlQU19DUFVfVExCLCAJLyogRmxhZ3MgZm9yIGltcGxlbWVudGF0aW9uIG9w dGlvbnMgKi8KCSAgMzIsCQkJLyogTnVtYmVyIG9mIFRMQiBlbnRyaWVzICovCgkgIHswLDAsMCww fSwgCQkvKiBJLWNhY2hlIGxpbmUgc2l6ZSwgI3NldHMsICN3YXlzLCBmbGFncyAqLwoJICB7MCww LDAsTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAvKiBVbmlmaWVkL0QtY2FjaGUgZGVzY3JpcHRv ciAqLwoJICB7MCwwLDAsMH0sIAkJLyogUy1jYWNoZSBkZXNjcmlwdG9yICovCgkgIHswLDAsMCww fX0sCQkvKiBUZXJ0aWFyeSBjYWNoZSBkZXNjcmlwdG9yICovCgkvKiBNSVBTIDRLYyAqLwoJeyBQ UklEX0lNUF80S0MsIENQVV80S0MsICBNSVBTX0NQVV9JU0FfTTMyLCBNSVBTX0NQVV9UTEIgfCAK CSAgICAgICAgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BVXzRLVExCIHwgTUlQU19DUFVfQ09VTlRF UiB8IAoJICAgICAgICBNSVBTX0NQVV9ESVZFQyB8IE1JUFNfQ1BVX1dBVENILCAxNiwgCgkgICAg ICAgIHsxNiwgMjU2LCA0LCAwfSwgezE2LCAyNTYsIDQsIDB9LCB7MCwwLDAsMH0sIHswLDAsMCww fX0sCgkvKiBNSVBTIDVLYyAqLwoJeyBQUklEX0lNUF81S0MsIENQVV81S0MsICBNSVBTX0NQVV9J U0FfTTY0LCBNSVBTX0NQVV9UTEIgfCAKCSAgICAgICAgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BV XzRLVExCIHwgTUlQU19DUFVfQ09VTlRFUiB8IAoJICAgICAgICBNSVBTX0NQVV9ESVZFQyB8IE1J UFNfQ1BVX1dBVENILCAzMiwKCSAgICAgICAgezMyLCAxMjgsIDQsIDB9LCB7MzIsIDEyOCwgNCwg MH0sIHswLDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFIzMDAwICovCgl7IFBSSURfSU1QX1IzMDAw LCBDUFVfUjMwMDAsIE1JUFNfQ1BVX0lTQV9JLCBNSVBTX0NQVV9UTEIsIDMyLAoJCXswLCAwLCAw LCAwfSwgezAsIDAsIDAsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgCgkJezAsMCwwLDB9LCB7 MCwwLDAsMH19LAoJLyogUjMwMDBBICovCgl7IFBSSURfSU1QX1IzMDAwIHwgUFJJRF9SRVZfUjMw MDBBLCBDUFVfUjMwMDBBLCAKCQlNSVBTX0NQVV9JU0FfSSwgTUlQU19DUFVfVExCLCAzMiwKCQl7 MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXswLDAs MCwwfSwgezAsMCwwLDB9fSwKCS8qIFI2MDAwICovCgl7IFBSSURfSU1QX1I2MDAwLCBDUFVfUjYw MDAsIE1JUFNfQ1BVX0lTQV9JSSwgCgkJTUlQU19DUFVfVExCIHwgTUlQU19DUFVfRlBVLCAzMiwK CQl7MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXsw LDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI2MDAwQSAqLwoJeyBQUklEX0lNUF9SNjAwMEEsIENQ VV9SNjAwMEEsIE1JUFNfQ1BVX0lTQV9JSSwgCgkJTUlQU19DUFVfVExCIHwgTUlQU19DUFVfRlBV LCAzMiwKCQl7MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30s IAoJCXswLDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI0MDAwU0MgKi8KCXsgUFJJRF9JTVBfUjQw MDAsIENQVV9SNDAwMFNDLCBNSVBTX0NQVV9JU0FfSUlJLCAKCSAgICBSNEtfT1BUUyB8IE1JUFNf Q1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSIAoJICAgIHwgTUlQU19DUFVfV0FUQ0ggfCBNSVBTX0NQ VV9WQ0UsIDQ4LAoJCXswLCAwLCAxLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXswLCAw LCAxLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sCgkJezAsMCwxLE1JUFNfQ0FDSEVfTkVFRFNf Q09ORklHfSwgezAsMCwwLDB9fSwKCS8qIFI0NDAwU0MgKi8KCXsgUFJJRF9JTVBfUjQwMDAgfCBQ UklEX1JFVl9SNDQwMCwgQ1BVX1I0NDAwU0MsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19P UFRTIHwgTUlQU19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIgCgkgICAgfCBNSVBTX0NQVV9XQVRD SCB8IE1JUFNfQ1BVX1ZDRSwgNDgsCgkJezAsIDAsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklH fSwgCgkJezAsIDAsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwKCQl7MCwwLDEsIE1JUFNf Q0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCwwLDB9fSwKCS8qIFI0MzAwICovCgl7IFBSSURfSU1Q X1I0MzAwLCBDUFVfUjQzMDAsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19PUFRTIHwgTUlQ U19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIgfCBNSVBTX0NQVV9XQVRDSCwgMzIsCgkJezMyLCA1 MTIsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgCgkJezE2LCA1MTIsIDEsIE1JUFNfQ0FD SEVfTkVFRFNfQ09ORklHfSwgCgkJezAsMCwwLDB9LCB7MCwwLDAsMH19LAoJLyogUjQ2MDAgKi8K CXsgUFJJRF9JTVBfUjQ2MDAsIENQVV9SNDYwMCwgTUlQU19DUFVfSVNBX0lJSSwgCgkgICAgUjRL X09QVFMgfCBNSVBTX0NQVV9GUFUsIDQ4LAoJCXszMiwgMTI4LCAyLCBNSVBTX0NBQ0hFX05FRURT X0NPTkZJR30sIAoJCXszMiwgMTI4LCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXsw LDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI0NjUwICovCgl7IFBSSURfSU1QX1I0NjUwLCBDUFVf UjQ2NTAsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19PUFRTIHwgTUlQU19DUFVfRlBVLCA0 OCwKCQl7MzIsIDEyOCwgMiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MzIsIDEyOCwg MiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MCwwLDAsMH0sIHswLDAsMCwwfX0sCgkv KiBSNDcwMCAqLwoJeyBQUklEX0lNUF9SNDcwMCwgQ1BVX1I0NzAwLCBNSVBTX0NQVV9JU0FfSUlJ LCAKCSAgICBSNEtfT1BUUyB8IE1JUFNfQ1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSLCA0OCwKCQl7 MzIsIDI1NiwgMiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MzIsIDI1NiwgMiwgTUlQ U19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MCwwLDAsMH0sIHswLDAsMCwwfX0sCgkvKiBSNTAw MCAqLwoJeyBQUklEX0lNUF9SNTAwMCwgQ1BVX1I1MDAwLCBNSVBTX0NQVV9JU0FfSVYsIAoJICAg IFI0S19PUFRTIHwgTUlQU19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIsIDQ4LAoJCXszMiwgNTEy LCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXszMiwgNTEyLCAyLCBNSVBTX0NBQ0hF X05FRURTX0NPTkZJR30sCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCww LDB9fSwKCS8qIFI1Mnh4LiBDYWNoZSBzaXplIHZhcmllcyB3aXRoIHJldmlzaW9uICovCgl7IFBS SURfSU1QX05FVkFEQSwgQ1BVX05FVkFEQSwgTUlQU19DUFVfSVNBX0lWLCAKCSAgICBSNEtfT1BU UyB8IE1JUFNfQ1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSIHwgTUlQU19DUFVfRElWRUMsIDQ4LAoJ CXswLCAwLCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIHswLCAwLCAyLCBNSVBTX0NBQ0hF X05FRURTX0NPTkZJR30sCgkJezAsMCwwLDB9LCB7MCwwLDAsMH19LAoJLyogUjgwMDAgLSBoYXMg d2llcmQgVExCOiAzLXdheSB4IDEyOCAqLwoJeyBQUklEX0lNUF9SODAwMCwgQ1BVX1I4MDAwLCBN SVBTX0NQVV9JU0FfSVYsIAoJICAgIE1JUFNfQ1BVX1RMQiB8IE1JUFNfQ1BVXzRLRVggfCBNSVBT X0NQVV9GUFUgfCBNSVBTX0NQVV8zMkZQUiwgMzg0LAoJCXszMiwgNTEyLCAxLCBNSVBTX0NBQ0hF X1ZJUlRVQUx9LCB7MzIsIDUxMiwgMSwgMH0sCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09O RklHfSwgezAsMCwwLDB9fSwKCS8qIFIxMDAwMCAqLwoJeyBQUklEX0lNUF9SMTAwMDAsIENQVV9S MTAwMDAsIE1JUFNfQ1BVX0lTQV9JViwgCgkgICAgTUlQU19DUFVfVExCIHwgTUlQU19DUFVfNEtF WCB8IE1JUFNfQ1BVX0ZQVSAKCSAgICB8IE1JUFNfQ1BVXzMyRlBSIHwgTUlQU19DUFVfQ09VTlRF UiB8IE1JUFNfQ1BVX1dBVENILCA2NCwKCQl7MzIsIDUxMiwgMiwgMH0sIHszMiwgNTEyLCAyLCAw fSwgCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCwwLDB9fSwKfTsKCi8q CiAqIFRoaXMgZnVuY3Rpb24gaXMgcnVubmluZyBvbiB0aGUgYm9vdCBwcm9tIHN0YWNrLiBJdCBz aG91bGQKICogbWluaW1pemUgdXNlIG9mIGR5bmFtaWMgdmFyaWFibGVzIGFuZCBjYWxsIGFuIGFi c29sdXRlCiAqIG1pbmltdW0gb2Ygb3RoZXIgZnVuY3Rpb25zLgogKi8KCl9faW5pdGZ1bmModm9p ZCBtaXBzX2NwdV9wcm9iZSh1bnNpZ25lZCBpbnQgcHJfaWQpKQp7CglpbnQgaTsKCiNpZmRlZiBD T05GSUdfQ1BVX01JUFMzMgoJLyoKCSAqIElmIGhpZ2gtb3JkZXIgaGFsZndvcmQgbm9uLXplcm8s IHVzZSBNSVBTMzIgbWVjaGFuaXNtCgkgKi8KCWlmKChwcl9pZCA+PiAxNikgIT0gMCkgewoJCW1p cHMzMl9jcHVfcHJvYmUocHJfaWQpOwoJCXJldHVybjsKCX0KI2VuZGlmCgoJLyoKCSAqIElmIG9s ZCBlbmNvZGluZyBzY2hlbWUgYW5kIENQVSBpbiB0YWJsZSwgZmluZCBhbmQgY29weS4KCSAqCgkg KiBGaXJzdCB0cnkgZm9yIG1hdGNoIGluY2x1ZGluZyByZXZpc2lvbiBudW1iZXIKCSAqLwoKCWZv cihpPTA7IG1pcHNfY3B1X3RlbXBsYXRlW2ldLnByb2Nlc3Nvcl9pZCAhPSAwOyBpKyspIHsKCQlp ZihtaXBzX2NwdV90ZW1wbGF0ZVtpXS5wcm9jZXNzb3JfaWQgPT0gcHJfaWQpIHsKCQkJbWVtY3B5 KCZtaXBzX2NwdSwgJm1pcHNfY3B1X3RlbXBsYXRlW2ldLAoJCQkJc2l6ZW9mKHN0cnVjdCBtaXBz X2NwdSkpOwoJCQlyZXR1cm47CgkJfQoJfQoKCS8qCgkgKiBUaGF0IGZhaWxpbmcsIGxvb2sgZm9y IG1hdGNoIG9uIGltcGxlbWVudGF0aW9uIG9ubHkKCSAqLwoKCWZvcihpPTA7IG1pcHNfY3B1X3Rl bXBsYXRlW2ldLnByb2Nlc3Nvcl9pZCAhPSAwOyBpKyspIHsKCQlpZigobWlwc19jcHVfdGVtcGxh dGVbaV0ucHJvY2Vzc29yX2lkICYgUFJJRF9JTVBfVU5LTk9XTikKCQkgICAgPT0gKHByX2lkICYg UFJJRF9JTVBfVU5LTk9XTikpIHsKCQkJbWVtY3B5KCZtaXBzX2NwdSwgJm1pcHNfY3B1X3RlbXBs YXRlW2ldLAoJCQkJc2l6ZW9mKHN0cnVjdCBtaXBzX2NwdSkpOwoJCQlyZXR1cm47CgkJfQoJfQoK CS8qCgkgKiBPdGhlcndpc2UgQ1BVIGlzIHVua25vd24gLSBhbGwgYmV0cyBhcmUgb2ZmCgkgKi8K CgltaXBzX2NwdS5wcm9jZXNzb3JfaWQgPSBwcl9pZDsKCW1pcHNfY3B1LmNwdXR5cGUgPSBDUFVf VU5LTk9XTjsKCW1pcHNfY3B1Lm9wdGlvbnMgPSAwOwoJbWlwc19jcHUuaWNhY2hlLmZsYWdzID0g TUlQU19DQUNIRV9ORUVEU19DT05GSUc7CgltaXBzX2NwdS5kY2FjaGUuZmxhZ3MgPSBNSVBTX0NB Q0hFX05FRURTX0NPTkZJRzsKCW1pcHNfY3B1LnNjYWNoZS5mbGFncyA9IE1JUFNfQ0FDSEVfTkVF RFNfQ09ORklHOwoJcmV0dXJuOwp9Cgo= ------=_NextPart_000_0083_01BFFC6C.24323180-- From jsun@mvista.com Wed Aug 2 19:07:06 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA10930; Wed, 2 Aug 2000 19:07:01 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 19:07:01 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id KAA14494; Wed, 2 Aug 2000 10:05:58 -0700 Sender: jsun@hermes.mvista.com Message-ID: <398854F5.EB3E73D6@mvista.com> Date: Wed, 02 Aug 2000 10:05:57 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS References: <008601bffc5b$6714c0a0$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1736 Lines: 45 Kevin, This looks great, something exactly I was hoping for! A couple of questions : . What about the actual cache operation routines (flush_cache_page, ...)? Are they divided into R4xxx, R3xx, etc? I guess I am curious how the code is organized. . Your structure gives the number of ways, but no info about how to select a way. How would do an index-based cache operation? It seems to me you probably need something like cache_way_selection_offset in the cpu table. Jun "Kevin D. Kissell" wrote: > > Rather than re-invent the wheel, please consider the > cache descriptor data structures we developed at > MIPS to deal with this problem. I believe that the > updated cache.h file, and maybe even the cpu_probe.c > file, was checked into the 2.2 repository at SGI long ago. > There are also a set of initialisation and invalidation routines > that key off the cache descriptor structure, but those aren't > in the SGI repository (though anyone can get them from > ftp.mips.com or www.paralogos.com). The CPU probe > logic (also on those sites, and already integrated > into several variants because it also supports setting > up state needed by the software FPU emulation) > is table-based, and for each PrID value, there is > a template for the cache characteristics, which > can either be taken "as is" or probed, depending > on a flag in the descriptor. Since the number of > "ways" cannot always be determined by probing, > if the number of ways is specified, it is preserved > even if a cache probe is performed. I won't attach the > full set of cache probe routines (which would only confuse > things), but here is the cache data structure definition > and the CPU descriptor template table that we use. > ... From kevin@dallasartists.net Wed Aug 2 18:08:14 2000 Received: from dali.deadartists.com ([64.217.211.178]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA10538; Wed, 2 Aug 2000 18:08:13 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 18:08:13 +0200 (MET DST) Received: from gibbsk [208.164.89.210] by dali.deadartists.com (SMTPD32-6.00) id A4F26FB0068; Wed, 02 Aug 2000 11:14:10 -0700 Message-ID: <001f01bffcac$d9f8d100$544bfea9@ins.com> From: "KT Gibbs" To: Subject: Indy R5000 Date: Wed, 2 Aug 2000 11:09:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01BFFC72.214B0860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Length: 822 Lines: 27 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BFFC72.214B0860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I *really* want to dump IRIX, do I have a shot with Linux/MIPS? ------=_NextPart_000_001C_01BFFC72.214B0860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I *really* want to dump IRIX, do I have = a shot with=20 Linux/MIPS?
------=_NextPart_000_001C_01BFFC72.214B0860-- From dom@mudchute.algor.co.uk Wed Aug 2 20:12:50 2000 Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [193.117.190.25]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA11466; Wed, 2 Aug 2000 20:12:48 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 20:12:48 +0200 (MET DST) Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [193.117.190.19]) by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id TAA01458; Wed, 2 Aug 2000 19:12:38 +0100 (GMT/BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id TAA11550; Wed, 2 Aug 2000 19:12:34 +0100 (BST) Date: Wed, 2 Aug 2000 19:12:34 +0100 (BST) Message-Id: <200008021812.TAA11550@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun Sun Cc: linux@engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS In-Reply-To: <398762B9.D8507860@mvista.com> References: <398762B9.D8507860@mvista.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 1379 Lines: 33 Jun Sun (jsun@mvista.com) writes: > The first issue is multi-way cache support. DDB5476 uses R5432 CPU > which has two-way set-associative cache. The problematic part is > the index-based cache operations in r4xxcache.h does not cover all > ways in a set. > > I think this is a problem in general. So far I have seen MIPS > processors with 2-way, 4-way and 8-way sets. And I have seen them > using ether least- significant-addressing-bits or > most-significant-addressing-bits within a cache line to select ways. So far as I know the Vr5432 is the only CPU to do anything so silly as using the lowest index bits to select the "way". Certainly most CPUs put the "way" bits above the cache-store-index; and MIPS now require it to be done like that for MIPS32 and MIPS64 compatible parts. The MS-selects-way organisation permits the cache to be initialised without the software ever needing to know how many ways it has (just crank the index up, but being careful about the tendency to recycle the same way when pre-filling cache data). Cache maintenance should always use "hit" type instructions, and you don't need to know the cache organisation for those, even with the Vr5432. I suggest you should implement the don't-care method, and then have a cpu_info-driven special case for the unique and deprecated Vr5432. Dominic Sweetman Algorithmics Ltd dom@algor.co.uk From kevink@mips.com Wed Aug 2 20:13:54 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA11492; Wed, 2 Aug 2000 20:13:52 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 20:13:52 +0200 (MET DST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA03103; Wed, 2 Aug 2000 11:12:42 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA28193; Wed, 2 Aug 2000 11:12:42 -0700 (PDT) Message-ID: <01ac01bffcad$a767c240$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: , , Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS Date: Wed, 2 Aug 2000 20:15:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Length: 2347 Lines: 50 -->A couple of questions : > >. What about the actual cache operation routines (flush_cache_page, >...)? Are they divided into R4xxx, R3xx, etc? I guess I am curious how >the code is organized. We kept pretty much the existing 2.2 structure for these things. We created the module "r4k.c" in arch/mips/mm which was essentially parallel to the old r4xx0.c module, but which implemented the various TLB and cache functions (a) using the information in the mips_cpu structure wherever it made sense and (b) in ways that are fully compatible with the "MIPS32" ISA+CP0 model as well as with the original R4000 family and its descendants. It's possible to write code that is compatible with an R4000 but not MIPS32, and vice versa, but they are 99% identical. >. Your structure gives the number of ways, but no info about how to >select a way. How would do an index-based cache operation? It seems to >me you probably need something like cache_way_selection_offset in the >cpu table. The MIPS32 spec for the CACHE instruction gives a trivial mapping from sets/ways/linesize into CACHE instruction operands. In fact, the same technique works for most pre MIPS32 multi-way caches as well. The only exception that comes to mind is the R10000. If one wanted to support the R10K or other oddball CACHE-implementations in this system, I would suggest adding a MIPS_CACHE_R10KWAYSEL or some flag to the flags field of the cache descriptor, and tweaking any routines that need to select indices (such a routine to hunt down and kill all possible virtual aliases of an address) to handle the special case. The primitives in Linux 2.2 did not require much knowedge of multi-way caches as such - they could all be implemented either using hit-based CACHE operations, or by cycling through all possible indices using knowledge of the total size and the line size. But the newer synthesizable MIPS cores allow cache configurations to be "dialed in" in ways that the old code could not handle. The CPUs themselves can be interrogated to determine the line size/nways/nsets geometry, so we mirror that in the Linux code and use those parameters to compute total size, way size, etc. The PrID-based lookup table and the dynamic probe routines are there to allow older parts to use the same mechanisms. Regards, Kevin K. From kevink@mips.com Wed Aug 2 20:34:46 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA11757; Wed, 2 Aug 2000 20:34:45 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 20:34:45 +0200 (MET DST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA03354; Wed, 2 Aug 2000 11:33:34 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA29718; Wed, 2 Aug 2000 11:33:34 -0700 (PDT) Message-ID: <01c901bffcb0$922057a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Dominic Sweetman" , "Jun Sun" Cc: , , Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS Date: Wed, 2 Aug 2000 20:36:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Length: 1158 Lines: 31 Dom Sweetman writes: >So far as I know the Vr5432 is the only CPU to do anything so silly as >using the lowest index bits to select the "way". Alas, the R10000 does the same silly thing, and while you and I might not consider such a venerable processor interesting for new embedded MIPS/Linux designs, our friends who are trying to replace IRIX with Linux on their SGI boxes are going to have to deal with them for a little while longer. >The MS-selects-way organisation permits the cache to be initialised >without the software ever needing to know how many ways it has (just >crank the index up, but being careful about the tendency to recycle >the same way when pre-filling cache data). Which is why MIPS belatedly documented it as the "correct" way to design a multiway cache... >Cache maintenance should always use "hit" type instructions, and you >don't need to know the cache organisation for those, even with the >Vr5432. The counterargument to *always* using "hit" ops is that they generate TLB traffic and TLB refills, which some people find annoying to allow for and in any case time consuming. Regards, Kevin K. From jsun@mvista.com Wed Aug 2 23:41:08 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA13579; Wed, 2 Aug 2000 23:41:03 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 23:41:03 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA25892; Wed, 2 Aug 2000 14:38:52 -0700 Sender: jsun@hermes.mvista.com Message-ID: <398894EC.233BB004@mvista.com> Date: Wed, 02 Aug 2000 14:38:52 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Sweetman CC: linux@engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS References: <398762B9.D8507860@mvista.com> <200008021812.TAA11550@mudchute.algor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1305 Lines: 37 Dominic Sweetman wrote: > > Jun Sun (jsun@mvista.com) writes: > > > The first issue is multi-way cache support. DDB5476 uses R5432 CPU > > which has two-way set-associative cache. The problematic part is > > the index-based cache operations in r4xxcache.h does not cover all > > ways in a set. > > > > I think this is a problem in general. So far I have seen MIPS > > processors with 2-way, 4-way and 8-way sets. And I have seen them > > using ether least- significant-addressing-bits or > > most-significant-addressing-bits within a cache line to select ways. > > So far as I know the Vr5432 is the only CPU to do anything so silly as > using the lowest index bits to select the "way". Actually Sony's R4500 uses the same low bits mechanism. > Cache maintenance should always use "hit" type instructions, and you > don't need to know the cache organisation for those, even with the > Vr5432. > Ideally - but no in reality. Linux stills uses index-operations a lot. Theorically, indexed flush is faster if the flushing are is bigger than the cache size. > I suggest you should implement the don't-care method, and then have a > cpu_info-driven special case for the unique and deprecated Vr5432. > If Vr5432 is really that unique, I think that is probably best way, at least for now. Jun From jsun@mvista.com Wed Aug 2 23:51:30 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA14191; Wed, 2 Aug 2000 23:51:27 +0200 (MET DST) Received-Date: Wed, 2 Aug 2000 23:51:27 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA26491; Wed, 2 Aug 2000 14:50:19 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3988979B.D264F549@mvista.com> Date: Wed, 02 Aug 2000 14:50:19 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS References: <01ac01bffcad$a767c240$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 466 Lines: 18 "Kevin D. Kissell" wrote: > It's possible to write code that is compatible with an R4000 but > not MIPS32, and vice versa, but they are 99% identical. > Kevin, Is that possible you can list the 1% difference here? I have always been confused by MIPS32/MIPS64 vs R3000/R4000/etc. (And on top of it, there is also MIPS I, II, III, IV, etc...). I am sure I am not the only one. If you can give an pointer that will clarify names, that would be good too. Jun From kevink@mips.com Thu Aug 3 00:42:39 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA15661; Thu, 3 Aug 2000 00:42:37 +0200 (MET DST) Received-Date: Thu, 3 Aug 2000 00:42:37 +0200 (MET DST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA05710; Wed, 2 Aug 2000 15:41:27 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA06909; Wed, 2 Aug 2000 15:41:27 -0700 (PDT) Message-ID: <027f01bffcd3$3279b800$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" Cc: , , Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS Date: Thu, 3 Aug 2000 00:44:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Length: 3817 Lines: 84 >> It's possible to write code that is compatible with an R4000 but >> not MIPS32, and vice versa, but they are 99% identical. > >Is that possible you can list the 1% difference here? > >I have always been confused by MIPS32/MIPS64 vs R3000/R4000/etc. (And >on top of it, there is also MIPS I, II, III, IV, etc...). I am sure I >am not the only one. MIPS I, II, III, IV, and V are ISAs, instruction-set architectures. R3000, R4000, R5000, R6000, R7000, R8000 et. al. are microprocessor designs that conform (more-or-less) to one of those ISAs. The ISAs were defined in such a way as to be strict supersets of one another. Any MIPS processor can run MIPS I code. Any MIPS IV processor can run MIPS I, II, III, and IV code, etc. To oversimplify slightly: MIPS I - basic 32-bit RISC ISA MIPS II - add branch-likely and Test instructions MIPS III - add 64-bit address and 64-bit data support MIPS IV - add FP MAC, Prefetch MIPS V - add "paired single" SIMD FP instructions As defined by MIPS in the beginning, the ISA - i.e. MIPS I, MIPS II, etc. - described the machine as seen from the standpoint of a user-mode application program. The CP0 instructions and registers weren't considered a part of it. This gave chip designers a lot of freedom and OS writers a lot of headaches. The R8000, for example, was the first MIPS IV CPU, and is 100% (well, maybe 99.99%) compatible with the MIPS IV R10000 at the user binary level. But while the R10000 has a CP0 organization that is a straightforward extrapolation of the R4000 - they wanted it to run NT, after all - the R8000 is just bizzare. Another problem with the way things had been done in the MIPS I/II/III days was that, due to the strict supersetting rules, any new feature had to ride on the back of all the other cool new features that came before it. As a specific example, PREFetch is a MIPS IV instruction. But MIPS IV implies MIPS III, and MIPS III implies a 64-bit CPU. So a 32-bit CPU supporting prefetch, which is a fairly obviously useful thing, does not fit neatly into the model. So... When MIPS Technologies spun back out of SGI, one of the first things that was done was to set about defining standard architectures for 32 and 64-bit CPUs that solved these problems. These new standard architectures are "MIPS32" and "MIPS64". These architectures include both the ISA and the privileged resource architecture, or PRA, so that CP0 is finally standardised - with some amount of permitted subsetting and implementation-specific details allowed, just the same. The MIPS32 ISA includes features from MIPS I, II, III, IV, and V, as well as some stuff like integer MADD, MSUB, CLZ, and CLO that had never made it into the standard user mode ISA. But MIPS32 has no 64-bit operations. MIPS64 is the full-blown 64-bit MIPS I-V+ ISA plus a PRA that is a strict superset of the MIPS32 PRA. So, to get back to Linux, a MIPS32 part can *almost* run the standard MIPS R4K kernel. Almost. What had to be fixed was essentially: - ensuring that TLB initialization and invalidation never write identical (even though invalid) entries to the TLB. MIPS32 parts are allowed to complain about that, and some of them do. - ensuring that no 64-bit instructions are ever used. This necessitated my rewriting the semaphore support code. - eliminating certain assumptions about the relationship between cache size, line size, and associativity. Note that none of this stuff is incompatible with an R4xxx or an R5xxx, its just a matter of being a little more generic. And of course the flip side is that we don't use prefetch, MADD, or CLZ in the kernel either, because the MIPS III-IV parts can't handle them (well, OK, some of them can). Hope this helps, Keivn K. From jsun@mvista.com Thu Aug 3 01:12:25 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA17181; Thu, 3 Aug 2000 01:11:59 +0200 (MET DST) Received-Date: Thu, 3 Aug 2000 01:11:59 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id QAA30268; Wed, 2 Aug 2000 16:10:43 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3988AA72.5C342E1D@mvista.com> Date: Wed, 02 Aug 2000 16:10:43 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS References: <027f01bffcd3$3279b800$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 372 Lines: 15 That certainly helps a lot. Thanks, Kevin. "Kevin D. Kissell" wrote: ... > > So, to get back to Linux, a MIPS32 part can *almost* > run the standard MIPS R4K kernel. Almost. What had Still one more question. If I understand correctly, the 4Km and 4Kp are MIPS32 CPUs. However, they don't have TLBs. Right? Without TLBs, I don't suppose Linux will run ... Jun From ralf@oss.sgi.com Thu Aug 3 01:32:12 2000 Received: from u-100.karlsruhe.ipdial.viaginterkom.de (u-100.karlsruhe.ipdial.viaginterkom.de [62.180.19.100]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA17415; Thu, 3 Aug 2000 01:32:11 +0200 (MET DST) Received-Date: Thu, 3 Aug 2000 01:32:11 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 3 Aug 2000 01:31:55 +0200 Date: Thu, 3 Aug 2000 01:31:55 +0200 From: Ralf Baechle To: Jun Sun Cc: "Kevin D. Kissell" , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS Message-ID: <20000803013155.A2097@bacchus.dhis.org> References: <027f01bffcd3$3279b800$0deca8c0@Ulysses> <3988AA72.5C342E1D@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3988AA72.5C342E1D@mvista.com>; from jsun@mvista.com on Wed, Aug 02, 2000 at 04:10:43PM -0700 X-Accept-Language: de,en,fr Content-Length: 595 Lines: 15 On Wed, Aug 02, 2000 at 04:10:43PM -0700, Jun Sun wrote: > > So, to get back to Linux, a MIPS32 part can *almost* > > run the standard MIPS R4K kernel. Almost. What had > > Still one more question. If I understand correctly, the 4Km and 4Kp are > MIPS32 CPUs. However, they don't have TLBs. Right? Without TLBs, I > don't suppose Linux will run ... There is ``Microcontroller Linux'' aka uclinux available at www.uclinux.org. It could be ported to TLB-less processors. You'd loose some of the important functionality of the standard Linux, including some source compatibility. Ralf From flo@rfc822.org Wed Aug 9 01:03:55 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA04629; Wed, 9 Aug 2000 01:03:54 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 01:03:54 +0200 (MET DST) Received: by noose.gt.owl.de (Postfix, from userid 10) id 64ADF7F4; Sun, 6 Aug 2000 16:50:13 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 0C4D58FF5; Fri, 4 Aug 2000 20:56:08 +0200 (CEST) Date: Fri, 4 Aug 2000 20:56:08 +0200 From: Florian Lohoff To: Geert Uytterhoeven Cc: =?iso-8859-1?Q?=B1=E8=C7=D1=BC=BA?= , linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr Subject: Re: IGS5050 Driver Message-ID: <20000804205608.A313@paradigm.rfc822.org> References: <000001bff6fe$34021120$8d19ebcb@khs> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.0.1i In-Reply-To: ; from geert@linux-m68k.org on Thu, Jul 27, 2000 at 02:26:02PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 933 Lines: 21 On Thu, Jul 27, 2000 at 02:26:02PM +0200, Geert Uytterhoeven wrote: > On Wed, 26 Jul 2000, [ks_c_5601-1987] ｱ霽ﾑ?ｺ wrote: > > I want to know that there is a IGS5050 Grpahic chip driver for linux-mips. > > If yes, where is the driver files? > > linux/drivers/video/cyber2000fb.c is a driver for the IGS CyberPro 2000, 2010 > and 5000 in the NetWinder, which has an ARM CPU. If the 5050 is sufficient > compatible with the 5000 it should not be too difficult to get cyber2000fb to > work on the 5050 on the MIPS. When back from Canada i will start working on that beast - I have 100 SetTopBoxes with the 5000/5050 Combination (Video and Audio Controller). (These are x86 based) The IGS People seem to be quiet helpful - I mailed them concerning Documentation and got a LARGE pdf back for this Chip. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "If you're not having fun right now, you're wasting your time." From macro@ds2.pg.gda.pl Wed Aug 9 00:51:55 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA01775; Wed, 9 Aug 2000 00:51:52 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 00:51:52 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04367; Mon, 7 Aug 2000 17:22:54 +0200 (MET DST) Date: Mon, 7 Aug 2000 17:22:54 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: High resolution timer support for I/O ASIC DECstations Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 29309 Lines: 914 Hi, Following is a patch that implements a high resolution timer for I/O ASIC DECstations, i.e. it provides a do_fast_gettimeoffset() function that is suitable for R3K-based machines (that do not have a cycle counter within the CPU). Also a proper do_div() macro is included. There are also a few small cleanups and enhancements in the related code. This change makes my NTP daemon particularly happy -- a dispersion of 0.02 when synchronizing with a remote server is really nice. An X server would benefit, too, if we had one. I'd like to encourage everyone interested to test these changes as much as possible. Also if anyone knows of a better division algorithm than the one I used for do_div64_32(), I'd be glad to hear of it. If nothing wrong pops up, these changes should be included in the official tree, I believe. Comments are welcomed, as usually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/Makefile --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/Makefile Thu Jul 13 04:26:16 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/Makefile Sat Aug 5 17:45:33 2000 @@ -35,7 +35,7 @@ # machines may also. Since BFD is incredibly buggy with respect to # crossformat linking we rely on the elf2ecoff tool for format conversion. # -CFLAGS += -G 0 -mno-abicalls -fno-pic +GCCFLAGS := -G 0 -mno-abicalls -fno-pic LINKFLAGS += -static -G 0 MODFLAGS += -mlong-calls @@ -47,31 +47,40 @@ # CPU-dependent compiler/assembler options for optimization. # ifdef CONFIG_CPU_R3000 -CFLAGS := $(CFLAGS) -mcpu=r3000 -mips1 +GCCFLAGS += -mcpu=r3000 -mips1 endif ifdef CONFIG_CPU_R6000 -CFLAGS := $(CFLAGS) -mcpu=r6000 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r6000 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_R4300 -CFLAGS := $(CFLAGS) -mcpu=r4300 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r4300 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_R4X00 -CFLAGS := $(CFLAGS) -mcpu=r4600 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_R5000 -CFLAGS := $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r8000 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_NEVADA -CFLAGS := $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap -mmad +GCCFLAGS += -mcpu=r8000 -mips2 -Wa,--trap -mmad endif ifdef CONFIG_CPU_R8000 -CFLAGS := $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r8000 -mips2 -Wa,--trap endif ifdef CONFIG_CPU_R10000 -CFLAGS := $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap +GCCFLAGS += -mcpu=r8000 -mips2 -Wa,--trap endif # +# The pipe options is bad for my low-mem machine +# Uncomment this if you want this. +# +GCCFLAGS += -pipe + +CFLAGS += $(GCCFLAGS) +AFLAGS += $(GCCFLAGS) + +# # Board-dependent options and extra files # ifdef CONFIG_ALGOR_P4032 @@ -168,12 +177,6 @@ ifdef LOADADDR LINKFLAGS += -Ttext $(word 1,$(LOADADDR)) endif - -# -# The pipe options is bad for my low-mem machine -# Uncomment this if you want this. -# -CFLAGS += -pipe HEAD := arch/mips/kernel/head.o arch/mips/kernel/init_task.o diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/dec/Makefile --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/Makefile Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/Makefile Sat Aug 5 17:24:35 2000 @@ -7,9 +7,9 @@ # .S.s: - $(CPP) $(CFLAGS) $< -o $*.s + $(CPP) $(AFLAGS) -traditional -o $*.o $< .S.o: - $(CC) $(CFLAGS) -c $< -o $*.o + $(CC) $(AFLAGS) -traditional -c -o $*.o $< all: dec.o O_TARGET := dec.o diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/int-handler.S linux-mips-2.4.0-test5-20000731/arch/mips/dec/int-handler.S --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/int-handler.S Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/int-handler.S Sat Aug 5 15:31:37 2000 @@ -2,6 +2,7 @@ * arch/mips/dec/int-handler.S * * Copyright (C) 1995, 1996, 1997 Paul M. Antoine and Harald Koerfgen + * Copyright (C) 2000 Maciej W. Rozycki * * Written by Ralf Baechle and Andreas Busse, modified for DECStation * support by Paul Antoine and Harald Koerfgen. @@ -16,6 +17,11 @@ #include #include +#include +#include +#include +#include +#include #include @@ -164,10 +170,10 @@ /* * Handle "IRQ Controller" Interrupts * Masked Interrupts are still visible and have to be masked "by hand". - * %hi(KN02_CSR_ADDR) does not work so all addresses are hardcoded :-(. */ EXPORT(kn02_io_int) -kn02_io_int: lui t0,0xbff0 # get interrupt status and mask +kn02_io_int: # 3max + lui t0,KN02_CSR_ADDR>>16 # get interrupt status and mask lw t0,(t0) la t1,asic_mask_tbl move t3,t0 @@ -176,17 +182,20 @@ and t0,t3 # mask out allowed ones EXPORT(kn03_io_int) -kn03_io_int: lui t2,0xbf84 # upper part of IOASIC Address - lw t0,0x0110(t2) # get status: IOASIC isr - lw t3,0x0120(t2) # get mask: IOASIC isrm +kn03_io_int: # 3max+ + lui t2,KN03_IOASIC_BASE>>16 # upper part of IOASIC Address + lw t0,SIR(t2) # get status: IOASIC isr + lw t3,SIMR(t2) # get mask: IOASIC isrm la t1,asic_mask_tbl b find_int and t0,t3 # mask out allowed ones - EXPORT(kn02ba_io_int) -kn02ba_io_int: lui t2,0xbc04 - lw t0,0x0110(t2) # IOASIC isr, works for maxine also - lw t3,0x0120(t2) # IOASIC isrm + EXPORT(kn02xa_io_int) +kn02xa_io_int: # 3min/maxine + lui t2,KN02XA_IOASIC_BASE>>16 + # upper part of IOASIC Address + lw t0,SIR(t2) # get status: IOASIC isr + lw t3,SIMR(t2) # get mask: IOASIC isrm la t1,asic_mask_tbl and t0,t3 diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/irq.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/irq.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/irq.c Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/irq.c Sat Aug 5 18:40:27 2000 @@ -27,10 +27,6 @@ #include -extern volatile unsigned int *isr; /* address of the interrupt status register */ -extern volatile unsigned int *imr; /* address of the interrupt mask register */ -extern decint_t dec_interrupt[NR_INTS]; - irq_cpustat_t irq_stat [NR_CPUS]; unsigned int local_bh_count[NR_CPUS]; diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/setup.c Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/setup.c Sat Aug 5 18:49:00 2000 @@ -6,6 +6,7 @@ * for more details. * * Copyright (C) 1998 Harald Koerfgen + * Copyright (C) 2000 Maciej W. Rozycki */ #include #include @@ -22,6 +23,8 @@ #include #include #include +#include +#include #include extern asmlinkage void decstation_handle_int(void); @@ -33,14 +36,14 @@ void dec_init_kn02ca(void); void dec_init_kn03(void); -char *dec_rtc_base = (char *) KN01_RTC_BASE; /* Assume DS2100/3100 initially */ +char *dec_rtc_base = (void *) KN01_RTC_BASE; /* Assume DS2100/3100 initially */ + +volatile unsigned int *ioasic_base; decint_t dec_interrupt[NR_INTS]; -/* +/* * Information regarding the IRQ Controller - * - * isr and imr are also hardcoded for different machines in int_handler.S */ volatile unsigned int *isr = 0L; /* address of the interrupt status register */ @@ -206,8 +209,8 @@ * Setup some memory addresses. FIXME: probably incomplete! */ dec_rtc_base = (char *) KN02_RTC_BASE; - isr = (volatile unsigned int *) KN02_CSR_ADDR; - imr = (volatile unsigned int *) KN02_CSR_ADDR; + isr = (void *) KN02_CSR_ADDR; + imr = (void *) KN02_CSR_ADDR; /* * Setup IOASIC interrupt @@ -275,16 +278,17 @@ /* * Setup some memory addresses. */ + ioasic_base = (void *) KN02XA_IOASIC_BASE; dec_rtc_base = (char *) KN02XA_RTC_BASE; - isr = (volatile unsigned int *) KN02XA_SIR_ADDR; - imr = (volatile unsigned int *) KN02XA_SIRM_ADDR; + isr = (void *) KN02XA_IOASIC_REG(SIR); + imr = (void *) KN02XA_IOASIC_REG(SIMR); /* * Setup IOASIC interrupt */ cpu_mask_tbl[0] = IE_IRQ3; cpu_irq_nr[0] = -1; - cpu_ivec_tbl[0] = kn02ba_io_int; + cpu_ivec_tbl[0] = kn02xa_io_int; *imr = 0; /* @@ -355,14 +359,15 @@ /* * Setup some memory addresses. FIXME: probably incomplete! */ + ioasic_base = (void *) KN02XA_IOASIC_BASE; dec_rtc_base = (char *) KN02XA_RTC_BASE; - isr = (volatile unsigned int *) KN02XA_SIR_ADDR; - imr = (volatile unsigned int *) KN02XA_SIRM_ADDR; + isr = (void *) KN02XA_IOASIC_REG(SIR); + imr = (void *) KN02XA_IOASIC_REG(SIMR); /* * Setup IOASIC interrupt */ - cpu_ivec_tbl[1] = kn02ba_io_int; + cpu_ivec_tbl[1] = kn02xa_io_int; cpu_irq_nr[1] = -1; cpu_mask_tbl[1] = IE_IRQ3; *imr = 0; @@ -430,9 +435,10 @@ /* * Setup some memory addresses. FIXME: probably incomplete! */ + ioasic_base = (void *) KN03_IOASIC_BASE; dec_rtc_base = (char *) KN03_RTC_BASE; - isr = (volatile unsigned int *) KN03_SIR_ADDR; - imr = (volatile unsigned int *) KN03_SIRM_ADDR; + isr = (void *) KN03_IOASIC_REG(SIR); + imr = (void *) KN03_IOASIC_REG(SIMR); /* * Setup IOASIC interrupt diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c Wed Jul 12 04:25:56 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c Sat Aug 5 19:19:57 2000 @@ -1,8 +1,9 @@ /* - * linux/arch/mips/kernel/time.c + * linux/arch/mips/dec/time.c * * Copyright (C) 1991, 1992, 1995 Linus Torvalds + * Copyright (C) 2000 Maciej W. Rozycki * * This file contains the time handling details for PC-style clocks as * found in some MIPS systems. @@ -21,10 +22,15 @@ #include #include #include +#include +#include +#include #include #include +#include + extern volatile unsigned long wall_jiffies; extern rwlock_t xtime_lock; @@ -36,12 +42,22 @@ /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) +#define USECS_PER_JIFFY_FRAC (0x100000000*1000000/HZ&0xffffffff) /* Cycle counter value at the previous timer interrupt.. */ static unsigned int timerhi = 0, timerlo = 0; /* + * Cached "1/(clocks per usec)*2^32" value. + * It has to be recalculated once each jiffy. + */ +static unsigned long cached_quotient = 0; + +/* Last jiffy when do_fast_gettimeoffset() was called. */ +static unsigned long last_jiffies = 0; + +/* * On MIPS only R4000 and better have a cycle counter. * * FIXME: Does playing with the RP bit in c0_status interfere with this code? @@ -50,45 +66,34 @@ { u32 count; unsigned long res, tmp; - - /* Last jiffy when do_fast_gettimeoffset() was called. */ - static unsigned long last_jiffies = 0; unsigned long quotient; - /* - * Cached "1/(clocks per usec)*2^32" value. - * It has to be recalculated once each jiffy. - */ - static unsigned long cached_quotient = 0; - tmp = jiffies; quotient = cached_quotient; - if (tmp && last_jiffies != tmp) { - last_jiffies = tmp; - __asm__(".set\tnoreorder\n\t" - ".set\tnoat\n\t" - ".set\tmips3\n\t" - "lwu\t%0,%2\n\t" - "dsll32\t$1,%1,0\n\t" - "or\t$1,$1,%0\n\t" - "ddivu\t$0,$1,%3\n\t" - "mflo\t$1\n\t" - "dsll32\t%0,%4,0\n\t" - "nop\n\t" - "ddivu\t$0,%0,$1\n\t" - "mflo\t%0\n\t" - ".set\tmips0\n\t" - ".set\tat\n\t" - ".set\treorder" - :"=&r"(quotient) - :"r"(timerhi), - "m"(timerlo), - "r"(tmp), - "r"(USECS_PER_JIFFY) - :"$1"); + if (last_jiffies != tmp) { + last_jiffies = tmp; + if (last_jiffies != 0) { + unsigned long r0; + __asm__(".set push\n\t" + ".set mips3\n\t" + "lwu %0,%3\n\t" + "dsll32 %1,%2,0\n\t" + "or %1,%1,%0\n\t" + "ddivu $0,%1,%4\n\t" + "mflo %1\n\t" + "dsll32 %0,%5,0\n\t" + "or %0,%0,%6\n\t" + "ddivu $0,%0,%1\n\t" + "mflo %0\n\t" + ".set pop" + : "=&r" (quotient), "=&r" (r0) + : "r" (timerhi), "m" (timerlo), + "r" (tmp), "r" (USECS_PER_JIFFY), + "r" (USECS_PER_JIFFY_FRAC)); cached_quotient = quotient; + } } /* Get last timer tick in absolute kernel time */ count = read_32bit_cp0_register(CP0_COUNT); @@ -97,11 +102,9 @@ count -= timerlo; //printk("count: %08lx, %08lx:%08lx\n", count, timerhi, timerlo); - __asm__("multu\t%1,%2\n\t" - "mfhi\t%0" - :"=r"(res) - :"r"(count), - "r"(quotient)); + __asm__("multu %2,%3" + : "=l" (tmp), "=h" (res) + : "r" (count), "r" (quotient)); /* * Due to possible jiffies inconsistencies, we need to check @@ -113,6 +116,47 @@ return res; } +static unsigned long do_ioasic_gettimeoffset(void) +{ + u32 count; + unsigned long res, tmp; + unsigned long quotient; + + tmp = jiffies; + + quotient = cached_quotient; + + if (last_jiffies != tmp) { + last_jiffies = tmp; + if (last_jiffies != 0) { + unsigned long r0; + do_div64_32(r0, timerhi, timerlo, tmp); + do_div64_32(quotient, USECS_PER_JIFFY, + USECS_PER_JIFFY_FRAC, r0); + cached_quotient = quotient; + } + } + /* Get last timer tick in absolute kernel time */ + count = ioasic_read(FCTR); + + /* .. relative to previous jiffy (32 bits is enough) */ + count -= timerlo; +//printk("count: %08x, %08x:%08x\n", count, timerhi, timerlo); + + __asm__("multu %2,%3" + : "=l" (tmp), "=h" (res) + : "r" (count), "r" (quotient)); + + /* + * Due to possible jiffies inconsistencies, we need to check + * the result so that we'll get a timer that is monotonic. + */ + if (res >= USECS_PER_JIFFY) + res = USECS_PER_JIFFY - 1; + + return res; +} + /* This function must be called with interrupts disabled * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs * @@ -170,8 +214,8 @@ tv->tv_usec += do_gettimeoffset(); /* - * xtime is atomically updated in timer_bh. lost_ticks is - * nonzero if the timer bottom half hasnt executed yet. + * xtime is atomically updated in timer_bh. jiffies - wall_jiffies + * is nonzero if the timer bottom half hasnt executed yet. */ if (jiffies - wall_jiffies) tv->tv_usec += USECS_PER_JIFFY; @@ -309,11 +353,12 @@ read_lock(&xtime_lock); if (time_state != TIME_BAD && xtime.tv_sec > last_rtc_update + 660 && xtime.tv_usec > 500000 - (tick >> 1) && - xtime.tv_usec < 500000 + (tick >> 1)) + xtime.tv_usec < 500000 + (tick >> 1)) { if (set_rtc_mmss(xtime.tv_sec) == 0) last_rtc_update = xtime.tv_sec; else last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */ + } /* As we return to user mode fire off the other CPU schedulers.. this is basically because we don't yet share IRQ's around. This message is rigged to be safe on the 386 - basically it's a hack, so don't look @@ -334,16 +379,42 @@ timerhi += (count < timerlo); /* Wrap around */ timerlo = count; + if (jiffies == ~0) { + /* + * If jiffies is to overflow in this timer_interrupt we must + * update the timer[hi]/[lo] to make do_fast_gettimeoffset() + * quotient calc still valid. -arca + */ + write_32bit_cp0_register(CP0_COUNT, 0); + timerhi = timerlo = 0; + } + timer_interrupt(irq, dev_id, regs); +} + +static void ioasic_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs) +{ + unsigned int count; + + /* + * The free-running counter is 32 bit which is good for about + * 2 minutes, 50 seconds at possible count rates of upto 25MHz. + */ + count = ioasic_read(FCTR); + timerhi += (count < timerlo); /* Wrap around */ + timerlo = count; - if (!jiffies) { + if (jiffies == ~0) { /* - * If jiffies has overflowed in this timer_interrupt we must + * If jiffies is to overflow in this timer_interrupt we must * update the timer[hi]/[lo] to make do_fast_gettimeoffset() * quotient calc still valid. -arca */ + ioasic_write(FCTR, 0); timerhi = timerlo = 0; } + + timer_interrupt(irq, dev_id, regs); } /* Converts Gregorian date to seconds since 1970-01-01 00:00:00. @@ -473,6 +544,10 @@ write_32bit_cp0_register(CP0_COUNT, 0); do_gettimeoffset = do_fast_gettimeoffset; irq0.handler = r4k_timer_interrupt; - } + } else if (IOASIC) { + ioasic_write(FCTR, 0); + do_gettimeoffset = do_ioasic_gettimeoffset; + irq0.handler = ioasic_timer_interrupt; + } board_time_init(&irq0); } diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/addrspace.h linux-mips-2.4.0-test5-20000731/include/asm-mips/addrspace.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/addrspace.h Tue Mar 28 04:27:19 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/addrspace.h Sat Aug 5 18:04:53 2000 @@ -4,6 +4,7 @@ * for more details. * * Copyright (C) 1996 by Ralf Baechle + * Copyright (C) 2000 by Maciej W. Rozycki * * Defitions for the address spaces of the MIPS CPUs. */ @@ -22,20 +23,35 @@ /* * Returns the kernel segment base of a given address */ +#ifndef __ASSEMBLY__ #define KSEGX(a) (((unsigned long)(a)) & 0xe0000000) +#else +#define KSEGX(a) ((a) & 0xe0000000) +#endif /* * Returns the physical address of a KSEG0/KSEG1 address */ +#ifndef __ASSEMBLY__ #define PHYSADDR(a) (((unsigned long)(a)) & 0x1fffffff) +#else +#define PHYSADDR(a) ((a) & 0x1fffffff) +#endif /* * Map an address to a certain kernel segment */ +#ifndef __ASSEMBLY__ #define KSEG0ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG0)) #define KSEG1ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG1)) #define KSEG2ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG2)) #define KSEG3ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG3)) +#else +#define KSEG0ADDR(a) (((a) & 0x1fffffff) | KSEG0) +#define KSEG1ADDR(a) (((a) & 0x1fffffff) | KSEG1) +#define KSEG2ADDR(a) (((a) & 0x1fffffff) | KSEG2) +#define KSEG3ADDR(a) (((a) & 0x1fffffff) | KSEG3) +#endif /* * Memory segments (64bit kernel mode addresses) diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/interrupts.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/interrupts.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/interrupts.h Tue Mar 28 04:27:23 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/interrupts.h Sat Aug 5 19:25:54 2000 @@ -36,7 +36,7 @@ #define NR_INTS 11 -#ifndef _LANGUAGE_ASSEMBLY +#ifndef __ASSEMBLY__ /* * Data structure to hide the differences between the DECstation Interrupts * @@ -50,6 +50,12 @@ unsigned int iemask; /* enabling interrupts in IRQ Controller */ } decint_t; +extern volatile unsigned int *isr; + /* address of the interrupt status register */ +extern volatile unsigned int *imr; + /* address of the interrupt mask register */ +extern decint_t dec_interrupt[NR_INTS]; + /* * Interrupt table structure to hide differences between different * systems such. @@ -68,7 +74,7 @@ extern void dec_intr_rtc(void); extern void kn02_io_int(void); -extern void kn02ba_io_int(void); +extern void kn02xa_io_int(void); extern void kn03_io_int(void); extern void intr_halt(void); diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic.h Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic.h Sat Aug 5 17:07:15 2000 @@ -0,0 +1,24 @@ +/* + * linux/asm-mips/dec/ioasic.h + * + * Copyright (C) 2000 Maciej W. Rozycki + * + * DEC I/O ASIC access operations. + */ + +#ifndef __ASM_DEC_IOASIC_H +#define __ASM_DEC_IOASIC_H + +extern volatile unsigned int *ioasic_base; + +extern inline void ioasic_write(unsigned int reg, unsigned int v) +{ + ioasic_base[reg / 4] = v; +} + +extern inline unsigned int ioasic_read(unsigned int reg) +{ + return ioasic_base[reg / 4]; +} + +#endif /* __ASM_DEC_IOASIC_H */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic_addrs.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic_addrs.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic_addrs.h Tue Mar 28 04:27:23 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic_addrs.h Sat Aug 5 14:48:14 2000 @@ -17,25 +17,25 @@ #define CHUNK_SIZE 0x00040000 -#define SYSTEM_ROM 00*CHUNK_SIZE /* ??? */ -#define IOCTL 01*CHUNK_SIZE -#define ESAR 02*CHUNK_SIZE -#define LANCE 03*CHUNK_SIZE -#define SCC0 04*CHUNK_SIZE -#define VDAC_HI 05*CHUNK_SIZE /* maxine only */ -#define SCC1 06*CHUNK_SIZE -#define VDAC_LO 07*CHUNK_SIZE /* maxine only */ -#define TOY 08*CHUNK_SIZE -#define ISDN 09*CHUNK_SIZE /* maxine only */ -#define ERRADDR 09*CHUNK_SIZE /* 3maxplus only */ -#define CHKSYN 10*CHUNK_SIZE /* 3maxplus only */ -#define ACCESS_BUS 10*CHUNK_SIZE /* maxine only */ -#define MCR 11*CHUNK_SIZE /* 3maxplus only */ -#define FLOPPY 11*CHUNK_SIZE /* maxine only */ -#define SCSI 12*CHUNK_SIZE -#define FLOPPY_DMA 13*CHUNK_SIZE /* maxine only */ -#define SCSI_DMA 14*CHUNK_SIZE -#define RESERVED_4 15*CHUNK_SIZE +#define SYSTEM_ROM (00*CHUNK_SIZE) /* ??? */ +#define IOCTL (01*CHUNK_SIZE) +#define ESAR (02*CHUNK_SIZE) +#define LANCE (03*CHUNK_SIZE) +#define SCC0 (04*CHUNK_SIZE) +#define VDAC_HI (05*CHUNK_SIZE) /* maxine only */ +#define SCC1 (06*CHUNK_SIZE) +#define VDAC_LO (07*CHUNK_SIZE) /* maxine only */ +#define TOY (08*CHUNK_SIZE) +#define ISDN (09*CHUNK_SIZE) /* maxine only */ +#define ERRADDR (09*CHUNK_SIZE) /* 3maxplus only */ +#define CHKSYN (10*CHUNK_SIZE) /* 3maxplus only */ +#define ACCESS_BUS (10*CHUNK_SIZE) /* maxine only */ +#define MCR (11*CHUNK_SIZE) /* 3maxplus only */ +#define FLOPPY (11*CHUNK_SIZE) /* maxine only */ +#define SCSI (12*CHUNK_SIZE) +#define FLOPPY_DMA (13*CHUNK_SIZE) /* maxine only */ +#define SCSI_DMA (14*CHUNK_SIZE) +#define RESERVED_4 (15*CHUNK_SIZE) /* * Offsets for IOCTL registers (relative to (system_base + IOCTL)) @@ -56,6 +56,7 @@ #define SSR 0x100 /* System Support Register */ #define SIR 0x110 /* System Interrupt Register */ #define SIMR 0x120 /* System Interrupt Mask Register */ +#define FCTR 0x1e0 /* Free-Running Counter */ /* * Handle partial word SCSI DMA transfers diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn02xa.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn02xa.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn02xa.h Tue Mar 28 04:27:23 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn02xa.h Sat Aug 5 15:35:24 2000 @@ -9,6 +9,7 @@ * * Copyright (C) 1995,1996 by Paul M. Antoine, some code and definitions * are by curteousy of Chris Fraser. + * Copyright (C) 2000 Maciej W. Rozycki * * These are addresses which have to be known early in the boot process. * For other addresses refer to tc.h ioasic_addrs.h and friends. @@ -19,16 +20,12 @@ #include /* - * Motherboard regs (kseg1 addresses) - */ -#define KN02XA_SSR_ADDR KSEG1ADDR(0x1c040100) /* system control & status reg */ -#define KN02XA_SIR_ADDR KSEG1ADDR(0x1c040110) /* system interrupt reg */ -#define KN02XA_SIRM_ADDR KSEG1ADDR(0x1c040120) /* system interrupt mask reg */ - -/* * Some port addresses... * FIXME: these addresses are incomplete and need tidying up! */ -#define KN02XA_RTC_BASE (KSEG1ADDR(0x1c000000 + 0x200000)) /* ASIC + SL8 */ +#define KN02XA_IOASIC_BASE KSEG1ADDR(0x1c040000) /* I/O ASIC */ +#define KN02XA_RTC_BASE KSEG1ADDR(0x1e000000) /* RTC */ + +#define KN02XA_IOASIC_REG(r) (KN02XA_IOASIC_BASE+(r)) #endif /* __ASM_MIPS_DEC_KN02XA_H */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn03.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn03.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn03.h Tue Mar 28 04:27:23 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn03.h Sat Aug 5 15:35:31 2000 @@ -8,6 +8,7 @@ * * Copyright (C) 1995,1996 by Paul M. Antoine, some code and definitions * are by curteousy of Chris Fraser. + * Copyright (C) 2000 Maciej W. Rozycki * * These are addresses which have to be known early in the boot process. * For other addresses refer to tc.h ioasic_addrs.h and friends. @@ -18,16 +19,12 @@ #include /* - * Motherboard regs (kseg1 addresses) - */ -#define KN03_SSR_ADDR KSEG1ADDR(0x1f840100) /* system control & status reg */ -#define KN03_SIR_ADDR KSEG1ADDR(0x1f840110) /* system interrupt reg */ -#define KN03_SIRM_ADDR KSEG1ADDR(0x1f840120) /* system interrupt mask reg */ - -/* * Some port addresses... * FIXME: these addresses are incomplete and need tidying up! */ -#define KN03_RTC_BASE (KSEG1ADDR(0x1f800000 + 0x200000)) /* ASIC + SL8 */ +#define KN03_IOASIC_BASE KSEG1ADDR(0x1f840000) /* I/O ASIC */ +#define KN03_RTC_BASE KSEG1ADDR(0x1fa00000) /* RTC */ + +#define KN03_IOASIC_REG(r) (KN03_IOASIC_BASE+(r)) #endif /* __ASM_MIPS_DEC_KN03_H */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/div64.h linux-mips-2.4.0-test5-20000731/include/asm-mips/div64.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/div64.h Tue Mar 28 04:27:19 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/div64.h Sun Aug 6 05:22:36 2000 @@ -1,4 +1,7 @@ -/* $Id: div64.h,v 1.1 2000/01/28 23:18:43 ralf Exp $ +/* + * include/asm-mips/div64.h + * + * Copyright (C) 2000 Maciej W. Rozycki * * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive @@ -7,14 +10,104 @@ #ifndef _ASM_DIV64_H #define _ASM_DIV64_H +#include + /* - * Hey, we're already 64-bit, no - * need to play games.. + * No traps on overflows for any of these... */ -#define do_div(n,base) ({ \ - int __res; \ - __res = ((unsigned long) n) % (unsigned) base; \ - n = ((unsigned long) n) / (unsigned) base; \ - __res; }) + +#if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2) + +#define do_div64_32(res, high, low, base) ({ \ + unsigned long __quot, __mod; \ + unsigned long __cf, __tmp, __i; \ + \ + __asm__(".set push\n\t" \ + ".set noat\n\t" \ + ".set noreorder\n\t" \ + "b 1f\n\t" \ + " li %4,0x21\n" \ + "0:\n\t" \ + "sll $1,%0,0x1\n\t" \ + "srl %3,%0,0x1f\n\t" \ + "or %0,$1,$2\n\t" \ + "sll %1,%1,0x1\n\t" \ + "sll %2,%2,0x1\n" \ + "1:\n\t" \ + "bnez %3,2f\n\t" \ + "sltu $2,%0,%z5\n\t" \ + "bnez $2,3f\n\t" \ + "2:\n\t" \ + " addiu %4,%4,-1\n\t" \ + "subu %0,%0,%z5\n\t" \ + "addiu %2,%2,1\n" \ + "3:\n\t" \ + "bnez %4,0b\n\t" \ + " srl $2,%1,0x1f\n\t" \ + ".set pop" \ + : "=&r" (__mod), "=&r" (__tmp), "=&r" (__quot), "=&r" (__cf), \ + "=&r" (__i) \ + : "Jr" (base), "0" (high), "1" (low), "2" (0), "3" (0) \ + /* Aarrgh! Ran out of gcc's limit on constraints... */ \ + : "$1", "$2"); \ + \ + (res) = __quot; \ + __mod; }) + +#define do_div(n, base) ({ \ + unsigned long long __quot; \ + unsigned long __upper, __low, __high, __mod; \ + \ + __quot = (n); \ + __high = __quot >> 32; \ + __low = __quot; \ + __upper = __high; \ + \ + if (__high) \ + __asm__("divu $0,%z2,%z3" \ + : "=h" (__upper), "=l" (__high) \ + : "Jr" (__high), "Jr" (base)); \ + \ + __mod = do_div64_32(__low, __upper, __low, base); \ + \ + __quot = __high; \ + __quot = __quot << 32 | __low; \ + (n) = __quot; \ + __mod; }) + +#else + +#define do_div64_32(res, high, low, base) ({ \ + unsigned long __quot, __mod, __r0; \ + \ + __asm__("dsll32 %2,%z3,0\n\t" \ + "or %2,%2,%z4\n\t" \ + "ddivu $0,%2,%z5" \ + : "=h" (__mod), "=l" (__quot), "=&r" (__r0) \ + : "Jr" (high), "Jr" (low), "Jr" (base)); \ + \ + (res) = __quot; \ + __mod; }) + +#define do_div(n, base) ({ \ + unsigned long long __quot; \ + unsigned long __mod, __r0; \ + \ + __quot = (n); \ + \ + __asm__("dsll32 %2,%M3,0\n\t" \ + "or %2,%2,%L3\n\t" \ + "ddivu $0,%2,%z4\n\t" \ + "mflo %L1\n\t" \ + "dsra32 %M1,%L1,0\n\t" \ + "dsll32 %L1,%L1,0\n\t" \ + "dsra32 %L1,%L1,0" \ + : "=h" (__mod), "=r" (__quot), "=&r" (__r0) \ + : "r" (n), "Jr" (base)); \ + \ + (n) = __quot; \ + __mod; }) + +#endif #endif /* _ASM_DIV64_H */ From macro@ds2.pg.gda.pl Wed Aug 9 00:51:48 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA01753; Wed, 9 Aug 2000 00:51:32 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 00:51:32 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04707; Mon, 7 Aug 2000 17:47:37 +0200 (MET DST) Date: Mon, 7 Aug 2000 17:47:36 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: A workaround to DEC's RTC year weirdness Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 6576 Lines: 202 Hi, Following is a patch that is an ultimate attempt to make the RTC's year work for DECstations. It uses an extra BBU RAM's location to store the real year and the original year is used only as a reference, to make incrementing work. Changes address the handling of leap years, too. The two only drawbacks of the patch are as follows: - there has to be at least a single RTC update during a year, as that's the only situation the real year gets written into the BBU RAM, - if a machine is powered down long enough the firmware decides to reset contents the RTC, there is no other way to recover than to set time again. I've tested various dates on my machine and the changes proved to work. The current implementation is expected to work until 2255 -- at about 220, we'll have to change our epoch. The changes involved are not transparent, though. I've used the last BBU RAM's location that appears to be unused on my 3max+ (it's apparently true for the preceding one, too). The firmware wouldn't change either of bytes no matter what I invoked (the "d" command excluded, of course) and what I wrote into them. I couldn't test Ultrix and OSF/1 interoperability though. Neither could I test other machines. There appears to be some uncertainity on years permitted by the firmware, too. The original code quoted 70, 71 and 72 are permitted. My system permits 72 and 73 and also the original setting of the epoch suggests it is true. Therefore I strongly encourage everyone interested to test the code as much as possible. Apart from interoperability issues, changes are rather straightforward. Comments are welcomed, as usual. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c Wed Jul 12 04:25:56 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c Sun Aug 6 14:24:55 2000 @@ -424,7 +424,7 @@ void __init time_init(void) { - unsigned int year, mon, day, hour, min, sec; + unsigned int year, mon, day, hour, min, sec, real_year; int i; /* The Linux interpretation of the CMOS clock register contents: @@ -457,10 +457,12 @@ } /* * The DECstation RTC is used as a TOY (Time Of Year). - * The PROM will reset the year to either '70, '71 or '72. - * This hack will only work until Dec 31 2001. + * The PROM will reset the year to either '72 or '73. + * Therefore we store the real year separately, in one + * of unused BBU RAM locations. */ - year += 1928; + real_year = CMOS_READ(RTC_DEC_YEAR); + year += real_year - 72 + 2000; write_lock_irq(&xtime_lock); xtime.tv_sec = mktime(year, mon, day, hour, min, sec); diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/rtc.c linux-mips-2.4.0-test5-20000731/drivers/char/rtc.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/char/rtc.c Mon Jul 24 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/char/rtc.c Sun Aug 6 14:22:34 2000 @@ -39,9 +39,10 @@ * 1.10a Andrea Arcangeli: Alpha updates * 1.10b Andrew Morton: SMP lock fix * 1.10c Cesar Barros: SMP locking fixes and cleanup + * 1.10d Maciej W. Rozycki: Handle DECstation's year weirdness. */ -#define RTC_VERSION "1.10c" +#define RTC_VERSION "1.10d" #define RTC_IO_EXTENT 0x10 /* Only really two ports, but... */ @@ -366,6 +367,9 @@ unsigned char mon, day, hrs, min, sec, leap_yr; unsigned char save_control, save_freq_select; unsigned int yrs; +#ifdef CONFIG_DECSTATION + unsigned int real_yrs; +#endif if (!capable(CAP_SYS_TIME)) return -EACCES; @@ -399,6 +403,20 @@ return -EINVAL; spin_lock_irq(&rtc_lock); +#ifdef CONFIG_DECSTATION + real_yrs = yrs; + yrs = 72; + + /* + * We want to keep the year set to 73 until March + * for non-leap years, so that Feb, 29th is handled + * correctly. + */ + if (!leap_yr && mon < 3) { + real_yrs--; + yrs = 73; + } +#endif if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY) || RTC_ALWAYS_BCD) { if (yrs > 169) { @@ -421,6 +439,9 @@ save_freq_select = CMOS_READ(RTC_FREQ_SELECT); CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); +#ifdef CONFIG_DECSTATION + CMOS_WRITE(real_yrs, RTC_DEC_YEAR); +#endif CMOS_WRITE(yrs, RTC_YEAR); CMOS_WRITE(mon, RTC_MONTH); CMOS_WRITE(day, RTC_DAY_OF_MONTH); @@ -474,7 +495,7 @@ spin_unlock_irq(&rtc_lock); return 0; } -#elif !defined(CONFIG_DECSTATION) +#endif case RTC_EPOCH_READ: /* Read the epoch. */ { return put_user (epoch, (unsigned long *)arg); @@ -493,7 +514,6 @@ epoch = arg; return 0; } -#endif default: return -EINVAL; } @@ -696,11 +716,11 @@ if (year > 20 && year < 48) { epoch = 1980; guess = "ARC console"; - } else if (year >= 48 && year < 70) { + } else if (year >= 48 && year < 72) { epoch = 1952; guess = "Digital UNIX"; - } else if (year >= 70 && year < 100) { - epoch = 1928; + } else if (year >= 72 && year < 74) { + epoch = 2000; guess = "Digital DECstation"; } if (guess) @@ -904,6 +924,9 @@ { unsigned long uip_watchdog = jiffies; unsigned char ctrl; +#ifdef CONFIG_DECSTATION + unsigned int real_year; +#endif /* * read RTC once any update in progress is done. The update @@ -932,6 +955,9 @@ rtc_tm->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH); rtc_tm->tm_mon = CMOS_READ(RTC_MONTH); rtc_tm->tm_year = CMOS_READ(RTC_YEAR); +#ifdef CONFIG_DECSTATION + real_year = CMOS_READ(RTC_DEC_YEAR); +#endif ctrl = CMOS_READ(RTC_CONTROL); spin_unlock_irq(&rtc_lock); @@ -944,6 +970,10 @@ BCD_TO_BIN(rtc_tm->tm_mon); BCD_TO_BIN(rtc_tm->tm_year); } + +#ifdef CONFIG_DECSTATION + rtc_tm->tm_year += real_year - 72; +#endif /* * Account for differences between how the RTC uses the values diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/mc146818rtc.h linux-mips-2.4.0-test5-20000731/include/asm-mips/mc146818rtc.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/mc146818rtc.h Wed Aug 2 06:29:06 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/mc146818rtc.h Sat Aug 5 08:19:07 2000 @@ -48,4 +48,8 @@ #define RTC_IRQ 8 #endif +#ifdef CONFIG_DECSTATION +#define RTC_DEC_YEAR 0x3f /* Where we store the real year on DECs. */ +#endif + #endif /* _ASM_MC146818RTC_H */ From macro@ds2.pg.gda.pl Wed Aug 9 00:51:51 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA01764; Wed, 9 Aug 2000 00:51:49 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 00:51:49 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04813; Mon, 7 Aug 2000 17:56:52 +0200 (MET DST) Date: Mon, 7 Aug 2000 17:56:52 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: BREAK and magic SysRq handling for Z8530 Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 8402 Lines: 267 Hi, It appears our current Z8530 driver lacks BREAK support. It also has the unfortunate side effect magic SysRq wouldn't work either, if we had it. Not anymore! The following patch adds both features to our Z8530 driver. It also allows the magic SysRq hack to be compiled-in (i.e. no more linking errors) even if no virtual terminal driver is build, which is suitable for certain configurations, including mine. Comments are welcomed, as usually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/keyboard.c linux-mips-2.4.0-test5-20000731/drivers/char/keyboard.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/char/keyboard.c Thu Feb 24 05:26:36 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/char/keyboard.c Sun Aug 6 09:15:46 2000 @@ -158,7 +158,6 @@ #ifdef CONFIG_MAGIC_SYSRQ static int sysrq_pressed; -int sysrq_enabled = 1; #endif static struct pm_dev *pm_kbd = NULL; diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/serial.c linux-mips-2.4.0-test5-20000731/drivers/char/serial.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/char/serial.c Mon Jul 24 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/char/serial.c Sun Aug 6 09:21:03 2000 @@ -597,7 +597,8 @@ printk("handling break...."); #endif #if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE) - if (info->line == sercons.index) { + if (info->line == sercons.index + && sysrq_enabled) { if (!break_pressed) { break_pressed = jiffies; goto ignore_char; diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/sysrq.c linux-mips-2.4.0-test5-20000731/drivers/char/sysrq.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/char/sysrq.c Tue Mar 28 04:26:29 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/char/sysrq.c Sun Aug 6 09:17:58 2000 @@ -33,6 +33,8 @@ /* Machine specific power off function */ void (*sysrq_power_off)(void) = NULL; +int sysrq_enabled = 1; + EXPORT_SYMBOL(sysrq_power_off); /* Send a signal to all user processes */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/sbus/char/sunkbd.c linux-mips-2.4.0-test5-20000731/drivers/sbus/char/sunkbd.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/sbus/char/sunkbd.c Sat Jul 15 04:26:34 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/sbus/char/sunkbd.c Sun Aug 6 09:16:21 2000 @@ -177,9 +177,6 @@ static struct pt_regs * pt_regs; #ifdef CONFIG_MAGIC_SYSRQ -#ifndef CONFIG_PCI -int sysrq_enabled = 1; -#endif unsigned char sun_sysrq_xlate[128] = "\0\0\0\0\0\201\202\212\203\213\204\214\205\0\206\0" /* 0x00 - 0x0f */ "\207\210\211\0\0\0\0\0\0\0\0\0\0\03312" /* 0x10 - 0x1f */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/tc/zs.c linux-mips-2.4.0-test5-20000731/drivers/tc/zs.c --- linux-mips-2.4.0-test5-20000731.macro/drivers/tc/zs.c Sat Jul 8 04:26:53 2000 +++ linux-mips-2.4.0-test5-20000731/drivers/tc/zs.c Sun Aug 6 13:34:43 2000 @@ -6,6 +6,7 @@ * * DECstation changes * Copyright (C) 1998 Harald Koerfgen (Harald.Koerfgen@home.ivm.de) + * Copyright (C) 2000 Maciej W. Rozycki (macro@ds2.pg.gda.pl) * * For the rest of the code the original Copyright applies: * Copyright (C) 1996 Paul Mackerras (Paul.Mackerras@cs.anu.edu.au) @@ -50,6 +51,9 @@ #ifdef CONFIG_KGDB #include #endif +#ifdef CONFIG_MAGIC_SYSRQ +#include +#endif #include "zs.h" @@ -75,6 +79,10 @@ #ifdef CONFIG_SERIAL_CONSOLE static struct console sercons; #endif +#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) \ + && !defined(MODULE) +static unsigned long break_pressed; /* break, really ... */ +#endif #ifdef CONFIG_KGDB struct dec_zschannel *zs_kgdbchan; @@ -302,6 +310,8 @@ * ----------------------------------------------------------------------- */ +static int tty_break; /* Set whenever BREAK condition is detected. */ + /* * This routine is used by the interrupt handler to schedule * processing in the software interrupt portion of the driver. @@ -320,7 +330,7 @@ struct tty_struct *tty = info->tty; unsigned char ch, stat, flag; - while ((read_zsreg(info->zs_channel, 0) & Rx_CH_AV) != 0) { + while ((read_zsreg(info->zs_channel, R0) & Rx_CH_AV) != 0) { stat = read_zsreg(info->zs_channel, R1); ch = read_zsdata(info->zs_channel); @@ -330,13 +340,53 @@ if (ch == 0x03 || ch == '$') breakpoint(); if (stat & (Rx_OVR|FRM_ERR|PAR_ERR)) - write_zsreg(info->zs_channel, 0, ERR_RES); + write_zsreg(info->zs_channel, R0, ERR_RES); return; } #endif if (!tty) continue; + if (tty_break) { + tty_break = 0; +#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE) + if (info->line == sercons.index && sysrq_enabled) { + if (!break_pressed) { + break_pressed = jiffies; + goto ignore_char; + } + break_pressed = 0; + } +#endif + flag = TTY_BREAK; + if (info->flags & ZILOG_SAK) + do_SAK(tty); + } else { + if (stat & Rx_OVR) { + flag = TTY_OVERRUN; + } else if (stat & FRM_ERR) { + flag = TTY_FRAME; + } else if (stat & PAR_ERR) { + flag = TTY_PARITY; + } else + flag = 0; + if (flag) + /* reset the error indication */ + write_zsreg(info->zs_channel, R0, ERR_RES); + } + +#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE) + if (break_pressed && info->line == sercons.index) { + if (ch != 0 && + time_before(jiffies, break_pressed + HZ*5)) { + handle_sysrq(ch, regs, NULL, NULL); + break_pressed = 0; + goto ignore_char; + } + break_pressed = 0; + } +#endif + if (tty->flip.count >= TTY_FLIPBUF_SIZE) { static int flip_buf_ovf; ++flip_buf_ovf; @@ -348,26 +398,17 @@ if (flip_max_cnt < tty->flip.count) flip_max_cnt = tty->flip.count; } - if (stat & Rx_OVR) { - flag = TTY_OVERRUN; - } else if (stat & FRM_ERR) { - flag = TTY_FRAME; - } else if (stat & PAR_ERR) { - flag = TTY_PARITY; - } else - flag = 0; - if (flag) - /* reset the error indication */ - write_zsreg(info->zs_channel, 0, ERR_RES); + *tty->flip.flag_buf_ptr++ = flag; *tty->flip.char_buf_ptr++ = ch; + ignore_char: } tty_flip_buffer_push(tty); } static void transmit_chars(struct dec_serial *info) { - if ((read_zsreg(info->zs_channel, 0) & Tx_BUF_EMP) == 0) + if ((read_zsreg(info->zs_channel, R0) & Tx_BUF_EMP) == 0) return; info->tx_active = 0; @@ -380,7 +421,7 @@ } if ((info->xmit_cnt <= 0) || info->tty->stopped || info->tx_stopped) { - write_zsreg(info->zs_channel, 0, RES_Tx_P); + write_zsreg(info->zs_channel, R0, RES_Tx_P); return; } /* Send char */ @@ -395,15 +436,22 @@ static _INLINE_ void status_handle(struct dec_serial *info) { - unsigned char status; + unsigned char stat; /* Get status from Read Register 0 */ - status = read_zsreg(info->zs_channel, 0); + stat = read_zsreg(info->zs_channel, R0); + + if (stat & BRK_ABRT) { +#ifdef SERIAL_DEBUG_INTR + printk("handling break...."); +#endif + tty_break = 1; + } /* FIXEM: Check for DCD transitions */ - if (((status ^ info->read_reg_zero) & DCD) != 0 + if (((stat ^ info->read_reg_zero) & DCD) != 0 && info->tty && !C_CLOCAL(info->tty)) { - if (status & DCD) { + if (stat & DCD) { wake_up_interruptible(&info->open_wait); } else if (!(info->flags & ZILOG_CALLOUT_ACTIVE)) { if (info->tty) @@ -420,7 +468,7 @@ * The DCD bit doesn't seem to be inverted * like this. */ - if ((status & CTS) != 0) { + if ((stat & CTS) != 0) { if (info->tx_stopped) { info->tx_stopped = 0; if (!info->tx_active) @@ -432,8 +480,8 @@ } /* Clear status condition... */ - write_zsreg(info->zs_channel, 0, RES_EXT_INT); - info->read_reg_zero = status; + write_zsreg(info->zs_channel, R0, RES_EXT_INT); + info->read_reg_zero = stat; } /* @@ -459,7 +507,7 @@ shift = 0; /* Channel B */ for (;;) { - zs_intreg = read_zsreg(info->zs_chan_a, 3) >> shift; + zs_intreg = read_zsreg(info->zs_chan_a, R3) >> shift; if ((zs_intreg & CHAN_IRQMASK) == 0) break; From mlambeck@eemhp8.ieam.tuwien.ac.at Wed Aug 9 02:50:40 2000 Received: from eempd5.ieam.tuwien.ac.at (root@[128.130.75.225]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA12888; Wed, 9 Aug 2000 02:50:39 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 02:50:39 +0200 (MET DST) Received: from eemhp8.ieam.tuwien.ac.at ([128.130.75.138] ident=mlambeck) by eempd5.ieam.tuwien.ac.at with esmtp (Exim 3.14 #3) id 13M8mq-0001Lm-00 for linux-mips@fnet.fr; Tue, 08 Aug 2000 14:47:16 +0200 Sender: mlambeck@fnet.fr Message-ID: <39900A37.7E14C5F1@eemhp8.ieam.tuwien.ac.at> Date: Tue, 08 Aug 2000 15:25:11 +0200 From: Michael Lambeck Reply-To: Michael.Lambeck@tuwien.ac.at X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/785) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: R4000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 147 Lines: 5 Dear Sirs, unfortunately the link on the linug.org-website does not seen to work, is the loinux-port on the R4000 still on the way? yours, Michael From <@Cologne.DE:karsten@excalibur.cologne.de> Wed Aug 9 11:57:03 2000 Received: from fileserv2.Cologne.DE ([195.227.25.6]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id LAA02956; Wed, 9 Aug 2000 11:56:57 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 11:56:57 +0200 (MET DST) Received: from localhost (1619 bytes) by fileserv2.Cologne.DE via rmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Wed, 9 Aug 2000 11:56:13 +0200 (CEST) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19) Received: (from karsten@localhost) by excalibur.cologne.de (8.9.3/8.8.7) id DAA23637; Wed, 9 Aug 2000 03:35:56 +0200 Message-ID: <20000809033555.A12116@excalibur.cologne.de> Date: Wed, 9 Aug 2000 03:35:55 +0200 From: Karsten Merker To: Michael.Lambeck@tuwien.ac.at Cc: linux-mips@fnet.fr Subject: Re: R4000 Mail-Followup-To: Michael.Lambeck@tuwien.ac.at, linux-mips@fnet.fr References: <39900A37.7E14C5F1@eemhp8.ieam.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <39900A37.7E14C5F1@eemhp8.ieam.tuwien.ac.at>; from Michael Lambeck on Tue, Aug 08, 2000 at 03:25:11PM +0200 X-No-Archive: yes Content-Length: 779 Lines: 19 On Tue, Aug 08, 2000 at 03:25:11PM +0200, Michael Lambeck wrote: > unfortunately the link on the linug.org-website does not seen to work, > is the loinux-port on the R4000 still on the way? Linux/MIPS is alive and develops well. Depending on what kind of machine you have you should take a look at http://oss.sgi.com/mips (Linux on SGI), http://decstation.unix-ag.org/ (Linux on DECstations), http://www.linux-vr.org/ (Linux on MIPS-based PDAs) or at http://www.linux-mips.org/ for a general overview (although the site currently covers mostly SGI stuff). HTH, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From raiko@niisi.msk.ru Wed Aug 9 10:02:40 2000 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA29003; Wed, 9 Aug 2000 10:01:51 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 10:01:51 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id MAA32540; Wed, 9 Aug 2000 12:00:06 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id LAA09694; Wed, 9 Aug 2000 11:49:30 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id LAA17229; Wed, 9 Aug 2000 11:56:19 +0400 (MSD) Message-ID: <39911193.672C7E59@niisi.msk.ru> Date: Wed, 09 Aug 2000 12:08:51 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: BREAK and magic SysRq handling for Z8530 References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 918 Lines: 25 Maciej, "Maciej W. Rozycki" wrote: > > Hi, > > It appears our current Z8530 driver lacks BREAK support. It also has the > unfortunate side effect magic SysRq wouldn't work either, if we had it. > Not anymore! The following patch adds both features to our Z8530 driver. > It also allows the magic SysRq hack to be compiled-in (i.e. no more > linking errors) even if no virtual terminal driver is build, which is > suitable for certain configurations, including mine. > Have you tested the patch? The problem isn't in the patch itself, but as I see the zs driver is broken for a long time. At least, I used to patch heavily this driver for my Baget taht has 2 zs chips on board. Harald has the plans to implement new version of the driver, but I guess he is busy all the time. Or have I missed a cleanup of the driver ? Also, changes in sunkbd.c, keyboard.c, and serial.c isn't a good idea. :-) Regards, Gleb. From agx@gandalf.physik.uni-konstanz.de Wed Aug 9 12:08:03 2000 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.30]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA03457; Wed, 9 Aug 2000 12:08:02 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 12:08:02 +0200 (MET DST) Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 2.05 #1 (Debian)) id 13MR4n-0007sk-00; Wed, 9 Aug 2000 10:19:01 +0200 Date: Wed, 9 Aug 2000 10:19:01 +0200 From: Guido Guenther To: Michael.Lambeck@tuwien.ac.at Cc: linux-mips@fnet.fr Subject: Re: R4000 Message-ID: <20000809101901.B30034@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Michael.Lambeck@tuwien.ac.at, linux-mips@fnet.fr References: <39900A37.7E14C5F1@eemhp8.ieam.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <39900A37.7E14C5F1@eemhp8.ieam.tuwien.ac.at>; from Michael Lambeck on Tue, Aug 08, 2000 at 03:25:11PM +0200 Sender: Guido Guenther Content-Length: 344 Lines: 12 see http://www.linux-mips.org/ -- Guido On Tue, Aug 08, 2000 at 03:25:11PM +0200, Michael Lambeck wrote: > Dear Sirs, > unfortunately the link on the linug.org-website does not seen to work, > is the loinux-port on the R4000 still on the way? > yours, > Michael > -- GPG-Public Key: http://honk.physik.uni-konstanz.de/~agx/guenther.gpg.asc From macro@ds2.pg.gda.pl Wed Aug 9 12:33:18 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA05742; Wed, 9 Aug 2000 12:33:09 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 12:33:09 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA11527; Wed, 9 Aug 2000 11:38:37 +0200 (MET DST) Date: Wed, 9 Aug 2000 11:38:37 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , Harald Koerfgen , Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: BREAK and magic SysRq handling for Z8530 In-Reply-To: <39911193.672C7E59@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1730 Lines: 40 Gleb, > Have you tested the patch? The problem isn't in the patch itself, but as Sure I did, to an extent I was able to. No problems noticed. > I see the zs driver is broken for a long time. At least, I used to patch > heavily this driver for my Baget taht has 2 zs chips on board. Harald Well, the driver seems to work good enough for now to use a serial console. And the SysRq support is an absolute must when trying to debug a locked-up kernel -- the lack of this support is a sign for me nobody is currently working on DECstations at the moment. > has the plans to implement new version of the driver, but I guess he is > busy all the time. Or have I missed a cleanup of the driver ? Hmm, I haven't noticed any, either. Fixing the driver is actually on my TODO list -- all the 8530 drivers present in Linux currently need to be merged into a single one. Also DMA and synchronous mode support has to be implemented. It's not on the top of my list, though. > Also, changes in sunkbd.c, keyboard.c, and serial.c isn't a good idea. > :-) It's actually the reverse. ;-) Without these (oh well, sunkbd.c is for completeness, indeed) you cannot compile-in the magic SysRq support if you do not include the virtual terminal driver. This is an unnecessary limitation -- I don't want the VT (well, actually I would, if I had a driver for my console, but I haven't, yet). Such changes actually went into the Linus' 2.4.0-test6-pre* (but not mine -- someone overtook me, and he also missed one bit ;-) ). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@oss.sgi.com Wed Aug 9 23:34:46 2000 Received: from u-22.karlsruhe.ipdial.viaginterkom.de ([62.180.19.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA08985; Wed, 9 Aug 2000 23:34:43 +0200 (MET DST) Received-Date: Wed, 9 Aug 2000 23:34:43 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 9 Aug 2000 18:13:57 +0200 Date: Wed, 9 Aug 2000 18:13:57 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Gleb O. Raiko" , Ralf Baechle , Harald Koerfgen , Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: BREAK and magic SysRq handling for Z8530 Message-ID: <20000809181357.B10906@bacchus.dhis.org> References: <39911193.672C7E59@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Aug 09, 2000 at 11:38:37AM +0200 X-Accept-Language: de,en,fr Content-Length: 712 Lines: 16 On Wed, Aug 09, 2000 at 11:38:37AM +0200, Maciej W. Rozycki wrote: > It's actually the reverse. ;-) Without these (oh well, sunkbd.c is for > completeness, indeed) you cannot compile-in the magic SysRq support if you > do not include the virtual terminal driver. This is an unnecessary > limitation -- I don't want the VT (well, actually I would, if I had a > driver for my console, but I haven't, yet). > > Such changes actually went into the Linus' 2.4.0-test6-pre* (but not mine > -- someone overtook me, and he also missed one bit ;-) ). That probably where Prumpf's changes; I recently discussed various problem with SysRq with him. I guess he only tried to fix the HP part of the problem. Ralf From jsun@mvista.com Thu Aug 10 03:09:32 2000 Received: from hermes.mvista.com ([63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA15929; Thu, 10 Aug 2000 03:09:31 +0200 (MET DST) Received-Date: Thu, 10 Aug 2000 03:09:31 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id SAA17369; Wed, 9 Aug 2000 18:08:14 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3992007C.49050FC@mvista.com> Date: Wed, 09 Aug 2000 18:08:12 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux@engr.sgi.com, linux-mips@fnet.fr Subject: bug in the latest cache code? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1183 Lines: 34 Ralf, I spent the last a few days to track down a problem where /sbin/init hangs forever. It turns out, I believe, to be a bug introduced in the recent cache code change. A new function, r4k_flush_icache_page_i32(), was added recently. It calls blast_icache32_page(), which uses Hit cache operations to flush cache. Unfortunately, that will generate TLB fault if virtual address is not present in TLB. Under certain conditions, r4k_flush_icache_page_i32() will be called in the middle of handling a page fault, and it will then generate the same page fault again with cache hit operation. This causes a deadlock (on current->mm->mmap_sem). I read the previous version of code. The fix seems to be using the indexed cache operation. Here is the fix, and apparently it fixes the problem on my board. Jun ----------- static void r4k_flush_icache_page_i32(struct vm_area_struct *vma, struct page *page, unsigned long address) { if (!(vma->vm_flags & VM_EXEC)) return; - blast_icache32_page(address); + address = KSEG0 + (address & PAGE_MASK & (dcache_size - 1)); + blast_icache32_page_indexed(address); } From nemoto@toshiba-tops.co.jp Thu Aug 10 04:32:04 2000 Received: from fwgate.toshiba-tops.co.jp ([202.230.225.20]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id EAA17804; Thu, 10 Aug 2000 04:31:16 +0200 (MET DST) Received-Date: Thu, 10 Aug 2000 04:31:16 +0200 (MET DST) Received: from topsms by fwgate.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 10 Aug 2000 02:31:16 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id LAA02650; Thu, 10 Aug 2000 11:30:37 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA89823; Thu, 10 Aug 2000 11:30:37 +0900 (JST) To: jsun@mvista.com Cc: linux@engr.sgi.com, linux-mips@fnet.fr Subject: Re: bug in the latest cache code? From: Atsushi Nemoto In-Reply-To: <3992007C.49050FC@mvista.com> References: <3992007C.49050FC@mvista.com> X-Mailer: Mew version 1.94.1 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000810113036S.nemoto@toshiba-tops.co.jp> Date: Thu, 10 Aug 2000 11:30:36 +0900 X-Dispatcher: imput version 990905(IM130) Content-Length: 1198 Lines: 25 >>>>> On Wed, 09 Aug 2000 18:08:12 -0700, Jun Sun said: jsun> A new function, r4k_flush_icache_page_i32(), was added recently. jsun> It calls blast_icache32_page(), which uses Hit cache operations jsun> to flush cache. Unfortunately, that will generate TLB fault if jsun> virtual address is not present in TLB. Under certain jsun> conditions, r4k_flush_icache_page_i32() will be called in the jsun> middle of handling a page fault, and it will then generate the jsun> same page fault again with cache hit operation. This causes a jsun> deadlock (on current->mm->mmap_sem). To my knowlege, if the vierual address is not present in TLB, cache hit operation generates TLB refill exception, not TLB invalid exception. After the TLB refill excepsion, the cache instruction can continue execution without a page fault (no deadlock). I met the same deadlock problem on my r3k (with r4k-like cache) board with 2.2.12 based kernel. I doubted my TLB/cache codes first, but the real cause was in vt.c. _kd_mksound() modifies TLB refill handler code if mips_io_port_base == 0xa0000000. Modifing the #if-line near _kd_mksound() fixed my problem. Hope this helps. --- Atsushi Nemoto From ralf@uni-koblenz.de Thu Aug 10 19:39:19 2000 Received: from u-173.karlsruhe.ipdial.viaginterkom.de (u-173.karlsruhe.ipdial.viaginterkom.de [62.180.19.173]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA04462; Thu, 10 Aug 2000 19:39:17 +0200 (MET DST) Received-Date: Thu, 10 Aug 2000 19:39:17 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 10 Aug 2000 19:38:58 +0200 Date: Thu, 10 Aug 2000 19:38:58 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: bug in the latest cache code? Message-ID: <20000810193858.A1478@bacchus.dhis.org> References: <3992007C.49050FC@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3992007C.49050FC@mvista.com>; from jsun@mvista.com on Wed, Aug 09, 2000 at 06:08:12PM -0700 X-Accept-Language: de,en,fr Content-Length: 1123 Lines: 25 On Wed, Aug 09, 2000 at 06:08:12PM -0700, Jun Sun wrote: > I spent the last a few days to track down a problem where /sbin/init > hangs forever. It turns out, I believe, to be a bug introduced in the > recent cache code change. > > A new function, r4k_flush_icache_page_i32(), was added recently. It > calls blast_icache32_page(), which uses Hit cache operations to flush > cache. Unfortunately, that will generate TLB fault if virtual address > is not present in TLB. Under certain conditions, > r4k_flush_icache_page_i32() will be called in the middle of handling a > page fault, and it will then generate the same page fault again with > cache hit operation. This causes a deadlock (on current->mm->mmap_sem). > > I read the previous version of code. The fix seems to be using the > indexed cache operation. Here is the fix, and apparently it fixes the > problem on my board. I can see how this may happen and will take care of fixing this one. We really want to avoid using index operations. Unlike what the comment in the kernel code suggest they do overly flush caches which is pretty expensive. Ralf From jsun@mvista.com Thu Aug 10 19:52:22 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA05005; Thu, 10 Aug 2000 19:52:19 +0200 (MET DST) Received-Date: Thu, 10 Aug 2000 19:52:19 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id KAA04609; Thu, 10 Aug 2000 10:50:28 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3992EB64.8F2587A6@mvista.com> Date: Thu, 10 Aug 2000 10:50:28 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: bug in the latest cache code? References: <3992007C.49050FC@mvista.com> <20000810193858.A1478@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2995 Lines: 83 Ralf Baechle wrote: > > On Wed, Aug 09, 2000 at 06:08:12PM -0700, Jun Sun wrote: > > > I spent the last a few days to track down a problem where /sbin/init > > hangs forever. It turns out, I believe, to be a bug introduced in the > > recent cache code change. > > > > A new function, r4k_flush_icache_page_i32(), was added recently. It > > calls blast_icache32_page(), which uses Hit cache operations to flush > > cache. Unfortunately, that will generate TLB fault if virtual address > > is not present in TLB. Under certain conditions, > > r4k_flush_icache_page_i32() will be called in the middle of handling a > > page fault, and it will then generate the same page fault again with > > cache hit operation. This causes a deadlock (on current->mm->mmap_sem). > > > > I read the previous version of code. The fix seems to be using the > > indexed cache operation. Here is the fix, and apparently it fixes the > > problem on my board. > > I can see how this may happen and will take care of fixing this one. > Thanks. Below is the stack trace and some of my notes on this problem. Hope this helps. I agree we should not use index operation abusively, but this is pretty serious problem. I don't think we can fix it easily without changing the arch-independent part of kernel. Jun ------------------------- more traces : the page fault is caused r4k_flush_icache_page_i32(), the first cache (Hit_....) operation. call stack when current->mm->sem has already been taken but r4k_flush_icache_page_i32() is still called. #0 jsun_bug () at r4xx0.c:1971 #1 0x8009aa60 in r4k_flush_icache_page_i32 (vma=0x811401e0, page=0x810476c0, address=263607008) at r4xx0.c:1986 #2 0x800b0320 in do_no_page (mm=0x81142080, vma=0x811401e0, address=263607008, write_access=0, page_table=0x811fed94) at memory.c:1162 #3 0x800b0508 in handle_mm_fault (mm=0x81142080, vma=0x811401e0, address=263607008, write_access=0) at memory.c:1202 #4 0x80094118 in do_page_fault (regs=0x81127f30, write=0, address=263607008) at fault.c:93 #5 0x8008ce98 in handle_tlbl () at r4k_misc.S:154 (263607008 = 0xfb652e0) The epc for #5 tlbl fault is 0xfb652e0, which means it is a page fault for the next instruction. **** annotated calling trace : handle_tlbl (in asm) - arch/mips/kernel/r4k_misc.S do_page_fault - arch/mips/mm/fault.c after check it is a good area swtich (handle_mm_fault(....) ) - line 93 [not visiable to gdb handle_mm_fault(...) - mm/memory.c ] alloc pte handle_pte_fault(...) check about the page and do_no_page(...) - mm/memory.c /* do a bunch of stuff but TLB entry for the new page is not built yet */ flush_page_to_ram(new_page); flush_icache_page(...) ( = r4k_flush_icache_page_i32) ; ==> jsun_bug() From yuki@shaka.com Sun Aug 13 07:32:01 2000 Received: from flex.com (flex.com [206.126.0.13]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id HAA05307; Sun, 13 Aug 2000 07:31:59 +0200 (MET DST) Received-Date: Sun, 13 Aug 2000 07:31:59 +0200 (MET DST) Received: from HANK (cvx-24.flex.com [207.12.8.24]) by flex.com (8.9.1a/8.9.1) with SMTP id FAA24807; Sat, 12 Aug 2000 05:03:57 -1000 (HST) Date: Sat, 12 Aug 2000 05:03:57 -1000 (HST) From: hank golden Message-Id: <200008121503.FAA24807@flex.com> To: yuki@shaka.com Subject: *-* Content-Length: 531 Lines: 25 ゆきちゃんだよ〜。 暑いね〜〜。 すごーいＨなサイト、みつけっちゃった。 超刺激的だよ。 http://www.tonight2.com/win/006/ 暇なとき、見てね。 じゃ、またね！ ゆきでしたぁ！！ ☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆ Per Section 301, Paragraph (a)(2)(C) of S. 1618, Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word"remove" in the subject line. ★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★ From fuk@iace.co.jp Mon Aug 14 06:23:09 2000 Received: from mf103.infoweb.ne.jp (mf103.infoweb.ne.jp [210.131.99.50]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA18468; Mon, 14 Aug 2000 06:23:07 +0200 (MET DST) Received-Date: Mon, 14 Aug 2000 06:23:07 +0200 (MET DST) Received: from 300gl by mf103.infoweb.ne.jp (8.9.3+3.2W/3.7W-10/13/99) with ESMTP id NAA24754 for ; Mon, 14 Aug 2000 13:22:50 +0900 Message-ID: <8675.966225089060@iace.co.jp> Date: Mon, 14 Aug 2000 12:51:29 +0900 (JST) From: "magiwa.com" To: linux-mips@fnet.fr Subject: =?iso-2022-jp?B?GyRCIiIiIzMkMzBOOTlUN2MwQjRWOl0+JklKGyhC?==?iso-2022-jp?B?GyRCJE4kNDBGRmIiIyIiGyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset =iso-2022-jp Content-Transfer-Encoding: 7bit Content-Length: 431 Lines: 10 $BFMA3$N%a!<%k$G<:Ni$7$^$9!#I,MW$N$J$$J}$KG[?.$5$l$?>l9g$O(B $B$*OM$S?=$7>e$2$^$9!#(B $B$3$N%a!<%k$O!"=PH/4V6a$N3$303J0B9R6u7t!&3J0B%D%"!<$J$I$N(B $BGd$l;D$j>&IJ$rCf?4$K!XN9!Y$N?'!9$J>pJs$rDj4|E*$K$4Ds6!:9(B $B$7>e$2$k%5%$%H$N$4>R2p$r$9$k$?$a$N$b$N$G$9!#2q0wEPO?@)$G(B $B$9$,!"EPO?NA$O$b$A$m$sL5NA$G$9!#$<$R0lEY$4Mw$K$J$i$l$F$_(B $B$F$O$$$+$,$G$7$g$&$+!)(B $B>pJs%5%$%H!!!!(Bhttp://www.iace.co.jp/ngo/magiwa.html From macro@ds2.pg.gda.pl Mon Aug 14 13:40:49 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA23124; Mon, 14 Aug 2000 13:40:48 +0200 (MET DST) Received-Date: Mon, 14 Aug 2000 13:40:48 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA17800; Mon, 14 Aug 2000 13:39:48 +0200 (MET DST) Date: Mon, 14 Aug 2000 13:39:47 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: NTP support code updates Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 5911 Lines: 160 Hi, Wondering why my RTC's time drifts away when the NTP daemon is running I discovered to my surprise that our NTP support code is still of 2.0 vintage and simply does not work. As a result set_rtc_mmss() does not get called at all. The following patch updates the relevant code for both MIPS and MIPS64 to match the rest of the kernel. I've only tested the DEC path but changes are straightforward and should work for all variations. [Hmm, now my dispersion changes between 1 and 0.1 -- the set_rtc_mmss() function resets the RTC's divider and as a result further timer interrupts do not arrive exactly at the right time. This probably cannot be avoided (apart from by disabling set_rtc_mmss()) but the code needs to be updated regardless.] Comments are welcomed, as usually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/time.c linux-mips-2.4.0-test5-20000731/arch/mips/baget/time.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/time.c Tue Mar 28 04:26:01 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/baget/time.c Sat Aug 12 21:47:26 2000 @@ -76,21 +76,22 @@ void do_gettimeofday(struct timeval *tv) { - unsigned long flags; + unsigned long flags; - save_and_cli(flags); - *tv = xtime; - restore_flags(flags); + save_and_cli(flags); + *tv = xtime; + restore_flags(flags); } void do_settimeofday(struct timeval *tv) { - unsigned long flags; + unsigned long flags; - save_and_cli(flags); - xtime = *tv; - time_state = TIME_BAD; - time_maxerror = MAXPHASE; - time_esterror = MAXPHASE; - restore_flags(flags); -} + save_and_cli(flags); + xtime = *tv; + time_adjust = 0; /* stop active adjtime() */ + time_status |= STA_UNSYNC; + time_maxerror = NTP_PHASE_LIMIT; + time_esterror = NTP_PHASE_LIMIT; + restore_flags(flags); +} diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c Wed Jul 12 04:25:56 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c Sat Aug 12 21:58:23 2000 @@ -187,6 +187,7 @@ void do_settimeofday(struct timeval *tv) { write_lock_irq(&xtime_lock); + /* This is revolting. We need to set the xtime.tv_usec * correctly. However, the value in this location is * is value at the last tick. @@ -199,10 +200,13 @@ tv->tv_usec += 1000000; tv->tv_sec--; } + xtime = *tv; - time_state = TIME_BAD; - time_maxerror = MAXPHASE; - time_esterror = MAXPHASE; + time_adjust = 0; /* stop active adjtime() */ + time_status |= STA_UNSYNC; + time_maxerror = NTP_PHASE_LIMIT; + time_esterror = NTP_PHASE_LIMIT; + write_unlock_irq(&xtime_lock); } @@ -307,13 +311,15 @@ * called as close as possible to 500 ms before the new second starts. */ read_lock(&xtime_lock); - if (time_state != TIME_BAD && xtime.tv_sec > last_rtc_update + 660 && - xtime.tv_usec > 500000 - (tick >> 1) && - xtime.tv_usec < 500000 + (tick >> 1)) { + if ((time_status & STA_UNSYNC) == 0 + && xtime.tv_sec > last_rtc_update + 660 + && xtime.tv_usec >= 500000 - tick / 2 + && xtime.tv_usec <= 500000 + tick / 2) { if (set_rtc_mmss(xtime.tv_sec) == 0) last_rtc_update = xtime.tv_sec; else - last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */ + /* do it again in 60 s */ + last_rtc_update = xtime.tv_sec - 600; } /* As we return to user mode fire off the other CPU schedulers.. this is basically because we don't yet share IRQ's around. This message is diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/indy_timer.c linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/indy_timer.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/indy_timer.c Tue Mar 28 04:26:13 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/indy_timer.c Sat Aug 12 21:25:13 2000 @@ -290,8 +290,9 @@ { write_lock_irq(&xtime_lock); xtime = *tv; - time_state = TIME_BAD; - time_maxerror = MAXPHASE; - time_esterror = MAXPHASE; + time_adjust = 0; /* stop active adjtime() */ + time_status |= STA_UNSYNC; + time_maxerror = NTP_PHASE_LIMIT; + time_esterror = NTP_PHASE_LIMIT; write_unlock_irq(&xtime_lock); } diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip22/ip22-timer.c linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip22/ip22-timer.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip22/ip22-timer.c Mon Mar 27 04:26:15 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip22/ip22-timer.c Sat Aug 12 21:32:29 2000 @@ -288,8 +288,9 @@ { write_lock_irq(&xtime_lock); xtime = *tv; - time_state = TIME_BAD; - time_maxerror = MAXPHASE; - time_esterror = MAXPHASE; + time_adjust = 0; /* stop active adjtime() */ + time_status |= STA_UNSYNC; + time_maxerror = NTP_PHASE_LIMIT; + time_esterror = NTP_PHASE_LIMIT; write_unlock_irq(&xtime_lock); } diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip27/ip27-timer.c linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip27/ip27-timer.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip27/ip27-timer.c Thu Jul 13 04:26:16 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip27/ip27-timer.c Sat Aug 12 21:33:21 2000 @@ -206,9 +206,9 @@ xtime = *tv; time_adjust = 0; /* stop active adjtime() */ - time_state = TIME_BAD; - time_maxerror = MAXPHASE; - time_esterror = MAXPHASE; + time_status |= STA_UNSYNC; + time_maxerror = NTP_PHASE_LIMIT; + time_esterror = NTP_PHASE_LIMIT; write_unlock_irq(&xtime_lock); } From macro@ds2.pg.gda.pl Mon Aug 14 14:15:34 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA24247; Mon, 14 Aug 2000 14:15:31 +0200 (MET DST) Received-Date: Mon, 14 Aug 2000 14:15:31 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA18734; Mon, 14 Aug 2000 14:15:22 +0200 (MET DST) Date: Mon, 14 Aug 2000 14:15:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: Craig P Prescott , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Non-contiguous memory support Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 33288 Lines: 1130 Hi, Following is a patch that provides support for non-contiguous memory. This is needed at least for MS02-based DECstations in mixed memory configurations, where 24MB holes exist between 8MB memory modules. I decided to write it in a generic way, hence the code is common to all MIPS platforms, removing tons of now unnecessary duplicate code. It's modelled after the E820 memory support for i386 and provides similar functionality, i.e. platform-specific backends can obtain a memory map in a system-dependent fashion and register it with the generic code. Later, the map may get either accepted or overridden by a command line providing a series of "mem=@" statements. The latter may be useful for developers to avoid pulling away memory modules to get specific memory configurations tested (e.g. low memory performance). The generic code registers the memory map in '/proc/iomem' just like it happens for other platforms -- here is an example output from my machine: $ cat /proc/iomem 00000000-067fffff : System RAM 00040000-00298e7f : Kernel code 002ac0a0-00344b0f : Kernel data 08000000-087fffff : System RAM 0a000000-0a7fffff : System RAM 0c000000-0c7fffff : System RAM Eventually all memory-mapped resources should get registered there, but this is something for a start. The code from arc/memory.c to place the bootmem allocator bitmap in the largest area available got removed. The bitmap gets always placed right above the kernel. I don't really think it should really matter, but if it did, I may add this code in a generic way (people interested in such machines, please make comments). I removed orion/misc.c completely instead of rewriting it -- orion/setup.c contains everything the former did and more. I tried to fix every system supported, but a few look weird -- they do not provide prom_init(), thus I am not sure how they even can be started by kernel/setup.c. As a result their memory initialization code remains intact (non-existent?). That aside, the memory initialization should look fairly sane now. The DEC path was tested as usual -- others did not. If there are any specific questions about some part of the code, I am looking forward to read them. Comments are welcomed, as usually. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/cmdline.c linux-mips-2.4.0-test5-20000731/arch/mips/arc/cmdline.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/cmdline.c Tue Mar 28 04:26:00 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/arc/cmdline.c Sun Aug 13 12:14:21 2000 @@ -14,7 +14,7 @@ /* #define DEBUG_CMDLINE */ -char arcs_cmdline[CL_SIZE]; +char arcs_cmdline[COMMAND_LINE_SIZE]; char * __init prom_getcmdline(void) { diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/memory.c linux-mips-2.4.0-test5-20000731/arch/mips/arc/memory.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/memory.c Wed Jul 5 04:25:46 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/arc/memory.c Sun Aug 13 20:37:39 2000 @@ -47,31 +47,25 @@ "LoadedProgram", "FirmwareTemporary", "FirmwarePermanent", - "FreeContigiuous" + "FreeContiguous" }; #define mtypes(a) (prom_flags & PROM_FLAG_ARCS) ? arcs_mtypes[a.arcs] : arc_mtypes[a.arc] #endif -static struct prom_pmemblock pblocks[PROM_MAX_PMEMBLOCKS]; - -#define MEMTYPE_DONTUSE 0 -#define MEMTYPE_PROM 1 -#define MEMTYPE_FREE 2 - static inline int memtype_classify_arcs (union linux_memtypes type) { switch (type.arcs) { case arcs_fcontig: case arcs_free: - return MEMTYPE_FREE; + return BOOT_MEM_RAM; case arcs_atmp: - return MEMTYPE_PROM; + return BOOT_MEM_ROM_DATA; case arcs_eblock: case arcs_rvpage: case arcs_bmem: case arcs_prog: case arcs_aperm: - return MEMTYPE_DONTUSE; + return BOOT_MEM_RESERVED; default: BUG(); } @@ -83,15 +77,15 @@ switch (type.arc) { case arc_free: case arc_fcontig: - return MEMTYPE_FREE; + return BOOT_MEM_RAM; case arc_atmp: - return MEMTYPE_PROM; + return BOOT_MEM_ROM_DATA; case arc_eblock: case arc_rvpage: case arc_bmem: case arc_prog: case arc_aperm: - return MEMTYPE_DONTUSE; + return BOOT_MEM_RESERVED; default: BUG(); } @@ -106,50 +100,13 @@ return memtype_classify_arc(type); } -static inline unsigned long find_max_low_pfn(void) -{ - struct prom_pmemblock *p, *highest; - unsigned long pfn; - - p = pblocks; - highest = 0; - while (p->size != 0) { - if (!highest || p->base > highest->base) - highest = p; - p++; - } - - pfn = (highest->base + highest->size) >> PAGE_SHIFT; -#ifdef DEBUG - prom_printf("find_max_low_pfn: 0x%lx pfns.\n", pfn); -#endif - return pfn; -} - -static inline struct prom_pmemblock *find_largest_memblock(void) -{ - struct prom_pmemblock *p, *largest; - - p = pblocks; - largest = 0; - while (p->size != 0) { - if (!largest || p->size > largest->size) - largest = p; - p++; - } - - return largest; -} - void __init prom_meminit(void) { - struct prom_pmemblock *largest; - unsigned long bootmap_size; struct linux_mdesc *p; - int totram; - int i = 0; #ifdef DEBUG + int i = 0; + prom_printf("ARCS MEMORY DESCRIPTOR dump:\n"); p = ArcGetMemoryDescriptor(PROM_NULL_MDESC); while(p) { @@ -160,77 +117,37 @@ } #endif - totram = 0; - i = 0; p = PROM_NULL_MDESC; while ((p = ArcGetMemoryDescriptor(p))) { - pblocks[i].type = prom_memtype_classify(p->type); - pblocks[i].base = p->base << PAGE_SHIFT; - pblocks[i].size = p->pages << PAGE_SHIFT; - - switch (pblocks[i].type) { - case MEMTYPE_FREE: - totram += pblocks[i].size; -#ifdef DEBUG - prom_printf("free_chunk[%d]: base=%08lx size=%x\n", - i, pblocks[i].base, - pblocks[i].size); -#endif - i++; - break; - case MEMTYPE_PROM: -#ifdef DEBUG - prom_printf("prom_chunk[%d]: base=%08lx size=%x\n", - i, pblocks[i].base, - pblocks[i].size); -#endif - i++; - break; - default: - break; - } - } - pblocks[i].size = 0; - - max_low_pfn = find_max_low_pfn(); - - largest = find_largest_memblock(); - bootmap_size = init_bootmem(largest->base >> PAGE_SHIFT, max_low_pfn); + unsigned long base, size; + long type; - for (i = 0; pblocks[i].size; i++) - if (pblocks[i].type == MEMTYPE_FREE) - free_bootmem(pblocks[i].base, pblocks[i].size); + base = __pa(p->base << PAGE_SHIFT); /* Fix up from KSEG0 */ + size = p->pages << PAGE_SHIFT; + type = prom_memtype_classify(p->type); - /* This test is simpleminded. It will fail if the bootmem bitmap - falls into multiple adjacent ARC memory areas. */ - if (bootmap_size > largest->size) { - prom_printf("CRITIAL: overwriting PROM data.\n"); - BUG(); + add_memory_region(base, pages, type); } - - /* Reserve the memory bootmap itself */ - reserve_bootmem(largest->base, bootmap_size); - - printk("PROMLIB: Total free ram %dK / %dMB.\n", - totram >> 10, totram >> 20); } void __init prom_free_prom_memory (void) { + int i; struct prom_pmemblock *p; unsigned long freed = 0; unsigned long addr; - for (p = pblocks; p->size != 0; p++) { - if (p->type != MEMTYPE_PROM) + for (i = 0; i < boot_mem_map.nr_map; i++) { + if (boot_mem_map.map[i].type != BOOT_MEM_ROM_DATA) continue; - addr = PAGE_OFFSET + p->base; - while (addr < p->base + p->size) { - ClearPageReserved(mem_map + MAP_NR(addr)); - set_page_count(mem_map + MAP_NR(addr), 1); - free_page(addr); + addr = boot_mem_map.map[i].addr; + while (addr < boot_mem_map.map[i].addr + + boot_mem_map.map[i].size) { + ClearPageReserved(mem_map + MAP_NR(__va(addr))); + set_page_count(mem_map + MAP_NR(__va(addr)), 1); + free_page(__va(addr)); addr += PAGE_SIZE; freed += PAGE_SIZE; } diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/prom/init.c linux-mips-2.4.0-test5-20000731/arch/mips/baget/prom/init.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/prom/init.c Tue Mar 28 04:26:02 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/baget/prom/init.c Sun Aug 13 20:24:28 2000 @@ -8,7 +8,7 @@ #include #include -char arcs_cmdline[CL_SIZE]; +char arcs_cmdline[COMMAND_LINE_SIZE]; int __init prom_init(unsigned int mem_upper) { @@ -17,10 +17,6 @@ mips_machtype = MACH_UNKNOWN; arcs_cmdline[0] = 0; return 0; -} - -void __init prom_fixup_mem_map(unsigned long start, unsigned long end) -{ } void prom_free_prom_memory (void) diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/prom.c linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/prom.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/prom.c Thu May 11 04:26:44 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/prom.c Sun Aug 13 20:24:58 2000 @@ -15,18 +15,11 @@ #include -char arcs_cmdline[CL_SIZE]; - -extern char _end; - -#define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) -#define PFN_ALIGN(x) (((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK) - +char arcs_cmdline[COMMAND_LINE_SIZE]; void __init prom_init(const char *s) { int i = 0; - unsigned long mem_size, free_start, free_end, start_pfn, bootmap_size; // _serinit(); @@ -37,24 +30,9 @@ mips_machgroup = MACH_GROUP_NEC_DDB; mips_machtype = MACH_NEC_DDB5074; - /* 64 MB non-upgradable */ - mem_size = 64 << 20; - - free_start = PHYSADDR(PFN_ALIGN(&_end)); - free_end = mem_size; - start_pfn = PFN_UP((unsigned long)&_end); - /* Register all the contiguous memory with the bootmem allocator - and free it. Be careful about the bootmem freemap. */ - bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); - - /* Free the entire available memory after the _end symbol. */ - free_start += bootmap_size; - free_bootmem(free_start, free_end-free_start); -} - -void __init prom_fixup_mem_map(unsigned long start, unsigned long end) -{ + /* 64 MB non-upgradable */ + add_memory_region(0, 64 << 20, BOOT_MEM_RAM); } void __init prom_free_prom_memory(void) diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/setup.c Wed Jun 21 04:26:38 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/setup.c Sun Aug 13 18:40:51 2000 @@ -118,11 +118,6 @@ panic_timeout = 180; } -int __init page_is_ram(unsigned long pagenr) -{ - return 1; -} - #define USE_NILE4_SERIAL 0 diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/cmdline.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/cmdline.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/cmdline.c Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/cmdline.c Sun Aug 13 16:54:47 2000 @@ -19,7 +19,7 @@ extern int (*prom_printf)(char *, ...); #endif -char arcs_cmdline[CL_SIZE]; +char arcs_cmdline[COMMAND_LINE_SIZE]; void __init prom_init_cmdline(int argc, char **argv, unsigned long magic) { diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/memory.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/memory.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/memory.c Mon Jul 10 04:26:02 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/memory.c Sun Aug 13 20:49:47 2000 @@ -2,6 +2,7 @@ * memory.c: memory initialisation code. * * Copyright (C) 1998 Harald Koerfgen, Frieder Streffer and Paul M. Antoine + * Copyright (C) 2000 Maciej W. Rozycki * * $Id: memory.c,v 1.3 1999/10/09 00:00:58 ralf Exp $ */ @@ -14,6 +15,8 @@ #include #include +#include + #include #include "prom.h" @@ -33,11 +36,6 @@ volatile unsigned long mem_err = 0; /* So we know an error occured */ -extern char _end; - -#define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) -#define PFN_ALIGN(x) (((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK) - /* * Probe memory in 4MB chunks, waiting for an error to tell us we've fallen * off the end of real memory. Only suitable for the 2100/3100's (PMAX). @@ -45,7 +43,7 @@ #define CHUNK_SIZE 0x400000 -unsigned long __init pmax_get_memory_size(void) +static void __init pmax_setup_memory_region(void) { volatile unsigned char *memory_page, dummy; char old_handler[0x80]; @@ -66,17 +64,19 @@ dummy = *memory_page; } memcpy((void *)(KSEG0 + 0x80), &old_handler, 0x80); - return (unsigned long)memory_page - KSEG1 - CHUNK_SIZE; + + add_memory_region(0, (unsigned long)memory_page - KSEG1 - CHUNK_SIZE, + BOOT_MEM_RAM); } /* * Use the REX prom calls to get hold of the memory bitmap, and thence * determine memory size. */ -unsigned long __init rex_get_memory_size(void) +static void __init rex_setup_memory_region(void) { int i, bitmap_size; - unsigned long mem_size = 0; + unsigned long mem_start = 0, mem_size = 0; memmap *bm; /* some free 64k */ @@ -88,40 +88,24 @@ /* FIXME: very simplistically only add full sets of pages */ if (bm->bitmap[i] == 0xff) mem_size += (8 * bm->pagesize); + else if (!mem_size) + mem_start += (8 * bm->pagesize); + else { + add_memory_region(mem_start, mem_size, BOOT_MEM_RAM); + mem_start += mem_size + (8 * bm->pagesize); + mem_size = 0; + } } - - return (mem_size); + if (mem_size) + add_memory_region(mem_start, mem_size, BOOT_MEM_RAM); } void __init prom_meminit(unsigned int magic) { - unsigned long free_start, free_end, start_pfn, bootmap_size; - unsigned long mem_size = 0; - if (magic != REX_PROM_MAGIC) - mem_size = pmax_get_memory_size(); + pmax_setup_memory_region(); else - mem_size = rex_get_memory_size(); - - free_start = PHYSADDR(PFN_ALIGN(&_end)); - free_end = mem_size; - start_pfn = PFN_UP((unsigned long)&_end); - -#ifdef PROM_DEBUG - prom_printf("free_start: 0x%08x\n", free_start); - prom_printf("free_end: 0x%08x\n", free_end); - prom_printf("start_pfn: 0x%08x\n", start_pfn); -#endif - - /* Register all the contiguous memory with the bootmem allocator - and free it. Be careful about the bootmem freemap. */ - bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); - free_bootmem(free_start + bootmap_size, free_end - free_start - bootmap_size); -} - -int __init page_is_ram(unsigned long pagenr) -{ - return 1; + rex_setup_memory_region(); } void prom_free_prom_memory (void) diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/jazz/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/jazz/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/jazz/setup.c Tue Mar 28 04:26:07 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/jazz/setup.c Sun Aug 13 18:42:14 2000 @@ -80,11 +80,6 @@ i8259_setup_irq(2, &irq2); } -int __init page_is_ram(unsigned long pagenr) -{ - return 1; -} - void __init jazz_setup(void) { add_wired_entry (0x02000017, 0x03c00017, 0xe0000000, PM_64K); diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/kernel/Makefile --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/Makefile Tue Jul 11 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/kernel/Makefile Sun Aug 13 12:23:32 2000 @@ -6,8 +6,10 @@ # unless it's something special (ie not a .c file). # +.S.s: + $(CPP) $(AFLAGS) $< -o $*.o .S.o: - $(CC) $(CFLAGS) -c $< -o $*.o + $(CC) $(AFLAGS) -c $< -o $*.o all: kernel.o head.o init_task.o EXTRA_ASFLAGS = -mips3 -mcpu=r4000 diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/kernel/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/setup.c Tue Jul 11 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/kernel/setup.c Sun Aug 13 20:48:28 2000 @@ -6,6 +6,7 @@ * Copyright (C) 1995 Linus Torvalds * Copyright (C) 1995, 1996, 1997, 1998 Ralf Baechle * Copyright (C) 1996 Stoned Elipot + * Copyright (C) 2000 Maciej W. Rozycki */ #include #include @@ -99,12 +100,14 @@ unsigned long mips_machtype = MACH_UNKNOWN; unsigned long mips_machgroup = MACH_GROUP_UNKNOWN; +struct boot_mem_map boot_mem_map; + unsigned char aux_device_present; -extern int _end; +extern char _ftext, _etext, _fdata, _edata, _end; -static char command_line[CL_SIZE] = { 0, }; - char saved_command_line[CL_SIZE]; -extern char arcs_cmdline[CL_SIZE]; +static char command_line[COMMAND_LINE_SIZE]; + char saved_command_line[COMMAND_LINE_SIZE]; +extern char arcs_cmdline[COMMAND_LINE_SIZE]; /* * The board specific setup routine sets irq_setup to point to a board @@ -130,6 +133,9 @@ extern asmlinkage void start_kernel(void); extern int prom_init(int, char **, char **, int *); +static struct resource code_resource = { "Kernel code" }; +static struct resource data_resource = { "Kernel data" }; + /* * Probe whether cpu has config register by trying to play with * alternate cache bit and see whether it matters. @@ -251,6 +257,97 @@ panic("Unknown machtype in init_IRQ"); } +void __init add_memory_region(unsigned long start, unsigned long size, + long type) +{ + int x = boot_mem_map.nr_map; + + if (x == BOOT_MEM_MAP_MAX) { + printk("Ooops! Too many entries in the memory map!\n"); + return; + } + + boot_mem_map.map[x].addr = start; + boot_mem_map.map[x].size = size; + boot_mem_map.map[x].type = type; + boot_mem_map.nr_map++; +} + +static void __init print_memory_map(void) +{ + int i; + + for (i = 0; i < boot_mem_map.nr_map; i++) { + printk(" memory: %08lx @ %08lx ", + boot_mem_map.map[i].size, boot_mem_map.map[i].addr); + switch (boot_mem_map.map[i].type) { + case BOOT_MEM_RAM: + printk("(usable)\n"); + break; + case BOOT_MEM_ROM_DATA: + printk("(ROM data)\n"); + break; + case BOOT_MEM_RESERVED: + printk("(reserved)\n"); + break; + default: + printk("type %lu\n", boot_mem_map.map[i].type); + break; + } + } +} + +static inline void parse_mem_cmdline(void) +{ + char c = ' ', *to = command_line, *from = saved_command_line; + unsigned long start_at, mem_size; + int len = 0; + int usermem = 0; + + printk("Determined physical RAM map:\n"); + print_memory_map(); + + for (;;) { + /* + * "mem=XXX[kKmM]" defines a memory region from + * 0 to , overriding the determined size. + * "mem=XXX[KkmM]@YYY[KkmM]" defines a memory region from + * to +, overriding the determined size. + */ + if (c == ' ' && !memcmp(from, "mem=", 4)) { + if (to != command_line) + to--; + /* + * If a user specifies memory size, we + * blow away any automatically generated + * size. + */ + if (usermem == 0) { + boot_mem_map.nr_map = 0; + usermem = 1; + } + mem_size = memparse(from + 4, &from); + if (*from == '@') + start_at = memparse(from + 1, &from); + else + start_at = 0; + add_memory_region(start_at, mem_size, BOOT_MEM_RAM); + } + c = *(from++); + if (!c) + break; + if (COMMAND_LINE_SIZE <= ++len) + break; + *(to++) = c; + } + *to = '\0'; + + if (usermem) { + printk("User-defined physical RAM map:\n"); + print_memory_map(); + } +} + void __init setup_arch(char **cmdline_p) { void baget_setup(void); @@ -263,6 +360,10 @@ void ddb_setup(void); void orion_setup(void); + unsigned long bootmap_size; + unsigned long start_pfn, max_pfn; + int i; + /* Save defaults for configuration-dependent routines. */ irq_setup = default_irq_setup; @@ -327,12 +428,88 @@ panic("Unsupported architecture"); } - strncpy (command_line, arcs_cmdline, CL_SIZE); - memcpy(saved_command_line, command_line, CL_SIZE); - saved_command_line[CL_SIZE-1] = '\0'; - + strncpy(command_line, arcs_cmdline, sizeof command_line); + command_line[sizeof command_line - 1] = 0; + strcpy(saved_command_line, command_line); *cmdline_p = command_line; + parse_mem_cmdline(); + +#define PFN_UP(x) (((x) + PAGE_SIZE - 1) >> PAGE_SHIFT) +#define PFN_DOWN(x) ((x) >> PAGE_SHIFT) +#define PFN_PHYS(x) ((x) << PAGE_SHIFT) + + /* + * Partially used pages are not usable - thus + * we are rounding upwards. + */ + start_pfn = PFN_UP(__pa(&_end)); + + /* Find the highest page frame number we have available. */ + max_pfn = 0; + for (i = 0; i < boot_mem_map.nr_map; i++) { + unsigned long start, end; + + if (boot_mem_map.map[i].type != BOOT_MEM_RAM) + continue; + + start = PFN_UP(boot_mem_map.map[i].addr); + end = PFN_DOWN(boot_mem_map.map[i].addr + + boot_mem_map.map[i].size); + + if (start >= end) + continue; + if (end > max_pfn) + max_pfn = end; + } + + /* Initialize the boot-time allocator. */ + bootmap_size = init_bootmem(start_pfn, max_pfn); + + /* + * Register fully available low RAM pages with the bootmem allocator. + */ + for (i = 0; i < boot_mem_map.nr_map; i++) { + unsigned long curr_pfn, last_pfn, size; + + /* + * Reserve usable memory. + */ + if (boot_mem_map.map[i].type != BOOT_MEM_RAM) + continue; + + /* + * We are rounding up the start address of usable memory: + */ + curr_pfn = PFN_UP(boot_mem_map.map[i].addr); + if (curr_pfn >= max_pfn) + continue; + if (curr_pfn < start_pfn) + curr_pfn = start_pfn; + + /* + * ... and at the end of the usable range downwards: + */ + last_pfn = PFN_DOWN(boot_mem_map.map[i].addr + + boot_mem_map.map[i].size); + + if (last_pfn > max_pfn) + last_pfn = max_pfn; + + /* + * ... finally, did all the rounding and playing + * around just make the area go away? + */ + if (last_pfn <= curr_pfn) + continue; + + size = last_pfn - curr_pfn; + free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(size)); + } + + /* Reserve the bootmap memory. */ + reserve_bootmem(PFN_PHYS(start_pfn), bootmap_size); + #ifdef CONFIG_BLK_DEV_INITRD #error "Fixme, I'm broken." tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8; @@ -354,6 +531,41 @@ #endif paging_init(); + + code_resource.start = virt_to_bus(&_ftext); + code_resource.end = virt_to_bus(&_etext) - 1; + data_resource.start = virt_to_bus(&_fdata); + data_resource.end = virt_to_bus(&_edata) - 1; + + /* + * Request address space for all standard RAM. + */ + for (i = 0; i < boot_mem_map.nr_map; i++) { + struct resource *res; + + res = alloc_bootmem(sizeof(struct resource)); + switch (boot_mem_map.map[i].type) { + case BOOT_MEM_RAM: + case BOOT_MEM_ROM_DATA: + res->name = "System RAM"; + break; + case BOOT_MEM_RESERVED: + default: + res->name = "reserved"; + } + res->start = boot_mem_map.map[i].addr; + res->end = res->start + boot_mem_map.map[i].size - 1; + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + request_resource(&iomem_resource, res); + + /* + * We dont't know which RAM region contains kernel data, + * so we try it repeatedly and let the resource manager + * test it. + */ + request_resource(res, &code_resource); + request_resource(res, &data_resource); + } } void r3081_wait(void) diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/mm/init.c linux-mips-2.4.0-test5-20000731/arch/mips/mm/init.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/mm/init.c Mon Jul 3 04:25:56 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/mm/init.c Sun Aug 13 20:25:18 2000 @@ -41,7 +41,6 @@ static unsigned long totalram_pages = 0; -extern void prom_fixup_mem_map(unsigned long start, unsigned long end); extern void prom_free_prom_memory(void); @@ -270,7 +269,30 @@ free_area_init(zones_size); } -extern int page_is_ram(unsigned long pagenr); +#define PFN_UP(x) (((x) + PAGE_SIZE - 1) >> PAGE_SHIFT) +#define PFN_DOWN(x) ((x) >> PAGE_SHIFT) + +static inline int page_is_ram(unsigned long pagenr) +{ + int i; + + for (i = 0; i < boot_mem_map.nr_map; i++) { + unsigned long addr, end; + + if (boot_mem_map.map[i].type != BOOT_MEM_RAM) + /* not usable memory */ + continue; + + addr = PFN_UP(boot_mem_map.map[i].addr); + end = PFN_DOWN(boot_mem_map.map[i].addr + + boot_mem_map.map[i].size); + + if (pagenr >= addr && pagenr < end) + return 1; + } + + return 0; +} void __init mem_init(void) { diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/misc.c linux-mips-2.4.0-test5-20000731/arch/mips/orion/misc.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/misc.c Tue Jul 11 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/orion/misc.c Thu Jan 1 00:00:00 1970 @@ -1,102 +0,0 @@ -/* - * Catch-all for Orion-specify code that doesn't fit easily elsewhere. - * -- Cort - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#ifdef CONFIG_BLK_DEV_RAM -#include -#endif -#include -#ifdef CONFIG_RTC -#include -#endif - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -char arcs_cmdline[CL_SIZE] = {0, }; -extern int _end; - -static unsigned char orion_rtc_read_data(unsigned long addr) -{ - return 0; -} - -static void orion_rtc_write_data(unsigned char data, unsigned long addr) -{ -} - -static int orion_rtc_bcd_mode(void) -{ - return 0; -} - -struct rtc_ops orion_rtc_ops = { - &orion_rtc_read_data, - &orion_rtc_write_data, - &orion_rtc_bcd_mode -}; - -extern void InitCIB(void); -extern void InitQpic(void); -extern void InitCupid(void); - -void __init orion_setup(void) -{ - InitCIB(); - InitQpic(); - InitCupid(); -} - -#define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) -#define PFN_ALIGN(x) (((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK) - - - -int orion_sysinit(void) -{ - unsigned long mem_size, free_start, free_end, start_pfn, bootmap_size; - - mips_machgroup = MACH_GROUP_ORION; - /* 64 MB non-upgradable */ - mem_size = 32 << 20; - - free_start = PHYSADDR(PFN_ALIGN(&_end)); - free_end = mem_size; - start_pfn = PFN_UP((unsigned long)&_end); - - /* Register all the contiguous memory with the bootmem allocator - and free it. Be careful about the bootmem freemap. */ - bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); - - /* Free the entire available memory after the _end symbol. */ - free_start += bootmap_size; - free_bootmem(free_start, free_end-free_start); -} diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/orion/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/setup.c Tue Jul 11 04:26:06 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/orion/setup.c Sun Aug 13 18:57:53 2000 @@ -42,8 +42,7 @@ #include #include -char arcs_cmdline[CL_SIZE] = { "console=ttyS0,19200" }; -extern int _end; +char arcs_cmdline[COMMAND_LINE_SIZE] = { "console=ttyS0,19200" }; static unsigned char orion_rtc_read_data(unsigned long addr) { @@ -83,45 +82,18 @@ InitCupid(); } -#define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) -#define PFN_ALIGN(x) (((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK) - -unsigned long mem_size; int __init prom_init(int a, char **b, char **c, int *d) { - unsigned long free_start, free_end, start_pfn, bootmap_size; extern unsigned long orion_initrd_start[], orion_initrd_size; mips_machgroup = MACH_GROUP_ORION; + /* 64 MB non-upgradable */ - mem_size = 64 << 20; - - free_start = PHYSADDR(PFN_ALIGN(&_end)); - free_end = mem_size; - start_pfn = PFN_UP((unsigned long)&_end); - - /* Register all the contiguous memory with the bootmem allocator - and free it. Be careful about the bootmem freemap. */ - bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT); - - /* Free the entire available memory after the _end symbol. */ - free_start += bootmap_size; - free_bootmem(free_start, free_end-free_start); - - initrd_start = (ulong)orion_initrd_start; - initrd_end = (ulong)orion_initrd_start + (ulong)orion_initrd_size; - initrd_below_start_ok = 1; + add_memory_region(0, 64 << 20, BOOT_MEM_RAM); return 0; } void prom_free_prom_memory (void) { -} - -int page_is_ram(unsigned long pagenr) -{ - if ( pagenr < (mem_size >> PAGE_SHIFT) ) - return 1; - return 0; } diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/setup.c Mon Jul 24 04:26:01 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/setup.c Sun Aug 13 18:48:39 2000 @@ -128,15 +128,6 @@ #endif } -int __init page_is_ram(unsigned long pagenr) -{ - if (pagenr < MAP_NR(PAGE_OFFSET + 0x2000UL)) - return 1; - if (pagenr > MAP_NR(PAGE_OFFSET + 0x08002000)) - return 1; - return 0; -} - void (*board_time_init)(struct irqaction *irq); static unsigned long dosample(volatile unsigned char *tcwp, diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sni/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/sni/setup.c --- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sni/setup.c Wed Jun 21 04:26:41 2000 +++ linux-mips-2.4.0-test5-20000731/arch/mips/sni/setup.c Sun Aug 13 18:48:47 2000 @@ -101,11 +101,6 @@ printk("%s.\n", boardtype); } -int __init page_is_ram(unsigned long pagenr) -{ - return 1; -} - void __init sni_rm200_pci_setup(void) { #if 0 /* XXX Tag me deeper */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/bootinfo.h linux-mips-2.4.0-test5-20000731/include/asm-mips/bootinfo.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/bootinfo.h Tue Jul 11 04:26:27 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/bootinfo.h Sun Aug 13 20:04:00 2000 @@ -1,4 +1,4 @@ -/* $Id: bootinfo.h,v 1.11 2000/03/06 11:14:32 raiko Exp $ +/* $Id: bootinfo.h,v 2.11 2000/03/06 11:14:32 raiko Exp $ * * bootinfo.h -- Definition of the Linux/MIPS boot information structure * @@ -155,9 +155,14 @@ "R6000A", "R8000", "R10000", "R4300", "R4650", "R4700", "R5000", \ "R5000A", "R4640", "Nevada" } -#define CL_SIZE (80) +#define COMMAND_LINE_SIZE 256 -#ifndef _LANGUAGE_ASSEMBLY +#define BOOT_MEM_MAP_MAX 32 +#define BOOT_MEM_RAM 1 +#define BOOT_MEM_ROM_DATA 2 +#define BOOT_MEM_RESERVED 3 + +#ifndef __ASSEMBLY__ /* * Some machine parameters passed by the bootloaders. @@ -191,6 +196,24 @@ extern unsigned long mips_machgroup; extern unsigned long mips_tlb_entries; -#endif /* _LANGUAGE_ASSEMBLY */ +/* + * A memory map that's built upon what was determined + * or specified on the command line. + */ +struct boot_mem_map { + int nr_map; + struct { + unsigned long addr; /* start of memory segment */ + unsigned long size; /* size of memory segment */ + long type; /* type of memory segment */ + } map[BOOT_MEM_MAP_MAX]; +}; + +extern struct boot_mem_map boot_mem_map; + +extern void add_memory_region(unsigned long start, unsigned long size, + long type); + +#endif /* !__ASSEMBLY__ */ #endif /* __ASM_MIPS_BOOTINFO_H */ diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/sgialib.h linux-mips-2.4.0-test5-20000731/include/asm-mips/sgialib.h --- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/sgialib.h Tue Mar 28 04:27:20 2000 +++ linux-mips-2.4.0-test5-20000731/include/asm-mips/sgialib.h Sun Aug 13 20:29:14 2000 @@ -30,28 +30,12 @@ /* Generic printf() using ARCS console I/O. */ extern void prom_printf(char *fmt, ...); -/* Memory descriptor management. */ -#define PROM_MAX_PMEMBLOCKS 32 -struct prom_pmemblock { - unsigned long base; /* Within KSEG0. */ - unsigned int size; /* In bytes. */ - unsigned int type; /* free or prom memory */ -}; - -/* Get next memory descriptor after CURR, returns first descriptor - * in chain is CURR is NULL. - */ -extern struct linux_mdesc *prom_getmdesc(struct linux_mdesc *curr); #define PROM_NULL_MDESC ((struct linux_mdesc *) 0) /* Called by prom_init to setup the physical memory pmemblock * array. */ extern void prom_meminit(void); -extern void prom_fixup_mem_map(unsigned long start_mem, unsigned long end_mem); - -/* Returns pointer to PROM physical memory block array. */ -extern struct prom_pmemblock *prom_getpblock_array(void); /* PROM device tree library routines. */ #define PROM_NULL_COMPONENT ((pcomponent *) 0) From aaabbb@erokul.com Mon Aug 14 14:31:10 2000 Received: from viola.ocn.ne.jp (viola.ocn.ne.jp [210.190.142.45]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA24842; Mon, 14 Aug 2000 14:31:08 +0200 (MET DST) Received-Date: Mon, 14 Aug 2000 14:31:08 +0200 (MET DST) Received: from viola.ocn.ne.jp (p0064-ip01higasisibu.tokyo.ocn.ne.jp [211.0.248.64]) by viola.ocn.ne.jp (8.9.1a/OCN/) with SMTP id VAA21912 for ; Mon, 14 Aug 2000 21:30:59 +0900 (JST) Date: Mon, 14 Aug 2000 21:30:59 +0900 (JST) Message-Id: <200008141230.VAA21912@viola.ocn.ne.jp> From: =?ISO-2022-JP?B?YXp1bWl=?= To: =?ISO-2022-JP?B??= X-Mailer: Direct Email v0.22 Subject: =?ISO-2022-JP?B?GyRCPDpOaSQkJD8kNyReJDkbKEI=?= Errors-To: school@negome.com Reply-To: vibe@negome.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Length: 837 Lines: 26 $BFMA3$N%a!<%k<:NiCW$7$^$9(B $B$3$N%a!<%k$O!"CK@-8~$1$KH/Aw$5$l$F$$$k%a!<%k$G$9!#(B $BK|$,0l$44X78$N$J$$J}$KFO$-$^$7$?;~$K$O?<$/$*OM$S?=$7>e$2$^$9!#(B $B%"%@%k%H>pJs$K6=L#$NL5$$J}!"(B18$B:PL$K~$NJ}!"I,MW$N$J$$J}$O$*R2p$7$F$$$k%5%$%H$O!"$9$Y$FL5NA%5%$%H$G$9!#(B $BgS$a$k!"$7$c$V$k!"$/$o$($k!"<\H,2hA|!*!*(B $B%U%'%i%A%*$C$F$H$C$F$b5$;}$A$$$$!*!*(B $B0|$i$J=w$N;R$NFCA*%(%m%(%m%U%'%i2hA|Bg8x3+!#(B $B0l@87|L?$7$c$V$C$F$k2D0&$$4i$,$?$^$j$^$;$s!*!*(B http://210.188.239.113/fera/check.html $BA,ErEp;#L5NA2hA|(B $B2; Mon, 14 Aug 2000 13:30:33 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <39982DB5.2E150657@galileo.co.il> Date: Mon, 14 Aug 2000 13:34:46 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: DMA under embedded boards Content-Type: multipart/mixed; boundary="------------A66AD4FE6AE1E6E9045B596E" Content-Length: 993 Lines: 40 This is a multi-part message in MIME format. --------------A66AD4FE6AE1E6E9045B596E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I'm running Linux over one of our embedded systems (MIPS cpu), I would like to ask how to register the DMA capabilities of our system controller that the Linux can use them ? Is there any function such as register_netdev, but for DMA's ? (register_dma etc...) please point me to a documentations. Regards, Rabeeh --------------A66AD4FE6AE1E6E9045B596E Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------A66AD4FE6AE1E6E9045B596E-- From dom@mudchute.algor.co.uk Tue Aug 15 15:21:01 2000 Received: from waterloo.algor.co.uk (0@waterloo.algor.co.uk [193.117.190.13]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA07135; Tue, 15 Aug 2000 15:21:00 +0200 (MET DST) Received-Date: Tue, 15 Aug 2000 15:21:00 +0200 (MET DST) Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [62.254.210.199]) by waterloo.algor.co.uk (8.8.5/8.8.8) with ESMTP id OAA19202; Tue, 15 Aug 2000 14:19:27 +0100 (BST) Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id MAA07956; Tue, 15 Aug 2000 12:13:10 +0100 (GMT/BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id LAA11816; Tue, 15 Aug 2000 11:52:20 +0100 (BST) Date: Tue, 15 Aug 2000 11:52:20 +0100 (BST) Message-Id: <200008151052.LAA11816@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alorithmics Contacts Subject: Algorithmics Ltd of England have moved X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 827 Lines: 26 First, apologies to the many of you who aren't interested. I have no practical way of cleaning my list of 1000+ email contacts any further. I'll keep this brief, and if you have no interest in the new location of Algorithmics Ltd of England, please delete it now. New address: The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND New phone: +44 1223 706200 New fax: +44 1223 706250 No change to email addresses or internet names (though our IP addresses have changed, but only the very techy will notice). We have redirects on our old address and phone numbers, but propagate this change as quickly as you can. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk From ralf@uni-koblenz.de Wed Aug 16 02:25:37 2000 Received: from lappi (proxy4.cosinecom.com [208.248.148.132]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA15530; Wed, 16 Aug 2000 02:25:36 +0200 (MET DST) Received-Date: Wed, 16 Aug 2000 02:25:36 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 15 Aug 2000 17:24:28 -0700 Date: Tue, 15 Aug 2000 17:24:27 -0700 From: Ralf Baechle To: Rabeeh Khoury Cc: "linux-mips@fnet.fr" Subject: Re: DMA under embedded boards Message-ID: <20000815172427.B4267@bacchus.dhis.org> References: <39982DB5.2E150657@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39982DB5.2E150657@galileo.co.il>; from rabeeh@galileo.co.il on Mon, Aug 14, 2000 at 01:34:46PM -0400 X-Accept-Language: de,en,fr Content-Length: 591 Lines: 15 On Mon, Aug 14, 2000 at 01:34:46PM -0400, Rabeeh Khoury wrote: > I'm running Linux over one of our embedded systems (MIPS cpu), I would > like to ask how to register the DMA capabilities of our system > controller that the Linux can use them ? > > Is there any function such as register_netdev, but for DMA's ? > (register_dma etc...) No. The assumption - which only is wrong for IBM PC style DMA but that one is only used by a few legacy things like the floppy driver on PCs - is that each card has it's own DMA engine and therefore there won't be any problems with sharing it. Ralf From <@Cologne.DE:karsten@excalibur.cologne.de> Thu Aug 17 21:29:41 2000 Received: from fileserv2.Cologne.DE (fileserv2.cologne.de [195.227.25.6]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id VAA04055; Thu, 17 Aug 2000 21:29:39 +0200 (MET DST) Received-Date: Thu, 17 Aug 2000 21:29:39 +0200 (MET DST) Received: from localhost (1200 bytes) by fileserv2.Cologne.DE via rmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Thu, 17 Aug 2000 21:29:33 +0200 (CEST) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19) Received: (from karsten@localhost) by excalibur.cologne.de (8.9.3/8.8.7) id TAA02089; Thu, 17 Aug 2000 19:29:59 +0200 Message-ID: <20000817192959.B1854@excalibur.cologne.de> Date: Thu, 17 Aug 2000 19:29:59 +0200 From: Karsten Merker To: linux-mips@fnet.fr Subject: Re: PAM in mips RPM's Mail-Followup-To: linux-mips@fnet.fr References: <399C57CB.C03A3383@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <399C57CB.C03A3383@galileo.co.il>; from Rabeeh Khoury on Thu, Aug 17, 2000 at 05:23:23PM -0400 X-No-Archive: yes Content-Length: 464 Lines: 14 On Thu, Aug 17, 2000 at 05:23:23PM -0400, Rabeeh Khoury wrote: > Does any one know if the package containing the PAM works fine ? pam-0.64-2.mipsel.rpm works for me, although I had no success yet to get newer PAM versions to work correctly. HTH, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From rabeeh@galileo.co.il Thu Aug 17 16:19:28 2000 Received: from galileo5.galileo.co.il ([199.203.130.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA00730; Thu, 17 Aug 2000 16:19:25 +0200 (MET DST) Received-Date: Thu, 17 Aug 2000 16:19:25 +0200 (MET DST) Received: from galileo.co.il (rabeeh@[10.2.20.126]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id RAA04830 for ; Thu, 17 Aug 2000 17:19:06 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <399C57CB.C03A3383@galileo.co.il> Date: Thu, 17 Aug 2000 17:23:23 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: PAM in mips RPM's Content-Type: multipart/mixed; boundary="------------CB79FD8701E2F241D51935A8" Content-Length: 1057 Lines: 40 This is a multi-part message in MIME format. --------------CB79FD8701E2F241D51935A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm running Mips Linux over an embedded system where my console is over the serial. Till now I installed new packages where sometimes I had to remove the file /etc/pam.conf . Now I tried to run linux with this file but it hangs just before login prompt. I treied adjusting this file but hopeless. Does any one know if the package containing the PAM works fine ? Regards, Rabeeh --------------CB79FD8701E2F241D51935A8 Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------CB79FD8701E2F241D51935A8-- From ddg@se.mediaone.net Fri Aug 18 01:26:51 2000 Received: from duval.se.mediaone.net (duval.se.mediaone.net [24.129.0.67]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA07295; Fri, 18 Aug 2000 01:26:49 +0200 (MET DST) Received-Date: Fri, 18 Aug 2000 01:26:49 +0200 (MET DST) Received: from se.mediaone.net (dws-72-197.jacksonville.net [24.129.72.197]) by duval.se.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA05433 for ; Thu, 17 Aug 2000 19:26:33 -0400 (EDT) Message-ID: <399C74D1.7EACFFFB@se.mediaone.net> Date: Thu, 17 Aug 2000 19:27:14 -0400 From: ddg X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: RM200C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 295 Lines: 7 Hello Any ez way to load this beast. I have not been able to switch to NT (little endian). I came across a couple of these with SINIX running on them and cannot locate the firmware needed to go "little endian" Any help appreciated, thanks for time David DiGiovanni ddg@se.mediaone.net From <> Fri Aug 18 06:02:22 2000 Received: from t-mta4.odn.ne.jp (mfep4.odn.ne.jp [143.90.131.182]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA09910; Fri, 18 Aug 2000 06:02:20 +0200 (MET DST) Received-Date: Fri, 18 Aug 2000 06:02:20 +0200 (MET DST) Received: from pcg-z505-series ([210.231.52.138]) by t-mta4.odn.ne.jp (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000818040208802.QEYL.882.t-mta4.odn.ne.jp@mta4.odn.ne.jp> for ; Fri, 18 Aug 2000 13:02:08 +0900 Message-ID: <2920.966571803060@mail.white-wizard.net> Date: Fri, 18 Aug 2000 13:10:03 +0900 (JST) From: WHITE-WIZARD <> Reply-To: support@mail.white-wizard.net To: WHITE-WIZARD Subject: =?iso-2022-jp?B?GyRCOiMkXiRHJE44ITp3JTUlJCVIJEdLfkItGyhC?==?iso-2022-jp?B?GyRCJDckRiReJDkkKyEpGyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset =iso-2022-jp Content-Transfer-Encoding: 7bit Content-Length: 3245 Lines: 80 $B!=!=!=!=!=!=!!(BWHITE-WIZARD$B!!!=!=!=!=!=!=!=(B URL: http://www.white-wizard.net e-mail: support@mail.white-wizard.net $B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $BA0(BHP$B$N:]$N$4EPO?$"$j$,$H$&$4$6$$$^$9!#(B $B$3$NEY!"(BWHITE-WIZARD$B$O%5%$%H%^%,%8%s$r3+@_$$$?$7$^$7$?!#(B $B!!(B $B%5%$%H%^%,%8%s$H$O%5%$%H4IM}R2p$r8+$F5$$KF~$C$?$H$3$m(B $B$rK,Ld$9$k$H$$$C$?$^$C$?$/?7$7$$%?%$%W$N>pJsDs6!%5!<%S%9$G$9!#(B $B8!:w%5%$%H$G$OC5$7$F$$$k%5%$%H$KK\Ev$K=P2q$($k$G$7$g$&$+!)(B WHITE-WIZARD$B$G$O!"2hA|$dR2p$r>\$7$/=q$+$l$F$$$k$N$G$*5RMM$,A*$P$l$k$N$K;29M$K$J$j$^$9!#(B $B$^$?!"2hA|$r%/%j%C%/$9$k$@$1$GEPO?%5%$%H$K%8%c%s%W$$$?$7$^$9!#(B $B$J$*!"$3$N%7%9%F%`$O$?$@$$$^FC5v=P4jCf$G$9!#(B $B!!!!!!!!(B WHITE-WIZARD$B$N7G:\FbMF$O!"(BWHITE-WIZARD$B$,87A*$7$?%5%$%H$r07$C$F$*$j$^$9!#(B $B$^$:$O$4MhE9$$$?$@$-8+3X$7$F$_$F$/$@$5$$!#(B $B!!$3$N%a!<%k$OA0%5%$%H$KEPO?$5$l$?$*5RMM$KG[?.$r$7$F$$$^$9!#(B $B%a!<%kG[?.$r$44uK>$5$l$k$*5RMM$O2<5-$N(BURL$B$h$j$4EPO?$r$*4j$$$7$^$9!#(B WHITE-WIZARD$B%5%$%H$X$O(B http://www.white-wizard.net $B$+$i$I$&$>(B $B!!!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B7G:\EPO?$rR2p$9$k$3$H$d!"(BWHITE-WIZARD$B$KMhE9$5$l(B $B2hA|$r1\Mw$5$l$k$3$H$K$h$j!"$H$F$b$9$P$d$$Mh5R?t$NA}2C$,8+9~$^$l$^$9!#(B $B$=$3$G!"A0$N(BHP$B$G$4EPO?$5$l$?J}$K8B$j!"H>3[%5!<%S%9$r$h$m$7$/$*4j$$$$$?$7$^$9!#(B $B$4EPO?$O$3$A$i!!(Bhttp://www.white-wizard.net $B$J$*!"%j%s%/%Z!<%8$,$"$k$*5RMM$O$4EPO?$r$*4j$$$$$?$7$^$9!#(B $B!!!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B WHITE-WIZARD$B$+$i$N%a!<%k$,?H$K3P$($N$J$$$*5RMM$X(B $B!!BgJQ?=$7Lu$4$6$$$^$;$s!#$*5RMM$N%"%I%l%9$,!"$[$+$NEPO?$5$l$?$*5RMM$N5$/$@$5$$!#(B $B!!!!!!!!!!!!!!!!(B http://www.white-wizard.net $B!!!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B $B!!!!!!!!!!!!!!!!!v!v!v!v!v!vM-8B2q@n!!E0(B $B$J$*!"(BTEL$B$G$N$*Ld$$9g$o$;$O$41sN8$/$@$5$$!#(B From agreaterliving@altavista.com Sat Aug 19 05:02:51 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA19713; Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:03:24 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From agreaterliving@altavista.com Sat Aug 19 05:02:51 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA19713; Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:03:24 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From agreaterliving@altavista.com Sat Aug 19 05:02:51 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA19713; Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:02:49 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:03:24 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From agreaterliving@altavista.com Sat Aug 19 05:49:58 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA20794; Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:50:31 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From agreaterliving@altavista.com Sat Aug 19 05:49:58 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA20794; Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:50:31 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From agreaterliving@altavista.com Sat Aug 19 05:49:58 2000 Received: from enrichkylie (mplsdslgw9poolD87.mpls.uswest.net [63.228.51.87]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id FAA20794; Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 05:49:57 +0200 (MET DST) From: "A Greater Living!" To: Subject: As Seen On TV! ... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 18 Aug 2000 22:50:31 Content-Length: 308 Lines: 13 Finally! Would you like to lose 10 to 16 pounds in two weeks? Feel lighter and more energetic? . . . Yes! This recipes program is almost free! and there is nothing else to buy. The catch? You must eat more!!! Why Is This Program Different From Many Others? . . . Visit us at: www.agreaterliving.com From adult1@dream.com Sat Aug 19 18:47:46 2000 Received: from pop05.dreamnet.ne.jp (smtp5.dreamnet.ne.jp [202.217.109.101]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA29217; Sat, 19 Aug 2000 18:47:44 +0200 (MET DST) Received-Date: Sat, 19 Aug 2000 18:47:44 +0200 (MET DST) Received: from LIVE ([202.217.122.139]) by pop05.dreamnet.ne.jp with SMTP id <20000819164739.OICB3043.pop05.dreamnet.ne.jp@LIVE> for ; Sun, 20 Aug 2000 01:47:39 +0900 Message-ID: <3417.966703808805@dream.com> Date: Sun, 20 Aug 2000 01:50:08 +0900 (JST) From: =?iso-2022-jp?B?GyRCJSIlQCVrJUglUSVpJUAlJCU5GyhCGyhC?= Reply-To: adult1@dream.com To: =?iso-2022-jp?B??= Subject: =?iso-2022-jp?B?GyRCIXpMNU5BRjAyaCU1ITwlUyU5GyhCGyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset =ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Length: 581 Lines: 14 $BFMA3$N%a!<%k??$K?=$7Lu$4$6$$$^$;$s!!I,MW$N$J$$J}$KFO$$$F$7$^$C$?;~$K$O(B $B!!?<$/$*OM$S$r?=$7>e$2$k$H6&$K!!:#8e0l@Z$N%a!<%k$O$*Aw$j$7$^$;$s$N$G$*(B $B To: linux-mips@fnet.fr, linux-mips@oss.sgi.com cc: Arnaldo Carvalho de Melo Subject: [PATCH] dz.c: cleanups, getting rid of panic and suser (fwd) Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 5572 Lines: 186 Hi, Here is what I got from linux-kernel today. I thought someone might be interested. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ---------- Forwarded message ---------- Message-ID: <20000824194303.B3047@conectiva.com.br> Date: Thu, 24 Aug 2000 19:43:03 -0300 From: Arnaldo Carvalho de Melo To: "Olivier A.D.Lebaillif" Cc: linux-kernel@vger.kernel.org Subject: [PATCH] dz.c: cleanups, getting rid of panic and suser Hi, Please take a look and consider applying. - Arnaldo --- linux-2.4.0-test7/drivers/char/dz.c Mon Jun 26 22:03:05 2000 +++ linux-2.4.0-test7.acme/drivers/char/dz.c Thu Aug 24 19:41:53 2000 @@ -17,6 +17,10 @@ * * Parts (C) 1999 David Airlie, airlied@linux.ie * [07-SEP-99] Bugfixes + * + * Arnaldo Carvalho de Melo 08/23/2000 + * - get rid of verify_area, panics and suser, using !capable(CAP_SYS_ADMIN) now + * - include missing restore_flags in dz_init */ #define DEBUG_DZ 1 @@ -844,14 +848,16 @@ struct dz_serial old_info; int retval = 0; + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + if (!new_info) return -EFAULT; - copy_from_user (&new_serial, new_info, sizeof(new_serial)); - old_info = *info; + if (copy_from_user(&new_serial, new_info, sizeof(new_serial))) + return -EFAULT; - if (!suser()) - return -EPERM; + old_info = *info; if (info->count > 1) return -EBUSY; @@ -919,7 +925,6 @@ static int dz_ioctl (struct tty_struct *tty, struct file *file, unsigned int cmd, unsigned long arg) { - int error; struct dz_serial * info = (struct dz_serial *)tty->driver_data; int retval; @@ -949,40 +954,30 @@ return 0; case TIOCGSOFTCAR: - error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(long)); - if (error) - return error; - put_user (C_CLOCAL(tty) ? 1 : 0, (unsigned long *)arg); - return 0; + return put_user (C_CLOCAL(tty) ? 1 : 0, (unsigned long *)arg); case TIOCSSOFTCAR: - error = get_user (arg, (unsigned long *)arg); - if (error) - return error; + if (get_user (arg, (unsigned long *)arg)) + return -EFAULT; tty->termios->c_cflag = ((tty->termios->c_cflag & ~CLOCAL) | (arg ? CLOCAL : 0)); return 0; case TIOCGSERIAL: - error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct serial_struct)); - if (error) - return error; + if (verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct serial_struct))) + return -EFAULT; return get_serial_info (info, (struct serial_struct *)arg); case TIOCSSERIAL: return set_serial_info (info, (struct serial_struct *) arg); case TIOCSERGETLSR: /* Get line status register */ - error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(unsigned int)); - if (error) - return error; - else - return get_lsr_info (info, (unsigned int *)arg); + if (verify_area (VERIFY_WRITE, (void *)arg, sizeof(unsigned int))) + return -EFAULT; + return get_lsr_info (info, (unsigned int *)arg); case TIOCSERGSTRUCT: - error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct dz_serial)); - if (error) - return error; - copy_to_user((struct dz_serial *)arg, info, sizeof(struct dz_serial)); + if (copy_to_user((struct dz_serial *)arg, info, sizeof(struct dz_serial))) + return -EFAULT; return 0; default: @@ -1290,7 +1285,7 @@ int __init dz_init(void) { - int i, flags; + int i, flags, ret; struct dz_serial *info; /* Setup base handler, and timer table. */ @@ -1340,10 +1335,16 @@ callout_driver.major = TTYAUX_MAJOR; callout_driver.subtype = SERIAL_TYPE_CALLOUT; - if (tty_register_driver (&serial_driver)) - panic("Couldn't register serial driver\n"); - if (tty_register_driver (&callout_driver)) - panic("Couldn't register callout driver\n"); + ret = tty_register_driver (&serial_driver); + if (ret) { + printk(KERN_ERR "Couldn't register serial driver\n"); + return ret; + } + ret = tty_register_driver (&callout_driver); + if (ret) { + printk(KERN_ERR "Couldn't register callout driver\n"); + goto cleanup_serial_driver; + } save_flags(flags); cli(); for (i=0; i < DZ_NB_PORT; i++) @@ -1376,8 +1377,10 @@ /* If we are pointing to address zero then punt - not correctly set up in setup.c to handle this. */ - if (! info->port) + if (!info->port) { + restore_flags(flags); return 0; + } printk("ttyS%02d at 0x%04x (irq = %d)\n", info->line, info->port, SERIAL); } @@ -1396,12 +1399,17 @@ is updated... in request_irq - to immediatedly obliterate it is unwise. */ restore_flags(flags); - - if (request_irq (SERIAL, dz_interrupt, SA_INTERRUPT, "DZ", lines[0])) - panic ("Unable to register DZ interrupt\n"); + if (request_irq (SERIAL, dz_interrupt, SA_INTERRUPT, "DZ", lines[0])) { + printk(KERN_ERR "Unable to register DZ interrupt\n"); + ret = -EBUSY; + goto cleanup_callout_driver; + } return 0; +cleanup_callout_driver: tty_unregister_driver(&callout_driver); +cleanup_serial_driver: tty_unregister_driver(&serial_driver); + return ret; } #ifdef CONFIG_SERIAL_CONSOLE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ From jsun@mvista.com Sat Aug 26 02:44:53 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA26727; Sat, 26 Aug 2000 02:44:52 +0200 (MET DST) Received-Date: Sat, 26 Aug 2000 02:44:52 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id RAA22039; Fri, 25 Aug 2000 17:44:14 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39A712DD.1BA2A1CF@mvista.com> Date: Fri, 25 Aug 2000 17:44:13 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux@engr.sgi.com, linux-mips@fnet.fr Subject: [Fwd: voodoo3 2000pci hangs with Linux framebuffer driver ...] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1036 Lines: 37 Jun Sun wrote: > > I bought a V3 2000PCI card and plug it into an embedded MIPS board. I > enabled the framebuffer driver for voodoo3. The driver hangs during > initializtion stage (tdfxfb_init()). > > bashee_make_room() is where cpu is doing an infinite loop. The STATUS > register value is 0x0c200000. It is the first long word in the > prefetchable (2nd) PCI memory block requested by the card. > > Does anybody know what bashee_make_room() is doing? what is wrong > here? What steps are missing? Note there is not vga bios on this > board. > > Also, where can I find the spec for V3 2kpci card? > > Thanks. > > Jun > > tdfxfb_init() > { > .... > /* disable block writes for SDRAM (why?) */ > miscinit1 = tdfx_inl(MISCINIT1); > miscinit1 |= sgram_p ? 0 : MISCINIT1_2DBLOCK_DIS; > miscinit1 |= MISCINIT1_CLUT_INV; > > banshee_make_room(1); > tdfx_outl(MISCINIT1, miscinit1); > > return lfbsize; > } > > static inline void banshee_make_room(int size) { > while((tdfx_inl(STATUS) & 0x1f) < size); > } From rabeeh@galileo.co.il Mon Aug 28 10:52:35 2000 Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA14282; Mon, 28 Aug 2000 10:52:31 +0200 (MET DST) Received-Date: Mon, 28 Aug 2000 10:52:31 +0200 (MET DST) Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id LAA26646 for ; Mon, 28 Aug 2000 11:52:13 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <39AA8BBF.23E531B1@galileo.co.il> Date: Mon, 28 Aug 2000 11:56:47 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: RPM installation order Content-Type: multipart/mixed; boundary="------------5917FC42731794F55D7F1199" Content-Length: 758 Lines: 33 This is a multi-part message in MIME format. --------------5917FC42731794F55D7F1199 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, What is the order in which I have to install the mipseb RPM's ? Regards, Rabeeh --------------5917FC42731794F55D7F1199 Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------5917FC42731794F55D7F1199-- From mika@webnewsnets.com Tue Aug 29 00:49:46 2000 Received: from q4.webnewsnets.com ([64.132.2.242]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA20521; Tue, 29 Aug 2000 00:49:44 +0200 (MET DST) Received-Date: Tue, 29 Aug 2000 00:49:44 +0200 (MET DST) Received: from HANK ([64.132.2.245]) by q4.webnewsnets.com (8.10.2/8.10.2) with SMTP id e7SMQpi22219; Mon, 28 Aug 2000 12:26:52 -1000 Date: Mon, 28 Aug 2000 12:26:52 -1000 From: mika Message-Id: <200008282226.e7SMQpi22219@q4.webnewsnets.com> To: youyou@guamisland.ne.jp Subject: @-@ Content-Length: 312 Lines: 18 芸能界の裏サイト、みつけたよ!!! 深田恭子とか、優香のエッチ写真とか・・・。 ほかにも、いろんな芸能人もの、あるんだけど・・・ これ、マジだったら、けっこうすごいよね。 ただで見れるサンプル映像もあるから ま、暇なときにでもチェックしてみてね。 http://www.zephyr.dti.ne.jp/~cstewart/123/idol.html じゃ。 みか From idol1256@hotmail.com Tue Aug 29 19:48:25 2000 Received: from smtp02.mem.interq.net (smtp02.mem.interq.net [210.157.1.52]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA28199; Tue, 29 Aug 2000 19:48:24 +0200 (MET DST) Received-Date: Tue, 29 Aug 2000 19:48:24 +0200 (MET DST) Received: from smtp.members.interq.or.jp (osaka-ppp-210-172-184-181.interq.or.jp [210.172.184.181]) by smtp02.mem.interq.net (8.9.3/8.9.1/matt89-pop) with SMTP id CAA07290 for ; Wed, 30 Aug 2000 02:53:49 +0900 (JST) Date: Wed, 30 Aug 2000 02:53:49 +0900 (JST) Message-Id: <200008291753.CAA07290@smtp02.mem.interq.net> From: =?ISO-2022-JP?B?GyRCJSolVSUjJTklIiUkJUklaxsoQh==?= To: =?ISO-2022-JP?B?bGludXgtbWlwc0BmbmV0LmZy?= X-Mailer: Direct Email v0.22 Subject: =?ISO-2022-JP?B?GyRCOkc/NyUiJSQlSSVrPnBKcyU1JSQlSCFYJSIlJCVJJWslUSVLJUMlLyFZMytAXyROJDQwRkZiGyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Length: 874 Lines: 23 $B:G?7%"%$%I%k>pJs%5%$%H!X%"%$%I%k%Q%K%C%/!Y3+@_$N$40FFb(B $BFMA3$N%a!<%k$K$F!"BgJQ<:Ni$$$?$7$^$9!#(B $B$3$NEY!"%"%$%I%k$N:G?7>pJs%5%$%H!X%"%$%I%k%Q%K%C%/!Y$r3+@_CW$7$^$7$?$N$G(B $B$40FFbCW$7$^$9(B!! $B"&"'"&"'"&"'"&"'"&"'"&(B $B!V%"%$%I%k%Q%K%C%/!W(B -------------------- http://idol.dnaj.org/ $B"$"%"$"%"$"%"$"%"$"%"$(B $B%"%$%I%k%Q%K%C%/$G$O!"9qL1E*%"%$%I%k$+$i!"Gd=P$7Cf$N%"%$%I%k!"99$K$O(B $B$^$b$J$/GzH/E*?M5$$H$J$k4|BTBg$N%"%$%I%k$N%?%^%4$^$GI}9-$/%U%)%m!<$7!"(B $B$$$AAa$/!"3'MM$K?7A/$J%"%$%I%k$N:G?7>pJs$r$4Ds6!$9$k$Y$/!"F|!9J3F.Cf$G$9!#(B $B$J$*!":#8e$NM=Dj$H$7$^$7$F!"%a!<%k%^%,%8%sH/9T$bM=Dj$7$F$*$j$^$9$N$G(B $B$44|BT2<$5$$(B!! $B>0!"G[?.$K$OK|A4$NCm0U$rJ'$C$F$*$j$^$9$,!"(B $BK|$,0lI,MW$NL5$$J}$KFO$$$?>l9g$O!"?<$/$*OM$S?=$7$"$2$^$9$H$H$b$K(B $B%a!<%j%s%0%j%9%H$+$i:o=|$7$^$9$N$G$40lJs$$$?$@$-$^$9$h$&$*4j$$?=$7>e$2$^$9!#(B From Sandeep_Kumar@neomagic.com Thu Aug 31 02:37:44 2000 Received: from neomagic.com (mailhost.neomagic.com [207.21.82.7]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA13163; Thu, 31 Aug 2000 02:37:42 +0200 (MET DST) Received-Date: Thu, 31 Aug 2000 02:37:42 +0200 (MET DST) Received: from pcindia0.neomagic ([172.16.2.32]) by neomagic.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7V0YW502819 for ; Wed, 30 Aug 2000 17:37:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20000830172254.00b02cb0@popserver> X-Sender: sandeep@popserver X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Aug 2000 17:23:35 -0700 To: linux-mips@fnet.fr From: Sandeep Kumar Subject: some help needed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 71 Lines: 1 can anyone tell me how to call C funtion from assembly, in detail pls. From jsun@mvista.com Thu Aug 31 05:15:44 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA15618; Thu, 31 Aug 2000 05:15:43 +0200 (MET DST) Received-Date: Thu, 31 Aug 2000 05:15:43 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id UAA19849; Wed, 30 Aug 2000 20:15:05 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39ADCDB9.FD67ADEB@mvista.com> Date: Wed, 30 Aug 2000 20:15:05 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: Sandeep Kumar CC: linux-mips@fnet.fr Subject: Re: some help needed References: <4.3.2.7.2.20000830172254.00b02cb0@popserver> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 434 Lines: 16 Sandeep Kumar wrote: > > can anyone tell me how to call C funtion from assembly, in detail pls. Assuming your C function will return back to the assembly code, you can simply use: jal myCFunc The first four integer arguments are passed through a0-a3, and the integer return is put in v0. For more complicated arguments and return values, I suggest you read the book: MIPS RISC Architecture, by Gerry Kane and Joe Heinrich. Jun From webster@weboptimization.net Thu Aug 31 13:03:17 2000 Received: from mail.rdc2.occa.home.com (imail@ha1.rdc2.occa.home.com [24.2.8.66]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA19671; Thu, 31 Aug 2000 13:03:16 +0200 (MET DST) Received-Date: Thu, 31 Aug 2000 13:03:16 +0200 (MET DST) From: webster@weboptimization.net Received: from brad ([24.13.182.37]) by mail.rdc2.occa.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000831110313.YEXK11948.mail.rdc2.occa.home.com@brad> for ; Thu, 31 Aug 2000 04:03:13 -0700 To: Subject: Website Optimization.net top search engine ranking MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-Id: <20000831110313.YEXK11948.mail.rdc2.occa.home.com@brad> Date: Thu, 31 Aug 2000 04:03:14 -0700 Content-Length: 1302 Lines: 27 There are hundreds of submission sites available on the internet; this is not simply submission. Our experts personally work with your site to optimize one of the most important factors of your advertising, marketing, and/or business solutions. With almost one billion web pages vying for eyeballs and traffic, aggressive -- even guerilla -- website marketing tactics are critical. Recent studies indicate 85% of web visitors are referred by search engines. To capture your share of that targeted traffic, you will need to be well positioned in the major search engines and directories. Find out how web site marketing can get you top search engine rankings and increase your hits. We specialize in helping small business sites succeed. Our affordable search engine positioning package can get your site the top rankings and attention it deserves. Once the traffic is heading your way, we will work with you personally to develop a complete web site marketing strategy. We will help you build customer trust and loyalty as well as find multiple affordable online advertising opportunities. If you are no longer interested in receiving email from us please click the link below: http://www.WebsiteOptimization.net/r.phpi=bestbiz&e= Visit us at: http://www.WebsiteOptimization.net