From hvr@gnu.org Mon May 1 14:45:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 14:46:11 +0100 (BST) Received: from fencepost.gnu.org ([199.232.76.164]:63373 "EHLO fencepost.gnu.org") by ftp.linux-mips.org with ESMTP id S8133397AbWEANp6 (ORCPT ); Mon, 1 May 2006 14:45:58 +0100 Received: from hvr by fencepost.gnu.org with local (Exim 4.34) id 1FaYil-0007A8-HB; Mon, 01 May 2006 09:45:51 -0400 To: jgarzik@pobox.com Cc: netdev@vger.kernel.org, linux-mips@linux-mips.org, sshtylyov@ru.mvista.com From: Herbert Valerio Riedel Date: Mon May 1 15:37:09 2006 +0200 Subject: [PATCH] au1000_eth.c: use ether_crc() from Message-Id: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips since the au1000 driver already selects the CRC32 routines, simply replace the internal ether_crc() implementation with the semantically equivalent one from Signed-off-by: Herbert Valerio Riedel --- drivers/net/au1000_eth.c | 18 +----------------- 1 files changed, 1 insertions(+), 17 deletions(-) 9360df5368deaaaa8fc7dcaacf9b7ca446af94c4 diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c index 29adebb..0823cb8 100644 --- a/drivers/net/au1000_eth.c +++ b/drivers/net/au1000_eth.c @@ -52,6 +52,7 @@ #include #include #include +#include #include #include #include @@ -2070,23 +2071,6 @@ static void au1000_tx_timeout(struct net netif_wake_queue(dev); } - -static unsigned const ethernet_polynomial = 0x04c11db7U; -static inline u32 ether_crc(int length, unsigned char *data) -{ - int crc = -1; - - while(--length >= 0) { - unsigned char current_octet = *data++; - int bit; - for (bit = 0; bit < 8; bit++, current_octet >>= 1) - crc = (crc << 1) ^ - ((crc < 0) ^ (current_octet & 1) ? - ethernet_polynomial : 0); - } - return crc; -} - static void set_rx_mode(struct net_device *dev) { struct au1000_private *aup = (struct au1000_private *) dev->priv; -- 1.2.6 From hvr@gnu.org Mon May 1 20:09:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 20:09:52 +0100 (BST) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:59064 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S8133466AbWEATJe (ORCPT ); Mon, 1 May 2006 20:09:34 +0100 Received: from mini.intra (dhcp-1432-30.blizz.at [213.143.126.4]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k41J9D8P000542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 May 2006 21:09:18 +0200 Subject: RFC: au1000_etc.c phylib rewrite From: Herbert Valerio Riedel To: Pete Popov Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CRavCE66iNmA7KvOUpw4" Organization: Free Software Foundation Date: Mon, 01 May 2006 21:09:02 +0200 Message-Id: <1146510542.16643.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: ClamAV 0.88.1/1433/Mon May 1 10:10:05 2006 on phobos.hvrlab.org X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips --=-CRavCE66iNmA7KvOUpw4 Content-Type: multipart/mixed; boundary="=-ASCzkIEkSfwkp9HUWIX1" --=-ASCzkIEkSfwkp9HUWIX1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hello *, I've started to rewrite the au1000_eth.c driver to make use of the new PHY framework in 2.6.x; see the attached patch for the current work in progress state; I'm a bit unsure what to do about those workarounds/hacks that are in the original au1000_eth.c driver (e.g. for the broadcom dual PHY); any comments/ideas? shall I continue work on this au1xxx-eth phylib-rewrite, or is it of no use? regards, hvr --=-ASCzkIEkSfwkp9HUWIX1 Content-Disposition: attachment; filename=au1000_eth_rewrite.patch Content-Type: text/x-patch; name=au1000_eth_rewrite.patch; charset=UTF-8 Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L0tjb25maWcgYi9kcml2ZXJzL25ldC9LY29uZmlnDQpp bmRleCAxZWRjYzBjLi45M2Y2ZWYwIDEwMDY0NA0KLS0tIGEvZHJpdmVycy9uZXQvS2NvbmZpZw0K KysrIGIvZHJpdmVycy9uZXQvS2NvbmZpZw0KQEAgLTQ1NSw2ICs0NTUsNyBAQCBjb25maWcgTUlQ U19HVDk2MTAwRVRIDQogY29uZmlnIE1JUFNfQVUxWDAwX0VORVQNCiAJYm9vbCAiTUlQUyBBVTEw MDAgRXRoZXJuZXQgc3VwcG9ydCINCiAJZGVwZW5kcyBvbiBORVRfRVRIRVJORVQgJiYgU09DX0FV MVgwMA0KKwlzZWxlY3QgUEhZTElCDQogCXNlbGVjdCBDUkMzMg0KIAloZWxwDQogCSAgSWYgeW91 IGhhdmUgYW4gQWxjaGVteSBTZW1pIEFVMVgwMCBiYXNlZCBzeXN0ZW0NCmRpZmYgLS1naXQgYS9k cml2ZXJzL25ldC9hdTEwMDBfZXRoLmMgYi9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmMNCmluZGV4 IDA4MjNjYjguLmE4NmIxOTAgMTAwNjQ0DQotLS0gYS9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmMN CisrKyBiL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguYw0KQEAgLTUzLDYgKzUzLDcgQEANCiAjaW5j bHVkZSA8bGludXgvc2tidWZmLmg+DQogI2luY2x1ZGUgPGxpbnV4L2RlbGF5Lmg+DQogI2luY2x1 ZGUgPGxpbnV4L2NyYzMyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3BoeS5oPg0KICNpbmNsdWRlIDxh c20vbWlwc3JlZ3MuaD4NCiAjaW5jbHVkZSA8YXNtL2lycS5oPg0KICNpbmNsdWRlIDxhc20vaW8u aD4NCkBAIC04OCwxNCArODksMTIgQEAgc3RhdGljIGludCBhdTEwMDBfdHgoc3RydWN0IHNrX2J1 ZmYgKiwgcw0KIHN0YXRpYyBpbnQgYXUxMDAwX3J4KHN0cnVjdCBuZXRfZGV2aWNlICopOw0KIHN0 YXRpYyBpcnFyZXR1cm5fdCBhdTEwMDBfaW50ZXJydXB0KGludCwgdm9pZCAqLCBzdHJ1Y3QgcHRf cmVncyAqKTsNCiBzdGF0aWMgdm9pZCBhdTEwMDBfdHhfdGltZW91dChzdHJ1Y3QgbmV0X2Rldmlj ZSAqKTsNCi1zdGF0aWMgaW50IGF1MTAwMF9zZXRfY29uZmlnKHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYsIHN0cnVjdCBpZm1hcCAqbWFwKTsNCiBzdGF0aWMgdm9pZCBzZXRfcnhfbW9kZShzdHJ1Y3Qg bmV0X2RldmljZSAqKTsNCiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKmF1MTAwMF9n ZXRfc3RhdHMoc3RydWN0IG5ldF9kZXZpY2UgKik7DQotc3RhdGljIHZvaWQgYXUxMDAwX3RpbWVy KHVuc2lnbmVkIGxvbmcpOw0KIHN0YXRpYyBpbnQgYXUxMDAwX2lvY3RsKHN0cnVjdCBuZXRfZGV2 aWNlICosIHN0cnVjdCBpZnJlcSAqLCBpbnQpOw0KIHN0YXRpYyBpbnQgbWRpb19yZWFkKHN0cnVj dCBuZXRfZGV2aWNlICosIGludCwgaW50KTsNCiBzdGF0aWMgdm9pZCBtZGlvX3dyaXRlKHN0cnVj dCBuZXRfZGV2aWNlICosIGludCwgaW50LCB1MTYpOw0KLXN0YXRpYyB2b2lkIGR1bXBfbWlpKHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQpOw0KK3N0YXRpYyB2b2lkIGF1MTAwMF9h ZGp1c3RfbGluayhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsNCiANCiAvLyBleHRlcm5zDQogZXh0 ZXJuICB2b2lkIGFja19yaXNlX2VkZ2VfaXJxKHVuc2lnbmVkIGludCk7DQpAQCAtMTM1LDY1OCAr MTM0LDI3IEBAIHN0YXRpYyB1bnNpZ25lZCBjaGFyIGF1MTAwMF9tYWNfYWRkcls2XSANCiANCiBz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1X21hY3NbTlVNX0VUSF9JTlRFUkZBQ0VTXTsNCiANCi0v KiBGSVhNRSANCi0gKiBBbGwgb2YgdGhlIFBIWSBjb2RlIHJlYWxseSBzaG91bGQgYmUgZGV0YWNo ZWQgZnJvbSB0aGUgTUFDIA0KLSAqIGNvZGUuDQotICovDQotDQotLyogRGVmYXVsdCBhZHZlcnRp c2UgKi8NCi0jZGVmaW5lIEdFTk1JSV9ERUZBVUxUX0FEVkVSVElTRSBcDQotCUFEVkVSVElTRURf MTBiYXNlVF9IYWxmIHwgQURWRVJUSVNFRF8xMGJhc2VUX0Z1bGwgfCBcDQotCUFEVkVSVElTRURf MTAwYmFzZVRfSGFsZiB8IEFEVkVSVElTRURfMTAwYmFzZVRfRnVsbCB8IFwNCi0JQURWRVJUSVNF RF9BdXRvbmVnDQotDQotI2RlZmluZSBHRU5NSUlfREVGQVVMVF9GRUFUVVJFUyBcDQotCVNVUFBP UlRFRF8xMGJhc2VUX0hhbGYgfCBTVVBQT1JURURfMTBiYXNlVF9GdWxsIHwgXA0KLQlTVVBQT1JU RURfMTAwYmFzZVRfSGFsZiB8IFNVUFBPUlRFRF8xMDBiYXNlVF9GdWxsIHwgXA0KLQlTVVBQT1JU RURfQXV0b25lZw0KLQ0KLWludCBiY21fNTIwMV9pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYs IGludCBwaHlfYWRkcikNCi17DQotCXMxNiBkYXRhOw0KLQkNCi0JLyogU3RvcCBhdXRvLW5lZ290 aWF0aW9uICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wp Ow0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhICYgfk1JSV9D TlRMX0FVVE8pOw0KLQ0KLQkvKiBTZXQgYWR2ZXJ0aXNlbWVudCB0byAxMC8xMDAgYW5kIEhhbGYv RnVsbCBkdXBsZXgNCi0JICogKGZ1bGwgY2FwYWJpbGl0aWVzKSAqLw0KLQlkYXRhID0gbWRpb19y ZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9BTkFEVik7DQotCWRhdGEgfD0gTUlJX05XQVlfVFggfCBN SUlfTldBWV9UWF9GRFggfCBNSUlfTldBWV9UX0ZEWCB8IE1JSV9OV0FZX1Q7DQotCW1kaW9fd3Jp dGUoZGV2LCBwaHlfYWRkciwgTUlJX0FOQURWLCBkYXRhKTsNCi0JDQotCS8qIFJlc3RhcnQgYXV0 by1uZWdvdGlhdGlvbiAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9D T05UUk9MKTsNCi0JZGF0YSB8PSBNSUlfQ05UTF9SU1RfQVVUTyB8IE1JSV9DTlRMX0FVVE87DQot CW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEpOw0KLQ0KLQlpZiAo YXUxMDAwX2RlYnVnID4gNCkgDQotCQlkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0JcmV0dXJu IDA7DQotfQ0KLQ0KLWludCBiY21fNTIwMV9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBp bnQgcGh5X2FkZHIpDQotew0KLQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVvdXQ7DQotCQ0KLQltaWlf Y29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCW1kaW9f d3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIG1paV9jb250cm9sIHwgTUlJX0NOVExf UkVTRVQpOw0KLQltZGVsYXkoMSk7DQotCWZvciAodGltZW91dCA9IDEwMDsgdGltZW91dCA+IDA7 IC0tdGltZW91dCkgew0KLQkJbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQkJaWYgKChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSA9PSAw KQ0KLQkJCWJyZWFrOw0KLQkJbWRlbGF5KDEpOw0KLQl9DQotCWlmIChtaWlfY29udHJvbCAmIE1J SV9DTlRMX1JFU0VUKSB7DQotCQlwcmludGsoS0VSTl9FUlIgIiVzIFBIWSByZXNldCB0aW1lb3V0 ICFcbiIsIGRldi0+bmFtZSk7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0K LQ0KLWludCANCi1iY21fNTIwMV9zdGF0dXMoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBo eV9hZGRyLCB1MTYgKmxpbmssIHUxNiAqc3BlZWQpDQotew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0 cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwOw0KLQ0KLQlpZiAoIWRldikgew0KLQkJcHJpbnRrKEtF Uk5fRVJSICJiY21fNTIwMV9zdGF0dXMgZXJyb3I6IE5VTEwgZGV2XG4iKTsNCi0JCXJldHVybiAt MTsNCi0JfQ0KLQlhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0N Ci0JbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfU1RBVFVTKTsN Ci0JaWYgKG1paV9kYXRhICYgTUlJX1NUQVRfTElOSykgew0KLQkJKmxpbmsgPSAxOw0KLQkJbWlp X2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQVVYX0NOVFJMKTsNCi0J CWlmIChtaWlfZGF0YSAmIE1JSV9BVVhfMTAwKSB7DQotCQkJaWYgKG1paV9kYXRhICYgTUlJX0FV WF9GRFgpIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJCWRldi0+aWZf cG9ydCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCX0NCi0JCQllbHNlIHsNCi0JCQkJKnNwZWVk ID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFT RVRYOw0KLQkJCX0NCi0JCX0NCi0JCWVsc2UgIHsNCi0JCQkqc3BlZWQgPSBJRl9QT1JUXzEwQkFT RVQ7DQotCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJfQ0KLQ0KLQl9DQot CWVsc2Ugew0KLQkJKmxpbmsgPSAwOw0KLQkJKnNwZWVkID0gMDsNCi0JCWRldi0+aWZfcG9ydCA9 IElGX1BPUlRfVU5LTk9XTjsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGxzaV84MDIy N19pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCWlmIChh dTEwMDBfZGVidWcgPiA0KQ0KLQkJcHJpbnRrKCJsc2lfODAyMjdfaW5pdFxuIik7DQotDQotCS8q IHJlc3RhcnQgYXV0by1uZWdvdGlhdGlvbiAqLw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIs IE1JSV9DT05UUk9MLA0KLQkJICAgTUlJX0NOVExfRjEwMCB8IE1JSV9DTlRMX0FVVE8gfCBNSUlf Q05UTF9SU1RfQVVUTyk7IC8vIHwgTUlJX0NOVExfRkRYKTsNCi0JbWRlbGF5KDEpOw0KLQ0KLQkv KiBzZXQgdXAgTEVEcyB0byBjb3JyZWN0IGRpc3BsYXkgKi8NCi0jaWZkZWYgQ09ORklHX01JUFNf TVRYMQ0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIDE3LCAweGZmODApOw0KLSNlbHNlDQot CW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgMTcsIDB4ZmZjMCk7DQotI2VuZGlmDQotDQotCWlm IChhdTEwMDBfZGVidWcgPiA0KQ0KLQkJZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotCXJldHVy biAwOw0KLX0NCi0NCi1pbnQgbHNpXzgwMjI3X3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYs IGludCBwaHlfYWRkcikNCi17DQotCXMxNiBtaWlfY29udHJvbCwgdGltZW91dDsNCi0JDQotCWlm IChhdTEwMDBfZGVidWcgPiA0KSB7DQotCQlwcmludGsoImxzaV84MDIyN19yZXNldFxuIik7DQot CQlkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0JfQ0KLQ0KLQltaWlfY29udHJvbCA9IG1kaW9f cmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlf YWRkciwgTUlJX0NPTlRST0wsIG1paV9jb250cm9sIHwgTUlJX0NOVExfUkVTRVQpOw0KLQltZGVs YXkoMSk7DQotCWZvciAodGltZW91dCA9IDEwMDsgdGltZW91dCA+IDA7IC0tdGltZW91dCkgew0K LQkJbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0K LQkJaWYgKChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSA9PSAwKQ0KLQkJCWJyZWFrOw0K LQkJbWRlbGF5KDEpOw0KLQl9DQotCWlmIChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSB7 DQotCQlwcmludGsoS0VSTl9FUlIgIiVzIFBIWSByZXNldCB0aW1lb3V0ICFcbiIsIGRldi0+bmFt ZSk7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludA0KLWxzaV84 MDIyN19zdGF0dXMoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxp bmssIHUxNiAqc3BlZWQpDQotew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0cnVjdCBhdTEwMDBfcHJp dmF0ZSAqYXVwOw0KLQ0KLQlpZiAoIWRldikgew0KLQkJcHJpbnRrKEtFUk5fRVJSICJsc2lfODAy Mjdfc3RhdHVzIGVycm9yOiBOVUxMIGRldlxuIik7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JYXVw ID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQotDQotCW1paV9kYXRhID0g bWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX1NUQVRVUyk7DQotCWlmIChtaWlfZGF0 YSAmIE1JSV9TVEFUX0xJTkspIHsNCi0JCSpsaW5rID0gMTsNCi0JCW1paV9kYXRhID0gbWRpb19y ZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0xTSV9QSFlfU1RBVCk7DQotCQlpZiAobWlpX2Rh dGEgJiBNSUlfTFNJX1BIWV9TVEFUX1NQRCkgew0KLQkJCWlmIChtaWlfZGF0YSAmIE1JSV9MU0lf UEhZX1NUQVRfRkRYKSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCQlk ZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQl9DQotCQkJZWxzZSB7DQotCQkJ CSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JU XzEwMEJBU0VUWDsNCi0JCQl9DQotCQl9DQotCQllbHNlICB7DQotCQkJKnNwZWVkID0gSUZfUE9S VF8xMEJBU0VUOw0KLQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCX0NCi0N Ci0JfQ0KLQllbHNlIHsNCi0JCSpsaW5rID0gMDsNCi0JCSpzcGVlZCA9IDA7DQotCQlkZXYtPmlm X3BvcnQgPSBJRl9QT1JUX1VOS05PV047DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBh bTc5YzkwMV9pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQot CXByaW50aygiYW03OWM5MDFfaW5pdFxuIik7DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgYW03 OWM5MDFfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0J cHJpbnRrKCJhbTc5YzkwMV9yZXNldFxuIik7DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgDQot YW03OWM5MDFfc3RhdHVzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2 ICpsaW5rLCB1MTYgKnNwZWVkKQ0KLXsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBhbTc5Yzg3 NF9pbml0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMxNiBk YXRhOw0KLQ0KLQkvKiA3OWM4NzQgaGFzIHF1aXQgcmVzZW1ibGVkIGJpdCBhc3NpZ25tZW50cyB0 byBCQ001MjAxICovDQotCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KLQkJcHJpbnRrKCJhbTc5Yzg0 N19pbml0XG4iKTsNCi0NCi0JLyogU3RvcCBhdXRvLW5lZ290aWF0aW9uICovDQotCWRhdGEgPSBt ZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwg cGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhICYgfk1JSV9DTlRMX0FVVE8pOw0KLQ0KLQkvKiBT ZXQgYWR2ZXJ0aXNlbWVudCB0byAxMC8xMDAgYW5kIEhhbGYvRnVsbCBkdXBsZXgNCi0JICogKGZ1 bGwgY2FwYWJpbGl0aWVzKSAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1J SV9BTkFEVik7DQotCWRhdGEgfD0gTUlJX05XQVlfVFggfCBNSUlfTldBWV9UWF9GRFggfCBNSUlf TldBWV9UX0ZEWCB8IE1JSV9OV0FZX1Q7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJ X0FOQURWLCBkYXRhKTsNCi0JDQotCS8qIFJlc3RhcnQgYXV0by1uZWdvdGlhdGlvbiAqLw0KLQlk YXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JZGF0YSB8PSBN SUlfQ05UTF9SU1RfQVVUTyB8IE1JSV9DTlRMX0FVVE87DQotDQotCW1kaW9fd3JpdGUoZGV2LCBw aHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEpOw0KLQ0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkg ZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgYW03OWM4 NzRfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2 IG1paV9jb250cm9sLCB0aW1lb3V0Ow0KLQkNCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQotCQlw cmludGsoImFtNzljODc0X3Jlc2V0XG4iKTsNCi0NCi0JbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQo ZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIs IE1JSV9DT05UUk9MLCBtaWlfY29udHJvbCB8IE1JSV9DTlRMX1JFU0VUKTsNCi0JbWRlbGF5KDEp Ow0KLQlmb3IgKHRpbWVvdXQgPSAxMDA7IHRpbWVvdXQgPiAwOyAtLXRpbWVvdXQpIHsNCi0JCW1p aV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCWlm ICgobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgPT0gMCkNCi0JCQlicmVhazsNCi0JCW1k ZWxheSgxKTsNCi0JfQ0KLQlpZiAobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgew0KLQkJ cHJpbnRrKEtFUk5fRVJSICIlcyBQSFkgcmVzZXQgdGltZW91dCAhXG4iLCBkZXYtPm5hbWUpOw0K LQkJcmV0dXJuIC0xOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgDQotYW03OWM4NzRf c3RhdHVzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICpsaW5rLCB1 MTYgKnNwZWVkKQ0KLXsNCi0JdTE2IG1paV9kYXRhOw0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUg KmF1cDsNCi0NCi0JLy8gcHJpbnRrKCJhbTc5Yzg3NF9zdGF0dXNcbiIpOw0KLQlpZiAoIWRldikg ew0KLQkJcHJpbnRrKEtFUk5fRVJSICJhbTc5Yzg3NF9zdGF0dXMgZXJyb3I6IE5VTEwgZGV2XG4i KTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQ0KLQlhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRl ICopIGRldi0+cHJpdjsNCi0JbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRy LCBNSUlfU1RBVFVTKTsNCi0NCi0JaWYgKG1paV9kYXRhICYgTUlJX1NUQVRfTElOSykgew0KLQkJ KmxpbmsgPSAxOw0KLQkJbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBN SUlfQU1EX1BIWV9TVEFUKTsNCi0JCWlmIChtaWlfZGF0YSAmIE1JSV9BTURfUEhZX1NUQVRfU1BE KSB7DQotCQkJaWYgKG1paV9kYXRhICYgTUlJX0FNRF9QSFlfU1RBVF9GRFgpIHsNCi0JCQkJKnNw ZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAw QkFTRUZYOw0KLQkJCX0NCi0JCQllbHNlIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNF VFg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCX0NCi0JCX0N Ci0JCWVsc2Ugew0KLQkJCSpzcGVlZCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCQlkZXYtPmlmX3Bv cnQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQl9DQotDQotCX0NCi0JZWxzZSB7DQotCQkqbGluayA9 IDA7DQotCQkqc3BlZWQgPSAwOw0KLQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF9VTktOT1dOOw0K LQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgbHh0OTcxYV9pbml0KHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KLQkJ cHJpbnRrKCJseHQ5NzFhX2luaXRcbiIpOw0KLQ0KLQkvKiByZXN0YXJ0IGF1dG8tbmVnb3RpYXRp b24gKi8NCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwNCi0JCSAgIE1J SV9DTlRMX0YxMDAgfCBNSUlfQ05UTF9BVVRPIHwgTUlJX0NOVExfUlNUX0FVVE8gfCBNSUlfQ05U TF9GRFgpOw0KLQ0KLQkvKiBzZXQgdXAgTEVEcyB0byBjb3JyZWN0IGRpc3BsYXkgKi8NCi0JbWRp b193cml0ZShkZXYsIHBoeV9hZGRyLCAyMCwgMHgwNDIyKTsNCi0NCi0JaWYgKGF1MTAwMF9kZWJ1 ZyA+IDQpDQotCQlkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0K LWludCBseHQ5NzFhX3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikN Ci17DQotCXMxNiBtaWlfY29udHJvbCwgdGltZW91dDsNCi0JDQotCWlmIChhdTEwMDBfZGVidWcg PiA0KSB7DQotCQlwcmludGsoImx4dDk3MWFfcmVzZXRcbiIpOw0KLQkJZHVtcF9taWkoZGV2LCBw aHlfYWRkcik7DQotCX0NCi0NCi0JbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRk ciwgTUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9M LCBtaWlfY29udHJvbCB8IE1JSV9DTlRMX1JFU0VUKTsNCi0JbWRlbGF5KDEpOw0KLQlmb3IgKHRp bWVvdXQgPSAxMDA7IHRpbWVvdXQgPiAwOyAtLXRpbWVvdXQpIHsNCi0JCW1paV9jb250cm9sID0g bWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCWlmICgobWlpX2NvbnRy b2wgJiBNSUlfQ05UTF9SRVNFVCkgPT0gMCkNCi0JCQlicmVhazsNCi0JCW1kZWxheSgxKTsNCi0J fQ0KLQlpZiAobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgew0KLQkJcHJpbnRrKEtFUk5f RVJSICIlcyBQSFkgcmVzZXQgdGltZW91dCAhXG4iLCBkZXYtPm5hbWUpOw0KLQkJcmV0dXJuIC0x Ow0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQNCi1seHQ5NzFhX3N0YXR1cyhzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUxNiAqbGluaywgdTE2ICpzcGVlZCkNCi17 DQotCXUxNiBtaWlfZGF0YTsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXA7DQotDQotCWlm ICghZGV2KSB7DQotCQlwcmludGsoS0VSTl9FUlIgImx4dDk3MWFfc3RhdHVzIGVycm9yOiBOVUxM IGRldlxuIik7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJp dmF0ZSAqKSBkZXYtPnByaXY7DQotDQotCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5w aHlfYWRkciwgTUlJX1NUQVRVUyk7DQotCWlmIChtaWlfZGF0YSAmIE1JSV9TVEFUX0xJTkspIHsN Ci0JCSpsaW5rID0gMTsNCi0JCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRk ciwgTUlJX0lOVEVMX1BIWV9TVEFUKTsNCi0JCWlmIChtaWlfZGF0YSAmIE1JSV9JTlRFTF9QSFlf U1RBVF9TUEQpIHsNCi0JCQlpZiAobWlpX2RhdGEgJiBNSUlfSU5URUxfUEhZX1NUQVRfRkRYKSB7 DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJ Rl9QT1JUXzEwMEJBU0VGWDsNCi0JCQl9DQotCQkJZWxzZSB7DQotCQkJCSpzcGVlZCA9IElGX1BP UlRfMTAwQkFTRVRYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0J CQl9DQotCQl9DQotCQllbHNlICB7DQotCQkJKnNwZWVkID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJ CWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCX0NCi0NCi0JfQ0KLQllbHNlIHsN Ci0JCSpsaW5rID0gMDsNCi0JCSpzcGVlZCA9IDA7DQotCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JU X1VOS05PV047DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBrczg5OTVtX2luaXQoc3Ry dWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IGRhdGE7DQotCQ0K LS8vCXByaW50aygia3M4OTk1bV9pbml0XG4iKTsNCi0JLyogU3RvcCBhdXRvLW5lZ290aWF0aW9u ICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQlt ZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhICYgfk1JSV9DTlRMX0FV VE8pOw0KLQ0KLQkvKiBTZXQgYWR2ZXJ0aXNlbWVudCB0byAxMC8xMDAgYW5kIEhhbGYvRnVsbCBk dXBsZXgNCi0JICogKGZ1bGwgY2FwYWJpbGl0aWVzKSAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRl diwgcGh5X2FkZHIsIE1JSV9BTkFEVik7DQotCWRhdGEgfD0gTUlJX05XQVlfVFggfCBNSUlfTldB WV9UWF9GRFggfCBNSUlfTldBWV9UX0ZEWCB8IE1JSV9OV0FZX1Q7DQotCW1kaW9fd3JpdGUoZGV2 LCBwaHlfYWRkciwgTUlJX0FOQURWLCBkYXRhKTsNCi0JDQotCS8qIFJlc3RhcnQgYXV0by1uZWdv dGlhdGlvbiAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9M KTsNCi0JZGF0YSB8PSBNSUlfQ05UTF9SU1RfQVVUTyB8IE1JSV9DTlRMX0FVVE87DQotCW1kaW9f d3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEpOw0KLQ0KLQlpZiAoYXUxMDAw X2RlYnVnID4gNCkgZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotDQotCXJldHVybiAwOw0KLX0N Ci0NCi1pbnQga3M4OTk1bV9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2Fk ZHIpDQotew0KLQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVvdXQ7DQotCQ0KLS8vCXByaW50aygia3M4 OTk1bV9yZXNldFxuIik7DQotCW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIs IE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwg bWlpX2NvbnRyb2wgfCBNSUlfQ05UTF9SRVNFVCk7DQotCW1kZWxheSgxKTsNCi0JZm9yICh0aW1l b3V0ID0gMTAwOyB0aW1lb3V0ID4gMDsgLS10aW1lb3V0KSB7DQotCQltaWlfY29udHJvbCA9IG1k aW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCQlpZiAoKG1paV9jb250cm9s ICYgTUlJX0NOVExfUkVTRVQpID09IDApDQotCQkJYnJlYWs7DQotCQltZGVsYXkoMSk7DQotCX0N Ci0JaWYgKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpIHsNCi0JCXByaW50ayhLRVJOX0VS UiAiJXMgUEhZIHJlc2V0IHRpbWVvdXQgIVxuIiwgZGV2LT5uYW1lKTsNCi0JCXJldHVybiAtMTsN Ci0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGtzODk5NW1fc3RhdHVzKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICpsaW5rLCB1MTYgKnNwZWVkKQ0KLXsNCi0J dTE2IG1paV9kYXRhOw0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cDsNCi0NCi0JaWYgKCFk ZXYpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAia3M4OTk1bV9zdGF0dXMgZXJyb3I6IE5VTEwgZGV2 XG4iKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQlhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRl ICopIGRldi0+cHJpdjsNCi0NCi0JbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9h ZGRyLCBNSUlfU1RBVFVTKTsNCi0JaWYgKG1paV9kYXRhICYgTUlJX1NUQVRfTElOSykgew0KLQkJ KmxpbmsgPSAxOw0KLQkJbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBN SUlfQVVYX0NOVFJMKTsNCi0JCWlmIChtaWlfZGF0YSAmIE1JSV9BVVhfMTAwKSB7DQotCQkJaWYg KG1paV9kYXRhICYgTUlJX0FVWF9GRFgpIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNF Rlg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCX0NCi0JCQll bHNlIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJCWRldi0+aWZfcG9y dCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCX0NCi0JCX0NCi0JCWVsc2UgIHsJCQkJCQkJCQkJ CQ0KLQkJCSpzcGVlZCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCQlkZXYtPmlmX3BvcnQgPSBJRl9Q T1JUXzEwQkFTRVQ7DQotCQl9DQotDQotCX0NCi0JZWxzZSB7DQotCQkqbGluayA9IDA7DQotCQkq c3BlZWQgPSAwOw0KLQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF9VTktOT1dOOw0KLQl9DQotCXJl dHVybiAwOw0KLX0NCi0NCi1pbnQNCi1zbXNjXzgzQzE4NV9pbml0IChzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYgZGF0YTsNCi0NCi0JaWYgKGF1MTAwMF9k ZWJ1ZyA+IDQpDQotCQlwcmludGsoInNtc2NfODNDMTg1X2luaXRcbiIpOw0KLQ0KLQkvKiBTdG9w IGF1dG8tbmVnb3RpYXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBN SUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRh dGEgJiB+TUlJX0NOVExfQVVUTyk7DQotDQotCS8qIFNldCBhZHZlcnRpc2VtZW50IHRvIDEwLzEw MCBhbmQgSGFsZi9GdWxsIGR1cGxleA0KLQkgKiAoZnVsbCBjYXBhYmlsaXRpZXMpICovDQotCWRh dGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0FOQURWKTsNCi0JZGF0YSB8PSBNSUlf TldBWV9UWCB8IE1JSV9OV0FZX1RYX0ZEWCB8IE1JSV9OV0FZX1RfRkRYIHwgTUlJX05XQVlfVDsN Ci0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYsIGRhdGEpOw0KLQkNCi0JLyog UmVzdGFydCBhdXRvLW5lZ290aWF0aW9uICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlf YWRkciwgTUlJX0NPTlRST0wpOw0KLQlkYXRhIHw9IE1JSV9DTlRMX1JTVF9BVVRPIHwgTUlJX0NO VExfQVVUTzsNCi0NCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0 YSk7DQotDQotCWlmIChhdTEwMDBfZGVidWcgPiA0KSBkdW1wX21paShkZXYsIHBoeV9hZGRyKTsN Ci0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludA0KLXNtc2NfODNDMTg1X3Jlc2V0IChzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVv dXQ7DQotCQ0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkNCi0JCXByaW50aygic21zY184M0MxODVf cmVzZXRcbiIpOw0KLQ0KLQltaWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBN SUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIG1p aV9jb250cm9sIHwgTUlJX0NOVExfUkVTRVQpOw0KLQltZGVsYXkoMSk7DQotCWZvciAodGltZW91 dCA9IDEwMDsgdGltZW91dCA+IDA7IC0tdGltZW91dCkgew0KLQkJbWlpX2NvbnRyb2wgPSBtZGlv X3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJaWYgKChtaWlfY29udHJvbCAm IE1JSV9DTlRMX1JFU0VUKSA9PSAwKQ0KLQkJCWJyZWFrOw0KLQkJbWRlbGF5KDEpOw0KLQl9DQot CWlmIChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSB7DQotCQlwcmludGsoS0VSTl9FUlIg IiVzIFBIWSByZXNldCB0aW1lb3V0ICFcbiIsIGRldi0+bmFtZSk7DQotCQlyZXR1cm4gLTE7DQot CX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCANCi1zbXNjXzgzQzE4NV9zdGF0dXMgKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICpsaW5rLCB1MTYgKnNwZWVkKQ0K LXsNCi0JdTE2IG1paV9kYXRhOw0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cDsNCi0NCi0J aWYgKCFkZXYpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAic21zY184M0MxODVfc3RhdHVzIGVycm9y OiBOVUxMIGRldlxuIik7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0NCi0JYXVwID0gKHN0cnVjdCBh dTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQotCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwg YXVwLT5waHlfYWRkciwgTUlJX1NUQVRVUyk7DQotDQotCWlmIChtaWlfZGF0YSAmIE1JSV9TVEFU X0xJTkspIHsNCi0JCSpsaW5rID0gMTsNCi0JCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVw LT5waHlfYWRkciwgMHgxZik7DQotCQlpZiAobWlpX2RhdGEgJiAoMTw8MykpIHsNCi0JCQlpZiAo bWlpX2RhdGEgJiAoMTw8NCkpIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQot CQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCX0NCi0JCQllbHNlIHsN Ci0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElG X1BPUlRfMTAwQkFTRVRYOw0KLQkJCX0NCi0JCX0NCi0JCWVsc2Ugew0KLQkJCSpzcGVlZCA9IElG X1BPUlRfMTBCQVNFVDsNCi0JCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQl9 DQotCX0NCi0JZWxzZSB7DQotCQkqbGluayA9IDA7DQotCQkqc3BlZWQgPSAwOw0KLQkJZGV2LT5p Zl9wb3J0ID0gSUZfUE9SVF9VTktOT1dOOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi0NCi0j aWZkZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi1pbnQgc3R1Yl9pbml0KHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCS8vcHJpbnRrKCJQSFkgc3R1Yl9pbml0XG4i KTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBzdHViX3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNl ICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCS8vcHJpbnRrKCJQSFkgc3R1Yl9yZXNldFxuIik7 DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgDQotc3R1Yl9zdGF0dXMoc3RydWN0IG5ldF9kZXZp Y2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxpbmssIHUxNiAqc3BlZWQpDQotew0KLQkvL3By aW50aygiUEhZIHN0dWJfc3RhdHVzXG4iKTsNCi0JKmxpbmsgPSAxOw0KLQkvKiBobW1tLCByZXZp c2l0ICovDQotCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQlkZXYtPmlmX3BvcnQgPSBJ Rl9QT1JUXzEwMEJBU0VGWDsNCi0JcmV0dXJuIDA7DQotfQ0KLSNlbmRpZg0KLQ0KLXN0cnVjdCBw aHlfb3BzIGJjbV81MjAxX29wcyA9IHsNCi0JYmNtXzUyMDFfaW5pdCwNCi0JYmNtXzUyMDFfcmVz ZXQsDQotCWJjbV81MjAxX3N0YXR1cywNCi19Ow0KLQ0KLXN0cnVjdCBwaHlfb3BzIGFtNzljODc0 X29wcyA9IHsNCi0JYW03OWM4NzRfaW5pdCwNCi0JYW03OWM4NzRfcmVzZXQsDQotCWFtNzljODc0 X3N0YXR1cywNCi19Ow0KLQ0KLXN0cnVjdCBwaHlfb3BzIGFtNzljOTAxX29wcyA9IHsNCi0JYW03 OWM5MDFfaW5pdCwNCi0JYW03OWM5MDFfcmVzZXQsDQotCWFtNzljOTAxX3N0YXR1cywNCi19Ow0K LQ0KLXN0cnVjdCBwaHlfb3BzIGxzaV84MDIyN19vcHMgPSB7IA0KLQlsc2lfODAyMjdfaW5pdCwN Ci0JbHNpXzgwMjI3X3Jlc2V0LA0KLQlsc2lfODAyMjdfc3RhdHVzLA0KLX07DQotDQotc3RydWN0 IHBoeV9vcHMgbHh0OTcxYV9vcHMgPSB7IA0KLQlseHQ5NzFhX2luaXQsDQotCWx4dDk3MWFfcmVz ZXQsDQotCWx4dDk3MWFfc3RhdHVzLA0KLX07DQotDQotc3RydWN0IHBoeV9vcHMga3M4OTk1bV9v cHMgPSB7DQotCWtzODk5NW1faW5pdCwNCi0Ja3M4OTk1bV9yZXNldCwNCi0Ja3M4OTk1bV9zdGF0 dXMsDQotfTsNCi0NCi1zdHJ1Y3QgcGh5X29wcyBzbXNjXzgzQzE4NV9vcHMgPSB7DQotCXNtc2Nf ODNDMTg1X2luaXQsDQotCXNtc2NfODNDMTg1X3Jlc2V0LA0KLQlzbXNjXzgzQzE4NV9zdGF0dXMs DQotfTsNCi0NCi0jaWZkZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi1zdHJ1Y3QgcGh5X29wcyBz dHViX29wcyA9IHsNCi0Jc3R1Yl9pbml0LA0KLQlzdHViX3Jlc2V0LA0KLQlzdHViX3N0YXR1cywN Ci19Ow0KLSNlbmRpZg0KKy8vIGxlZnQtb3ZlciBmcm9tIHBoeWxpYiByZXdyaXRlLCBuZWVkcyB0 byBnZXQgcmVtb3ZlZCBhcyB3ZWxsLi4uIEZJWE1FDQogDQogc3RhdGljIHN0cnVjdCBtaWlfY2hp cF9pbmZvIHsNCiAJY29uc3QgY2hhciAqIG5hbWU7DQogCXUxNiBwaHlfaWQwOw0KIAl1MTYgcGh5 X2lkMTsNCi0Jc3RydWN0IHBoeV9vcHMgKnBoeV9vcHM7CQ0KKwlzdHJ1Y3QgcGh5X29wcyAqcGh5 X29wc19vYnNvbGV0ZTsJDQogCWludCBkdWFsX3BoeTsNCiB9IG1paV9jaGlwX3RhYmxlW10gPSB7 DQotCXsiQnJvYWRjb20gQkNNNTIwMSAxMC8xMDAgQmFzZVQgUEhZIiwweDAwNDAsMHg2MjEyLCAm YmNtXzUyMDFfb3BzLDB9LA0KLQl7IkJyb2FkY29tIEJDTTUyMjEgMTAvMTAwIEJhc2VUIFBIWSIs MHgwMDQwLDB4NjFlNCwgJmJjbV81MjAxX29wcywwfSwNCi0JeyJCcm9hZGNvbSBCQ001MjIyIDEw LzEwMCBCYXNlVCBQSFkiLDB4MDA0MCwweDYzMjIsICZiY21fNTIwMV9vcHMsMX0sDQotCXsiTlMg RFA4Mzg0NyBQSFkiLCAweDIwMDAsIDB4NWMzMCwgJmJjbV81MjAxX29wcyAsMH0sDQotCXsiQU1E IDc5QzkwMSBIb21lUE5BIFBIWSIsMHgwMDAwLDB4MzVjOCwgJmFtNzljOTAxX29wcywwfSwNCi0J eyJBTUQgNzlDODc0IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAyMiwweDU2MWIsICZhbTc5Yzg3NF9v cHMsMH0sDQotCXsiTFNJIDgwMjI3IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAxNiwweGY4NDAsICZs c2lfODAyMjdfb3BzLDB9LA0KLQl7IkludGVsIExYVDk3MUEgRHVhbCBTcGVlZCBQSFkiLDB4MDAx MywweDc4ZTIsICZseHQ5NzFhX29wcywwfSwNCi0JeyJLZW5kaW4gS1M4OTk1TSAxMC8xMDAgQmFz ZVQgUEhZIiwweDAwMjIsMHgxNDUwLCAma3M4OTk1bV9vcHMsMH0sDQotCXsiU01TQyBMQU44M0Mx ODUgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDA3LDB4YzBhMywgJnNtc2NfODNDMTg1X29wcywwfSwN CisJeyJCcm9hZGNvbSBCQ001MjAxIDEwLzEwMCBCYXNlVCBQSFkiLDB4MDA0MCwweDYyMTIsIDAg LDB9LA0KKwl7IkJyb2FkY29tIEJDTTUyMjEgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDQwLDB4NjFl NCwgMCAsMH0sDQorCXsiQnJvYWRjb20gQkNNNTIyMiAxMC8xMDAgQmFzZVQgUEhZIiwweDAwNDAs MHg2MzIyLCAwICwxfSwNCisJeyJOUyBEUDgzODQ3IFBIWSIsIDB4MjAwMCwgMHg1YzMwLCAwICww fSwNCisJeyJBTUQgNzlDOTAxIEhvbWVQTkEgUEhZIiwweDAwMDAsMHgzNWM4LCAwLDB9LA0KKwl7 IkFNRCA3OUM4NzQgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDIyLDB4NTYxYiwgMCwwfSwNCisJeyJM U0kgODAyMjcgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDE2LDB4Zjg0MCwgMCwwfSwNCisJeyJJbnRl bCBMWFQ5NzFBIER1YWwgU3BlZWQgUEhZIiwweDAwMTMsMHg3OGUyLCAwLDB9LA0KKwl7IktlbmRp biBLUzg5OTVNIDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAyMiwweDE0NTAsIDAsMH0sDQorCXsiU01T QyBMQU44M0MxODUgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDA3LDB4YzBhMywgMCwwfSwNCiAjaWZk ZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi0JeyJTdHViIiwgMHgxMjM0LCAweDU2NzgsICZzdHVi X29wcyB9LA0KKwl7IlN0dWIiLCAweDEyMzQsIDB4NTY3OCwgMCwgMCB9LA0KICNlbmRpZg0KIAl7 MCx9LA0KIH07DQpAQCAtODkzLDE5ICsyNjEsMjkgQEAgc3RhdGljIHZvaWQgbWRpb193cml0ZShz dHJ1Y3QgbmV0X2RldmljZQ0KIAkqbWlpX2NvbnRyb2xfcmVnID0gbWlpX2NvbnRyb2w7DQogfQ0K IA0KK3N0YXRpYyBpbnQNCittZGlvYnVzX3JlYWQoc3RydWN0IG1paV9idXMgKmJ1cywgaW50IG1p aV9pZCwgaW50IHJlZ251bSkNCit7DQorICBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gYnVzLT5w cml2Ow0KKyAgcmV0dXJuIG1kaW9fcmVhZChkZXYsIG1paV9pZCwgcmVnbnVtKTsNCit9DQogDQot c3RhdGljIHZvaWQgZHVtcF9taWkoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9pZCkN CitzdGF0aWMgaW50DQorbWRpb2J1c193cml0ZShzdHJ1Y3QgbWlpX2J1cyAqYnVzLCBpbnQgbWlp X2lkLCBpbnQgcmVnbnVtLCB1MTYgdmFsdWUpDQogew0KLQlpbnQgaSwgdmFsOw0KKyAgc3RydWN0 IG5ldF9kZXZpY2UgKmRldiA9IGJ1cy0+cHJpdjsNCisgIG1kaW9fd3JpdGUoZGV2LCBtaWlfaWQs IHJlZ251bSwgdmFsdWUpOw0KKyAgcmV0dXJuIDA7DQorfQ0KIA0KLQlmb3IgKGkgPSAwOyBpIDwg NzsgaSsrKSB7DQotCQlpZiAoKHZhbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9pZCwgaSkpID49IDAp DQotCQkJcHJpbnRrKCIlczogTUlJIFJlZyAlZD0leFxuIiwgZGV2LT5uYW1lLCBpLCB2YWwpOw0K LQl9DQotCWZvciAoaSA9IDE2OyBpIDwgMjU7IGkrKykgew0KLQkJaWYgKCh2YWwgPSBtZGlvX3Jl YWQoZGV2LCBwaHlfaWQsIGkpKSA+PSAwKQ0KLQkJCXByaW50aygiJXM6IE1JSSBSZWcgJWQ9JXhc biIsIGRldi0+bmFtZSwgaSwgdmFsKTsNCi0JfQ0KK3N0YXRpYyBpbnQNCittZGlvYnVzX3Jlc2V0 KHN0cnVjdCBtaWlfYnVzICpidXMpDQorew0KKyAgc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IGJ1 cy0+cHJpdjsNCisNCisgIHByaW50ayAoS0VSTl9XQVJOSU5HICIlczogbWRpb2J1c19yZXNldCgp IG5vdCBpbXBsZW1lbnRlZFxuIiwgZGV2LT5uYW1lKTsNCisgIC8vIEZJWE1FLCBUT0RPDQorICBy ZXR1cm4gMDsNCiB9DQogDQogc3RhdGljIGludCBtaWlfcHJvYmUgKHN0cnVjdCBuZXRfZGV2aWNl ICogZGV2KQ0KQEAgLTkzMCwxMyArMzA4LDEzIEBAIHN0YXRpYyBpbnQgbWlpX3Byb2JlIChzdHJ1 Y3QgbmV0X2RldmljZSANCiAJCX0NCiAJCSNlbmRpZg0KIA0KLQkJbWlpX3N0YXR1cyA9IG1kaW9f cmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfU1RBVFVTKTsNCisJCW1paV9zdGF0dXMgPSBtZGlvX3Jl YWQoZGV2LCBwaHlfYWRkciwgTUlJX0JNU1IpOw0KIAkJaWYgKG1paV9zdGF0dXMgPT0gMHhmZmZm IHx8IG1paV9zdGF0dXMgPT0gMHgwMDAwKQ0KIAkJCS8qIHRoZSBtaWkgaXMgbm90IGFjY2Vzc2Fi bGUsIHRyeSBuZXh0IG9uZSAqLw0KIAkJCWNvbnRpbnVlOw0KIA0KLQkJcGh5X2lkMCA9IG1kaW9f cmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfUEhZX0lEMCk7DQotCQlwaHlfaWQxID0gbWRpb19yZWFk KGRldiwgcGh5X2FkZHIsIE1JSV9QSFlfSUQxKTsNCisJCXBoeV9pZDAgPSBtZGlvX3JlYWQoZGV2 LCBwaHlfYWRkciwgTUlJX1BIWVNJRDEpOw0KKwkJcGh5X2lkMSA9IG1kaW9fcmVhZChkZXYsIHBo eV9hZGRyLCBNSUlfUEhZU0lEMik7DQogDQogCQkvKiBzZWFyY2ggb3VyIG1paSB0YWJsZSBmb3Ig dGhlIGN1cnJlbnQgbWlpICovIA0KIAkJZm9yIChpID0gMDsgbWlpX2NoaXBfdGFibGVbaV0ucGh5 X2lkMTsgaSsrKSB7DQpAQCAtOTUyLDkgKzMzMCw2IEBAIHN0YXRpYyBpbnQgbWlpX3Byb2JlIChz dHJ1Y3QgbmV0X2RldmljZSANCiAjZW5kaWYNCiAJCQkJbWlpX3BoeS0+Y2hpcF9pbmZvID0gbWlp X2NoaXBfdGFibGUraTsNCiAJCQkJYXVwLT5waHlfYWRkciA9IHBoeV9hZGRyOw0KLQkJCQlhdXAt PndhbnRfYXV0b25lZyA9IDE7DQotCQkJCWF1cC0+cGh5X29wcyA9IG1paV9jaGlwX3RhYmxlW2ld LnBoeV9vcHM7DQotCQkJCWF1cC0+cGh5X29wcy0+cGh5X2luaXQoZGV2LHBoeV9hZGRyKTsNCiAN CiAJCQkJLy8gQ2hlY2sgZm9yIGR1YWwtcGh5IGFuZCB0aGVuIHN0b3JlIHJlcXVpcmVkIA0KIAkJ CQkvLyB2YWx1ZXMgYW5kIHNldCBpbmRpY2F0b3JzLiBXZSBuZWVkIHRvIGRvIA0KQEAgLTEwMTMs MTAgKzM4OCw3IEBAIGZvdW5kOg0KIAkJCQkJbWlpX3BoeS0+Y2hpcF9pbmZvID0gbWlpX2NoaXBf dGFibGUraTsNCiAJCQkJCWF1cC0+cGh5X2FkZHIgPSBwaHlfYWRkcjsNCiAJCQkJCW1paV9waHkt Pm5leHQgPSBhdXAtPm1paTsNCi0JCQkJCWF1cC0+cGh5X29wcyA9IA0KLQkJCQkJCW1paV9jaGlw X3RhYmxlW2ldLnBoeV9vcHM7DQogCQkJCQlhdXAtPm1paSA9IG1paV9waHk7DQotCQkJCQlhdXAt PnBoeV9vcHMtPnBoeV9pbml0KGRldixwaHlfYWRkcik7DQogCQkJCX0gZWxzZSB7DQogCQkJCQlw cmludGsoS0VSTl9FUlIgIiVzOiBvdXQgb2YgbWVtb3J5XG4iLCANCiAJCQkJCQkJZGV2LT5uYW1l KTsNCkBAIC0xMDI0LDggKzM5Niw2IEBAIGZvdW5kOg0KIAkJCQl9DQogCQkJCW1paV9waHktPmNo aXBfaW5mbyA9IG1paV9jaGlwX3RhYmxlK2k7DQogCQkJCWF1cC0+cGh5X2FkZHIgPSBwaHlfYWRk cjsNCi0JCQkJYXVwLT5waHlfb3BzID0gbWlpX2NoaXBfdGFibGVbaV0ucGh5X29wczsNCi0JCQkJ YXVwLT5waHlfb3BzLT5waHlfaW5pdChkZXYscGh5X2FkZHIpOw0KIAkJCQlicmVhazsNCiAJCQl9 DQogCQl9DQpAQCAtMTAzOCw2ICs0MDgsMzYgQEAgZm91bmQ6DQogCX0NCiAjZW5kaWYNCiANCisJ ew0KKwkJY2hhciBwaHlfaWRbQlVTX0lEX1NJWkVdOw0KKwkJc3RydWN0IHBoeV9kZXZpY2UgKnBo eWRldjsNCisJCQ0KKwkJc25wcmludGYocGh5X2lkLCBCVVNfSURfU0laRSwgUEhZX0lEX0ZNVCwg YXVwLT5tYWNfaWQsIGF1cC0+cGh5X2FkZHIpOw0KKwkJDQorCQlwaHlkZXYgPSBwaHlfY29ubmVj dChkZXYsIHBoeV9pZCwgJmF1MTAwMF9hZGp1c3RfbGluaywgMCk7DQorCQkNCisJCWlmIChJU19F UlIocGh5ZGV2KSkgew0KKwkJCXByaW50ayhLRVJOX0VSUiAiJXM6IENvdWxkIG5vdCBhdHRhY2gg dG8gUEhZXG4iLCBkZXYtPm5hbWUpOw0KKwkJCXJldHVybiBQVFJfRVJSKHBoeWRldik7DQorCQl9 DQorCQkNCisJCS8vIG1hc2sgd2l0aCBNQUMgc3VwcG9ydGVkIGZlYXR1cmVzDQorCQlwaHlkZXYt PnN1cHBvcnRlZCAmPSAoU1VQUE9SVEVEXzEwYmFzZVRfSGFsZiANCisJCQkJICAgICAgfCBTVVBQ T1JURURfMTBiYXNlVF9GdWxsIA0KKwkJCQkgICAgICB8IFNVUFBPUlRFRF8xMDBiYXNlVF9IYWxm IA0KKwkJCQkgICAgICB8IFNVUFBPUlRFRF8xMDBiYXNlVF9GdWxsIA0KKwkJCQkgICAgICB8IFNV UFBPUlRFRF9BdXRvbmVnIA0KKwkJCQkgICAgICB8IFNVUFBPUlRFRF9NSUkgDQorCQkJCSAgICAg IHwgU1VQUE9SVEVEX1RQKTsNCisJCQ0KKwkJcGh5ZGV2LT5hZHZlcnRpc2luZyA9IHBoeWRldi0+ c3VwcG9ydGVkOw0KKw0KKwkJYXVwLT5vbGRfbGluayA9IDA7DQorCQlhdXAtPm9sZF9zcGVlZCA9 IDA7DQorCQlhdXAtPm9sZF9kdXBsZXggPSAtMTsNCisJCWF1cC0+cGh5X2RldiA9IHBoeWRldjsN CisJfQ0KKw0KIAlpZiAoYXVwLT5taWktPmNoaXBfaW5mbyA9PSBOVUxMKSB7DQogCQlwcmludGso S0VSTl9FUlIgIiVzOiBBdTF4IE5vIGtub3duIE1JSSB0cmFuc2NlaXZlcnMgZm91bmQhXG4iLA0K IAkJCQlkZXYtPm5hbWUpOw0KQEAgLTExMDksOSArNTA5LDcgQEAgc3RhdGljIHZvaWQgcmVzZXRf bWFjKHN0cnVjdCBuZXRfZGV2aWNlIA0KIAkJCQlkZXYtPm5hbWUsICh1bnNpZ25lZClhdXApOw0K IA0KIAlzcGluX2xvY2tfaXJxc2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQotCWlmIChhdXAtPnRp bWVyLmZ1bmN0aW9uID09ICZhdTEwMDBfdGltZXIpIHsvKiBjaGVjayBpZiB0aW1lciBpbml0dGVk ICovDQotCQlkZWxfdGltZXIoJmF1cC0+dGltZXIpOw0KLQl9DQorCS8vIGZpeG1lLCBsb2NrIG1p aWJ1cw0KIA0KIAloYXJkX3N0b3AoZGV2KTsNCiAJI2lmZGVmIENPTkZJR19CQ001MjIyX0RVQUxf UEhZDQpAQCAtMTIzNywxNzggKzYzNSwyMiBAQCBzdGF0aWMgaW50IF9faW5pdCBhdTEwMDBfaW5p dF9tb2R1bGUodm9pDQogCXJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgaW50IGF1MTAwMF9zZXR1 cF9hbmVnKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHUzMiBhZHZlcnRpc2UpDQotew0KLQlzdHJ1 Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnBy aXY7DQotCXUxNiBjdGwsIGFkdjsNCi0NCi0JLyogU2V0dXAgc3RhbmRhcmQgYWR2ZXJ0aXNlICov DQotCWFkdiA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9BRFZFUlRJU0UpOw0K LQlhZHYgJj0gfihBRFZFUlRJU0VfQUxMIHwgQURWRVJUSVNFXzEwMEJBU0U0KTsNCi0JaWYgKGFk dmVydGlzZSAmIEFEVkVSVElTRURfMTBiYXNlVF9IYWxmKQ0KLQkJYWR2IHw9IEFEVkVSVElTRV8x MEhBTEY7DQotCWlmIChhZHZlcnRpc2UgJiBBRFZFUlRJU0VEXzEwYmFzZVRfRnVsbCkNCi0JCWFk diB8PSBBRFZFUlRJU0VfMTBGVUxMOw0KLQlpZiAoYWR2ZXJ0aXNlICYgQURWRVJUSVNFRF8xMDBi YXNlVF9IYWxmKQ0KLQkJYWR2IHw9IEFEVkVSVElTRV8xMDBIQUxGOw0KLQlpZiAoYWR2ZXJ0aXNl ICYgQURWRVJUSVNFRF8xMDBiYXNlVF9GdWxsKQ0KLQkJYWR2IHw9IEFEVkVSVElTRV8xMDBGVUxM Ow0KLQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0FEVkVSVElTRSwgYWR2KTsN Ci0NCi0JLyogU3RhcnQvUmVzdGFydCBhbmVnICovDQotCWN0bCA9IG1kaW9fcmVhZChkZXYsIGF1 cC0+cGh5X2FkZHIsIE1JSV9CTUNSKTsNCi0JY3RsIHw9IChCTUNSX0FORU5BQkxFIHwgQk1DUl9B TlJFU1RBUlQpOw0KLQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0JNQ1IsIGN0 bCk7DQotDQotCXJldHVybiAwOw0KLX0NCi0NCi1zdGF0aWMgaW50IGF1MTAwMF9zZXR1cF9mb3Jj ZWQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHNwZWVkLCBpbnQgZmQpDQotew0KLQlzdHJ1 Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnBy aXY7DQotCXUxNiBjdGw7DQotDQotCWN0bCA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIs IE1JSV9CTUNSKTsNCi0JY3RsICY9IH4oQk1DUl9GVUxMRFBMWCB8IEJNQ1JfU1BFRUQxMDAgfCBC TUNSX0FORU5BQkxFKTsNCi0NCi0JLyogRmlyc3QgcmVzZXQgdGhlIFBIWSAqLw0KLQltZGlvX3dy aXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0JNQ1IsIGN0bCB8IEJNQ1JfUkVTRVQpOw0KLQ0K LQkvKiBTZWxlY3Qgc3BlZWQgJiBkdXBsZXggKi8NCi0Jc3dpdGNoIChzcGVlZCkgew0KLQkJY2Fz ZSBTUEVFRF8xMDoNCi0JCQlicmVhazsNCi0JCWNhc2UgU1BFRURfMTAwOg0KLQkJCWN0bCB8PSBC TUNSX1NQRUVEMTAwOw0KLQkJCWJyZWFrOw0KLQkJY2FzZSBTUEVFRF8xMDAwOg0KLQkJZGVmYXVs dDoNCi0JCQlyZXR1cm4gLUVJTlZBTDsNCi0JfQ0KLQlpZiAoZmQgPT0gRFVQTEVYX0ZVTEwpDQot CQljdGwgfD0gQk1DUl9GVUxMRFBMWDsNCi0JbWRpb193cml0ZShkZXYsIGF1cC0+cGh5X2FkZHIs IE1JSV9CTUNSLCBjdGwpOw0KLQ0KLQlyZXR1cm4gMDsNCi19DQotDQotDQotc3RhdGljIHZvaWQN Ci1hdTEwMDBfc3RhcnRfbGluayhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgZXRodG9v bF9jbWQgKmNtZCkNCi17DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBh dTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JdTMyIGFkdmVydGlzZTsNCi0JaW50IGF1dG9u ZWc7DQotCWludCBmb3JjZWRfc3BlZWQ7DQotCWludCBmb3JjZWRfZHVwbGV4Ow0KLQ0KLQkvKiBE ZWZhdWx0IGFkdmVydGlzZSAqLw0KLQlhZHZlcnRpc2UgPSBHRU5NSUlfREVGQVVMVF9BRFZFUlRJ U0U7DQotCWF1dG9uZWcgPSBhdXAtPndhbnRfYXV0b25lZzsNCi0JZm9yY2VkX3NwZWVkID0gU1BF RURfMTAwOw0KLQlmb3JjZWRfZHVwbGV4ID0gRFVQTEVYX0ZVTEw7DQotDQotCS8qIFNldHVwIGxp bmsgcGFyYW1ldGVycyAqLw0KLQlpZiAoY21kKSB7DQotCQlpZiAoY21kLT5hdXRvbmVnID09IEFV VE9ORUdfRU5BQkxFKSB7DQotCQkJYWR2ZXJ0aXNlID0gY21kLT5hZHZlcnRpc2luZzsNCi0JCQlh dXRvbmVnID0gMTsNCi0JCX0gZWxzZSB7DQotCQkJYXV0b25lZyA9IDA7DQotDQotCQkJZm9yY2Vk X3NwZWVkID0gY21kLT5zcGVlZDsNCi0JCQlmb3JjZWRfZHVwbGV4ID0gY21kLT5kdXBsZXg7DQot CQl9DQotCX0NCi0NCi0JLyogQ29uZmlndXJlIFBIWSAmIHN0YXJ0IGFuZWcgKi8NCi0JYXVwLT53 YW50X2F1dG9uZWcgPSBhdXRvbmVnOw0KLQlpZiAoYXV0b25lZykNCi0JCWF1MTAwMF9zZXR1cF9h bmVnKGRldiwgYWR2ZXJ0aXNlKTsNCi0JZWxzZQ0KLQkJYXUxMDAwX3NldHVwX2ZvcmNlZChkZXYs IGZvcmNlZF9zcGVlZCwgZm9yY2VkX2R1cGxleCk7DQotCW1vZF90aW1lcigmYXVwLT50aW1lciwg amlmZmllcyArIEhaKTsNCi19DQotDQogc3RhdGljIGludCBhdTEwMDBfZ2V0X3NldHRpbmdzKHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBldGh0b29sX2NtZCAqY21kKQ0KIHsNCiAJc3Ry dWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopZGV2LT5w cml2Ow0KLQl1MTYgbGluaywgc3BlZWQ7DQogDQotCWNtZC0+c3VwcG9ydGVkID0gR0VOTUlJX0RF RkFVTFRfRkVBVFVSRVM7DQotCWNtZC0+YWR2ZXJ0aXNpbmcgPSBHRU5NSUlfREVGQVVMVF9BRFZF UlRJU0U7DQotCWNtZC0+cG9ydCA9IFBPUlRfTUlJOw0KLQljbWQtPnRyYW5zY2VpdmVyID0gWENW Ul9FWFRFUk5BTDsNCi0JY21kLT5waHlfYWRkcmVzcyA9IGF1cC0+cGh5X2FkZHI7DQotCXNwaW5f bG9ja19pcnEoJmF1cC0+bG9jayk7DQotCWNtZC0+YXV0b25lZyA9IGF1cC0+d2FudF9hdXRvbmVn Ow0KLQlhdXAtPnBoeV9vcHMtPnBoeV9zdGF0dXMoZGV2LCBhdXAtPnBoeV9hZGRyLCAmbGluaywg JnNwZWVkKTsNCi0JaWYgKChzcGVlZCA9PSBJRl9QT1JUXzEwMEJBU0VUWCkgfHwgKHNwZWVkID09 IElGX1BPUlRfMTAwQkFTRUZYKSkNCi0JCWNtZC0+c3BlZWQgPSBTUEVFRF8xMDA7DQotCWVsc2Ug aWYgKHNwZWVkID09IElGX1BPUlRfMTBCQVNFVCkNCi0JCWNtZC0+c3BlZWQgPSBTUEVFRF8xMDsN Ci0JaWYgKGxpbmsgJiYgKGRldi0+aWZfcG9ydCA9PSBJRl9QT1JUXzEwMEJBU0VGWCkpDQotCQlj bWQtPmR1cGxleCA9IERVUExFWF9GVUxMOw0KLQllbHNlDQotCQljbWQtPmR1cGxleCA9IERVUExF WF9IQUxGOw0KLQlzcGluX3VubG9ja19pcnEoJmF1cC0+bG9jayk7DQotCXJldHVybiAwOw0KKwly ZXR1cm4gcGh5X2V0aHRvb2xfZ3NldChhdXAtPnBoeV9kZXYsIGNtZCk7DQogfQ0KIA0KIHN0YXRp YyBpbnQgYXUxMDAwX3NldF9zZXR0aW5ncyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3Qg ZXRodG9vbF9jbWQgKmNtZCkNCiB7DQogCSBzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnByaXY7DQotCSAgdW5zaWduZWQgbG9uZyBmZWF0 dXJlcyA9IEdFTk1JSV9ERUZBVUxUX0ZFQVRVUkVTOw0KIA0KIAkgaWYgKCFjYXBhYmxlKENBUF9O RVRfQURNSU4pKQ0KIAkJIHJldHVybiAtRVBFUk07DQogDQotCSBpZiAoY21kLT5hdXRvbmVnICE9 IEFVVE9ORUdfRU5BQkxFICYmIGNtZC0+YXV0b25lZyAhPSBBVVRPTkVHX0RJU0FCTEUpDQotCQkg cmV0dXJuIC1FSU5WQUw7DQotCSBpZiAoY21kLT5hdXRvbmVnID09IEFVVE9ORUdfRU5BQkxFICYm IGNtZC0+YWR2ZXJ0aXNpbmcgPT0gMCkNCi0JCSByZXR1cm4gLUVJTlZBTDsNCi0JIGlmIChjbWQt PmR1cGxleCAhPSBEVVBMRVhfSEFMRiAmJiBjbWQtPmR1cGxleCAhPSBEVVBMRVhfRlVMTCkNCi0J CSByZXR1cm4gLUVJTlZBTDsNCi0JIGlmIChjbWQtPmF1dG9uZWcgPT0gQVVUT05FR19ESVNBQkxF KQ0KLQkJIHN3aXRjaCAoY21kLT5zcGVlZCkgew0KLQkJIGNhc2UgU1BFRURfMTA6DQotCQkJIGlm IChjbWQtPmR1cGxleCA9PSBEVVBMRVhfSEFMRiAmJg0KLQkJCQkgKGZlYXR1cmVzICYgU1VQUE9S VEVEXzEwYmFzZVRfSGFsZikgPT0gMCkNCi0JCQkJIHJldHVybiAtRUlOVkFMOw0KLQkJCSBpZiAo Y21kLT5kdXBsZXggPT0gRFVQTEVYX0ZVTEwgJiYNCi0JCQkJIChmZWF0dXJlcyAmIFNVUFBPUlRF RF8xMGJhc2VUX0Z1bGwpID09IDApDQotCQkJCSByZXR1cm4gLUVJTlZBTDsNCi0JCQkgYnJlYWs7 DQotCQkgY2FzZSBTUEVFRF8xMDA6DQotCQkJIGlmIChjbWQtPmR1cGxleCA9PSBEVVBMRVhfSEFM RiAmJg0KLQkJCQkgKGZlYXR1cmVzICYgU1VQUE9SVEVEXzEwMGJhc2VUX0hhbGYpID09IDApDQot CQkJCSByZXR1cm4gLUVJTlZBTDsNCi0JCQkgaWYgKGNtZC0+ZHVwbGV4ID09IERVUExFWF9GVUxM ICYmDQotCQkJCSAoZmVhdHVyZXMgJiBTVVBQT1JURURfMTAwYmFzZVRfRnVsbCkgPT0gMCkNCi0J CQkJIHJldHVybiAtRUlOVkFMOw0KLQkJCSBicmVhazsNCi0JCSBkZWZhdWx0Og0KLQkJCSByZXR1 cm4gLUVJTlZBTDsNCi0JCSB9DQotCSBlbHNlIGlmICgoZmVhdHVyZXMgJiBTVVBQT1JURURfQXV0 b25lZykgPT0gMCkNCi0JCSByZXR1cm4gLUVJTlZBTDsNCi0NCi0JIHNwaW5fbG9ja19pcnEoJmF1 cC0+bG9jayk7DQotCSBhdTEwMDBfc3RhcnRfbGluayhkZXYsIGNtZCk7DQotCSBzcGluX3VubG9j a19pcnEoJmF1cC0+bG9jayk7DQotCSByZXR1cm4gMDsNCi19DQotDQotc3RhdGljIGludCBhdTEw MDBfbndheV9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KLXsNCi0Jc3RydWN0IGF1MTAw MF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopZGV2LT5wcml2Ow0KLQ0K LQlpZiAoIWF1cC0+d2FudF9hdXRvbmVnKQ0KLQkJcmV0dXJuIC1FSU5WQUw7DQotCXNwaW5fbG9j a19pcnEoJmF1cC0+bG9jayk7DQotCWF1MTAwMF9zdGFydF9saW5rKGRldiwgTlVMTCk7DQotCXNw aW5fdW5sb2NrX2lycSgmYXVwLT5sb2NrKTsNCi0JcmV0dXJuIDA7DQorCSAvL3NwaW5fbG9ja19p cnEoJmF1cC0+bG9jayk7IG5lZWQgdGhpcz8NCisJIHJldHVybiBwaHlfZXRodG9vbF9zc2V0KGF1 cC0+cGh5X2RldiwgY21kKTsNCiB9DQogDQogc3RhdGljIHZvaWQNCkBAIC0xNDIzLDE3ICs2NjUs MTEgQEAgYXUxMDAwX2dldF9kcnZpbmZvKHN0cnVjdCBuZXRfZGV2aWNlICpkZQ0KIAlpbmZvLT5y ZWdkdW1wX2xlbiA9IDA7DQogfQ0KIA0KLXN0YXRpYyB1MzIgYXUxMDAwX2dldF9saW5rKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQotew0KLQlyZXR1cm4gbmV0aWZfY2Fycmllcl9vayhkZXYpOw0K LX0NCi0NCiBzdGF0aWMgc3RydWN0IGV0aHRvb2xfb3BzIGF1MTAwMF9ldGh0b29sX29wcyA9IHsN CiAJLmdldF9zZXR0aW5ncyA9IGF1MTAwMF9nZXRfc2V0dGluZ3MsDQogCS5zZXRfc2V0dGluZ3Mg PSBhdTEwMDBfc2V0X3NldHRpbmdzLA0KIAkuZ2V0X2RydmluZm8gPSBhdTEwMDBfZ2V0X2Rydmlu Zm8sDQotCS5ud2F5X3Jlc2V0ID0gYXUxMDAwX253YXlfcmVzZXQsDQotCS5nZXRfbGluayA9IGF1 MTAwMF9nZXRfbGluaw0KKwkuZ2V0X2xpbmsgPSBldGh0b29sX29wX2dldF9saW5rLA0KIH07DQog DQogc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlICoNCkBAIC0xNTQ2LDYgKzc4MiwxOCBAQCBhdTEw MDBfcHJvYmUodTMyIGlvYWRkciwgaW50IGlycSwgaW50IHBvDQogCWF1cC0+bWlpLT5taWlfY29u dHJvbF9yZWcgPSAwOw0KIAlhdXAtPm1paS0+bWlpX2RhdGFfcmVnID0gMDsNCiANCisJYXVwLT5t aWlfYnVzLnByaXYgPSBkZXY7DQorCWF1cC0+bWlpX2J1cy5yZWFkID0gbWRpb2J1c19yZWFkOw0K KwlhdXAtPm1paV9idXMud3JpdGUgPSBtZGlvYnVzX3dyaXRlOw0KKwlhdXAtPm1paV9idXMucmVz ZXQgPSBtZGlvYnVzX3Jlc2V0Ow0KKwlhdXAtPm1paV9idXMubmFtZSA9ICJhdTEwMDBfZXRoX21p aSI7DQorCWF1cC0+bWlpX2J1cy5pZCA9IGF1cC0+bWFjX2lkOw0KKwlhdXAtPm1paV9idXMuaXJx ID0ga21hbGxvYyhzaXplb2YoaW50KSpQSFlfTUFYX0FERFIsIEdGUF9LRVJORUwpOw0KKwlmb3Io aSA9IDA7IGkgPCBQSFlfTUFYX0FERFI7ICsraSkNCisJCWF1cC0+bWlpX2J1cy5pcnFbaV0gPSBQ SFlfUE9MTDsNCisNCisJbWRpb2J1c19yZWdpc3RlcigmYXVwLT5taWlfYnVzKTsNCisNCiAJaWYg KG1paV9wcm9iZShkZXYpICE9IDApIHsNCiAJCWdvdG8gZXJyX291dDsNCiAJfQ0KQEAgLTE1OTAs NyArODM4LDYgQEAgYXUxMDAwX3Byb2JlKHUzMiBpb2FkZHIsIGludCBpcnEsIGludCBwbw0KIAlk ZXYtPnNldF9tdWx0aWNhc3RfbGlzdCA9ICZzZXRfcnhfbW9kZTsNCiAJZGV2LT5kb19pb2N0bCA9 ICZhdTEwMDBfaW9jdGw7DQogCVNFVF9FVEhUT09MX09QUyhkZXYsICZhdTEwMDBfZXRodG9vbF9v cHMpOw0KLQlkZXYtPnNldF9jb25maWcgPSAmYXUxMDAwX3NldF9jb25maWc7DQogCWRldi0+dHhf dGltZW91dCA9IGF1MTAwMF90eF90aW1lb3V0Ow0KIAlkZXYtPndhdGNoZG9nX3RpbWVvID0gRVRI X1RYX1RJTUVPVVQ7DQogDQpAQCAtMTY0MCw3ICs4ODcsNiBAQCBzdGF0aWMgaW50IGF1MTAwMF9p bml0KHN0cnVjdCBuZXRfZGV2aWNlDQogCXUzMiBmbGFnczsNCiAJaW50IGk7DQogCXUzMiBjb250 cm9sOw0KLQl1MTYgbGluaywgc3BlZWQ7DQogDQogCWlmIChhdTEwMDBfZGVidWcgPiA0KSANCiAJ CXByaW50aygiJXM6IGF1MTAwMF9pbml0XG4iLCBkZXYtPm5hbWUpOw0KQEAgLTE2NjgsMTQgKzkx NCwxMiBAQCBzdGF0aWMgaW50IGF1MTAwMF9pbml0KHN0cnVjdCBuZXRfZGV2aWNlDQogCX0NCiAJ YXVfc3luYygpOw0KIA0KLQlhdXAtPnBoeV9vcHMtPnBoeV9zdGF0dXMoZGV2LCBhdXAtPnBoeV9h ZGRyLCAmbGluaywgJnNwZWVkKTsNCiAJY29udHJvbCA9IE1BQ19ESVNBQkxFX1JYX09XTiB8IE1B Q19SWF9FTkFCTEUgfCBNQUNfVFhfRU5BQkxFOw0KICNpZm5kZWYgQ09ORklHX0NQVV9MSVRUTEVf RU5ESUFODQogCWNvbnRyb2wgfD0gTUFDX0JJR19FTkRJQU47DQogI2VuZGlmDQotCWlmIChsaW5r ICYmIChkZXYtPmlmX3BvcnQgPT0gSUZfUE9SVF8xMDBCQVNFRlgpKSB7DQotCQljb250cm9sIHw9 IE1BQ19GVUxMX0RVUExFWDsNCi0JfQ0KKwlpZiAoYXVwLT5waHlfZGV2LT5saW5rICYmIGF1cC0+ cGh5X2Rldi0+ZHVwbGV4KSANCisJCWNvbnRyb2wgfD0gTUFDX0ZVTExfRFVQTEVYOyANCiANCiAJ YXVwLT5tYWMtPmNvbnRyb2wgPSBjb250cm9sOw0KIAlhdXAtPm1hYy0+dmxhbjFfdGFnID0gMHg4 MTAwOyAvKiBhY3RpdmF0ZSB2bGFuIHN1cHBvcnQgKi8NCkBAIC0xNjg1LDU3ICs5MjksNzIgQEAg c3RhdGljIGludCBhdTEwMDBfaW5pdChzdHJ1Y3QgbmV0X2RldmljZQ0KIAlyZXR1cm4gMDsNCiB9 DQogDQotc3RhdGljIHZvaWQgYXUxMDAwX3RpbWVyKHVuc2lnbmVkIGxvbmcgZGF0YSkNCitzdGF0 aWMgdm9pZA0KK2F1MTAwMF9hZGp1c3RfbGluayhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KIHsN Ci0Jc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IChzdHJ1Y3QgbmV0X2RldmljZSAqKWRhdGE7DQog CXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBk ZXYtPnByaXY7DQotCXVuc2lnbmVkIGNoYXIgaWZfcG9ydDsNCi0JdTE2IGxpbmssIHNwZWVkOw0K KwlzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2ID0gYXVwLT5waHlfZGV2Ow0KKwl1bnNpZ25lZCBs b25nIGZsYWdzOw0KIA0KLQlpZiAoIWRldikgew0KLQkJLyogZmF0YWwgZXJyb3IsIGRvbid0IHJl c3RhcnQgdGhlIHRpbWVyICovDQotCQlwcmludGsoS0VSTl9FUlIgImF1MTAwMF90aW1lciBlcnJv cjogTlVMTCBkZXZcbiIpOw0KLQkJcmV0dXJuOw0KLQl9DQorCWludCBzdGF0dXNfY2hhbmdlID0g MDsNCiANCi0JaWZfcG9ydCA9IGRldi0+aWZfcG9ydDsNCi0JaWYgKGF1cC0+cGh5X29wcy0+cGh5 X3N0YXR1cyhkZXYsIGF1cC0+cGh5X2FkZHIsICZsaW5rLCAmc3BlZWQpID09IDApIHsNCi0JCWlm IChsaW5rKSB7DQotCQkJaWYgKCFuZXRpZl9jYXJyaWVyX29rKGRldikpIHsNCi0JCQkJbmV0aWZf Y2Fycmllcl9vbihkZXYpOw0KLQkJCQlwcmludGsoS0VSTl9JTkZPICIlczogbGluayB1cFxuIiwg ZGV2LT5uYW1lKTsNCi0JCQl9DQotCQl9DQotCQllbHNlIHsNCi0JCQlpZiAobmV0aWZfY2Fycmll cl9vayhkZXYpKSB7DQotCQkJCW5ldGlmX2NhcnJpZXJfb2ZmKGRldik7DQotCQkJCWRldi0+aWZf cG9ydCA9IDA7DQotCQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBsaW5rIGRvd25cbiIsIGRldi0+ bmFtZSk7DQotCQkJfQ0KKwlzcGluX2xvY2tfaXJxc2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQor DQorCWlmIChwaHlkZXYtPmxpbmsgJiYgKGF1cC0+b2xkX3NwZWVkICE9IHBoeWRldi0+c3BlZWQp KSB7DQorCQkvLyBzcGVlZCBjaGFuZ2VkIA0KKw0KKwkJc3dpdGNoKHBoeWRldi0+c3BlZWQpIHsN CisJCWNhc2UgMTA6DQorCQljYXNlIDEwMDoNCisJCQlicmVhazsNCisJCWRlZmF1bHQ6DQorCQkJ cHJpbnRrKEtFUk5fV0FSTklORw0KKwkJCSAgICAgICAiJXM6IFNwZWVkICglZCkgaXMgbm90IDEw LzEwMC8xMDAwID8/XG4iLA0KKwkJCSAgICAgICBkZXYtPm5hbWUsIHBoeWRldi0+c3BlZWQpOw0K KwkJCWJyZWFrOw0KIAkJfQ0KKw0KKwkJYXVwLT5vbGRfc3BlZWQgPSBwaHlkZXYtPnNwZWVkOw0K Kw0KKwkJc3RhdHVzX2NoYW5nZSA9IDE7DQogCX0NCiANCi0JaWYgKGxpbmsgJiYgKGRldi0+aWZf cG9ydCAhPSBpZl9wb3J0KSAmJiANCi0JCQkoZGV2LT5pZl9wb3J0ICE9IElGX1BPUlRfVU5LTk9X TikpIHsNCi0JCWhhcmRfc3RvcChkZXYpOw0KLQkJaWYgKGRldi0+aWZfcG9ydCA9PSBJRl9QT1JU XzEwMEJBU0VGWCkgew0KLQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBnb2luZyB0byBmdWxsIGR1 cGxleFxuIiwgDQotCQkJCQlkZXYtPm5hbWUpOw0KKwlpZiAocGh5ZGV2LT5saW5rICYmIChhdXAt Pm9sZF9kdXBsZXggIT0gcGh5ZGV2LT5kdXBsZXgpKSB7DQorCQkvLyBkdXBsZXggbW9kZSBjaGFu Z2VkDQorCQkNCisJCS8vaGFyZF9zdG9wKGRldik7DQorDQorCQlpZiAocGh5ZGV2LT5kdXBsZXgp DQogCQkJYXVwLT5tYWMtPmNvbnRyb2wgfD0gTUFDX0ZVTExfRFVQTEVYOw0KLQkJCWF1X3N5bmNf ZGVsYXkoMSk7DQotCQl9DQotCQllbHNlIHsNCisJCWVsc2UNCiAJCQlhdXAtPm1hYy0+Y29udHJv bCAmPSB+TUFDX0ZVTExfRFVQTEVYOw0KLQkJCWF1X3N5bmNfZGVsYXkoMSk7DQorCQlhdV9zeW5j X2RlbGF5KDEpOw0KKw0KKwkJLy9lbmFibGVfcnhfdHgoZGV2KTsNCisJCWF1cC0+b2xkX2R1cGxl eCA9IHBoeWRldi0+ZHVwbGV4Ow0KKw0KKwkJc3RhdHVzX2NoYW5nZSA9IDE7DQorCX0NCisNCisJ aWYocGh5ZGV2LT5saW5rICE9IGF1cC0+b2xkX2xpbmspIHsNCisJCS8vIGxpbmsgc3RhdGUgY2hh bmdlZA0KKw0KKwkJaWYgKHBoeWRldi0+bGluaykgeyAvLyBsaW5rIHdlbnQgdXANCisJCQluZXRp Zl9zY2hlZHVsZShkZXYpOw0KKwkJfSBlbHNlIHsgLy8gbGluayB3ZW50IGRvd24NCisJCQlhdXAt Pm9sZF9zcGVlZCA9IDA7DQorCQkJYXVwLT5vbGRfZHVwbGV4ID0gLTE7DQogCQl9DQotCQllbmFi bGVfcnhfdHgoZGV2KTsNCisNCisJCWF1cC0+b2xkX2xpbmsgPSBwaHlkZXYtPmxpbms7DQorCQlz dGF0dXNfY2hhbmdlID0gMTsNCiAJfQ0KIA0KLQlhdXAtPnRpbWVyLmV4cGlyZXMgPSBSVU5fQVQo KDEqSFopKTsgDQotCWF1cC0+dGltZXIuZGF0YSA9ICh1bnNpZ25lZCBsb25nKWRldjsNCi0JYXVw LT50aW1lci5mdW5jdGlvbiA9ICZhdTEwMDBfdGltZXI7IC8qIHRpbWVyIGhhbmRsZXIgKi8NCi0J YWRkX3RpbWVyKCZhdXAtPnRpbWVyKTsNCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYXVwLT5s b2NrLCBmbGFncyk7DQogDQorCWlmIChzdGF0dXNfY2hhbmdlKSB7DQorCQlwaHlfcHJpbnRfc3Rh dHVzKHBoeWRldik7DQorCX0NCiB9DQogDQogc3RhdGljIGludCBhdTEwMDBfb3BlbihzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KQEAgLTE3NDYsMTMgKzEwMDUsNiBAQCBzdGF0aWMgaW50IGF1MTAw MF9vcGVuKHN0cnVjdCBuZXRfZGV2aWNlDQogCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KIAkJcHJp bnRrKCIlczogb3BlbjogZGV2PSVwXG4iLCBkZXYtPm5hbWUsIGRldik7DQogDQotCWlmICgocmV0 dmFsID0gYXUxMDAwX2luaXQoZGV2KSkpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAiJXM6IGVycm9y IGluIGF1MTAwMF9pbml0XG4iLCBkZXYtPm5hbWUpOw0KLQkJZnJlZV9pcnEoZGV2LT5pcnEsIGRl dik7DQotCQlyZXR1cm4gcmV0dmFsOw0KLQl9DQotCW5ldGlmX3N0YXJ0X3F1ZXVlKGRldik7DQot DQogCWlmICgocmV0dmFsID0gcmVxdWVzdF9pcnEoZGV2LT5pcnEsICZhdTEwMDBfaW50ZXJydXB0 LCAwLCANCiAJCQkJCWRldi0+bmFtZSwgZGV2KSkpIHsNCiAJCXByaW50ayhLRVJOX0VSUiAiJXM6 IHVuYWJsZSB0byBnZXQgSVJRICVkXG4iLCANCkBAIC0xNzYwLDExICsxMDEyLDE1IEBAIHN0YXRp YyBpbnQgYXUxMDAwX29wZW4oc3RydWN0IG5ldF9kZXZpY2UNCiAJCXJldHVybiByZXR2YWw7DQog CX0NCiANCi0JaW5pdF90aW1lcigmYXVwLT50aW1lcik7IC8qIHVzZWQgaW4gaW9jdGwoKSAqLw0K LQlhdXAtPnRpbWVyLmV4cGlyZXMgPSBSVU5fQVQoKDMqSFopKTsgDQotCWF1cC0+dGltZXIuZGF0 YSA9ICh1bnNpZ25lZCBsb25nKWRldjsNCi0JYXVwLT50aW1lci5mdW5jdGlvbiA9ICZhdTEwMDBf dGltZXI7IC8qIHRpbWVyIGhhbmRsZXIgKi8NCi0JYWRkX3RpbWVyKCZhdXAtPnRpbWVyKTsNCisJ aWYgKChyZXR2YWwgPSBhdTEwMDBfaW5pdChkZXYpKSkgew0KKwkJcHJpbnRrKEtFUk5fRVJSICIl czogZXJyb3IgaW4gYXUxMDAwX2luaXRcbiIsIGRldi0+bmFtZSk7DQorCQlmcmVlX2lycShkZXYt PmlycSwgZGV2KTsNCisJCXJldHVybiByZXR2YWw7DQorCX0NCisNCisJcGh5X3N0YXJ0KGF1cC0+ cGh5X2Rldik7DQorDQorCW5ldGlmX3N0YXJ0X3F1ZXVlKGRldik7DQogDQogCWlmIChhdTEwMDBf ZGVidWcgPiA0KQ0KIAkJcHJpbnRrKCIlczogb3BlbjogSW5pdGlhbGl6YXRpb24gZG9uZS5cbiIs IGRldi0+bmFtZSk7DQpAQCAtMTc4Nyw2ICsxMDQzLDggQEAgc3RhdGljIGludCBhdTEwMDBfY2xv c2Uoc3RydWN0IG5ldF9kZXZpYw0KIAkvKiBzdG9wIHRoZSBkZXZpY2UgKi8NCiAJbmV0aWZfc3Rv cF9xdWV1ZShkZXYpOw0KIA0KKwlwaHlfc3RvcChhdXAtPnBoeV9kZXYpOw0KKw0KIAkvKiBkaXNh YmxlIHRoZSBpbnRlcnJ1cHQgKi8NCiAJZnJlZV9pcnEoZGV2LT5pcnEsIGRldik7DQogCXNwaW5f dW5sb2NrX2lycXJlc3RvcmUoJmF1cC0+bG9jaywgZmxhZ3MpOw0KQEAgLTE4MzAsNyArMTA4OCw3 IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV90eF9zdGF0cyhzdHJ1Y3QgbmV0X2QNCiAJc3RydWN0IG5l dF9kZXZpY2Vfc3RhdHMgKnBzID0gJmF1cC0+c3RhdHM7DQogDQogCWlmIChzdGF0dXMgJiBUWF9G UkFNRV9BQk9SVEVEKSB7DQotCQlpZiAoZGV2LT5pZl9wb3J0ID09IElGX1BPUlRfMTAwQkFTRUZY KSB7DQorCQlpZiAoYXVwLT5waHlfZGV2LT5kdXBsZXgpIHsNCiAJCQlpZiAoc3RhdHVzICYgKFRY X0pBQl9USU1FT1VUIHwgVFhfVU5ERVJSVU4pKSB7DQogCQkJCS8qIGFueSBvdGhlciB0eCBlcnJv cnMgYXJlIG9ubHkgdmFsaWQNCiAJCQkJICogaW4gaGFsZiBkdXBsZXggbW9kZSAqLw0KQEAgLTIx MDQsMTI2ICsxMzYyLDEzIEBAIHN0YXRpYyB2b2lkIHNldF9yeF9tb2RlKHN0cnVjdCBuZXRfZGV2 aWMNCiAJfQ0KIH0NCiANCi0NCiBzdGF0aWMgaW50IGF1MTAwMF9pb2N0bChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKnJxLCBpbnQgY21kKQ0KIHsNCiAJc3RydWN0IGF1MTAw MF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopZGV2LT5wcml2Ow0KLQl1 MTYgKmRhdGEgPSAodTE2ICopJnJxLT5pZnJfaWZydTsNCi0NCi0Jc3dpdGNoKGNtZCkgeyANCi0J CWNhc2UgU0lPQ0RFVlBSSVZBVEU6CS8qIEdldCB0aGUgYWRkcmVzcyBvZiB0aGUgUEhZIGluIHVz ZS4gKi8NCi0JCWNhc2UgU0lPQ0dNSUlQSFk6DQotCQkgICAgICAgIGlmICghbmV0aWZfcnVubmlu ZyhkZXYpKSByZXR1cm4gLUVJTlZBTDsNCi0JCQlkYXRhWzBdID0gYXVwLT5waHlfYWRkcjsNCi0J CWNhc2UgU0lPQ0RFVlBSSVZBVEUrMToJLyogUmVhZCB0aGUgc3BlY2lmaWVkIE1JSSByZWdpc3Rl ci4gKi8NCi0JCWNhc2UgU0lPQ0dNSUlSRUc6DQotCQkJZGF0YVszXSA9ICBtZGlvX3JlYWQoZGV2 LCBkYXRhWzBdLCBkYXRhWzFdKTsgDQotCQkJcmV0dXJuIDA7DQotCQljYXNlIFNJT0NERVZQUklW QVRFKzI6CS8qIFdyaXRlIHRoZSBzcGVjaWZpZWQgTUlJIHJlZ2lzdGVyICovDQotCQljYXNlIFNJ T0NTTUlJUkVHOiANCi0JCQlpZiAoIWNhcGFibGUoQ0FQX05FVF9BRE1JTikpDQotCQkJCXJldHVy biAtRVBFUk07DQotCQkJbWRpb193cml0ZShkZXYsIGRhdGFbMF0sIGRhdGFbMV0sZGF0YVsyXSk7 DQotCQkJcmV0dXJuIDA7DQotCQlkZWZhdWx0Og0KLQkJCXJldHVybiAtRU9QTk9UU1VQUDsNCi0J fQ0KLQ0KLX0NCi0NCi0NCi1zdGF0aWMgaW50IGF1MTAwMF9zZXRfY29uZmlnKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYsIHN0cnVjdCBpZm1hcCAqbWFwKQ0KLXsNCi0Jc3RydWN0IGF1MTAwMF9wcml2 YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0JdTE2IGNv bnRyb2w7DQogDQotCWlmIChhdTEwMDBfZGVidWcgPiA0KSAgew0KLQkJcHJpbnRrKCIlczogc2V0 X2NvbmZpZyBjYWxsZWQ6IGRldi0+aWZfcG9ydCAlZCBtYXAtPnBvcnQgJXhcbiIsIA0KLQkJCQlk ZXYtPm5hbWUsIGRldi0+aWZfcG9ydCwgbWFwLT5wb3J0KTsNCi0JfQ0KKwlpZiAoIW5ldGlmX3J1 bm5pbmcoZGV2KSkgcmV0dXJuIC1FSU5WQUw7DQogDQotCXN3aXRjaChtYXAtPnBvcnQpew0KLQkJ Y2FzZSBJRl9QT1JUX1VOS05PV046IC8qIHVzZSBhdXRvIGhlcmUgKi8gICANCi0JCQlwcmludGso S0VSTl9JTkZPICIlczogY29uZmlnIHBoeSBmb3IgYW5lZ1xuIiwgDQotCQkJCQlkZXYtPm5hbWUp Ow0KLQkJCWRldi0+aWZfcG9ydCA9IG1hcC0+cG9ydDsNCi0JCQkvKiBMaW5rIERvd246IHRoZSB0 aW1lciB3aWxsIGJyaW5nIGl0IHVwICovDQotCQkJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsNCi0J DQotCQkJLyogcmVhZCBjdXJyZW50IGNvbnRyb2wgKi8NCi0JCQljb250cm9sID0gbWRpb19yZWFk KGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJCWNvbnRyb2wgJj0gfihNSUlf Q05UTF9GRFggfCBNSUlfQ05UTF9GMTAwKTsNCi0NCi0JCQkvKiBlbmFibGUgYXV0byBuZWdvdGlh dGlvbiBhbmQgcmVzZXQgdGhlIG5lZ290aWF0aW9uICovDQotCQkJbWRpb193cml0ZShkZXYsIGF1 cC0+cGh5X2FkZHIsIE1JSV9DT05UUk9MLCANCi0JCQkJCWNvbnRyb2wgfCBNSUlfQ05UTF9BVVRP IHwgDQotCQkJCQlNSUlfQ05UTF9SU1RfQVVUTyk7DQotDQotCQkJYnJlYWs7DQotICAgIA0KLQkJ Y2FzZSBJRl9QT1JUXzEwQkFTRVQ6IC8qIDEwQmFzZVQgKi8gICAgICAgICANCi0JCQlwcmludGso S0VSTl9JTkZPICIlczogY29uZmlnIHBoeSBmb3IgMTBCYXNlVFxuIiwgDQotCQkJCQlkZXYtPm5h bWUpOw0KLQkJCWRldi0+aWZfcG9ydCA9IG1hcC0+cG9ydDsNCi0JDQotCQkJLyogTGluayBEb3du OiB0aGUgdGltZXIgd2lsbCBicmluZyBpdCB1cCAqLw0KLQkJCW5ldGlmX2NhcnJpZXJfb2ZmKGRl dik7DQotDQotCQkJLyogc2V0IFNwZWVkIHRvIDEwTWJwcywgSGFsZiBEdXBsZXggKi8NCi0JCQlj b250cm9sID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJ CWNvbnRyb2wgJj0gfihNSUlfQ05UTF9GMTAwIHwgTUlJX0NOVExfQVVUTyB8IA0KLQkJCQkJTUlJ X0NOVExfRkRYKTsNCi0JDQotCQkJLyogZGlzYWJsZSBhdXRvIG5lZ290aWF0aW9uIGFuZCBmb3Jj ZSAxME0vSEQgbW9kZSovDQotCQkJbWRpb193cml0ZShkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9D T05UUk9MLCBjb250cm9sKTsNCi0JCQlicmVhazsNCi0gICAgDQotCQljYXNlIElGX1BPUlRfMTAw QkFTRVQ6IC8qIDEwMEJhc2VUICovDQotCQljYXNlIElGX1BPUlRfMTAwQkFTRVRYOiAvKiAxMDBC YXNlVHggKi8gDQotCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IGNvbmZpZyBwaHkgZm9yIDEwMEJh c2VUWFxuIiwgDQotCQkJCQlkZXYtPm5hbWUpOw0KLQkJCWRldi0+aWZfcG9ydCA9IG1hcC0+cG9y dDsNCi0JDQotCQkJLyogTGluayBEb3duOiB0aGUgdGltZXIgd2lsbCBicmluZyBpdCB1cCAqLw0K LQkJCW5ldGlmX2NhcnJpZXJfb2ZmKGRldik7DQotCQ0KLQkJCS8qIHNldCBTcGVlZCB0byAxMDBN YnBzLCBIYWxmIER1cGxleCAqLw0KLQkJCS8qIGRpc2FibGUgYXV0byBuZWdvdGlhdGlvbiBhbmQg ZW5hYmxlIDEwME1CaXQgTW9kZSAqLw0KLQkJCWNvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBhdXAt PnBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCQkJY29udHJvbCAmPSB+KE1JSV9DTlRMX0FVVE8g fCBNSUlfQ05UTF9GRFgpOw0KLQkJCWNvbnRyb2wgfD0gTUlJX0NOVExfRjEwMDsNCi0JCQltZGlv X3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wsIGNvbnRyb2wpOw0KLQkJCWJy ZWFrOw0KLSAgICANCi0JCWNhc2UgSUZfUE9SVF8xMDBCQVNFRlg6IC8qIDEwMEJhc2VGeCAqLw0K LQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBjb25maWcgcGh5IGZvciAxMDBCYXNlRlhcbiIsIA0K LQkJCQkJZGV2LT5uYW1lKTsNCi0JCQlkZXYtPmlmX3BvcnQgPSBtYXAtPnBvcnQ7DQotCQ0KLQkJ CS8qIExpbmsgRG93bjogdGhlIHRpbWVyIHdpbGwgYnJpbmcgaXQgdXAgKi8NCi0JCQluZXRpZl9j YXJyaWVyX29mZihkZXYpOw0KLQkNCi0JCQkvKiBzZXQgU3BlZWQgdG8gMTAwTWJwcywgRnVsbCBE dXBsZXggKi8NCi0JCQkvKiBkaXNhYmxlIGF1dG8gbmVnb3RpYXRpb24gYW5kIGVuYWJsZSAxMDBN Qml0IE1vZGUgKi8NCi0JCQljb250cm9sID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQkJCWNvbnRyb2wgJj0gfk1JSV9DTlRMX0FVVE87DQotCQkJY29udHJv bCB8PSAgTUlJX0NOVExfRjEwMCB8IE1JSV9DTlRMX0ZEWDsNCi0JCQltZGlvX3dyaXRlKGRldiwg YXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wsIGNvbnRyb2wpOw0KLQkJCWJyZWFrOw0KLQkJY2Fz ZSBJRl9QT1JUXzEwQkFTRTI6IC8qIDEwQmFzZTIgKi8NCi0JCWNhc2UgSUZfUE9SVF9BVUk6IC8q IEFVSSAqLw0KLQkJLyogVGhlc2UgTW9kZXMgYXJlIG5vdCBzdXBwb3J0ZWQgKGFyZSB0aGV5Pykq Lw0KLQkJCXByaW50ayhLRVJOX0VSUiAiJXM6IDEwQmFzZTIvQVVJIG5vdCBzdXBwb3J0ZWQiLCAN Ci0JCQkJCWRldi0+bmFtZSk7DQotCQkJcmV0dXJuIC1FT1BOT1RTVVBQOw0KLQkJCWJyZWFrOw0K LSAgICANCi0JCWRlZmF1bHQ6DQotCQkJcHJpbnRrKEtFUk5fRVJSICIlczogSW52YWxpZCBtZWRp YSBzZWxlY3RlZCIsIA0KLQkJCQkJZGV2LT5uYW1lKTsNCi0JCQlyZXR1cm4gLUVJTlZBTDsNCi0J fQ0KLQlyZXR1cm4gMDsNCisJcmV0dXJuIHBoeV9taWlfaW9jdGwoYXVwLT5waHlfZGV2LCBpZl9t aWkocnEpLCBjbWQpOw0KIH0NCiANCiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKmF1 MTAwMF9nZXRfc3RhdHMoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCmRpZmYgLS1naXQgYS9kcml2 ZXJzL25ldC9hdTEwMDBfZXRoLmggYi9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmgNCmluZGV4IGNj YjM1ZmEuLjkzYjMyZjEgMTAwNjQ0DQotLS0gYS9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmgNCisr KyBiL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguaA0KQEAgLTQwLDEwNiArNDAsNiBAQA0KIA0KICNk ZWZpbmUgTVVMVElDQVNUX0ZJTFRFUl9MSU1JVCA2NA0KIA0KLS8qIEZJWE1FIA0KLSAqIFRoZSBQ SFkgZGVmaW5lcyBzaG91bGQgYmUgaW4gYSBzZXBhcmF0ZSBmaWxlLg0KLSAqLw0KLQ0KLS8qIE1J SSByZWdpc3RlciBvZmZzZXRzICovDQotI2RlZmluZQlNSUlfQ09OVFJPTCAweDAwMDANCi0jZGVm aW5lIE1JSV9TVEFUVVMgIDB4MDAwMQ0KLSNkZWZpbmUgTUlJX1BIWV9JRDAgMHgwMDAyDQotI2Rl ZmluZQlNSUlfUEhZX0lEMSAweDAwMDMNCi0jZGVmaW5lIE1JSV9BTkFEViAgIDB4MDAwNA0KLSNk ZWZpbmUgTUlJX0FOTFBBUiAgMHgwMDA1DQotI2RlZmluZSBNSUlfQUVYUCAgICAweDAwMDYNCi0j ZGVmaW5lIE1JSV9BTkVYVCAgIDB4MDAwNw0KLSNkZWZpbmUgTUlJX0xTSV9QSFlfQ09ORklHIDB4 MDAxMQ0KLS8qIFN0YXR1cyByZWdpc3RlciAqLw0KLSNkZWZpbmUgTUlJX0xTSV9QSFlfU1RBVCAg IDB4MDAxMg0KLSNkZWZpbmUgTUlJX0FNRF9QSFlfU1RBVCAgIE1JSV9MU0lfUEhZX1NUQVQNCi0j ZGVmaW5lIE1JSV9JTlRFTF9QSFlfU1RBVCAweDAwMTENCi0NCi0jZGVmaW5lIE1JSV9BVVhfQ05U UkwgIDB4MDAxOA0KLS8qIG1paSByZWdpc3RlcnMgc3BlY2lmaWMgdG8gQU1EIDc5QzkwMSAqLw0K LSNkZWZpbmUJTUlJX1NUQVRVU19TVU1NQVJZID0gMHgwMDE4DQotDQotLyogTUlJIENvbnRyb2wg cmVnaXN0ZXIgYml0IGRlZmluaXRpb25zLiAqLw0KLSNkZWZpbmUJTUlJX0NOVExfRkRYICAgICAg MHgwMTAwDQotI2RlZmluZSBNSUlfQ05UTF9SU1RfQVVUTyAweDAyMDANCi0jZGVmaW5lCU1JSV9D TlRMX0lTT0xBVEUgIDB4MDQwMA0KLSNkZWZpbmUgTUlJX0NOVExfUFdSRFdOICAgMHgwODAwDQot I2RlZmluZQlNSUlfQ05UTF9BVVRPICAgICAweDEwMDANCi0jZGVmaW5lIE1JSV9DTlRMX0YxMDAg ICAgIDB4MjAwMA0KLSNkZWZpbmUJTUlJX0NOVExfTFBCSyAgICAgMHg0MDAwDQotI2RlZmluZSBN SUlfQ05UTF9SRVNFVCAgICAweDgwMDANCi0NCi0vKiBNSUkgU3RhdHVzIHJlZ2lzdGVyIGJpdCAg Ki8NCi0jZGVmaW5lCU1JSV9TVEFUX0VYVCAgICAgICAgMHgwMDAxIA0KLSNkZWZpbmUgTUlJX1NU QVRfSkFCICAgICAgICAweDAwMDINCi0jZGVmaW5lCU1JSV9TVEFUX0xJTksgICAgICAgMHgwMDA0 DQotI2RlZmluZSBNSUlfU1RBVF9DQU5fQVVUTyAgIDB4MDAwOA0KLSNkZWZpbmUJTUlJX1NUQVRf RkFVTFQgICAgICAweDAwMTAgDQotI2RlZmluZSBNSUlfU1RBVF9BVVRPX0RPTkUgIDB4MDAyMA0K LSNkZWZpbmUJTUlJX1NUQVRfQ0FOX1QgICAgICAweDA4MDANCi0jZGVmaW5lIE1JSV9TVEFUX0NB Tl9UX0ZEWCAgMHgxMDAwDQotI2RlZmluZQlNSUlfU1RBVF9DQU5fVFggICAgIDB4MjAwMCANCi0j ZGVmaW5lIE1JSV9TVEFUX0NBTl9UWF9GRFggMHg0MDAwDQotI2RlZmluZQlNSUlfU1RBVF9DQU5f VDQgICAgIDB4ODAwMA0KLQ0KLQ0KLSNkZWZpbmUJCU1JSV9JRDFfT1VJX0xPCQkweEZDMDAJLyog bG93IGJpdHMgb2YgT1VJIG1hc2sgKi8NCi0jZGVmaW5lCQlNSUlfSUQxX01PREVMCQkweDAzRjAJ LyogbW9kZWwgbnVtYmVyICovDQotI2RlZmluZQkJTUlJX0lEMV9SRVYJCTB4MDAwRgkvKiBtb2Rl bCBudW1iZXIgKi8NCi0NCi0vKiBNSUkgTldBWSBSZWdpc3RlciBCaXRzIC4uLg0KLSAgIHZhbGlk IGZvciB0aGUgQU5BUiAoQXV0by1OZWdvdGlhdGlvbiBBZHZlcnRpc2VtZW50KSBhbmQNCi0gICBB TkxQQVIgKEF1dG8tTmVnb3RpYXRpb24gTGluayBQYXJ0bmVyKSByZWdpc3RlcnMgKi8NCi0jZGVm aW5lCU1JSV9OV0FZX05PREVfU0VMIDB4MDAxZg0KLSNkZWZpbmUgTUlJX05XQVlfQ1NNQV9DRCAg MHgwMDAxDQotI2RlZmluZQlNSUlfTldBWV9UCSAgMHgwMDIwDQotI2RlZmluZSBNSUlfTldBWV9U X0ZEWCAgICAweDAwNDANCi0jZGVmaW5lCU1JSV9OV0FZX1RYICAgICAgIDB4MDA4MA0KLSNkZWZp bmUgTUlJX05XQVlfVFhfRkRYICAgMHgwMTAwDQotI2RlZmluZQlNSUlfTldBWV9UNCAgICAgICAw eDAyMDAgDQotI2RlZmluZSBNSUlfTldBWV9QQVVTRSAgICAweDA0MDAgDQotI2RlZmluZQlNSUlf TldBWV9SRiAgICAgICAweDIwMDAgLyogUmVtb3RlIEZhdWx0ICovDQotI2RlZmluZSBNSUlfTldB WV9BQ0sgICAgICAweDQwMDAgLyogUmVtb3RlIEFja25vd2xlZGdlICovDQotI2RlZmluZQlNSUlf TldBWV9OUCAgICAgICAweDgwMDAgLyogTmV4dCBQYWdlIChFbmFibGUpICovDQotDQotLyogbWlp IHN0c291dCByZWdpc3RlciBiaXRzICovDQotI2RlZmluZQlNSUlfU1RTT1VUX0xJTktfRkFJTCAw eDQwMDANCi0jZGVmaW5lCU1JSV9TVFNPVVRfU1BEICAgICAgIDB4MDA4MA0KLSNkZWZpbmUgTUlJ X1NUU09VVF9EUExYICAgICAgMHgwMDQwDQotDQotLyogbWlpIHN0c2ljcyByZWdpc3RlciBiaXRz ICovDQotI2RlZmluZQlNSUlfU1RTSUNTX1NQRCAgICAgICAweDgwMDANCi0jZGVmaW5lIE1JSV9T VFNJQ1NfRFBMWCAgICAgIDB4NDAwMA0KLSNkZWZpbmUJTUlJX1NUU0lDU19MSU5LU1RTICAgMHgw MDAxDQotDQotLyogbWlpIHN0c3N1bSByZWdpc3RlciBiaXRzICovDQotI2RlZmluZQlNSUlfU1RT U1VNX0xJTksgIDB4MDAwOA0KLSNkZWZpbmUgTUlJX1NUU1NVTV9EUExYICAweDAwMDQNCi0jZGVm aW5lCU1JSV9TVFNTVU1fQVVUTyAgMHgwMDAyDQotI2RlZmluZSBNSUlfU1RTU1VNX1NQRCAgIDB4 MDAwMQ0KLQ0KLS8qIGxzaSBwaHkgc3RhdHVzIHJlZ2lzdGVyICovDQotI2RlZmluZSBNSUlfTFNJ X1BIWV9TVEFUX0ZEWAkweDAwNDANCi0jZGVmaW5lIE1JSV9MU0lfUEhZX1NUQVRfU1BECTB4MDA4 MA0KLQ0KLS8qIGFtZCBwaHkgc3RhdHVzIHJlZ2lzdGVyICovDQotI2RlZmluZSBNSUlfQU1EX1BI WV9TVEFUX0ZEWAkweDA4MDANCi0jZGVmaW5lIE1JSV9BTURfUEhZX1NUQVRfU1BECTB4MDQwMA0K LQ0KLS8qIGludGVsIHBoeSBzdGF0dXMgcmVnaXN0ZXIgKi8NCi0jZGVmaW5lIE1JSV9JTlRFTF9Q SFlfU1RBVF9GRFgJMHgwMjAwDQotI2RlZmluZSBNSUlfSU5URUxfUEhZX1NUQVRfU1BECTB4NDAw MA0KLQ0KLS8qIEF1eGlsbGlhcnkgQ29udHJvbC9TdGF0dXMgUmVnaXN0ZXIgKi8NCi0jZGVmaW5l IE1JSV9BVVhfRkRYICAgICAgMHgwMDAxDQotI2RlZmluZSBNSUlfQVVYXzEwMCAgICAgIDB4MDAw Mg0KLSNkZWZpbmUgTUlJX0FVWF9GMTAwICAgICAweDAwMDQNCi0jZGVmaW5lIE1JSV9BVVhfQU5F RyAgICAgMHgwMDA4DQotDQogdHlwZWRlZiBzdHJ1Y3QgbWlpX3BoeSB7DQogCXN0cnVjdCBtaWlf cGh5ICogbmV4dDsNCiAJc3RydWN0IG1paV9jaGlwX2luZm8gKiBjaGlwX2luZm87DQpAQCAtMTQ4 LDEyICs0OCw2IEBAIHR5cGVkZWYgc3RydWN0IG1paV9waHkgew0KIAl1MzIgKm1paV9kYXRhX3Jl ZzsNCiB9IG1paV9waHlfdDsNCiANCi1zdHJ1Y3QgcGh5X29wcyB7DQotCWludCAoKnBoeV9pbml0 KSAoc3RydWN0IG5ldF9kZXZpY2UgKiwgaW50KTsNCi0JaW50ICgqcGh5X3Jlc2V0KSAoc3RydWN0 IG5ldF9kZXZpY2UgKiwgaW50KTsNCi0JaW50ICgqcGh5X3N0YXR1cykgKHN0cnVjdCBuZXRfZGV2 aWNlICosIGludCwgdTE2ICosIHUxNiAqKTsNCi19Ow0KLQ0KIC8qIA0KICAqIERhdGEgQnVmZmVy IERlc2NyaXB0b3IuIERhdGEgYnVmZmVycyBtdXN0IGJlIGFsaWduZWQgb24gMzIgYnl0ZSANCiAg KiBib3VuZGFyeSBmb3IgYm90aCwgcmVjZWl2ZSBhbmQgdHJhbnNtaXQuDQpAQCAtMjAwLDcgKzk0 LDYgQEAgdHlwZWRlZiBzdHJ1Y3QgbWFjX3JlZyB7DQogDQogDQogc3RydWN0IGF1MTAwMF9wcml2 YXRlIHsNCi0JDQogCWRiX2Rlc3RfdCAqcERCZnJlZTsNCiAJZGJfZGVzdF90IGRiW05VTV9SWF9C VUZGUytOVU1fVFhfQlVGRlNdOw0KIAl2b2xhdGlsZSByeF9kbWFfdCAqcnhfZG1hX3JpbmdbTlVN X1JYX0RNQV07DQpAQCAtMjE0LDggKzEwNywxNCBAQCBzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgew0K IA0KIAlpbnQgbWFjX2lkOw0KIAltaWlfcGh5X3QgKm1paTsNCi0Jc3RydWN0IG1paV9pZl9pbmZv IG1paV9pZjsNCi0Jc3RydWN0IHBoeV9vcHMgKnBoeV9vcHM7DQorDQorCWludCBvbGRfbGluazsg ICAgICAgICAgLyogdXNlZCBieSBhdTEwMDBfYWRqdXN0X2xpbmsgKi8NCisJaW50IG9sZF9zcGVl ZDsgDQorCWludCBvbGRfZHVwbGV4Ow0KKw0KKwlpbnQgcGh5X2FkZHI7ICAgICAgICAgIC8qIHBo eSBhZGRyZXNzICovDQorCXN0cnVjdCBwaHlfZGV2aWNlICpwaHlfZGV2Ow0KKwlzdHJ1Y3QgbWlp X2J1cyBtaWlfYnVzOw0KIAkNCiAJLyogVGhlc2UgdmFyaWFibGVzIGFyZSBqdXN0IGZvciBxdWlj ayBhY2Nlc3MgdG8gY2VydGFpbiByZWdzIGFkZHJlc3Nlcy4gKi8NCiAJdm9sYXRpbGUgbWFjX3Jl Z190ICptYWM7ICAvKiBtYWMgcmVnaXN0ZXJzICAgICAgICAgICAgICAgICAgICAgICovICAgDQpA QCAtMjI3LDExICsxMjYsOSBAQCBzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgew0KIAl1OCAqaGFzaF90 YWJsZTsNCiAJdTMyIGhhc2hfbW9kZTsNCiAJdTMyIGludHJfd29ya19kb25lOyAvKiBudW1iZXIg b2YgUnggYW5kIFR4IHBrdHMgcHJvY2Vzc2VkIGluIHRoZSBpc3IgKi8NCi0JaW50IHBoeV9hZGRy OyAgICAgICAgICAvKiBwaHkgYWRkcmVzcyAqLw0KIAl1MzIgb3B0aW9uczsgICAgICAgICAgIC8q IFVzZXItc2V0dGFibGUgbWlzYy4gZHJpdmVyIG9wdGlvbnMuICovDQogCXUzMiBkcnZfZmxhZ3M7 DQotCWludCB3YW50X2F1dG9uZWc7DQorDQogCXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzIHN0YXRz Ow0KLQlzdHJ1Y3QgdGltZXJfbGlzdCB0aW1lcjsNCiAJc3BpbmxvY2tfdCBsb2NrOyAgICAgICAv KiBTZXJpYWxpc2UgYWNjZXNzIHRvIGRldmljZSAqLw0KIH07DQo= --=-ASCzkIEkSfwkp9HUWIX1-- --=-CRavCE66iNmA7KvOUpw4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEVlzOSYHgZIg/QUIRAqzpAJwIfhxT+T7rF1zkiABdBD6X+XaiigCdGHtO 5Y/pL2CDIX8ncxClDn23Qt8= =YWDr -----END PGP SIGNATURE----- --=-CRavCE66iNmA7KvOUpw4-- From ppopov@embeddedalley.com Mon May 1 20:15:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 20:16:09 +0100 (BST) Received: from smtp103.biz.mail.mud.yahoo.com ([68.142.200.238]:10428 "HELO smtp103.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S8133466AbWEATP7 (ORCPT ); Mon, 1 May 2006 20:15:59 +0100 Received: (qmail 1851 invoked from network); 1 May 2006 19:15:52 -0000 Received: from unknown (HELO ?192.168.1.103?) (ppopov@embeddedalley.com@71.128.175.242 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 1 May 2006 19:15:51 -0000 Subject: Re: RFC: au1000_etc.c phylib rewrite From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Herbert Valerio Riedel Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com In-Reply-To: <1146510542.16643.10.camel@localhost.localdomain> References: <1146510542.16643.10.camel@localhost.localdomain> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Mon, 01 May 2006 12:15:45 -0700 Message-Id: <1146510945.21947.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips On Mon, 2006-05-01 at 21:09 +0200, Herbert Valerio Riedel wrote: > hello *, > > I've started to rewrite the au1000_eth.c driver to make use of the new > PHY framework in 2.6.x; see the attached patch for the current work in > progress state; > > I'm a bit unsure what to do about those workarounds/hacks that are in > the original au1000_eth.c driver (e.g. for the broadcom dual PHY); Maybe you should dump that bcm dual phy support. I can't remember what board it was on and whether that board is even supported still. > any comments/ideas? shall I continue work on this au1xxx-eth > phylib-rewrite, or is it of no use? Seems like a good idea to me. Pete From robbat2@gentoo.org Mon May 1 21:05:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 21:05:55 +0100 (BST) Received: from pops.net-conex.com ([204.244.176.3]:23187 "EHLO mail.net-conex.com") by ftp.linux-mips.org with ESMTP id S8133558AbWEAUFq (ORCPT ); Mon, 1 May 2006 21:05:46 +0100 Received: from curie.orbis-terrarum.net (S01060050da688d47.vc.shawcable.net [24.80.100.253]) by mail.net-conex.com (8.13.4/8.12.11) with ESMTP id k41K5hBU016684 for ; Mon, 1 May 2006 13:05:43 -0700 Received: (qmail 31376 invoked by uid 10000); 1 May 2006 13:05:48 -0700 Date: Mon, 1 May 2006 13:05:48 -0700 From: "Robin H. Johnson" To: linux-mips@linux-mips.org Subject: Re: RFC: au1000_etc.c phylib rewrite Message-ID: <20060501200548.GA30331@curie-int.vc.shawcable.net> Mail-Followup-To: linux-mips@linux-mips.org References: <1146510542.16643.10.camel@localhost.localdomain> <1146510945.21947.44.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <1146510945.21947.44.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robbat2@gentoo.org Precedence: bulk X-list: linux-mips --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 01, 2006 at 12:15:45PM -0700, Pete Popov wrote: > Maybe you should dump that bcm dual phy support. I can't remember what > board it was on and whether that board is even supported still.=20 XXS1500 definetly uses it, and is still supported last time I checked. If not, just drop me a line, and I'll check up on it, as I have the unit, and made use of both network links. --=20 Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFEVmocPpIsIjIzwiwRAoKVAKDFzeegb/O4olOuS4tQpmGCDmDoCgCgko9+ T++78Ie5sXPRGxmB3GS5n94= =idor -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From mschank@dcbnet.com Mon May 1 21:08:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 21:08:38 +0100 (BST) Received: from firewall.dcbnet.com ([12.96.67.19]:28084 "EHLO firewall.dcbnet.com") by ftp.linux-mips.org with ESMTP id S8133558AbWEAUI3 (ORCPT ); Mon, 1 May 2006 21:08:29 +0100 Received: from mschank.dcbnet.com (mschank.dcbnet.com [205.166.54.128]) by firewall.dcbnet.com (8.12.10/8.12.10) with ESMTP id k41K8Ii7016340; Mon, 1 May 2006 15:08:20 -0500 Message-Id: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> X-Sender: mschank@205.166.54.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 May 2006 15:09:15 -0500 To: ppopov@embeddedalley.com, Herbert Valerio Riedel From: Mark Schank Subject: Re: RFC: au1000_etc.c phylib rewrite Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com In-Reply-To: <1146510945.21947.44.camel@localhost.localdomain> References: <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mschank@dcbnet.com Precedence: bulk X-list: linux-mips The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned the board and switched to two single Broadcom phys, but they continued to control both phys through MAC0, which is the actual purpose of the dual-phy hack. I am a user of the CSB655, so I sort of care. Will the new PHY framework allow a second PHY for a second MAC (MAC1) be controlled from the first MAC's (MAC0) mdio interface? Yes, I acknowledge this was a bad design, but its what I am stuck with. -Mark At 12:15 PM 5/1/06 -0700, Pete Popov wrote: >On Mon, 2006-05-01 at 21:09 +0200, Herbert Valerio Riedel wrote: > > hello *, > > > > I've started to rewrite the au1000_eth.c driver to make use of the new > > PHY framework in 2.6.x; see the attached patch for the current work in > > progress state; > > > > I'm a bit unsure what to do about those workarounds/hacks that are in > > the original au1000_eth.c driver (e.g. for the broadcom dual PHY); > >Maybe you should dump that bcm dual phy support. I can't remember what >board it was on and whether that board is even supported still. > > > any comments/ideas? shall I continue work on this au1xxx-eth > > phylib-rewrite, or is it of no use? > >Seems like a good idea to me. > >Pete From mcdonald@pmc-sierra.com Mon May 1 21:29:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 May 2006 21:29:20 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:44774 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133558AbWEAU3J (ORCPT ); Mon, 1 May 2006 21:29:09 +0100 Received: (qmail 27240 invoked by uid 101); 1 May 2006 20:28:58 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 1 May 2006 20:28:58 -0000 Received: from duval.pmc-sierra.bc.ca (duval.pmc-sierra.bc.ca [134.87.183.32]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k41KSvf5021911 for ; Mon, 1 May 2006 13:28:58 -0700 From: Shane McDonald Received: (from mcdonald@localhost) by duval.pmc-sierra.bc.ca (8.12.11/8.12.11) id k41KSvsS002784 for linux-mips@linux-mips.org; Mon, 1 May 2006 14:28:57 -0600 Date: Mon, 1 May 2006 14:28:57 -0600 Message-Id: <200605012028.k41KSvsS002784@duval.pmc-sierra.bc.ca> To: linux-mips@linux-mips.org Subject: [PATCH] improve readability of arch/mips/Kconfig Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mcdonald@pmc-sierra.com Precedence: bulk X-list: linux-mips From: Shane McDonald The wording of the help entries for CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, and CPU_MIPS64_R2 was confusing. The entries have been slightly reworded to improve the readability. Signed-off-by: Shane McDonald --- diff -uprN a/arch/mips/Kconfig b/arch/mips/Kconfig --- a/arch/mips/Kconfig 2006-05-01 13:41:40.000000000 -0600 +++ b/arch/mips/Kconfig 2006-05-01 13:54:26.000000000 -0600 @@ -1075,10 +1075,10 @@ config CPU_MIPS32_R1 Choose this option to build a kernel for release 1 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. - Release 2 of the MIPS32 architecture is available since several - years so chances are you even have a MIPS32 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + Release 2 of the MIPS32 architecture has been available for + several years so chances are you have a MIPS32 Release 2 processor in which case you should choose CPU_MIPS32_R2 instead for better performance. @@ -1093,8 +1093,8 @@ config CPU_MIPS32_R2 Choose this option to build a kernel for release 2 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. config CPU_MIPS64_R1 bool "MIPS64 Release 1" @@ -1108,10 +1108,10 @@ config CPU_MIPS64_R1 Choose this option to build a kernel for release 1 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. - Release 2 of the MIPS64 architecture is available since several - years so chances are you even have a MIPS64 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + Release 2 of the MIPS64 architecture has been available for + several years so chances are you have a MIPS64 Release 2 processor in which case you should choose CPU_MIPS64_R2 instead for better performance. @@ -1127,8 +1127,8 @@ config CPU_MIPS64_R2 Choose this option to build a kernel for release 2 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. config CPU_R3000 bool "R3000" From jimssubs@telus.net Tue May 2 00:13:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 00:13:32 +0100 (BST) Received: from test-iport-3.cisco.com ([171.71.176.78]:23094 "EHLO test-iport-3.cisco.com") by ftp.linux-mips.org with ESMTP id S8133612AbWEAXNX (ORCPT ); Tue, 2 May 2006 00:13:23 +0100 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 16:13:16 -0700 Received: from [0.0.0.0] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k41NDFh0020423 for ; Mon, 1 May 2006 16:13:16 -0700 (PDT) Message-ID: <4456960D.70403@telus.net> Date: Mon, 01 May 2006 16:13:17 -0700 From: Jim User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: how do i get register state from process before interrupt? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jimssubs@telus.net Precedence: bulk X-list: linux-mips I have a number of processes and drivers on a SB1250 card and I suspect one of the drivers is misbehaving such that user processes are not getting a chance to run. I implemented a rudimentary watchdog in the timer interrupt which is kicked by one such user process if things when things are fine. How would I capture the register state of the process that was running before the interrupt is run? I'm on linux 2.4.18. Thanks, Jim From weo@reccoware.de Tue May 2 06:46:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 06:46:25 +0100 (BST) Received: from bes.recconet.de ([212.227.59.164]:28648 "EHLO bes.recconet.de") by ftp.linux-mips.org with ESMTP id S8133358AbWEBFqM (ORCPT ); Tue, 2 May 2006 06:46:12 +0100 Received: from trinity.recco.de (trinity.intern.recconet.de [192.168.11.241]) by bes.recconet.de (8.13.1/8.13.1/Recconet-2005031001) with ESMTP id k425kBE2008179 for ; Tue, 2 May 2006 07:46:11 +0200 Received: from seneca.recco.de (seneca.recco.de [172.16.135.97]) by trinity.recco.de (8.13.1/8.13.1/Reccoware-2005061101) with ESMTP id k425jLl2010102 for ; Tue, 2 May 2006 07:45:21 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by seneca.recco.de (8.13.6/8.13.4/Seneca.Reccoware-2005061801) with ESMTP id k425kAqr023308 for ; Tue, 2 May 2006 07:46:10 +0200 Subject: Au1200 MMC/SD problem From: Wolfgang Ocker To: linux-mips@linux-mips.org Content-Type: text/plain Organization: Reccoware Systems Date: Tue, 02 May 2006 07:46:10 +0200 Message-Id: <1146548770.1597.43.camel@seneca.recco.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: weo@reccoware.de Precedence: bulk X-list: linux-mips Hello, I'm trying to get a SD card to work on an Db1200 board. I'm using kernel 2.6.16.11 (+ the patch from Jordan Crouse): http://www.linux-mips.org/archives/linux-mips/2005-12/msg00006.html The card gets recognized and issues its relative address. Then command 9 (send csd) times out. MMC: req done (37): 0: 00000120 00000000 00000000 00000000 MMC: starting cmd 29 arg 00018000 flags 00000061 MMC: req done (29): 0: 80ff8000 00000000 00000000 00000000 MMC: starting cmd0 2 arg 00000000 flags 00000067 MMC: req done (02): 0: 01504153 30313642 414a8be0 08004a00 MMC: starting cmd 03 arg 00000000 flags 00000065 MMC: req done (03): 0: e008004a 00000000 00000000 00000000 MMC: starting cmd 02 arg 00000000 flags 00000067 MMC: req done (02): 1: 00000000 00000000 00000000 00000000 MMC: req done (02): 1: 00000000 00000000 00000000 00000000 MMC: req done (02): 1: 00000000 00000000 00000000 00000000 MMC: req done (02): 1: 00000000 00000000 00000000 00000000 au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=15, mode=2) MMC: starting cmd 09 arg e0080000 flags 00000007 MMC: req done (09): 1: 00000000 00000000 00000000 00000000 MMC: req done (09): 1: 00000000 00000000 00000000 00000000 MMC: req done (09): 1: 00000000 00000000 00000000 00000000 MMC: req done (09): 1: 00000000 00000000 00000000 00000000 I'm new to MMC/SD and I have no idea whether this is a problem with the hardware, the software or the SD card (I tried two different SD cards. Both work on my laptop with Linux 2.6.16 and a Winbond W83L51xD). Any hints are highly appreciated. Thanks, Wolfgang From hvr@gnu.org Tue May 2 07:25:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 07:25:40 +0100 (BST) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:55767 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S8133386AbWEBGZ1 (ORCPT ); Tue, 2 May 2006 07:25:27 +0100 Received: from mini.intra (dhcp-1432-30.blizz.at [213.143.126.4]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k426PAFK004037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 May 2006 08:25:11 +0200 Subject: Re: RFC: au1000_etc.c phylib rewrite From: Herbert Valerio Riedel To: Mark Schank Cc: ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com In-Reply-To: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> References: <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> Content-Type: text/plain Organization: Free Software Foundation Date: Tue, 02 May 2006 08:23:47 +0200 Message-Id: <1146551027.19659.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.1/1434/Mon May 1 21:51:00 2006 on phobos.hvrlab.org X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote: > The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned > the board and switched to two single Broadcom phys, but they continued to > control both phys through MAC0, which is the actual purpose of the dual-phy > hack. I am a user of the CSB655, so I sort of care. > > Will the new PHY framework allow a second PHY for a second MAC (MAC1) be > controlled from the first MAC's (MAC0) mdio interface? should'nt be a problem (as opposed to the bosporus case... see below)... I assume the phy-addresses on which the boarcom dual phy is configured are the same for all Cogent CSB655 boards? does this need to be autodetected dynamically at runtime, or can we rely on a compile time Kconfig-conditional to set a static phy-addr<->eth% d-phy mapping for this board-specific case? Or de we really need such a complex mii_probe() function to detect weird scenarios? :) using static phy addr mappings would also allow for setting board-specific phy-irq assignments, which would then be handled by the phylib facilities, instead of polling the status of phy with a timer; (and in case we don't have any board-specific compile time setting, we can still fall back to search the phy-addresses for a PHY at runtime as the generic case) while at it, what about that CONFIG_MIPS_BOSPORUS special case? why doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the physical world? #ifdef CONFIG_MIPS_BOSPORUS /* This is a workaround for the Micrel/Kendin 5 port switch The second MAC doesn't see a PHY connected... so we need to trick it into thinking we have one. If this kernel is run on another Au1500 development board the stub will be found as well as the actual PHY. However, the last found PHY will be used... usually at Addr 31 (Db1500). */ > Yes, I acknowledge this was a bad design, but its what I am stuck with. :-) -- Herbert Valerio Riedel From gowri@bitel.co.kr Tue May 2 08:17:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 08:17:33 +0100 (BST) Received: from www.haninternet.co.kr ([211.63.64.4]:22286 "EHLO www.haninternet.co.kr") by ftp.linux-mips.org with ESMTP id S8133374AbWEBHRX (ORCPT ); Tue, 2 May 2006 08:17:23 +0100 Received: from [211.63.70.179] ([211.63.70.179]) by www.haninternet.co.kr (8.9.3/8.9.3) with ESMTP id QAA27218; Tue, 2 May 2006 16:12:41 +0900 Subject: RE: Java virtual machine on linux MIPS From: Gowri Satish Adimulam Reply-To: gowri@bitel.co.kr To: Prashant Viswanathan Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Organization: Bitel Co Ltd Date: Tue, 02 May 2006 16:17:09 +0900 Message-Id: <1146554229.20277.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gowri@bitel.co.kr Precedence: bulk X-list: linux-mips Thanks every body for thier kind suggestions . I will chck all the options provide in this group. Regards Gowri On Fri, 2006-04-28 at 10:02 -0700, Prashant Viswanathan wrote: > IBM's J9 works on linux-mips. > > > -----Original Message----- > > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux- > > mips.org] On Behalf Of Gowri Satish Adimulam > > Sent: Thursday, April 27, 2006 6:39 PM > > To: linux-mips@linux-mips.org > > Subject: Java virtual machine on linux MIPS > > > > Hi , > > > > He is there any java virtual machine runs on mips based linux . > > > > any pointers will be helpful > > > > Regards > > Gowri > > From francis_moreau2000@yahoo.fr Tue May 2 08:20:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 08:20:12 +0100 (BST) Received: from web25811.mail.ukl.yahoo.com ([217.146.176.244]:65442 "HELO web25811.mail.ukl.yahoo.com") by ftp.linux-mips.org with SMTP id S8133408AbWEBHUB (ORCPT ); Tue, 2 May 2006 08:20:01 +0100 Received: (qmail 44640 invoked by uid 60001); 2 May 2006 07:19:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2iKUVKnnio8la8F9feZsOI6xYjSXzocgnEdyRayzG38LAjtd+qRCMK9RUJj5qWQS98/WuVNiBFOlWe9VTjFGNtfDQf3wxhEe+OitrDc28eTkRLDxsJZOTE4DNyaeeqYgEWatCg+ttUZuHFurknuasrqrvsxA8nQI9S2e9Q10ze4= ; Message-ID: <20060502071949.44638.qmail@web25811.mail.ukl.yahoo.com> Date: Tue, 2 May 2006 07:19:49 +0000 (GMT) From: moreau francis Reply-To: moreau francis Subject: Re : module allocation To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20060428200307.GA17705@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: francis_moreau2000@yahoo.fr Precedence: bulk X-list: linux-mips > There is another reason against putting modules into mapped space and > that's the need for -mlong-calls which generates larger, less efficient > code. BTW, I don't see why -mlong-calls wouldn't be needed for GFP module allocation. Can you explain ? Thanks From vagabon.xyz@gmail.com Tue May 2 08:55:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 08:56:02 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.193]:28357 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133437AbWEBHzw convert rfc822-to-8bit (ORCPT ); Tue, 2 May 2006 08:55:52 +0100 Received: by nz-out-0102.google.com with SMTP id j2so2519212nzf for ; Tue, 02 May 2006 00:55:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BtVgaiK/MYWnSpKzYxQ0pxiAcdHM/AtxEriOkJ7RTW1BKbr459zrwcPOB5/bz8M7+bw3E2AJKOsqkoQb/Li7ixsnMenkU8E/CF9yFpOoQh6C5WqI3djO8TqahotmjIctVa/uIuc9wEF94hkXxbA/8J4IxbRMqM1RENY2kPgcIA4= Received: by 10.36.129.3 with SMTP id b3mr706761nzd; Tue, 02 May 2006 00:55:51 -0700 (PDT) Received: by 10.36.49.2 with HTTP; Tue, 2 May 2006 00:55:51 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 09:55:51 +0200 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: [PATCH] Make interrupt handler works for all cases Cc: linux-mips MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips specially when the kernel is mapped. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/genex.S | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) 72821cd1fc2a6e31e31c2babf338425b29e8f11f diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index ff7af36..50cb0c2 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -132,7 +132,8 @@ NESTED(handle_int, PT_SIZE, sp) PTR_LA ra, ret_from_irq move a0, sp - j plat_irq_dispatch + PTR_LA k0, plat_irq_dispatch + jr k0 END(handle_int) __INIT -- 1.3.0.g2473 From ralf@linux-mips.org Tue May 2 10:36:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 10:36:38 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:23970 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133408AbWEBJga (ORCPT ); Tue, 2 May 2006 10:36:30 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k429aNgt004399; Tue, 2 May 2006 10:36:23 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k429aLwq004398; Tue, 2 May 2006 10:36:21 +0100 Date: Tue, 2 May 2006 10:36:21 +0100 From: Ralf Baechle To: moreau francis Cc: linux-mips@linux-mips.org Subject: Re: Re : module allocation Message-ID: <20060502093621.GA4301@linux-mips.org> References: <20060428200307.GA17705@linux-mips.org> <20060502071949.44638.qmail@web25811.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060502071949.44638.qmail@web25811.mail.ukl.yahoo.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, May 02, 2006 at 07:19:49AM +0000, moreau francis wrote: > > There is another reason against putting modules into mapped space and > > that's the need for -mlong-calls which generates larger, less efficient > > code. > > BTW, I don't see why -mlong-calls wouldn't be needed for GFP module > allocation. Can you explain ? It assumes a low-memory system where the entire RAM resides within the range of a J/JAL instructions. Ralf From ralf@linux-mips.org Tue May 2 10:41:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 10:41:33 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:58793 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133463AbWEBJlZ (ORCPT ); Tue, 2 May 2006 10:41:25 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k429fOcw004601; Tue, 2 May 2006 10:41:24 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k429fNW3004600; Tue, 2 May 2006 10:41:23 +0100 Date: Tue, 2 May 2006 10:41:23 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: [PATCH] Make interrupt handler works for all cases Message-ID: <20060502094123.GB4301@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > specially when the kernel is mapped. At which time you're on very fragile ice because TLB instructions should better be executed from an unmapped address ... Ralf From vagabon.xyz@gmail.com Tue May 2 11:30:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 11:30:36 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.202]:3668 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133496AbWEBKaY convert rfc822-to-8bit (ORCPT ); Tue, 2 May 2006 11:30:24 +0100 Received: by nz-out-0102.google.com with SMTP id j2so2539748nzf for ; Tue, 02 May 2006 03:30:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tyl9i1VIHbr0/+xkDr3x/RESUcbwJhLRwkCPOGXkZtwyUIUTAE4FxZ+6pRPELmBfq+LMa0HoTbVJ0tuIx60qh8bdQdRLstScgTw/YfJCUCKaBmm9XwZxxZp1bc1uyM47BjB7cvdmIKJnNuKWRWihACOV0s212waeLHLAQvq7BQk= Received: by 10.36.129.3 with SMTP id b3mr908874nzd; Tue, 02 May 2006 03:30:22 -0700 (PDT) Received: by 10.36.49.2 with HTTP; Tue, 2 May 2006 03:30:22 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 12:30:22 +0200 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH] Make interrupt handler works for all cases Cc: linux-mips In-Reply-To: <20060502094123.GB4301@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20060502094123.GB4301@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2006/5/2, Ralf Baechle : > On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > > > specially when the kernel is mapped. > > At which time you're on very fragile ice because TLB instructions should > better be executed from an unmapped address ... > well TLB entry used by the kernel is wired, so it should work fined, shouldn't it ? Thanks -- Franck From ths@networkno.de Tue May 2 11:45:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 11:45:39 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:8871 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133705AbWEBKp1 (ORCPT ); Tue, 2 May 2006 11:45:27 +0100 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id A3E3C44348; Tue, 2 May 2006 12:45:26 +0200 (MEST) Received: from ths by lagash with local (Exim 4.61) (envelope-from ) id 1FasMz-0002vC-PN; Tue, 02 May 2006 11:44:41 +0100 Date: Tue, 2 May 2006 11:44:41 +0100 To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH] Make interrupt handler works for all cases Message-ID: <20060502104441.GA5004@networkno.de> References: <20060502094123.GB4301@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > 2006/5/2, Ralf Baechle : > >On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > > > >> specially when the kernel is mapped. > > > >At which time you're on very fragile ice because TLB instructions should > >better be executed from an unmapped address ... > > > > well TLB entry used by the kernel is wired, so it should work fined, > shouldn't it ? The architecture spec doesn't guarantee it will. Thiemo From goldfinger@member.fsf.org Tue May 2 12:06:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 12:06:21 +0100 (BST) Received: from host54-127.pool873.interbusiness.it ([87.3.127.54]:574 "HELO localhost.localdomain") by ftp.linux-mips.org with SMTP id S8133496AbWEBLGG (ORCPT ); Tue, 2 May 2006 12:06:06 +0100 Received: by localhost.localdomain (Postfix, from userid 501) id D2665110DFE; Tue, 2 May 2006 13:05:56 +0200 (CEST) Subject: ip27 not working From: Michele Carla` To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 02 May 2006 13:05:55 +0200 Message-Id: <1146567955.3112.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: goldfinger@member.fsf.org Precedence: bulk X-list: linux-mips Yesterday I have tried last 2.6 from git on a Origin-2000, I have xcompiled it with gcc-3.4, and booted it via tftpd with: "bootp(): console=ttyS0 root=/dev/sda1", but after downloading the kernel, it doesn't print anything and freeze ! any idea ? if needed I can provide an account on the Origin -- Pluralitas non est ponenda sine neccesitate Frustra fit per plura quod potest fieri per pauciora Entia non sunt multiplicanda praeter necessitatem Occam's Razor MiChele Carla` aKa Goldfinger From giometti@enneenne.com Tue May 2 13:23:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 13:23:24 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:5351 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133496AbWEBMXP (ORCPT ); Tue, 2 May 2006 13:23:15 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FatuE-0005vj-00; Tue, 02 May 2006 14:23:06 +0200 Date: Tue, 2 May 2006 14:23:06 +0200 From: Rodolfo Giometti To: Michele Carla` Cc: linux-mips@linux-mips.org Subject: Re: ip27 not working Message-ID: <20060502122306.GC20543@gundam.enneenne.com> References: <1146567955.3112.5.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aT9PWwzfKXlsBJM1" Content-Disposition: inline In-Reply-To: <1146567955.3112.5.camel@localhost> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 02, 2006 at 01:05:55PM +0200, Michele Carla` wrote: > Yesterday I have tried last 2.6 from git on a Origin-2000, I have > xcompiled it with gcc-3.4, and booted it via tftpd with: > "bootp(): console=3DttyS0 root=3D/dev/sda1", but after downloading the > kernel, it doesn't print anything and freeze ! any idea ? Maybe you have my same (old) problem. Please, consider to take a look at thread =ABtrouble on serial console for au1100=BB. Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --aT9PWwzfKXlsBJM1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEV08qQaTCYNJaVjMRAjILAJ9m5aQRWjeqc40i3AK6516FjugzLQCbB/6o /4rVj3xh12amYnX9A4hUDuI= =g8/q -----END PGP SIGNATURE----- --aT9PWwzfKXlsBJM1-- From giometti@enneenne.com Tue May 2 13:23:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 13:24:10 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:5863 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133706AbWEBMXk (ORCPT ); Tue, 2 May 2006 13:23:40 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1Fatsx-0005vQ-00; Tue, 02 May 2006 14:21:47 +0200 Date: Tue, 2 May 2006 14:21:47 +0200 From: Rodolfo Giometti To: Jordan Crouse Cc: Freddy Spierenburg , linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: trouble on serial console for au1100 Message-ID: <20060502122147.GB20543@gundam.enneenne.com> References: <20060427154948.GI32278@enneenne.com> <20060428111933.GY11097@dusktilldawn.nl> <20060428171923.GG3314@cosmic.amd.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <20060428171923.GG3314@cosmic.amd.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 28, 2006 at 11:19:23AM -0600, Jordan Crouse wrote: >=20 > CCing the serial list too. It could use more testing, but this seems > like it might be the answer to the myriad of serial issues that have=20 > been reported in the last month or so.=20 >=20 > I'm ashamed to admit I have no idea if this patch is even in the system or > not. If not, I'm sure somebody > can clean it up and send it in the proper style. Here: http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-seria= l-fix the patch against =ABlinux-2.6.16-stable=BB branch for serial support tested with an au1100 based board. Here: http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-seria= l-real-interrupt my suggestion to get real interrupts from the serial line (I have redefined the function =ABis_real_interrupt()=BB for the au1x00 CPUs into the platform =ABserial.h=BB file). Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEV07bQaTCYNJaVjMRAo7nAKCycQAd19UVDR7mQvyXlrZ26QrJPQCcCjNp ZVB8gE1hN5SzzEpV9nxZre0= =GIkD -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From giometti@enneenne.com Tue May 2 13:27:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 13:27:59 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:51650 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133706AbWEBM1u (ORCPT ); Tue, 2 May 2006 13:27:50 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1Fatyn-00065U-00 for ; Tue, 02 May 2006 14:27:49 +0200 Date: Tue, 2 May 2006 14:27:49 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: [PATCH] uImage support for u-boot Message-ID: <20060502122749.GD20543@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Here: http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-uImage-support a patch against «linux-2.6.16-stable» branch to add support for "u-boot" image generation. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From jcrouse@cosmic.amd.com Tue May 2 15:29:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 15:29:17 +0100 (BST) Received: from amdext4.amd.com ([163.181.251.6]:1973 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133712AbWEBO3G (ORCPT ); Tue, 2 May 2006 15:29:06 +0100 Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k42ER2nU001594; Tue, 2 May 2006 09:29:28 -0500 Received: from 163.181.22.101 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 02 May 2006 09:28:47 -0500 X-Server-Uuid: 8C3DB987-180B-4465-9446-45C15473FD3E Received: from ldcmail.amd.com ([147.5.200.40]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 2 May 2006 09:28:47 -0500 Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id C59F42028; Tue, 2 May 2006 08:28:46 -0600 (MDT) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k42EhE2r019166; Tue, 2 May 2006 08:43:14 -0600 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k42EhET4019165; Tue, 2 May 2006 08:43:14 -0600 Date: Tue, 2 May 2006 08:43:14 -0600 From: "Jordan Crouse" To: "Wolfgang Ocker" cc: linux-mips@linux-mips.org Subject: Re: Au1200 MMC/SD problem Message-ID: <20060502144314.GI22167@cosmic.amd.com> References: <1146548770.1597.43.camel@seneca.recco.de> MIME-Version: 1.0 In-Reply-To: <1146548770.1597.43.camel@seneca.recco.de> User-Agent: Mutt/1.5.11 X-OriginalArrivalTime: 02 May 2006 14:28:47.0484 (UTC) FILETIME=[B94BD3C0:01C66DF4] X-WSS-ID: 6849B3154IS4797242-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips On 02/05/06 07:46 +0200, Wolfgang Ocker wrote: > Hello, > > I'm trying to get a SD card to work on an Db1200 board. I'm using kernel > 2.6.16.11 (+ the patch from Jordan Crouse): Thats not an encouraging sign. > au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=15, mode=2) > MMC: starting cmd 09 arg e0080000 flags 00000007 > MMC: req done (09): 1: 00000000 00000000 00000000 00000000 > MMC: req done (09): 1: 00000000 00000000 00000000 00000000 > MMC: req done (09): 1: 00000000 00000000 00000000 00000000 > MMC: req done (09): 1: 00000000 00000000 00000000 00000000 Ok - so the reasons for cmd->error to be MMC_ERR_TIMEOUT are: * invalid return from dma_map_sg in au1xmmc_prepare_data * general error from the DBDMA engine * one of SD_STATUS_RAT sent when the IRQ fires So to narrow it down - check the return value of au1xmmc_prepare_data in au1xmmc_request. Then, see if RAT is ever set in au1xmmc_irq. This will help narrow down the problem. Also, the usual general questions: What SD card are you using? How big is it? Is it a v1.01 or a v1.1 card? Jordan From ilya@total-knowledge.com Tue May 2 16:05:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 16:05:52 +0100 (BST) Received: from alpha.total-knowledge.com ([205.217.158.170]:25990 "EHLO total-knowledge.com") by ftp.linux-mips.org with ESMTP id S8133712AbWEBPFm (ORCPT ); Tue, 2 May 2006 16:05:42 +0100 Received: (qmail 485 invoked from network); 2 May 2006 08:05:40 -0700 Received: from unknown (HELO ?10.50.163.242?) (ilya@209.157.142.204) by alpha.total-knowledge.com with ESMTPA; 2 May 2006 08:05:40 -0700 Message-ID: <4457753E.3020001@total-knowledge.com> Date: Tue, 02 May 2006 08:05:34 -0700 From: "Ilya A. Volynets-Evenbakh" Organization: Total Knowledge User-Agent: Mail/News 1.5 (X11/20060420) MIME-Version: 1.0 To: Michele Carla` CC: linux-mips@linux-mips.org Subject: Re: ip27 not working References: <1146567955.3112.5.camel@localhost> In-Reply-To: <1146567955.3112.5.camel@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@total-knowledge.com Precedence: bulk X-list: linux-mips Plain git will not work. Check out Gentoo patch set for kernel - there are few IP27-specific patches that are absolutely required. http://gentoo.osuosl.org/distfiles/mips-sources-generic_patches-1.21.tar.bz2 Although I have to say that latest git even with relevant patches applied gets me to starting init, but not further. Michele Carla` wrote: > Yesterday I have tried last 2.6 from git on a Origin-2000, I have > xcompiled it with gcc-3.4, and booted it via tftpd with: > "bootp(): console=ttyS0 root=/dev/sda1", but after downloading the > kernel, it doesn't print anything and freeze ! any idea ? > > if needed I can provide an account on the Origin > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com From giometti@enneenne.com Tue May 2 16:10:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 16:10:39 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:45255 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133712AbWEBPKa (ORCPT ); Tue, 2 May 2006 16:10:30 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FawV0-0002EA-00; Tue, 02 May 2006 17:09:14 +0200 Date: Tue, 2 May 2006 17:09:14 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: jgarzik@pobox.com, netdev@vger.kernel.org, Linux-MIPS Subject: Re: [PATCH] au1000_eth.c Power Management, driver registration and module support Message-ID: <20060502150914.GE20543@gundam.enneenne.com> References: <20060405154711.GL7029@enneenne.com> <20060405222332.GO7029@enneenne.com> <20060405222620.GP7029@enneenne.com> <4435290C.50607@ru.mvista.com> <20060406155011.GC23424@enneenne.com> <4446857D.90507@ru.mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: <4446857D.90507@ru.mvista.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, here: http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1000_eth-p= m-and-registration the new version of my patch for au1000_eth.c who should implement: * Module support. - bool "MIPS AU1000 Ethernet support" + tristate "MIPS AU1000 Ethernet support" * Driver registration. +static int __init au1000_eth_init(void) +{ + return driver_register(&au1000_driver); +} + +static void __exit au1000_eth_cleanup(void) +{ + driver_unregister(&au1000_driver); +} =20 * Power Management. +#ifdef CONFIG_PM + .suspend =3D au1000_drv_suspend, + .resume =3D au1000_drv_resume, +#endif Also, as suggested by Sergei it: * uses physical addresses and not KSEG1-based virtual anymore and claims/releases the 4-byte MAC enable registers: wwpc:~# cat /proc/iomem 10500000-1050ffff : eth-base 10520000-10520003 : eth-mac =20 * assigns to the Ethernet ports two consecutive MAC addresses: - dev->dev_addr[4] +=3D 0x10; + ((unsigned long) macen_addr); + memcpy(ndev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr)); + ndev->dev_addr[5] +=3D 0x01; =20 Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEV3YaQaTCYNJaVjMRAkmvAKC1t5hzmLeO1EmmfVz1+l8sX6dQeACdHu+c Vr4ge1cRv4H88pgyp+ncci4= =cO/5 -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl-- From ralf@linux-mips.org Tue May 2 17:10:00 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 17:10:08 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:2771 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133720AbWEBQKA (ORCPT ); Tue, 2 May 2006 17:10:00 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k42G9x6C016049; Tue, 2 May 2006 17:09:59 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k42G9w5u016048; Tue, 2 May 2006 17:09:58 +0100 Date: Tue, 2 May 2006 17:09:58 +0100 From: Ralf Baechle To: "Randy.Dunlap" Cc: linux-mips@linux-mips.org Subject: Re: SETNAME (set nodename) in syscall.c Message-ID: <20060502160958.GB15052@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Apr 29, 2006 at 09:01:59PM -0700, Randy.Dunlap wrote: > In arch/mips/syscall.c::_sys_sysmips(), case SETNAME, > isn't one of the strncpy() and strlcpy() unneeded? > > down_write(&uts_sem); > strncpy(system_utsname.nodename, nodename, len); > nodename[__NEW_UTS_LEN] = '\0'; > strlcpy(system_utsname.nodename, nodename, > sizeof(system_utsname.nodename)); > up_write(&uts_sem); Seems that came with the 2.5.70 merge and got copied and moved around a few times since. I'm pretty sure the whole sysmips(SETNAME, ...) operation is unused. Any objections again removal of sysmips(SETNAME, ...) support? Ralf From mschank@dcbnet.com Tue May 2 17:19:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 17:20:18 +0100 (BST) Received: from firewall.dcbnet.com ([12.96.67.19]:26313 "EHLO firewall.dcbnet.com") by ftp.linux-mips.org with ESMTP id S8133720AbWEBQT7 (ORCPT ); Tue, 2 May 2006 17:19:59 +0100 Received: from mschank.dcbnet.com (mschank.dcbnet.com [205.166.54.128]) by firewall.dcbnet.com (8.12.10/8.12.10) with ESMTP id k42GJji7011286; Tue, 2 May 2006 11:19:50 -0500 Message-Id: <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> X-Sender: mschank@205.166.54.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 May 2006 11:20:43 -0500 To: Herbert Valerio Riedel From: Mark Schank Subject: Re: RFC: au1000_etc.c phylib rewrite Cc: ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com In-Reply-To: <1146551027.19659.12.camel@localhost.localdomain> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mschank@dcbnet.com Precedence: bulk X-list: linux-mips At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote: >On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote: > > The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned > > the board and switched to two single Broadcom phys, but they continued to > > control both phys through MAC0, which is the actual purpose of the > dual-phy > > hack. I am a user of the CSB655, so I sort of care. > > > > Will the new PHY framework allow a second PHY for a second MAC (MAC1) be > > controlled from the first MAC's (MAC0) mdio interface? > >should'nt be a problem (as opposed to the bosporus case... see below)... >I assume the phy-addresses on which the boarcom dual phy is configured >are the same for all Cogent CSB655 boards? Dual PHY configuration: MAC0 - phy addr 4 MAC1 - phy addr 3 Single PHY configuration: MAC0 - phy addr 1 MAC1 - phy addr 0 >does this need to be autodetected dynamically at runtime, or can we rely >on a compile time Kconfig-conditional to set a static phy-addr<->eth% >d-phy mapping for this board-specific case? Or de we really need such a >complex mii_probe() function to detect weird scenarios? :) The compile time Kconfig-conditional should be okay. The driver need to handle the fact that the MAC1's phy is controlled by MAC0's mdio interface. This means that MAC0 controller can not be disabled when the associated eth% device is down, otherwise you lose the ability to control MAC1's phy. >using static phy addr mappings would also allow for setting >board-specific phy-irq assignments, which would then be handled by the >phylib facilities, instead of polling the status of phy with a timer; >(and in case we don't have any board-specific compile time setting, we >can still fall back to search the phy-addresses for a PHY at runtime as >the generic case) Will the phylib facilities handle the case where two phys share a single IRQ? >while at it, what about that CONFIG_MIPS_BOSPORUS special case? why >doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the >physical world? I don't have first hand knowledge of this board, but I have worked with Kendin switches before. They have a special port that allows direct connection of a MAC into the switch port without the use of a phy. The MAC's MII is directly connected to the switch ports MII. So instead of this: MAC <-> PHY <->PHY <-> Switch_Port You have this: MAC <-> Switch_Port So the MAC talks to the physical world via the switch. >#ifdef CONFIG_MIPS_BOSPORUS > /* This is a workaround for the Micrel/Kendin 5 port switch > The second MAC doesn't see a PHY connected... so we need to > trick it into thinking we have one. > > If this kernel is run on another Au1500 development board > the stub will be found as well as the actual PHY. However, > the last found PHY will be used... usually at Addr 31 (Db1500). > */ > > > > Yes, I acknowledge this was a bad design, but its what I am stuck with. > >:-) >-- >Herbert Valerio Riedel From goldfinger@member.fsf.org Tue May 2 17:29:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 17:29:24 +0100 (BST) Received: from host54-127.pool873.interbusiness.it ([87.3.127.54]:32116 "HELO localhost.localdomain") by ftp.linux-mips.org with SMTP id S8133720AbWEBQ3O (ORCPT ); Tue, 2 May 2006 17:29:14 +0100 Received: by localhost.localdomain (Postfix, from userid 501) id 14FBB110DFE; Tue, 2 May 2006 18:29:05 +0200 (CEST) Subject: Re: ip27 not working From: Michele Carla` To: linux-mips@linux-mips.org In-Reply-To: <4457753E.3020001@total-knowledge.com> References: <1146567955.3112.5.camel@localhost> <4457753E.3020001@total-knowledge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 02 May 2006 18:29:04 +0200 Message-Id: <1146587344.3170.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: goldfinger@member.fsf.org Precedence: bulk X-list: linux-mips On Tue, 2006-05-02 at 08:05 -0700, Ilya A. Volynets-Evenbakh wrote: > Plain git will not work. Check out Gentoo patch set > for kernel - there are few IP27-specific patches that > are absolutely required. > http://gentoo.osuosl.org/distfiles/mips-sources-generic_patches-1.21.tar.bz2 > > Although I have to say that latest git even with relevant patches > applied gets me to starting init, but not further. Really tanks ! Have you got networking (integrated or menet) working whit this kernel ? Are you using an Origin-200 or 2k Tanks again ! > > Michele Carla` wrote: > > Yesterday I have tried last 2.6 from git on a Origin-2000, I have > > xcompiled it with gcc-3.4, and booted it via tftpd with: > > "bootp(): console=ttyS0 root=/dev/sda1", but after downloading the > > kernel, it doesn't print anything and freeze ! any idea ? > > > > if needed I can provide an account on the Origin > > > > > -- Pluralitas non est ponenda sine neccesitate Frustra fit per plura quod potest fieri per pauciora Entia non sunt multiplicanda praeter necessitatem Occam's Razor MiChele Carla` aKa Goldfinger From vagabon.xyz@gmail.com Tue May 2 18:43:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 18:43:39 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.207]:17564 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133932AbWEBRn1 convert rfc822-to-8bit (ORCPT ); Tue, 2 May 2006 18:43:27 +0100 Received: by nz-out-0102.google.com with SMTP id j2so2631959nzf for ; Tue, 02 May 2006 10:43:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DRAiCSaxS8LV+XANCIV8Isq+cvmG5wQG/ZpMsZKZnOEJ8SW00tUpSkSzdRZOgHTJjJSQDu1Kq+uxPyLQ5JpTZOI/78ewmGCfSnwXKm12h947Bpx5ndwCVCMDEB3+3EqptSPr+wTu7oNVgAAg0blhGqCB3hAiVAXysyiTzgVhpFA= Received: by 10.36.129.3 with SMTP id b3mr1538616nzd; Tue, 02 May 2006 10:43:26 -0700 (PDT) Received: by 10.36.49.2 with HTTP; Tue, 2 May 2006 10:43:26 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 19:43:26 +0200 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH] Make interrupt handler works for all cases Cc: linux-mips In-Reply-To: <20060502094123.GB4301@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20060502094123.GB4301@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2006/5/2, Ralf Baechle : > On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > > > specially when the kernel is mapped. > > At which time you're on very fragile ice because TLB instructions should > better be executed from an unmapped address ... > So does it mean that MIPS arch can't provide reliable support for running mapped kernel ? -- Franck From vagabon.xyz@gmail.com Tue May 2 18:48:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 18:48:56 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.192]:51781 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133753AbWEBRsm convert rfc822-to-8bit (ORCPT ); Tue, 2 May 2006 18:48:42 +0100 Received: by nz-out-0102.google.com with SMTP id j2so2633104nzf for ; Tue, 02 May 2006 10:48:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oTjLmKCpqcD6oGOvHoem4f48R6jemjA/EVSeVO4qDzUqbNU6clrcMK+i9O/jWsIXqJ4IqJMysgLJ9AvC7vwRY/T1jYK5Bcd/lNJ4cRgssPH3fqKh1Iy9NgycYJ1FGjkw1YxUKwzlEPYDkDnFztjM6oV6S4cXdo1CJ4EXbmX7kw8= Received: by 10.36.118.9 with SMTP id q9mr1718173nzc; Tue, 02 May 2006 10:48:38 -0700 (PDT) Received: by 10.36.49.2 with HTTP; Tue, 2 May 2006 10:48:38 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 19:48:38 +0200 From: "Franck Bui-Huu" To: "Thiemo Seufer" Subject: Re: [PATCH] Make interrupt handler works for all cases Cc: "Ralf Baechle" , linux-mips In-Reply-To: <20060502104441.GA5004@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20060502094123.GB4301@linux-mips.org> <20060502104441.GA5004@networkno.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2006/5/2, Thiemo Seufer : > Franck Bui-Huu wrote: > > 2006/5/2, Ralf Baechle : > > >On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > > > > > >> specially when the kernel is mapped. > > > > > >At which time you're on very fragile ice because TLB instructions should > > >better be executed from an unmapped address ... > > > > > > > well TLB entry used by the kernel is wired, so it should work fined, > > shouldn't it ? > > The architecture spec doesn't guarantee it will. > having a quick look at the TLB handling code, it seems that the code assumes it will... -- Franck From weo@reccoware.de Tue May 2 19:02:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 19:02:31 +0100 (BST) Received: from bes.recconet.de ([212.227.59.164]:36588 "EHLO bes.recconet.de") by ftp.linux-mips.org with ESMTP id S8133932AbWEBSCV (ORCPT ); Tue, 2 May 2006 19:02:21 +0100 Received: from trinity.recco.de (trinity.intern.recconet.de [192.168.11.241]) by bes.recconet.de (8.13.1/8.13.1/Recconet-2005031001) with ESMTP id k42I2CmC017086; Tue, 2 May 2006 20:02:12 +0200 Received: from seneca.recco.de (seneca.recco.de [172.16.135.97]) by trinity.recco.de (8.13.1/8.13.1/Reccoware-2005061101) with ESMTP id k42I1L9K002924; Tue, 2 May 2006 20:01:21 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by seneca.recco.de (8.13.6/8.13.4/Seneca.Reccoware-2005061801) with ESMTP id k42I26uR015708; Tue, 2 May 2006 20:02:11 +0200 Subject: Re: Au1200 MMC/SD problem From: Wolfgang Ocker To: Jordan Crouse Cc: linux-mips@linux-mips.org In-Reply-To: <20060502144314.GI22167@cosmic.amd.com> References: <1146548770.1597.43.camel@seneca.recco.de> <20060502144314.GI22167@cosmic.amd.com> Content-Type: text/plain Organization: Reccoware Systems Date: Tue, 02 May 2006 20:02:06 +0200 Message-Id: <1146592926.11188.12.camel@seneca.recco.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: weo@reccoware.de Precedence: bulk X-list: linux-mips On Tue, 2006-05-02 at 08:43 -0600, Jordan Crouse wrote: > On 02/05/06 07:46 +0200, Wolfgang Ocker wrote: > > [ timeout during cmd 9 ] > Ok - so the reasons for cmd->error to be MMC_ERR_TIMEOUT are: > * invalid return from dma_map_sg in au1xmmc_prepare_data > * general error from the DBDMA engine > * one of SD_STATUS_RAT sent when the IRQ fires The last one. In au1xmmc_irq() the status register is read with the SD_STATUS_RAT bit set. > So to narrow it down - check the return value of au1xmmc_prepare_data > in au1xmmc_request. Then, see if RAT is ever set in au1xmmc_irq. This > will help narrow down the problem. au1xmmc_prepare_data doesn't return any error. > Also, the usual general questions: > What SD card are you using? How big is it? Is it a v1.01 or a v1.1 card? 1. Canon, 16 MB, got this one with a Canon camera. 2. Labeled by Hama, 1 GB, but I don't know the real manufacturer. I can operate the cards on my Linux-Laptop. Is there a way to determine the manufacturer and version directly from the card? Thanks, Wolfgang From ths@networkno.de Tue May 2 19:05:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 19:05:33 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:25755 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133938AbWEBSFW (ORCPT ); Tue, 2 May 2006 19:05:22 +0100 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id EBFBE44BCB; Tue, 2 May 2006 20:05:21 +0200 (MEST) Received: from ths by lagash with local (Exim 4.61) (envelope-from ) id 1FazEi-0001zm-7g; Tue, 02 May 2006 19:04:36 +0100 Date: Tue, 2 May 2006 19:04:36 +0100 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH] Make interrupt handler works for all cases Message-ID: <20060502180436.GH5004@networkno.de> References: <20060502094123.GB4301@linux-mips.org> <20060502104441.GA5004@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > 2006/5/2, Thiemo Seufer : > >Franck Bui-Huu wrote: > >> 2006/5/2, Ralf Baechle : > >> >On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > >> > > >> >> specially when the kernel is mapped. > >> > > >> >At which time you're on very fragile ice because TLB instructions should > >> >better be executed from an unmapped address ... > >> > > >> > >> well TLB entry used by the kernel is wired, so it should work fined, > >> shouldn't it ? > > > >The architecture spec doesn't guarantee it will. > > having a quick look at the TLB handling code, it seems that the code > assumes it will... I don't know which code you are looking at, but the kernel's TLB handling doesn't run in mapped space. (The ip27 is an exception, I assume the R1x000 allows for mapped TLB handling.) Thiemo From ralf@linux-mips.org Tue May 2 20:38:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 20:38:48 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:35238 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133942AbWEBTij (ORCPT ); Tue, 2 May 2006 20:38:39 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k42JcdqK003602; Tue, 2 May 2006 20:38:39 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k42Jcci7003601; Tue, 2 May 2006 20:38:38 +0100 Date: Tue, 2 May 2006 20:38:38 +0100 From: Ralf Baechle To: Jim Cc: linux-mips@linux-mips.org Subject: Re: how do i get register state from process before interrupt? Message-ID: <20060502193838.GA3474@linux-mips.org> References: <4456960D.70403@telus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4456960D.70403@telus.net> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 01, 2006 at 04:13:17PM -0700, Jim wrote: > I have a number of processes and drivers on a SB1250 card > and I suspect one of the drivers is misbehaving such that > user processes are not getting a chance to run. I implemented > a rudimentary watchdog in the timer interrupt which is kicked > by one such user process if things when things are fine. > How would I capture the register state of the process > that was running before the interrupt is run? I'm on > linux 2.4.18. You can find a struct pt_regs at (unsigned long)task_stack_page(p) + THREAD_SIZE - 32 Ralf From ralf@linux-mips.org Tue May 2 21:27:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 21:27:13 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:22992 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133947AbWEBU1F (ORCPT ); Tue, 2 May 2006 21:27:05 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k42KR12j004796; Tue, 2 May 2006 21:27:01 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k42KR0I9004795; Tue, 2 May 2006 21:27:00 +0100 Date: Tue, 2 May 2006 21:27:00 +0100 From: Ralf Baechle To: Shane McDonald Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] improve readability of arch/mips/Kconfig Message-ID: <20060502202700.GB3474@linux-mips.org> References: <200605012028.k41KSvsS002784@duval.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605012028.k41KSvsS002784@duval.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 01, 2006 at 02:28:57PM -0600, Shane McDonald wrote: your patch is corrupt. From ralf@linux-mips.org Tue May 2 21:34:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 21:34:43 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:7110 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133947AbWEBUef (ORCPT ); Tue, 2 May 2006 21:34:35 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k42KYXxC004953; Tue, 2 May 2006 21:34:33 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k42KYRcp004952; Tue, 2 May 2006 21:34:27 +0100 Date: Tue, 2 May 2006 21:34:27 +0100 From: Ralf Baechle To: Herbert Valerio Riedel Cc: jgarzik@pobox.com, netdev@vger.kernel.org, linux-mips@linux-mips.org, sshtylyov@ru.mvista.com Subject: Re: [PATCH] au1000_eth.c: use ether_crc() from Message-ID: <20060502203427.GC3474@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 01, 2006 at 01:46:42PM +0000, Herbert Valerio Riedel wrote: > since the au1000 driver already selects the CRC32 routines, simply replace > the internal ether_crc() implementation with the semantically equivalent > one from > > Signed-off-by: Herbert Valerio Riedel Looks good to me. Acked-by: Ralf Baechle Ralf From mrahman@sypixx.com Tue May 2 22:22:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 May 2006 22:22:24 +0100 (BST) Received: from smtp115.iad.emailsrvr.com ([207.97.245.115]:50335 "HELO smtp135.iad.emailsrvr.com") by ftp.linux-mips.org with SMTP id S8133953AbWEBVWO (ORCPT ); Tue, 2 May 2006 22:22:14 +0100 Received: from ratin (adsl-69-233-145-110.dsl.sndg02.pacbell.net [69.233.145.110]) (Authenticated sender: mrahman@sypixx.com) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 99B88451674 for ; Tue, 2 May 2006 17:22:06 -0400 (EDT) Message-ID: <007e01c66e2e$8008f720$2300a8c0@ratin> Reply-To: "Ratin" From: "Ratin" To: References: <4456960D.70403@telus.net> <20060502193838.GA3474@linux-mips.org> Subject: changing IP address on mipsel-linux Date: Tue, 2 May 2006 14:22:21 -0700 Organization: Sypixx Networks MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: OK Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrahman@sypixx.com Precedence: bulk X-list: linux-mips I am not sure if this is the right mailing list (new here) but how would you change the IP address parmanently on a box having IDT C32H434 CPU ? There seems to be no /etc/init.d/network on this box. I could do it with ifconfig but I need to make parmanent change as well as effective right away. The other question is when I change the IP address on the fly with ifconfig, is there a way to make the inet listener apps (that are running in the background) to autometically listen on the new IP address? Thanks, Ratin From cklai@itri.org.tw Wed May 3 04:17:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 04:17:29 +0100 (BST) Received: from maillog.itri.org.tw ([61.61.254.20]:33220 "EHLO maillog.itri.org.tw") by ftp.linux-mips.org with ESMTP id S8126480AbWECDRO (ORCPT ); Wed, 3 May 2006 04:17:14 +0100 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id k433D2o10802 for ; Wed, 3 May 2006 11:13:05 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k433Mth5010922 for ; Wed, 3 May 2006 11:23:10 +0800 (CST) Received: from ms1.itri.org.tw ([140.96.147.43]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k433MKV9010489 for ; Wed, 3 May 2006 11:22:55 +0800 (CST) Received: from 11088002601 ([140.96.147.156]) by ms1.itri.org.tw (Lotus Domino Release 5.0.13a) with ESMTP id 2006050311160693:18681 ; Wed, 3 May 2006 11:16:06 +0800 Message-ID: <00fa01c66e5f$eb0af470$8873608c@11088002601> Reply-To: "Charles C.K.Lai" From: "Charles C.K.Lai" To: Subject: How can I use DBAu1550 UART3 instead of UART0? Date: Wed, 3 May 2006 11:16:01 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-MIMETrack: Itemize by SMTP Server on MS1/ITRI(Release 5.0.13a |April 8, 2004) at 2006-05-03 11:16:07 AM, Serialize by Router on MS1/ITRI(Release 5.0.13a |April 8, 2004) at 2006-05-03 11:16:42 AM, Serialize complete at 2006-05-03 11:16:42 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cklai@itri.org.tw Precedence: bulk X-list: linux-mips Dear All, I have a AMD DBAu1550 Development board, if I have to use the uart port 3 instead of uart port 0, what can I do? Thanks a lot. Charles C.K. Lai From freddy@dusktilldawn.nl Wed May 3 08:11:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 08:11:24 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:49087 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133394AbWECHLM (ORCPT ); Wed, 3 May 2006 08:11:12 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 7A3195E584; Wed, 3 May 2006 09:11:04 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06440-03; Wed, 3 May 2006 09:11:04 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id 06AFF5DF61; Wed, 3 May 2006 09:11:03 +0200 (CEST) Date: Wed, 3 May 2006 09:11:03 +0200 From: Freddy Spierenburg To: Ratin Cc: linux-mips@linux-mips.org Subject: Re: changing IP address on mipsel-linux Message-ID: <20060503071103.GC11097@dusktilldawn.nl> References: <4456960D.70403@telus.net> <20060502193838.GA3474@linux-mips.org> <007e01c66e2e$8008f720$2300a8c0@ratin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YOiw+WO4Gc95oc3L" Content-Disposition: inline In-Reply-To: <007e01c66e2e$8008f720$2300a8c0@ratin> X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --YOiw+WO4Gc95oc3L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ratin, On Tue, May 02, 2006 at 02:22:21PM -0700, Ratin wrote: > I am not sure if this is the right mailing list (new here) but > how would you change the IP address parmanently on a box having > IDT C32H434 CPU ? Changing the ip address permanently does not depend on the cpu used, but more on the GNU/Linux distribution used. > There seems to be no /etc/init.d/network on this box. I could > do it with ifconfig but I need to make parmanent change as well > as effective right away. You should first tell me which GNU/Linux distribution you use and then I can give you a clue on where to change it permanently. Say for instance Debian uses /etc/network/interfaces . S.u.S.E has a thing called YaST if I remember correctly and Red Hat and the likes use a directory called /etc/sysconfig/network-scripts/ But you tell me there does exist no /etc/init.d/network. So maybe you are running BusyBox or something and then you are completely on your own how to do things. Althought conforming to well known practice will not hurt you. :-) The best thing to do is check out /etc/inittab and learn how it works ($ man inittab). Then you will be able to find out how your GNU/Linux system boots and after some thorough searching you will find where the ip address is set. Then there is also the possibility that the ip address is set using the command to boot the kernel. Well, then you know where to permanently change it :-) As you can see, lot's of possibilities. Good luck! > The other question is when I change the IP address on the fly > with ifconfig, is there a way to make the inet listener apps > (that are running in the background) to autometically listen on > the new IP address? This depends completely on the application used. If the application listens on a specific ip address, then you should probably restart the application to make it listen to the new ip address. But than you would in between the restart also have to configure the application to listen on the new ip address. If you have the application listen to INADDR_ANY (0.0.0.0) then you don't have to do anything. Again, good luck! --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --YOiw+WO4Gc95oc3L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWFeHbxf9XXlB0eERAvSUAKDkbA0Q33vpKwvqRdc0sVvYyTr8awCgnkxp YQmJDQqafDah1S8DhNdDet8= =W9SC -----END PGP SIGNATURE----- --YOiw+WO4Gc95oc3L-- From freddy@dusktilldawn.nl Wed May 3 08:16:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 08:16:26 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:51135 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133394AbWECHQR (ORCPT ); Wed, 3 May 2006 08:16:17 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 62D2A5E59E; Wed, 3 May 2006 09:16:11 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19933-01; Wed, 3 May 2006 09:16:09 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id D19085DF61; Wed, 3 May 2006 09:16:08 +0200 (CEST) Date: Wed, 3 May 2006 09:16:08 +0200 From: Freddy Spierenburg To: "Charles C.K.Lai" Cc: linux-mips@linux-mips.org Subject: Re: How can I use DBAu1550 UART3 instead of UART0? Message-ID: <20060503071608.GE11097@dusktilldawn.nl> References: <00fa01c66e5f$eb0af470$8873608c@11088002601> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9nxfG+mZwdJSiAE" Content-Disposition: inline In-Reply-To: <00fa01c66e5f$eb0af470$8873608c@11088002601> X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --/9nxfG+mZwdJSiAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Charles, On Wed, May 03, 2006 at 11:16:01AM +0800, Charles C.K.Lai wrote: > I have a AMD DBAu1550 Development board,=20 > if I have to use the uart port 3 instead of uart port 0,=20 > what can I do?=20 Using /dev/ttyS3 instead of /dev/ttyS0 might be the thing to do. Do you see both ports get detected during boot ($ dmesg)? That should give you a clue. --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --/9nxfG+mZwdJSiAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWFi4bxf9XXlB0eERAo9kAJ9jfFtXGowmcAqRcb+TSgFbZCsX5wCg8Ebv b1U6C6LvWIa5nsZnjeUIPRQ= =BOVX -----END PGP SIGNATURE----- --/9nxfG+mZwdJSiAE-- From giometti@enneenne.com Wed May 3 08:47:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 08:48:06 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:14289 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133394AbWECHr4 (ORCPT ); Wed, 3 May 2006 08:47:56 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbC57-0006SZ-00; Wed, 03 May 2006 09:47:33 +0200 Date: Wed, 3 May 2006 09:47:33 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: jgarzik@pobox.com, netdev@vger.kernel.org, Linux-MIPS Subject: Re: [PATCH] au1000_eth.c Power Management, driver registration and module support Message-ID: <20060503074733.GA23726@gundam.enneenne.com> References: <20060405154711.GL7029@enneenne.com> <20060405222332.GO7029@enneenne.com> <20060405222620.GP7029@enneenne.com> <4435290C.50607@ru.mvista.com> <20060406155011.GC23424@enneenne.com> <4446857D.90507@ru.mvista.com> <20060502150914.GE20543@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20060502150914.GE20543@gundam.enneenne.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, yesterday I did a little mess with GIT... now the patch is complete. Sorry. :) I forgot also to say that it has been done against =ABlinux-2.6.16-stable=BB branch. Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWGAVQaTCYNJaVjMRAoWSAKCjGwhF6GYkr1SZwpj8oiRX3iB2DgCgykmi 0yigW5WKhWraCr+XWdZdszg= =TYtd -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From cklai@itri.org.tw Wed May 3 08:53:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 08:53:33 +0100 (BST) Received: from maillog.itri.org.tw ([61.61.254.20]:65013 "EHLO maillog.itri.org.tw") by ftp.linux-mips.org with ESMTP id S8133516AbWECHxX (ORCPT ); Wed, 3 May 2006 08:53:23 +0100 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id k437n2o14939; Wed, 3 May 2006 15:49:08 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k437x0JZ009160; Wed, 3 May 2006 15:59:10 +0800 (CST) Received: from ms4.itri.org.tw ([140.96.151.44]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k437wWBU008979; Wed, 3 May 2006 15:58:49 +0800 (CST) Received: from 11088002601 ([140.96.151.160]) by ms4.itri.org.tw (Lotus Domino Release 5.0.13a) with ESMTP id 2006050315521908:13886 ; Wed, 3 May 2006 15:52:19 +0800 Message-ID: <017c01c66e86$811e56c0$8873608c@11088002601> Reply-To: "Charles C.K.Lai" From: "Charles C.K.Lai" To: "Freddy Spierenburg" Cc: References: <00fa01c66e5f$eb0af470$8873608c@11088002601> <20060503071608.GE11097@dusktilldawn.nl> Subject: Re: How can I use DBAu1550 UART3 instead of UART0? Date: Wed, 3 May 2006 15:52:08 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-MIMETrack: Itemize by SMTP Server on MS4/ITRI(Release 5.0.13a |April 8, 2004) at 2006-05-03 03:52:19 PM, Serialize by Router on MS4/ITRI(Release 5.0.13a |April 8, 2004) at 2006-05-03 03:52:46 PM, Serialize complete at 2006-05-03 03:52:46 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01C66EC9.88D30350" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cklai@itri.org.tw Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0178_01C66EC9.88D30350 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Dear Freddy, If I'd like to build my kernel starting with UART port 3, not starting with UART port 0, which files should I modify? Or what should I take care? Thanks a lot. Charles C.K. Lai ------=_NextPart_000_0178_01C66EC9.88D30350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5"
Dear Freddy,
 
    If I'd like to = build my=20 kernel starting with UART port 3,
    not starting with = UART port=20 0,
    which files = should I=20 modify?
    Or what should I = take=20 care?
 
    Thanks a = lot.
 
    Charles C.K.=20 Lai
------=_NextPart_000_0178_01C66EC9.88D30350-- From freddy@dusktilldawn.nl Wed May 3 09:15:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 09:15:54 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:57535 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133394AbWECIPn (ORCPT ); Wed, 3 May 2006 09:15:43 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 16FCC5E59E; Wed, 3 May 2006 10:15:38 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06440-06; Wed, 3 May 2006 10:15:37 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id A52815DF61; Wed, 3 May 2006 10:15:37 +0200 (CEST) Date: Wed, 3 May 2006 10:15:37 +0200 From: Freddy Spierenburg To: "Charles C.K.Lai" Cc: linux-mips@linux-mips.org Subject: Re: How can I use DBAu1550 UART3 instead of UART0? Message-ID: <20060503081537.GF11097@dusktilldawn.nl> References: <00fa01c66e5f$eb0af470$8873608c@11088002601> <20060503071608.GE11097@dusktilldawn.nl> <017c01c66e86$811e56c0$8873608c@11088002601> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xf1frN3LpSrbXX2S" Content-Disposition: inline In-Reply-To: <017c01c66e86$811e56c0$8873608c@11088002601> X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --xf1frN3LpSrbXX2S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Charles, I'm not sure what you try to accomplish, so I'll try to answer your question in two ways. On Wed, May 03, 2006 at 03:52:08PM +0800, Charles C.K.Lai wrote: > If I'd like to build my kernel starting with UART port 3,=20 > not starting with UART port 0,=20 Do you want UART port 3 to become /dev/ttyS0 and completely ignore the fact that your CPU has a UART port 0 and 1 too? So you just only want to use 1 UART namely port 3 of you CPU? If this is the case you can start fiddling around with drivers/serial/8250_au1x00.c and also have a loog at include/asm/mach-au1x00/au1000.h If you just want to have your serial console on UART port 3 instead of port 0 you have to do a little bit more. First you need to tell yamon (the bootloader I expect you to use) to use UART port 3 instead of port 0 and then you just boot the kernel with the console=3D option. See Documentation/kernel-parameters.txt for more information. Hope this will help. Otherwist try to explain a little bit more thoroughly what you try to accomplish. Good luck! --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --xf1frN3LpSrbXX2S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWGapbxf9XXlB0eERAvgwAKCrRSmlRwMjNnATnh0LYYXrKHkBYQCdHb0Y mUt1yYcaMT4OJbkj0Ku7AeM= =0pza -----END PGP SIGNATURE----- --xf1frN3LpSrbXX2S-- From jcrouse@cosmic.amd.com Wed May 3 15:43:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 15:44:02 +0100 (BST) Received: from amdext3.amd.com ([139.95.251.6]:61841 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S7620188AbWECOnu (ORCPT ); Wed, 3 May 2006 15:43:50 +0100 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k43EhQcE022418; Wed, 3 May 2006 07:44:27 -0700 Received: from 139.95.53.182 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Wed, 03 May 2006 07:43:33 -0700 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com ([147.5.200.40]) by SSVLEXBH1.amd.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 3 May 2006 07:43:33 -0700 Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id E66FD2028; Wed, 3 May 2006 08:43:32 -0600 (MDT) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k43ExRam003142; Wed, 3 May 2006 08:59:27 -0600 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k43ExRx8003141; Wed, 3 May 2006 08:59:27 -0600 Date: Wed, 3 May 2006 08:59:27 -0600 From: "Jordan Crouse" To: "Wolfgang Ocker" cc: linux-mips@linux-mips.org Subject: Re: Au1200 MMC/SD problem Message-ID: <20060503145927.GD24185@cosmic.amd.com> References: <1146548770.1597.43.camel@seneca.recco.de> <20060502144314.GI22167@cosmic.amd.com> <1146592926.11188.12.camel@seneca.recco.de> MIME-Version: 1.0 In-Reply-To: <1146592926.11188.12.camel@seneca.recco.de> User-Agent: Mutt/1.5.11 X-OriginalArrivalTime: 03 May 2006 14:43:33.0502 (UTC) FILETIME=[F3D131E0:01C66EBF] X-WSS-ID: 68461E1F32W5755790-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips > The last one. In au1xmmc_irq() the status register is read with the > SD_STATUS_RAT bit set. Ok - so the card is timing out. That could be a series of problems, some of which could be hardware, some of which could be software. Since you are using a db1200, I'll rule out hardware for the moment, unless you have a modified board. Do MMC cards work? Try one - that will give us another data point. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From mrahman@sypixx.com Wed May 3 17:11:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 17:11:40 +0100 (BST) Received: from smtp135.iad.emailsrvr.com ([207.97.245.135]:5834 "HELO smtp135.iad.emailsrvr.com") by ftp.linux-mips.org with SMTP id S8133465AbWECQLa (ORCPT ); Wed, 3 May 2006 17:11:30 +0100 Received: from ratin (adsl-69-233-145-110.dsl.sndg02.pacbell.net [69.233.145.110]) (Authenticated sender: mrahman@sypixx.com) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id 625B744C6F8; Wed, 3 May 2006 12:11:21 -0400 (EDT) Message-ID: <005501c66ecc$4b2ef470$2300a8c0@ratin> Reply-To: "Ratin" From: "Ratin" To: "Freddy Spierenburg" Cc: References: <4456960D.70403@telus.net> <20060502193838.GA3474@linux-mips.org> <007e01c66e2e$8008f720$2300a8c0@ratin> <20060503071103.GC11097@dusktilldawn.nl> Subject: Re: changing IP address on mipsel-linux Date: Wed, 3 May 2006 09:11:53 -0700 Organization: Sypixx Networks MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: OK Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrahman@sypixx.com Precedence: bulk X-list: linux-mips Hi Freddy, Thanks for your response, I appreciate your help. I am kind of new to this version of Linux. The uname -a gives me this: Linux 192.168.0.62 2.6.10-idt20050328 #1 Tue Dec 13 10:36:55 PST 2005 mips unknown But it is referred as Mipsel-Linux. It is running busybox. I guess I have to dig more into kernel code to see how the kernel sets the IP address during init. I was hoping somebody here would know the Mipsel-Linux IP address assignment process. Thanks, Ratin ----- Original Message ----- From: "Freddy Spierenburg" To: "Ratin" Cc: Sent: Wednesday, May 03, 2006 12:11 AM Subject: Re: changing IP address on mipsel-linux From geert@linux-m68k.org Wed May 3 17:14:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 17:14:32 +0100 (BST) Received: from witte.sonytel.be ([80.88.33.193]:161 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133465AbWECQOV (ORCPT ); Wed, 3 May 2006 17:14:21 +0100 Received: from pademelon.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id k43GEJCQ017887; Wed, 3 May 2006 18:14:19 +0200 (MEST) Date: Wed, 3 May 2006 18:14:18 +0200 (CEST) From: Geert Uytterhoeven To: Ratin cc: Freddy Spierenburg , Linux/MIPS Development Subject: Re: changing IP address on mipsel-linux In-Reply-To: <005501c66ecc$4b2ef470$2300a8c0@ratin> Message-ID: References: <4456960D.70403@telus.net> <20060502193838.GA3474@linux-mips.org> <007e01c66e2e$8008f720$2300a8c0@ratin> <20060503071103.GC11097@dusktilldawn.nl> <005501c66ecc$4b2ef470$2300a8c0@ratin> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 3 May 2006, Ratin wrote: > Hi Freddy, Thanks for your response, I appreciate your help. I am kind of new > to this version of Linux. > The uname -a gives me this: > > Linux 192.168.0.62 2.6.10-idt20050328 #1 Tue Dec 13 10:36:55 PST 2005 mips > unknown > > But it is referred as Mipsel-Linux. It is running busybox. I guess I have to > dig more into kernel code to see how the > kernel sets the IP address during init. I was hoping somebody here would know > the Mipsel-Linux IP address assignment > process. Thanks, The kernel does not set the IP address during init. That's the responsibility of user space, i.e. the scripts that call busybox in your case. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From Don_Hiatt@pmc-sierra.com Wed May 3 17:22:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 17:22:22 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:30377 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S7620187AbWECQWL (ORCPT ); Wed, 3 May 2006 17:22:11 +0100 Received: (qmail 9540 invoked by uid 101); 3 May 2006 16:21:59 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 3 May 2006 16:21:59 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k43GLwpK003741; Wed, 3 May 2006 09:21:59 -0700 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Wed, 3 May 2006 09:21:58 -0700 Message-ID: <5C1FD43E5F1B824E83985A74F396286E01DD4E88@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> From: Don Hiatt To: "'Ratin'" Cc: linux-mips@linux-mips.org Subject: RE: changing IP address on mipsel-linux Date: Wed, 3 May 2006 09:21:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Don_Hiatt@pmc-sierra.com Precedence: bulk X-list: linux-mips Perhaps you mean you want to set the IP for a NFS mounted filesystem? If so you can pass "ip=dhcp" or ip="192.168.13.120" as a kernel argument. Cheers, don -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ratin Sent: Wednesday, May 03, 2006 9:12 AM To: Freddy Spierenburg Cc: linux-mips@linux-mips.org Subject: Re: changing IP address on mipsel-linux Hi Freddy, Thanks for your response, I appreciate your help. I am kind of new to this version of Linux. The uname -a gives me this: Linux 192.168.0.62 2.6.10-idt20050328 #1 Tue Dec 13 10:36:55 PST 2005 mips unknown Ratin From hvr@gnu.org Wed May 3 17:42:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 17:42:26 +0100 (BST) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:28397 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S7620190AbWECQmO (ORCPT ); Wed, 3 May 2006 17:42:14 +0100 Received: from mini.intra (dhcp-1432-30.blizz.at [213.143.126.4]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k43Gfbci015500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 May 2006 18:41:43 +0200 Subject: Re: RFC: au1000_etc.c phylib rewrite From: Herbert Valerio Riedel To: Mark Schank Cc: ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com, netdev@vger.kernel.org, Ralf Baechle , "Robin H. Johnson" In-Reply-To: <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mbzD0rZ6vt078KauN4eQ" Organization: Free Software Foundation Date: Wed, 03 May 2006 18:34:16 +0200 Message-Id: <1146674056.31241.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: ClamAV 0.88.1/1437/Wed May 3 08:54:45 2006 on phobos.hvrlab.org X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips --=-mbzD0rZ6vt078KauN4eQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hello * On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote: > At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote: > >On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote: > > > The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesi= gned > > > the board and switched to two single Broadcom phys, but they continue= d to > > > control both phys through MAC0, which is the actual purpose of the=20 > > dual-phy > > > hack. I am a user of the CSB655, so I sort of care. > > > > > > Will the new PHY framework allow a second PHY for a second MAC (MAC1)= be > > > controlled from the first MAC's (MAC0) mdio interface? > > > >should'nt be a problem (as opposed to the bosporus case... see below)... > >I assume the phy-addresses on which the boarcom dual phy is configured > >are the same for all Cogent CSB655 boards? >=20 > Dual PHY configuration: > MAC0 - phy addr 4 > MAC1 - phy addr 3 > Single PHY configuration: > MAC0 - phy addr 1 > MAC1 - phy addr 0 while at it, does anyone happen to know what the phy-addr/MAC assignment on the XXS1500 is? > >does this need to be autodetected dynamically at runtime, or can we rely > >on a compile time Kconfig-conditional to set a static phy-addr<->eth% > >d-phy mapping for this board-specific case? Or de we really need such a > >complex mii_probe() function to detect weird scenarios? :) >=20 > The compile time Kconfig-conditional should be okay. The driver need to=20 > handle the fact that the MAC1's phy is controlled by MAC0's mdio=20 > interface. This means that MAC0 controller can not be disabled when the=20 > associated eth% device is down, otherwise you lose the ability to control= =20 > MAC1's phy. ...or at least, the MAC associated with the particular MII bus should be brought up if necessary before any mdio access (that's what I'm implementing right now) but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't seem to be defined anywhere; shouldn't that be at least defined in some Kconfig file, especially if the XXS1550 board is supposed to make use of it?=20 btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I couldn't find any mention of it in Kconfig files either? > >using static phy addr mappings would also allow for setting > >board-specific phy-irq assignments, which would then be handled by the > >phylib facilities, instead of polling the status of phy with a timer; > >(and in case we don't have any board-specific compile time setting, we > >can still fall back to search the phy-addresses for a PHY at runtime as > >the generic case) >=20 > Will the phylib facilities handle the case where two phys share a single = IRQ? afaics from the source, it doesn't handle the case of multiplexed phy notification irqs; although the interrupt is requested with the SA_SHIRQ flag, the first phy-interrupt-handler to be called already returns IRQ_HANDLED... doesn't feel right in some way ;-) > >while at it, what about that CONFIG_MIPS_BOSPORUS special case? why > >doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the > >physical world? >=20 > I don't have first hand knowledge of this board, but I have worked with=20 > Kendin switches before. They have a special port that allows direct=20 > connection of a MAC into the switch port without the use of a phy. The=20 > MAC's MII is directly connected to the switch ports MII. So instead of t= his: > MAC <-> PHY <->PHY <-> Switch_Port > You have this: > MAC <-> Switch_Port >=20 > So the MAC talks to the physical world via the switch. thx; in the meantime, I've happened to find the board schematics and the switch data-sheet in order to understand the situation better regards, hvr --=-mbzD0rZ6vt078KauN4eQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEWNuISYHgZIg/QUIRAv10AJ9J5flzM9+vstKPnccHjW+xhroMmQCfT/YE fJRevU7OAVXjhh40INNuMiI= =eZj5 -----END PGP SIGNATURE----- --=-mbzD0rZ6vt078KauN4eQ-- From mrahman@sypixx.com Wed May 3 17:54:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 17:54:37 +0100 (BST) Received: from smtp125.iad.emailsrvr.com ([207.97.245.125]:23959 "HELO smtp135.iad.emailsrvr.com") by ftp.linux-mips.org with SMTP id S7620187AbWECQy1 (ORCPT ); Wed, 3 May 2006 17:54:27 +0100 Received: from ratin (adsl-69-233-145-110.dsl.sndg02.pacbell.net [69.233.145.110]) (Authenticated sender: mrahman@sypixx.com) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id 11B6744C45A; Wed, 3 May 2006 12:54:12 -0400 (EDT) Message-ID: <007b01c66ed2$493622f0$2300a8c0@ratin> Reply-To: "Ratin" From: "Ratin" To: "Don Hiatt" Cc: References: <5C1FD43E5F1B824E83985A74F396286E01DD4E88@bby1exm08.pmc_nt.nt.pmc-sierra.bc.ca> Subject: Re: changing IP address on mipsel-linux Date: Wed, 3 May 2006 09:54:46 -0700 Organization: Sypixx Networks MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: OK Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrahman@sypixx.com Precedence: bulk X-list: linux-mips I meant changing the IP address of the device running mipsel-linux statically (not DHCP) on the fly (I am using http interface and a C handler function to do so) and then keeping it for the rest of its lifetime, so have to run system ( ifconfig ) or similar API call for immediate change and perhaps write the new IP to a file somewhere, which I am yet to discover. Ratin ----- Original Message ----- From: "Don Hiatt" To: "'Ratin'" Cc: Sent: Wednesday, May 03, 2006 9:21 AM Subject: RE: changing IP address on mipsel-linux > Perhaps you mean you want to set the IP for a NFS mounted filesystem? > > If so you can pass "ip=dhcp" or ip="192.168.13.120" as a kernel argument. > > Cheers, > > don > > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ratin > Sent: Wednesday, May 03, 2006 9:12 AM > To: Freddy Spierenburg > Cc: linux-mips@linux-mips.org > Subject: Re: changing IP address on mipsel-linux > > > Hi Freddy, Thanks for your response, I appreciate your help. I am kind of > new to this version of Linux. > The uname -a gives me this: > > Linux 192.168.0.62 2.6.10-idt20050328 #1 Tue Dec 13 10:36:55 PST 2005 mips > unknown > > Ratin > From mschank@dcbnet.com Wed May 3 19:00:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 May 2006 19:00:30 +0100 (BST) Received: from firewall.dcbnet.com ([12.96.67.19]:10470 "EHLO firewall.dcbnet.com") by ftp.linux-mips.org with ESMTP id S7620194AbWECSAU (ORCPT ); Wed, 3 May 2006 19:00:20 +0100 Received: from mschank.dcbnet.com (mschank.dcbnet.com [205.166.54.128]) by firewall.dcbnet.com (8.12.10/8.12.10) with ESMTP id k43I08i7013390; Wed, 3 May 2006 13:00:11 -0500 Message-Id: <5.1.0.14.2.20060503122616.0283e3b0@205.166.54.3> X-Sender: mschank@205.166.54.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 May 2006 13:01:02 -0500 To: Herbert Valerio Riedel From: Mark Schank Subject: Re: RFC: au1000_etc.c phylib rewrite Cc: linux-mips@linux-mips.org In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain> References: <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mschank@dcbnet.com Precedence: bulk X-list: linux-mips Herbert, >btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I >couldn't find any mention of it in Kconfig files either? The CSB655 makes use of some of these seeming "unused" options, but the board specific code for the CSB655 was never submitted back to linux-mips tree. I did not develop of any of this code, so I am not sure of the reason why it was not submitted back. I received the code when I purchased a CSB655/955 developers kit and have since ported portions of it forward to the 2.6.16 branch. I am willing to submit what I have done, but I don't want to step on the original developers toes. There were also several changes I had to make to generic MIPs and Linux code, and I am not sure of the proper way to handle them in the general linux-mips tree. -Mark From safiudeen@hotmail.com Thu May 4 07:31:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 07:31:29 +0100 (BST) Received: from bay18-f22.bay18.hotmail.com ([65.54.187.72]:62399 "EHLO hotmail.com") by ftp.linux-mips.org with ESMTP id S8133525AbWEDGbS (ORCPT ); Thu, 4 May 2006 07:31:18 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 May 2006 23:31:11 -0700 Message-ID: Received: from 220.247.245.66 by by18fd.bay18.hotmail.msn.com with HTTP; Thu, 04 May 2006 06:31:08 GMT X-Originating-IP: [220.247.245.66] X-Originating-Email: [safiudeen@hotmail.com] X-Sender: safiudeen@hotmail.com From: "safiudeen Ts" To: linux-mips@linux-mips.org Subject: Linux-2.6.16 on DB1100 Date: Thu, 04 May 2006 06:31:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 May 2006 06:31:11.0343 (UTC) FILETIME=[55BB37F0:01C66F44] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: safiudeen@hotmail.com Precedence: bulk X-list: linux-mips Hi all, I am testing linux-2.6.16 on DB1100 board.I downloded the kernel from www.linux-mips.org and cross compiled with configaration that suit for Db1100. I used following command to get vmlinux.srec $ make vmlinux.srec and copyed it to /tftpboot/ DB1100 board load the kernel image through nfs using yamon boot loader. when we reset the board, it starts the yamon and load the kernel from nfs server after that it hang threre. There are no any kernel messages comming to minicom ( minicom is running in PC with serial port is connected to the db1100 boards serial port 0) Followings are the minicom output I recived ----------------------------------------------------------- About to load tftp://192.168.0.3//tftpboot/vmlinux.srec Press Ctrl-C to break ............................................................................... .................................................................................. ................................................................................ Start = 0x8034f000, range = ( 0x80100000,0x8036e084 ) ----------------------------------------------------------- Please can anyone help me to short it out this problem? Thanx Safiudeen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From robbat2@gentoo.org Thu May 4 07:49:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 07:49:52 +0100 (BST) Received: from pops.net-conex.com ([204.244.176.3]:36792 "EHLO mail.net-conex.com") by ftp.linux-mips.org with ESMTP id S8133525AbWEDGtm (ORCPT ); Thu, 4 May 2006 07:49:42 +0100 Received: from curie.orbis-terrarum.net (S01060050da688d47.vc.shawcable.net [24.80.100.253]) by mail.net-conex.com (8.13.4/8.12.11) with ESMTP id k446ndC1017198 for ; Wed, 3 May 2006 23:49:40 -0700 Received: (qmail 27368 invoked by uid 10000); 3 May 2006 23:49:45 -0700 Date: Wed, 3 May 2006 23:49:45 -0700 From: "Robin H. Johnson" To: Herbert Valerio Riedel Cc: linux-mips@linux-mips.org, netdev@vger.kernel.org Subject: Re: RFC: au1000_etc.c phylib rewrite Message-ID: <20060504064945.GE12203@curie-int.vc.shawcable.net> Mail-Followup-To: Herbert Valerio Riedel , linux-mips@linux-mips.org, netdev@vger.kernel.org References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <1146674056.31241.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="maH1Gajj2nflutpK" Content-Disposition: inline In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robbat2@gentoo.org Precedence: bulk X-list: linux-mips --maH1Gajj2nflutpK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 03, 2006 at 06:34:16PM +0200, Herbert Valerio Riedel wrote: > while at it, does anyone happen to know what the phy-addr/MAC assignment > on the XXS1500 is? Nope. > but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't > seem to be defined anywhere; shouldn't that be at least defined in some > Kconfig file, especially if the XXS1550 board is supposed to make use of > it?=20 Hmm, I do recall submitting a patch previously that added=20 'select BCM5222_DUAL_PHY' for the XXS1500 unit. --=20 Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --maH1Gajj2nflutpK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFEWaQJPpIsIjIzwiwRAmnIAJwJWwob8g8a1FGR0B/lRFYpihXchACglqdK Wgfl2lz8nmJvKy0KPPzPW6M= =zwe8 -----END PGP SIGNATURE----- --maH1Gajj2nflutpK-- From freddy@dusktilldawn.nl Thu May 4 07:57:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 07:57:33 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:47553 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133487AbWEDG5F (ORCPT ); Thu, 4 May 2006 07:57:05 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 7C3F15E59A; Thu, 4 May 2006 08:56:58 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32305-04; Thu, 4 May 2006 08:56:58 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id F27FB5DF61; Thu, 4 May 2006 08:56:57 +0200 (CEST) Date: Thu, 4 May 2006 08:56:57 +0200 From: Freddy Spierenburg To: safiudeen Ts Cc: linux-mips@linux-mips.org Subject: Re: Linux-2.6.16 on DB1100 Message-ID: <20060504065657.GI11097@dusktilldawn.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wFsmFZmaatp/x6ak" Content-Disposition: inline In-Reply-To: X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --wFsmFZmaatp/x6ak Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Safiudeen, On Thu, May 04, 2006 at 06:31:08AM +0000, safiudeen Ts wrote: > About to load tftp://192.168.0.3//tftpboot/vmlinux.srec > Press Ctrl-C to break > .........................................................................= =2E..... > .........................................................................= =2E........ > .........................................................................= =2E...... >=20 > Start =3D 0x8034f000, range =3D ( 0x80100000,0x8036e084 ) There is some vital information missing from your email. Can you also send the yamon command's you use to start the system. Like for instance the output below is far more complete than yours. I have put some extra comment in between '->' and '<-' to give you an idea what is happenin= g. -> Here yamon starts and shows some general information <- YAMON ROM Monitor, Revision 02.27GDB1100. Copyright (c) 1999-2004 MIPS Technologies, Inc. - All Rights Reserved. For a list of available commands, type 'help'. Switch S1.1 selects endian. Compilation time =3D Jan 1 2000 00:00:35 MAC address =3D 00.00.00.00.00.00 Processor Company ID =3D 0x03 Processor ID/revision =3D 0x02 / 0x04 Endianness =3D Little CPU =3D 396 MHz Flash memory size =3D 64 MByte SDRAM size =3D 192 MByte First free SDRAM address =3D 0x800a66ec -> Here you can see me loading the kernel image by means of tftp from my tf= tp-server. <- YAMON> load tftp://192.168.10.136/vmlinux-2.6.16-20060418.000.srec About to load tftp://192.168.10.136/vmlinux-2.6.16-20060418.000.srec Press Ctrl-C to break ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ .................. Start =3D 0x80473000, range =3D (0x80100000,0x80498085), format =3D SREC -> Here you can see me starting the kernel image, which uses a root filesystem from my nfs-server <- YAMON> go . ip=3D192.168.10.236 nfsroot=3D192.168.10.136:\ ? /opt/cellar0/AMD.Alchemy/test.20060202/root/ rw -> Here you can see my kernel starting <- Linux version 2.6.16 (frsp@id6236) (gcc version 3.4.6 20060122 (prereleas= e) (Debian 3.4.5-2)) #20 PREEMPT Tue Apr 18 10:59:57 CEST 2006 CPU revision is: 02030204 AMD Alchemy Au1100/Db1100 Board (PRId 02030204) @ 396MHZ BCLK switching enabled! Determined physical RAM map: memory: 0c000000 @ 00000000 (usable) Built 1 zonelists Kernel command line: ip=3D192.168.10.236 nfsroot=3D192.168.10.136:/opt/ce= llar0/AMD.Alchemy/test.20060202/root/ rw console=3DttyS0,115200 -> I have cut out the rest for brevity <- So there can be two things: a) You forgot to start the loaded kernel. (this I can't tell from your output, so please make it more verbose) b) Can it be that you have disabled CONFIG_PRINTK in the kernel configuration??? --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --wFsmFZmaatp/x6ak Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWaW5bxf9XXlB0eERArDpAJ9sUya6dZUmZWH5abHD5/cBjfyWpACfXxdV luil/nEZFXO02WICmYTe9qs= =8o2h -----END PGP SIGNATURE----- --wFsmFZmaatp/x6ak-- From safiudeen@hotmail.com Thu May 4 10:10:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 10:11:00 +0100 (BST) Received: from bay18-f5.bay18.hotmail.com ([65.54.187.55]:31865 "EHLO hotmail.com") by ftp.linux-mips.org with ESMTP id S8133532AbWEDJKr (ORCPT ); Thu, 4 May 2006 10:10:47 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 4 May 2006 02:10:37 -0700 Message-ID: Received: from 220.247.245.66 by by18fd.bay18.hotmail.msn.com with HTTP; Thu, 04 May 2006 09:10:34 GMT X-Originating-IP: [220.247.245.66] X-Originating-Email: [safiudeen@hotmail.com] X-Sender: safiudeen@hotmail.com In-Reply-To: <20060504065657.GI11097@dusktilldawn.nl> From: "safiudeen Ts" To: freddy@dusktilldawn.nl, linux-mips@linux-mips.org Subject: Re: Linux-2.6.16 on DB1100 Date: Thu, 04 May 2006 09:10:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 May 2006 09:10:37.0199 (UTC) FILETIME=[9B6D01F0:01C66F5A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: safiudeen@hotmail.com Precedence: bulk X-list: linux-mips Hi , Here is the original output from minicom. ------------------------------------------------------------ YAMON ROM Monitor, Revision 02.19DB1100. Copyright (c) 1999-2000 MIPS Technologies, Inc. - All Rights Reserved. For a list of available commands, type 'help'. Compilation time = Oct 18 2005 11:09:13 MAC address = 00.00.1a.18.d4.d4 Processor Company ID = 0x03 Processor ID/revision = 0x02 / 0x04 Endianness = Little CPU = 396 MHz Flash memory size = 32 MByte SDRAM size = 64 MByte First free SDRAM address = 0x8008d314 Environment variable 'start' exists. After 2 seconds it will be interpreted as a YAMON command and executed. Press Ctrl-C to bypass this. About to load tftp://192.168.0.5//tftpboot/vmlinux.srec Press Ctrl-C to break ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ .............................. Start = 0x8034f000, range = (0x80100000,0x8036e084), format = SREC ----------------------------------------------------------- After above message there are no any messagess were displayed. It look like kernel hang somewhere before doing the serial UART0 initialization. I put fiew code like setting GPIO18 to high and low in preodically to see whether the kernel is running, but there were no change in the state of GPIO18. Followings are the Yamon enviremnt variables ----------------------------------------------------------------- YAMON> setenv MAC (R/W) 0 bootfile (R/W) /tftpboot/vmlinux.srec bootprot (R/W) tftp bootser (USER) 192.168.0.5 bootserport (R/W) tty0 bootserver (R/W) 192.168.0.5 ethaddr (R/W) 00.00.1a.18.d4.d4 gateway (R/W) 0.0.0.0 ipaddr (R/W) 192.168.0.42 memsize (RO) 0x04000000 modetty0 (R/W) 115200,n,8,1,none modetty1 (R/W) 115200,n,8,1,none prompt (R/W) YAMON start (R/W) load; go . ip=192.168.0.42:192.168.0.5::::eth0: subnetmask (R/W) 255.255.255.0 YAMON> ----------------------------------------------------------------- please tell me wether I should apply any patches to this Linux-2.6.16 kernel to make it works with db1100 I have tested db1100 board with linux-2.4.20 in the same way there it works fine. I want to move to linux-2.6. please suggest me any good working linux-2.6 kernel release with db1100. Thanx Safiudeen >From: Freddy Spierenburg >To: safiudeen Ts >CC: linux-mips@linux-mips.org >Subject: Re: Linux-2.6.16 on DB1100 >Date: Thu, 4 May 2006 08:56:57 +0200 > >Hi Safiudeen, > >On Thu, May 04, 2006 at 06:31:08AM +0000, safiudeen Ts wrote: > > About to load tftp://192.168.0.3//tftpboot/vmlinux.srec > > Press Ctrl-C to break > > >............................................................................... > > >.................................................................................. > > >................................................................................ > > > > Start = 0x8034f000, range = ( 0x80100000,0x8036e084 ) >There is some vital information missing from your email. Can you >also send the yamon command's you use to start the system. Like for >instance the output below is far more complete than yours. I have put some >extra comment in between '->' and '<-' to give you an idea what is >happening. > >-> Here yamon starts and shows some general information <- > > YAMON ROM Monitor, Revision 02.27GDB1100. > Copyright (c) 1999-2004 MIPS Technologies, Inc. - All Rights Reserved. > > For a list of available commands, type 'help'. > > Switch S1.1 selects endian. > > Compilation time = Jan 1 2000 00:00:35 > MAC address = 00.00.00.00.00.00 > Processor Company ID = 0x03 > Processor ID/revision = 0x02 / 0x04 > Endianness = Little > CPU = 396 MHz > Flash memory size = 64 MByte > SDRAM size = 192 MByte > First free SDRAM address = 0x800a66ec > >-> Here you can see me loading the kernel image by means of tftp from my >tftp-server. <- > > YAMON> load tftp://192.168.10.136/vmlinux-2.6.16-20060418.000.srec > About to load tftp://192.168.10.136/vmlinux-2.6.16-20060418.000.srec > Press Ctrl-C to break > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > ........................................ > .................. > Start = 0x80473000, range = (0x80100000,0x80498085), format = SREC > >-> Here you can see me starting the kernel image, which uses a > root filesystem from my nfs-server <- > > YAMON> go . ip=192.168.10.236 nfsroot=192.168.10.136:\ > ? /opt/cellar0/AMD.Alchemy/test.20060202/root/ rw > >-> Here you can see my kernel starting <- > > Linux version 2.6.16 (frsp@id6236) (gcc version 3.4.6 20060122 >(prerelease) (Debian 3.4.5-2)) #20 PREEMPT Tue Apr 18 10:59:57 CEST 2006 > CPU revision is: 02030204 > AMD Alchemy Au1100/Db1100 Board > (PRId 02030204) @ 396MHZ > BCLK switching enabled! > Determined physical RAM map: > memory: 0c000000 @ 00000000 (usable) > Built 1 zonelists > Kernel command line: ip=192.168.10.236 >nfsroot=192.168.10.136:/opt/cellar0/AMD.Alchemy/test.20060202/root/ rw >console=ttyS0,115200 > >-> I have cut out the rest for brevity <- > >So there can be two things: > > a) You forgot to start the loaded kernel. (this I can't tell > from your output, so please make it more verbose) > > b) Can it be that you have disabled CONFIG_PRINTK in the kernel > configuration??? > >-- >$ cat ~/.signature >Freddy Spierenburg http://freddy.snarl.nl/ >GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 >$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! ><< signature.asc >> _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From hvr@gnu.org Thu May 4 10:27:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 10:28:06 +0100 (BST) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:44493 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S8133560AbWEDJ1l (ORCPT ); Thu, 4 May 2006 10:27:41 +0100 Received: from mini.intra (dhcp-1432-30.blizz.at [213.143.126.4]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k449RCgS021082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 May 2006 11:27:12 +0200 Subject: RFC: new WIP version of au1000_eth.c phylib conversion (was Re: RFC: au1000_etc.c phylib rewrite) From: Herbert Valerio Riedel To: Mark Schank Cc: ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com, netdev@vger.kernel.org, Ralf Baechle , "Robin H. Johnson" In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <1146674056.31241.18.camel@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gG6GUuD/D7Sog08cBLNj" Organization: Free Software Foundation Date: Thu, 04 May 2006 11:17:03 +0200 Message-Id: <1146734223.31241.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: ClamAV 0.88.1/1439/Thu May 4 09:33:29 2006 on phobos.hvrlab.org X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips --=-gG6GUuD/D7Sog08cBLNj Content-Type: multipart/mixed; boundary="=-7NBnvUkjbxuQTR5LDyMk" --=-7NBnvUkjbxuQTR5LDyMk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I've tried to adapt the PHY detection code to allow for dynamic runtime configuration (with fallback to search for the 2nd MAC PHY on the 1st MAC's MII bus), as well as selectable static PHY configuration through Kconfig (e.g. for supporting PHYs w/o MII connection) e.g. for a MIPS BOSPORUS board, one would set something like through Kconfig (haven't bothered yet, to autoselect this when MIPS_BOSPORUS is defined): CONFIG_MIPS_AU1X00_ENET=3Dy CONFIG_MIPS_AU1X00_ENET_STATIC_PHY_CONFIG=3Dy CONFIG_MIPS_AU1X00_ENET_ETH0_PHY_ADDR=3D5 CONFIG_MIPS_AU1X00_ENET_ETH1_PHY_ON_MAC0=3Dy CONFIG_MIPS_AU1X00_ENET_ETH1_PHY_ADDR=3D-1 the default dynamic runtime PHY search behaviour is now to find the lowest phy_addr containing a living PHY (which is not already claimed by another MAC) on the MAC's current MII bus, and if not found, try again on the first MAC's MII bus; and if that also fails eth initialization fails for the given MAC; ...well, if anyone has the time and hardware, testing would be greatly welcomed :-) alas, this patch is rather big and I'd like to split it into smaller pieces, but imho it's an 'all or nothing' thing to convert to the PHY lib... :-/ Kconfig | 31 + au1000_eth.c | 1494 ++++++++++--------------------------------------------= ----- au1000_eth.h | 132 ----- 3 files changed, 310 insertions(+), 1347 deletions(-) regards, hvr --=-7NBnvUkjbxuQTR5LDyMk Content-Disposition: attachment; filename=au1000_eth_phylib_conversion.patch Content-Type: text/x-patch; name=au1000_eth_phylib_conversion.patch; charset=UTF-8 Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L0tjb25maWcgYi9kcml2ZXJzL25ldC9LY29uZmlnDQpp bmRleCAxZWRjYzBjLi41ODhkZGFkIDEwMDY0NA0KLS0tIGEvZHJpdmVycy9uZXQvS2NvbmZpZw0K KysrIGIvZHJpdmVycy9uZXQvS2NvbmZpZw0KQEAgLTQ1NSwxMSArNDU1LDQyIEBAIGNvbmZpZyBN SVBTX0dUOTYxMDBFVEgNCiBjb25maWcgTUlQU19BVTFYMDBfRU5FVA0KIAlib29sICJNSVBTIEFV MTAwMCBFdGhlcm5ldCBzdXBwb3J0Ig0KIAlkZXBlbmRzIG9uIE5FVF9FVEhFUk5FVCAmJiBTT0Nf QVUxWDAwDQorCXNlbGVjdCBQSFlMSUINCiAJc2VsZWN0IENSQzMyDQogCWhlbHANCiAJICBJZiB5 b3UgaGF2ZSBhbiBBbGNoZW15IFNlbWkgQVUxWDAwIGJhc2VkIHN5c3RlbQ0KIAkgIHNheSBZLiAg T3RoZXJ3aXNlLCBzYXkgTi4NCiANCitjb25maWcgTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZ X0NPTkZJRw0KKwlib29sICJTdGF0aWMgUEhZIGNvbmZpZ3VyYXRpb24iDQorCWRlcGVuZHMgb24g TUlQU19BVTFYMDBfRU5FVA0KKwlkZWZhdWx0IG4NCisJaGVscA0KKwkgIFNheSBZIGlmIHlvdSBu ZWVkIHRvIHNldCBhIHN0YXRpYyBQSFkgY29uZmlndXJhdGlvbi4gSWYgeW91IHNheSBOLCB0aGUN CisJICBkcml2ZXIgd2lsbCB0cnkgdG8gYXV0b2RldGVjdCB0aGUgUEhZIGNvbmZpZ3VyYXRpb24u DQorDQorY29uZmlnIE1JUFNfQVUxWDAwX0VORVRfRVRIMF9QSFlfQUREUg0KKwlpbnQgIjFzdCBF dGhlcm5ldCdzIFBIWSBhZGRyZXNzIHstMSwwLi4zMX0iDQorCWRlcGVuZHMgb24gTUlQU19BVTFY MDBfRU5FVF9TVEFUSUNfUEhZX0NPTkZJRw0KKwloZWxwDQorCSAgUHJvdmlkZSB0aGUgUEhZIGFk ZHJlc3Mgb2YgdGhlIGZpcnN0IER0aGVybmV0IGRldmljZS4gDQorCSAgSWYgdGhlIFBIWSBoYXMg bm8gUEhZIGFkZHJlc3MsIHNheSAiLTEiLg0KKw0KK2NvbmZpZyBNSVBTX0FVMVgwMF9FTkVUX0VU SDFfUEhZX09OX01BQzANCisJYm9vbCAiMm5kIEV0aGVybmV0J3MgUEhZIGlzIGF0dGFjaGVkIHRv IDFzdCBNQUMiDQorCWRlcGVuZHMgb24gTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZX0NPTkZJ Rw0KKwlkZWZhdWx0IG4NCisJaGVscA0KKwkgIFNheSBZIGhlcmUsIGlmIHRoZSBzZWNvbmQgRXRo ZXJuZXQncyBQSFkgaXMgYXR0YWNoZWQgdG8gDQorCSAgdGhlIE1JSSBidXMgb2YgdGhlIGZpcnN0 IE1BQy4NCisNCitjb25maWcgTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9BRERSDQorCWludCAi Mm5kIEV0aGVybmV0J3MgUEhZIGFkZHJlc3Mgey0xLDAuLjMxfSINCisJZGVwZW5kcyBvbiBNSVBT X0FVMVgwMF9FTkVUX1NUQVRJQ19QSFlfQ09ORklHDQorCWhlbHANCisJICBQcm92aWRlIHRoZSBQ SFkgYWRkcmVzcyBvZiB0aGUgc2Vjb25kIEV0aGVybmV0IGRldmljZS4gDQorCSAgSWYgdGhlIFBI WSBoYXMgbm8gUEhZIGFkZHJlc3MsIHNheSAiLTEiLg0KKw0KIGNvbmZpZyBTR0lfSU9DM19FVEgN CiAJYm9vbCAiU0dJIElPQzMgRXRoZXJuZXQiDQogCWRlcGVuZHMgb24gTkVUX0VUSEVSTkVUICYm IFBDSSAmJiBTR0lfSVAyNw0KZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguYyBi L2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguYw0KaW5kZXggMDgyM2NiOC4uOGMwYjI2ZiAxMDA2NDQN Ci0tLSBhL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguYw0KKysrIGIvZHJpdmVycy9uZXQvYXUxMDAw X2V0aC5jDQpAQCAtOSw2ICs5LDkgQEANCiAgKiBVcGRhdGU6IDIwMDQgQmpvZXJuIFJpZW1lciwg cmllbWVyQGZva3VzLmZyYXVuaG9mZXIuZGUgDQogICogb3IgcmllbWVyQHJpZW1lci1udC5kZTog Zml4ZWQgdGhlIGxpbmsgYmVhdCBkZXRlY3Rpb24gd2l0aCANCiAgKiBpb2N0bHMgKFNJT0NHTUlJ UEhZKQ0KKyAqIENvcHlyaWdodCAyMDA2IEhlcmJlcnQgVmFsZXJpbyBSaWVkZWwgPGh2ckBnbnUu b3JnPg0KKyAqICBjb252ZXJ0ZWQgdG8gdXNlIGxpbnV4LTIuNi54J3MgUEhZIGZyYW1ld29yayAN CisgKg0KICAqIEF1dGhvcjogTW9udGFWaXN0YSBTb2Z0d2FyZSwgSW5jLg0KICAqICAgICAgICAg CXBwb3BvdkBtdmlzdGEuY29tIG9yIHNvdXJjZUBtdmlzdGEuY29tDQogICoNCkBAIC01Myw2ICs1 Niw3IEBADQogI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5oPg0KICNpbmNsdWRlIDxsaW51eC9kZWxh eS5oPg0KICNpbmNsdWRlIDxsaW51eC9jcmMzMi5oPg0KKyNpbmNsdWRlIDxsaW51eC9waHkuaD4N CiAjaW5jbHVkZSA8YXNtL21pcHNyZWdzLmg+DQogI2luY2x1ZGUgPGFzbS9pcnEuaD4NCiAjaW5j bHVkZSA8YXNtL2lvLmg+DQpAQCAtODgsMTQgKzkyLDEzIEBAIHN0YXRpYyBpbnQgYXUxMDAwX3R4 KHN0cnVjdCBza19idWZmICosIHMNCiBzdGF0aWMgaW50IGF1MTAwMF9yeChzdHJ1Y3QgbmV0X2Rl dmljZSAqKTsNCiBzdGF0aWMgaXJxcmV0dXJuX3QgYXUxMDAwX2ludGVycnVwdChpbnQsIHZvaWQg Kiwgc3RydWN0IHB0X3JlZ3MgKik7DQogc3RhdGljIHZvaWQgYXUxMDAwX3R4X3RpbWVvdXQoc3Ry dWN0IG5ldF9kZXZpY2UgKik7DQotc3RhdGljIGludCBhdTEwMDBfc2V0X2NvbmZpZyhzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZtYXAgKm1hcCk7DQogc3RhdGljIHZvaWQgc2V0X3J4 X21vZGUoc3RydWN0IG5ldF9kZXZpY2UgKik7DQogc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0 YXRzICphdTEwMDBfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICopOw0KLXN0YXRpYyB2b2lk IGF1MTAwMF90aW1lcih1bnNpZ25lZCBsb25nKTsNCiBzdGF0aWMgaW50IGF1MTAwMF9pb2N0bChz dHJ1Y3QgbmV0X2RldmljZSAqLCBzdHJ1Y3QgaWZyZXEgKiwgaW50KTsNCiBzdGF0aWMgaW50IG1k aW9fcmVhZChzdHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQsIGludCk7DQogc3RhdGljIHZvaWQgbWRp b193cml0ZShzdHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQsIGludCwgdTE2KTsNCi1zdGF0aWMgdm9p ZCBkdW1wX21paShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2lkKTsNCitzdGF0aWMg dm9pZCBhdTEwMDBfYWRqdXN0X2xpbmsoc3RydWN0IG5ldF9kZXZpY2UgKik7DQorc3RhdGljIHZv aWQgZW5hYmxlX21hYyhzdHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQpOw0KIA0KIC8vIGV4dGVybnMN CiBleHRlcm4gIHZvaWQgYWNrX3Jpc2VfZWRnZV9pcnEodW5zaWduZWQgaW50KTsNCkBAIC0xMzUs Njk2ICsxMzgsMTQgQEAgc3RhdGljIHVuc2lnbmVkIGNoYXIgYXUxMDAwX21hY19hZGRyWzZdIA0K IA0KIHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVfbWFjc1tOVU1fRVRIX0lOVEVSRkFDRVNdOw0K IA0KLS8qIEZJWE1FIA0KLSAqIEFsbCBvZiB0aGUgUEhZIGNvZGUgcmVhbGx5IHNob3VsZCBiZSBk ZXRhY2hlZCBmcm9tIHRoZSBNQUMgDQotICogY29kZS4NCi0gKi8NCi0NCi0vKiBEZWZhdWx0IGFk dmVydGlzZSAqLw0KLSNkZWZpbmUgR0VOTUlJX0RFRkFVTFRfQURWRVJUSVNFIFwNCi0JQURWRVJU SVNFRF8xMGJhc2VUX0hhbGYgfCBBRFZFUlRJU0VEXzEwYmFzZVRfRnVsbCB8IFwNCi0JQURWRVJU SVNFRF8xMDBiYXNlVF9IYWxmIHwgQURWRVJUSVNFRF8xMDBiYXNlVF9GdWxsIHwgXA0KLQlBRFZF UlRJU0VEX0F1dG9uZWcNCi0NCi0jZGVmaW5lIEdFTk1JSV9ERUZBVUxUX0ZFQVRVUkVTIFwNCi0J U1VQUE9SVEVEXzEwYmFzZVRfSGFsZiB8IFNVUFBPUlRFRF8xMGJhc2VUX0Z1bGwgfCBcDQotCVNV UFBPUlRFRF8xMDBiYXNlVF9IYWxmIHwgU1VQUE9SVEVEXzEwMGJhc2VUX0Z1bGwgfCBcDQotCVNV UFBPUlRFRF9BdXRvbmVnDQotDQotaW50IGJjbV81MjAxX2luaXQoc3RydWN0IG5ldF9kZXZpY2Ug KmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IGRhdGE7DQotCQ0KLQkvKiBTdG9wIGF1dG8t bmVnb3RpYXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09O VFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEgJiB+ TUlJX0NOVExfQVVUTyk7DQotDQotCS8qIFNldCBhZHZlcnRpc2VtZW50IHRvIDEwLzEwMCBhbmQg SGFsZi9GdWxsIGR1cGxleA0KLQkgKiAoZnVsbCBjYXBhYmlsaXRpZXMpICovDQotCWRhdGEgPSBt ZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0FOQURWKTsNCi0JZGF0YSB8PSBNSUlfTldBWV9U WCB8IE1JSV9OV0FZX1RYX0ZEWCB8IE1JSV9OV0FZX1RfRkRYIHwgTUlJX05XQVlfVDsNCi0JbWRp b193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYsIGRhdGEpOw0KLQkNCi0JLyogUmVzdGFy dCBhdXRvLW5lZ290aWF0aW9uICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQlkYXRhIHw9IE1JSV9DTlRMX1JTVF9BVVRPIHwgTUlJX0NOVExfQVVU TzsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSk7DQotDQot CWlmIChhdTEwMDBfZGVidWcgPiA0KSANCi0JCWR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQly ZXR1cm4gMDsNCi19DQotDQotaW50IGJjbV81MjAxX3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMxNiBtaWlfY29udHJvbCwgdGltZW91dDsNCi0JDQot CW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0J bWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgbWlpX2NvbnRyb2wgfCBNSUlf Q05UTF9SRVNFVCk7DQotCW1kZWxheSgxKTsNCi0JZm9yICh0aW1lb3V0ID0gMTAwOyB0aW1lb3V0 ID4gMDsgLS10aW1lb3V0KSB7DQotCQltaWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9h ZGRyLCBNSUlfQ09OVFJPTCk7DQotCQlpZiAoKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQp ID09IDApDQotCQkJYnJlYWs7DQotCQltZGVsYXkoMSk7DQotCX0NCi0JaWYgKG1paV9jb250cm9s ICYgTUlJX0NOVExfUkVTRVQpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAiJXMgUEhZIHJlc2V0IHRp bWVvdXQgIVxuIiwgZGV2LT5uYW1lKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQlyZXR1cm4gMDsN Ci19DQotDQotaW50IA0KLWJjbV81MjAxX3N0YXR1cyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBp bnQgcGh5X2FkZHIsIHUxNiAqbGluaywgdTE2ICpzcGVlZCkNCi17DQotCXUxNiBtaWlfZGF0YTsN Ci0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXA7DQotDQotCWlmICghZGV2KSB7DQotCQlwcmlu dGsoS0VSTl9FUlIgImJjbV81MjAxX3N0YXR1cyBlcnJvcjogTlVMTCBkZXZcbiIpOw0KLQkJcmV0 dXJuIC0xOw0KLQl9DQotCWF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2 Ow0KLQ0KLQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9TVEFU VVMpOw0KLQlpZiAobWlpX2RhdGEgJiBNSUlfU1RBVF9MSU5LKSB7DQotCQkqbGluayA9IDE7DQot CQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9BVVhfQ05UUkwp Ow0KLQkJaWYgKG1paV9kYXRhICYgTUlJX0FVWF8xMDApIHsNCi0JCQlpZiAobWlpX2RhdGEgJiBN SUlfQVVYX0ZEWCkgew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQkJZGV2 LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJfQ0KLQkJCWVsc2Ugew0KLQkJCQkq c3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8x MDBCQVNFVFg7DQotCQkJfQ0KLQkJfQ0KLQkJZWxzZSAgew0KLQkJCSpzcGVlZCA9IElGX1BPUlRf MTBCQVNFVDsNCi0JCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQl9DQotDQot CX0NCi0JZWxzZSB7DQotCQkqbGluayA9IDA7DQotCQkqc3BlZWQgPSAwOw0KLQkJZGV2LT5pZl9w b3J0ID0gSUZfUE9SVF9VTktOT1dOOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgbHNp XzgwMjI3X2luaXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0J aWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQotCQlwcmludGsoImxzaV84MDIyN19pbml0XG4iKTsNCi0N Ci0JLyogcmVzdGFydCBhdXRvLW5lZ290aWF0aW9uICovDQotCW1kaW9fd3JpdGUoZGV2LCBwaHlf YWRkciwgTUlJX0NPTlRST0wsDQotCQkgICBNSUlfQ05UTF9GMTAwIHwgTUlJX0NOVExfQVVUTyB8 IE1JSV9DTlRMX1JTVF9BVVRPKTsgLy8gfCBNSUlfQ05UTF9GRFgpOw0KLQltZGVsYXkoMSk7DQot DQotCS8qIHNldCB1cCBMRURzIHRvIGNvcnJlY3QgZGlzcGxheSAqLw0KLSNpZmRlZiBDT05GSUdf TUlQU19NVFgxDQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgMTcsIDB4ZmY4MCk7DQotI2Vs c2UNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCAxNywgMHhmZmMwKTsNCi0jZW5kaWYNCi0N Ci0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQotCQlkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0J cmV0dXJuIDA7DQotfQ0KLQ0KLWludCBsc2lfODAyMjdfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2Ug KmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IG1paV9jb250cm9sLCB0aW1lb3V0Ow0KLQkN Ci0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpIHsNCi0JCXByaW50aygibHNpXzgwMjI3X3Jlc2V0XG4i KTsNCi0JCWR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQl9DQotDQotCW1paV9jb250cm9sID0g bWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYs IHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgbWlpX2NvbnRyb2wgfCBNSUlfQ05UTF9SRVNFVCk7DQot CW1kZWxheSgxKTsNCi0JZm9yICh0aW1lb3V0ID0gMTAwOyB0aW1lb3V0ID4gMDsgLS10aW1lb3V0 KSB7DQotCQltaWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJP TCk7DQotCQlpZiAoKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpID09IDApDQotCQkJYnJl YWs7DQotCQltZGVsYXkoMSk7DQotCX0NCi0JaWYgKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVT RVQpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAiJXMgUEhZIHJlc2V0IHRpbWVvdXQgIVxuIiwgZGV2 LT5uYW1lKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50DQot bHNpXzgwMjI3X3N0YXR1cyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUx NiAqbGluaywgdTE2ICpzcGVlZCkNCi17DQotCXUxNiBtaWlfZGF0YTsNCi0Jc3RydWN0IGF1MTAw MF9wcml2YXRlICphdXA7DQotDQotCWlmICghZGV2KSB7DQotCQlwcmludGsoS0VSTl9FUlIgImxz aV84MDIyN19zdGF0dXMgZXJyb3I6IE5VTEwgZGV2XG4iKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0K LQlhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0NCi0JbWlpX2Rh dGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfU1RBVFVTKTsNCi0JaWYgKG1p aV9kYXRhICYgTUlJX1NUQVRfTElOSykgew0KLQkJKmxpbmsgPSAxOw0KLQkJbWlpX2RhdGEgPSBt ZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfTFNJX1BIWV9TVEFUKTsNCi0JCWlmICht aWlfZGF0YSAmIE1JSV9MU0lfUEhZX1NUQVRfU1BEKSB7DQotCQkJaWYgKG1paV9kYXRhICYgTUlJ X0xTSV9QSFlfU1RBVF9GRFgpIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQot CQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCX0NCi0JCQllbHNlIHsN Ci0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElG X1BPUlRfMTAwQkFTRVRYOw0KLQkJCX0NCi0JCX0NCi0JCWVsc2UgIHsNCi0JCQkqc3BlZWQgPSBJ Rl9QT1JUXzEwQkFTRVQ7DQotCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJ fQ0KLQ0KLQl9DQotCWVsc2Ugew0KLQkJKmxpbmsgPSAwOw0KLQkJKnNwZWVkID0gMDsNCi0JCWRl di0+aWZfcG9ydCA9IElGX1BPUlRfVU5LTk9XTjsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQot aW50IGFtNzljOTAxX2luaXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0K LXsNCi0JcHJpbnRrKCJhbTc5YzkwMV9pbml0XG4iKTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWlu dCBhbTc5YzkwMV9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQot ew0KLQlwcmludGsoImFtNzljOTAxX3Jlc2V0XG4iKTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWlu dCANCi1hbTc5YzkwMV9zdGF0dXMoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRy LCB1MTYgKmxpbmssIHUxNiAqc3BlZWQpDQotew0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGFt NzljODc0X2luaXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0J czE2IGRhdGE7DQotDQotCS8qIDc5Yzg3NCBoYXMgcXVpdCByZXNlbWJsZWQgYml0IGFzc2lnbm1l bnRzIHRvIEJDTTUyMDEgKi8NCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQotCQlwcmludGsoImFt NzljODQ3X2luaXRcbiIpOw0KLQ0KLQkvKiBTdG9wIGF1dG8tbmVnb3RpYXRpb24gKi8NCi0JZGF0 YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUo ZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEgJiB+TUlJX0NOVExfQVVUTyk7DQotDQot CS8qIFNldCBhZHZlcnRpc2VtZW50IHRvIDEwLzEwMCBhbmQgSGFsZi9GdWxsIGR1cGxleA0KLQkg KiAoZnVsbCBjYXBhYmlsaXRpZXMpICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRk ciwgTUlJX0FOQURWKTsNCi0JZGF0YSB8PSBNSUlfTldBWV9UWCB8IE1JSV9OV0FZX1RYX0ZEWCB8 IE1JSV9OV0FZX1RfRkRYIHwgTUlJX05XQVlfVDsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRy LCBNSUlfQU5BRFYsIGRhdGEpOw0KLQkNCi0JLyogUmVzdGFydCBhdXRvLW5lZ290aWF0aW9uICov DQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQlkYXRh IHw9IE1JSV9DTlRMX1JTVF9BVVRPIHwgTUlJX0NOVExfQVVUTzsNCi0NCi0JbWRpb193cml0ZShk ZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSk7DQotDQotCWlmIChhdTEwMDBfZGVidWcg PiA0KSBkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBh bTc5Yzg3NF9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0K LQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVvdXQ7DQotCQ0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkN Ci0JCXByaW50aygiYW03OWM4NzRfcmVzZXRcbiIpOw0KLQ0KLQltaWlfY29udHJvbCA9IG1kaW9f cmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlf YWRkciwgTUlJX0NPTlRST0wsIG1paV9jb250cm9sIHwgTUlJX0NOVExfUkVTRVQpOw0KLQltZGVs YXkoMSk7DQotCWZvciAodGltZW91dCA9IDEwMDsgdGltZW91dCA+IDA7IC0tdGltZW91dCkgew0K LQkJbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0K LQkJaWYgKChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSA9PSAwKQ0KLQkJCWJyZWFrOw0K LQkJbWRlbGF5KDEpOw0KLQl9DQotCWlmIChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSB7 DQotCQlwcmludGsoS0VSTl9FUlIgIiVzIFBIWSByZXNldCB0aW1lb3V0ICFcbiIsIGRldi0+bmFt ZSk7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCANCi1hbTc5 Yzg3NF9zdGF0dXMoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxp bmssIHUxNiAqc3BlZWQpDQotew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0cnVjdCBhdTEwMDBfcHJp dmF0ZSAqYXVwOw0KLQ0KLQkvLyBwcmludGsoImFtNzljODc0X3N0YXR1c1xuIik7DQotCWlmICgh ZGV2KSB7DQotCQlwcmludGsoS0VSTl9FUlIgImFtNzljODc0X3N0YXR1cyBlcnJvcjogTlVMTCBk ZXZcbiIpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotDQotCWF1cCA9IChzdHJ1Y3QgYXUxMDAwX3By aXZhdGUgKikgZGV2LT5wcml2Ow0KLQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5 X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQ0KLQlpZiAobWlpX2RhdGEgJiBNSUlfU1RBVF9MSU5LKSB7 DQotCQkqbGluayA9IDE7DQotCQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2Fk ZHIsIE1JSV9BTURfUEhZX1NUQVQpOw0KLQkJaWYgKG1paV9kYXRhICYgTUlJX0FNRF9QSFlfU1RB VF9TUEQpIHsNCi0JCQlpZiAobWlpX2RhdGEgJiBNSUlfQU1EX1BIWV9TVEFUX0ZEWCkgew0KLQkJ CQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9S VF8xMDBCQVNFRlg7DQotCQkJfQ0KLQkJCWVsc2Ugew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEw MEJBU0VUWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJfQ0K LQkJfQ0KLQkJZWxzZSB7DQotCQkJKnNwZWVkID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJCWRldi0+ aWZfcG9ydCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCX0NCi0NCi0JfQ0KLQllbHNlIHsNCi0JCSps aW5rID0gMDsNCi0JCSpzcGVlZCA9IDA7DQotCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUX1VOS05P V047DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBseHQ5NzFhX2luaXQoc3RydWN0IG5l dF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQp DQotCQlwcmludGsoImx4dDk3MWFfaW5pdFxuIik7DQotDQotCS8qIHJlc3RhcnQgYXV0by1uZWdv dGlhdGlvbiAqLw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLA0KLQkJ ICAgTUlJX0NOVExfRjEwMCB8IE1JSV9DTlRMX0FVVE8gfCBNSUlfQ05UTF9SU1RfQVVUTyB8IE1J SV9DTlRMX0ZEWCk7DQotDQotCS8qIHNldCB1cCBMRURzIHRvIGNvcnJlY3QgZGlzcGxheSAqLw0K LQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIDIwLCAweDA0MjIpOw0KLQ0KLQlpZiAoYXUxMDAw X2RlYnVnID4gNCkNCi0JCWR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQlyZXR1cm4gMDsNCi19 DQotDQotaW50IGx4dDk3MWFfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9h ZGRyKQ0KLXsNCi0JczE2IG1paV9jb250cm9sLCB0aW1lb3V0Ow0KLQkNCi0JaWYgKGF1MTAwMF9k ZWJ1ZyA+IDQpIHsNCi0JCXByaW50aygibHh0OTcxYV9yZXNldFxuIik7DQotCQlkdW1wX21paShk ZXYsIHBoeV9hZGRyKTsNCi0JfQ0KLQ0KLQltaWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBo eV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NP TlRST0wsIG1paV9jb250cm9sIHwgTUlJX0NOVExfUkVTRVQpOw0KLQltZGVsYXkoMSk7DQotCWZv ciAodGltZW91dCA9IDEwMDsgdGltZW91dCA+IDA7IC0tdGltZW91dCkgew0KLQkJbWlpX2NvbnRy b2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJaWYgKChtaWlf Y29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSA9PSAwKQ0KLQkJCWJyZWFrOw0KLQkJbWRlbGF5KDEp Ow0KLQl9DQotCWlmIChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSB7DQotCQlwcmludGso S0VSTl9FUlIgIiVzIFBIWSByZXNldCB0aW1lb3V0ICFcbiIsIGRldi0+bmFtZSk7DQotCQlyZXR1 cm4gLTE7DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludA0KLWx4dDk3MWFfc3RhdHVzKHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICpsaW5rLCB1MTYgKnNwZWVk KQ0KLXsNCi0JdTE2IG1paV9kYXRhOw0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cDsNCi0N Ci0JaWYgKCFkZXYpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAibHh0OTcxYV9zdGF0dXMgZXJyb3I6 IE5VTEwgZGV2XG4iKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQlhdXAgPSAoc3RydWN0IGF1MTAw MF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0NCi0JbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBh dXAtPnBoeV9hZGRyLCBNSUlfU1RBVFVTKTsNCi0JaWYgKG1paV9kYXRhICYgTUlJX1NUQVRfTElO Sykgew0KLQkJKmxpbmsgPSAxOw0KLQkJbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBo eV9hZGRyLCBNSUlfSU5URUxfUEhZX1NUQVQpOw0KLQkJaWYgKG1paV9kYXRhICYgTUlJX0lOVEVM X1BIWV9TVEFUX1NQRCkgew0KLQkJCWlmIChtaWlfZGF0YSAmIE1JSV9JTlRFTF9QSFlfU1RBVF9G RFgpIHsNCi0JCQkJKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJCWRldi0+aWZfcG9y dCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCX0NCi0JCQllbHNlIHsNCi0JCQkJKnNwZWVkID0g SUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTAwQkFTRVRY Ow0KLQkJCX0NCi0JCX0NCi0JCWVsc2UgIHsNCi0JCQkqc3BlZWQgPSBJRl9QT1JUXzEwQkFTRVQ7 DQotCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJfQ0KLQ0KLQl9DQotCWVs c2Ugew0KLQkJKmxpbmsgPSAwOw0KLQkJKnNwZWVkID0gMDsNCi0JCWRldi0+aWZfcG9ydCA9IElG X1BPUlRfVU5LTk9XTjsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGtzODk5NW1faW5p dChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYgZGF0YTsN Ci0JDQotLy8JcHJpbnRrKCJrczg5OTVtX2luaXRcbiIpOw0KLQkvKiBTdG9wIGF1dG8tbmVnb3Rp YXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7 DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRhdGEgJiB+TUlJX0NO VExfQVVUTyk7DQotDQotCS8qIFNldCBhZHZlcnRpc2VtZW50IHRvIDEwLzEwMCBhbmQgSGFsZi9G dWxsIGR1cGxleA0KLQkgKiAoZnVsbCBjYXBhYmlsaXRpZXMpICovDQotCWRhdGEgPSBtZGlvX3Jl YWQoZGV2LCBwaHlfYWRkciwgTUlJX0FOQURWKTsNCi0JZGF0YSB8PSBNSUlfTldBWV9UWCB8IE1J SV9OV0FZX1RYX0ZEWCB8IE1JSV9OV0FZX1RfRkRYIHwgTUlJX05XQVlfVDsNCi0JbWRpb193cml0 ZShkZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYsIGRhdGEpOw0KLQkNCi0JLyogUmVzdGFydCBhdXRv LW5lZ290aWF0aW9uICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NP TlRST0wpOw0KLQlkYXRhIHw9IE1JSV9DTlRMX1JTVF9BVVRPIHwgTUlJX0NOVExfQVVUTzsNCi0J bWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSk7DQotDQotCWlmIChh dTEwMDBfZGVidWcgPiA0KSBkdW1wX21paShkZXYsIHBoeV9hZGRyKTsNCi0NCi0JcmV0dXJuIDA7 DQotfQ0KLQ0KLWludCBrczg5OTVtX3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBw aHlfYWRkcikNCi17DQotCXMxNiBtaWlfY29udHJvbCwgdGltZW91dDsNCi0JDQotLy8JcHJpbnRr KCJrczg5OTVtX3Jlc2V0XG4iKTsNCi0JbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlf YWRkciwgTUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05U Uk9MLCBtaWlfY29udHJvbCB8IE1JSV9DTlRMX1JFU0VUKTsNCi0JbWRlbGF5KDEpOw0KLQlmb3Ig KHRpbWVvdXQgPSAxMDA7IHRpbWVvdXQgPiAwOyAtLXRpbWVvdXQpIHsNCi0JCW1paV9jb250cm9s ID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCWlmICgobWlpX2Nv bnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgPT0gMCkNCi0JCQlicmVhazsNCi0JCW1kZWxheSgxKTsN Ci0JfQ0KLQlpZiAobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgew0KLQkJcHJpbnRrKEtF Uk5fRVJSICIlcyBQSFkgcmVzZXQgdGltZW91dCAhXG4iLCBkZXYtPm5hbWUpOw0KLQkJcmV0dXJu IC0xOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQga3M4OTk1bV9zdGF0dXMoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxpbmssIHUxNiAqc3BlZWQpDQot ew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwOw0KLQ0KLQlp ZiAoIWRldikgew0KLQkJcHJpbnRrKEtFUk5fRVJSICJrczg5OTVtX3N0YXR1cyBlcnJvcjogTlVM TCBkZXZcbiIpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotCWF1cCA9IChzdHJ1Y3QgYXUxMDAwX3By aXZhdGUgKikgZGV2LT5wcml2Ow0KLQ0KLQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+ cGh5X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQlpZiAobWlpX2RhdGEgJiBNSUlfU1RBVF9MSU5LKSB7 DQotCQkqbGluayA9IDE7DQotCQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2Fk ZHIsIE1JSV9BVVhfQ05UUkwpOw0KLQkJaWYgKG1paV9kYXRhICYgTUlJX0FVWF8xMDApIHsNCi0J CQlpZiAobWlpX2RhdGEgJiBNSUlfQVVYX0ZEWCkgew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEw MEJBU0VGWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJfQ0K LQkJCWVsc2Ugew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQkJZGV2LT5p Zl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJfQ0KLQkJfQ0KLQkJZWxzZSAgewkJCQkJ CQkJCQkJDQotCQkJKnNwZWVkID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJCWRldi0+aWZfcG9ydCA9 IElGX1BPUlRfMTBCQVNFVDsNCi0JCX0NCi0NCi0JfQ0KLQllbHNlIHsNCi0JCSpsaW5rID0gMDsN Ci0JCSpzcGVlZCA9IDA7DQotCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUX1VOS05PV047DQotCX0N Ci0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludA0KLXNtc2NfODNDMTg1X2luaXQgKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMxNiBkYXRhOw0KLQ0KLQlpZiAoYXUx MDAwX2RlYnVnID4gNCkNCi0JCXByaW50aygic21zY184M0MxODVfaW5pdFxuIik7DQotDQotCS8q IFN0b3AgYXV0by1uZWdvdGlhdGlvbiAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2Fk ZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJP TCwgZGF0YSAmIH5NSUlfQ05UTF9BVVRPKTsNCi0NCi0JLyogU2V0IGFkdmVydGlzZW1lbnQgdG8g MTAvMTAwIGFuZCBIYWxmL0Z1bGwgZHVwbGV4DQotCSAqIChmdWxsIGNhcGFiaWxpdGllcykgKi8N Ci0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYpOw0KLQlkYXRhIHw9 IE1JSV9OV0FZX1RYIHwgTUlJX05XQVlfVFhfRkRYIHwgTUlJX05XQVlfVF9GRFggfCBNSUlfTldB WV9UOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9BTkFEViwgZGF0YSk7DQotCQ0K LQkvKiBSZXN0YXJ0IGF1dG8tbmVnb3RpYXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYs IHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCWRhdGEgfD0gTUlJX0NOVExfUlNUX0FVVE8gfCBN SUlfQ05UTF9BVVRPOw0KLQ0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9M LCBkYXRhKTsNCi0NCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpIGR1bXBfbWlpKGRldiwgcGh5X2Fk ZHIpOw0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50DQotc21zY184M0MxODVfcmVzZXQgKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMxNiBtaWlfY29udHJvbCwg dGltZW91dDsNCi0JDQotCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KLQkJcHJpbnRrKCJzbXNjXzgz QzE4NV9yZXNldFxuIik7DQotDQotCW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2Fk ZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJP TCwgbWlpX2NvbnRyb2wgfCBNSUlfQ05UTF9SRVNFVCk7DQotCW1kZWxheSgxKTsNCi0JZm9yICh0 aW1lb3V0ID0gMTAwOyB0aW1lb3V0ID4gMDsgLS10aW1lb3V0KSB7DQotCQltaWlfY29udHJvbCA9 IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCQlpZiAoKG1paV9jb250 cm9sICYgTUlJX0NOVExfUkVTRVQpID09IDApDQotCQkJYnJlYWs7DQotCQltZGVsYXkoMSk7DQot CX0NCi0JaWYgKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpIHsNCi0JCXByaW50ayhLRVJO X0VSUiAiJXMgUEhZIHJlc2V0IHRpbWVvdXQgIVxuIiwgZGV2LT5uYW1lKTsNCi0JCXJldHVybiAt MTsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IA0KLXNtc2NfODNDMTg1X3N0YXR1cyAo c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxpbmssIHUxNiAqc3Bl ZWQpDQotew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwOw0K LQ0KLQlpZiAoIWRldikgew0KLQkJcHJpbnRrKEtFUk5fRVJSICJzbXNjXzgzQzE4NV9zdGF0dXMg ZXJyb3I6IE5VTEwgZGV2XG4iKTsNCi0JCXJldHVybiAtMTsNCi0JfQ0KLQ0KLQlhdXAgPSAoc3Ry dWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0JbWlpX2RhdGEgPSBtZGlvX3JlYWQo ZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfU1RBVFVTKTsNCi0NCi0JaWYgKG1paV9kYXRhICYgTUlJ X1NUQVRfTElOSykgew0KLQkJKmxpbmsgPSAxOw0KLQkJbWlpX2RhdGEgPSBtZGlvX3JlYWQoZGV2 LCBhdXAtPnBoeV9hZGRyLCAweDFmKTsNCi0JCWlmIChtaWlfZGF0YSAmICgxPDwzKSkgew0KLQkJ CWlmIChtaWlfZGF0YSAmICgxPDw0KSkgew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VG WDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJfQ0KLQkJCWVs c2Ugew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQkJZGV2LT5pZl9wb3J0 ID0gSUZfUE9SVF8xMDBCQVNFVFg7DQotCQkJfQ0KLQkJfQ0KLQkJZWxzZSB7DQotCQkJKnNwZWVk ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTBCQVNFVDsN Ci0JCX0NCi0JfQ0KLQllbHNlIHsNCi0JCSpsaW5rID0gMDsNCi0JCSpzcGVlZCA9IDA7DQotCQlk ZXYtPmlmX3BvcnQgPSBJRl9QT1JUX1VOS05PV047DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0K LQ0KLSNpZmRlZiBDT05GSUdfTUlQU19CT1NQT1JVUw0KLWludCBzdHViX2luaXQoc3RydWN0IG5l dF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JLy9wcmludGsoIlBIWSBzdHViX2lu aXRcbiIpOw0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IHN0dWJfcmVzZXQoc3RydWN0IG5ldF9k ZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JLy9wcmludGsoIlBIWSBzdHViX3Jlc2V0 XG4iKTsNCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCANCi1zdHViX3N0YXR1cyhzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUxNiAqbGluaywgdTE2ICpzcGVlZCkNCi17DQot CS8vcHJpbnRrKCJQSFkgc3R1Yl9zdGF0dXNcbiIpOw0KLQkqbGluayA9IDE7DQotCS8qIGhtbW0s IHJldmlzaXQgKi8NCi0JKnNwZWVkID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCWRldi0+aWZfcG9y dCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQlyZXR1cm4gMDsNCi19DQotI2VuZGlmDQotDQotc3Ry dWN0IHBoeV9vcHMgYmNtXzUyMDFfb3BzID0gew0KLQliY21fNTIwMV9pbml0LA0KLQliY21fNTIw MV9yZXNldCwNCi0JYmNtXzUyMDFfc3RhdHVzLA0KLX07DQotDQotc3RydWN0IHBoeV9vcHMgYW03 OWM4NzRfb3BzID0gew0KLQlhbTc5Yzg3NF9pbml0LA0KLQlhbTc5Yzg3NF9yZXNldCwNCi0JYW03 OWM4NzRfc3RhdHVzLA0KLX07DQotDQotc3RydWN0IHBoeV9vcHMgYW03OWM5MDFfb3BzID0gew0K LQlhbTc5YzkwMV9pbml0LA0KLQlhbTc5YzkwMV9yZXNldCwNCi0JYW03OWM5MDFfc3RhdHVzLA0K LX07DQotDQotc3RydWN0IHBoeV9vcHMgbHNpXzgwMjI3X29wcyA9IHsgDQotCWxzaV84MDIyN19p bml0LA0KLQlsc2lfODAyMjdfcmVzZXQsDQotCWxzaV84MDIyN19zdGF0dXMsDQotfTsNCi0NCi1z dHJ1Y3QgcGh5X29wcyBseHQ5NzFhX29wcyA9IHsgDQotCWx4dDk3MWFfaW5pdCwNCi0JbHh0OTcx YV9yZXNldCwNCi0JbHh0OTcxYV9zdGF0dXMsDQotfTsNCi0NCi1zdHJ1Y3QgcGh5X29wcyBrczg5 OTVtX29wcyA9IHsNCi0Ja3M4OTk1bV9pbml0LA0KLQlrczg5OTVtX3Jlc2V0LA0KLQlrczg5OTVt X3N0YXR1cywNCi19Ow0KLQ0KLXN0cnVjdCBwaHlfb3BzIHNtc2NfODNDMTg1X29wcyA9IHsNCi0J c21zY184M0MxODVfaW5pdCwNCi0Jc21zY184M0MxODVfcmVzZXQsDQotCXNtc2NfODNDMTg1X3N0 YXR1cywNCi19Ow0KLQ0KLSNpZmRlZiBDT05GSUdfTUlQU19CT1NQT1JVUw0KLXN0cnVjdCBwaHlf b3BzIHN0dWJfb3BzID0gew0KLQlzdHViX2luaXQsDQotCXN0dWJfcmVzZXQsDQotCXN0dWJfc3Rh dHVzLA0KLX07DQotI2VuZGlmDQotDQotc3RhdGljIHN0cnVjdCBtaWlfY2hpcF9pbmZvIHsNCi0J Y29uc3QgY2hhciAqIG5hbWU7DQotCXUxNiBwaHlfaWQwOw0KLQl1MTYgcGh5X2lkMTsNCi0Jc3Ry dWN0IHBoeV9vcHMgKnBoeV9vcHM7CQ0KLQlpbnQgZHVhbF9waHk7DQotfSBtaWlfY2hpcF90YWJs ZVtdID0gew0KLQl7IkJyb2FkY29tIEJDTTUyMDEgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDQwLDB4 NjIxMiwgJmJjbV81MjAxX29wcywwfSwNCi0JeyJCcm9hZGNvbSBCQ001MjIxIDEwLzEwMCBCYXNl VCBQSFkiLDB4MDA0MCwweDYxZTQsICZiY21fNTIwMV9vcHMsMH0sDQotCXsiQnJvYWRjb20gQkNN NTIyMiAxMC8xMDAgQmFzZVQgUEhZIiwweDAwNDAsMHg2MzIyLCAmYmNtXzUyMDFfb3BzLDF9LA0K LQl7Ik5TIERQODM4NDcgUEhZIiwgMHgyMDAwLCAweDVjMzAsICZiY21fNTIwMV9vcHMgLDB9LA0K LQl7IkFNRCA3OUM5MDEgSG9tZVBOQSBQSFkiLDB4MDAwMCwweDM1YzgsICZhbTc5YzkwMV9vcHMs MH0sDQotCXsiQU1EIDc5Qzg3NCAxMC8xMDAgQmFzZVQgUEhZIiwweDAwMjIsMHg1NjFiLCAmYW03 OWM4NzRfb3BzLDB9LA0KLQl7IkxTSSA4MDIyNyAxMC8xMDAgQmFzZVQgUEhZIiwweDAwMTYsMHhm ODQwLCAmbHNpXzgwMjI3X29wcywwfSwNCi0JeyJJbnRlbCBMWFQ5NzFBIER1YWwgU3BlZWQgUEhZ IiwweDAwMTMsMHg3OGUyLCAmbHh0OTcxYV9vcHMsMH0sDQotCXsiS2VuZGluIEtTODk5NU0gMTAv MTAwIEJhc2VUIFBIWSIsMHgwMDIyLDB4MTQ1MCwgJmtzODk5NW1fb3BzLDB9LA0KLQl7IlNNU0Mg TEFOODNDMTg1IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAwNywweGMwYTMsICZzbXNjXzgzQzE4NV9v cHMsMH0sDQotI2lmZGVmIENPTkZJR19NSVBTX0JPU1BPUlVTDQotCXsiU3R1YiIsIDB4MTIzNCwg MHg1Njc4LCAmc3R1Yl9vcHMgfSwNCi0jZW5kaWYNCi0JezAsfSwNCi19Ow0KLQ0KLXN0YXRpYyBp bnQgbWRpb19yZWFkKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQsIGludCByZWcp DQorc3RhdGljIGludCBtZGlvX3JlYWQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9h ZGRyLCBpbnQgcmVnKQ0KIHsNCiAJc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0 IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0Jdm9sYXRpbGUgdTMyICptaWlfY29udHJv bF9yZWc7DQotCXZvbGF0aWxlIHUzMiAqbWlpX2RhdGFfcmVnOw0KKwl2b2xhdGlsZSB1MzIgKmNv bnN0IG1paV9jb250cm9sX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2NvbnRyb2w7DQorCXZvbGF0aWxl IHUzMiAqY29uc3QgbWlpX2RhdGFfcmVnID0gJmF1cC0+bWFjLT5taWlfZGF0YTsNCiAJdTMyIHRp bWVkb3V0ID0gMjA7DQogCXUzMiBtaWlfY29udHJvbDsNCiANCi0JI2lmZGVmIENPTkZJR19CQ001 MjIyX0RVQUxfUEhZDQotCS8qIEZpcnN0IHRpbWUgd2UgcHJvYmUsIGl0J3MgZm9yIHRoZSBtYWMw IHBoeS4NCi0JICogU2luY2Ugd2UgaGF2ZW4ndCBkZXRlcm1pbmVkIHlldCB0aGF0IHdlIGhhdmUg YSBkdWFsIHBoeSwNCi0JICogYXVwLT5taWktPm1paV9jb250cm9sX3JlZyB3b24ndCBiZSBzZXR1 cCBhbmQgd2UnbGwNCi0JICogZGVmYXVsdCB0byB0aGUgZWxzZSBzdGF0ZW1lbnQuDQotCSAqIEJ5 IHRoZSB0aW1lIHdlIHByb2JlIGZvciB0aGUgbWFjMSBwaHksIHRoZSBtaWlfY29udHJvbF9yZWcN Ci0JICogd2lsbCBiZSBzZXR1cCB0byBiZSB0aGUgYWRkcmVzcyBvZiB0aGUgbWFjMCBwaHkgY29u dHJvbCBzaW5jZQ0KLQkgKiBib3RoIHBoeXMgYXJlIGNvbnRyb2xsZWQgdGhyb3VnaCBtYWMwLg0K LQkgKi8NCi0JaWYgKGF1cC0+bWlpICYmIGF1cC0+bWlpLT5taWlfY29udHJvbF9yZWcpIHsNCi0J CW1paV9jb250cm9sX3JlZyA9IGF1cC0+bWlpLT5taWlfY29udHJvbF9yZWc7DQotCQltaWlfZGF0 YV9yZWcgPSBhdXAtPm1paS0+bWlpX2RhdGFfcmVnOw0KLQl9DQotCWVsc2UgaWYgKGF1X21hY3Nb MF0tPm1paSAmJiBhdV9tYWNzWzBdLT5taWktPm1paV9jb250cm9sX3JlZykgew0KLQkJLyogYXNz dW1lIGJvdGggcGh5cyBhcmUgY29udHJvbGxlZCB0aHJvdWdoIG1hYzAgKi8NCi0JCW1paV9jb250 cm9sX3JlZyA9IGF1X21hY3NbMF0tPm1paS0+bWlpX2NvbnRyb2xfcmVnOw0KLQkJbWlpX2RhdGFf cmVnID0gYXVfbWFjc1swXS0+bWlpLT5taWlfZGF0YV9yZWc7DQotCX0NCi0JZWxzZSANCi0JI2Vu ZGlmDQotCXsNCi0JCS8qIGRlZmF1bHQgY29udHJvbCBhbmQgZGF0YSByZWcgYWRkcmVzc2VzICov DQotCQltaWlfY29udHJvbF9yZWcgPSAmYXVwLT5tYWMtPm1paV9jb250cm9sOw0KLQkJbWlpX2Rh dGFfcmVnID0gJmF1cC0+bWFjLT5taWlfZGF0YTsNCi0JfQ0KLQ0KIAl3aGlsZSAoKm1paV9jb250 cm9sX3JlZyAmIE1BQ19NSUlfQlVTWSkgew0KIAkJbWRlbGF5KDEpOw0KIAkJaWYgKC0tdGltZWRv dXQgPT0gMCkgew0KQEAgLTgzNSw3ICsxNTYsNyBAQCBzdGF0aWMgaW50IG1kaW9fcmVhZChzdHJ1 Y3QgbmV0X2RldmljZSAqDQogCX0NCiANCiAJbWlpX2NvbnRyb2wgPSBNQUNfU0VUX01JSV9TRUxF Q1RfUkVHKHJlZykgfCANCi0JCU1BQ19TRVRfTUlJX1NFTEVDVF9QSFkocGh5X2lkKSB8IE1BQ19N SUlfUkVBRDsNCisJCU1BQ19TRVRfTUlJX1NFTEVDVF9QSFkocGh5X2FkZHIpIHwgTUFDX01JSV9S RUFEOw0KIA0KIAkqbWlpX2NvbnRyb2xfcmVnID0gbWlpX2NvbnRyb2w7DQogDQpAQCAtODUxLDMy ICsxNzIsMTQgQEAgc3RhdGljIGludCBtZGlvX3JlYWQoc3RydWN0IG5ldF9kZXZpY2UgKg0KIAly ZXR1cm4gKGludCkqbWlpX2RhdGFfcmVnOw0KIH0NCiANCi1zdGF0aWMgdm9pZCBtZGlvX3dyaXRl KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQsIGludCByZWcsIHUxNiB2YWx1ZSkN CitzdGF0aWMgdm9pZCBtZGlvX3dyaXRlKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlf YWRkciwgaW50IHJlZywgdTE2IHZhbHVlKQ0KIHsNCiAJc3RydWN0IGF1MTAwMF9wcml2YXRlICph dXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCi0Jdm9sYXRpbGUgdTMy ICptaWlfY29udHJvbF9yZWc7DQotCXZvbGF0aWxlIHUzMiAqbWlpX2RhdGFfcmVnOw0KKwl2b2xh dGlsZSB1MzIgKmNvbnN0IG1paV9jb250cm9sX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2NvbnRyb2w7 DQorCXZvbGF0aWxlIHUzMiAqY29uc3QgbWlpX2RhdGFfcmVnID0gJmF1cC0+bWFjLT5taWlfZGF0 YTsNCiAJdTMyIHRpbWVkb3V0ID0gMjA7DQogCXUzMiBtaWlfY29udHJvbDsNCiANCi0JI2lmZGVm IENPTkZJR19CQ001MjIyX0RVQUxfUEhZDQotCWlmIChhdXAtPm1paSAmJiBhdXAtPm1paS0+bWlp X2NvbnRyb2xfcmVnKSB7DQotCQltaWlfY29udHJvbF9yZWcgPSBhdXAtPm1paS0+bWlpX2NvbnRy b2xfcmVnOw0KLQkJbWlpX2RhdGFfcmVnID0gYXVwLT5taWktPm1paV9kYXRhX3JlZzsNCi0JfQ0K LQllbHNlIGlmIChhdV9tYWNzWzBdLT5taWkgJiYgYXVfbWFjc1swXS0+bWlpLT5taWlfY29udHJv bF9yZWcpIHsNCi0JCS8qIGFzc3VtZSBib3RoIHBoeXMgYXJlIGNvbnRyb2xsZWQgdGhyb3VnaCBt YWMwICovDQotCQltaWlfY29udHJvbF9yZWcgPSBhdV9tYWNzWzBdLT5taWktPm1paV9jb250cm9s X3JlZzsNCi0JCW1paV9kYXRhX3JlZyA9IGF1X21hY3NbMF0tPm1paS0+bWlpX2RhdGFfcmVnOw0K LQl9DQotCWVsc2UgDQotCSNlbmRpZg0KLQl7DQotCQkvKiBkZWZhdWx0IGNvbnRyb2wgYW5kIGRh dGEgcmVnIGFkZHJlc3NlcyAqLw0KLQkJbWlpX2NvbnRyb2xfcmVnID0gJmF1cC0+bWFjLT5taWlf Y29udHJvbDsNCi0JCW1paV9kYXRhX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2RhdGE7DQotCX0NCi0N CiAJd2hpbGUgKCptaWlfY29udHJvbF9yZWcgJiBNQUNfTUlJX0JVU1kpIHsNCiAJCW1kZWxheSgx KTsNCiAJCWlmICgtLXRpbWVkb3V0ID09IDApIHsNCkBAIC04ODcsMTY1ICsxOTAsMTM2IEBAIHN0 YXRpYyB2b2lkIG1kaW9fd3JpdGUoc3RydWN0IG5ldF9kZXZpY2UNCiAJfQ0KIA0KIAltaWlfY29u dHJvbCA9IE1BQ19TRVRfTUlJX1NFTEVDVF9SRUcocmVnKSB8IA0KLQkJTUFDX1NFVF9NSUlfU0VM RUNUX1BIWShwaHlfaWQpIHwgTUFDX01JSV9XUklURTsNCisJCU1BQ19TRVRfTUlJX1NFTEVDVF9Q SFkocGh5X2FkZHIpIHwgTUFDX01JSV9XUklURTsNCiANCiAJKm1paV9kYXRhX3JlZyA9IHZhbHVl Ow0KIAkqbWlpX2NvbnRyb2xfcmVnID0gbWlpX2NvbnRyb2w7DQogfQ0KIA0KLQ0KLXN0YXRpYyB2 b2lkIGR1bXBfbWlpKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfaWQpDQorc3RhdGlj IGludCBtZGlvYnVzX3JlYWQoc3RydWN0IG1paV9idXMgKmJ1cywgaW50IHBoeV9hZGRyLCBpbnQg cmVnbnVtKQ0KIHsNCi0JaW50IGksIHZhbDsNCisJc3RydWN0IG5ldF9kZXZpY2UgKmNvbnN0IGRl diA9IGJ1cy0+cHJpdjsgLyogYmV3YXJlOiBidXMtPnBoeV9tYXBbcGh5X2FkZHJdLmF0dGFjaGVk X2RldiA9PSBkZXYgZG9lcyBfTk9UXyBob2xkIGFsd2F5cyAgKi8NCisJZW5hYmxlX21hYyhkZXYs IDApOyAvKiBtYWtlIHN1cmUgTUFDIGFzc29jaWF0ZWQgd2l0aCB0aGlzIG1paV9idXMgaXMgZW5h YmxlZCAqLw0KKwlyZXR1cm4gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIHJlZ251bSk7DQorfQ0K IA0KLQlmb3IgKGkgPSAwOyBpIDwgNzsgaSsrKSB7DQotCQlpZiAoKHZhbCA9IG1kaW9fcmVhZChk ZXYsIHBoeV9pZCwgaSkpID49IDApDQotCQkJcHJpbnRrKCIlczogTUlJIFJlZyAlZD0leFxuIiwg ZGV2LT5uYW1lLCBpLCB2YWwpOw0KLQl9DQotCWZvciAoaSA9IDE2OyBpIDwgMjU7IGkrKykgew0K LQkJaWYgKCh2YWwgPSBtZGlvX3JlYWQoZGV2LCBwaHlfaWQsIGkpKSA+PSAwKQ0KLQkJCXByaW50 aygiJXM6IE1JSSBSZWcgJWQ9JXhcbiIsIGRldi0+bmFtZSwgaSwgdmFsKTsNCi0JfQ0KK3N0YXRp YyBpbnQgbWRpb2J1c193cml0ZShzdHJ1Y3QgbWlpX2J1cyAqYnVzLCBpbnQgcGh5X2FkZHIsIGlu dCByZWdudW0sIHUxNiB2YWx1ZSkNCit7DQorCXN0cnVjdCBuZXRfZGV2aWNlICpjb25zdCBkZXYg PSBidXMtPnByaXY7IC8qIGJld2FyZTogYnVzLT5waHlfbWFwW3BoeV9hZGRyXS5hdHRhY2hlZF9k ZXYgPT0gZGV2IGRvZXMgX05PVF8gaG9sZCBhbHdheXMgICovDQorCWVuYWJsZV9tYWMoZGV2LCAw KTsgLyogbWFrZSBzdXJlIE1BQyBhc3NvY2lhdGVkIHdpdGggdGhpcyBtaWlfYnVzIGlzIGVuYWJs ZWQgKi8NCisJbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCByZWdudW0sIHZhbHVlKTsNCisJcmV0 dXJuIDA7DQogfQ0KIA0KLXN0YXRpYyBpbnQgbWlpX3Byb2JlIChzdHJ1Y3QgbmV0X2RldmljZSAq IGRldikNCitzdGF0aWMgaW50IG1kaW9idXNfcmVzZXQoc3RydWN0IG1paV9idXMgKmJ1cykNCiB7 DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAq KSBkZXYtPnByaXY7DQotCWludCBwaHlfYWRkcjsNCi0jaWZkZWYgQ09ORklHX01JUFNfQk9TUE9S VVMNCi0JaW50IHBoeV9mb3VuZD0wOw0KLSNlbmRpZg0KKwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 ID0gYnVzLT5wcml2Ow0KIA0KLQkvKiBzZWFyY2ggZm9yIHRvdGFsIG9mIDMyIHBvc3NpYmxlIG1p aSBwaHkgYWRkcmVzc2VzICovDQotCWZvciAocGh5X2FkZHIgPSAwOyBwaHlfYWRkciA8IDMyOyBw aHlfYWRkcisrKSB7DQotCQl1MTYgbWlpX3N0YXR1czsNCi0JCXUxNiBwaHlfaWQwLCBwaHlfaWQx Ow0KLQkJaW50IGk7DQorCWVuYWJsZV9tYWMoZGV2LCAwKTsgLyogbWFrZSBzdXJlIE1BQyBhc3Nv Y2lhdGVkIHdpdGggdGhpcyBtaWlfYnVzIGlzIGVuYWJsZWQgKi8NCiANCi0JCSNpZmRlZiBDT05G SUdfQkNNNTIyMl9EVUFMX1BIWQ0KLQkJLyogTWFzayB0aGUgYWxyZWFkeSBmb3VuZCBwaHksIHRy eSBuZXh0IG9uZSAqLw0KLQkJaWYgKGF1X21hY3NbMF0tPm1paSAmJiBhdV9tYWNzWzBdLT5taWkt Pm1paV9jb250cm9sX3JlZykgew0KLQkJCWlmIChhdV9tYWNzWzBdLT5waHlfYWRkciA9PSBwaHlf YWRkcikNCi0JCQkJY29udGludWU7DQotCQl9DQotCQkjZW5kaWYNCisJcmV0dXJuIDA7DQorfQ0K IA0KLQkJbWlpX3N0YXR1cyA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfU1RBVFVTKTsN Ci0JCWlmIChtaWlfc3RhdHVzID09IDB4ZmZmZiB8fCBtaWlfc3RhdHVzID09IDB4MDAwMCkNCi0J CQkvKiB0aGUgbWlpIGlzIG5vdCBhY2Nlc3NhYmxlLCB0cnkgbmV4dCBvbmUgKi8NCi0JCQljb250 aW51ZTsNCi0NCi0JCXBoeV9pZDAgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX1BIWV9J RDApOw0KLQkJcGh5X2lkMSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfUEhZX0lEMSk7 DQotDQotCQkvKiBzZWFyY2ggb3VyIG1paSB0YWJsZSBmb3IgdGhlIGN1cnJlbnQgbWlpICovIA0K LQkJZm9yIChpID0gMDsgbWlpX2NoaXBfdGFibGVbaV0ucGh5X2lkMTsgaSsrKSB7DQotCQkJaWYg KHBoeV9pZDAgPT0gbWlpX2NoaXBfdGFibGVbaV0ucGh5X2lkMCAmJg0KLQkJCSAgICBwaHlfaWQx ID09IG1paV9jaGlwX3RhYmxlW2ldLnBoeV9pZDEpIHsNCi0JCQkJc3RydWN0IG1paV9waHkgKiBt aWlfcGh5ID0gYXVwLT5taWk7DQotDQotCQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiAlcyBhdCBw aHkgYWRkcmVzcyAlZFxuIiwNCi0JCQkJICAgICAgIGRldi0+bmFtZSwgbWlpX2NoaXBfdGFibGVb aV0ubmFtZSwgDQotCQkJCSAgICAgICBwaHlfYWRkcik7DQotI2lmZGVmIENPTkZJR19NSVBTX0JP U1BPUlVTDQotCQkJCXBoeV9mb3VuZCA9IDE7DQotI2VuZGlmDQotCQkJCW1paV9waHktPmNoaXBf aW5mbyA9IG1paV9jaGlwX3RhYmxlK2k7DQotCQkJCWF1cC0+cGh5X2FkZHIgPSBwaHlfYWRkcjsN Ci0JCQkJYXVwLT53YW50X2F1dG9uZWcgPSAxOw0KLQkJCQlhdXAtPnBoeV9vcHMgPSBtaWlfY2hp cF90YWJsZVtpXS5waHlfb3BzOw0KLQkJCQlhdXAtPnBoeV9vcHMtPnBoeV9pbml0KGRldixwaHlf YWRkcik7DQotDQotCQkJCS8vIENoZWNrIGZvciBkdWFsLXBoeSBhbmQgdGhlbiBzdG9yZSByZXF1 aXJlZCANCi0JCQkJLy8gdmFsdWVzIGFuZCBzZXQgaW5kaWNhdG9ycy4gV2UgbmVlZCB0byBkbyAN Ci0JCQkJLy8gdGhpcyBub3cgc2luY2UgbWRpb197cmVhZCx3cml0ZX0gbmVlZCB0aGUgDQotCQkJ CS8vIGNvbnRyb2wgYW5kIGRhdGEgcmVnaXN0ZXIgYWRkcmVzc2VzLg0KLQkJCQkjaWZkZWYgQ09O RklHX0JDTTUyMjJfRFVBTF9QSFkNCi0JCQkJaWYgKCBtaWlfY2hpcF90YWJsZVtpXS5kdWFsX3Bo eSkgew0KLQ0KLQkJCQkJLyogYXNzdW1lIGJvdGggcGh5cyBhcmUgY29udHJvbGxlZCANCi0JCQkJ CSAqIHRocm91Z2ggTUFDMC4gQm9hcmQgc3BlY2lmaWM/ICovDQotCQkJCQkNCi0JCQkJCS8qIHNh bml0eSBjaGVjayAqLw0KLQkJCQkJaWYgKCFhdV9tYWNzWzBdIHx8ICFhdV9tYWNzWzBdLT5taWkp DQotCQkJCQkJcmV0dXJuIC0xOw0KLQkJCQkJYXVwLT5taWktPm1paV9jb250cm9sX3JlZyA9ICh1 MzIgKikNCi0JCQkJCQkmYXVfbWFjc1swXS0+bWFjLT5taWlfY29udHJvbDsNCi0JCQkJCWF1cC0+ bWlpLT5taWlfZGF0YV9yZWcgPSAodTMyICopDQotCQkJCQkJJmF1X21hY3NbMF0tPm1hYy0+bWlp X2RhdGE7DQotCQkJCX0NCi0JCQkJI2VuZGlmDQotCQkJCWdvdG8gZm91bmQ7DQotCQkJfQ0KLQkJ fQ0KK3N0YXRpYyBpbnQgbWlpX3Byb2JlIChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KK3sNCisJ c3RydWN0IGF1MTAwMF9wcml2YXRlICpjb25zdCBhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRl ICopIGRldi0+cHJpdjsNCisJc3RydWN0IHBoeV9kZXZpY2UgKnBoeWRldiA9IE5VTEw7DQorCQ0K KyNpZiBkZWZpbmVkKENPTkZJR19NSVBTX0FVMVgwMF9FTkVUX1NUQVRJQ19QSFlfQ09ORklHKQ0K KwlCVUdfT04oYXVwLT5tYWNfaWQgPCAwIHx8IGF1cC0+bWFjX2lkID4gMSk7DQorDQorCWlmKGF1 cC0+bWFjX2lkID09IDApIHsNCisjIGlmIENPTkZJR19NSVBTX0FVMVgwMF9FTkVUX0VUSDBfUEhZ X0FERFI9PS0xDQorCQlwcmludGsgKEtFUk5fSU5GTyBEUlZfTkFNRSAiOiVzOiB1c2luZyBQSFkt bGVzcyBjb25maWdcbiIsIGRldi0+bmFtZSk7DQorCQlyZXR1cm4gMDsNCisjIGVsaWYgKENPTkZJ R19NSVBTX0FVMVgwMF9FTkVUX0VUSDBfUEhZX0FERFI+PTApICYmIChDT05GSUdfTUlQU19BVTFY MDBfRU5FVF9FVEgwX1BIWV9BRERSPFBIWV9NQVhfQUREUikNCisJCXBoeWRldiA9IGF1cC0+bWlp X2J1cy5waHlfbWFwW0NPTkZJR19NSVBTX0FVMVgwMF9FTkVUX0VUSDBfUEhZX0FERFJdOw0KKyMg ZWxzZQ0KKyMgIGVycm9yIEJhZCB2YWx1ZSBmb3IgQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRI MF9QSFlfQUREUiBnaXZlbg0KKyMgZW5kaWYNCisJfSBlbHNlIGlmIChhdXAtPm1hY19pZCA9PSAx KSB7DQorIyBpZiBDT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9BRERSPT0tMQ0KKwkJ cHJpbnRrIChLRVJOX0lORk8gRFJWX05BTUUgIjolczogdXNpbmcgUEhZLWxlc3MgY29uZmlnXG4i LCBkZXYtPm5hbWUpOw0KKwkJcmV0dXJuIDA7DQorIyBlbGlmIChDT05GSUdfTUlQU19BVTFYMDBf RU5FVF9FVEgxX1BIWV9BRERSPj0wKSAmJiAoQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMV9Q SFlfQUREUjxQSFlfTUFYX0FERFIpDQorIyAgaWYgZGVmaW5lZChDT05GSUdfTUlQU19BVTFYMDBf RU5FVF9FVEgxX1BIWV9PTl9NQUMwKQ0KKyMgICBpZiBDT05GSUdfTUlQU19BVTFYMDBfRU5FVF9F VEgxX1BIWV9BRERSPT1DT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgwX1BIWV9BRERSDQorIyAg ICBlcnJvciBnaXZlbiBzYW1lIHN0YXRpYyBQSFkgYWRkcmVzcywgYW5kIGJvdGggUEhZcyBhcmUg b24gdGhlIHNhbWUgYnVzDQorIyAgIGVuZGlmDQorCQlwaHlkZXYgPSBhdV9tYWNzWzBdLT5taWlf YnVzLnBoeV9tYXBbQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMV9QSFlfQUREUl07DQorIyAg ZWxzZQ0KKwkJcGh5ZGV2ID0gYXVwLT5taWlfYnVzLnBoeV9tYXBbQ09ORklHX01JUFNfQVUxWDAw X0VORVRfRVRIMV9QSFlfQUREUl07DQorIyAgZW5kaWYNCisjIGVsc2UNCisjICBlcnJvciBCYWQg dmFsdWUgZm9yIENPTkZJR19NSVBTX0FVMVgwMF9FTkVUX0VUSDBfUEhZX0FERFIgZ2l2ZW4NCisj IGVuZGlmDQogCX0NCi1mb3VuZDoNCiANCi0jaWZkZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi0J LyogVGhpcyBpcyBhIHdvcmthcm91bmQgZm9yIHRoZSBNaWNyZWwvS2VuZGluIDUgcG9ydCBzd2l0 Y2gNCi0JICAgVGhlIHNlY29uZCBNQUMgZG9lc24ndCBzZWUgYSBQSFkgY29ubmVjdGVkLi4uIHNv IHdlIG5lZWQgdG8NCi0JICAgdHJpY2sgaXQgaW50byB0aGlua2luZyB3ZSBoYXZlIG9uZS4NCi0J CQ0KLQkgICBJZiB0aGlzIGtlcm5lbCBpcyBydW4gb24gYW5vdGhlciBBdTE1MDAgZGV2ZWxvcG1l bnQgYm9hcmQNCi0JICAgdGhlIHN0dWIgd2lsbCBiZSBmb3VuZCBhcyB3ZWxsIGFzIHRoZSBhY3R1 YWwgUEhZLiBIb3dldmVyLA0KLQkgICB0aGUgbGFzdCBmb3VuZCBQSFkgd2lsbCBiZSB1c2VkLi4u IHVzdWFsbHkgYXQgQWRkciAzMSAoRGIxNTAwKS4JDQotCSovDQotCWlmICggKCFwaHlfZm91bmQp ICkNCi0Jew0KLQkJdTE2IHBoeV9pZDAsIHBoeV9pZDE7DQotCQlpbnQgaTsNCisjZWxzZSAvKiBy dW50aW1lIGRldGVjdGVkIFBIWSBjb25maWd1cmF0aW9uICovDQorCWludCBwaHlfYWRkcjsNCiAN Ci0JCXBoeV9pZDAgPSAweDEyMzQ7DQotCQlwaHlfaWQxID0gMHg1Njc4Ow0KKwkvKiBmaW5kIHRo ZSBmaXJzdCAobG93ZXN0IGFkZHJlc3MpIFBIWSBvbiB0aGUgY3VycmVudCBNQUMncyBNSUkgYnVz ICovDQorCWZvciAocGh5X2FkZHIgPSAwOyBwaHlfYWRkciA8IFBIWV9NQVhfQUREUjsgcGh5X2Fk ZHIrKykgDQorCQlpZiAoYXVwLT5taWlfYnVzLnBoeV9tYXBbcGh5X2FkZHJdKSB7DQorCQkJcGh5 ZGV2ID0gYXVwLT5taWlfYnVzLnBoeV9tYXBbcGh5X2FkZHJdOw0KKwkJCWJyZWFrOyAvKiBmb3Vu ZCBpdCAqLw0KKwkJfQ0KKw0KKwkvKiB0cnkgaGFyZGVyIHRvIGZpbmQgYSBQSFkgKi8NCisJaWYg KCFwaHlkZXYgJiYgKGF1cC0+bWFjX2lkID09IDEpKSB7IC8qIG5vIFBIWSBmb3VuZCwgbWF5YmUg d2UgaGF2ZSBhIGR1YWwgUEhZPyAqLyANCisJCXByaW50ayAoS0VSTl9JTkZPIERSVl9OQU1FICI6 IG5vIFBIWSBmb3VuZCBvbiBNQUMxLCBsZXQncyBzZWUgaWYgaXQncyBhdHRhY2hlZCB0byBNQUMw Li4uXG4iKTsNCisNCisJCUJVR19PTighYXVfbWFjc1swXSB8fCAhYXVfbWFjc1swXS0+bWlpX2J1 cyk7DQorDQorCQkvKiBmaW5kIHRoZSBmaXJzdCAobG93ZXN0IGFkZHJlc3MpIG5vbi1hdHRhY2hl ZCBQSFkgb24gdGhlIE1BQzAgTUlJIGJ1cyAqLw0KKwkJZm9yIChwaHlfYWRkciA9IDA7IHBoeV9h ZGRyIDwgUEhZX01BWF9BRERSOyBwaHlfYWRkcisrKSB7DQorCQkJc3RydWN0IHBoeV9kZXZpY2Ug KmNvbnN0IHRtcF9waHlkZXYgPSBhdXAtPmF1X21hY3NbMF0tPm1paV9idXMucGh5X21hcFtwaHlf YWRkcl07DQorCQkJDQorCQkJaWYgKCF0bXBfcGh5ZGV2KQ0KKwkJCQljb250aW51ZTsgLyogbm8g UEhZIGhlcmUuLi4gKi8NCisJCQkNCisJCQlpZiAodG1wX3BoeWRldi0+YXR0YWNoZWRfZGV2KQ0K KwkJCQljb250aW51ZTsgLyogYWxyZWFkeSBjbGFpbWVkIGJ5IE1BQzAgKi8NCiANCi0JCS8qIHNl YXJjaCBvdXIgbWlpIHRhYmxlIGZvciB0aGUgY3VycmVudCBtaWkgKi8gDQotCQlmb3IgKGkgPSAw OyBtaWlfY2hpcF90YWJsZVtpXS5waHlfaWQxOyBpKyspIHsNCi0JCQlpZiAocGh5X2lkMCA9PSBt aWlfY2hpcF90YWJsZVtpXS5waHlfaWQwICYmDQotCQkJICAgIHBoeV9pZDEgPT0gbWlpX2NoaXBf dGFibGVbaV0ucGh5X2lkMSkgew0KLQkJCQlzdHJ1Y3QgbWlpX3BoeSAqIG1paV9waHk7DQotDQot CQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiAlcyBhdCBwaHkgYWRkcmVzcyAlZFxuIiwNCi0JCQkJ ICAgICAgIGRldi0+bmFtZSwgbWlpX2NoaXBfdGFibGVbaV0ubmFtZSwgDQotCQkJCSAgICAgICBw aHlfYWRkcik7DQotCQkJCW1paV9waHkgPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWlpX3BoeSks IA0KLQkJCQkJCUdGUF9LRVJORUwpOw0KLQkJCQlpZiAobWlpX3BoeSkgew0KLQkJCQkJbWlpX3Bo eS0+Y2hpcF9pbmZvID0gbWlpX2NoaXBfdGFibGUraTsNCi0JCQkJCWF1cC0+cGh5X2FkZHIgPSBw aHlfYWRkcjsNCi0JCQkJCW1paV9waHktPm5leHQgPSBhdXAtPm1paTsNCi0JCQkJCWF1cC0+cGh5 X29wcyA9IA0KLQkJCQkJCW1paV9jaGlwX3RhYmxlW2ldLnBoeV9vcHM7DQotCQkJCQlhdXAtPm1p aSA9IG1paV9waHk7DQotCQkJCQlhdXAtPnBoeV9vcHMtPnBoeV9pbml0KGRldixwaHlfYWRkcik7 DQotCQkJCX0gZWxzZSB7DQotCQkJCQlwcmludGsoS0VSTl9FUlIgIiVzOiBvdXQgb2YgbWVtb3J5 XG4iLCANCi0JCQkJCQkJZGV2LT5uYW1lKTsNCi0JCQkJCXJldHVybiAtMTsNCi0JCQkJfQ0KLQkJ CQltaWlfcGh5LT5jaGlwX2luZm8gPSBtaWlfY2hpcF90YWJsZStpOw0KLQkJCQlhdXAtPnBoeV9h ZGRyID0gcGh5X2FkZHI7DQotCQkJCWF1cC0+cGh5X29wcyA9IG1paV9jaGlwX3RhYmxlW2ldLnBo eV9vcHM7DQotCQkJCWF1cC0+cGh5X29wcy0+cGh5X2luaXQoZGV2LHBoeV9hZGRyKTsNCi0JCQkJ YnJlYWs7DQotCQkJfQ0KKwkJCXBoeWRldiA9IHRtcF9waHlkZXY7DQorCQkJYnJlYWs7IC8qIGZv dW5kIGl0ICovDQogCQl9DQogCX0NCi0JaWYgKGF1cC0+bWFjX2lkID09IDApIHsNCi0JCS8qIHRo ZSBCb3Nwb3J1cyBwaHkgcmVzcG9uZHMgdG8gYWRkcmVzc2VzIDAtNSBidXQgDQotCQkgKiA1IGlz IHRoZSBjb3JyZWN0IG9uZS4NCi0JCSAqLw0KLQkJYXVwLT5waHlfYWRkciA9IDU7DQotCX0NCi0j ZW5kaWYNCiANCi0JaWYgKGF1cC0+bWlpLT5jaGlwX2luZm8gPT0gTlVMTCkgew0KLQkJcHJpbnRr KEtFUk5fRVJSICIlczogQXUxeCBObyBrbm93biBNSUkgdHJhbnNjZWl2ZXJzIGZvdW5kIVxuIiwN Ci0JCQkJZGV2LT5uYW1lKTsNCisjZW5kaWYNCisJaWYgKCFwaHlkZXYpIHsNCisJCXByaW50ayAo S0VSTl9FUlIgRFJWX05BTUUgIjolczogbm8gUEhZIGZvdW5kXG4iLCBkZXYtPm5hbWUpOw0KIAkJ cmV0dXJuIC0xOw0KIAl9DQogDQotCXByaW50ayhLRVJOX0lORk8gIiVzOiBVc2luZyAlcyBhcyBk ZWZhdWx0XG4iLCANCi0JCQlkZXYtPm5hbWUsIGF1cC0+bWlpLT5jaGlwX2luZm8tPm5hbWUpOw0K KwkvKiBub3cgd2UgYXJlIHN1cHBvc2VkIHRvIGhhdmUgYSBwcm9wZXIgcGh5ZGV2LCB0byBhdHRh Y2ggdG8uLi4gKi8NCisJQlVHX09OKCFwaHlkZXYpOw0KKw0KKwlwaHlkZXYgPSBwaHlfY29ubmVj dChkZXYsIHBoeWRldi0+ZGV2LmJ1c19pZCwgJmF1MTAwMF9hZGp1c3RfbGluaywgMCk7DQorCQkN CisJaWYgKElTX0VSUihwaHlkZXYpKSB7DQorCQlwcmludGsoS0VSTl9FUlIgIiVzOiBDb3VsZCBu b3QgYXR0YWNoIHRvIFBIWVxuIiwgZGV2LT5uYW1lKTsNCisJCXJldHVybiBQVFJfRVJSKHBoeWRl dik7DQorCX0NCisJCQ0KKwkvLyBtYXNrIHdpdGggTUFDIHN1cHBvcnRlZCBmZWF0dXJlcw0KKwlw aHlkZXYtPnN1cHBvcnRlZCAmPSAoU1VQUE9SVEVEXzEwYmFzZVRfSGFsZiANCisJCQkgICAgICB8 IFNVUFBPUlRFRF8xMGJhc2VUX0Z1bGwgDQorCQkJICAgICAgfCBTVVBQT1JURURfMTAwYmFzZVRf SGFsZiANCisJCQkgICAgICB8IFNVUFBPUlRFRF8xMDBiYXNlVF9GdWxsIA0KKwkJCSAgICAgIHwg U1VQUE9SVEVEX0F1dG9uZWcgDQorCQkJICAgICAgfCBTVVBQT1JURURfTUlJIA0KKwkJCSAgICAg IHwgU1VQUE9SVEVEX1RQKTsNCisJCQ0KKwlwaHlkZXYtPmFkdmVydGlzaW5nID0gcGh5ZGV2LT5z dXBwb3J0ZWQ7DQorDQorCWF1cC0+b2xkX2xpbmsgPSAwOw0KKwlhdXAtPm9sZF9zcGVlZCA9IDA7 DQorCWF1cC0+b2xkX2R1cGxleCA9IC0xOw0KKwlhdXAtPnBoeV9kZXYgPSBwaHlkZXY7DQorDQor CXByaW50ayhLRVJOX0lORk8gIiVzOiBhdHRhY2hlZCAlcyAobWlpPSVzLCBpcnE9JWQpXG4iLCAN CisJICAgICAgIGRldi0+bmFtZSwgcGh5ZGV2LT5kcnYtPm5hbWUsIHBoeWRldi0+ZGV2LmJ1c19p ZCwgcGh5ZGV2LT5pcnEpOw0KIA0KIAlyZXR1cm4gMDsNCiB9DQpAQCAtMTA5Nyw2ICszNzEsMjQg QEAgc3RhdGljIHZvaWQgaGFyZF9zdG9wKHN0cnVjdCBuZXRfZGV2aWNlIA0KIAlhdV9zeW5jX2Rl bGF5KDEwKTsNCiB9DQogDQorc3RhdGljIHZvaWQgZW5hYmxlX21hYyhzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgZm9yY2VfcmVzZXQpDQorew0KKwl1bnNpZ25lZCBsb25nIGZsYWdzOw0KKwlz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2 LT5wcml2Ow0KKw0KKwlzcGluX2xvY2tfaXJxc2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQorDQor CWlmKGZvcmNlX3Jlc2V0IHx8ICghYXVwLT5tYWNfZW5hYmxlZCkpIHsNCisJCSphdXAtPmVuYWJs ZSA9IE1BQ19FTl9DTE9DS19FTkFCTEU7DQorCQlhdV9zeW5jX2RlbGF5KDIpOw0KKwkJKmF1cC0+ ZW5hYmxlID0gTUFDX0VOX1JFU0VUMCB8IE1BQ19FTl9SRVNFVDEgfCBNQUNfRU5fUkVTRVQyIHwg TUFDX0VOX0NMT0NLX0VOQUJMRTsNCisJCWF1X3N5bmNfZGVsYXkoMik7DQorDQorCQlhdXAtPm1h Y19lbmFibGVkID0gMTsNCisJfQ0KKw0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZhdXAtPmxv Y2ssIGZsYWdzKTsNCit9DQogDQogc3RhdGljIHZvaWQgcmVzZXRfbWFjKHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYpDQogew0KQEAgLTExMDksMjMgKzQwMSwxNSBAQCBzdGF0aWMgdm9pZCByZXNldF9t YWMoc3RydWN0IG5ldF9kZXZpY2UgDQogCQkJCWRldi0+bmFtZSwgKHVuc2lnbmVkKWF1cCk7DQog DQogCXNwaW5fbG9ja19pcnFzYXZlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCi0JaWYgKGF1cC0+dGlt ZXIuZnVuY3Rpb24gPT0gJmF1MTAwMF90aW1lcikgey8qIGNoZWNrIGlmIHRpbWVyIGluaXR0ZWQg Ki8NCi0JCWRlbF90aW1lcigmYXVwLT50aW1lcik7DQotCX0NCisJLy8gZml4bWUsIGxvY2sgbWlp YnVzDQogDQogCWhhcmRfc3RvcChkZXYpOw0KLQkjaWZkZWYgQ09ORklHX0JDTTUyMjJfRFVBTF9Q SFkNCi0JaWYgKGF1cC0+bWFjX2lkICE9IDApIHsNCi0JI2VuZGlmDQotCQkvKiBJZiBCQ001MjIy LCB3ZSBjYW4ndCBsZWF2ZSBNQUMwIGluIHJlc2V0IGJlY2F1c2UgdGhlbiANCi0JCSAqIHdlIGNh bid0IGFjY2VzcyB0aGUgZHVhbCBwaHkgZm9yIEVUSDEgKi8NCi0JCSphdXAtPmVuYWJsZSA9IE1B Q19FTl9DTE9DS19FTkFCTEU7DQotCQlhdV9zeW5jX2RlbGF5KDIpOw0KLQkJKmF1cC0+ZW5hYmxl ID0gMDsNCi0JCWF1X3N5bmNfZGVsYXkoMik7DQotCSNpZmRlZiBDT05GSUdfQkNNNTIyMl9EVUFM X1BIWQ0KLQl9DQotCSNlbmRpZg0KKw0KKwkqYXVwLT5lbmFibGUgPSBNQUNfRU5fQ0xPQ0tfRU5B QkxFOw0KKwlhdV9zeW5jX2RlbGF5KDIpOw0KKwkqYXVwLT5lbmFibGUgPSAwOw0KKwlhdV9zeW5j X2RlbGF5KDIpOw0KKw0KIAlhdXAtPnR4X2Z1bGwgPSAwOw0KIAlmb3IgKGkgPSAwOyBpIDwgTlVN X1JYX0RNQTsgaSsrKSB7DQogCQkvKiByZXNldCBjb250cm9sIGJpdHMgKi8NCkBAIC0xMTM1LDYg KzQxOSw5IEBAIHN0YXRpYyB2b2lkIHJlc2V0X21hYyhzdHJ1Y3QgbmV0X2RldmljZSANCiAJCS8q IHJlc2V0IGNvbnRyb2wgYml0cyAqLw0KIAkJYXVwLT50eF9kbWFfcmluZ1tpXS0+YnVmZl9zdGF0 ICY9IH4weGY7DQogCX0NCisNCisJYXVwLT5tYWNfZW5hYmxlZCA9IDA7DQorDQogCXNwaW5fdW5s b2NrX2lycXJlc3RvcmUoJmF1cC0+bG9jaywgZmxhZ3MpOw0KIH0NCiANCkBAIC0xMjM3LDE3OCAr NTI0LDI2IEBAIHN0YXRpYyBpbnQgX19pbml0IGF1MTAwMF9pbml0X21vZHVsZSh2b2kNCiAJcmV0 dXJuIDA7DQogfQ0KIA0KLXN0YXRpYyBpbnQgYXUxMDAwX3NldHVwX2FuZWcoc3RydWN0IG5ldF9k ZXZpY2UgKmRldiwgdTMyIGFkdmVydGlzZSkNCi17DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAq YXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JdTE2IGN0bCwgYWR2 Ow0KLQ0KLQkvKiBTZXR1cCBzdGFuZGFyZCBhZHZlcnRpc2UgKi8NCi0JYWR2ID0gbWRpb19yZWFk KGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0FEVkVSVElTRSk7DQotCWFkdiAmPSB+KEFEVkVSVElT RV9BTEwgfCBBRFZFUlRJU0VfMTAwQkFTRTQpOw0KLQlpZiAoYWR2ZXJ0aXNlICYgQURWRVJUSVNF RF8xMGJhc2VUX0hhbGYpDQotCQlhZHYgfD0gQURWRVJUSVNFXzEwSEFMRjsNCi0JaWYgKGFkdmVy dGlzZSAmIEFEVkVSVElTRURfMTBiYXNlVF9GdWxsKQ0KLQkJYWR2IHw9IEFEVkVSVElTRV8xMEZV TEw7DQotCWlmIChhZHZlcnRpc2UgJiBBRFZFUlRJU0VEXzEwMGJhc2VUX0hhbGYpDQotCQlhZHYg fD0gQURWRVJUSVNFXzEwMEhBTEY7DQotCWlmIChhZHZlcnRpc2UgJiBBRFZFUlRJU0VEXzEwMGJh c2VUX0Z1bGwpDQotCQlhZHYgfD0gQURWRVJUSVNFXzEwMEZVTEw7DQotCW1kaW9fd3JpdGUoZGV2 LCBhdXAtPnBoeV9hZGRyLCBNSUlfQURWRVJUSVNFLCBhZHYpOw0KLQ0KLQkvKiBTdGFydC9SZXN0 YXJ0IGFuZWcgKi8NCi0JY3RsID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0JN Q1IpOw0KLQljdGwgfD0gKEJNQ1JfQU5FTkFCTEUgfCBCTUNSX0FOUkVTVEFSVCk7DQotCW1kaW9f d3JpdGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQk1DUiwgY3RsKTsNCi0NCi0JcmV0dXJuIDA7 DQotfQ0KLQ0KLXN0YXRpYyBpbnQgYXUxMDAwX3NldHVwX2ZvcmNlZChzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgc3BlZWQsIGludCBmZCkNCi17DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAq YXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JdTE2IGN0bDsNCi0N Ci0JY3RsID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0JNQ1IpOw0KLQljdGwg Jj0gfihCTUNSX0ZVTExEUExYIHwgQk1DUl9TUEVFRDEwMCB8IEJNQ1JfQU5FTkFCTEUpOw0KLQ0K LQkvKiBGaXJzdCByZXNldCB0aGUgUEhZICovDQotCW1kaW9fd3JpdGUoZGV2LCBhdXAtPnBoeV9h ZGRyLCBNSUlfQk1DUiwgY3RsIHwgQk1DUl9SRVNFVCk7DQotDQotCS8qIFNlbGVjdCBzcGVlZCAm IGR1cGxleCAqLw0KLQlzd2l0Y2ggKHNwZWVkKSB7DQotCQljYXNlIFNQRUVEXzEwOg0KLQkJCWJy ZWFrOw0KLQkJY2FzZSBTUEVFRF8xMDA6DQotCQkJY3RsIHw9IEJNQ1JfU1BFRUQxMDA7DQotCQkJ YnJlYWs7DQotCQljYXNlIFNQRUVEXzEwMDA6DQotCQlkZWZhdWx0Og0KLQkJCXJldHVybiAtRUlO VkFMOw0KLQl9DQotCWlmIChmZCA9PSBEVVBMRVhfRlVMTCkNCi0JCWN0bCB8PSBCTUNSX0ZVTExE UExYOw0KLQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0JNQ1IsIGN0bCk7DQot DQotCXJldHVybiAwOw0KLX0NCi0NCi0NCi1zdGF0aWMgdm9pZA0KLWF1MTAwMF9zdGFydF9saW5r KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBldGh0b29sX2NtZCAqY21kKQ0KLXsNCi0J c3RydWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopZGV2 LT5wcml2Ow0KLQl1MzIgYWR2ZXJ0aXNlOw0KLQlpbnQgYXV0b25lZzsNCi0JaW50IGZvcmNlZF9z cGVlZDsNCi0JaW50IGZvcmNlZF9kdXBsZXg7DQotDQotCS8qIERlZmF1bHQgYWR2ZXJ0aXNlICov DQotCWFkdmVydGlzZSA9IEdFTk1JSV9ERUZBVUxUX0FEVkVSVElTRTsNCi0JYXV0b25lZyA9IGF1 cC0+d2FudF9hdXRvbmVnOw0KLQlmb3JjZWRfc3BlZWQgPSBTUEVFRF8xMDA7DQotCWZvcmNlZF9k dXBsZXggPSBEVVBMRVhfRlVMTDsNCi0NCi0JLyogU2V0dXAgbGluayBwYXJhbWV0ZXJzICovDQot CWlmIChjbWQpIHsNCi0JCWlmIChjbWQtPmF1dG9uZWcgPT0gQVVUT05FR19FTkFCTEUpIHsNCi0J CQlhZHZlcnRpc2UgPSBjbWQtPmFkdmVydGlzaW5nOw0KLQkJCWF1dG9uZWcgPSAxOw0KLQkJfSBl bHNlIHsNCi0JCQlhdXRvbmVnID0gMDsNCi0NCi0JCQlmb3JjZWRfc3BlZWQgPSBjbWQtPnNwZWVk Ow0KLQkJCWZvcmNlZF9kdXBsZXggPSBjbWQtPmR1cGxleDsNCi0JCX0NCi0JfQ0KLQ0KLQkvKiBD b25maWd1cmUgUEhZICYgc3RhcnQgYW5lZyAqLw0KLQlhdXAtPndhbnRfYXV0b25lZyA9IGF1dG9u ZWc7DQotCWlmIChhdXRvbmVnKQ0KLQkJYXUxMDAwX3NldHVwX2FuZWcoZGV2LCBhZHZlcnRpc2Up Ow0KLQllbHNlDQotCQlhdTEwMDBfc2V0dXBfZm9yY2VkKGRldiwgZm9yY2VkX3NwZWVkLCBmb3Jj ZWRfZHVwbGV4KTsNCi0JbW9kX3RpbWVyKCZhdXAtPnRpbWVyLCBqaWZmaWVzICsgSFopOw0KLX0N Ci0NCiBzdGF0aWMgaW50IGF1MTAwMF9nZXRfc2V0dGluZ3Moc3RydWN0IG5ldF9kZXZpY2UgKmRl diwgc3RydWN0IGV0aHRvb2xfY21kICpjbWQpDQogew0KIAlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUg KmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnByaXY7DQotCXUxNiBsaW5rLCBz cGVlZDsNCiANCi0JY21kLT5zdXBwb3J0ZWQgPSBHRU5NSUlfREVGQVVMVF9GRUFUVVJFUzsNCi0J Y21kLT5hZHZlcnRpc2luZyA9IEdFTk1JSV9ERUZBVUxUX0FEVkVSVElTRTsNCi0JY21kLT5wb3J0 ID0gUE9SVF9NSUk7DQotCWNtZC0+dHJhbnNjZWl2ZXIgPSBYQ1ZSX0VYVEVSTkFMOw0KLQljbWQt PnBoeV9hZGRyZXNzID0gYXVwLT5waHlfYWRkcjsNCi0Jc3Bpbl9sb2NrX2lycSgmYXVwLT5sb2Nr KTsNCi0JY21kLT5hdXRvbmVnID0gYXVwLT53YW50X2F1dG9uZWc7DQotCWF1cC0+cGh5X29wcy0+ cGh5X3N0YXR1cyhkZXYsIGF1cC0+cGh5X2FkZHIsICZsaW5rLCAmc3BlZWQpOw0KLQlpZiAoKHNw ZWVkID09IElGX1BPUlRfMTAwQkFTRVRYKSB8fCAoc3BlZWQgPT0gSUZfUE9SVF8xMDBCQVNFRlgp KQ0KLQkJY21kLT5zcGVlZCA9IFNQRUVEXzEwMDsNCi0JZWxzZSBpZiAoc3BlZWQgPT0gSUZfUE9S VF8xMEJBU0VUKQ0KLQkJY21kLT5zcGVlZCA9IFNQRUVEXzEwOw0KLQlpZiAobGluayAmJiAoZGV2 LT5pZl9wb3J0ID09IElGX1BPUlRfMTAwQkFTRUZYKSkNCi0JCWNtZC0+ZHVwbGV4ID0gRFVQTEVY X0ZVTEw7DQotCWVsc2UNCi0JCWNtZC0+ZHVwbGV4ID0gRFVQTEVYX0hBTEY7DQotCXNwaW5fdW5s b2NrX2lycSgmYXVwLT5sb2NrKTsNCi0JcmV0dXJuIDA7DQotfQ0KKwlpZiAoIWF1cC0+cGh5X2Rl dikgcmV0dXJuIC1FSU5WQUw7IC8vIFBIWSBub3QgY29udHJvbGxhYmxlDQogDQotc3RhdGljIGlu dCBhdTEwMDBfc2V0X3NldHRpbmdzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBldGh0 b29sX2NtZCAqY21kKQ0KLXsNCi0JIHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVj dCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JICB1bnNpZ25lZCBsb25nIGZlYXR1cmVz ID0gR0VOTUlJX0RFRkFVTFRfRkVBVFVSRVM7DQotDQotCSBpZiAoIWNhcGFibGUoQ0FQX05FVF9B RE1JTikpDQotCQkgcmV0dXJuIC1FUEVSTTsNCi0NCi0JIGlmIChjbWQtPmF1dG9uZWcgIT0gQVVU T05FR19FTkFCTEUgJiYgY21kLT5hdXRvbmVnICE9IEFVVE9ORUdfRElTQUJMRSkNCi0JCSByZXR1 cm4gLUVJTlZBTDsNCi0JIGlmIChjbWQtPmF1dG9uZWcgPT0gQVVUT05FR19FTkFCTEUgJiYgY21k LT5hZHZlcnRpc2luZyA9PSAwKQ0KLQkJIHJldHVybiAtRUlOVkFMOw0KLQkgaWYgKGNtZC0+ZHVw bGV4ICE9IERVUExFWF9IQUxGICYmIGNtZC0+ZHVwbGV4ICE9IERVUExFWF9GVUxMKQ0KLQkJIHJl dHVybiAtRUlOVkFMOw0KLQkgaWYgKGNtZC0+YXV0b25lZyA9PSBBVVRPTkVHX0RJU0FCTEUpDQot CQkgc3dpdGNoIChjbWQtPnNwZWVkKSB7DQotCQkgY2FzZSBTUEVFRF8xMDoNCi0JCQkgaWYgKGNt ZC0+ZHVwbGV4ID09IERVUExFWF9IQUxGICYmDQotCQkJCSAoZmVhdHVyZXMgJiBTVVBQT1JURURf MTBiYXNlVF9IYWxmKSA9PSAwKQ0KLQkJCQkgcmV0dXJuIC1FSU5WQUw7DQotCQkJIGlmIChjbWQt PmR1cGxleCA9PSBEVVBMRVhfRlVMTCAmJg0KLQkJCQkgKGZlYXR1cmVzICYgU1VQUE9SVEVEXzEw YmFzZVRfRnVsbCkgPT0gMCkNCi0JCQkJIHJldHVybiAtRUlOVkFMOw0KLQkJCSBicmVhazsNCi0J CSBjYXNlIFNQRUVEXzEwMDoNCi0JCQkgaWYgKGNtZC0+ZHVwbGV4ID09IERVUExFWF9IQUxGICYm DQotCQkJCSAoZmVhdHVyZXMgJiBTVVBQT1JURURfMTAwYmFzZVRfSGFsZikgPT0gMCkNCi0JCQkJ IHJldHVybiAtRUlOVkFMOw0KLQkJCSBpZiAoY21kLT5kdXBsZXggPT0gRFVQTEVYX0ZVTEwgJiYN Ci0JCQkJIChmZWF0dXJlcyAmIFNVUFBPUlRFRF8xMDBiYXNlVF9GdWxsKSA9PSAwKQ0KLQkJCQkg cmV0dXJuIC1FSU5WQUw7DQotCQkJIGJyZWFrOw0KLQkJIGRlZmF1bHQ6DQotCQkJIHJldHVybiAt RUlOVkFMOw0KLQkJIH0NCi0JIGVsc2UgaWYgKChmZWF0dXJlcyAmIFNVUFBPUlRFRF9BdXRvbmVn KSA9PSAwKQ0KLQkJIHJldHVybiAtRUlOVkFMOw0KLQ0KLQkgc3Bpbl9sb2NrX2lycSgmYXVwLT5s b2NrKTsNCi0JIGF1MTAwMF9zdGFydF9saW5rKGRldiwgY21kKTsNCi0JIHNwaW5fdW5sb2NrX2ly cSgmYXVwLT5sb2NrKTsNCi0JIHJldHVybiAwOw0KKwlyZXR1cm4gcGh5X2V0aHRvb2xfZ3NldChh dXAtPnBoeV9kZXYsIGNtZCk7DQogfQ0KIA0KLXN0YXRpYyBpbnQgYXUxMDAwX253YXlfcmVzZXQo c3RydWN0IG5ldF9kZXZpY2UgKmRldikNCitzdGF0aWMgaW50IGF1MTAwMF9zZXRfc2V0dGluZ3Mo c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGV0aHRvb2xfY21kICpjbWQpDQogew0KIAlz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYt PnByaXY7DQotDQotCWlmICghYXVwLT53YW50X2F1dG9uZWcpDQotCQlyZXR1cm4gLUVJTlZBTDsN Ci0Jc3Bpbl9sb2NrX2lycSgmYXVwLT5sb2NrKTsNCi0JYXUxMDAwX3N0YXJ0X2xpbmsoZGV2LCBO VUxMKTsNCi0Jc3Bpbl91bmxvY2tfaXJxKCZhdXAtPmxvY2spOw0KLQlyZXR1cm4gMDsNCisJDQor CWlmICghY2FwYWJsZShDQVBfTkVUX0FETUlOKSkNCisJCXJldHVybiAtRVBFUk07DQorCQ0KKwlp ZiAoIWF1cC0+cGh5X2RldikgcmV0dXJuIC1FSU5WQUw7IC8vIFBIWSBub3QgY29udHJvbGxhYmxl DQorCQ0KKwkvL3NwaW5fbG9ja19pcnEoJmF1cC0+bG9jayk7IG5lZWQgdGhpcz8NCisJcmV0dXJu IHBoeV9ldGh0b29sX3NzZXQoYXVwLT5waHlfZGV2LCBjbWQpOw0KIH0NCiANCiBzdGF0aWMgdm9p ZA0KQEAgLTE0MjMsMTcgKzU1OCwxMSBAQCBhdTEwMDBfZ2V0X2RydmluZm8oc3RydWN0IG5ldF9k ZXZpY2UgKmRlDQogCWluZm8tPnJlZ2R1bXBfbGVuID0gMDsNCiB9DQogDQotc3RhdGljIHUzMiBh dTEwMDBfZ2V0X2xpbmsoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCi17DQotCXJldHVybiBuZXRp Zl9jYXJyaWVyX29rKGRldik7DQotfQ0KLQ0KIHN0YXRpYyBzdHJ1Y3QgZXRodG9vbF9vcHMgYXUx MDAwX2V0aHRvb2xfb3BzID0gew0KIAkuZ2V0X3NldHRpbmdzID0gYXUxMDAwX2dldF9zZXR0aW5n cywNCiAJLnNldF9zZXR0aW5ncyA9IGF1MTAwMF9zZXRfc2V0dGluZ3MsDQogCS5nZXRfZHJ2aW5m byA9IGF1MTAwMF9nZXRfZHJ2aW5mbywNCi0JLm53YXlfcmVzZXQgPSBhdTEwMDBfbndheV9yZXNl dCwNCi0JLmdldF9saW5rID0gYXUxMDAwX2dldF9saW5rDQorCS5nZXRfbGluayA9IGV0aHRvb2xf b3BfZ2V0X2xpbmssDQogfTsNCiANCiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2UgKg0KQEAgLTE1 MjcsMjQgKzY1NiwyMiBAQCBhdTEwMDBfcHJvYmUodTMyIGlvYWRkciwgaW50IGlycSwgaW50IHBv DQogCQlwcmludGsoS0VSTl9FUlIgIiVzOiBiYWQgaW9hZGRyXG4iLCBkZXYtPm5hbWUpOw0KIAl9 DQogDQotCS8qIGJyaW5nIHRoZSBkZXZpY2Ugb3V0IG9mIHJlc2V0LCBvdGhlcndpc2UgcHJvYmlu ZyB0aGUgbWlpDQotCSAqIHdpbGwgaGFuZyAqLw0KLQkqYXVwLT5lbmFibGUgPSBNQUNfRU5fQ0xP Q0tfRU5BQkxFOw0KLQlhdV9zeW5jX2RlbGF5KDIpOw0KLQkqYXVwLT5lbmFibGUgPSBNQUNfRU5f UkVTRVQwIHwgTUFDX0VOX1JFU0VUMSB8IA0KLQkJTUFDX0VOX1JFU0VUMiB8IE1BQ19FTl9DTE9D S19FTkFCTEU7DQotCWF1X3N5bmNfZGVsYXkoMik7DQorCSphdXAtPmVuYWJsZSA9IDA7DQorCWF1 cC0+bWFjX2VuYWJsZWQgPSAwOw0KIA0KLQlhdXAtPm1paSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVj dCBtaWlfcGh5KSwgR0ZQX0tFUk5FTCk7DQotCWlmICghYXVwLT5taWkpIHsNCi0JCXByaW50ayhL RVJOX0VSUiAiJXM6IG91dCBvZiBtZW1vcnlcbiIsIGRldi0+bmFtZSk7DQotCQlnb3RvIGVycl9v dXQ7DQorCWF1cC0+bWlpX2J1cy5wcml2ID0gZGV2Ow0KKwlhdXAtPm1paV9idXMucmVhZCA9IG1k aW9idXNfcmVhZDsNCisJYXVwLT5taWlfYnVzLndyaXRlID0gbWRpb2J1c193cml0ZTsNCisJYXVw LT5taWlfYnVzLnJlc2V0ID0gbWRpb2J1c19yZXNldDsNCisJYXVwLT5taWlfYnVzLm5hbWUgPSAi YXUxMDAwX2V0aF9taWkiOw0KKwlhdXAtPm1paV9idXMuaWQgPSBhdXAtPm1hY19pZDsNCisJYXVw LT5taWlfYnVzLmlycSA9IGttYWxsb2Moc2l6ZW9mKGludCkqUEhZX01BWF9BRERSLCBHRlBfS0VS TkVMKTsNCisJZm9yKGkgPSAwOyBpIDwgUEhZX01BWF9BRERSOyArK2kpIHsNCisJCWF1cC0+bWlp X2J1cy5waHlfbWFwW2ldID0gTlVMTDsgLyogcGFyYW5vaWEgKi8NCisJCWF1cC0+bWlpX2J1cy5p cnFbaV0gPSBQSFlfUE9MTDsNCiAJfQ0KLQlhdXAtPm1paS0+bmV4dCA9IE5VTEw7DQotCWF1cC0+ bWlpLT5jaGlwX2luZm8gPSBOVUxMOw0KLQlhdXAtPm1paS0+c3RhdHVzID0gMDsNCi0JYXVwLT5t aWktPm1paV9jb250cm9sX3JlZyA9IDA7DQotCWF1cC0+bWlpLT5taWlfZGF0YV9yZWcgPSAwOw0K Kw0KKwltZGlvYnVzX3JlZ2lzdGVyKCZhdXAtPm1paV9idXMpOw0KIA0KIAlpZiAobWlpX3Byb2Jl KGRldikgIT0gMCkgew0KIAkJZ290byBlcnJfb3V0Ow0KQEAgLTE1OTAsNyArNzE3LDYgQEAgYXUx MDAwX3Byb2JlKHUzMiBpb2FkZHIsIGludCBpcnEsIGludCBwbw0KIAlkZXYtPnNldF9tdWx0aWNh c3RfbGlzdCA9ICZzZXRfcnhfbW9kZTsNCiAJZGV2LT5kb19pb2N0bCA9ICZhdTEwMDBfaW9jdGw7 DQogCVNFVF9FVEhUT09MX09QUyhkZXYsICZhdTEwMDBfZXRodG9vbF9vcHMpOw0KLQlkZXYtPnNl dF9jb25maWcgPSAmYXUxMDAwX3NldF9jb25maWc7DQogCWRldi0+dHhfdGltZW91dCA9IGF1MTAw MF90eF90aW1lb3V0Ow0KIAlkZXYtPndhdGNoZG9nX3RpbWVvID0gRVRIX1RYX1RJTUVPVVQ7DQog DQpAQCAtMTYwNiw3ICs3MzIsNyBAQCBlcnJfb3V0Og0KIAkvKiBoZXJlIHdlIHNob3VsZCBoYXZl IGEgdmFsaWQgZGV2IHBsdXMgYXVwLT4gcmVnaXN0ZXIgYWRkcmVzc2VzDQogCSAqIHNvIHdlIGNh biByZXNldCB0aGUgbWFjIHByb3Blcmx5LiovDQogCXJlc2V0X21hYyhkZXYpOw0KLQlrZnJlZShh dXAtPm1paSk7DQorDQogCWZvciAoaSA9IDA7IGkgPCBOVU1fUlhfRE1BOyBpKyspIHsNCiAJCWlm IChhdXAtPnJ4X2RiX2ludXNlW2ldKQ0KIAkJCVJlbGVhc2VEQihhdXAsIGF1cC0+cnhfZGJfaW51 c2VbaV0pOw0KQEAgLTE2NDAsMTkgKzc2NiwxNCBAQCBzdGF0aWMgaW50IGF1MTAwMF9pbml0KHN0 cnVjdCBuZXRfZGV2aWNlDQogCXUzMiBmbGFnczsNCiAJaW50IGk7DQogCXUzMiBjb250cm9sOw0K LQl1MTYgbGluaywgc3BlZWQ7DQogDQogCWlmIChhdTEwMDBfZGVidWcgPiA0KSANCiAJCXByaW50 aygiJXM6IGF1MTAwMF9pbml0XG4iLCBkZXYtPm5hbWUpOw0KIA0KLQlzcGluX2xvY2tfaXJxc2F2 ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQotDQogCS8qIGJyaW5nIHRoZSBkZXZpY2Ugb3V0IG9mIHJl c2V0ICovDQotCSphdXAtPmVuYWJsZSA9IE1BQ19FTl9DTE9DS19FTkFCTEU7DQotICAgICAgICBh dV9zeW5jX2RlbGF5KDIpOw0KLQkqYXVwLT5lbmFibGUgPSBNQUNfRU5fUkVTRVQwIHwgTUFDX0VO X1JFU0VUMSB8IA0KLQkJTUFDX0VOX1JFU0VUMiB8IE1BQ19FTl9DTE9DS19FTkFCTEU7DQotCWF1 X3N5bmNfZGVsYXkoMjApOw0KKwllbmFibGVfbWFjKGRldiwgMSk7DQorDQorCXNwaW5fbG9ja19p cnFzYXZlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCiANCiAJYXVwLT5tYWMtPmNvbnRyb2wgPSAwOw0K IAlhdXAtPnR4X2hlYWQgPSAoYXVwLT50eF9kbWFfcmluZ1swXS0+YnVmZl9zdGF0ICYgMHhDKSA+ PiAyOw0KQEAgLTE2NjgsMTMgKzc4OSwxNSBAQCBzdGF0aWMgaW50IGF1MTAwMF9pbml0KHN0cnVj dCBuZXRfZGV2aWNlDQogCX0NCiAJYXVfc3luYygpOw0KIA0KLQlhdXAtPnBoeV9vcHMtPnBoeV9z dGF0dXMoZGV2LCBhdXAtPnBoeV9hZGRyLCAmbGluaywgJnNwZWVkKTsNCi0JY29udHJvbCA9IE1B Q19ESVNBQkxFX1JYX09XTiB8IE1BQ19SWF9FTkFCTEUgfCBNQUNfVFhfRU5BQkxFOw0KKwljb250 cm9sID0gTUFDX1JYX0VOQUJMRSB8IE1BQ19UWF9FTkFCTEU7IC8qIGZpeG1lOiBzZXQgTUFDX0RJ U0FCTEVfT1dOX1JYIHdoZW4gbmVjZXNzYXJ5ICg9PSAhRFVQTEVYICYmICJub3JtYWwgb3BlcmF0 aW9uIikgKi8NCiAjaWZuZGVmIENPTkZJR19DUFVfTElUVExFX0VORElBTg0KIAljb250cm9sIHw9 IE1BQ19CSUdfRU5ESUFOOw0KICNlbmRpZg0KLQlpZiAobGluayAmJiAoZGV2LT5pZl9wb3J0ID09 IElGX1BPUlRfMTAwQkFTRUZYKSkgew0KLQkJY29udHJvbCB8PSBNQUNfRlVMTF9EVVBMRVg7DQor CWlmIChhdXAtPnBoeV9kZXYpIHsNCisJCWlmIChhdXAtPnBoeV9kZXYtPmxpbmsgJiYgYXVwLT5w aHlfZGV2LT5kdXBsZXgpIA0KKwkJCWNvbnRyb2wgfD0gTUFDX0ZVTExfRFVQTEVYOyANCisJfSBl bHNlIHsgLyogUEhZLWxlc3Mgb3AsIGFzc3VtZSBmdWxsLWR1cGxleCAqLw0KKwkJY29udHJvbCB8 PSBNQUNfRlVMTF9EVVBMRVg7IA0KIAl9DQogDQogCWF1cC0+bWFjLT5jb250cm9sID0gY29udHJv bDsNCkBAIC0xNjg1LDU3ICs4MDgsNzUgQEAgc3RhdGljIGludCBhdTEwMDBfaW5pdChzdHJ1Y3Qg bmV0X2RldmljZQ0KIAlyZXR1cm4gMDsNCiB9DQogDQotc3RhdGljIHZvaWQgYXUxMDAwX3RpbWVy KHVuc2lnbmVkIGxvbmcgZGF0YSkNCitzdGF0aWMgdm9pZA0KK2F1MTAwMF9hZGp1c3RfbGluayhz dHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KIHsNCi0Jc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IChz dHJ1Y3QgbmV0X2RldmljZSAqKWRhdGE7DQogCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0g KHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQotCXVuc2lnbmVkIGNoYXIgaWZf cG9ydDsNCi0JdTE2IGxpbmssIHNwZWVkOw0KKwlzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2ID0g YXVwLT5waHlfZGV2Ow0KKwl1bnNpZ25lZCBsb25nIGZsYWdzOw0KIA0KLQlpZiAoIWRldikgew0K LQkJLyogZmF0YWwgZXJyb3IsIGRvbid0IHJlc3RhcnQgdGhlIHRpbWVyICovDQotCQlwcmludGso S0VSTl9FUlIgImF1MTAwMF90aW1lciBlcnJvcjogTlVMTCBkZXZcbiIpOw0KLQkJcmV0dXJuOw0K LQl9DQorCWludCBzdGF0dXNfY2hhbmdlID0gMDsNCiANCi0JaWZfcG9ydCA9IGRldi0+aWZfcG9y dDsNCi0JaWYgKGF1cC0+cGh5X29wcy0+cGh5X3N0YXR1cyhkZXYsIGF1cC0+cGh5X2FkZHIsICZs aW5rLCAmc3BlZWQpID09IDApIHsNCi0JCWlmIChsaW5rKSB7DQotCQkJaWYgKCFuZXRpZl9jYXJy aWVyX29rKGRldikpIHsNCi0JCQkJbmV0aWZfY2Fycmllcl9vbihkZXYpOw0KLQkJCQlwcmludGso S0VSTl9JTkZPICIlczogbGluayB1cFxuIiwgZGV2LT5uYW1lKTsNCi0JCQl9DQotCQl9DQotCQll bHNlIHsNCi0JCQlpZiAobmV0aWZfY2Fycmllcl9vayhkZXYpKSB7DQotCQkJCW5ldGlmX2NhcnJp ZXJfb2ZmKGRldik7DQotCQkJCWRldi0+aWZfcG9ydCA9IDA7DQotCQkJCXByaW50ayhLRVJOX0lO Rk8gIiVzOiBsaW5rIGRvd25cbiIsIGRldi0+bmFtZSk7DQotCQkJfQ0KKwlCVUdfT04oIWF1cC0+ cGh5X2Rldik7DQorDQorCXNwaW5fbG9ja19pcnFzYXZlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCisN CisJaWYgKHBoeWRldi0+bGluayAmJiAoYXVwLT5vbGRfc3BlZWQgIT0gcGh5ZGV2LT5zcGVlZCkp IHsNCisJCS8vIHNwZWVkIGNoYW5nZWQgDQorDQorCQlzd2l0Y2gocGh5ZGV2LT5zcGVlZCkgew0K KwkJY2FzZSAxMDoNCisJCWNhc2UgMTAwOg0KKwkJCWJyZWFrOw0KKwkJZGVmYXVsdDoNCisJCQlw cmludGsoS0VSTl9XQVJOSU5HDQorCQkJICAgICAgICIlczogU3BlZWQgKCVkKSBpcyBub3QgMTAv MTAwLzEwMDAgPz9cbiIsDQorCQkJICAgICAgIGRldi0+bmFtZSwgcGh5ZGV2LT5zcGVlZCk7DQor CQkJYnJlYWs7DQogCQl9DQorDQorCQlhdXAtPm9sZF9zcGVlZCA9IHBoeWRldi0+c3BlZWQ7DQor DQorCQlzdGF0dXNfY2hhbmdlID0gMTsNCiAJfQ0KIA0KLQlpZiAobGluayAmJiAoZGV2LT5pZl9w b3J0ICE9IGlmX3BvcnQpICYmIA0KLQkJCShkZXYtPmlmX3BvcnQgIT0gSUZfUE9SVF9VTktOT1dO KSkgew0KKwlpZiAocGh5ZGV2LT5saW5rICYmIChhdXAtPm9sZF9kdXBsZXggIT0gcGh5ZGV2LT5k dXBsZXgpKSB7DQorCQkvLyBkdXBsZXggbW9kZSBjaGFuZ2VkDQorCQkNCisJCS8qIHN3aXRjaGlu ZyBkdXBsZXggbW9kZSByZXF1aXJlcyB0byBkaXNhYmxlIHJ4IGFuZCB0eCEgKi8NCiAJCWhhcmRf c3RvcChkZXYpOw0KLQkJaWYgKGRldi0+aWZfcG9ydCA9PSBJRl9QT1JUXzEwMEJBU0VGWCkgew0K LQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBnb2luZyB0byBmdWxsIGR1cGxleFxuIiwgDQotCQkJ CQlkZXYtPm5hbWUpOw0KKw0KKwkJaWYgKHBoeWRldi0+ZHVwbGV4KQ0KIAkJCWF1cC0+bWFjLT5j b250cm9sIHw9IE1BQ19GVUxMX0RVUExFWDsNCi0JCQlhdV9zeW5jX2RlbGF5KDEpOw0KLQkJfQ0K LQkJZWxzZSB7DQorCQllbHNlDQogCQkJYXVwLT5tYWMtPmNvbnRyb2wgJj0gfk1BQ19GVUxMX0RV UExFWDsNCi0JCQlhdV9zeW5jX2RlbGF5KDEpOw0KLQkJfQ0KKwkJYXVfc3luY19kZWxheSgxKTsN CisNCiAJCWVuYWJsZV9yeF90eChkZXYpOw0KKwkJYXVwLT5vbGRfZHVwbGV4ID0gcGh5ZGV2LT5k dXBsZXg7DQorDQorCQlzdGF0dXNfY2hhbmdlID0gMTsNCisJfQ0KKw0KKwlpZihwaHlkZXYtPmxp bmsgIT0gYXVwLT5vbGRfbGluaykgew0KKwkJLy8gbGluayBzdGF0ZSBjaGFuZ2VkDQorDQorCQlp ZiAocGh5ZGV2LT5saW5rKSB7IC8vIGxpbmsgd2VudCB1cA0KKwkJCW5ldGlmX3NjaGVkdWxlKGRl dik7DQorCQl9IGVsc2UgeyAvLyBsaW5rIHdlbnQgZG93bg0KKwkJCWF1cC0+b2xkX3NwZWVkID0g MDsNCisJCQlhdXAtPm9sZF9kdXBsZXggPSAtMTsNCisJCX0NCisNCisJCWF1cC0+b2xkX2xpbmsg PSBwaHlkZXYtPmxpbms7DQorCQlzdGF0dXNfY2hhbmdlID0gMTsNCiAJfQ0KIA0KLQlhdXAtPnRp bWVyLmV4cGlyZXMgPSBSVU5fQVQoKDEqSFopKTsgDQotCWF1cC0+dGltZXIuZGF0YSA9ICh1bnNp Z25lZCBsb25nKWRldjsNCi0JYXVwLT50aW1lci5mdW5jdGlvbiA9ICZhdTEwMDBfdGltZXI7IC8q IHRpbWVyIGhhbmRsZXIgKi8NCi0JYWRkX3RpbWVyKCZhdXAtPnRpbWVyKTsNCisJc3Bpbl91bmxv Y2tfaXJxcmVzdG9yZSgmYXVwLT5sb2NrLCBmbGFncyk7DQogDQorCWlmIChzdGF0dXNfY2hhbmdl KSB7DQorCQlwaHlfcHJpbnRfc3RhdHVzKHBoeWRldik7DQorCX0NCiB9DQogDQogc3RhdGljIGlu dCBhdTEwMDBfb3BlbihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KQEAgLTE3NDYsMTMgKzg4Nyw2 IEBAIHN0YXRpYyBpbnQgYXUxMDAwX29wZW4oc3RydWN0IG5ldF9kZXZpY2UNCiAJaWYgKGF1MTAw MF9kZWJ1ZyA+IDQpDQogCQlwcmludGsoIiVzOiBvcGVuOiBkZXY9JXBcbiIsIGRldi0+bmFtZSwg ZGV2KTsNCiANCi0JaWYgKChyZXR2YWwgPSBhdTEwMDBfaW5pdChkZXYpKSkgew0KLQkJcHJpbnRr KEtFUk5fRVJSICIlczogZXJyb3IgaW4gYXUxMDAwX2luaXRcbiIsIGRldi0+bmFtZSk7DQotCQlm cmVlX2lycShkZXYtPmlycSwgZGV2KTsNCi0JCXJldHVybiByZXR2YWw7DQotCX0NCi0JbmV0aWZf c3RhcnRfcXVldWUoZGV2KTsNCi0NCiAJaWYgKChyZXR2YWwgPSByZXF1ZXN0X2lycShkZXYtPmly cSwgJmF1MTAwMF9pbnRlcnJ1cHQsIDAsIA0KIAkJCQkJZGV2LT5uYW1lLCBkZXYpKSkgew0KIAkJ cHJpbnRrKEtFUk5fRVJSICIlczogdW5hYmxlIHRvIGdldCBJUlEgJWRcbiIsIA0KQEAgLTE3NjAs MTEgKzg5NCwxNiBAQCBzdGF0aWMgaW50IGF1MTAwMF9vcGVuKHN0cnVjdCBuZXRfZGV2aWNlDQog CQlyZXR1cm4gcmV0dmFsOw0KIAl9DQogDQotCWluaXRfdGltZXIoJmF1cC0+dGltZXIpOyAvKiB1 c2VkIGluIGlvY3RsKCkgKi8NCi0JYXVwLT50aW1lci5leHBpcmVzID0gUlVOX0FUKCgzKkhaKSk7 IA0KLQlhdXAtPnRpbWVyLmRhdGEgPSAodW5zaWduZWQgbG9uZylkZXY7DQotCWF1cC0+dGltZXIu ZnVuY3Rpb24gPSAmYXUxMDAwX3RpbWVyOyAvKiB0aW1lciBoYW5kbGVyICovDQotCWFkZF90aW1l cigmYXVwLT50aW1lcik7DQorCWlmICgocmV0dmFsID0gYXUxMDAwX2luaXQoZGV2KSkpIHsNCisJ CXByaW50ayhLRVJOX0VSUiAiJXM6IGVycm9yIGluIGF1MTAwMF9pbml0XG4iLCBkZXYtPm5hbWUp Ow0KKwkJZnJlZV9pcnEoZGV2LT5pcnEsIGRldik7DQorCQlyZXR1cm4gcmV0dmFsOw0KKwl9DQor DQorCWlmIChhdXAtPnBoeV9kZXYpDQorCQlwaHlfc3RhcnQoYXVwLT5waHlfZGV2KTsNCisNCisJ bmV0aWZfc3RhcnRfcXVldWUoZGV2KTsNCiANCiAJaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQogCQlw cmludGsoIiVzOiBvcGVuOiBJbml0aWFsaXphdGlvbiBkb25lLlxuIiwgZGV2LT5uYW1lKTsNCkBA IC0xNzg3LDYgKzkyNiw5IEBAIHN0YXRpYyBpbnQgYXUxMDAwX2Nsb3NlKHN0cnVjdCBuZXRfZGV2 aWMNCiAJLyogc3RvcCB0aGUgZGV2aWNlICovDQogCW5ldGlmX3N0b3BfcXVldWUoZGV2KTsNCiAN CisJaWYgKGF1cC0+cGh5X2RldikNCisJCXBoeV9zdG9wKGF1cC0+cGh5X2Rldik7DQorDQogCS8q IGRpc2FibGUgdGhlIGludGVycnVwdCAqLw0KIAlmcmVlX2lycShkZXYtPmlycSwgZGV2KTsNCiAJ c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYXVwLT5sb2NrLCBmbGFncyk7DQpAQCAtMTgwNSw3ICs5 NDcsNyBAQCBzdGF0aWMgdm9pZCBfX2V4aXQgYXUxMDAwX2NsZWFudXBfbW9kdWxlDQogCQlpZiAo ZGV2KSB7DQogCQkJYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQog CQkJdW5yZWdpc3Rlcl9uZXRkZXYoZGV2KTsNCi0JCQlrZnJlZShhdXAtPm1paSk7DQorDQogCQkJ Zm9yIChqID0gMDsgaiA8IE5VTV9SWF9ETUE7IGorKykgew0KIAkJCQlpZiAoYXVwLT5yeF9kYl9p bnVzZVtqXSkNCiAJCQkJCVJlbGVhc2VEQihhdXAsIGF1cC0+cnhfZGJfaW51c2Vbal0pOw0KQEAg LTE4MzAsNyArOTcyLDcgQEAgc3RhdGljIHZvaWQgdXBkYXRlX3R4X3N0YXRzKHN0cnVjdCBuZXRf ZA0KIAlzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqcHMgPSAmYXVwLT5zdGF0czsNCiANCiAJaWYg KHN0YXR1cyAmIFRYX0ZSQU1FX0FCT1JURUQpIHsNCi0JCWlmIChkZXYtPmlmX3BvcnQgPT0gSUZf UE9SVF8xMDBCQVNFRlgpIHsNCisJCWlmICghYXVwLT5waHlfZGV2IHx8IGF1cC0+cGh5X2Rldi0+ ZHVwbGV4KSB7DQogCQkJaWYgKHN0YXR1cyAmIChUWF9KQUJfVElNRU9VVCB8IFRYX1VOREVSUlVO KSkgew0KIAkJCQkvKiBhbnkgb3RoZXIgdHggZXJyb3JzIGFyZSBvbmx5IHZhbGlkDQogCQkJCSAq IGluIGhhbGYgZHVwbGV4IG1vZGUgKi8NCkBAIC0yMTA0LDEyNiArMTI0NiwxNSBAQCBzdGF0aWMg dm9pZCBzZXRfcnhfbW9kZShzdHJ1Y3QgbmV0X2RldmljDQogCX0NCiB9DQogDQotDQogc3RhdGlj IGludCBhdTEwMDBfaW9jdGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICpy cSwgaW50IGNtZCkNCiB7DQogCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBh dTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JdTE2ICpkYXRhID0gKHUxNiAqKSZycS0+aWZy X2lmcnU7DQogDQotCXN3aXRjaChjbWQpIHsgDQotCQljYXNlIFNJT0NERVZQUklWQVRFOgkvKiBH ZXQgdGhlIGFkZHJlc3Mgb2YgdGhlIFBIWSBpbiB1c2UuICovDQotCQljYXNlIFNJT0NHTUlJUEhZ Og0KLQkJICAgICAgICBpZiAoIW5ldGlmX3J1bm5pbmcoZGV2KSkgcmV0dXJuIC1FSU5WQUw7DQot CQkJZGF0YVswXSA9IGF1cC0+cGh5X2FkZHI7DQotCQljYXNlIFNJT0NERVZQUklWQVRFKzE6CS8q IFJlYWQgdGhlIHNwZWNpZmllZCBNSUkgcmVnaXN0ZXIuICovDQotCQljYXNlIFNJT0NHTUlJUkVH Og0KLQkJCWRhdGFbM10gPSAgbWRpb19yZWFkKGRldiwgZGF0YVswXSwgZGF0YVsxXSk7IA0KLQkJ CXJldHVybiAwOw0KLQkJY2FzZSBTSU9DREVWUFJJVkFURSsyOgkvKiBXcml0ZSB0aGUgc3BlY2lm aWVkIE1JSSByZWdpc3RlciAqLw0KLQkJY2FzZSBTSU9DU01JSVJFRzogDQotCQkJaWYgKCFjYXBh YmxlKENBUF9ORVRfQURNSU4pKQ0KLQkJCQlyZXR1cm4gLUVQRVJNOw0KLQkJCW1kaW9fd3JpdGUo ZGV2LCBkYXRhWzBdLCBkYXRhWzFdLGRhdGFbMl0pOw0KLQkJCXJldHVybiAwOw0KLQkJZGVmYXVs dDoNCi0JCQlyZXR1cm4gLUVPUE5PVFNVUFA7DQotCX0NCi0NCi19DQorCWlmICghbmV0aWZfcnVu bmluZyhkZXYpKSByZXR1cm4gLUVJTlZBTDsNCiANCisJaWYgKCFhdXAtPnBoeV9kZXYpIHJldHVy biAtRUlOVkFMOyAvLyBQSFkgbm90IGNvbnRyb2xsYWJsZQ0KIA0KLXN0YXRpYyBpbnQgYXUxMDAw X3NldF9jb25maWcoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmbWFwICptYXApDQot ew0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUg KikgZGV2LT5wcml2Ow0KLQl1MTYgY29udHJvbDsNCi0NCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQp ICB7DQotCQlwcmludGsoIiVzOiBzZXRfY29uZmlnIGNhbGxlZDogZGV2LT5pZl9wb3J0ICVkIG1h cC0+cG9ydCAleFxuIiwgDQotCQkJCWRldi0+bmFtZSwgZGV2LT5pZl9wb3J0LCBtYXAtPnBvcnQp Ow0KLQl9DQotDQotCXN3aXRjaChtYXAtPnBvcnQpew0KLQkJY2FzZSBJRl9QT1JUX1VOS05PV046 IC8qIHVzZSBhdXRvIGhlcmUgKi8gICANCi0JCQlwcmludGsoS0VSTl9JTkZPICIlczogY29uZmln IHBoeSBmb3IgYW5lZ1xuIiwgDQotCQkJCQlkZXYtPm5hbWUpOw0KLQkJCWRldi0+aWZfcG9ydCA9 IG1hcC0+cG9ydDsNCi0JCQkvKiBMaW5rIERvd246IHRoZSB0aW1lciB3aWxsIGJyaW5nIGl0IHVw ICovDQotCQkJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsNCi0JDQotCQkJLyogcmVhZCBjdXJyZW50 IGNvbnRyb2wgKi8NCi0JCQljb250cm9sID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQkJCWNvbnRyb2wgJj0gfihNSUlfQ05UTF9GRFggfCBNSUlfQ05UTF9G MTAwKTsNCi0NCi0JCQkvKiBlbmFibGUgYXV0byBuZWdvdGlhdGlvbiBhbmQgcmVzZXQgdGhlIG5l Z290aWF0aW9uICovDQotCQkJbWRpb193cml0ZShkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9DT05U Uk9MLCANCi0JCQkJCWNvbnRyb2wgfCBNSUlfQ05UTF9BVVRPIHwgDQotCQkJCQlNSUlfQ05UTF9S U1RfQVVUTyk7DQotDQotCQkJYnJlYWs7DQotICAgIA0KLQkJY2FzZSBJRl9QT1JUXzEwQkFTRVQ6 IC8qIDEwQmFzZVQgKi8gICAgICAgICANCi0JCQlwcmludGsoS0VSTl9JTkZPICIlczogY29uZmln IHBoeSBmb3IgMTBCYXNlVFxuIiwgDQotCQkJCQlkZXYtPm5hbWUpOw0KLQkJCWRldi0+aWZfcG9y dCA9IG1hcC0+cG9ydDsNCi0JDQotCQkJLyogTGluayBEb3duOiB0aGUgdGltZXIgd2lsbCBicmlu ZyBpdCB1cCAqLw0KLQkJCW5ldGlmX2NhcnJpZXJfb2ZmKGRldik7DQotDQotCQkJLyogc2V0IFNw ZWVkIHRvIDEwTWJwcywgSGFsZiBEdXBsZXggKi8NCi0JCQljb250cm9sID0gbWRpb19yZWFkKGRl diwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJCWNvbnRyb2wgJj0gfihNSUlfQ05U TF9GMTAwIHwgTUlJX0NOVExfQVVUTyB8IA0KLQkJCQkJTUlJX0NOVExfRkRYKTsNCi0JDQotCQkJ LyogZGlzYWJsZSBhdXRvIG5lZ290aWF0aW9uIGFuZCBmb3JjZSAxME0vSEQgbW9kZSovDQotCQkJ bWRpb193cml0ZShkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9DT05UUk9MLCBjb250cm9sKTsNCi0J CQlicmVhazsNCi0gICAgDQotCQljYXNlIElGX1BPUlRfMTAwQkFTRVQ6IC8qIDEwMEJhc2VUICov DQotCQljYXNlIElGX1BPUlRfMTAwQkFTRVRYOiAvKiAxMDBCYXNlVHggKi8gDQotCQkJcHJpbnRr KEtFUk5fSU5GTyAiJXM6IGNvbmZpZyBwaHkgZm9yIDEwMEJhc2VUWFxuIiwgDQotCQkJCQlkZXYt Pm5hbWUpOw0KLQkJCWRldi0+aWZfcG9ydCA9IG1hcC0+cG9ydDsNCi0JDQotCQkJLyogTGluayBE b3duOiB0aGUgdGltZXIgd2lsbCBicmluZyBpdCB1cCAqLw0KLQkJCW5ldGlmX2NhcnJpZXJfb2Zm KGRldik7DQotCQ0KLQkJCS8qIHNldCBTcGVlZCB0byAxMDBNYnBzLCBIYWxmIER1cGxleCAqLw0K LQkJCS8qIGRpc2FibGUgYXV0byBuZWdvdGlhdGlvbiBhbmQgZW5hYmxlIDEwME1CaXQgTW9kZSAq Lw0KLQkJCWNvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQ09OVFJP TCk7DQotCQkJY29udHJvbCAmPSB+KE1JSV9DTlRMX0FVVE8gfCBNSUlfQ05UTF9GRFgpOw0KLQkJ CWNvbnRyb2wgfD0gTUlJX0NOVExfRjEwMDsNCi0JCQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlf YWRkciwgTUlJX0NPTlRST0wsIGNvbnRyb2wpOw0KLQkJCWJyZWFrOw0KLSAgICANCi0JCWNhc2Ug SUZfUE9SVF8xMDBCQVNFRlg6IC8qIDEwMEJhc2VGeCAqLw0KLQkJCXByaW50ayhLRVJOX0lORk8g IiVzOiBjb25maWcgcGh5IGZvciAxMDBCYXNlRlhcbiIsIA0KLQkJCQkJZGV2LT5uYW1lKTsNCi0J CQlkZXYtPmlmX3BvcnQgPSBtYXAtPnBvcnQ7DQotCQ0KLQkJCS8qIExpbmsgRG93bjogdGhlIHRp bWVyIHdpbGwgYnJpbmcgaXQgdXAgKi8NCi0JCQluZXRpZl9jYXJyaWVyX29mZihkZXYpOw0KLQkN Ci0JCQkvKiBzZXQgU3BlZWQgdG8gMTAwTWJwcywgRnVsbCBEdXBsZXggKi8NCi0JCQkvKiBkaXNh YmxlIGF1dG8gbmVnb3RpYXRpb24gYW5kIGVuYWJsZSAxMDBNQml0IE1vZGUgKi8NCi0JCQljb250 cm9sID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJCWNv bnRyb2wgJj0gfk1JSV9DTlRMX0FVVE87DQotCQkJY29udHJvbCB8PSAgTUlJX0NOVExfRjEwMCB8 IE1JSV9DTlRMX0ZEWDsNCi0JCQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NP TlRST0wsIGNvbnRyb2wpOw0KLQkJCWJyZWFrOw0KLQkJY2FzZSBJRl9QT1JUXzEwQkFTRTI6IC8q IDEwQmFzZTIgKi8NCi0JCWNhc2UgSUZfUE9SVF9BVUk6IC8qIEFVSSAqLw0KLQkJLyogVGhlc2Ug TW9kZXMgYXJlIG5vdCBzdXBwb3J0ZWQgKGFyZSB0aGV5PykqLw0KLQkJCXByaW50ayhLRVJOX0VS UiAiJXM6IDEwQmFzZTIvQVVJIG5vdCBzdXBwb3J0ZWQiLCANCi0JCQkJCWRldi0+bmFtZSk7DQot CQkJcmV0dXJuIC1FT1BOT1RTVVBQOw0KLQkJCWJyZWFrOw0KLSAgICANCi0JCWRlZmF1bHQ6DQot CQkJcHJpbnRrKEtFUk5fRVJSICIlczogSW52YWxpZCBtZWRpYSBzZWxlY3RlZCIsIA0KLQkJCQkJ ZGV2LT5uYW1lKTsNCi0JCQlyZXR1cm4gLUVJTlZBTDsNCi0JfQ0KLQlyZXR1cm4gMDsNCisJcmV0 dXJuIHBoeV9taWlfaW9jdGwoYXVwLT5waHlfZGV2LCBpZl9taWkocnEpLCBjbWQpOw0KIH0NCiAN CiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKmF1MTAwMF9nZXRfc3RhdHMoc3RydWN0 IG5ldF9kZXZpY2UgKmRldikNCkBAIC0yMjQxLDMgKzEyNzIsMTQgQEAgc3RhdGljIHN0cnVjdCBu ZXRfZGV2aWNlX3N0YXRzICphdTEwMDBfZw0KIA0KIG1vZHVsZV9pbml0KGF1MTAwMF9pbml0X21v ZHVsZSk7DQogbW9kdWxlX2V4aXQoYXUxMDAwX2NsZWFudXBfbW9kdWxlKTsNCisNCisvKg0KKyAq IE92ZXJyaWRlcyBmb3IgRW1hY3Mgc28gdGhhdCB3ZSBmb2xsb3cgTGludXMncyB0YWJiaW5nIHN0 eWxlLg0KKyAqIEVtYWNzIHdpbGwgbm90aWNlIHRoaXMgc3R1ZmYgYXQgdGhlIGVuZCBvZiB0aGUg ZmlsZSBhbmQgYXV0b21hdGljYWxseQ0KKyAqIGFkanVzdCB0aGUgc2V0dGluZ3MgZm9yIHRoaXMg YnVmZmVyIG9ubHkuICBUaGlzIG11c3QgcmVtYWluIGF0IHRoZSBlbmQNCisgKiBvZiB0aGUgZmls ZS4NCisgKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCisgKiBMb2NhbCB2YXJpYWJsZXM6DQorICogYy1m aWxlLXN0eWxlOiAibGludXgiDQorICogRW5kOg0KKyAqLw0KZGlmZiAtLWdpdCBhL2RyaXZlcnMv bmV0L2F1MTAwMF9ldGguaCBiL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguaA0KaW5kZXggY2NiMzVm YS4uNGVmNzRkYiAxMDA2NDQNCi0tLSBhL2RyaXZlcnMvbmV0L2F1MTAwMF9ldGguaA0KKysrIGIv ZHJpdmVycy9uZXQvYXUxMDAwX2V0aC5oDQpAQCAtNDAsMTIwICs0MCw2IEBADQogDQogI2RlZmlu ZSBNVUxUSUNBU1RfRklMVEVSX0xJTUlUIDY0DQogDQotLyogRklYTUUgDQotICogVGhlIFBIWSBk ZWZpbmVzIHNob3VsZCBiZSBpbiBhIHNlcGFyYXRlIGZpbGUuDQotICovDQotDQotLyogTUlJIHJl Z2lzdGVyIG9mZnNldHMgKi8NCi0jZGVmaW5lCU1JSV9DT05UUk9MIDB4MDAwMA0KLSNkZWZpbmUg TUlJX1NUQVRVUyAgMHgwMDAxDQotI2RlZmluZSBNSUlfUEhZX0lEMCAweDAwMDINCi0jZGVmaW5l CU1JSV9QSFlfSUQxIDB4MDAwMw0KLSNkZWZpbmUgTUlJX0FOQURWICAgMHgwMDA0DQotI2RlZmlu ZSBNSUlfQU5MUEFSICAweDAwMDUNCi0jZGVmaW5lIE1JSV9BRVhQICAgIDB4MDAwNg0KLSNkZWZp bmUgTUlJX0FORVhUICAgMHgwMDA3DQotI2RlZmluZSBNSUlfTFNJX1BIWV9DT05GSUcgMHgwMDEx DQotLyogU3RhdHVzIHJlZ2lzdGVyICovDQotI2RlZmluZSBNSUlfTFNJX1BIWV9TVEFUICAgMHgw MDEyDQotI2RlZmluZSBNSUlfQU1EX1BIWV9TVEFUICAgTUlJX0xTSV9QSFlfU1RBVA0KLSNkZWZp bmUgTUlJX0lOVEVMX1BIWV9TVEFUIDB4MDAxMQ0KLQ0KLSNkZWZpbmUgTUlJX0FVWF9DTlRSTCAg MHgwMDE4DQotLyogbWlpIHJlZ2lzdGVycyBzcGVjaWZpYyB0byBBTUQgNzlDOTAxICovDQotI2Rl ZmluZQlNSUlfU1RBVFVTX1NVTU1BUlkgPSAweDAwMTgNCi0NCi0vKiBNSUkgQ29udHJvbCByZWdp c3RlciBiaXQgZGVmaW5pdGlvbnMuICovDQotI2RlZmluZQlNSUlfQ05UTF9GRFggICAgICAweDAx MDANCi0jZGVmaW5lIE1JSV9DTlRMX1JTVF9BVVRPIDB4MDIwMA0KLSNkZWZpbmUJTUlJX0NOVExf SVNPTEFURSAgMHgwNDAwDQotI2RlZmluZSBNSUlfQ05UTF9QV1JEV04gICAweDA4MDANCi0jZGVm aW5lCU1JSV9DTlRMX0FVVE8gICAgIDB4MTAwMA0KLSNkZWZpbmUgTUlJX0NOVExfRjEwMCAgICAg MHgyMDAwDQotI2RlZmluZQlNSUlfQ05UTF9MUEJLICAgICAweDQwMDANCi0jZGVmaW5lIE1JSV9D TlRMX1JFU0VUICAgIDB4ODAwMA0KLQ0KLS8qIE1JSSBTdGF0dXMgcmVnaXN0ZXIgYml0ICAqLw0K LSNkZWZpbmUJTUlJX1NUQVRfRVhUICAgICAgICAweDAwMDEgDQotI2RlZmluZSBNSUlfU1RBVF9K QUIgICAgICAgIDB4MDAwMg0KLSNkZWZpbmUJTUlJX1NUQVRfTElOSyAgICAgICAweDAwMDQNCi0j ZGVmaW5lIE1JSV9TVEFUX0NBTl9BVVRPICAgMHgwMDA4DQotI2RlZmluZQlNSUlfU1RBVF9GQVVM VCAgICAgIDB4MDAxMCANCi0jZGVmaW5lIE1JSV9TVEFUX0FVVE9fRE9ORSAgMHgwMDIwDQotI2Rl ZmluZQlNSUlfU1RBVF9DQU5fVCAgICAgIDB4MDgwMA0KLSNkZWZpbmUgTUlJX1NUQVRfQ0FOX1Rf RkRYICAweDEwMDANCi0jZGVmaW5lCU1JSV9TVEFUX0NBTl9UWCAgICAgMHgyMDAwIA0KLSNkZWZp bmUgTUlJX1NUQVRfQ0FOX1RYX0ZEWCAweDQwMDANCi0jZGVmaW5lCU1JSV9TVEFUX0NBTl9UNCAg ICAgMHg4MDAwDQotDQotDQotI2RlZmluZQkJTUlJX0lEMV9PVUlfTE8JCTB4RkMwMAkvKiBsb3cg Yml0cyBvZiBPVUkgbWFzayAqLw0KLSNkZWZpbmUJCU1JSV9JRDFfTU9ERUwJCTB4MDNGMAkvKiBt b2RlbCBudW1iZXIgKi8NCi0jZGVmaW5lCQlNSUlfSUQxX1JFVgkJMHgwMDBGCS8qIG1vZGVsIG51 bWJlciAqLw0KLQ0KLS8qIE1JSSBOV0FZIFJlZ2lzdGVyIEJpdHMgLi4uDQotICAgdmFsaWQgZm9y IHRoZSBBTkFSIChBdXRvLU5lZ290aWF0aW9uIEFkdmVydGlzZW1lbnQpIGFuZA0KLSAgIEFOTFBB UiAoQXV0by1OZWdvdGlhdGlvbiBMaW5rIFBhcnRuZXIpIHJlZ2lzdGVycyAqLw0KLSNkZWZpbmUJ TUlJX05XQVlfTk9ERV9TRUwgMHgwMDFmDQotI2RlZmluZSBNSUlfTldBWV9DU01BX0NEICAweDAw MDENCi0jZGVmaW5lCU1JSV9OV0FZX1QJICAweDAwMjANCi0jZGVmaW5lIE1JSV9OV0FZX1RfRkRY ICAgIDB4MDA0MA0KLSNkZWZpbmUJTUlJX05XQVlfVFggICAgICAgMHgwMDgwDQotI2RlZmluZSBN SUlfTldBWV9UWF9GRFggICAweDAxMDANCi0jZGVmaW5lCU1JSV9OV0FZX1Q0ICAgICAgIDB4MDIw MCANCi0jZGVmaW5lIE1JSV9OV0FZX1BBVVNFICAgIDB4MDQwMCANCi0jZGVmaW5lCU1JSV9OV0FZ X1JGICAgICAgIDB4MjAwMCAvKiBSZW1vdGUgRmF1bHQgKi8NCi0jZGVmaW5lIE1JSV9OV0FZX0FD SyAgICAgIDB4NDAwMCAvKiBSZW1vdGUgQWNrbm93bGVkZ2UgKi8NCi0jZGVmaW5lCU1JSV9OV0FZ X05QICAgICAgIDB4ODAwMCAvKiBOZXh0IFBhZ2UgKEVuYWJsZSkgKi8NCi0NCi0vKiBtaWkgc3Rz b3V0IHJlZ2lzdGVyIGJpdHMgKi8NCi0jZGVmaW5lCU1JSV9TVFNPVVRfTElOS19GQUlMIDB4NDAw MA0KLSNkZWZpbmUJTUlJX1NUU09VVF9TUEQgICAgICAgMHgwMDgwDQotI2RlZmluZSBNSUlfU1RT T1VUX0RQTFggICAgICAweDAwNDANCi0NCi0vKiBtaWkgc3RzaWNzIHJlZ2lzdGVyIGJpdHMgKi8N Ci0jZGVmaW5lCU1JSV9TVFNJQ1NfU1BEICAgICAgIDB4ODAwMA0KLSNkZWZpbmUgTUlJX1NUU0lD U19EUExYICAgICAgMHg0MDAwDQotI2RlZmluZQlNSUlfU1RTSUNTX0xJTktTVFMgICAweDAwMDEN Ci0NCi0vKiBtaWkgc3Rzc3VtIHJlZ2lzdGVyIGJpdHMgKi8NCi0jZGVmaW5lCU1JSV9TVFNTVU1f TElOSyAgMHgwMDA4DQotI2RlZmluZSBNSUlfU1RTU1VNX0RQTFggIDB4MDAwNA0KLSNkZWZpbmUJ TUlJX1NUU1NVTV9BVVRPICAweDAwMDINCi0jZGVmaW5lIE1JSV9TVFNTVU1fU1BEICAgMHgwMDAx DQotDQotLyogbHNpIHBoeSBzdGF0dXMgcmVnaXN0ZXIgKi8NCi0jZGVmaW5lIE1JSV9MU0lfUEhZ X1NUQVRfRkRYCTB4MDA0MA0KLSNkZWZpbmUgTUlJX0xTSV9QSFlfU1RBVF9TUEQJMHgwMDgwDQot DQotLyogYW1kIHBoeSBzdGF0dXMgcmVnaXN0ZXIgKi8NCi0jZGVmaW5lIE1JSV9BTURfUEhZX1NU QVRfRkRYCTB4MDgwMA0KLSNkZWZpbmUgTUlJX0FNRF9QSFlfU1RBVF9TUEQJMHgwNDAwDQotDQot LyogaW50ZWwgcGh5IHN0YXR1cyByZWdpc3RlciAqLw0KLSNkZWZpbmUgTUlJX0lOVEVMX1BIWV9T VEFUX0ZEWAkweDAyMDANCi0jZGVmaW5lIE1JSV9JTlRFTF9QSFlfU1RBVF9TUEQJMHg0MDAwDQot DQotLyogQXV4aWxsaWFyeSBDb250cm9sL1N0YXR1cyBSZWdpc3RlciAqLw0KLSNkZWZpbmUgTUlJ X0FVWF9GRFggICAgICAweDAwMDENCi0jZGVmaW5lIE1JSV9BVVhfMTAwICAgICAgMHgwMDAyDQot I2RlZmluZSBNSUlfQVVYX0YxMDAgICAgIDB4MDAwNA0KLSNkZWZpbmUgTUlJX0FVWF9BTkVHICAg ICAweDAwMDgNCi0NCi10eXBlZGVmIHN0cnVjdCBtaWlfcGh5IHsNCi0Jc3RydWN0IG1paV9waHkg KiBuZXh0Ow0KLQlzdHJ1Y3QgbWlpX2NoaXBfaW5mbyAqIGNoaXBfaW5mbzsNCi0JdTE2IHN0YXR1 czsNCi0JdTMyICptaWlfY29udHJvbF9yZWc7DQotCXUzMiAqbWlpX2RhdGFfcmVnOw0KLX0gbWlp X3BoeV90Ow0KLQ0KLXN0cnVjdCBwaHlfb3BzIHsNCi0JaW50ICgqcGh5X2luaXQpIChzdHJ1Y3Qg bmV0X2RldmljZSAqLCBpbnQpOw0KLQlpbnQgKCpwaHlfcmVzZXQpIChzdHJ1Y3QgbmV0X2Rldmlj ZSAqLCBpbnQpOw0KLQlpbnQgKCpwaHlfc3RhdHVzKSAoc3RydWN0IG5ldF9kZXZpY2UgKiwgaW50 LCB1MTYgKiwgdTE2ICopOw0KLX07DQotDQogLyogDQogICogRGF0YSBCdWZmZXIgRGVzY3JpcHRv ci4gRGF0YSBidWZmZXJzIG11c3QgYmUgYWxpZ25lZCBvbiAzMiBieXRlIA0KICAqIGJvdW5kYXJ5 IGZvciBib3RoLCByZWNlaXZlIGFuZCB0cmFuc21pdC4NCkBAIC0yMDAsNyArODYsNiBAQCB0eXBl ZGVmIHN0cnVjdCBtYWNfcmVnIHsNCiANCiANCiBzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgew0KLQkN CiAJZGJfZGVzdF90ICpwREJmcmVlOw0KIAlkYl9kZXN0X3QgZGJbTlVNX1JYX0JVRkZTK05VTV9U WF9CVUZGU107DQogCXZvbGF0aWxlIHJ4X2RtYV90ICpyeF9kbWFfcmluZ1tOVU1fUlhfRE1BXTsN CkBAIC0yMTMsOSArOTgsMTYgQEAgc3RydWN0IGF1MTAwMF9wcml2YXRlIHsNCiAJdTMyIHR4X2Z1 bGw7DQogDQogCWludCBtYWNfaWQ7DQotCW1paV9waHlfdCAqbWlpOw0KLQlzdHJ1Y3QgbWlpX2lm X2luZm8gbWlpX2lmOw0KLQlzdHJ1Y3QgcGh5X29wcyAqcGh5X29wczsNCisNCisJaW50IG1hY19l bmFibGVkOyAgICAgICAvKiB3aGV0aGVyIE1BQyBpcyBjdXJyZW50bHkgZW5hYmxlZCBhbmQgcnVu bmluZyAocmVxLiBmb3IgbWRpbykgKi8NCisNCisJaW50IG9sZF9saW5rOyAgICAgICAgICAvKiB1 c2VkIGJ5IGF1MTAwMF9hZGp1c3RfbGluayAqLw0KKwlpbnQgb2xkX3NwZWVkOyANCisJaW50IG9s ZF9kdXBsZXg7DQorDQorCWludCBwaHlfYWRkcjsgICAgICAgICAgLyogcGh5IGFkZHJlc3MgKi8N CisJc3RydWN0IHBoeV9kZXZpY2UgKnBoeV9kZXY7DQorCXN0cnVjdCBtaWlfYnVzIG1paV9idXM7 DQogCQ0KIAkvKiBUaGVzZSB2YXJpYWJsZXMgYXJlIGp1c3QgZm9yIHF1aWNrIGFjY2VzcyB0byBj ZXJ0YWluIHJlZ3MgYWRkcmVzc2VzLiAqLw0KIAl2b2xhdGlsZSBtYWNfcmVnX3QgKm1hYzsgIC8q IG1hYyByZWdpc3RlcnMgICAgICAgICAgICAgICAgICAgICAgKi8gICANCkBAIC0yMjcsMTEgKzEx OSw5IEBAIHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSB7DQogCXU4ICpoYXNoX3RhYmxlOw0KIAl1MzIg aGFzaF9tb2RlOw0KIAl1MzIgaW50cl93b3JrX2RvbmU7IC8qIG51bWJlciBvZiBSeCBhbmQgVHgg cGt0cyBwcm9jZXNzZWQgaW4gdGhlIGlzciAqLw0KLQlpbnQgcGh5X2FkZHI7ICAgICAgICAgIC8q IHBoeSBhZGRyZXNzICovDQogCXUzMiBvcHRpb25zOyAgICAgICAgICAgLyogVXNlci1zZXR0YWJs ZSBtaXNjLiBkcml2ZXIgb3B0aW9ucy4gKi8NCiAJdTMyIGRydl9mbGFnczsNCi0JaW50IHdhbnRf YXV0b25lZzsNCisNCiAJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgc3RhdHM7DQotCXN0cnVjdCB0 aW1lcl9saXN0IHRpbWVyOw0KIAlzcGlubG9ja190IGxvY2s7ICAgICAgIC8qIFNlcmlhbGlzZSBh Y2Nlc3MgdG8gZGV2aWNlICovDQogfTsNCm== --=-7NBnvUkjbxuQTR5LDyMk-- --=-gG6GUuD/D7Sog08cBLNj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEWcaPSYHgZIg/QUIRAkEqAJwOBi225mr7PxQbS3l/F899bulpTACfamMT Aa5ZD35OuAOefKOpsPDnoq4= =SaYh -----END PGP SIGNATURE----- --=-gG6GUuD/D7Sog08cBLNj-- From giometti@enneenne.com Thu May 4 10:53:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 10:53:52 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:58521 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133624AbWEDJxn (ORCPT ); Thu, 4 May 2006 10:53:43 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbaWj-00016M-00 for ; Thu, 04 May 2006 11:53:41 +0200 Date: Thu, 4 May 2006 11:53:41 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: Porting Au1x000 USB host controller on u-boot Message-ID: <20060504095341.GB19913@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Hello, I'm trying to implement support for USB host into u-boot. I initialized the USB controller just as linux does, the EDs and the TDs look like good in memory but the controller seems not well reading them and on the bus I see random USB messages... I think that there could be some problem on memory coherency... some suggestion? Thanks, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From giometti@enneenne.com Thu May 4 11:11:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 11:11:23 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:14746 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133624AbWEDKLN (ORCPT ); Thu, 4 May 2006 11:11:13 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1Fbang-0001gm-00 for ; Thu, 04 May 2006 12:11:12 +0200 Date: Thu, 4 May 2006 12:11:12 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: [PATCH] Physical addresses fix for au1x00 serial driver Message-ID: <20060504101112.GC19913@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Hello, here: http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-serial-phys-addr a little patch (against «linux-2.6.16-stable» branch and tested on au1100 based board) to fix the addresses specification for the serial driver. With this patch at boot time we get: Serial: 8250/16550 driver $Revision: 1.90 $ 3 ports, IRQ sharing disabled serial8250.7: ttyS0 at MMIO 0x11100000 (irq = 0) is a 16550A serial8250.7: ttyS1 at MMIO 0x11200000 (irq = 1) is a 16550A serial8250.7: ttyS2 at MMIO 0x11400000 (irq = 3) is a 16550A and into procfs we read: wwpc:~# cat /proc/iomem 10100000-10200000 : au1xxx-ohci.0 10500000-1050ffff : eth-base 10520000-10520003 : eth-mac 11100000-1110001f : serial 11200000-1120001f : serial 11400000-1140001f : serial wwpc:~# cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:16550A port:11100000 irq:0 tx:3905 rx:39 RTS|CTS|DTR|DSR|CD|RI 1: uart:16550A port:11200000 irq:1 tx:0 rx:0 CTS|DSR|CD|RI 2: uart:16550A port:11400000 irq:3 tx:0 rx:0 CTS|DSR|CD|RI Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From freddy@dusktilldawn.nl Thu May 4 11:12:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 11:12:56 +0100 (BST) Received: from tool.snarl.nl ([213.84.251.124]:5058 "HELO tool.snarl.nl") by ftp.linux-mips.org with SMTP id S8133713AbWEDKMk (ORCPT ); Thu, 4 May 2006 11:12:40 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id 356125E5B2; Thu, 4 May 2006 12:12:34 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09015-01-2; Thu, 4 May 2006 12:12:33 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id D28865DF61; Thu, 4 May 2006 12:12:33 +0200 (CEST) Date: Thu, 4 May 2006 12:12:33 +0200 From: Freddy Spierenburg To: safiudeen Ts Cc: linux-mips@linux-mips.org Subject: Re: Linux-2.6.16 on DB1100 Message-ID: <20060504101233.GJ11097@dusktilldawn.nl> References: <20060504065657.GI11097@dusktilldawn.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2RPQY0WN3yNjQaZ" Content-Disposition: inline In-Reply-To: X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --p2RPQY0WN3yNjQaZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Safiudeen, On Thu, May 04, 2006 at 09:10:34AM +0000, safiudeen Ts wrote: > please tell me wether I should apply any patches to this Linux-2.6.16=20 > kernel to make it works with db1100 There do not exist patches that will help you with your problem. I do not know at the moment what exactly goes wrong, but I have a 2.6.16 kernel running on a db1100 without your problems. There do exist some small problems with the standard 2.6.16 git, but they are not related to your problem (IMHO). To help you out a bit I have put a minimal working kernel at http://snarl.nl/~freddy/misc/mips.linux-2.6.16-minimal/ Try the srec file and see what happens. Use the YAMON commands below, althought I tried your command's too and it booted. Althought it gave a kernel panic, since it was obviously not able to mount a root partition. This is because your command (the start environment variable in YAMON) is not compatible with the setup I have over here. YAMON> load tftp://192.168.0.5/vmlinux-2.6.16-minimal.srec YAMON> go . If this works for you, you can find at the URL mentioned above the config file I used to build the kernel and that should provide you with a starting point to continue exploring the system. At that same URL are two small patches that should solve the small problems with the standard 2.6.16 git I mentioned before. Good luck! --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --p2RPQY0WN3yNjQaZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWdORbxf9XXlB0eERAuRRAKCLnQ6atPzajVM4qEop1OijmceQ8ACeO/hN XWtLRIi9+CfaddBVzh81BAU= =pwAj -----END PGP SIGNATURE----- --p2RPQY0WN3yNjQaZ-- From sshtylyov@ru.mvista.com Thu May 4 13:45:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 13:45:56 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:20154 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133764AbWEDMpo (ORCPT ); Thu, 4 May 2006 13:45:44 +0100 Received: (qmail 24665 invoked from network); 4 May 2006 16:50:43 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 16:50:43 -0000 Message-ID: <4459F72D.4010408@ru.mvista.com> Date: Thu, 04 May 2006 16:44:29 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: linux-mips@linux-mips.org Subject: Re: [PATCH] Physical addresses fix for au1x00 serial driver References: <20060504101112.GC19913@gundam.enneenne.com> In-Reply-To: <20060504101112.GC19913@gundam.enneenne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Rodolfo Giometti wrote: > here: > > http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-au1x00-serial-phys-addr > a little patch (against «linux-2.6.16-stable» branch and tested on > au1100 based board) to fix the addresses specification for the serial > driver. With this patch at boot time we get: > Serial: 8250/16550 driver $Revision: 1.90 $ 3 ports, IRQ sharing disabled > serial8250.7: ttyS0 at MMIO 0x11100000 (irq = 0) is a 16550A > serial8250.7: ttyS1 at MMIO 0x11200000 (irq = 1) is a 16550A > serial8250.7: ttyS2 at MMIO 0x11400000 (irq = 3) is a 16550A I have already noticed and fixed this. The fix is in Andrew Morton's tree (unpublished yet). See this msg for the patch: http://www.linux-mips.org/archives/linux-mips/2006-04/msg00029.html > wwpc:~# cat /proc/iomem > 10100000-10200000 : au1xxx-ohci.0 > 10500000-1050ffff : eth-base > 10520000-10520003 : eth-mac > 11100000-1110001f : serial > 11200000-1120001f : serial > 11400000-1140001f : serial This is not quite correct. The UARTs take up 1 MB of memory each. > Ciao, > > Rodolfo WBR, Sergei From giometti@enneenne.com Thu May 4 14:24:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 14:24:34 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:49804 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133767AbWEDNYU (ORCPT ); Thu, 4 May 2006 14:24:20 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbdoT-000730-00; Thu, 04 May 2006 15:24:13 +0200 Date: Thu, 4 May 2006 15:24:13 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Physical addresses fix for au1x00 serial driver Message-ID: <20060504132413.GD19913@gundam.enneenne.com> References: <20060504101112.GC19913@gundam.enneenne.com> <4459F72D.4010408@ru.mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <4459F72D.4010408@ru.mvista.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 04:44:29PM +0400, Sergei Shtylyov wrote: > > I have already noticed and fixed this. The fix is in Andrew Morton's= =20 > tree (unpublished yet). See this msg for the patch: >=20 > http://www.linux-mips.org/archives/linux-mips/2006-04/msg00029.html I see. :) > This is not quite correct. The UARTs take up 1 MB of memory each. Yes, in my patch is missing this part: switch (up->port.iotype) { + case UPIO_AU: + size =3D 0x100000; + /* fall thru */ case UPIO_MEM: if (!up->port.mapbase) Are you already working on 8250_early for au1x00? I'm quite ready for the patch. :) Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWgB9QaTCYNJaVjMRAhmAAJ4g2r+R2UAZkQSZfa3ZO5rQbmsGBgCgmAAu q2iDVQHJdYzBUObGT43daU8= =tmEV -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a-- From giometti@enneenne.com Thu May 4 14:45:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 14:45:22 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:50657 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133530AbWEDNpL (ORCPT ); Thu, 4 May 2006 14:45:11 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1Fbe8j-0007l8-00 for ; Thu, 04 May 2006 15:45:09 +0200 Date: Thu, 4 May 2006 15:45:09 +0200 From: Rodolfo Giometti To: linux-mips@linux-mips.org Subject: [PATCH] 8250_early console support for au1x00 Message-ID: <20060504134509.GE19913@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips Done! :) Here the patch (against «linux-2.6.16-stable» and tested with au1100 based board): http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-patch-au1x00-early-console My kernel command line has now: console=uart,au,0x11100000,115200 so, I suppose, it's important that the serial lines physical addresses are specified as 0x11100000 and not as 0xB1100000! Please, note also the «know bugs» section. Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From giometti@enneenne.com Thu May 4 14:58:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 14:58:54 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:18111 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133530AbWEDN6p (ORCPT ); Thu, 4 May 2006 14:58:45 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbeLl-00083P-00; Thu, 04 May 2006 15:58:37 +0200 Date: Thu, 4 May 2006 15:58:37 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Physical addresses fix for au1x00 serial driver Message-ID: <20060504135837.GF19913@gundam.enneenne.com> References: <20060504101112.GC19913@gundam.enneenne.com> <4459F72D.4010408@ru.mvista.com> <20060504132413.GD19913@gundam.enneenne.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2" Content-Disposition: inline In-Reply-To: <20060504132413.GD19913@gundam.enneenne.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 03:24:13PM +0200, Rodolfo Giometti wrote: > > This is not quite correct. The UARTs take up 1 MB of memory each. The patch: diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 8365d5b..3473e7a 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -1935,8 +1935,10 @@ static int serial8250_request_std_resour int ret =3D 0; =20 switch (up->port.iotype) { - case UPIO_MEM: case UPIO_AU: + size =3D 0x100000; + /* fall thru */ + case UPIO_MEM: if (!up->port.mapbase) break; =20 I'll merge this patch with my previous one ASAP... Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWgiNQaTCYNJaVjMRAoKWAJ9DcU/sqJGWcku2Uf+iGivN8IwFggCfdt8V COLBKskHQHm3cE20wdnnwEw= =fh/K -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2-- From sshtylyov@ru.mvista.com Thu May 4 15:29:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 15:29:18 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:41709 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133769AbWEDO3D (ORCPT ); Thu, 4 May 2006 15:29:03 +0100 Received: (qmail 26685 invoked from network); 4 May 2006 18:34:03 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 18:34:03 -0000 Message-ID: <445A0F65.8060803@ru.mvista.com> Date: Thu, 04 May 2006 18:27:49 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: linux-mips@linux-mips.org Subject: Re: [PATCH] Physical addresses fix for au1x00 serial driver References: <20060504101112.GC19913@gundam.enneenne.com> <4459F72D.4010408@ru.mvista.com> <20060504132413.GD19913@gundam.enneenne.com> <20060504135837.GF19913@gundam.enneenne.com> In-Reply-To: <20060504135837.GF19913@gundam.enneenne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Rodolfo Giometti wrote: >>> This is not quite correct. The UARTs take up 1 MB of memory each. > The patch: > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c > index 8365d5b..3473e7a 100644 > --- a/drivers/serial/8250.c > +++ b/drivers/serial/8250.c > @@ -1935,8 +1935,10 @@ static int serial8250_request_std_resour > int ret = 0; > > switch (up->port.iotype) { > - case UPIO_MEM: > case UPIO_AU: > + size = 0x100000; > + /* fall thru */ > + case UPIO_MEM: > if (!up->port.mapbase) > break; > I'll merge this patch with my previous one ASAP... Better just use my patch. There's no sense in calling ioremp() on UART addresses. > Ciao, > > Rodolfo WBR, Sergei From hellokishore@gmail.com Thu May 4 15:30:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 15:30:22 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.194]:13759 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133772AbWEDOaL (ORCPT ); Thu, 4 May 2006 15:30:11 +0100 Received: by nz-out-0102.google.com with SMTP id z6so462226nzd for ; Thu, 04 May 2006 07:30:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UAS32J/0q4ZaLRcZ7gMQYK/8DYf+ODVc/SAyD+Ljkw0xT2NZyFqw/RJuoJnjxu8Y9FiPdxwRMjdYl6+m9lyiu0R8bMOeox7krtZ95XmsGTV9NrOC3RloDs81p1Ah53WueBwqSB1u5Ar0DyDryCSE7+EDVs+0rdKYqYCovoXGw/s= Received: by 10.36.121.12 with SMTP id t12mr627511nzc; Thu, 04 May 2006 07:30:04 -0700 (PDT) Received: by 10.36.49.4 with HTTP; Thu, 4 May 2006 07:30:04 -0700 (PDT) Message-ID: Date: Thu, 4 May 2006 20:00:04 +0530 From: "Kishore K" To: "linux-mips@linux-mips.org" Subject: Compilation problem with eepro100 in 2.6.16 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9997_33203890.1146753004401" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hellokishore@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_9997_33203890.1146753004401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline hi 2.6.16 kernel (from linux-mips) build is failing when enabled the support for eepro100 ethernet driver (error is given below). But, I don't see the same problem, if the kernel from kernel.org is used. I guess the problem is due to the changes in the files arch/mips/lib/iomap.c and include/asm-mips/io.h. In general, the problem is observed for all the drivers which use ioread*, iowrite* calls. I observe that changes are minimal between kernel.org and linux-mips branches for 2.6.16. May, I know, what is the current procedure being followed for taking the mips kernels? Is it from linux-mips or kernel.org ? Could you please advise. drivers/built-in.o(.text+0x27b8c): In function `do_slow_command': : undefined reference to `ioread8' drivers/built-in.o(.text+0x27bb4): In function `do_slow_command': : undefined reference to `ioread8' drivers/built-in.o(.text+0x27bd4): In function `do_slow_command': : undefined reference to `iowrite8' drivers/built-in.o(.text+0x27be4): In function `do_slow_command': : undefined reference to `ioread8' drivers/built-in.o(.text+0x27c08): In function `do_slow_command': : undefined reference to `ioread8' drivers/built-in.o(.text+0x27c44): In function `do_slow_command': : undefined reference to `ioread32' drivers/built-in.o(.text+0x27cb8): In function `mdio_read': : undefined reference to `iowrite32' drivers/built-in.o(.text+0x27cc0): In function `mdio_read': : undefined reference to `ioread32' drivers/built-in.o(.text+0x27d50): In function `mdio_write': : undefined reference to `iowrite32' drivers/built-in.o(.text+0x27d58): In function `mdio_write': : undefined reference to `ioread32' drivers/built-in.o(.text+0x27e48): In function `speedo_open': : undefined reference to `iowrite16' drivers/built-in.o(.text+0x27ed4): In function `speedo_open': : undefined reference to `ioread16' drivers/built-in.o(.text+0x27fbc): In function `speedo_resume': : undefined reference to `ioread8' drivers/built-in.o(.text+0x28008): In function `speedo_resume': : undefined reference to `iowrite32' drivers/built-in.o(.text+0x28038): In function `speedo_resume': : undefined reference to `iowrite32' drivers/built-in.o(.text+0x28040): In function `speedo_resume': : undefined reference to `ioread32' drivers/built-in.o(.text+0x28090): In function `speedo_resume': : undefined reference to `iowrite32' drivers/built-in.o(.text+0x28098): In function `speedo_resume': : undefined reference to `ioread32' drivers/built-in.o(.text+0x280a4): In function `speedo_resume': : undefined reference to `iowrite8' drivers/built-in.o(.text+0x280dc): In function `speedo_resume': Thanks, --kishore ------=_Part_9997_33203890.1146753004401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline hi
2.6.16 kernel (from linux-mips) build is failing when enabled the sup= port for eepro100 ethernet driver (error is given below). But, I don't see = the same problem, if the kernel from kernel.o= rg is used. I guess the problem is due to the changes in the files arch/m= ips/lib/iomap.c and include/asm-mips/io.h. In general, the problem is obser= ved for all the drivers which use ioread*, iowrite* calls.

I observe= that changes are minimal between=20 kernel.org and linux-mips branches for 2.= 6.16. May, I know, what is the current procedure being followed for taking = the mips kernels? Is it from linux-mips or ke= rnel.org ?  Could you please advise.


drivers/built-in.o(.text+0= x27b8c): In function `do_slow_command':
: undefined reference to `ioread= 8'
drivers/built-in.o(.text+0x27bb4): In function `do_slow_command':
= : undefined reference to `ioread8'
drivers/built-in.o(.text+0x27bd4): In function `do_slow_command':
: = undefined reference to `iowrite8'
drivers/built-in.o(.text+0x27be4): In = function `do_slow_command':
: undefined reference to `ioread8'
driver= s/built- in.o(.text+0x27c08): In function `do_slow_command':
: undefined referenc= e to `ioread8'
drivers/built-in.o(.text+0x27c44): In function `do_slow_c= ommand':
: undefined reference to `ioread32'
drivers/built-in.o(.text= +0x27cb8): In function `mdio_read':
: undefined reference to `iowrite32'
drivers/built-in.o(.text+0x27cc= 0): In function `mdio_read':
: undefined reference to `ioread32'
driv= ers/built-in.o(.text+0x27d50): In function `mdio_write':
: undefined ref= erence to `iowrite32'
drivers/built-in.o(.text+0x27d58): In function `mdio_write':
: undef= ined reference to `ioread32'
drivers/built-in.o(.text+0x27e48): In funct= ion `speedo_open':
: undefined reference to `iowrite16'
drivers/built= - in.o(.text+0x27ed4): In function `speedo_open':
: undefined reference to= `ioread16'
drivers/built-in.o(.text+0x27fbc): In function `speedo_resum= e':
: undefined reference to `ioread8'
drivers/built-in.o(.text+0x280= 08): In function `speedo_resume':
: undefined reference to `iowrite32'
drivers/built-in.o(.text+0x2803= 8): In function `speedo_resume':
: undefined reference to `iowrite32'drivers/built-in.o(.text+0x28040): In function `speedo_resume':
: undef= ined reference to `ioread32'
drivers/built-in.o(.text+0x28090): In function `speedo_resume':
: un= defined reference to `iowrite32'
drivers/built-in.o(.text+0x28098): In f= unction `speedo_resume':
: undefined reference to `ioread32'
drivers/= built- in.o(.text+0x280a4): In function `speedo_resume':
: undefined reference = to `iowrite8'
drivers/built-in.o(.text+0x280dc): In function `speedo_res= ume':

Thanks,
--kishore
------=_Part_9997_33203890.1146753004401-- From sshtylyov@ru.mvista.com Thu May 4 15:37:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 15:37:12 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:37762 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133530AbWEDOhB (ORCPT ); Thu, 4 May 2006 15:37:01 +0100 Received: (qmail 26866 invoked from network); 4 May 2006 18:42:01 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 18:42:01 -0000 Message-ID: <445A114B.4040404@ru.mvista.com> Date: Thu, 04 May 2006 18:35:55 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: linux-mips@linux-mips.org Subject: Re: [PATCH] 8250_early console support for au1x00 References: <20060504134509.GE19913@gundam.enneenne.com> In-Reply-To: <20060504134509.GE19913@gundam.enneenne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Rodolfo Giometti wrote: > Done! :) > > Here the patch (against «linux-2.6.16-stable» and tested with au1100 > based board): > > http://ftp.enneenne.com/pub/misc/au1100-patches/linux/patch-patch-au1x00-early-console The following 2 fragments are kind of contradictory: > --- a/drivers/serial/8250.c > +++ b/drivers/serial/8250.c > @@ -2322,16 +2322,18 @@ static int __init find_port(struct uart_ > > int __init serial8250_start_console(struct uart_port *port, char *options) > { > - int line; > + int line, mmio; > > line = find_port(port); > if (line < 0) > return -ENODEV; > > add_preferred_console("ttyS", line, options); > + mmio = (port->iotype == UPIO_MEM) || (port->iotype == UPIO_AU); > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : > + line, > + mmio ? "MMIO" : "I/O port", > + mmio ? (unsigned long) port->mapbase : > (unsigned long) port->iobase, options); > if (!(serial8250_console.flags & CON_ENABLED)) { > --- a/drivers/serial/8250_early.c > +++ b/drivers/serial/8250_early.c > @@ -232,22 +380,23 @@ static int __init early_uart_console_swi > { > struct early_uart_device *device = &early_device; > struct uart_port *port = &device->port; > - int mmio, line; > + int line; > > if (!(early_uart_console.flags & CON_ENABLED)) > return 0; > > /* Try to start the normal driver on a matching line. */ > - mmio = (port->iotype == UPIO_MEM); > line = serial8250_start_console(port, device->options); > if (line < 0) > printk("No ttyS device at %s 0x%lx for console\n", > - mmio ? "MMIO" : "I/O port", > - mmio ? port->mapbase : > + (port->iotype == UPIO_MEM) ? "MMIO" : \ > + (port->iotype == UPIO_AU) ? "AU" : "I/O port", > + (port->iotype == UPIO_MEM) || \ > + (port->iotype == UPIO_AU) ? port->mapbase : > (unsigned long) port->iobase); > > unregister_console(&early_uart_console); > - if (mmio) > + if ((port->iotype == UPIO_MEM) || (port->iotype == UPIO_AU)) > iounmap(port->membase); Why the different code here? I suggest sticking to the 8250.c variant... And, as I said. there's not much sense in calling iomap() on Alchemy UART, UPIO_IOREMAP flag wasn't really needed... > Please, note also the «know bugs» section. You propably meant "known bugs"? :-) > Ciao, > > Rodolfo WBR, Sergei From giometti@enneenne.com Thu May 4 16:20:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 16:21:02 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:47288 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133705AbWEDPUx (ORCPT ); Thu, 4 May 2006 16:20:53 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbfdI-00023N-00; Thu, 04 May 2006 17:20:48 +0200 Date: Thu, 4 May 2006 17:20:48 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] 8250_early console support for au1x00 Message-ID: <20060504152048.GG19913@gundam.enneenne.com> References: <20060504134509.GE19913@gundam.enneenne.com> <445A114B.4040404@ru.mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n/aVsWSeQ4JHkrmm" Content-Disposition: inline In-Reply-To: <445A114B.4040404@ru.mvista.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --n/aVsWSeQ4JHkrmm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 06:35:55PM +0400, Sergei Shtylyov wrote: >=20 > The following 2 fragments are kind of contradictory: I see, but I decided to keep it different since the kernel message is: Adding console on ttyS0 at MMIO 0x11100000 (options '115200') and setting it as: Adding console on ttyS0 at AU 0x11100000 (options '115200') sounds bad to me. :) > And, as I said. there's not much sense in calling iomap() on Alchemy UART= ,=20 > UPIO_IOREMAP flag wasn't really needed... Mmm... to be =ABcoherent=BB I think it should be done... > You propably meant "known bugs"? :-) Yes. :) Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --n/aVsWSeQ4JHkrmm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWhvQQaTCYNJaVjMRAkK5AJ99/hmRiOCZn0oRqYcOHl9E68FARQCfc1jb lr22cJFb+HqnkL3ee+d5WME= =xLQ8 -----END PGP SIGNATURE----- --n/aVsWSeQ4JHkrmm-- From sshtylyov@ru.mvista.com Thu May 4 16:49:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 16:50:05 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:60815 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133518AbWEDPty (ORCPT ); Thu, 4 May 2006 16:49:54 +0100 Received: (qmail 27896 invoked from network); 4 May 2006 19:54:54 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 19:54:54 -0000 Message-ID: <445A225F.7090300@ru.mvista.com> Date: Thu, 04 May 2006 19:48:47 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: linux-mips@linux-mips.org Subject: Re: [PATCH] 8250_early console support for au1x00 References: <20060504134509.GE19913@gundam.enneenne.com> <445A114B.4040404@ru.mvista.com> <20060504152048.GG19913@gundam.enneenne.com> In-Reply-To: <20060504152048.GG19913@gundam.enneenne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Rodolfo Giometti wrote: > On Thu, May 04, 2006 at 06:35:55PM +0400, Sergei Shtylyov wrote: >> The following 2 fragments are kind of contradictory: > I see, but I decided to keep it different since the kernel message is: > Adding console on ttyS0 at MMIO 0x11100000 (options '115200') > and setting it as: > Adding console on ttyS0 at AU 0x11100000 (options '115200') > sounds bad to me. :) Yes. But the error msg emmitted by your patch would look this way, i.e. AU, not MMIO. No symmetry. :-) >>And, as I said. there's not much sense in calling iomap() on Alchemy UART, >>UPIO_IOREMAP flag wasn't really needed... > > > Mmm... to be «coherent» I think it should be done... Wouldn't hurt, just useless. So, I think no special checks are needed to avoid it. :-) > Ciao, > > Rodolfo WBR, Sergei From giometti@enneenne.com Thu May 4 17:33:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 17:33:24 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:10184 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133518AbWEDQdH (ORCPT ); Thu, 4 May 2006 17:33:07 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbglB-00044M-00; Thu, 04 May 2006 18:33:01 +0200 Date: Thu, 4 May 2006 18:33:01 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] 8250_early console support for au1x00 Message-ID: <20060504163301.GH19913@gundam.enneenne.com> References: <20060504134509.GE19913@gundam.enneenne.com> <445A114B.4040404@ru.mvista.com> <20060504152048.GG19913@gundam.enneenne.com> <445A225F.7090300@ru.mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WK3l2KTTmXPVedZ6" Content-Disposition: inline In-Reply-To: <445A225F.7090300@ru.mvista.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 07:48:47PM +0400, Sergei Shtylyov wrote: >=20 > Yes. But the error msg emmitted by your patch would look this way, i.e= =2E=20 > AU, not MMIO. No symmetry. :-) Ah! Now I see... ok, I'll fix it! :) > Wouldn't hurt, just useless. So, I think no special checks are needed = to=20 > avoid it. :-) If don't hurt I think we should use the physical address instead of KSEG1... Ciao, Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWiy9QaTCYNJaVjMRAhXAAJ9VMKjO+nzc0X9sZUOKh6DPg0XN8QCfUB8M NNVeAQUmNB2n7EE5OfWtiYA= =pscU -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6-- From sshtylyov@ru.mvista.com Thu May 4 18:07:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 18:07:24 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:1950 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133518AbWEDRHJ (ORCPT ); Thu, 4 May 2006 18:07:09 +0100 Received: (qmail 28823 invoked from network); 4 May 2006 21:12:09 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 21:12:09 -0000 Message-ID: <445A347A.5050507@ru.mvista.com> Date: Thu, 04 May 2006 21:06:02 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: Linux-MIPS Subject: Re: Porting Au1x000 USB host controller on u-boot References: <20060504095341.GB19913@gundam.enneenne.com> In-Reply-To: <20060504095341.GB19913@gundam.enneenne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, Rodolfo Giometti wrote: > I'm trying to implement support for USB host into u-boot. I > initialized the USB controller just as linux does, the EDs and the TDs > look like good in memory but the controller seems not well reading > them and on the bus I see random USB messages... > > I think that there could be some problem on memory coherency... some > suggestion? Be sure to set Config0.OD (bit 19), it's proven to fix the USB-related lockups on Au1500 at least. See arch/mips/common/cputable.c for the CPU steppings where it must be set to mask various errata. Also, try to disable USB controller's DMA coherency in the USB enable register (there's a related errata in all Au1xx0 family) -- the Linux driver doesn't do this though, and this shouldn't matter unless you're modifying USB buffers on the fly. :-) Also, note that this magic bit may be write only, so make sure it's set on every write to CP0 Config0 reg. See this patch: http://www.linux-mips.org/archives/linux-mips/2006-03/msg00243.html > Thanks, > > Rodolfo WBR, Sergei From sshtylyov@ru.mvista.com Thu May 4 18:11:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 18:11:22 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:18334 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133518AbWEDRLI (ORCPT ); Thu, 4 May 2006 18:11:08 +0100 Received: (qmail 28949 invoked from network); 4 May 2006 21:16:09 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 21:16:09 -0000 Message-ID: <445A356A.9010701@ru.mvista.com> Date: Thu, 04 May 2006 21:10:02 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: Linux-MIPS Subject: Re: Porting Au1x000 USB host controller on u-boot References: <20060504095341.GB19913@gundam.enneenne.com> <445A347A.5050507@ru.mvista.com> In-Reply-To: <445A347A.5050507@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, Sergei Shtylyov wrote: >> I'm trying to implement support for USB host into u-boot. I >> initialized the USB controller just as linux does, the EDs and the TDs >> look like good in memory but the controller seems not well reading >> them and on the bus I see random USB messages... >> I think that there could be some problem on memory coherency... some >> suggestion? > Be sure to set Config0.OD (bit 19), it's proven to fix the > USB-related lockups on Au1500 at least. See arch/mips/common/cputable.c arch/mips/au1000/common/cputable.c, I mean... :-) WBR, Sergei From sshtylyov@ru.mvista.com Thu May 4 18:17:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 18:17:37 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:32927 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133530AbWEDRR1 (ORCPT ); Thu, 4 May 2006 18:17:27 +0100 Received: (qmail 29000 invoked from network); 4 May 2006 21:22:28 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 21:22:28 -0000 Message-ID: <445A36E3.4010809@ru.mvista.com> Date: Thu, 04 May 2006 21:16:19 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 CC: Rodolfo Giometti , Linux-MIPS Subject: Re: Porting Au1x000 USB host controller on u-boot References: <20060504095341.GB19913@gundam.enneenne.com> <445A347A.5050507@ru.mvista.com> In-Reply-To: <445A347A.5050507@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, I wrote: >> I'm trying to implement support for USB host into u-boot. I >> initialized the USB controller just as linux does, the EDs and the TDs >> look like good in memory but the controller seems not well reading >> them and on the bus I see random USB messages... >> I think that there could be some problem on memory coherency... some >> suggestion? > try to disable USB controller's DMA coherency in the USB enable register > (there's a related errata in all Au1xx0 family) -- the Linux driver > doesn't do this though, and this shouldn't matter unless you're > modifying USB buffers on the fly. :-) AND make sure every buffer/TD/ED is written back / invalidated from cache before the OHCI accesses them since the cache coherency on Au1xx0 is b0rken! WBR, Sergei From giometti@enneenne.com Thu May 4 18:21:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 18:22:02 +0100 (BST) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:7309 "EHLO gundam.enneenne.com") by ftp.linux-mips.org with ESMTP id S8133518AbWEDRVj (ORCPT ); Thu, 4 May 2006 18:21:39 +0100 Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian)) id 1FbhW7-0005WE-00; Thu, 04 May 2006 19:21:31 +0200 Date: Thu, 4 May 2006 19:21:31 +0200 From: Rodolfo Giometti To: Sergei Shtylyov Cc: Linux-MIPS Subject: Re: Porting Au1x000 USB host controller on u-boot Message-ID: <20060504172131.GF7357@gundam.enneenne.com> References: <20060504095341.GB19913@gundam.enneenne.com> <445A347A.5050507@ru.mvista.com> <445A36E3.4010809@ru.mvista.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y/WcH0a6A93yCHGr" Content-Disposition: inline In-Reply-To: <445A36E3.4010809@ru.mvista.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@linux.it Precedence: bulk X-list: linux-mips --Y/WcH0a6A93yCHGr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 04, 2006 at 09:16:19PM +0400, Sergei Shtylyov wrote: >=20 > AND make sure every buffer/TD/ED is written back / invalidated from=20 > cache before the OHCI accesses them since the cache coherency on Au1xx= 0 is=20 > b0rken! Mmm... good suggestion! :) How can I invalidated the cache? Can you please show me some example code? Thanks _a lot_! Rodolfo --=20 GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --Y/WcH0a6A93yCHGr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEWjgbQaTCYNJaVjMRArzZAKDbR9h/h07zo5VhM54zg1hX55l7yQCg3H3y qHeyoBwXiUpZnX9SDR4Ce60= =bXLh -----END PGP SIGNATURE----- --Y/WcH0a6A93yCHGr-- From sshtylyov@ru.mvista.com Thu May 4 18:27:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 18:28:09 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:55972 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133518AbWEDR1z (ORCPT ); Thu, 4 May 2006 18:27:55 +0100 Received: (qmail 29110 invoked from network); 4 May 2006 21:32:56 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 4 May 2006 21:32:56 -0000 Message-ID: <445A3959.3050906@ru.mvista.com> Date: Thu, 04 May 2006 21:26:49 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Rodolfo Giometti CC: Linux-MIPS Subject: Re: Porting Au1x000 USB host controller on u-boot References: <20060504095341.GB19913@gundam.enneenne.com> <445A347A.5050507@ru.mvista.com> <445A36E3.4010809@ru.mvista.com> <20060504172131.GF7357@gundam.enneenne.com> In-Reply-To: <20060504172131.GF7357@gundam.enneenne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Rodolfo Giometti wrote: >> AND make sure every buffer/TD/ED is written back / invalidated from >> cache before the OHCI accesses them since the cache coherency on Au1xx0 is >>b0rken! Or, better yet, access TD/ED (and, if possible, the buffers) via uncached KSEG1 only. > Mmm... good suggestion! :) How can I invalidated the cache? Can you > please show me some example code? Dig in arch/mips/mm/c-r4k.c... > Thanks _a lot_! > > Rodolfo WBR, Sergei From vagabon.xyz@gmail.com Thu May 4 19:34:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 19:34:38 +0100 (BST) Received: from nz-out-0102.google.com ([64.233.162.196]:64721 "EHLO nz-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133769AbWEDSeT convert rfc822-to-8bit (ORCPT ); Thu, 4 May 2006 19:34:19 +0100 Received: by nz-out-0102.google.com with SMTP id z6so522857nzd for ; Thu, 04 May 2006 11:34:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=keiYSPhCOzg8cvq6TcK3URUoZKqFg+gX5YGAC07hya5kRIlLMhcQmQouQQkQKm9l+gwBErK37OZZjEnEVJFmbGyHII4Uuv/nVP+/0Sj1kHhNvfz4+dLCYddHaanFKQjWErpA/VWga7+9gydNxPDlhbBnL8+cRJU3d9xOOJAcai4= Received: by 10.36.160.18 with SMTP id i18mr1468778nze; Thu, 04 May 2006 11:34:18 -0700 (PDT) Received: by 10.36.49.2 with HTTP; Thu, 4 May 2006 11:34:18 -0700 (PDT) Message-ID: Date: Thu, 4 May 2006 20:34:18 +0200 From: "Franck Bui-Huu" To: "Thiemo Seufer" Subject: Re: [PATCH] Make interrupt handler works for all cases Cc: "Ralf Baechle" , linux-mips In-Reply-To: <20060502180436.GH5004@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20060502094123.GB4301@linux-mips.org> <20060502104441.GA5004@networkno.de> <20060502180436.GH5004@networkno.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips 2006/5/2, Thiemo Seufer : > Franck Bui-Huu wrote: > > 2006/5/2, Thiemo Seufer : > > >Franck Bui-Huu wrote: > > >> 2006/5/2, Ralf Baechle : > > >> >On Tue, May 02, 2006 at 09:55:51AM +0200, Franck Bui-Huu wrote: > > >> > > > >> >> specially when the kernel is mapped. > > >> > > > >> >At which time you're on very fragile ice because TLB instructions should > > >> >better be executed from an unmapped address ... > > >> > > > >> > > >> well TLB entry used by the kernel is wired, so it should work fined, > > >> shouldn't it ? > > > > > >The architecture spec doesn't guarantee it will. > > > > having a quick look at the TLB handling code, it seems that the code > > assumes it will... > > I don't know which code you are looking at, but the kernel's TLB > handling doesn't run in mapped space. (The ip27 is an exception, > I assume the R1x000 allows for mapped TLB handling.) > I have assumed the same for r4k cpu and it seems to work fine... Anyways, Ralf can you apply this patch ? Thanks -- Franck From tim.bird@am.sony.com Thu May 4 20:35:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 20:35:48 +0100 (BST) Received: from mail8.fw-sd.sony.com ([160.33.66.75]:22919 "EHLO mail8.fw-sd.sony.com") by ftp.linux-mips.org with ESMTP id S8133786AbWEDTfd (ORCPT ); Thu, 4 May 2006 20:35:33 +0100 Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id k44JZQ4n000702 for ; Thu, 4 May 2006 19:35:26 GMT Received: from [43.134.85.135] ([43.134.85.135]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id k44JZP7a021702 for ; Thu, 4 May 2006 19:35:26 GMT Message-ID: <445A577D.7090507@am.sony.com> Date: Thu, 04 May 2006 12:35:25 -0700 From: Tim Bird User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tim.bird@am.sony.com Precedence: bulk X-list: linux-mips The following patch allows to build using CROSS_COMPILE from the environment. I have an automated system which works like this, but it chokes on MIPS when I use it with (albeit non-standard-named) cross-compiler tools. An easy workaround I'm using is to put CROSS_COMPILE on the make command line, but it would be nice to use the definition already in the environment when I work manually in the system. For past discussion of this see: http://www.linux-mips.org/archives/linux-mips/2003-02/msg00196.html I'm not sure why the change didn't make it in back in 2003, but if the complaint was about the use of "?=", that seems to be in use other places, and fairly standard now. For example, from the top level kernel Makefile: ARCH ?= $(SUBARCH) CROSS_COMPILE ?= Signed-off-by: Tim Bird --- --- alp-linux.orig/arch/mips/Makefile 2006-05-04 12:22:17.000000000 -0700 +++ alp-linux/arch/mips/Makefile 2006-05-04 12:10:22.000000000 -0700 @@ -49,7 +49,7 @@ UTS_MACHINE := mips64 endif ifdef CONFIG_CROSSCOMPILE -CROSS_COMPILE = $(tool-prefix) +CROSS_COMPILE ?= $(tool-prefix) endif CHECKFLAGS-y += -D__linux__ -D__mips__ \ From ths@networkno.de Thu May 4 21:55:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 21:55:47 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:43976 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133800AbWEDUzg (ORCPT ); Thu, 4 May 2006 21:55:36 +0100 Received: from lagash (88-106-136-76.dynamic.dsl.as9105.com [88.106.136.76]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 86A9C441E5; Thu, 4 May 2006 22:55:35 +0200 (MEST) Received: from ths by lagash with local (Exim 4.61) (envelope-from ) id 1Fbkqz-0006Y1-KK; Thu, 04 May 2006 21:55:17 +0100 Date: Thu, 4 May 2006 21:55:17 +0100 To: Tim Bird Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504205517.GF18218@networkno.de> References: <445A577D.7090507@am.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445A577D.7090507@am.sony.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Tim Bird wrote: > The following patch allows to build using CROSS_COMPILE from the environment. > I have an automated system which works like this, but it chokes on MIPS when > I use it with (albeit non-standard-named) cross-compiler tools. An easy > workaround I'm using is to put CROSS_COMPILE on the make command line, but it would > be nice to use the definition already in the environment when I work > manually in the system. > > For past discussion of this see: > http://www.linux-mips.org/archives/linux-mips/2003-02/msg00196.html > > I'm not sure why the change didn't make it in back in 2003, but > if the complaint was about the use of "?=", that seems to be in use > other places, and fairly standard now. > > For example, from the top level kernel Makefile: > ARCH ?= $(SUBARCH) > CROSS_COMPILE ?= It looks like the other arch-specific Makefiles also override the environment. To work around the problem, you can disable CONFIG_CROSSCOMPILE and define CROSS_COMPILE in the environment. Strangely enough, the help for CONFIG_CROSSCOMPILE already explains that. Thiemo From trini@kernel.crashing.org Thu May 4 22:04:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 22:05:09 +0100 (BST) Received: from fed1rmmtao04.cox.net ([68.230.241.35]:3249 "HELO fed1rmmtao04.cox.net") by ftp.linux-mips.org with SMTP id S8133786AbWEDVE5 (ORCPT ); Thu, 4 May 2006 22:04:57 +0100 Received: from opus ([68.110.9.227]) by fed1rmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060504210449.VKUZ17501.fed1rmmtao04.cox.net@opus>; Thu, 4 May 2006 17:04:49 -0400 Date: Thu, 4 May 2006 14:04:49 -0700 From: Tom Rini To: Thiemo Seufer Cc: Tim Bird , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504210449.GA12676@smtp.west.cox.net> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060504205517.GF18218@networkno.de> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: trini@kernel.crashing.org Precedence: bulk X-list: linux-mips On Thu, May 04, 2006 at 09:55:17PM +0100, Thiemo Seufer wrote: > Tim Bird wrote: > > The following patch allows to build using CROSS_COMPILE from the environment. > > I have an automated system which works like this, but it chokes on MIPS when > > I use it with (albeit non-standard-named) cross-compiler tools. An easy > > workaround I'm using is to put CROSS_COMPILE on the make command line, but it would > > be nice to use the definition already in the environment when I work > > manually in the system. > > > > For past discussion of this see: > > http://www.linux-mips.org/archives/linux-mips/2003-02/msg00196.html > > > > I'm not sure why the change didn't make it in back in 2003, but > > if the complaint was about the use of "?=", that seems to be in use > > other places, and fairly standard now. > > > > For example, from the top level kernel Makefile: > > ARCH ?= $(SUBARCH) > > CROSS_COMPILE ?= > > It looks like the other arch-specific Makefiles also override the > environment. To work around the problem, you can disable > CONFIG_CROSSCOMPILE and define CROSS_COMPILE in the environment. > > Strangely enough, the help for CONFIG_CROSSCOMPILE already explains > that. Let me ask a stupid question. With all of the ways to otherwise do a cross compile, why a config option on MIPS? ARM*/SH*, which are at least as likely to not be native-compiled, don't do that. Just something I've always wondered, really. -- Tom Rini http://gate.crashing.org/~trini/ From tim.bird@am.sony.com Thu May 4 22:17:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 22:17:24 +0100 (BST) Received: from mail8.fw-sd.sony.com ([160.33.66.75]:44976 "EHLO mail8.fw-sd.sony.com") by ftp.linux-mips.org with ESMTP id S8133786AbWEDVRN (ORCPT ); Thu, 4 May 2006 22:17:13 +0100 Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id k44LH6Lw019953; Thu, 4 May 2006 21:17:06 GMT Received: from [43.134.85.135] ([43.134.85.135]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id k44LH58T016983; Thu, 4 May 2006 21:17:05 GMT Message-ID: <445A6F51.90308@am.sony.com> Date: Thu, 04 May 2006 14:17:05 -0700 From: Tim Bird User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Thiemo Seufer CC: linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> In-Reply-To: <20060504205517.GF18218@networkno.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tim.bird@am.sony.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > It looks like the other arch-specific Makefiles also override the > environment. 4 other arches I work with don't. > To work around the problem, you can disable > CONFIG_CROSSCOMPILE and define CROSS_COMPILE in the environment. I thought that might be the case, but that's pretty broken IMHO. It's counterintuitive and undocumented. > > Strangely enough, the help for CONFIG_CROSSCOMPILE already explains > that. Here's the help from my Kconfig.debug: Say Y here if you are compiling the kernel on a different architecture than the one it is intended to run on. Am I missing something? -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Electronics ============================= From kevink@mips.com Thu May 4 22:22:19 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 22:22:37 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:46728 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133797AbWEDVWT (ORCPT ); Thu, 4 May 2006 22:22:19 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k44LM0xV015453; Thu, 4 May 2006 14:22:01 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id k44LLx1O000609; Thu, 4 May 2006 14:22:00 -0700 (PDT) Message-ID: <028201c66fc1$4f724d20$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Tom Rini" , "Thiemo Seufer" Cc: "Tim Bird" , References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Date: Thu, 4 May 2006 23:25:46 +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 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > Let me ask a stupid question. With all of the ways to otherwise do a > cross compile, why a config option on MIPS? ARM*/SH*, which are at > least as likely to not be native-compiled, don't do that. Just > something I've always wondered, really. Probably because, unlike ARM and SH, the MIPS architecture began life as a workstation/server processor, and for a while there cross-compilation was the exception rather than the rule. Regards, Kevin K. From kevink@mips.com Thu May 4 22:28:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 22:29:13 +0100 (BST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:50824 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133797AbWEDV2y (ORCPT ); Thu, 4 May 2006 22:28:54 +0100 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k44LSiWd015499; Thu, 4 May 2006 14:28:44 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id k44LSgiR000803; Thu, 4 May 2006 14:28:43 -0700 (PDT) Message-ID: <028901c66fc2$3ff139f0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Kevin D. Kissell" , "Tom Rini" , "Thiemo Seufer" Cc: "Tim Bird" , References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> <028201c66fc1$4f724d20$10eca8c0@grendel> Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Date: Thu, 4 May 2006 23:32:29 +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 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > > Let me ask a stupid question. With all of the ways to otherwise do a > > cross compile, why a config option on MIPS? ARM*/SH*, which are at > > least as likely to not be native-compiled, don't do that. Just > > something I've always wondered, really. > > Probably because, unlike ARM and SH, the MIPS architecture began life > as a workstation/server processor, and for a while there cross-compilation > was the exception rather than the rule. Before anyone else jumps in, yeah, ARM was sort-of a workstation processor to begin with, too, but I don't think the original Acorn RISC Machine was set up to run a "real" OS, with memory management, etc., whereas MIPS was. Regards, Kevin K. From trini@kernel.crashing.org Thu May 4 22:44:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 22:44:35 +0100 (BST) Received: from fed1rmmtao11.cox.net ([68.230.241.28]:988 "HELO fed1rmmtao11.cox.net") by ftp.linux-mips.org with SMTP id S8133790AbWEDVoZ (ORCPT ); Thu, 4 May 2006 22:44:25 +0100 Received: from opus ([68.110.9.227]) by fed1rmmtao11.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060504214417.VUNH9215.fed1rmmtao11.cox.net@opus>; Thu, 4 May 2006 17:44:17 -0400 Date: Thu, 4 May 2006 14:44:17 -0700 From: Tom Rini To: "Kevin D. Kissell" Cc: Thiemo Seufer , Tim Bird , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504214417.GB12676@smtp.west.cox.net> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> <028201c66fc1$4f724d20$10eca8c0@grendel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <028201c66fc1$4f724d20$10eca8c0@grendel> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: trini@kernel.crashing.org Precedence: bulk X-list: linux-mips On Thu, May 04, 2006 at 11:25:46PM +0200, Kevin D. Kissell wrote: > > Let me ask a stupid question. With all of the ways to otherwise do a > > cross compile, why a config option on MIPS? ARM*/SH*, which are at > > least as likely to not be native-compiled, don't do that. Just > > something I've always wondered, really. > > Probably because, unlike ARM and SH, the MIPS architecture began life > as a workstation/server processor, and for a while there cross-compilation > was the exception rather than the rule. OK, PowerPC. My kinda question/point was perhaps it's time to deprecate CONFIG_CROSSCOMPILE in favor of env or make to bring it in line with other arches (similar to how 2.4 had a few ways for arch/$(ARCH)/*config/ dirs, 2.6 is uniform). -- Tom Rini http://gate.crashing.org/~trini/ From ths@networkno.de Thu May 4 23:35:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 23:36:16 +0100 (BST) Received: from bender.bawue.de ([193.7.176.20]:54494 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133797AbWEDWf5 (ORCPT ); Thu, 4 May 2006 23:35:57 +0100 Received: from lagash (88-106-136-76.dynamic.dsl.as9105.com [88.106.136.76]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 2493244BE2; Fri, 5 May 2006 00:35:57 +0200 (MEST) Received: from ths by lagash with local (Exim 4.61) (envelope-from ) id 1FbmQ7-000780-OZ; Thu, 04 May 2006 23:35:39 +0100 Date: Thu, 4 May 2006 23:35:39 +0100 From: Thiemo Seufer To: Tim Bird Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504223539.GG18218@networkno.de> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <445A6F51.90308@am.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445A6F51.90308@am.sony.com> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Tim Bird wrote: > Thiemo Seufer wrote: > > It looks like the other arch-specific Makefiles also override the > > environment. > > 4 other arches I work with don't. > > > To work around the problem, you can disable > > CONFIG_CROSSCOMPILE and define CROSS_COMPILE in the environment. > > I thought that might be the case, but that's pretty broken IMHO. > It's counterintuitive and undocumented. > > > > > Strangely enough, the help for CONFIG_CROSSCOMPILE already explains > > that. > > Here's the help from my Kconfig.debug: > > Say Y here if you are compiling the kernel on a different > architecture than the one it is intended to run on. > > Am I missing something? Update to a newer version: config CROSSCOMPILE bool "Are you using a crosscompiler" help Say Y here if you are compiling the kernel on a different architecture than the one it is intended to run on. This is just a convenience option which will select the appropriate value for the CROSS_COMPILE make variable which otherwise has to be passed on the command line from mips-linux-, mipsel-linux-, mips64-linux- and mips64el-linux- as appropriate for a particular kernel configuration. You will have to pass the value for CROSS_COMPILE manually if the name prefix for your tools is different. Thiemo From Marinus.DeJong@flir.com Thu May 4 23:56:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 May 2006 23:56:53 +0100 (BST) Received: from SBA.FLIR.com ([12.164.250.85]:52695 "EHLO coral.sba.flir.net") by ftp.linux-mips.org with ESMTP id S8133819AbWEDW4i (ORCPT ); Thu, 4 May 2006 23:56:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146783397" Subject: NPTL compatible versions of buildroot/gcc/uclibc ... Date: Thu, 4 May 2006 15:56:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NPTL compatible versions of buildroot/gcc/uclibc ... Thread-Index: AcZvn7hBKfhufCbBQGOYsBbuirdt7Q== From: "De Jong, Rienco" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marinus.DeJong@flir.com Precedence: bulk X-list: linux-mips ------=neXtPaRt_1146783397 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66FCD.FE7A427C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66FCD.FE7A427C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am trying to get the NPTL running on my au1200. I am running the linux-alchemy-src-2.6.11-r000055.tar.gz and have successfully run using linuxthreads on the target with the buildroot snapshot=20 buildroot-20060227.tar.bz2 and would now like to use the NPTL. I am using the uClibc library and saw on the web that the uClibc NPTL for MIPS was completed around the middle of March by Steve Hill (http://www.realitydiluted.com/nptl-uclibc). In my trolling on the web and mailing lists I couldn't find a diffinitive statement of a buildroot and gcc version that were compatible so I thought I should be able to get the latest version of buildroot and version 4.1.0 of gcc and be good to go. I took the buildroot-20060504 snapshot and started the build of buildroot but got the following error: =20 monetary_members.cc: In member function 'void std::moneypunct<_CharT, _Intl>::_M_initialize_moneypunct(int*, const char*) [with _CharT =3D wchar_t, bool _Intl =3D true]': monetary_members.cc:409: error: '__global_locale' was not declared in this scope monetary_members.cc: In member function 'void std::moneypunct<_CharT, _Intl>::_M_initialize_moneypunct(int*, const char*) [with _CharT =3D wchar_t, bool _Intl =3D false]': monetary_members.cc:564: error: '__global_locale' was not declared in this scope make[5]: *** [monetary_members.lo] Error 1 make[5]: Leaving directory `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-l inux-uclibc/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-l inux-uclibc/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-l inux-uclibc/libstdc++-v3' make[2]: *** [all-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final' make: *** [/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/.compile d] Error 2 =20 The uClibc is uClibc-0.9.28 The binutils is binutils-2.16.91.0.7 Is there an option I should have turned on? =20 Does anyone know what the correct combination of buildroot/toolchain that will give me the NPTL functionality? =20 Thanks, =20 Rienco ------_=_NextPart_001_01C66FCD.FE7A427C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am trying to get the NPTL running on my = au1200.  I am running the linux-alchemy-src-2.6.11-r000055.tar.gz and have = successfully run using linuxthreads on the target with the buildroot snapshot =

buildroot-20060227.tar.bz2 and would now like to use = the NPTL.  I am using the uClibc library and saw on the web that the = uClibc NPTL for MIPS was completed around the middle of March by Steve Hill (http://www.realitydilu= ted.com/nptl-uclibc).  In my trolling on the web and mailing lists I couldn't find a = diffinitive statement of a buildroot and gcc version that were compatible so I thought I = should be able to get the latest version of buildroot and version 4.1.0 of gcc and = be good to go.  I took the buildroot-20060504 snapshot and started the = build of buildroot but got the following error:

 

monetary_members.cc: In member function 'void std::moneypunct<_CharT, _Intl>::_M_initialize_moneypunct(int*, = const char*) [with _CharT =3D wchar_t, bool _Intl =3D = true]':

monetary_members.cc:409: error: '__global_locale' was = not declared in this scope

monetary_members.cc: In member function 'void std::moneypunct<_CharT, _Intl>::_M_initialize_moneypunct(int*, = const char*) [with _CharT =3D wchar_t, bool _Intl =3D = false]':

monetary_members.cc:564: error: '__global_locale' was = not declared in this scope

make[5]: *** [monetary_members.lo] Error = 1

make[5]: Leaving directory = `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-li= nux-uclibc/libstdc++-v3/src'

make[4]: *** [all-recursive] Error = 1

make[4]: Leaving directory = `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-li= nux-uclibc/libstdc++-v3'

make[3]: *** [all] Error 2

make[3]: Leaving directory = `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/mipsel-li= nux-uclibc/libstdc++-v3'

make[2]: *** [all-target-libstdc++-v3] Error = 2

make[2]: Leaving directory = `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final'

make[1]: *** [all] Error 2

make[1]: Leaving directory = `/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final'

make: *** = [/home/rdejong/buildroot/toolchain_build_mipsel/gcc-4.1.0-final/.compiled= ] Error 2

 

The uClibc is uClibc-0.9.28

The binutils is = binutils-2.16.91.0.7

Is there an option I should have turned = on?

 

Does anyone know what the correct combination of buildroot/toolchain that will give me the NPTL = functionality?

 

Thanks,

 

Rienco

------_=_NextPart_001_01C66FCD.FE7A427C-- ------=neXtPaRt_1146783397 Content-Type: text/plain; ********************************************************************** Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. ********************************************************************** ------=neXtPaRt_1146783397-- From ralf@linux-mips.org Fri May 5 00:06:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 00:06:59 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:26844 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133813AbWEDXGv (ORCPT ); Fri, 5 May 2006 00:06:51 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k44N6mdF005319; Fri, 5 May 2006 00:06:48 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k44N6lQq005318; Fri, 5 May 2006 00:06:47 +0100 Date: Fri, 5 May 2006 00:06:47 +0100 From: Ralf Baechle To: Tom Rini Cc: Thiemo Seufer , Tim Bird , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504230647.GA3465@linux-mips.org> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060504210449.GA12676@smtp.west.cox.net> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, May 04, 2006 at 02:04:49PM -0700, Tom Rini wrote: > Let me ask a stupid question. With all of the ways to otherwise do a > cross compile, why a config option on MIPS? ARM*/SH*, which are at > least as likely to not be native-compiled, don't do that. Just > something I've always wondered, really. Having such information in an environment variable is imho terribly inelegant, having to pass it on the command line for each make invocation is terrible abuse for the fingertips so I went for this option which makes the makefile pick the right prefix. Ralf From trini@kernel.crashing.org Fri May 5 00:14:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 00:14:51 +0100 (BST) Received: from fed1rmmtao08.cox.net ([68.230.241.31]:25064 "HELO fed1rmmtao08.cox.net") by ftp.linux-mips.org with SMTP id S8133806AbWEDXOk (ORCPT ); Fri, 5 May 2006 00:14:40 +0100 Received: from opus ([68.110.9.227]) by fed1rmmtao08.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060504231433.ICPL27967.fed1rmmtao08.cox.net@opus>; Thu, 4 May 2006 19:14:33 -0400 Date: Thu, 4 May 2006 16:14:32 -0700 From: Tom Rini To: Ralf Baechle Cc: Thiemo Seufer , Tim Bird , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504231432.GC12676@smtp.west.cox.net> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> <20060504230647.GA3465@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060504230647.GA3465@linux-mips.org> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: trini@kernel.crashing.org Precedence: bulk X-list: linux-mips On Fri, May 05, 2006 at 12:06:47AM +0100, Ralf Baechle wrote: > On Thu, May 04, 2006 at 02:04:49PM -0700, Tom Rini wrote: > > > Let me ask a stupid question. With all of the ways to otherwise do a > > cross compile, why a config option on MIPS? ARM*/SH*, which are at > > least as likely to not be native-compiled, don't do that. Just > > something I've always wondered, really. > > Having such information in an environment variable is imho terribly > inelegant, having to pass it on the command line for each make invocation > is terrible abuse for the fingertips so I went for this option which makes > the makefile pick the right prefix. I don't suppose you'd be willing to front pushing that to the rest of the world then, would you? Inconsistency is more of a problem for me than changing any of my scripts to use something else :) -- Tom Rini http://gate.crashing.org/~trini/ From trini@kernel.crashing.org Fri May 5 00:34:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 00:34:58 +0100 (BST) Received: from fed1rmmtao05.cox.net ([68.230.241.34]:33213 "HELO fed1rmmtao05.cox.net") by ftp.linux-mips.org with SMTP id S8133806AbWEDXeq (ORCPT ); Fri, 5 May 2006 00:34:46 +0100 Received: from opus ([68.110.9.227]) by fed1rmmtao05.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060504233429.BHWC25666.fed1rmmtao05.cox.net@opus>; Thu, 4 May 2006 19:34:29 -0400 Date: Thu, 4 May 2006 16:34:29 -0700 From: Tom Rini To: Ralf Baechle Cc: Thiemo Seufer , Tim Bird , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Message-ID: <20060504233429.GD12676@smtp.west.cox.net> References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> <20060504230647.GA3465@linux-mips.org> <20060504231432.GC12676@smtp.west.cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060504231432.GC12676@smtp.west.cox.net> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: trini@kernel.crashing.org Precedence: bulk X-list: linux-mips On Thu, May 04, 2006 at 04:14:32PM -0700, Tom Rini wrote: > On Fri, May 05, 2006 at 12:06:47AM +0100, Ralf Baechle wrote: > > On Thu, May 04, 2006 at 02:04:49PM -0700, Tom Rini wrote: > > > > > Let me ask a stupid question. With all of the ways to otherwise do a > > > cross compile, why a config option on MIPS? ARM*/SH*, which are at > > > least as likely to not be native-compiled, don't do that. Just > > > something I've always wondered, really. > > > > Having such information in an environment variable is imho terribly > > inelegant, having to pass it on the command line for each make invocation > > is terrible abuse for the fingertips so I went for this option which makes > > the makefile pick the right prefix. > > I don't suppose you'd be willing to front pushing that to the rest of > the world then, would you? Inconsistency is more of a problem for me > than changing any of my scripts to use something else :) ... I forgot this doesn't take a string value of what to use but hard-coded options. -- Tom Rini http://gate.crashing.org/~trini/ From afleming@freescale.com Fri May 5 01:36:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 01:37:16 +0100 (BST) Received: from az33egw01.freescale.net ([192.88.158.102]:43738 "EHLO az33egw01.freescale.net") by ftp.linux-mips.org with ESMTP id S8133797AbWEEAg6 (ORCPT ); Fri, 5 May 2006 01:36:58 +0100 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id k450tuFm013782; Thu, 4 May 2006 17:55:56 -0700 (MST) Received: from [10.82.16.201] ([10.82.16.201]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id k450lpta026867; Thu, 4 May 2006 19:47:51 -0500 (CDT) In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <1146674056.31241.18.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87D75728-B63F-445C-A4F8-7DA3A2619459@freescale.com> Cc: Mark Schank , ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com, netdev@vger.kernel.org, Ralf Baechle , "Robin H. Johnson" Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: au1000_etc.c phylib rewrite Date: Thu, 4 May 2006 19:36:33 -0500 To: Herbert Valerio Riedel X-Mailer: Apple Mail (2.749.3) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: afleming@freescale.com Precedence: bulk X-list: linux-mips On May 3, 2006, at 11:34, Herbert Valerio Riedel wrote: > hello * > > On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote: >> At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote: >>> On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote: >>>> The Cogent CSB655 used the Broadcom Dual Phy. They eventually >>>> redesigned >>>> the board and switched to two single Broadcom phys, but they >>>> continued to >>>> control both phys through MAC0, which is the actual purpose of the >>> dual-phy >>>> hack. I am a user of the CSB655, so I sort of care. >>>> >>>> Will the new PHY framework allow a second PHY for a second MAC >>>> (MAC1) be >>>> controlled from the first MAC's (MAC0) mdio interface? That definitely isn't a problem (though it looks like you've probably figured that out). The original user (gianfar) has a similar setup, where all 2-4 NICs use TSEC0's MII interface to control the PHYs. It was actually one of the reasons for writing it in the first place--to more cleanly share that interface between several different device instances. >>> >>> should'nt be a problem (as opposed to the bosporus case... see >>> below)... >>> I assume the phy-addresses on which the boarcom dual phy is >>> configured >>> are the same for all Cogent CSB655 boards? >> >> Dual PHY configuration: >> MAC0 - phy addr 4 >> MAC1 - phy addr 3 >> Single PHY configuration: >> MAC0 - phy addr 1 >> MAC1 - phy addr 0 > > while at it, does anyone happen to know what the phy-addr/MAC > assignment > on the XXS1500 is? > >>> does this need to be autodetected dynamically at runtime, or can >>> we rely >>> on a compile time Kconfig-conditional to set a static phy-addr<- >>> >eth% >>> d-phy mapping for this board-specific case? Or de we really need >>> such a >>> complex mii_probe() function to detect weird scenarios? :) >> >> The compile time Kconfig-conditional should be okay. The driver >> need to >> handle the fact that the MAC1's phy is controlled by MAC0's mdio >> interface. This means that MAC0 controller can not be disabled >> when the >> associated eth% device is down, otherwise you lose the ability to >> control >> MAC1's phy. > > ...or at least, the MAC associated with the particular MII bus > should be > brought up if necessary before any mdio access (that's what I'm > implementing right now) > > but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY > doesn't > seem to be defined anywhere; shouldn't that be at least defined in > some > Kconfig file, especially if the XXS1550 board is supposed to make > use of > it? > > btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I > couldn't find any mention of it in Kconfig files either? > >>> using static phy addr mappings would also allow for setting >>> board-specific phy-irq assignments, which would then be handled >>> by the >>> phylib facilities, instead of polling the status of phy with a >>> timer; >>> (and in case we don't have any board-specific compile time >>> setting, we >>> can still fall back to search the phy-addresses for a PHY at >>> runtime as >>> the generic case) >> >> Will the phylib facilities handle the case where two phys share a >> single IRQ? > > afaics from the source, it doesn't handle the case of multiplexed phy > notification irqs; although the interrupt is requested with the > SA_SHIRQ > flag, the first phy-interrupt-handler to be called already returns > IRQ_HANDLED... doesn't feel right in some way ;-) The PHY layer does handle multiplexed interrupts (I've got boards with 4 PHYs sharing the same IRQ). While I'm not sure returning IRQ_HANDLED is the perfect implementation, I'm not sure there are any options. I've worked pretty hard to ensure that PHY transactions don't occur in interrupt context so that it's possible to implement a driver that has an interrupt signal the end of a transaction. As such, reading the PHY interrupt status cannot happen in the interrupt handler, which means the interrupt handler doesn't have the ability to determine whether any particular invocation is handling the actual cause of the interrupt. From what I've seen of the interrupt code, this is only an issue if a spurious interrupt starts troubling the same line the PHY is using. Does anyone disagree, or have some better suggestion for how to handle this? From geert@linux-m68k.org Fri May 5 08:45:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 08:45:59 +0100 (BST) Received: from witte.sonytel.be ([80.88.33.193]:12488 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133404AbWEEHpq (ORCPT ); Fri, 5 May 2006 08:45:46 +0100 Received: from pademelon.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id k457jcCQ005595; Fri, 5 May 2006 09:45:39 +0200 (MEST) Date: Fri, 5 May 2006 09:45:38 +0200 (CEST) From: Geert Uytterhoeven To: Tom Rini cc: Ralf Baechle , Thiemo Seufer , Tim Bird , Linux/MIPS Development Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var In-Reply-To: <20060504233429.GD12676@smtp.west.cox.net> Message-ID: References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <20060504210449.GA12676@smtp.west.cox.net> <20060504230647.GA3465@linux-mips.org> <20060504231432.GC12676@smtp.west.cox.net> <20060504233429.GD12676@smtp.west.cox.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Thu, 4 May 2006, Tom Rini wrote: > On Thu, May 04, 2006 at 04:14:32PM -0700, Tom Rini wrote: > > On Fri, May 05, 2006 at 12:06:47AM +0100, Ralf Baechle wrote: > > > On Thu, May 04, 2006 at 02:04:49PM -0700, Tom Rini wrote: > > > > > > > Let me ask a stupid question. With all of the ways to otherwise do a > > > > cross compile, why a config option on MIPS? ARM*/SH*, which are at > > > > least as likely to not be native-compiled, don't do that. Just > > > > something I've always wondered, really. > > > > > > Having such information in an environment variable is imho terribly > > > inelegant, having to pass it on the command line for each make invocation > > > is terrible abuse for the fingertips so I went for this option which makes You can make it so that you can use both, right? This is what the suggested patch does. No CROSS_COMPILE in env or on the make command line means a native compilation. > > > the makefile pick the right prefix. > > > > I don't suppose you'd be willing to front pushing that to the rest of > > the world then, would you? Inconsistency is more of a problem for me > > than changing any of my scripts to use something else :) > > ... I forgot this doesn't take a string value of what to use but > hard-coded options. So let it take a string option, and make it generic. But on second thought: config options are part of the target configuration, while CROSS_COMPILE= is part of the host configuration, so IMHO it doesn't belong in Kconfig. I.e. do you want to have CONFIG_CROSS_COMPILE set in your defconfig? Yes or no, depending on whether you do cross-compilations or not. So you cannot simply take a defconfig, you'll have to modify it for your host setup. So I'd prefer to keep the CROSS_COMPILE, like other arches do. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From donimus@gmail.com Fri May 5 08:58:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 08:58:12 +0100 (BST) Received: from wx-out-0102.google.com ([66.249.82.193]:52338 "EHLO wx-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S8133361AbWEEH6C (ORCPT ); Fri, 5 May 2006 08:58:02 +0100 Received: by wx-out-0102.google.com with SMTP id s17so486276wxc for ; Fri, 05 May 2006 00:58:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=Xy00Kkb3Uy3thRdGgQMuSi+O2Iwkcnknrv5CcOJGfG63RKu8jx4HkI8g2D6kAkGV4yw0vDBQeaY5XwM6xSq4KydwBzh8VzC7lEV/PIQ6A1wTxpFSSJ1eysQwiRiUS6kDeUhcdILKYh11rUSwo58cMwV2TuSeWiojfIu2/k4xdbs= Received: by 10.70.41.5 with SMTP id o5mr2046970wxo; Fri, 05 May 2006 00:58:01 -0700 (PDT) Received: from ?192.168.1.99? ( [24.184.9.219]) by mx.gmail.com with ESMTP id i18sm627447wxd.2006.05.05.00.58.01; Fri, 05 May 2006 00:58:01 -0700 (PDT) Message-ID: <445B0589.5060709@gmail.com> Date: Fri, 05 May 2006 03:58:01 -0400 From: Don Imus User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: wiki problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: donimus@gmail.com Precedence: bulk X-list: linux-mips There's no contact info email addys on the wiki so I'm posting this here. http://www.linux-mips.org/wiki/SoC There used to be a substantial page on the ADM5120 SoC. It seems to be MIA. I tried restoring it from the last good version from 17 April but the changes won't take. It tells me that someone else has changed the page since I started editing it. Database problem? From weo@reccoware.de Fri May 5 11:39:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 11:39:26 +0100 (BST) Received: from bes.recconet.de ([212.227.59.164]:41697 "EHLO bes.recconet.de") by ftp.linux-mips.org with ESMTP id S8133404AbWEEKjQ (ORCPT ); Fri, 5 May 2006 11:39:16 +0100 Received: from trinity.recco.de (trinity.intern.recconet.de [192.168.11.241]) by bes.recconet.de (8.13.1/8.13.1/Recconet-2005031001) with ESMTP id k45AdCIS029748; Fri, 5 May 2006 12:39:13 +0200 Received: from seneca.recco.de (seneca.recco.de [172.16.135.97]) by trinity.recco.de (8.13.1/8.13.1/Reccoware-2005061101) with ESMTP id k45AcJin007094; Fri, 5 May 2006 12:38:19 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by seneca.recco.de (8.13.6/8.13.4/Seneca.Reccoware-2005061801) with ESMTP id k45AdCr0002720; Fri, 5 May 2006 12:39:12 +0200 Subject: Re: Au1200 MMC/SD problem From: Wolfgang Ocker To: Jordan Crouse Cc: linux-mips@linux-mips.org In-Reply-To: <20060503145927.GD24185@cosmic.amd.com> References: <1146548770.1597.43.camel@seneca.recco.de> <20060502144314.GI22167@cosmic.amd.com> <1146592926.11188.12.camel@seneca.recco.de> <20060503145927.GD24185@cosmic.amd.com> Content-Type: text/plain Organization: Reccoware Systems Date: Fri, 05 May 2006 12:39:11 +0200 Message-Id: <1146825551.15761.8.camel@seneca.recco.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: weo@reccoware.de Precedence: bulk X-list: linux-mips On Wed, 2006-05-03 at 08:59 -0600, Jordan Crouse wrote: > > The last one. In au1xmmc_irq() the status register is read with the > > SD_STATUS_RAT bit set. > > Ok - so the card is timing out. That could be a series of problems, some > of which could be hardware, some of which could be software. Since you are > using a db1200, I'll rule out hardware for the moment, unless you have a > modified board. Today I tested a third SD card from SanDisk, 128MB, same problem and log output (time out in command 9). > Do MMC cards work? Try one - that will give us another data point. Today I received a SanDisk 64 MB MMC card, it doesn't work either. Here the log output: au1xx(0): DEBUG: set_ios (power=0, clock=0Hz, vdd=0, mode=1) au1xxx-mmc: MMC Controller 0 set up at B0600000 (mode=dma) au1xx(0): DEBUG: set_ios (power=1, clock=0Hz, vdd=23, mode=1) au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1) au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1) MMC: starting cmd 00 arg 00000000 flags 00000040 MMC: req done (00): 0: 00000000 00000000 00000000 00000000 au1xx(0): DEBUG: set_ios (power=2, clock=450000Hz, vdd=23, mode=1) MMC: starting cmd 37 arg 00000000 flags 00000015 au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: starting cmd 37 arg 00000000 flags 00000015 au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set MMC: req done (37): 1: 00000000 00000000 00000000 00000000 MMC: mmc_setup(), send_app_op_cond, ocr = 1000fc00, err = 1 MMC: mmc_setup(), no SD card found (1) MMC: starting cmd 01 arg 00000000 flags 00000061 au1xx(0): DEBUG: au1xmmc_irq(), SD_STATUS_RAT set MMC: req done (01): 1: 00000000 00000000 00000000 00000000 MMC: mmc_rescan(): no card found! au1xx(0): DEBUG: set_ios (power=0, clock=0Hz, vdd=0, mode=1) Thanks, Wolfgang From sathesh_edara2003@yahoo.co.in Fri May 5 13:51:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 13:51:25 +0100 (BST) Received: from web8706.mail.in.yahoo.com ([203.84.221.127]:33136 "HELO web8706.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S8133711AbWEEMvP (ORCPT ); Fri, 5 May 2006 13:51:15 +0100 Received: (qmail 47133 invoked by uid 60001); 5 May 2006 12:51:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nzEISSSDu5nXJXDMxOv4xLK6DjTJPkAz5+Yjp7kNVYmhVUYctqz9pZohQuQxRzt3nkgfGXPAevSGZOREmUhO5poSEAkR2jQtu3ZlWQT2Rou64ql53epBiCA6040LkOMyZ6yp5YB00iQ0NYQQqef9GEAO+ck+3Cd/7gC7S0+Zo6Y= ; Message-ID: <20060505125106.47131.qmail@web8706.mail.in.yahoo.com> Received: from [137.71.23.54] by web8706.mail.in.yahoo.com via HTTP; Fri, 05 May 2006 13:51:06 BST Date: Fri, 5 May 2006 13:51:06 +0100 (BST) From: sathesh babu Subject: KGDB support for Linux-2.6.12 To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-812703961-1146833466=:43471" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sathesh_edara2003@yahoo.co.in Precedence: bulk X-list: linux-mips --0-812703961-1146833466=:43471 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I would like to know, Is KGDB support available in linux-mips-2.6.12 kernel for R3000 (lx4189 processor). Do we need to apply any patches to make KGDB work on linux-mips-2.6.12 kernel (R3000 ,lx4189 processor) ?. Thanks in advance. Regards, sathesh --------------------------------- Yahoo! India Answers: Share what you know. Learn something new. Click here --0-812703961-1146833466=:43471 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
   I would like to know, Is KGDB support available in linux-mips-2.6.12 kernel for R3000 (lx4189 processor).
 
Do we need to apply any  patches to make KGDB work on  linux-mips-2.6.12 kernel (R3000 ,lx4189 processor) ?.
 
Thanks in advance.
 
Regards,
sathesh  

Yahoo! India Answers: Share what you know. Learn something new. Click here --0-812703961-1146833466=:43471-- From ralf@linux-mips.org Fri May 5 13:53:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 13:53:22 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:35722 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133737AbWEEMxN (ORCPT ); Fri, 5 May 2006 13:53:13 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k45CrCGH005767; Fri, 5 May 2006 13:53:12 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k45CrBHA005766; Fri, 5 May 2006 13:53:11 +0100 Date: Fri, 5 May 2006 13:53:11 +0100 From: Ralf Baechle To: Don Imus Cc: linux-mips@linux-mips.org Subject: Re: wiki problem Message-ID: <20060505125311.GA4677@linux-mips.org> References: <445B0589.5060709@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445B0589.5060709@gmail.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 05, 2006 at 03:58:01AM -0400, Don Imus wrote: > There's no contact info email addys on the wiki so I'm posting this here. I thought webmaster@... (RFC2142) was common knowledge ... > http://www.linux-mips.org/wiki/SoC That page is perfectly fine ... > There used to be a substantial page on the ADM5120 SoC. It seems to be > MIA. I tried restoring it from the last good version from 17 April but > the changes won't take. It tells me that someone else has changed the > page since I started editing it. Database problem? Seems like it the upgrade went a little rough, looking into it. Ralf From ralf@linux-mips.org Fri May 5 14:44:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 14:44:32 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62369 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133606AbWEENoY (ORCPT ); Fri, 5 May 2006 14:44:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k45DiN7W007170; Fri, 5 May 2006 14:44:23 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k45DiNnJ007169; Fri, 5 May 2006 14:44:23 +0100 Date: Fri, 5 May 2006 14:44:23 +0100 From: Ralf Baechle To: Don Imus Cc: linux-mips@linux-mips.org Subject: Re: wiki problem Message-ID: <20060505134423.GB4677@linux-mips.org> References: <445B0589.5060709@gmail.com> <20060505125311.GA4677@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060505125311.GA4677@linux-mips.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 05, 2006 at 01:53:11PM +0100, Ralf Baechle wrote: > > There used to be a substantial page on the ADM5120 SoC. It seems to be > > MIA. I tried restoring it from the last good version from 17 April but > > the changes won't take. It tells me that someone else has changed the > > page since I started editing it. Database problem? > > Seems like it the upgrade went a little rough, looking into it. So I've glued the instance of the ADM5120 page but there might be a few more, let me know if you find any. Ralf From rongkai.zhan@windriver.com Fri May 5 16:42:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 16:42:32 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:11393 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133502AbWEEPmS convert rfc822-to-8bit (ORCPT ); Fri, 5 May 2006 16:42:18 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k45FgAPY015620; Fri, 5 May 2006 08:42:12 -0700 (PDT) Received: from ism-mail01.corp.ad.wrs.com ([147.11.96.20]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 08:42:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Date: Fri, 5 May 2006 17:42:04 +0200 Message-ID: <6A3254532ACD7A42805B4E1BFD18080EB307A0@ism-mail01.corp.ad.wrs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Thread-Index: AcZwWnVbR80JPDvUTRCyPwJUbl9MWA== From: "Zhan, Rongkai" To: Cc: X-OriginalArrivalTime: 05 May 2006 15:42:09.0826 (UTC) FILETIME=[78892820:01C6705A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hello, Here is a patch to add the support for Wind River 4KC PPMC Evaluation board, which is based on the GT64120 bridge chip. Mark. Zhan Signed-off-by: Rongkai.Zhan diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/int-handler.S linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/int-handler.S --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/int-handler.S 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/int-handler.S 2006-05-05 16:38:12.000000000 +0800 @@ -0,0 +1,37 @@ +/* + * 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 + * for more details. + * + * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle + * Copyright (C) Wind River System Inc. Rongkai.Zhan + */ +#include +#include +#include +#include +#include + + .align 5 + .set noat +NESTED(handle_IRQ, PT_SIZE, sp) + SAVE_ALL + CLI # Important: mark KERNEL mode ! + + mfc0 t0, CP0_CAUSE # get pending interrupts + mfc0 t1, CP0_STATUS # get enabled interrupts + and t0, t0, t1 # get allowed interrupts + andi t0, t0, 0xFF00 + beqz t0, 1f + + move a0, sp # Prepare 'struct pt_regs *regs' pointer + jal do_wrppmc_IRQ + nop + j ret_from_irq + nop + + /* wrong alarm or masked ... */ +1: j spurious_interrupt + nop +END(handle_IRQ) + diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/irq.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/irq.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/irq.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/irq.c 2006-05-05 17:30:57.000000000 +0800 @@ -0,0 +1,76 @@ +/* + * irq.c: GT64120 Interrupt Controller + * + * Copyright (C) 2006, Wind River System Inc. + * Author: Rongkai.Zhan, + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +extern asmlinkage void handle_IRQ(void); + +asmlinkage void do_wrppmc_IRQ(struct pt_regs *regs) +{ + unsigned long pending; + int irq; + + pending = read_c0_cause(); + pending &= read_c0_status(); + pending = (pending & 0xFF00) >> 8; + irq = ffs(pending) - 1; + + do_IRQ(irq, regs); +} + +/** + * Initialize GT64120 Interrupt Controller + */ +void gt64120_init_pic(void) +{ + /* clear CPU Interrupt Cause Registers */ + GT_WRITE(GT_INTRCAUSE_OFS, (0x1F << 21)); + GT_WRITE(GT_HINTRCAUSE_OFS, 0x00); + + /* Disable all interrupts from GT64120 bridge chip */ + GT_WRITE(GT_INTRMASK_OFS, 0x00); + GT_WRITE(GT_HINTRMASK_OFS, 0x00); + GT_WRITE(GT_PCI0_ICMASK_OFS, 0x00); + GT_WRITE(GT_PCI0_HICMASK_OFS, 0x00); +} + +void __init arch_init_irq(void) +{ + /* enable all CPU interrupt bits. */ + set_c0_status(ST0_IM); /* IE bit is still 0 */ + + /* Install MIPS Interrupt Trap Vector */ + set_except_vector(0, handle_IRQ); + + /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ + mips_cpu_irq_init(0); + + gt64120_init_pic(); +} diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/Makefile linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/Makefile --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/Makefile 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/Makefile 2006-04-14 15:25:48.000000000 +0800 @@ -0,0 +1,14 @@ +# +# 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 +# for more details. +# +# Copyright 2006 Wind River System, Inc. +# Author: Rongkai.Zhan +# +# Makefile for the Wind River MIPS 4KC PPMC Eval Board +# + +obj-y += int-handler.o irq.o reset.o setup.o time.o pci.o + +EXTRA_AFLAGS := $(CFLAGS) diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/pci.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/pci.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/pci.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/pci.c 2006-05-05 17:25:48.000000000 +0800 @@ -0,0 +1,53 @@ +/* + * pci.c: GT64120 PCI support. + * + * Copyright (C) 2006, Wind River System Inc. Rongkai.Zhan + * + * 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 + * for more details. + */ +#include +#include +#include +#include +#include + +extern struct pci_ops gt64120_pci_ops; + +static struct resource pci0_io_resource = { + .name = "pci_0 io", + .start = GT_PCI_IO_BASE, + .end = GT_PCI_IO_BASE + GT_PCI_IO_SIZE - 1, + .flags = IORESOURCE_IO, +}; + +static struct resource pci0_mem_resource = { + .name = "pci_0 memory", + .start = GT_PCI_MEM_BASE, + .end = GT_PCI_MEM_BASE + GT_PCI_MEM_SIZE - 1, + .flags = IORESOURCE_MEM, +}; + +static struct pci_controller hose_0 = { + .pci_ops = >64120_pci_ops, + .io_resource = &pci0_io_resource, + .mem_resource = &pci0_mem_resource, +}; + +static int __init gt64120_pci_init(void) +{ + u32 tmp; + + tmp = GT_READ(GT_PCI0_CMD_OFS); /* Huh??? -- Ralf */ + tmp = GT_READ(GT_PCI0_BARE_OFS); + + /* reset the whole PCI I/O space range */ + ioport_resource.start = GT_PCI_IO_BASE; + ioport_resource.end = GT_PCI_IO_BASE + GT_PCI_IO_SIZE - 1; + + register_pci_controller(&hose_0); + return 0; +} + +arch_initcall(gt64120_pci_init); diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/reset.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/reset.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/reset.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/reset.c 2006-04-13 22:24:56.000000000 +0800 @@ -0,0 +1,50 @@ +/* + * 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 + * for more details. + * + * Copyright (C) 1997 Ralf Baechle + */ +#include +#include +#include +#include +#include +#include +#include +#include + +void wrppmc_machine_restart(char *command) +{ + /* + * Ouch, we're still alive ... This time we take the silver bullet ... + * ... and find that we leave the hardware in a state in which the + * kernel in the flush locks up somewhen during of after the PCI + * detection stuff. + */ + local_irq_disable(); + set_c0_status(ST0_BEV | ST0_ERL); + change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); + flush_cache_all(); + write_c0_wired(0); + __asm__ __volatile__("jr\t%0"::"r"(0xbfc00000)); +} + +void wrppmc_machine_halt(void) +{ + local_irq_disable(); + + printk(KERN_NOTICE "You can safely turn off the power\n"); + while (1) { + __asm__( + ".set\tmips3\n\t" + "wait\n\t" + ".set\tmips0" + ); + } +} + +void wrppmc_machine_power_off(void) +{ + wrppmc_machine_halt(); +} diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/setup.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/setup.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/setup.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/setup.c 2006-05-05 17:08:27.000000000 +0800 @@ -0,0 +1,173 @@ +/* + * setup.c: Setup pointers to hardware dependent routines. + * + * 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 + * for more details. + * + * Copyright (C) 1996, 1997, 2004 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2006, Wind River System Inc. Rongkai.zhan + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +unsigned long gt64120_base = KSEG1ADDR(0x14000000); + +#ifdef WRPPMC_EARLY_DEBUG + +static volatile unsigned char * wrppmc_led = \ + (volatile unsigned char *)KSEG1ADDR(WRPPMC_LED_BASE); + +/* + * PPMC LED control register: + * -) bit[0] controls DS1 LED (1 - OFF, 0 - ON) + * -) bit[1] controls DS2 LED (1 - OFF, 0 - ON) + * -) bit[2] controls DS4 LED (1 - OFF, 0 - ON) + */ +void wrppmc_led_on(int mask) +{ + unsigned char value = *wrppmc_led; + + value &= (0xF8 | mask); + *wrppmc_led = value; +} + +/* If mask = 0, turn off all LEDs */ +void wrppmc_led_off(int mask) +{ + unsigned char value = *wrppmc_led; + + value |= (0x7 & mask); + *wrppmc_led = value; +} + +/* + * We assume that bootloader has initialized UART16550 correctly + */ +void __init wrppmc_early_putc(char ch) +{ + static volatile unsigned char *wrppmc_uart = \ + (volatile unsigned char *)KSEG1ADDR(WRPPMC_UART16550_BASE); + unsigned char value; + + /* Wait until Transmit-Holding-Register is empty */ + while (1) { + value = *(wrppmc_uart + 5); + if (value & 0x20) + break; + } + + *wrppmc_uart = ch; +} + +void __init wrppmc_early_printk(const char *fmt, ...) +{ + static char pbuf[256] = {'\0', }; + char *ch = pbuf; + va_list args; + unsigned int i; + + memset(pbuf, 0, 256); + va_start(args, fmt); + i = vsprintf(pbuf, fmt, args); + va_end(args); + + /* Print the string */ + while (*ch != '\0') { + wrppmc_early_putc(*ch); + /* if print '\n', also print '\r' */ + if (*ch++ == '\n') + wrppmc_early_putc('\r'); + } +} +#endif /* WRPPMC_EARLY_DEBUG */ + +unsigned long __init prom_free_prom_memory(void) +{ + return 0; +} + +#ifdef CONFIG_SERIAL_8250 +static void wrppmc_setup_serial(void) +{ + struct uart_port up; + + memset(&up, 0x00, sizeof(struct uart_port)); + + /* + * A note about mapbase/membase + * -) mapbase is the physical address of the IO port. + * -) membase is an 'ioremapped' cookie. + */ + up.line = 0; + up.type = PORT_16550; + up.iotype = UPIO_MEM; + up.mapbase = WRPPMC_UART16550_BASE; + up.membase = ioremap(up.mapbase, 8); + up.irq = WRPPMC_UART16550_IRQ; + up.uartclk = WRPPMC_UART16550_CLOCK; + up.flags = UPF_SKIP_TEST/* | UPF_BOOT_AUTOCONF */; + up.regshift = 0; + + early_serial_setup(&up); +} +#endif + +void __init plat_setup(void) +{ + extern void wrppmc_time_init(void); + extern void wrppmc_timer_setup(struct irqaction *); + extern void wrppmc_machine_restart(char *command); + extern void wrppmc_machine_halt(void); + extern void wrppmc_machine_power_off(void); + + _machine_restart = wrppmc_machine_restart; + _machine_halt = wrppmc_machine_halt; + pm_power_off = wrppmc_machine_power_off; + + /* Use MIPS Count/Compare Timer */ + board_time_init = wrppmc_time_init; + board_timer_setup = wrppmc_timer_setup; + + /* This makes the operations of 'in/out[bwl]' to the + * physical address ( < KSEG0) can work via KSEG1 + */ + set_io_port_base(KSEG1); + +#ifdef CONFIG_SERIAL_8250 + wrppmc_setup_serial(); +#endif +} + +const char *get_system_type(void) +{ + return "Wind River PPMC (GT64120)"; +} + +/* + * Initializes basic routines and structures pointers, memory size (as + * given by the bios and saves the command line. + */ +void __init prom_init(void) +{ + mips_machgroup = MACH_GROUP_GALILEO; + mips_machtype = MACH_EV64120A; + + add_memory_region(WRPPMC_SDRAM_SCS0_BASE, WRPPMC_SDRAM_SCS0_SIZE, BOOT_MEM_RAM); + add_memory_region(WRPPMC_BOOTROM_BASE, WRPPMC_BOOTROM_SIZE, BOOT_MEM_ROM_DATA); + + wrppmc_early_printk("prom_init: GT64120 SDRAM Bank 0: 0x%x - 0x%08lx\n", + WRPPMC_SDRAM_SCS0_BASE, (WRPPMC_SDRAM_SCS0_BASE + WRPPMC_SDRAM_SCS0_SIZE)); +} diff -urN linux-2.6.16.11/arch/mips/gt64120/wrppmc/time.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/time.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/time.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/time.c 2006-05-05 16:39:32.000000000 +0800 @@ -0,0 +1,57 @@ +/* + * time.c: MIPS CPU Count/Compare timer hookup + * + * Author: Mark.Zhan, + * + * 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 + * for more details. + * + * Copyright (C) 1996, 1997, 2004 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2006, Wind River System Inc. + */ +#include +#include +#include +#include +#include /* for HZ */ +#include +#include +#include + +#include +#include +#include +#include +#include + +#define WRPPMC_CPU_CLK_FREQ 40000000 /* 40MHZ */ + +void __init wrppmc_timer_setup(struct irqaction *irq) +{ + /* Install ISR for timer interrupt */ + setup_irq(WRPPMC_MIPS_TIMER_IRQ, irq); + + /* to generate the first timer interrupt */ + write_c0_compare(mips_hpt_frequency/HZ); + write_c0_count(0); +} + +/* + * Estimate CPU frequency. Sets mips_hpt_frequency as a side-effect + * + * NOTE: We disable all GT64120 timers, and use MIPS processor internal + * timer as the source of kernel clock tick. + */ +void __init wrppmc_time_init(void) +{ + /* Disable GT64120 timers */ + GT_WRITE(GT_TC_CONTROL_OFS, 0x00); + GT_WRITE(GT_TC0_OFS, 0x00); + GT_WRITE(GT_TC1_OFS, 0x00); + GT_WRITE(GT_TC2_OFS, 0x00); + GT_WRITE(GT_TC3_OFS, 0x00); + + /* Use MIPS compare/count internal timer */ + mips_hpt_frequency = WRPPMC_CPU_CLK_FREQ; +} diff -urN linux-2.6.16.11/arch/mips/Kconfig linux-2.6.16.11-ppmc/arch/mips/Kconfig --- linux-2.6.16.11/arch/mips/Kconfig 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/Kconfig 2006-05-05 10:53:40.000000000 +0800 @@ -326,6 +326,27 @@ This enables support for the MIPS Technologies SEAD evaluation board. +config WR_PPMC + bool "Support for Wind River PPMC board" + select IRQ_CPU + select BOOT_ELF32 + select DMA_NONCOHERENT + select HW_HAS_PCI + select MIPS_GT64120 + select SWAP_IO_SPACE + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_HAS_CPU_MIPS64_R1 + select SYS_HAS_CPU_NEVADA + select SYS_HAS_CPU_RM7000 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_LITTLE_ENDIAN + help + This enables support for the Wind River MIPS32 4KC PPMC evaluation + board, which is based on GT64120 bridge chip. + config MIPS_SIM bool 'Support for MIPS simulator (MIPSsim)' select DMA_NONCOHERENT diff -urN linux-2.6.16.11/arch/mips/Makefile linux-2.6.16.11-ppmc/arch/mips/Makefile --- linux-2.6.16.11/arch/mips/Makefile 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/Makefile 2006-05-05 12:42:16.000000000 +0800 @@ -419,6 +419,13 @@ load-$(CONFIG_MIPS_EV96100) += 0xffffffff80100000 # +# Wind River PPMC Board (4KC + GT64120) +# +core-$(CONFIG_WR_PPMC) += arch/mips/gt64120/wrppmc/ +cflags-$(CONFIG_WR_PPMC) += -Iinclude/asm-mips/mach-wrppmc +load-$(CONFIG_WR_PPMC) += 0xffffffff80100000 + +# # Globespan IVR eval board with QED 5231 CPU # core-$(CONFIG_ITE_BOARD_GEN) += arch/mips/ite-boards/generic/ diff -urN linux-2.6.16.11/arch/mips/pci/fixup-wrppmc.c linux-2.6.16.11-ppmc/arch/mips/pci/fixup-wrppmc.c --- linux-2.6.16.11/arch/mips/pci/fixup-wrppmc.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/pci/fixup-wrppmc.c 2006-05-05 16:40:01.000000000 +0800 @@ -0,0 +1,37 @@ +/* + * fixup-wrppmc.c: PPMC board specific PCI fixup + * + * 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 + * for more details. + * + * Copyright (C) 2006, Wind River Inc. Rongkai.zhan (rongkai.zhan@windriver.com) + */ +#include +#include +#include + +/* PCI interrupt pins */ +#define PCI_INTA 1 +#define PCI_INTB 2 +#define PCI_INTC 3 +#define PCI_INTD 4 + +#define PCI_SLOT_MAXNR 32 /* Each PCI bus has 32 physical slots */ + +static char pci_irq_tab[PCI_SLOT_MAXNR][5] __initdata = { + /* 0 INTA INTB INTC INTD */ + [0] = {0, 0, 0, 0, 0}, /* Slot 0: GT64120 PCI bridge */ + [6] = {0, WRPPMC_PCI_INTA, 0, 0, 0}, +}; + +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) +{ + return pci_irq_tab[slot][pin]; +} + +/* Do platform specific device initialization at pci_enable_device() time */ +int pcibios_plat_dev_init(struct pci_dev *dev) +{ + return 0; +} diff -urN linux-2.6.16.11/arch/mips/pci/Makefile linux-2.6.16.11-ppmc/arch/mips/pci/Makefile --- linux-2.6.16.11/arch/mips/pci/Makefile 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/pci/Makefile 2006-05-05 11:30:44.000000000 +0800 @@ -57,3 +57,4 @@ obj-$(CONFIG_TOSHIBA_RBTX4938) += fixup-tx4938.o ops-tx4938.o obj-$(CONFIG_VICTOR_MPC30X) += fixup-mpc30x.o obj-$(CONFIG_ZAO_CAPCELLA) += fixup-capcella.o +obj-$(CONFIG_WR_PPMC) += fixup-wrppmc.o diff -urN linux-2.6.16.11/include/asm-mips/mach-wrppmc/mach-gt64120.h linux-2.6.16.11-ppmc/include/asm-mips/mach-wrppmc/mach-gt64120.h --- linux-2.6.16.11/include/asm-mips/mach-wrppmc/mach-gt64120.h 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/include/asm-mips/mach-wrppmc/mach-gt64120.h 2006-05-05 16:56:33.000000000 +0800 @@ -0,0 +1,81 @@ +/* + * This is a direct copy of the ev96100.h file, with a global + * search and replace. The numbers are the same. + * + * The reason I'm duplicating this is so that the 64120/96100 + * defines won't be confusing in the source code. + */ +#ifndef __ASM_MIPS_GT64120_H +#define __ASM_MIPS_GT64120_H + +/* + * GT64120 config space base address + */ +extern unsigned long gt64120_base; + +#define GT64120_BASE (gt64120_base) + +/* + * This is the CPU physical memory map of PPMC Board: + * + * 0x00000000-0x03FFFFFF - 64MB SDRAM (SCS[0]#) + * 0x1C000000-0x1C000000 - LED (CS0) + * 0x1C800000-0x1C800007 - UART 16550 port (CS1) + * 0x1F000000-0x1F000000 - MailBox (CS3) + * 0x1FC00000-0x20000000 - 4MB Flash (BOOT CS) + */ + +#define WRPPMC_SDRAM_SCS0_BASE 0x00000000 +#define WRPPMC_SDRAM_SCS0_SIZE 0x04000000 + +#define WRPPMC_UART16550_BASE 0x1C800000 +#define WRPPMC_UART16550_CLOCK 3686400 /* 3.68MHZ */ + +#define WRPPMC_LED_BASE 0x1C000000 +#define WRPPMC_MBOX_BASE 0x1F000000 + +#define WRPPMC_BOOTROM_BASE 0x1FC00000 +#define WRPPMC_BOOTROM_SIZE 0x00400000 /* 4M Flash */ + +#define WRPPMC_MIPS_TIMER_IRQ 7 /* MIPS compare/count timer interrupt */ +#define WRPPMC_UART16550_IRQ 6 +#define WRPPMC_PCI_INTA 3 + +/* + * PCI Bus I/O and Memory resources allocation + * + * NOTE: We only have PCI_0 hose interface + */ +#define GT_PCI_MEM_BASE 0x13000000UL +#define GT_PCI_MEM_SIZE 0x02000000UL +#define GT_PCI_IO_BASE 0x11000000UL +#define GT_PCI_IO_SIZE 0x02000000UL +#define GT_ISA_IO_BASE PCI_IO_BASE + +/* + * PCI interrupts will come in on either the INTA or INTD interrups lines, + * which are mapped to the #2 and #5 interrupt pins of the MIPS. On our + * boards, they all either come in on IntD or they all come in on IntA, they + * aren't mixed. There can be numerous PCI interrupts, so we keep a list of the + * "requested" interrupt numbers and go through the list whenever we get an + * IntA/D. + * + * Interrupts < 8 are directly wired to the processor; PCI INTA is 8 and + * INTD is 11. + */ +#define GT_TIMER 4 +#define GT_INTA 2 +#define GT_INTD 5 + +/* define WRPPMC_EARLY_DEBUG to enable early output something to UART */ +#undef WRPPMC_EARLY_DEBUG + +#ifdef WRPPMC_EARLY_DEBUG +extern void wrppmc_led_on(int mask); +extern void wrppmc_led_off(int mask); +extern void wrppmc_early_printk(const char *fmt, ...); +#else +#define wrppmc_early_printk(fmt, ...) do {} while (0) +#endif /* WRPPMC_EARLY_DEBUG */ + +#endif /* __ASM_MIPS_GT64120_H */ From rongkai.zhan@windriver.com Fri May 5 16:48:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 16:48:18 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:36228 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133737AbWEEPsE convert rfc822-to-8bit (ORCPT ); Fri, 5 May 2006 16:48:04 +0100 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k45Flwe2016499; Fri, 5 May 2006 08:47:58 -0700 (PDT) Received: from ism-mail01.corp.ad.wrs.com ([147.11.96.20]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 08:47:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: [PATCH 2/2] Wind River 4KC PPMC Eval Board Support Date: Fri, 5 May 2006 17:47:52 +0200 Message-ID: <6A3254532ACD7A42805B4E1BFD18080EB307A1@ism-mail01.corp.ad.wrs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/2] Wind River 4KC PPMC Eval Board Support Thread-Index: AcZwW0TGyEhwQz99RFOuj7nfOpsWyg== From: "Zhan, Rongkai" To: Cc: X-OriginalArrivalTime: 05 May 2006 15:47:57.0916 (UTC) FILETIME=[480379C0:01C6705B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Hello, Here is the default configuration file for Wind River PPMC Eval Board. Mark. Zhan Signed-off-by: Rongkai.Zhan diff -urN linux-2.6.16.11/arch/mips/configs/wrppmc_defconfig linux-2.6.16.11-ppmc/arch/mips/configs/wrppmc_defconfig --- linux-2.6.16.11/arch/mips/configs/wrppmc_defconfig 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/configs/wrppmc_defconfig 2006-05-05 17:11:22.000000000 +0800 @@ -0,0 +1,801 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.16.11 +# Fri May 5 17:11:22 2006 +# +CONFIG_MIPS=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MIPS_EV96100 is not set +# CONFIG_MIPS_IVR is not set +# CONFIG_MIPS_ITE8172 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +CONFIG_WR_PPMC=y +# CONFIG_MIPS_SIM is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM200_PCI is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +CONFIG_CPU_BIG_ENDIAN=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_IRQ_CPU=y +CONFIG_MIPS_GT64120=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_BOOT_ELF32=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +CONFIG_CPU_MIPS32_R1=y +# CONFIG_CPU_MIPS32_R2 is not set +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_HAS_CPU_MIPS32_R2=y +CONFIG_SYS_HAS_CPU_MIPS64_R1=y +CONFIG_SYS_HAS_CPU_NEVADA=y +CONFIG_SYS_HAS_CPU_RM7000=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_CPU_HAS_PREFETCH=y +# CONFIG_MIPS_MT is not set +# CONFIG_64BIT_PHYS_ADDR is not set +# CONFIG_CPU_ADVANCED is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +# CONFIG_EPOLL is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_OBSOLETE_MODPARM=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +# CONFIG_KMOD is not set + +# +# Block layer +# +# CONFIG_LBD is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +CONFIG_PCI_LEGACY_PROC=y +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# +CONFIG_HOTPLUG_PCI=y +# CONFIG_HOTPLUG_PCI_FAKE is not set +# CONFIG_HOTPLUG_PCI_CPCI is not set +# CONFIG_HOTPLUG_PCI_SHPC is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +CONFIG_BINFMT_MISC=y +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +CONFIG_PACKET=y +CONFIG_PACKET_MMAP=y +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +CONFIG_IP_MROUTE=y +# CONFIG_IP_PIMSM_V1 is not set +# CONFIG_IP_PIMSM_V2 is not set +CONFIG_ARPD=y +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_BIC=y +# CONFIG_IPV6 is not set +# CONFIG_NETFILTER is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=4096 +CONFIG_BLK_DEV_INITRD=y +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +# CONFIG_SCSI is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +CONFIG_PHYLIB=y + +# +# MII PHY device drivers +# +# CONFIG_MARVELL_PHY is not set +# CONFIG_DAVICOM_PHY is not set +# CONFIG_QSEMI_PHY is not set +# CONFIG_LXT_PHY is not set +# CONFIG_CICADA_PHY is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_DM9000 is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +CONFIG_E100=y +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SKY2 is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +# CONFIG_INPUT is not set + +# +# Hardware I/O ports +# +# CONFIG_SERIO is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=1 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +CONFIG_RTC=y +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set +# CONFIG_TELCLOCK is not set + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_SENSORS_F71805F is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Misc devices +# + +# +# Multimedia Capabilities Port drivers +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set + +# +# Graphics support +# +# CONFIG_FB is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +# CONFIG_USB is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# + +# +# File systems +# +# CONFIG_EXT2_FS is not set +# CONFIG_EXT3_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +CONFIG_INOTIFY=y +# CONFIG_QUOTA is not set +CONFIG_DNOTIFY=y +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +# CONFIG_MSDOS_FS is not set +# CONFIG_VFAT_FS is not set +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +# CONFIG_NFS_V3_ACL is not set +# CONFIG_NFS_V4 is not set +# CONFIG_NFS_DIRECTIO is not set +# CONFIG_NFSD is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +# CONFIG_RPCSEC_GSS_KRB5 is not set +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +# CONFIG_NLS is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +# CONFIG_PRINTK_TIME is not set +# CONFIG_MAGIC_SYSRQ is not set +# CONFIG_DEBUG_KERNEL is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="console=ttyS0,115200n8" + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +# CONFIG_CRYPTO is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_CRC_CCITT=y +CONFIG_CRC16=y +CONFIG_CRC32=y +CONFIG_LIBCRC32C=y From ralf@linux-mips.org Fri May 5 17:07:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 17:07:36 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:57300 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133502AbWEEQH2 (ORCPT ); Fri, 5 May 2006 17:07:28 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k45G7RB1012383; Fri, 5 May 2006 17:07:27 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k45G7QCY012382; Fri, 5 May 2006 17:07:26 +0100 Date: Fri, 5 May 2006 17:07:26 +0100 From: Ralf Baechle To: "Zhan, Rongkai" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Message-ID: <20060505160726.GA9309@linux-mips.org> References: <6A3254532ACD7A42805B4E1BFD18080EB307A0@ism-mail01.corp.ad.wrs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A3254532ACD7A42805B4E1BFD18080EB307A0@ism-mail01.corp.ad.wrs.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 05, 2006 at 05:42:04PM +0200, Zhan, Rongkai wrote: > Here is a patch to add the support for Wind River 4KC PPMC Evaluation > board, which is based on the GT64120 bridge chip. Standard problem: This patch has line-wrapped lines so can't be applied ... > 1970-01-01 08:00:00.000000000 +0800 > +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/int-handler.S > 2006-05-05 16:38:12.000000000 +0800 > @@ -0,0 +1,37 @@ > +/* > + * 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 > + * for more details. > + * > + * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle > + * Copyright (C) Wind River System Inc. Rongkai.Zhan > > + */ > +#include > +#include > +#include > +#include > +#include > + > + .align 5 > + .set noat > +NESTED(handle_IRQ, PT_SIZE, sp) > + SAVE_ALL > + CLI # Important: mark KERNEL mode ! > + > + mfc0 t0, CP0_CAUSE # get pending interrupts > + mfc0 t1, CP0_STATUS # get enabled interrupts > + and t0, t0, t1 # get allowed interrupts > + andi t0, t0, 0xFF00 > + beqz t0, 1f > + > + move a0, sp # Prepare 'struct pt_regs *regs' > pointer > + jal do_wrppmc_IRQ > + nop > + j ret_from_irq > + nop > + > + /* wrong alarm or masked ... */ > +1: j spurious_interrupt > + nop > +END(handle_IRQ) Changeset e4ac58afdfac792c0583af30dbd9eae53e24c78b rewrites all interrupt handlers from assembler to C, so your patche does no longer work. Can you create a patch against the master branch, please? > + printk(KERN_NOTICE "You can safely turn off the power\n"); This looks sooo windowsy ;-) Ralf From mcdonald@pmc-sierra.com Fri May 5 19:18:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 19:18:24 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:44716 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133813AbWEESSH (ORCPT ); Fri, 5 May 2006 19:18:07 +0100 Received: (qmail 14826 invoked by uid 101); 5 May 2006 18:17:51 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by mother.pmc-sierra.com with SMTP; 5 May 2006 18:17:51 -0000 Received: from duval.pmc-sierra.bc.ca (duval.pmc-sierra.bc.ca [134.87.183.32]) by ogyruan.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k45IHpxA010704 for ; Fri, 5 May 2006 11:17:51 -0700 From: Shane McDonald Received: (from mcdonald@localhost) by duval.pmc-sierra.bc.ca (8.12.11/8.12.11) id k45IHpkC031672 for linux-mips@linux-mips.org; Fri, 5 May 2006 12:17:51 -0600 Date: Fri, 5 May 2006 12:17:51 -0600 Message-Id: <200605051817.k45IHpkC031672@duval.pmc-sierra.bc.ca> To: linux-mips@linux-mips.org Subject: Re: [PATCH] improve readability of arch/mips/Kconfig Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mcdonald@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 3671 Lines: 67 I'll try this again ... I think I've got the corrupt patch issue resolved. From: Shane McDonald The wording of the help entries for CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, and CPU_MIPS64_R2 was confusing. The entries have been slightly reworded to improve the readability. Signed-off-by: Shane McDonald --- diff -uprN a/arch/mips/Kconfig b/arch/mips/Kconfig --- a/arch/mips/Kconfig 2006-05-04 16:25:32.000000000 -0600 +++ b/arch/mips/Kconfig 2006-05-04 16:50:08.000000000 -0600 @@ -1075,10 +1075,10 @@ config CPU_MIPS32_R1 Choose this option to build a kernel for release 1 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. - Release 2 of the MIPS32 architecture is available since several - years so chances are you even have a MIPS32 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + Release 2 of the MIPS32 architecture has been available for + several years so chances are you have a MIPS32 Release 2 processor in which case you should choose CPU_MIPS32_R2 instead for better performance. @@ -1093,8 +1093,8 @@ config CPU_MIPS32_R2 Choose this option to build a kernel for release 2 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. config CPU_MIPS64_R1 bool "MIPS64 Release 1" @@ -1108,10 +1108,10 @@ config CPU_MIPS64_R1 Choose this option to build a kernel for release 1 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. - Release 2 of the MIPS64 architecture is available since several - years so chances are you even have a MIPS64 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + Release 2 of the MIPS64 architecture has been available for + several years so chances are you have a MIPS64 Release 2 processor in which case you should choose CPU_MIPS64_R2 instead for better performance. @@ -1127,8 +1127,8 @@ config CPU_MIPS64_R2 Choose this option to build a kernel for release 2 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. config CPU_R3000 bool "R3000" From wd@denx.de Fri May 5 19:45:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 19:45:45 +0100 (BST) Received: from mail-out.m-online.net ([212.18.0.9]:15009 "HELO mail-out.m-online.net") by ftp.linux-mips.org with SMTP id S8133813AbWEESpR convert rfc822-to-8bit (ORCPT ); Fri, 5 May 2006 19:45:17 +0100 Received: from mail01.m-online.net (svr21.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 2C43772EE4; Fri, 5 May 2006 20:45:11 +0200 (CEST) X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= X-Auth-Info: o2OpLf2+X028E3W086dSuk21T1L8H+iHadiZAilxY+o= Received: from mail.denx.de (p549675E3.dip.t-dialin.net [84.150.117.227]) by smtp-auth.mnet-online.de (Postfix) with ESMTP id 0D6E79194F; Fri, 5 May 2006 20:45:11 +0200 (CEST) Received: from atlas.denx.de (atlas.denx.de [10.0.0.14]) by mail.denx.de (Postfix) with ESMTP id 9790D6D00A8; Fri, 5 May 2006 20:45:10 +0200 (CEST) Received: from atlas.denx.de (localhost.localdomain [127.0.0.1]) by atlas.denx.de (Postfix) with ESMTP id 86790353BE7; Fri, 5 May 2006 20:45:10 +0200 (MEST) To: Geert Uytterhoeven cc: Tom Rini , Ralf Baechle , Thiemo Seufer , Tim Bird , Linux/MIPS Development From: Wolfgang Denk Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 In-reply-to: Your message of "Fri, 05 May 2006 09:45:38 +0200." Date: Fri, 05 May 2006 20:45:10 +0200 Message-Id: <20060505184510.86790353BE7@atlas.denx.de> Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wd@denx.de Precedence: bulk X-list: linux-mips Content-Length: 1080 Lines: 26 In message you wrote: > > But on second thought: config options are part of the target configuration, > while CROSS_COMPILE= is part of the host configuration, so IMHO it doesn't > belong in Kconfig. I.e. do you want to have CONFIG_CROSS_COMPILE set in your > defconfig? Yes or no, depending on whether you do cross-compilations or not. So > you cannot simply take a defconfig, you'll have to modify it for your host > setup. CONFIG_CROSS_COMPILE is a terrible idea. Don't do it. We may want to try different tool chains which require different CROSS_COMPILE settings with exact the same default config file. Don't break this! > So I'd prefer to keep the CROSS_COMPILE, like other arches do. Me too! Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de If A equals success, then the formula is A = X + Y + Z. X is work. Y is play. Z is keep your mouth shut. - Albert Einstein From asingh@ikanos.com Fri May 5 23:36:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 May 2006 23:36:24 +0100 (BST) Received: from curley.ikanos.com ([206.40.46.115]:12140 "EHLO maple.ikanos.com") by ftp.linux-mips.org with ESMTP id S8133813AbWEEWgP (ORCPT ); Fri, 5 May 2006 23:36:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67094.952AA11C" Subject: Changing Kernel Frequency Date: Fri, 5 May 2006 15:38:08 -0700 Message-ID: <6D18EB74171FCF4281F8D13726E1E7B703CB7BE6@maple.ikanos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing Kernel Frequency Thread-Index: AcZwlExYUt7CvhyPRdCN+wUlsOx7dw== From: "Akshay Singh" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: asingh@ikanos.com Precedence: bulk X-list: linux-mips Content-Length: 1587 Lines: 64 This is a multi-part message in MIME format. ------_=_NextPart_001_01C67094.952AA11C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All,=20 We use Linux 2.6 for VoIP solutions and I was using default kernel frequency (1000) and everything works good ( A very minimum jitter) but when I change the kernel frequency from 1000 to 100, jitter increases a lot ! Any pointers on this.=20 FYI , we use 200 MHz MIPS based processor. Thanks, Akshay ------_=_NextPart_001_01C67094.952AA11C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changing Kernel Frequency

All,

We use Linux 2.6 for VoIP solutions and = I was using default kernel frequency (1000) and everything works good ( = A very minimum jitter) but when I change the kernel frequency from 1000 = to 100, jitter increases a lot !

Any pointers on this.

FYI , we use 200 MHz MIPS based = processor.

Thanks,
Akshay


------_=_NextPart_001_01C67094.952AA11C-- From sathesh_edara2003@yahoo.co.in Sat May 6 07:29:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 07:29:27 +0100 (BST) Received: from web8707.mail.in.yahoo.com ([203.84.221.128]:61316 "HELO web8707.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S8133353AbWEFG3S (ORCPT ); Sat, 6 May 2006 07:29:18 +0100 Received: (qmail 9779 invoked by uid 60001); 6 May 2006 06:29:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FEQtFL9sJnNpHwzb3Kf4oQ6zCrfn1PGyYbNsUBu1jj3puhLjH+gKhpljvme3uPhy6avParLhTJvBtwszd9eJVPiuKW7Tg9kkkeZlasn/aObvC8b2NNQV3BNU4FBjBDYZOh52/wDUQ5SXXZhlUdamNddqYFijObXoSaw3kOiUBQw= ; Message-ID: <20060506062911.9777.qmail@web8707.mail.in.yahoo.com> Received: from [137.71.23.54] by web8707.mail.in.yahoo.com via HTTP; Sat, 06 May 2006 07:29:11 BST Date: Sat, 6 May 2006 07:29:11 +0100 (BST) From: sathesh babu Subject: kgdb version Linux-mips- 2.6.12 To: linux-mips@linux-mips.org, linux-cvs-patches@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1317611256-1146896951=:8241" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sathesh_edara2003@yahoo.co.in Precedence: bulk X-list: linux-mips Content-Length: 1447 Lines: 31 --0-1317611256-1146896951=:8241 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Could you please give the following info on Linux-mips-2.6.12 kernel version. 1) If i download Linux-2.6.12 kernel from linux-mips.org, Can i get KGDB as part of distribution. If yes, what is the version of KGDB?. if no, what version of the KGDB patch should be applied and where can i get this patch?. Regards, Sathesh --------------------------------- Yahoo! India Answers: Share what you know. Learn something new. Click here --0-1317611256-1146896951=:8241 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
   Could you please give the following info on Linux-mips-2.6.12 kernel version.
  
  1) If i download Linux-2.6.12 kernel from linux-mips.org, Can i get KGDB as part of distribution.
 
  If yes, what is the version of KGDB?.
  if no, what version of the KGDB patch should be applied and where can i get this patch?.
 
Regards,
Sathesh


Yahoo! India Answers: Share what you know. Learn something new. Click here --0-1317611256-1146896951=:8241-- From sathesh_edara2003@yahoo.co.in Sat May 6 07:32:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 07:32:18 +0100 (BST) Received: from web8714.mail.in.yahoo.com ([203.84.221.135]:35473 "HELO web8714.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S8133353AbWEFGcJ (ORCPT ); Sat, 6 May 2006 07:32:09 +0100 Received: (qmail 48976 invoked by uid 60001); 6 May 2006 06:31:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=A1JJi26OtJNtAsd4+8uf6j969U4giMH11ZnWxshWGrIhKiumNTlvaRsLw/UFJsYH7RKjNpjC9EWgiCOj5nw6grV9+mmLBXv7ACAQMEsFLkiZRLevdTT3xQwOkI6M4yiyFp3dmr7Ffp3rQxRgucGVd+iR4CY2t8048vIVmTx1dTk= ; Message-ID: <20060506063159.48974.qmail@web8714.mail.in.yahoo.com> Received: from [137.71.23.54] by web8714.mail.in.yahoo.com via HTTP; Sat, 06 May 2006 07:31:59 BST Date: Sat, 6 May 2006 07:31:59 +0100 (BST) From: sathesh babu Subject: kgdb version Linux-mips- 2.6.12 To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-86373334-1146897119=:48565" Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sathesh_edara2003@yahoo.co.in Precedence: bulk X-list: linux-mips Content-Length: 1434 Lines: 29 --0-86373334-1146897119=:48565 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Could you please give the following info on Linux-mips-2.6.12 kernel version. 1) If i download Linux-2.6.12 kernel from linux-mips.org, Can i get KGDB as part of distribution. If yes, what is the version of KGDB?. if no, what version of the KGDB patch should be applied and where can i get this patch?. Regards, Sathesh --------------------------------- Yahoo! India Answers: Share what you know. Learn something new. Click here --0-86373334-1146897119=:48565 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
   Could you please give the following info on Linux-mips-2.6.12 kernel version.
  
  1) If i download Linux-2.6.12 kernel from linux-mips.org, Can i get KGDB as part of distribution.
 
  If yes, what is the version of KGDB?.
  if no, what version of the KGDB patch should be applied and where can i get this patch?.
 
Regards,
Sathesh

Yahoo! India Answers: Share what you know. Learn something new. Click here --0-86373334-1146897119=:48565-- From dpervushin@ru.mvista.com Sat May 6 09:03:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 09:03:38 +0100 (BST) Received: from rtsoft3.corbina.net ([85.21.88.6]:57202 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S8133433AbWEFIDL (ORCPT ); Sat, 6 May 2006 09:03:11 +0100 Received: from [192.168.5.10] ([10.150.0.9]) by buildserver.ru.mvista.com (8.11.6/8.11.6) with ESMTP id k46836s24343 for ; Sat, 6 May 2006 13:03:06 +0500 Subject: [PATCH] [RFC] support for NEC EMMA2RH board From: dmitry pervushin Reply-To: dpervushin@ru.mvista.com To: linux-mips@linux-mips.org Content-Type: text/plain Organization: montavista Date: Sat, 06 May 2006 12:02:56 +0400 Message-Id: <1146902576.6369.3.camel@diimka-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dpervushin@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 81113 Lines: 2841 Hello all, The patch below adds base support for NEC EMMA2RH Mark-eins board. Any comments and feedback will be appreciated Signed-off-by: dmitry pervushin Index: linux-2.6.10/arch/mips/configs/emma2rh_defconfig =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/configs/emma2rh_defconfig @@ -0,0 +1,1088 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.10_mvl401 +# Thu Apr 27 19:51:02 2006 +# +CONFIG_MIPS=y +# CONFIG_MIPS64 is not set +# CONFIG_64BIT is not set +CONFIG_MIPS32=y + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +# CONFIG_CLEAN_COMPILE is not set +CONFIG_BROKEN=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SEMMNI=128 +CONFIG_SYSVIPC_SEMMSL=250 +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_HOTPLUG=y +CONFIG_KOBJECT_UEVENT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_FUTEX=y +CONFIG_EPOLL=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_LTT_MAX_HANDLES=128 +# CONFIG_BOOT_FLIGHT_RECORDER is not set +CONFIG_LOCKLESS=y +CONFIG_BOOT_FLIGHT_BUFFERS=4 +CONFIG_BOOT_FLIGHT_SIZE=524288 +CONFIG_FLIGHT_PROC_BUFFERS=8 +CONFIG_FLIGHT_PROC_SIZE=8192 +CONFIG_NEWEV=y +CONFIG_CSTM=y +# CONFIG_TINY_SHMEM is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_OBSOLETE_MODPARM=y +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Machine selection +# +# CONFIG_MACH_JAZZ is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_MIPS_BRCM is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MIPS_EV96100 is not set +# CONFIG_MIPS_IVR is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ITE8172 is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_PNX8550_STB810 is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_VR5701_SG2 is not set +# CONFIG_NEC_OSPREY is not set +CONFIG_MARKEINS=y +# CONFIG_SGI_IP22 is not set +# CONFIG_SOC_AU1X00 is not set +# CONFIG_SIBYTE_SB1xxx_SOC is not set +# CONFIG_SNI_RM200_PCI is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +# CONFIG_TOSHIBA_RBTX4939 is not set +# CONFIG_CAVIUM_OCTEON_EBT3000 is not set +# CONFIG_PREEMPT_NONE is not set +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT_DESKTOP is not set +CONFIG_PREEMPT_RT=y +CONFIG_PREEMPT=y +CONFIG_PREEMPT_SOFTIRQS=y +CONFIG_PREEMPT_HARDIRQS=y +CONFIG_PREEMPT_RCU=y +CONFIG_PREEMPT_BKL=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ASM_SEMAPHORES=y +CONFIG_HAVE_DEC_LOCK=y +CONFIG_DMA_NONCOHERENT=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_IRQ_CPU=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_EMMA2RH=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +CONFIG_CPU_MIPS32=y +# CONFIG_CPU_MIPS64 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R5500 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +# CONFIG_CPU_CAVIUM_OCTEON is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +# CONFIG_VTAG_ICACHE is not set +# CONFIG_64BIT_PHYS_ADDR is not set +# CONFIG_CPU_ADVANCED is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +# CONFIG_HIGH_RES_TIMERS is not set +# CONFIG_CPU_TIMER is not set + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_LEGACY_PROC is not set +CONFIG_PCI_NAMES=y +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PC-card bridges +# + +# +# PCI Hotplug Support +# +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y +# CONFIG_BINFMT_IRIX is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set +# CONFIG_DEBUG_DRIVER is not set + +# +# Memory Technology Devices (MTD) +# +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +CONFIG_MTD_CMDLINE_PARTS=y + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_MTD_CFI=y +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_GEN_PROBE=y +# CONFIG_MTD_CFI_ADV_OPTIONS is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_CFI_INTELEXT is not set +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_AMDSTD_RETRY=0 +# CONFIG_MTD_CFI_STAA is not set +CONFIG_MTD_CFI_UTIL=y +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set +# CONFIG_MTD_OBSOLETE_CHIPS is not set +# CONFIG_MTD_XIP is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PHYSMAP is not set +# CONFIG_MTD_MULTI_PHYSMAP is not set +CONFIG_MTD_EMMA2RH=y +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_PMC551 is not set +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +# CONFIG_MTD_MTDRAM is not set +# CONFIG_RAMTD is not set +# CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_CRYPTOLOOP=m +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_RAM is not set +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_INITRAMFS_SOURCE="" +CONFIG_LBD=y +# CONFIG_CDROM_PKTCDVD is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +CONFIG_SCSI=m +# CONFIG_SCSI_PROC_FS is not set + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=m +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +CONFIG_CHR_DEV_SG=m + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set + +# +# SCSI Transport Attributes +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set + +# +# SCSI low-level drivers +# +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_ADP94XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ADVANSYS is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_SCSI_SATA is not set +# CONFIG_SCSI_BUSLOGIC is not set +# CONFIG_SCSI_CPQFCTS is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_EATA is not set +# CONFIG_SCSI_EATA_PIO is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_GDTH is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_IPR is not set +# CONFIG_SCSI_PCI2000 is not set +# CONFIG_SCSI_PCI2220I is not set +# CONFIG_SCSI_QLOGIC_ISP is not set +# CONFIG_SCSI_QLOGIC_FC is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +CONFIG_SCSI_QLA2XXX=m +# CONFIG_SCSI_QLA21XX is not set +# CONFIG_SCSI_QLA22XX is not set +# CONFIG_SCSI_QLA2300 is not set +# CONFIG_SCSI_QLA2322 is not set +# CONFIG_SCSI_QLA6312 is not set +# CONFIG_SCSI_QLA6322 is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Networking support +# +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +CONFIG_PACKET_MMAP=y +# CONFIG_NETLINK_DEV is not set +CONFIG_UNIX=y +CONFIG_NET_KEY=y +# CONFIG_NET_KEY_MIGRATE is not set +CONFIG_USE_POLICY_FWD=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_PNP=y +# CONFIG_IP_PNP_DHCP is not set +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +CONFIG_SYN_COOKIES=y +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_TUNNEL is not set +# CONFIG_IP_TCPDIAG is not set +# CONFIG_IP_TCPDIAG_IPV6 is not set +CONFIG_IPV6=m +# CONFIG_IPV6_PRIVACY is not set +# CONFIG_IPV6_ROUTER_PREF is not set +# CONFIG_INET6_AH is not set +# CONFIG_INET6_ESP is not set +# CONFIG_INET6_IPCOMP is not set +# CONFIG_INET6_TUNNEL is not set +# CONFIG_IPV6_TUNNEL is not set +# CONFIG_IPV6_ADVANCED_ROUTER is not set +# CONFIG_IPV6_MIP6 is not set +# CONFIG_NETFILTER is not set +CONFIG_XFRM=y +# CONFIG_XFRM_USER is not set +# CONFIG_XFRM_ENHANCEMENT is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +CONFIG_IP_SCTP=m +# CONFIG_SCTP_DBG_MSG is not set +# CONFIG_SCTP_DBG_OBJCNT is not set +# CONFIG_SCTP_HMAC_NONE is not set +# CONFIG_SCTP_HMAC_SHA1 is not set +CONFIG_SCTP_HMAC_MD5=y +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set +# CONFIG_NET_CLS_ROUTE is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_SMC91X is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set + +# +# Broadcom network devices +# +# CONFIG_HND is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +CONFIG_NATSEMI=y +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_TSLIBDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input I/O drivers +# +# CONFIG_GAMEPORT is not set +CONFIG_SOUND_GAMEPORT=y +# CONFIG_SERIO is not set +# CONFIG_SERIO_I8042 is not set + +# +# Input Device Drivers +# +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=4 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +CONFIG_RTC=m +# CONFIG_RTC_HISTOGRAM is not set +# CONFIG_BLOCKER is not set +CONFIG_GEN_RTC=m +CONFIG_GEN_RTC_X=y +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# I2C support +# +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y + +# +# I2C Algorithms +# +# CONFIG_I2C_ALGOBIT is not set +# CONFIG_I2C_ALGOPCF is not set +# CONFIG_I2C_ALGOPCA is not set +# CONFIG_I2C_ALGO_SGI is not set +CONFIG_I2C_ALGO_EMMA2RH=y + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_ALI1535 is not set +# CONFIG_I2C_ALI1563 is not set +# CONFIG_I2C_ALI15X3 is not set +# CONFIG_I2C_AMD756 is not set +# CONFIG_I2C_AMD8111 is not set +# CONFIG_I2C_I801 is not set +# CONFIG_I2C_I810 is not set +# CONFIG_I2C_ISA is not set +# CONFIG_I2C_NFORCE2 is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_PIIX4 is not set +# CONFIG_I2C_PROSAVAGE is not set +# CONFIG_I2C_SAVAGE4 is not set +# CONFIG_SCx200_ACB is not set +# CONFIG_I2C_SIS5595 is not set +# CONFIG_I2C_SIS630 is not set +# CONFIG_I2C_SIS96X is not set +# CONFIG_I2C_STUB is not set +# CONFIG_I2C_VIA is not set +# CONFIG_I2C_VIAPRO is not set +# CONFIG_I2C_VOODOO3 is not set +# CONFIG_I2C_PCA_ISA is not set +# CONFIG_I2C_OMAP is not set +CONFIG_I2C_EMMA2RH=y + +# +# Hardware Sensors Chip support +# +# CONFIG_I2C_SENSOR is not set +# CONFIG_SENSORS_ADM1021 is not set +# CONFIG_SENSORS_ADM1025 is not set +# CONFIG_SENSORS_ADM1026 is not set +# CONFIG_SENSORS_ADM1031 is not set +# CONFIG_SENSORS_ASB100 is not set +# CONFIG_SENSORS_DS1621 is not set +# CONFIG_SENSORS_FSCHER is not set +# CONFIG_SENSORS_GL518SM is not set +# CONFIG_SENSORS_IT87 is not set +# CONFIG_SENSORS_LM63 is not set +# CONFIG_SENSORS_LM75 is not set +# CONFIG_SENSORS_LM77 is not set +# CONFIG_SENSORS_LM78 is not set +# CONFIG_SENSORS_LM80 is not set +# CONFIG_SENSORS_LM83 is not set +# CONFIG_SENSORS_LM85 is not set +# CONFIG_SENSORS_LM87 is not set +# CONFIG_SENSORS_LM90 is not set +# CONFIG_SENSORS_MAX1619 is not set +# CONFIG_SENSORS_PC87360 is not set +# CONFIG_SENSORS_SMSC47M1 is not set +# CONFIG_SENSORS_VIA686A is not set +# CONFIG_SENSORS_W83781D is not set +# CONFIG_SENSORS_W83L785TS is not set +# CONFIG_SENSORS_W83627HF is not set + +# +# Other I2C Chip support +# +# CONFIG_SENSORS_DS1374 is not set +# CONFIG_SENSORS_EEPROM is not set +# CONFIG_SENSORS_PCF8574 is not set +# CONFIG_SENSORS_PCF8591 is not set +# CONFIG_SENSORS_RTC8564 is not set +# CONFIG_TPS65010 is not set +# CONFIG_I2C_DEBUG_CHIP is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Misc devices +# + +# +# Multimedia Capabilities Port drivers +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set + +# +# Graphics support +# +# CONFIG_FB is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +# CONFIG_USB is not set +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# Synchronous Serial Interfaces (SSI) +# + +# +# File systems +# +CONFIG_EXT2_FS=y +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT2_FS_POSIX_ACL=y +CONFIG_EXT2_FS_SECURITY=y +# CONFIG_EXT3_FS is not set +# CONFIG_JBD is not set +CONFIG_FS_MBCACHE=y +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +CONFIG_FS_POSIX_ACL=y +# CONFIG_XFS_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_QUOTA is not set +# CONFIG_DNOTIFY is not set +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +CONFIG_NTFS_FS=m +# CONFIG_NTFS_DEBUG is not set +# CONFIG_NTFS_RW is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_SYSFS=y +# CONFIG_DEVFS_FS is not set +CONFIG_DEVPTS_FS_XATTR=y +CONFIG_DEVPTS_FS_SECURITY=y +CONFIG_TMPFS=y +CONFIG_TMPFS_XATTR=y +CONFIG_TMPFS_SECURITY=y +# CONFIG_HUGETLBFS is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_RELAYFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_JFFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set +# CONFIG_JFFS2_CMODE_NONE is not set +CONFIG_JFFS2_CMODE_PRIORITY=y +# CONFIG_JFFS2_CMODE_SIZE is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set +# CONFIG_YAFFS_FS is not set +# CONFIG_YAFFS1_FS is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_NFS_V4=y +CONFIG_NFS_DIRECTIO=y +# CONFIG_NFSD is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +# CONFIG_EXPORTFS is not set +CONFIG_SUNRPC=y +CONFIG_SUNRPC_GSS=y +CONFIG_RPCSEC_GSS_KRB5=y +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="" +# CONFIG_NLS_CODEPAGE_437 is not set +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +# CONFIG_NLS_ISO8859_1 is not set +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +# CONFIG_DEBUG_KERNEL=y +# CONFIG_MAGIC_SYSRQ is not set +# CONFIG_SCHEDSTATS is not set +# CONFIG_DEBUG_SLAB is not set +# CONFIG_DEBUG_PREEMPT is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_WAKEUP_TIMING is not set +# CONFIG_CRITICAL_PREEMPT_TIMING is not set +# CONFIG_CRITICAL_IRQSOFF_TIMING is not set +#CONFIG_RT_DEADLOCK_DETECT=y +#CONFIG_DEBUG_KOBJECT=y +#CONFIG_DEBUG_INFO=y +# CONFIG_KGDB is not set +CONFIG_CROSSCOMPILE=y +# CONFIG_CMDLINE="" +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_RUNTIME_DEBUG is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_HMAC=y +# CONFIG_CRYPTO_NULL is not set +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=y +# CONFIG_CRYPTO_SHA1 is not set +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_AES is not set +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_CRC32C is not set +# CONFIG_CRYPTO_TEST is not set + +# +# Library routines +# +# CONFIG_CRC_CCITT is not set +CONFIG_CRC32=y +# CONFIG_LIBCRC32C is not set +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y + +# +# Fast Real-Time Domain +# +# CONFIG_FRD is not set + +# +# Fast Real-Time Domain Advanced Options +# +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y Index: linux-2.6.10/arch/mips/emma2rh/common/irq.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/common/irq.c @@ -0,0 +1,108 @@ +/* + * arch/mips/emma2rh/common/irq.c + * This file is common irq dispatcher. + * + * Copyright (C) NEC Electronics Corporation 2005-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/irq.c + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* + * the first level int-handler will jump here if it is a emma2rh irq + */ +asmlinkage void emma2rh_irq_dispatch(struct pt_regs *regs) +{ + u32 intStatus; + u32 bitmask; + u32 i; + + intStatus = emma2rh_in32(EMMA2RH_BHIF_INT_ST_0) + & emma2rh_in32(EMMA2RH_BHIF_INT_EN_0); + +#ifdef EMMA2RH_SW_CASCADE + if (intStatus & + (1 << ((EMMA2RH_SW_CASCADE - EMMA2RH_IRQ_INT0) & (32 - 1)))) { + u32 swIntStatus; + swIntStatus = emma2rh_in32(EMMA2RH_BHIF_SW_INT) + & emma2rh_in32(EMMA2RH_BHIF_SW_INT_EN); + for (i = 0, bitmask = 1; i < 32; i++, bitmask <<= 1) { + if (swIntStatus & bitmask) { + do_IRQ(EMMA2RH_SW_IRQ_BASE + i, regs); + return; + } + } + } +#endif + + for (i = 0, bitmask = 1; i < 32; i++, bitmask <<= 1) { + if (intStatus & bitmask) { + do_IRQ(EMMA2RH_IRQ_BASE + i, regs); + return; + } + } + + intStatus = emma2rh_in32(EMMA2RH_BHIF_INT_ST_1) + & emma2rh_in32(EMMA2RH_BHIF_INT_EN_1); + +#ifdef EMMA2RH_GPIO_CASCADE + if (intStatus & + (1 << ((EMMA2RH_GPIO_CASCADE - EMMA2RH_IRQ_INT0) & (32 - 1)))) { + u32 gpioIntStatus; + gpioIntStatus = emma2rh_in32(EMMA2RH_GPIO_INT_ST) + & emma2rh_in32(EMMA2RH_GPIO_INT_MASK); + for (i = 0, bitmask = 1; i < 32; i++, bitmask <<= 1) { + if (gpioIntStatus & bitmask) { + do_IRQ(EMMA2RH_GPIO_IRQ_BASE + i, regs); + return; + } + } + } +#endif + + for (i = 32, bitmask = 1; i < 64; i++, bitmask <<= 1) { + if (intStatus & bitmask) { + do_IRQ(EMMA2RH_IRQ_BASE + i, regs); + return; + } + } + + intStatus = emma2rh_in32(EMMA2RH_BHIF_INT_ST_2) + & emma2rh_in32(EMMA2RH_BHIF_INT_EN_2); + + for (i = 64, bitmask = 1; i < 96; i++, bitmask <<= 1) { + if (intStatus & bitmask) { + do_IRQ(EMMA2RH_IRQ_BASE + i, regs); + return; + } + } +} Index: linux-2.6.10/arch/mips/emma2rh/common/irq_emma2rh.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/common/irq_emma2rh.c @@ -0,0 +1,135 @@ +/* + * arch/mips/emma2rh/common/irq_emma2rh.c + * This file defines the irq handler for EMMA2RH. + * + * Copyright (C) NEC Electronics Corporation 2005-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/irq_5477.c + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* + * EMMA2RH defines 64 IRQs. + * + * This file exports one function: + * emma2rh_irq_init(u32 irq_base); + */ + +#include +#include +#include + +#include + +#include + +/* number of total irqs supported by EMMA2RH */ +#define NUM_EMMA2RH_IRQ 96 + +static int emma2rh_irq_base = -1; + +void ll_emma2rh_irq_enable(int); +void ll_emma2rh_irq_disable(int); + +static void emma2rh_irq_enable(unsigned int irq) +{ + ll_emma2rh_irq_enable(irq - emma2rh_irq_base); +} + +static void emma2rh_irq_disable(unsigned int irq) +{ + ll_emma2rh_irq_disable(irq - emma2rh_irq_base); +} + +static unsigned int emma2rh_irq_startup(unsigned int irq) +{ + emma2rh_irq_enable(irq); + return 0; +} + +#define emma2rh_irq_shutdown emma2rh_irq_disable + +static void emma2rh_irq_ack(unsigned int irq) +{ + /* disable interrupt - some handler will re-enable the irq + * and if the interrupt is leveled, we will have infinite loop + */ + ll_emma2rh_irq_disable(irq - emma2rh_irq_base); +} + +static void emma2rh_irq_end(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + ll_emma2rh_irq_enable(irq - emma2rh_irq_base); +} + +hw_irq_controller emma2rh_irq_controller = { + .typename = "emma2rh_irq", + .startup = emma2rh_irq_startup, + .shutdown = emma2rh_irq_shutdown, + .enable = emma2rh_irq_enable, + .disable = emma2rh_irq_disable, + .ack = emma2rh_irq_ack, + .end = emma2rh_irq_end, + .set_affinity = NULL /* no affinity stuff for UP */ +}; + +void emma2rh_irq_init(u32 irq_base) +{ + extern irq_desc_t irq_desc[]; + u32 i; + + for (i = irq_base; i < irq_base + NUM_EMMA2RH_IRQ; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 1; + irq_desc[i].handler = &emma2rh_irq_controller; + } + + emma2rh_irq_base = irq_base; +} + +void ll_emma2rh_irq_enable(int emma2rh_irq) +{ + u32 reg_value; + u32 reg_bitmask; + u32 reg_index; + + reg_index = EMMA2RH_BHIF_INT_EN_0 + + (EMMA2RH_BHIF_INT_EN_1 - EMMA2RH_BHIF_INT_EN_0) + * (emma2rh_irq / 32); + reg_value = emma2rh_in32(reg_index); + reg_bitmask = 0x1 << (emma2rh_irq % 32); + db_assert((reg_value & reg_bitmask) == 0); + emma2rh_out32(reg_index, reg_value | reg_bitmask); +} + +void ll_emma2rh_irq_disable(int emma2rh_irq) +{ + u32 reg_value; + u32 reg_bitmask; + u32 reg_index; + + reg_index = EMMA2RH_BHIF_INT_EN_0 + + (EMMA2RH_BHIF_INT_EN_1 - EMMA2RH_BHIF_INT_EN_0) + * (emma2rh_irq / 32); + reg_value = emma2rh_in32(reg_index); + reg_bitmask = 0x1 << (emma2rh_irq % 32); + db_assert((reg_value & reg_bitmask) != 0); + emma2rh_out32(reg_index, reg_value & ~reg_bitmask); +} Index: linux-2.6.10/arch/mips/emma2rh/common/Makefile =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/common/Makefile @@ -0,0 +1,13 @@ +# +# arch/mips/emma2rh/common/Makefile +# Makefile for the common code of NEC EMMA2RH based board. +# +# Copyright (C) NEC Electronics Corporation 2005-2006 +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# + +obj-$(CONFIG_MARKEINS) += irq.o irq_emma2rh.o prom.o Index: linux-2.6.10/arch/mips/emma2rh/common/prom.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/common/prom.c @@ -0,0 +1,77 @@ +/* + * arch/mips/emma2rh/common/prom.c + * This file is prom file. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This file is based on the arch/mips/ddb5xxx/common/prom.c + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +const char *get_system_type(void) +{ + switch (mips_machtype) { + case MACH_NEC_MARKEINS: + return "NEC EMMA2RH Mark-eins"; + default: + return "Unknown NEC board"; + } +} + +/* [jsun@junsun.net] PMON passes arguments in C main() style */ +void __init prom_init(void) +{ + int argc = fw_arg0; + char **arg = (char **)fw_arg1; + int i; + + /* if user passes kernel args, ignore the default one */ + if (argc > 1) + arcs_cmdline[0] = '\0'; + + /* arg[0] is "g", the rest is boot parameters */ + for (i = 1; i < argc; i++) { + if (strlen(arcs_cmdline) + strlen(arg[i] + 1) + >= sizeof(arcs_cmdline)) + break; + strcat(arcs_cmdline, arg[i]); + strcat(arcs_cmdline, " "); + } + + mips_machgroup = MACH_GROUP_NEC_EMMA2RH; + +#if defined(CONFIG_MARKEINS) + mips_machtype = MACH_NEC_MARKEINS; + add_memory_region(0, EMMA2RH_RAM_SIZE, BOOT_MEM_RAM); +#endif + +} + +void __init prom_free_prom_memory(void) +{ +} Index: linux-2.6.10/arch/mips/emma2rh/markeins/int-handler.S =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/int-handler.S @@ -0,0 +1,88 @@ +/* + * arch/mips/emma2rh/markeins/int-handler.S + * first level dispatcher for EMMA2RH Mark-eins. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/int-handler.S + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include + +/* + * first level interrupt dispatcher for Mark-eins board - + * We check for the timer first, then check PCI ints A and D. + * Then check for serial IRQ and fall through. + */ + .align 5 + NESTED(emma2rh_handle_int, PT_SIZE, sp) + SAVE_ALL + CLI + .set at + .set noreorder + mfc0 t0, CP0_CAUSE + mfc0 t2, CP0_STATUS + + and t0, t2 + + andi t1, t0, STATUSF_IP7 /* cpu timer */ + bnez t1, ll_cputimer_irq + andi t1, t0, STATUSF_IP2 /* emma2rh int 2 */ + bnez t1, ll_emma2rh_irq + andi t1, t0, STATUSF_IP1 /* software int 1 */ + bnez t1, ll_cpu_ip1 + andi t1, t0, STATUSF_IP0 /* software int 0 */ + bnez t1, ll_cpu_ip0 + nop + .set reorder + + /* wrong alarm or masked ... */ + j spurious_interrupt + nop + END(emma2rh_handle_int) + + .align 5 + +ll_emma2rh_irq: + move a0, sp + jal emma2rh_irq_dispatch + j ret_from_irq + +ll_cputimer_irq: + li a0, CPU_IRQ_BASE + 7 + move a1, sp + jal do_IRQ + j ret_from_irq + + +ll_cpu_ip0: + li a0, CPU_IRQ_BASE + 0 + move a1, sp + jal do_IRQ + j ret_from_irq + +ll_cpu_ip1: + li a0, CPU_IRQ_BASE + 1 + move a1, sp + jal do_IRQ + j ret_from_irq Index: linux-2.6.10/arch/mips/emma2rh/markeins/irq.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/irq.c @@ -0,0 +1,112 @@ +/* + * arch/mips/emma2rh/markeins/irq.c + * This file defines the irq handler for EMMA2RH. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/irq.c + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* + * IRQ mapping + * + * 0-7: 8 CPU interrupts + * 0 - software interrupt 0 + * 1 - software interrupt 1 + * 2 - most Vrc5477 interrupts are routed to this pin + * 3 - (optional) some other interrupts routed to this pin for debugg + * 4 - not used + * 5 - not used + * 6 - not used + * 7 - cpu timer (used by default) + * + */ + +extern void emma2rh_sw_irq_init(u32 base); +extern void emma2rh_gpio_irq_init(u32 base); +extern void emma2rh_irq_init(u32 base); +extern void mips_cpu_irq_init(u32 base); +extern asmlinkage void emma2rh_handle_int(void); +extern int setup_irq(unsigned int irq, struct irqaction *irqaction); +static struct irqaction irq_cascade = + { no_action, 0, CPU_MASK_NONE, "cascade", NULL, NULL }; + +void __init arch_init_irq(void) +{ + u32 reg; + + db_run(printk("markeins_irq_setup invoked.\n")); + + /* by default, interrupts are disabled. */ + emma2rh_out32(EMMA2RH_BHIF_INT_EN_0, 0); + emma2rh_out32(EMMA2RH_BHIF_INT_EN_1, 0); + emma2rh_out32(EMMA2RH_BHIF_INT_EN_2, 0); + emma2rh_out32(EMMA2RH_BHIF_INT1_EN_0, 0); + emma2rh_out32(EMMA2RH_BHIF_INT1_EN_1, 0); + emma2rh_out32(EMMA2RH_BHIF_INT1_EN_2, 0); + emma2rh_out32(EMMA2RH_BHIF_SW_INT_EN, 0); + + clear_c0_status(0xff00); + set_c0_status(0x0400); + +#define GPIO_PCI (0xf<<15) + /* setup GPIO interrupt for PCI interface */ + /* direction input */ + reg = emma2rh_in32(EMMA2RH_GPIO_DIR); + emma2rh_out32(EMMA2RH_GPIO_DIR, reg & ~GPIO_PCI); + /* disable interrupt */ + reg = emma2rh_in32(EMMA2RH_GPIO_INT_MASK); + emma2rh_out32(EMMA2RH_GPIO_INT_MASK, reg & ~GPIO_PCI); + /* level triggerd */ + reg = emma2rh_in32(EMMA2RH_GPIO_INT_MODE); + emma2rh_out32(EMMA2RH_GPIO_INT_MODE, reg | GPIO_PCI); + reg = emma2rh_in32(EMMA2RH_GPIO_INT_CND_A); + emma2rh_out32(EMMA2RH_GPIO_INT_CND_A, reg & (~GPIO_PCI)); + /* interrupt clear */ + emma2rh_out32(EMMA2RH_GPIO_INT_ST, ~GPIO_PCI); + + /* init all controllers */ + emma2rh_irq_init(EMMA2RH_IRQ_BASE); + emma2rh_sw_irq_init(EMMA2RH_SW_IRQ_BASE); + emma2rh_gpio_irq_init(EMMA2RH_GPIO_IRQ_BASE); + mips_cpu_irq_init(CPU_IRQ_BASE); + + /* setup cascade interrupts */ + setup_irq(EMMA2RH_IRQ_BASE + EMMA2RH_SW_CASCADE, &irq_cascade); + setup_irq(EMMA2RH_IRQ_BASE + EMMA2RH_GPIO_CASCADE, &irq_cascade); + setup_irq(CPU_IRQ_BASE + CPU_EMMA2RH_CASCADE, &irq_cascade); + + /* hook up the first-level interrupt handler */ + set_except_vector(0, emma2rh_handle_int); +} Index: linux-2.6.10/arch/mips/emma2rh/markeins/irq_markeins.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/irq_markeins.c @@ -0,0 +1,198 @@ +/* + * arch/mips/emma2rh/markeins/irq_markeins.c + * This file defines the irq handler for Mark-eins. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/irq_5477.c + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include + +#include +#include + +static int emma2rh_sw_irq_base = -1; +static int emma2rh_gpio_irq_base = -1; + +void ll_emma2rh_sw_irq_enable(int reg); +void ll_emma2rh_sw_irq_disable(int reg); +void ll_emma2rh_gpio_irq_enable(int reg); +void ll_emma2rh_gpio_irq_disable(int reg); + +static void emma2rh_sw_irq_enable(unsigned int irq) +{ + ll_emma2rh_sw_irq_enable(irq - emma2rh_sw_irq_base); +} + +static void emma2rh_sw_irq_disable(unsigned int irq) +{ + ll_emma2rh_sw_irq_disable(irq - emma2rh_sw_irq_base); +} + +static unsigned int emma2rh_sw_irq_startup(unsigned int irq) +{ + emma2rh_sw_irq_enable(irq); + return 0; +} + +#define emma2rh_sw_irq_shutdown emma2rh_sw_irq_disable + +static void emma2rh_sw_irq_ack(unsigned int irq) +{ + ll_emma2rh_sw_irq_disable(irq - emma2rh_sw_irq_base); +} + +static void emma2rh_sw_irq_end(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + ll_emma2rh_sw_irq_enable(irq - emma2rh_sw_irq_base); +} + +hw_irq_controller emma2rh_sw_irq_controller = { + .typename = "emma2rh_sw_irq", + .startup = emma2rh_sw_irq_startup, + .shutdown = emma2rh_sw_irq_shutdown, + .enable = emma2rh_sw_irq_enable, + .disable = emma2rh_sw_irq_disable, + .ack = emma2rh_sw_irq_ack, + .end = emma2rh_sw_irq_end, + .set_affinity = NULL, +}; + +void emma2rh_sw_irq_init(u32 irq_base) +{ + extern irq_desc_t irq_desc[]; + u32 i; + + for (i = irq_base; i < irq_base + NUM_EMMA2RH_IRQ_SW; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 2; + irq_desc[i].handler = &emma2rh_sw_irq_controller; + } + + emma2rh_sw_irq_base = irq_base; +} + +void ll_emma2rh_sw_irq_enable(int irq) +{ + u32 reg; + + db_assert(irq >= 0); + db_assert(irq < NUM_EMMA2RH_IRQ_SW); + + reg = emma2rh_in32(EMMA2RH_BHIF_SW_INT_EN); + reg |= 1 << irq; + emma2rh_out32(EMMA2RH_BHIF_SW_INT_EN, reg); +} + +void ll_emma2rh_sw_irq_disable(int irq) +{ + u32 reg; + + db_assert(irq >= 0); + db_assert(irq < 32); + + reg = emma2rh_in32(EMMA2RH_BHIF_SW_INT_EN); + reg &= ~(1 << irq); + emma2rh_out32(EMMA2RH_BHIF_SW_INT_EN, reg); +} + +static void emma2rh_gpio_irq_enable(unsigned int irq) +{ + ll_emma2rh_gpio_irq_enable(irq - emma2rh_gpio_irq_base); +} + +static void emma2rh_gpio_irq_disable(unsigned int irq) +{ + ll_emma2rh_gpio_irq_disable(irq - emma2rh_gpio_irq_base); +} + +static unsigned int emma2rh_gpio_irq_startup(unsigned int irq) +{ + emma2rh_gpio_irq_enable(irq); + return 0; +} + +#define emma2rh_gpio_irq_shutdown emma2rh_gpio_irq_disable + +static void emma2rh_gpio_irq_ack(unsigned int irq) +{ + irq -= emma2rh_gpio_irq_base; + emma2rh_out32(EMMA2RH_GPIO_INT_ST, ~(1 << irq)); + ll_emma2rh_gpio_irq_disable(irq); +} + +static void emma2rh_gpio_irq_end(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + ll_emma2rh_gpio_irq_enable(irq - emma2rh_gpio_irq_base); +} + +hw_irq_controller emma2rh_gpio_irq_controller = { + .typename = "emma2rh_gpio_irq", + .startup = emma2rh_gpio_irq_startup, + .shutdown = emma2rh_gpio_irq_shutdown, + .enable = emma2rh_gpio_irq_enable, + .disable = emma2rh_gpio_irq_disable, + .ack = emma2rh_gpio_irq_ack, + .end = emma2rh_gpio_irq_end, + .set_affinity = NULL, +}; + +void emma2rh_gpio_irq_init(u32 irq_base) +{ + extern irq_desc_t irq_desc[]; + u32 i; + + for (i = irq_base; i < irq_base + NUM_EMMA2RH_IRQ_GPIO; i++) { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = NULL; + irq_desc[i].depth = 2; + irq_desc[i].handler = &emma2rh_gpio_irq_controller; + } + + emma2rh_gpio_irq_base = irq_base; +} + +void ll_emma2rh_gpio_irq_enable(int irq) +{ + u32 reg; + + db_assert(irq >= 0); + db_assert(irq < NUM_EMMA2RH_IRQ_GPIO); + + reg = emma2rh_in32(EMMA2RH_GPIO_INT_MASK); + reg |= 1 << irq; + emma2rh_out32(EMMA2RH_GPIO_INT_MASK, reg); +} + +void ll_emma2rh_gpio_irq_disable(int irq) +{ + u32 reg; + + db_assert(irq >= 0); + db_assert(irq < NUM_EMMA2RH_IRQ_GPIO); + + reg = emma2rh_in32(EMMA2RH_GPIO_INT_MASK); + reg &= ~(1 << irq); + emma2rh_out32(EMMA2RH_GPIO_INT_MASK, reg); +} Index: linux-2.6.10/arch/mips/emma2rh/markeins/led.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/led.c @@ -0,0 +1,60 @@ +/* + * arch/mips/emma2rh/markeins/led.c + * This file defines the led display for Mark-eins. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include + +const unsigned long clear = 0x20202020; + +#define LED_BASE 0xb1400038 + +void markeins_led_clear(void) +{ + emma2rh_out32(LED_BASE, clear); + emma2rh_out32(LED_BASE + 4, clear); +} + +void markeins_led(const char *str) +{ + int i; + int len = strlen(str); + + markeins_led_clear(); + if (len > 8) + len = 8; + + if (emma2rh_in32(0xb0000800) & (0x1 << 18)) + for (i = 0; i < len; i++) + emma2rh_out8(LED_BASE + i, str[i]); + else + for (i = 0; i < len; i++) + emma2rh_out8(LED_BASE + (i & 4) + (3 - (i & 3)), + str[i]); +} + +void markeins_led_hex(u32 val) +{ + char str[10]; + + sprintf(str, "%08x", val); + markeins_led(str); +} Index: linux-2.6.10/arch/mips/emma2rh/markeins/Makefile =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/Makefile @@ -0,0 +1,14 @@ +# +# arch/mips/emma2rh/markeins/Makefile +# Makefile for the common code of NEC EMMA2RH based board. +# +# Copyright (C) NEC Electronics Corporation 2005-2006 +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# + +obj-$(CONFIG_MARKEINS) += int-handler.o irq.o irq_markeins.o setup.o led.o platform.o +# EXTRA_AFLAGS := $(CFLAGS) Index: linux-2.6.10/arch/mips/emma2rh/markeins/setup.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/setup.c @@ -0,0 +1,173 @@ +/* + * arch/mips/emma2rh/markeins/setup.c + * This file is setup for EMMA2RH Mark-eins. + * + * Copyright (C) NEC Electronics Corporation 2004-2006 + * + * This file is based on the arch/mips/ddb5xxx/ddb5477/setup.c. + * + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include /* for ROOT_DEV */ +#include +#include /* for HZ */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define USE_CPU_COUNTER_TIMER /* whether we use cpu counter */ + +extern void markeins_led(const char *); + +static int bus_frequency = 0; + +static void markeins_machine_restart(char *command) +{ + static void (*back_to_prom) (void) = (void (*)(void))0xbfc00000; + + printk("cannot EMMA2RH Mark-eins restart.\n"); + markeins_led("restart."); + back_to_prom(); +} + +static void markeins_machine_halt(void) +{ + printk("EMMA2RH Mark-eins halted.\n"); + markeins_led("halted."); + while (1) ; +} + +static void markeins_machine_power_off(void) +{ + printk("EMMA2RH Mark-eins halted. Please turn off the power.\n"); + markeins_led("poweroff."); + while (1) ; +} + +static unsigned long clock[4] = { 166500000, 187312500, 199800000, 210600000 }; + +static unsigned int __init detect_bus_frequency(unsigned long rtc_base) +{ + u32 reg; + + /* detect from boot strap */ + reg = emma2rh_in32(EMMA2RH_BHIF_STRAP_0); + reg = (reg >> 4) & 0x3; + return clock[reg]; +} + +static void __init emma2rh_time_init(void) +{ + u32 reg; + if (bus_frequency == 0) + bus_frequency = detect_bus_frequency(0); + + reg = emma2rh_in32(EMMA2RH_BHIF_STRAP_0); + if ((reg & 0x3) == 0) + reg = (reg >> 6) & 0x3; + else { + reg = emma2rh_in32(EMMA2RH_BHIF_MAIN_CTRL); + reg = (reg >> 4) & 0x3; + } + mips_hpt_frequency = (bus_frequency * (4 + reg)) / 4 / 2; +} + +extern int setup_irq(unsigned int irq, struct irqaction *irqaction); + +static void __init emma2rh_timer_setup(struct irqaction *irq) +{ + /* we are using the cpu counter for timer interrupts */ + setup_irq(CPU_IRQ_BASE + 7, irq); +} + +static void markeins_board_init(void); +extern void markeins_irq_setup(void); + +#if defined(CONFIG_BLK_DEV_INITRD) +extern unsigned long __rd_start, __rd_end, initrd_start, initrd_end; +#endif + +int __init platform_setup(void) +{ + extern int panic_timeout; + + /* initialize board - we don't trust the loader */ + markeins_board_init(); + + set_io_port_base(KSEG1ADDR(EMMA2RH_PCI_IO_BASE)); + + board_time_init = emma2rh_time_init; + board_timer_setup = emma2rh_timer_setup; + + _machine_restart = markeins_machine_restart; + _machine_halt = markeins_machine_halt; + _machine_power_off = markeins_machine_power_off; + + /* setup resource limits */ + ioport_resource.start = EMMA2RH_PCI_IO_BASE; + ioport_resource.end = EMMA2RH_PCI_IO_BASE + EMMA2RH_PCI_IO_SIZE - 1; + iomem_resource.start = EMMA2RH_IO_BASE; + iomem_resource.end = EMMA2RH_PCI_MEM_BASE + EMMA2RH_PCI_MEM_SIZE - 1; + + /* Reboot on panic */ + panic_timeout = 180; + +#if defined(CONFIG_BLK_DEV_INITRD) + ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0); + initrd_start = (unsigned long)&__rd_start; + initrd_end = (unsigned long)&__rd_end; +#endif + + return 0; +} + +static void __init markeins_board_init(void) +{ + u32 val; + + val = emma2rh_in32(EMMA2RH_PBRD_INT_EN); /* open serial interrupts. */ + emma2rh_out32(EMMA2RH_PBRD_INT_EN, val | 0xaa); + val = emma2rh_in32(EMMA2RH_PBRD_CLKSEL); /* set serial clocks. */ + emma2rh_out32(EMMA2RH_PBRD_CLKSEL, val | 0x5); /* 18MHz */ + emma2rh_out32(EMMA2RH_PCI_CONTROL, 0); + + markeins_led("MVL E2RH"); +} + +early_initcall(platform_setup); Index: linux-2.6.10/arch/mips/Kconfig =================================================================== --- linux-2.6.10.orig/arch/mips/Kconfig +++ linux-2.6.10/arch/mips/Kconfig @@ -516,6 +516,19 @@ config NEC_OSPREY select DMA_NONCOHERENT select IRQ_CPU +config MARKEINS + bool "Support for NEC EMMA2RH Mark-eins" + select DMA_NONCOHERENT + select HW_HAS_PCI + select IRQ_CPU + select SWAP_IO_SPACE + help + This enables support for the R5432-based NEC Mark-eins + boards with R5500 CPU. + + Features : kernel debugging, serial terminal, NFS root fs, on-board + ether port USB, PCI, etc. + config SGI_IP22 bool "Support for SGI IP22 (Indy/Indigo2)" select ARC @@ -1134,7 +1147,7 @@ config MIPS_DISABLE_OBSOLETE_IDE config CPU_LITTLE_ENDIAN bool "Generate little endian code" default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477 || MACH_DECSTATION || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR || SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI || VICTOR_MPC30X || ZAO_CAPCELLA - default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT || MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927 || CAVIUM_OCTEON_EBT3000 + default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT || MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927 || CAVIUM_OCTEON_EBT3000 || MARKEINS help Some MIPS machines can be configured for either little or big endian byte order. These modes require different kernels. Say Y if your @@ -1198,6 +1211,11 @@ config SOC_PNX8550 config SWAP_IO_SPACE bool +config EMMA2RH + bool + depends on MARKEINS + default y + # # Unfortunately not all GT64120 systems run the chip at the same clock. # As the user for the clock rate and try to minimize the available options. Index: linux-2.6.10/arch/mips/Makefile =================================================================== --- linux-2.6.10.orig/arch/mips/Makefile +++ linux-2.6.10/arch/mips/Makefile @@ -177,7 +177,7 @@ cflags-$(CONFIG_CPU_MIPS64) += \ cflags-$(CONFIG_CPU_R5000) += \ $(call set_gccflags,r5000,mips4,r5000,mips4,mips2) \ - -Wa,--trap + -Wa,--trap cflags-$(CONFIG_CPU_R5432) += \ $(call set_gccflags,r5400,mips4,r5000,mips4,mips2) \ @@ -577,6 +577,16 @@ load-$(CONFIG_PNX8550_JBS) += 0xffffffff # libs-$(CONFIG_PNX8550_STB810) += arch/mips/philips/pnx8550/stb810/ load-$(CONFIG_PNX8550_STB810) += 0xffffffff80060000 +# NEC EMMA2RH boards +# +core-$(CONFIG_EMMA2RH) += arch/mips/emma2rh/common/ +cflags-$(CONFIG_EMMA2RH) += -Iinclude/asm-mips/mach-emma2rh + +# NEC EMMA2RH Mark-eins +core-$(CONFIG_MARKEINS) += arch/mips/emma2rh/markeins/ +load-$(CONFIG_MARKEINS) += 0xffffffff88100000 + +# # # SGI IP22 (Indy/Indigo2) @@ -816,7 +826,7 @@ archclean: @$(MAKE) $(clean)=arch/mips/boot @$(MAKE) $(clean)=arch/mips/lasat -# Generate +#else +#error "Unknown EMMA2RH board!" +#endif + +#endif /* __ASM_EMMA2RH_EMMA2RH_H */ Index: linux-2.6.10/include/asm-mips/emma2rh/hardware.h =================================================================== --- /dev/null +++ linux-2.6.10/include/asm-mips/emma2rh/hardware.h @@ -0,0 +1,29 @@ + +#define FLASH_WINDOW_ADDR 0x1e000000 +#define FLASH_WINDOW_SIZE 0x02000000 +#endif /* CONFIG_MARKEINS */ + +/* -------------------------------------------------------------------- */ +/* i2c-algo-emma2rh.h: NEC EMMA2RH global defines */ +/* -------------------------------------------------------------------- */ +/* + Copyright (C) NEC Electronics Corporation 2005-2006 + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA*/ +/* -------------------------------------------------------------------- */ + +#ifndef I2C_EMMA2RH_H +#define I2C_EMMA2RH_H +#endif /* I2C_EMMA2RH_H */ Index: linux-2.6.10/include/asm-mips/emma2rh/markeins.h =================================================================== --- /dev/null +++ linux-2.6.10/include/asm-mips/emma2rh/markeins.h @@ -0,0 +1,80 @@ +/* + * include/asm-mips/emma2rh/markeins.h + * This file is EMMA2RH board depended header. + * + * Copyright (C) NEC Electronics Corporation 2005-2006 + * + * This file based on include/asm-mips/ddb5xxx/ddb5xxx.h + * Copyright 2001 MontaVista Software Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef MARKEINS_H +#define MARKEINS_H + +#define NUM_EMMA2RH_IRQ_SW 32 +#define NUM_EMMA2RH_IRQ_GPIO 32 + +#define EMMA2RH_SW_CASCADE (EMMA2RH_IRQ_INT7 - EMMA2RH_IRQ_INT0) +#define EMMA2RH_GPIO_CASCADE (EMMA2RH_IRQ_INT46 - EMMA2RH_IRQ_INT0) + +#define EMMA2RH_SW_IRQ_BASE (EMMA2RH_IRQ_BASE + NUM_EMMA2RH_IRQ) +#define EMMA2RH_GPIO_IRQ_BASE (EMMA2RH_SW_IRQ_BASE + NUM_EMMA2RH_IRQ_SW) +#define CPU_IRQ_BASE (EMMA2RH_GPIO_IRQ_BASE + NUM_EMMA2RH_IRQ_GPIO) + +#define EMMA2RH_SW_IRQ_INT0 (0+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT1 (1+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT2 (2+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT3 (3+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT4 (4+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT5 (5+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT6 (6+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT7 (7+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT8 (8+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT9 (9+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT10 (10+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT11 (11+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT12 (12+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT13 (13+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT14 (14+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT15 (15+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT16 (16+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT17 (17+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT18 (18+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT19 (19+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT20 (20+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT21 (21+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT22 (22+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT23 (23+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT24 (24+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT25 (25+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT26 (26+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT27 (27+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT28 (28+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT29 (29+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT30 (30+EMMA2RH_SW_IRQ_BASE) +#define EMMA2RH_SW_IRQ_INT31 (31+EMMA2RH_SW_IRQ_BASE) + +#define MARKEINS_PCI_IRQ_INTA EMMA2RH_GPIO_IRQ_BASE+15 +#define MARKEINS_PCI_IRQ_INTB EMMA2RH_GPIO_IRQ_BASE+16 +#define MARKEINS_PCI_IRQ_INTC EMMA2RH_GPIO_IRQ_BASE+17 +#define MARKEINS_PCI_IRQ_INTD EMMA2RH_GPIO_IRQ_BASE+18 + +/* flash */ +#define FLASH_WINDOW_ADDR 0x1e000000 +#define FLASH_WINDOW_SIZE 0x02000000 + +#endif /* CONFIG_MARKEINS */ Index: linux-2.6.10/include/asm-mips/mach-emma2rh/irq.h =================================================================== --- /dev/null +++ linux-2.6.10/include/asm-mips/mach-emma2rh/irq.h @@ -0,0 +1,13 @@ +/* + * 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 + * for more details. + * + * Copyright (C) 2003 by Ralf Baechle + */ +#ifndef __ASM_MACH_EMMA2RH_IRQ_H +#define __ASM_MACH_EMMA2RH_IRQ_H + +#define NR_IRQS 256 + +#endif /* __ASM_MACH_EMMA2RH_IRQ_H */ Index: linux-2.6.10/arch/mips/emma2rh/markeins/platform.c =================================================================== --- /dev/null +++ linux-2.6.10/arch/mips/emma2rh/markeins/platform.c @@ -0,0 +1,135 @@ +/* + * arch/mips/emma2rh/markeins/platofrm.c + * This file sets up platform devices for EMMA2RH Mark-eins. + * + * Copyright(C) MontaVista Software Inc, 2006 + * + * Author: dmitry pervushin + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#define I2C_EMMA2RH "emma2rh-iic" /* must be in sync with IIC driver */ + +static struct resource i2c_emma_resources_0[] = { + { NULL, EMMA2RH_IRQ_PIIC0, EMMA2RH_IRQ_PIIC0, IORESOURCE_IRQ }, + { NULL, KSEG1ADDR(EMMA2RH_PIIC0_BASE), KSEG1ADDR(EMMA2RH_PIIC0_BASE + 0x1000), 0 }, +}; + +struct resource i2c_emma_resources_1[] = { + { NULL, EMMA2RH_IRQ_PIIC1, EMMA2RH_IRQ_PIIC1, IORESOURCE_IRQ }, + { NULL, KSEG1ADDR(EMMA2RH_PIIC1_BASE), KSEG1ADDR(EMMA2RH_PIIC1_BASE + 0x1000), 0 }, +}; + +struct resource i2c_emma_resources_2[] = { + { NULL, EMMA2RH_IRQ_PIIC2, EMMA2RH_IRQ_PIIC2, IORESOURCE_IRQ }, + { NULL, KSEG1ADDR(EMMA2RH_PIIC2_BASE), KSEG1ADDR(EMMA2RH_PIIC2_BASE + 0x1000), 0 }, +}; + +struct platform_device i2c_emma_devices[] = { + [0] = { + .name = I2C_EMMA2RH, + .id = 0, + .resource = i2c_emma_resources_0, + .num_resources = ARRAY_SIZE(i2c_emma_resources_0), + }, + [1] = { + .name = I2C_EMMA2RH, + .id = 1, + .resource = i2c_emma_resources_1, + .num_resources = ARRAY_SIZE(i2c_emma_resources_1), + }, + [2] = { + .name = I2C_EMMA2RH, + .id = 2, + .resource = i2c_emma_resources_2, + .num_resources = ARRAY_SIZE(i2c_emma_resources_2), + }, +}; + +#define EMMA2RH_SERIAL_CLOCK 18544000 +#define EMMA2RH_SERIAL_FLAGS UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ + +static struct plat_serial8250_port platform_serial_ports[] = { + [0] = { + .membase = (void __iomem*)KSEG1ADDR(EMMA2RH_PFUR0_BASE + 3), + .irq = EMMA2RH_IRQ_PFUR0, + .uartclk = EMMA2RH_SERIAL_CLOCK, + .regshift = 4, + .iotype = UPIO_MEM, + .flags = EMMA2RH_SERIAL_FLAGS, + }, + [1] = { + .membase = (void __iomem*)KSEG1ADDR(EMMA2RH_PFUR1_BASE + 3), + .irq = EMMA2RH_IRQ_PFUR1, + .uartclk = EMMA2RH_SERIAL_CLOCK, + .regshift = 4, + .iotype = UPIO_MEM, + .flags = EMMA2RH_SERIAL_FLAGS, + }, + [2] = { + .membase = (void __iomem*)KSEG1ADDR(EMMA2RH_PFUR2_BASE + 3), + .irq = EMMA2RH_IRQ_PFUR2, + .uartclk = EMMA2RH_SERIAL_CLOCK, + .regshift = 4, + .iotype = UPIO_MEM, + .flags = EMMA2RH_SERIAL_FLAGS, + }, + [3] = { + .flags = 0, + }, +}; + +static struct platform_device serial_emma = { + .name = "serial8250", + .dev = { + .platform_data = &platform_serial_ports, + }, +}; + +static struct platform_device *devices[] = { + &i2c_emma_devices[0], + &i2c_emma_devices[1], + &i2c_emma_devices[2], + &serial_emma, +}; + +static int __init platform_devices_setup(void) +{ + return platform_add_devices(devices, ARRAY_SIZE(devices)); +} + +arch_initcall(platform_devices_setup); + -- cheers, dmitry pervushin From rongkai.zhan@windriver.com Sat May 6 10:04:32 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 10:04:52 +0100 (BST) Received: from mail.windriver.com ([147.11.1.11]:42626 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8133433AbWEFJEc (ORCPT ); Sat, 6 May 2006 10:04:32 +0100 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k4694PcR005718; Sat, 6 May 2006 02:04:25 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 May 2006 02:04:25 -0700 Received: from [192.168.1.101] ([147.11.69.1]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 May 2006 02:04:22 -0700 Message-ID: <445C6694.6010901@windriver.com> Date: Sat, 06 May 2006 17:04:20 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: ralf@linux-mips.org Subject: Re: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2006 09:04:23.0160 (UTC) FILETIME=[114EAF80:01C670EC] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 37504 Lines: 1499 Hi Ralf, According to your comments, I re-create the patch. Hopefully, no line-wrapped problems:-) Patch 1 and 2 in the original mails are concatenated into one patch in this mail. Best Regards, Mark.Zhan Signed-off-by: Rongkai.Zhan ---- diff -uprN linux-2.6.16.11/arch/mips/configs/wrppmc_defconfig linux-2.6.16.11-ppmc/arch/mips/configs/wrppmc_defconfig --- linux-2.6.16.11/arch/mips/configs/wrppmc_defconfig 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/configs/wrppmc_defconfig 2006-05-05 17:11:22.000000000 +0800 @@ -0,0 +1,801 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.16.11 +# Fri May 5 17:11:22 2006 +# +CONFIG_MIPS=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MIPS_EV96100 is not set +# CONFIG_MIPS_IVR is not set +# CONFIG_MIPS_ITE8172 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +CONFIG_WR_PPMC=y +# CONFIG_MIPS_SIM is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_DDB5074 is not set +# CONFIG_DDB5476 is not set +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM200_PCI is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +CONFIG_CPU_BIG_ENDIAN=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_IRQ_CPU=y +CONFIG_MIPS_GT64120=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_BOOT_ELF32=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +CONFIG_CPU_MIPS32_R1=y +# CONFIG_CPU_MIPS32_R2 is not set +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_HAS_CPU_MIPS32_R2=y +CONFIG_SYS_HAS_CPU_MIPS64_R1=y +CONFIG_SYS_HAS_CPU_NEVADA=y +CONFIG_SYS_HAS_CPU_RM7000=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_CPU_HAS_PREFETCH=y +# CONFIG_MIPS_MT is not set +# CONFIG_64BIT_PHYS_ADDR is not set +# CONFIG_CPU_ADVANCED is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +# CONFIG_EPOLL is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_SLAB=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_OBSOLETE_MODPARM=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +# CONFIG_KMOD is not set + +# +# Block layer +# +# CONFIG_LBD is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +CONFIG_PCI_LEGACY_PROC=y +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# +CONFIG_HOTPLUG_PCI=y +# CONFIG_HOTPLUG_PCI_FAKE is not set +# CONFIG_HOTPLUG_PCI_CPCI is not set +# CONFIG_HOTPLUG_PCI_SHPC is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +CONFIG_BINFMT_MISC=y +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +CONFIG_PACKET=y +CONFIG_PACKET_MMAP=y +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +CONFIG_IP_MROUTE=y +# CONFIG_IP_PIMSM_V1 is not set +# CONFIG_IP_PIMSM_V2 is not set +CONFIG_ARPD=y +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_BIC=y +# CONFIG_IPV6 is not set +# CONFIG_NETFILTER is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=4096 +CONFIG_BLK_DEV_INITRD=y +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +# CONFIG_SCSI is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +CONFIG_PHYLIB=y + +# +# MII PHY device drivers +# +# CONFIG_MARVELL_PHY is not set +# CONFIG_DAVICOM_PHY is not set +# CONFIG_QSEMI_PHY is not set +# CONFIG_LXT_PHY is not set +# CONFIG_CICADA_PHY is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_DM9000 is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +CONFIG_E100=y +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_LAN_SAA9730 is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SKY2 is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +# CONFIG_INPUT is not set + +# +# Hardware I/O ports +# +# CONFIG_SERIO is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=1 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +CONFIG_RTC=y +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set +# CONFIG_TELCLOCK is not set + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_SENSORS_F71805F is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Misc devices +# + +# +# Multimedia Capabilities Port drivers +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set + +# +# Graphics support +# +# CONFIG_FB is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +# CONFIG_USB is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# + +# +# File systems +# +# CONFIG_EXT2_FS is not set +# CONFIG_EXT3_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +CONFIG_INOTIFY=y +# CONFIG_QUOTA is not set +CONFIG_DNOTIFY=y +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +# CONFIG_MSDOS_FS is not set +# CONFIG_VFAT_FS is not set +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_RELAYFS_FS is not set +# CONFIG_CONFIGFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +# CONFIG_NFS_V3_ACL is not set +# CONFIG_NFS_V4 is not set +# CONFIG_NFS_DIRECTIO is not set +# CONFIG_NFSD is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +# CONFIG_RPCSEC_GSS_KRB5 is not set +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +# CONFIG_NLS is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +# CONFIG_PRINTK_TIME is not set +# CONFIG_MAGIC_SYSRQ is not set +# CONFIG_DEBUG_KERNEL is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="console=ttyS0,115200n8" + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +# CONFIG_CRYPTO is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_CRC_CCITT=y +CONFIG_CRC16=y +CONFIG_CRC32=y +CONFIG_LIBCRC32C=y diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/int-handler.S linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/int-handler.S --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/int-handler.S 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/int-handler.S 2006-05-06 15:41:04.000000000 +0800 @@ -0,0 +1,59 @@ +/* + * 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 + * for more details. + * + * Copyright (C) 1995, 1996, 1997, 2003 by Ralf Baechle + * Copyright (C) Wind River System Inc. Rongkai.Zhan + */ +#include +#include +#include +#include +#include +#include + + .align 5 + .set noat +NESTED(handle_IRQ, PT_SIZE, sp) + SAVE_ALL + CLI # Important: mark KERNEL mode ! + .set at + + mfc0 t0, CP0_CAUSE # get pending interrupts + mfc0 t1, CP0_STATUS # get enabled interrupts + and t0, t0, t1 # get allowed interrupts + andi t0, t0, 0xFF00 + beqz t0, 1f + move a1, sp # Prepare 'struct pt_regs *regs' pointer + + andi t1, t0, CAUSEF_IP7 # CPU Compare/Count internal timer + bnez t1, handle_cputimer_irq + andi t1, t0, CAUSEF_IP6 # UART 16550 port + bnez t1, handle_uart_irq + andi t1, t0, CAUSEF_IP3 # PCI INT_A + bnez t1, handle_pci_intA_irq + + /* wrong alarm or masked ... */ +1: j spurious_interrupt + nop +END(handle_IRQ) + + .align 5 +handle_cputimer_irq: + li a0, WRPPMC_MIPS_TIMER_IRQ + jal do_IRQ + j ret_from_irq + + .align 5 +handle_uart_irq: + li a0, WRPPMC_UART16550_IRQ + jal do_IRQ + j ret_from_irq + + .align 5 +handle_pci_intA_irq: + li a0, WRPPMC_PCI_INTA_IRQ + jal do_IRQ + j ret_from_irq + diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/irq.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/irq.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/irq.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/irq.c 2006-05-06 15:39:27.000000000 +0800 @@ -0,0 +1,63 @@ +/* + * irq.c: GT64120 Interrupt Controller + * + * Copyright (C) 2006, Wind River System Inc. + * Author: Rongkai.Zhan, + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +extern asmlinkage void handle_IRQ(void); + +/** + * Initialize GT64120 Interrupt Controller + */ +void gt64120_init_pic(void) +{ + /* clear CPU Interrupt Cause Registers */ + GT_WRITE(GT_INTRCAUSE_OFS, (0x1F << 21)); + GT_WRITE(GT_HINTRCAUSE_OFS, 0x00); + + /* Disable all interrupts from GT64120 bridge chip */ + GT_WRITE(GT_INTRMASK_OFS, 0x00); + GT_WRITE(GT_HINTRMASK_OFS, 0x00); + GT_WRITE(GT_PCI0_ICMASK_OFS, 0x00); + GT_WRITE(GT_PCI0_HICMASK_OFS, 0x00); +} + +void __init arch_init_irq(void) +{ + /* enable all CPU interrupt bits. */ + set_c0_status(ST0_IM); /* IE bit is still 0 */ + + /* Install MIPS Interrupt Trap Vector */ + set_except_vector(0, handle_IRQ); + + /* IRQ 0 - 7 are for MIPS common irq_cpu controller */ + mips_cpu_irq_init(0); + + gt64120_init_pic(); +} diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/Makefile linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/Makefile --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/Makefile 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/Makefile 2006-04-14 15:25:48.000000000 +0800 @@ -0,0 +1,14 @@ +# +# 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 +# for more details. +# +# Copyright 2006 Wind River System, Inc. +# Author: Rongkai.Zhan +# +# Makefile for the Wind River MIPS 4KC PPMC Eval Board +# + +obj-y += int-handler.o irq.o reset.o setup.o time.o pci.o + +EXTRA_AFLAGS := $(CFLAGS) diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/pci.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/pci.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/pci.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/pci.c 2006-05-05 17:25:48.000000000 +0800 @@ -0,0 +1,53 @@ +/* + * pci.c: GT64120 PCI support. + * + * Copyright (C) 2006, Wind River System Inc. Rongkai.Zhan + * + * 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 + * for more details. + */ +#include +#include +#include +#include +#include + +extern struct pci_ops gt64120_pci_ops; + +static struct resource pci0_io_resource = { + .name = "pci_0 io", + .start = GT_PCI_IO_BASE, + .end = GT_PCI_IO_BASE + GT_PCI_IO_SIZE - 1, + .flags = IORESOURCE_IO, +}; + +static struct resource pci0_mem_resource = { + .name = "pci_0 memory", + .start = GT_PCI_MEM_BASE, + .end = GT_PCI_MEM_BASE + GT_PCI_MEM_SIZE - 1, + .flags = IORESOURCE_MEM, +}; + +static struct pci_controller hose_0 = { + .pci_ops = >64120_pci_ops, + .io_resource = &pci0_io_resource, + .mem_resource = &pci0_mem_resource, +}; + +static int __init gt64120_pci_init(void) +{ + u32 tmp; + + tmp = GT_READ(GT_PCI0_CMD_OFS); /* Huh??? -- Ralf */ + tmp = GT_READ(GT_PCI0_BARE_OFS); + + /* reset the whole PCI I/O space range */ + ioport_resource.start = GT_PCI_IO_BASE; + ioport_resource.end = GT_PCI_IO_BASE + GT_PCI_IO_SIZE - 1; + + register_pci_controller(&hose_0); + return 0; +} + +arch_initcall(gt64120_pci_init); diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/reset.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/reset.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/reset.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/reset.c 2006-04-13 22:24:56.000000000 +0800 @@ -0,0 +1,50 @@ +/* + * 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 + * for more details. + * + * Copyright (C) 1997 Ralf Baechle + */ +#include +#include +#include +#include +#include +#include +#include +#include + +void wrppmc_machine_restart(char *command) +{ + /* + * Ouch, we're still alive ... This time we take the silver bullet ... + * ... and find that we leave the hardware in a state in which the + * kernel in the flush locks up somewhen during of after the PCI + * detection stuff. + */ + local_irq_disable(); + set_c0_status(ST0_BEV | ST0_ERL); + change_c0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); + flush_cache_all(); + write_c0_wired(0); + __asm__ __volatile__("jr\t%0"::"r"(0xbfc00000)); +} + +void wrppmc_machine_halt(void) +{ + local_irq_disable(); + + printk(KERN_NOTICE "You can safely turn off the power\n"); + while (1) { + __asm__( + ".set\tmips3\n\t" + "wait\n\t" + ".set\tmips0" + ); + } +} + +void wrppmc_machine_power_off(void) +{ + wrppmc_machine_halt(); +} diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/setup.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/setup.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/setup.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/setup.c 2006-05-06 16:05:30.000000000 +0800 @@ -0,0 +1,173 @@ +/* + * setup.c: Setup pointers to hardware dependent routines. + * + * 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 + * for more details. + * + * Copyright (C) 1996, 1997, 2004 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2006, Wind River System Inc. Rongkai.zhan + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +unsigned long gt64120_base = KSEG1ADDR(0x14000000); + +#ifdef WRPPMC_EARLY_DEBUG + +static volatile unsigned char * wrppmc_led = \ + (volatile unsigned char *)KSEG1ADDR(WRPPMC_LED_BASE); + +/* + * PPMC LED control register: + * -) bit[0] controls DS1 LED (1 - OFF, 0 - ON) + * -) bit[1] controls DS2 LED (1 - OFF, 0 - ON) + * -) bit[2] controls DS4 LED (1 - OFF, 0 - ON) + */ +void wrppmc_led_on(int mask) +{ + unsigned char value = *wrppmc_led; + + value &= (0xF8 | mask); + *wrppmc_led = value; +} + +/* If mask = 0, turn off all LEDs */ +void wrppmc_led_off(int mask) +{ + unsigned char value = *wrppmc_led; + + value |= (0x7 & mask); + *wrppmc_led = value; +} + +/* + * We assume that bootloader has initialized UART16550 correctly + */ +void __init wrppmc_early_putc(char ch) +{ + static volatile unsigned char *wrppmc_uart = \ + (volatile unsigned char *)KSEG1ADDR(WRPPMC_UART16550_BASE); + unsigned char value; + + /* Wait until Transmit-Holding-Register is empty */ + while (1) { + value = *(wrppmc_uart + 5); + if (value & 0x20) + break; + } + + *wrppmc_uart = ch; +} + +void __init wrppmc_early_printk(const char *fmt, ...) +{ + static char pbuf[256] = {'\0', }; + char *ch = pbuf; + va_list args; + unsigned int i; + + memset(pbuf, 0, 256); + va_start(args, fmt); + i = vsprintf(pbuf, fmt, args); + va_end(args); + + /* Print the string */ + while (*ch != '\0') { + wrppmc_early_putc(*ch); + /* if print '\n', also print '\r' */ + if (*ch++ == '\n') + wrppmc_early_putc('\r'); + } +} +#endif /* WRPPMC_EARLY_DEBUG */ + +unsigned long __init prom_free_prom_memory(void) +{ + return 0; +} + +#ifdef CONFIG_SERIAL_8250 +static void wrppmc_setup_serial(void) +{ + struct uart_port up; + + memset(&up, 0x00, sizeof(struct uart_port)); + + /* + * A note about mapbase/membase + * -) mapbase is the physical address of the IO port. + * -) membase is an 'ioremapped' cookie. + */ + up.line = 0; + up.type = PORT_16550; + up.iotype = UPIO_MEM; + up.mapbase = WRPPMC_UART16550_BASE; + up.membase = ioremap(up.mapbase, 8); + up.irq = WRPPMC_UART16550_IRQ; + up.uartclk = WRPPMC_UART16550_CLOCK; + up.flags = UPF_SKIP_TEST/* | UPF_BOOT_AUTOCONF */; + up.regshift = 0; + + early_serial_setup(&up); +} +#endif + +void __init plat_setup(void) +{ + extern void wrppmc_time_init(void); + extern void wrppmc_timer_setup(struct irqaction *); + extern void wrppmc_machine_restart(char *command); + extern void wrppmc_machine_halt(void); + extern void wrppmc_machine_power_off(void); + + _machine_restart = wrppmc_machine_restart; + _machine_halt = wrppmc_machine_halt; + pm_power_off = wrppmc_machine_power_off; + + /* Use MIPS Count/Compare Timer */ + board_time_init = wrppmc_time_init; + board_timer_setup = wrppmc_timer_setup; + + /* This makes the operations of 'in/out[bwl]' to the + * physical address ( < KSEG0) can work via KSEG1 + */ + set_io_port_base(KSEG1); + +#ifdef CONFIG_SERIAL_8250 + wrppmc_setup_serial(); +#endif +} + +const char *get_system_type(void) +{ + return "Wind River PPMC (GT64120)"; +} + +/* + * Initializes basic routines and structures pointers, memory size (as + * given by the bios and saves the command line. + */ +void __init prom_init(void) +{ + mips_machgroup = MACH_GROUP_GALILEO; + mips_machtype = MACH_EV64120A; + + add_memory_region(WRPPMC_SDRAM_SCS0_BASE, WRPPMC_SDRAM_SCS0_SIZE, BOOT_MEM_RAM); + add_memory_region(WRPPMC_BOOTROM_BASE, WRPPMC_BOOTROM_SIZE, BOOT_MEM_ROM_DATA); + + wrppmc_early_printk("prom_init: GT64120 SDRAM Bank 0: 0x%x - 0x%08lx\n", + WRPPMC_SDRAM_SCS0_BASE, (WRPPMC_SDRAM_SCS0_BASE + WRPPMC_SDRAM_SCS0_SIZE)); +} diff -uprN linux-2.6.16.11/arch/mips/gt64120/wrppmc/time.c linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/time.c --- linux-2.6.16.11/arch/mips/gt64120/wrppmc/time.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/gt64120/wrppmc/time.c 2006-05-05 16:39:32.000000000 +0800 @@ -0,0 +1,57 @@ +/* + * time.c: MIPS CPU Count/Compare timer hookup + * + * Author: Mark.Zhan, + * + * 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 + * for more details. + * + * Copyright (C) 1996, 1997, 2004 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2006, Wind River System Inc. + */ +#include +#include +#include +#include +#include /* for HZ */ +#include +#include +#include + +#include +#include +#include +#include +#include + +#define WRPPMC_CPU_CLK_FREQ 40000000 /* 40MHZ */ + +void __init wrppmc_timer_setup(struct irqaction *irq) +{ + /* Install ISR for timer interrupt */ + setup_irq(WRPPMC_MIPS_TIMER_IRQ, irq); + + /* to generate the first timer interrupt */ + write_c0_compare(mips_hpt_frequency/HZ); + write_c0_count(0); +} + +/* + * Estimate CPU frequency. Sets mips_hpt_frequency as a side-effect + * + * NOTE: We disable all GT64120 timers, and use MIPS processor internal + * timer as the source of kernel clock tick. + */ +void __init wrppmc_time_init(void) +{ + /* Disable GT64120 timers */ + GT_WRITE(GT_TC_CONTROL_OFS, 0x00); + GT_WRITE(GT_TC0_OFS, 0x00); + GT_WRITE(GT_TC1_OFS, 0x00); + GT_WRITE(GT_TC2_OFS, 0x00); + GT_WRITE(GT_TC3_OFS, 0x00); + + /* Use MIPS compare/count internal timer */ + mips_hpt_frequency = WRPPMC_CPU_CLK_FREQ; +} diff -uprN linux-2.6.16.11/arch/mips/Kconfig linux-2.6.16.11-ppmc/arch/mips/Kconfig --- linux-2.6.16.11/arch/mips/Kconfig 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/Kconfig 2006-05-05 10:53:40.000000000 +0800 @@ -326,6 +326,27 @@ config MIPS_SEAD This enables support for the MIPS Technologies SEAD evaluation board. +config WR_PPMC + bool "Support for Wind River PPMC board" + select IRQ_CPU + select BOOT_ELF32 + select DMA_NONCOHERENT + select HW_HAS_PCI + select MIPS_GT64120 + select SWAP_IO_SPACE + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_HAS_CPU_MIPS64_R1 + select SYS_HAS_CPU_NEVADA + select SYS_HAS_CPU_RM7000 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_LITTLE_ENDIAN + help + This enables support for the Wind River MIPS32 4KC PPMC evaluation + board, which is based on GT64120 bridge chip. + config MIPS_SIM bool 'Support for MIPS simulator (MIPSsim)' select DMA_NONCOHERENT diff -uprN linux-2.6.16.11/arch/mips/Makefile linux-2.6.16.11-ppmc/arch/mips/Makefile --- linux-2.6.16.11/arch/mips/Makefile 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/Makefile 2006-05-05 12:42:16.000000000 +0800 @@ -419,6 +419,13 @@ cflags-$(CONFIG_MIPS_EV96100) += -Iinclu load-$(CONFIG_MIPS_EV96100) += 0xffffffff80100000 # +# Wind River PPMC Board (4KC + GT64120) +# +core-$(CONFIG_WR_PPMC) += arch/mips/gt64120/wrppmc/ +cflags-$(CONFIG_WR_PPMC) += -Iinclude/asm-mips/mach-wrppmc +load-$(CONFIG_WR_PPMC) += 0xffffffff80100000 + +# # Globespan IVR eval board with QED 5231 CPU # core-$(CONFIG_ITE_BOARD_GEN) += arch/mips/ite-boards/generic/ diff -uprN linux-2.6.16.11/arch/mips/pci/fixup-wrppmc.c linux-2.6.16.11-ppmc/arch/mips/pci/fixup-wrppmc.c --- linux-2.6.16.11/arch/mips/pci/fixup-wrppmc.c 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/pci/fixup-wrppmc.c 2006-05-06 15:24:57.000000000 +0800 @@ -0,0 +1,37 @@ +/* + * fixup-wrppmc.c: PPMC board specific PCI fixup + * + * 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 + * for more details. + * + * Copyright (C) 2006, Wind River Inc. Rongkai.zhan (rongkai.zhan@windriver.com) + */ +#include +#include +#include + +/* PCI interrupt pins */ +#define PCI_INTA 1 +#define PCI_INTB 2 +#define PCI_INTC 3 +#define PCI_INTD 4 + +#define PCI_SLOT_MAXNR 32 /* Each PCI bus has 32 physical slots */ + +static char pci_irq_tab[PCI_SLOT_MAXNR][5] __initdata = { + /* 0 INTA INTB INTC INTD */ + [0] = {0, 0, 0, 0, 0}, /* Slot 0: GT64120 PCI bridge */ + [6] = {0, WRPPMC_PCI_INTA_IRQ, 0, 0, 0}, +}; + +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) +{ + return pci_irq_tab[slot][pin]; +} + +/* Do platform specific device initialization at pci_enable_device() time */ +int pcibios_plat_dev_init(struct pci_dev *dev) +{ + return 0; +} diff -uprN linux-2.6.16.11/arch/mips/pci/Makefile linux-2.6.16.11-ppmc/arch/mips/pci/Makefile --- linux-2.6.16.11/arch/mips/pci/Makefile 2006-04-25 04:20:24.000000000 +0800 +++ linux-2.6.16.11-ppmc/arch/mips/pci/Makefile 2006-05-05 11:30:44.000000000 +0800 @@ -57,3 +57,4 @@ obj-$(CONFIG_TOSHIBA_RBTX4927) += fixup- obj-$(CONFIG_TOSHIBA_RBTX4938) += fixup-tx4938.o ops-tx4938.o obj-$(CONFIG_VICTOR_MPC30X) += fixup-mpc30x.o obj-$(CONFIG_ZAO_CAPCELLA) += fixup-capcella.o +obj-$(CONFIG_WR_PPMC) += fixup-wrppmc.o diff -uprN linux-2.6.16.11/include/asm-mips/mach-wrppmc/mach-gt64120.h linux-2.6.16.11-ppmc/include/asm-mips/mach-wrppmc/mach-gt64120.h --- linux-2.6.16.11/include/asm-mips/mach-wrppmc/mach-gt64120.h 1970-01-01 08:00:00.000000000 +0800 +++ linux-2.6.16.11-ppmc/include/asm-mips/mach-wrppmc/mach-gt64120.h 2006-05-06 15:31:51.000000000 +0800 @@ -0,0 +1,84 @@ +/* + * This is a direct copy of the ev96100.h file, with a global + * search and replace. The numbers are the same. + * + * The reason I'm duplicating this is so that the 64120/96100 + * defines won't be confusing in the source code. + */ +#ifndef __ASM_MIPS_GT64120_H +#define __ASM_MIPS_GT64120_H + +/* + * This is the CPU physical memory map of PPMC Board: + * + * 0x00000000-0x03FFFFFF - 64MB SDRAM (SCS[0]#) + * 0x1C000000-0x1C000000 - LED (CS0) + * 0x1C800000-0x1C800007 - UART 16550 port (CS1) + * 0x1F000000-0x1F000000 - MailBox (CS3) + * 0x1FC00000-0x20000000 - 4MB Flash (BOOT CS) + */ + +#define WRPPMC_SDRAM_SCS0_BASE 0x00000000 +#define WRPPMC_SDRAM_SCS0_SIZE 0x04000000 + +#define WRPPMC_UART16550_BASE 0x1C800000 +#define WRPPMC_UART16550_CLOCK 3686400 /* 3.68MHZ */ + +#define WRPPMC_LED_BASE 0x1C000000 +#define WRPPMC_MBOX_BASE 0x1F000000 + +#define WRPPMC_BOOTROM_BASE 0x1FC00000 +#define WRPPMC_BOOTROM_SIZE 0x00400000 /* 4M Flash */ + +#define WRPPMC_MIPS_TIMER_IRQ 7 /* MIPS compare/count timer interrupt */ +#define WRPPMC_UART16550_IRQ 6 +#define WRPPMC_PCI_INTA_IRQ 3 + +/* + * PCI Bus I/O and Memory resources allocation + * + * NOTE: We only have PCI_0 hose interface + */ +#define GT_PCI_MEM_BASE 0x13000000UL +#define GT_PCI_MEM_SIZE 0x02000000UL +#define GT_PCI_IO_BASE 0x11000000UL +#define GT_PCI_IO_SIZE 0x02000000UL +#define GT_ISA_IO_BASE PCI_IO_BASE + +/* + * PCI interrupts will come in on either the INTA or INTD interrups lines, + * which are mapped to the #2 and #5 interrupt pins of the MIPS. On our + * boards, they all either come in on IntD or they all come in on IntA, they + * aren't mixed. There can be numerous PCI interrupts, so we keep a list of the + * "requested" interrupt numbers and go through the list whenever we get an + * IntA/D. + * + * Interrupts < 8 are directly wired to the processor; PCI INTA is 8 and + * INTD is 11. + */ +#define GT_TIMER 4 +#define GT_INTA 2 +#define GT_INTD 5 + +#ifndef __ASSEMBLY__ + +/* + * GT64120 internal register space base address + */ +extern unsigned long gt64120_base; + +#define GT64120_BASE (gt64120_base) + +/* define WRPPMC_EARLY_DEBUG to enable early output something to UART */ +#undef WRPPMC_EARLY_DEBUG + +#ifdef WRPPMC_EARLY_DEBUG +extern void wrppmc_led_on(int mask); +extern void wrppmc_led_off(int mask); +extern void wrppmc_early_printk(const char *fmt, ...); +#else +#define wrppmc_early_printk(fmt, ...) do {} while (0) +#endif /* WRPPMC_EARLY_DEBUG */ + +#endif /* __ASSEMBLY__ */ +#endif /* __ASM_MIPS_GT64120_H */ From ralf@linux-mips.org Sat May 6 10:05:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 10:07:07 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:12770 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133488AbWEFJFH (ORCPT ); Sat, 6 May 2006 10:05:07 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k45LmW76004777 for ; Fri, 5 May 2006 22:48:32 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k45LlWHN004724; Fri, 5 May 2006 22:47:32 +0100 Date: Fri, 5 May 2006 22:47:32 +0100 From: Ralf Baechle To: Shane McDonald Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] improve readability of arch/mips/Kconfig Message-ID: <20060505214732.GA4528@linux-mips.org> References: <200605051817.k45IHpkC031672@duval.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605051817.k45IHpkC031672@duval.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 193 Lines: 7 On Fri, May 05, 2006 at 12:17:51PM -0600, Shane McDonald wrote: > I'll try this again ... I think I've got the corrupt patch issue resolved. Nope, still all tabs converted to spaces. Ralf From mcdonald@pmc-sierra.com Sat May 6 22:48:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 May 2006 22:48:21 +0100 (BST) Received: from mother.pmc-sierra.com ([216.241.224.12]:59096 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S8133531AbWEFVsL (ORCPT ); Sat, 6 May 2006 22:48:11 +0100 Received: (qmail 1593 invoked by uid 101); 6 May 2006 21:48:00 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 6 May 2006 21:48:00 -0000 Received: from duval.pmc-sierra.bc.ca (duval.pmc-sierra.bc.ca [134.87.183.32]) by ogmios.pmc-sierra.bc.ca (8.13.3/8.12.7) with ESMTP id k46Llsi8027763 for ; Sat, 6 May 2006 14:47:59 -0700 From: Shane McDonald Received: (from mcdonald@localhost) by duval.pmc-sierra.bc.ca (8.12.11/8.12.11) id k46Llrfb024188 for linux-mips@linux-mips.org; Sat, 6 May 2006 15:47:53 -0600 Date: Sat, 6 May 2006 15:47:53 -0600 Message-Id: <200605062147.k46Llrfb024188@duval.pmc-sierra.bc.ca> To: linux-mips@linux-mips.org Subject: Re: [PATCH] improve readability of arch/mips/Kconfig Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mcdonald@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 3557 Lines: 74 > > I'll try this again ... I think I've got the corrupt patch > issue resolved. > > Nope, still all tabs converted to spaces. > > Ralf Oops, heh heh. One last time before I crawl back under my rock... From: Shane McDonald The wording of the help entries for CPU_MIPS32_R1, CPU_MIPS32_R2, CPU_MIPS64_R1, and CPU_MIPS64_R2 was confusing. The entries have been slightly reworded to improve the readability. Signed-off-by: Shane McDonald --- diff -uprN a/arch/mips/Kconfig b/arch/mips/Kconfig --- a/arch/mips/Kconfig 2006-05-04 16:25:32.000000000 -0600 +++ b/arch/mips/Kconfig 2006-05-04 16:50:08.000000000 -0600 @@ -1075,10 +1075,10 @@ config CPU_MIPS32_R1 Choose this option to build a kernel for release 1 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. - Release 2 of the MIPS32 architecture is available since several - years so chances are you even have a MIPS32 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + Release 2 of the MIPS32 architecture has been available for + several years so chances are you have a MIPS32 Release 2 processor in which case you should choose CPU_MIPS32_R2 instead for better performance. @@ -1093,8 +1093,8 @@ config CPU_MIPS32_R2 Choose this option to build a kernel for release 2 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS32_R1 is a safe bet for any MIPS32 system. config CPU_MIPS64_R1 bool "MIPS64 Release 1" @@ -1108,10 +1108,10 @@ config CPU_MIPS64_R1 Choose this option to build a kernel for release 1 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. - Release 2 of the MIPS64 architecture is available since several - years so chances are you even have a MIPS64 Release 2 processor + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + Release 2 of the MIPS64 architecture has been available for + several years so chances are you have a MIPS64 Release 2 processor in which case you should choose CPU_MIPS64_R2 instead for better performance. @@ -1127,8 +1127,8 @@ config CPU_MIPS64_R2 Choose this option to build a kernel for release 2 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the - specific type of processor in your system, choose those that one - otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. + specific type of processor in your system, choose that one; + otherwise, CPU_MIPS64_R1 is a safe bet for any MIPS64 system. config CPU_R3000 bool "R3000" From hvr@gnu.org Sun May 7 14:52:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 May 2006 14:52:36 +0100 (BST) Received: from fencepost.gnu.org ([199.232.76.164]:13032 "EHLO fencepost.gnu.org") by ftp.linux-mips.org with ESMTP id S8133425AbWEGNwY (ORCPT ); Sun, 7 May 2006 14:52:24 +0100 Received: from hvr by fencepost.gnu.org with local (Exim 4.34) id 1FcjgI-0007TD-8R; Sun, 07 May 2006 09:52:18 -0400 From: Herbert Valerio Riedel Date: Sun May 7 15:48:25 2006 +0200 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] [MIPS] au1xxx: board specific irq code cleanup Message-Id: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips Content-Length: 8414 Lines: 224 convert sizeof/sizeof use to use of ARRAY_SIZE macro, and annotate irqmap structures as __initdata Signed-off-by: Herbert Valerio Riedel --- arch/mips/au1000/common/au1xxx_irqmap.c | 4 ++-- arch/mips/au1000/csb250/irqmap.c | 4 ++-- arch/mips/au1000/db1x00/irqmap.c | 4 ++-- arch/mips/au1000/hydrogen3/irqmap.c | 4 ++-- arch/mips/au1000/mtx-1/irqmap.c | 4 ++-- arch/mips/au1000/pb1000/irqmap.c | 4 ++-- arch/mips/au1000/pb1100/irqmap.c | 4 ++-- arch/mips/au1000/pb1200/irqmap.c | 4 ++-- arch/mips/au1000/pb1500/irqmap.c | 4 ++-- arch/mips/au1000/pb1550/irqmap.c | 4 ++-- arch/mips/au1000/xxs1500/irqmap.c | 4 ++-- 11 files changed, 22 insertions(+), 22 deletions(-) b09723a2dc77200c4bd76835663016ca60b5a0ec diff --git a/arch/mips/au1000/common/au1xxx_irqmap.c b/arch/mips/au1000/common/au1xxx_irqmap.c index 0b2c03c..5a1e368 100644 --- a/arch/mips/au1000/common/au1xxx_irqmap.c +++ b/arch/mips/au1000/common/au1xxx_irqmap.c @@ -55,7 +55,7 @@ * Careful if you change match 2 request! * The interrupt handler is called directly from the low level dispatch code. */ -au1xxx_irq_map_t au1xxx_ic0_map[] = { +au1xxx_irq_map_t __initdata au1xxx_ic0_map[] = { #if defined(CONFIG_SOC_AU1000) { AU1000_UART0_INT, INTC_INT_HIGH_LEVEL, 0}, @@ -220,5 +220,5 @@ au1xxx_irq_map_t au1xxx_ic0_map[] = { }; -int au1xxx_ic0_nr_irqs = sizeof(au1xxx_ic0_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_ic0_nr_irqs = ARRAY_SIZE(au1xxx_ic0_map); diff --git a/arch/mips/au1000/csb250/irqmap.c b/arch/mips/au1000/csb250/irqmap.c index 5cb1166..57d6040 100644 --- a/arch/mips/au1000/csb250/irqmap.c +++ b/arch/mips/au1000/csb250/irqmap.c @@ -47,7 +47,7 @@ #include #include -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1500_GPIO_204, INTC_INT_HIGH_LEVEL, 0}, { AU1500_GPIO_201, INTC_INT_LOW_LEVEL, 0 }, @@ -57,4 +57,4 @@ au1xxx_irq_map_t au1xxx_irq_map[] = { { AU1500_GPIO_207, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/db1x00/irqmap.c b/arch/mips/au1000/db1x00/irqmap.c index f63024a..0138c5b 100644 --- a/arch/mips/au1000/db1x00/irqmap.c +++ b/arch/mips/au1000/db1x00/irqmap.c @@ -80,7 +80,7 @@ char irq_tab_alchemy[][5] __initdata = { #endif -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { #ifndef CONFIG_MIPS_MIRAGE #ifdef CONFIG_MIPS_DB1550 @@ -101,4 +101,4 @@ au1xxx_irq_map_t au1xxx_irq_map[] = { }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/hydrogen3/irqmap.c b/arch/mips/au1000/hydrogen3/irqmap.c index 6eacaa0..14e1ed3 100644 --- a/arch/mips/au1000/hydrogen3/irqmap.c +++ b/arch/mips/au1000/hydrogen3/irqmap.c @@ -47,10 +47,10 @@ #include #include -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { /* { AU1500_GPIO_205, INTC_INT_LOW_LEVEL, 0 }, */ { AU1000_GPIO_21, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/mtx-1/irqmap.c b/arch/mips/au1000/mtx-1/irqmap.c index f9a0a8b..4693a4e 100644 --- a/arch/mips/au1000/mtx-1/irqmap.c +++ b/arch/mips/au1000/mtx-1/irqmap.c @@ -58,7 +58,7 @@ char irq_tab_alchemy[][5] __initdata = { [7] = { -1, INTD, INTC, INTX, INTX}, /* IDSEL 07 - AdapterD-Slot1 (bottom) */ }; -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1500_GPIO_204, INTC_INT_HIGH_LEVEL, 0}, { AU1500_GPIO_201, INTC_INT_LOW_LEVEL, 0 }, { AU1500_GPIO_202, INTC_INT_LOW_LEVEL, 0 }, @@ -66,4 +66,4 @@ au1xxx_irq_map_t au1xxx_irq_map[] = { { AU1500_GPIO_205, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/pb1000/irqmap.c b/arch/mips/au1000/pb1000/irqmap.c index a3c460e..156500b 100644 --- a/arch/mips/au1000/pb1000/irqmap.c +++ b/arch/mips/au1000/pb1000/irqmap.c @@ -47,8 +47,8 @@ #include #include -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1000_GPIO_15, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/pb1100/irqmap.c b/arch/mips/au1000/pb1100/irqmap.c index 43be715..d986916 100644 --- a/arch/mips/au1000/pb1100/irqmap.c +++ b/arch/mips/au1000/pb1100/irqmap.c @@ -47,11 +47,11 @@ #include #include -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1000_GPIO_9, INTC_INT_LOW_LEVEL, 0 }, // PCMCIA Card Fully_Interted# { AU1000_GPIO_10, INTC_INT_LOW_LEVEL, 0 }, // PCMCIA Card STSCHG# { AU1000_GPIO_11, INTC_INT_LOW_LEVEL, 0 }, // PCMCIA Card IRQ# { AU1000_GPIO_13, INTC_INT_LOW_LEVEL, 0 }, // DC_IRQ# }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/pb1200/irqmap.c b/arch/mips/au1000/pb1200/irqmap.c index 59e70e5..bacc0c6 100644 --- a/arch/mips/au1000/pb1200/irqmap.c +++ b/arch/mips/au1000/pb1200/irqmap.c @@ -55,11 +55,11 @@ #define PB1200_INT_END DB1200_INT_END #endif -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1000_GPIO_7, INTC_INT_LOW_LEVEL, 0 }, // This is exteranl interrupt cascade }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); /* * Support for External interrupts on the PbAu1200 Development platform. diff --git a/arch/mips/au1000/pb1500/irqmap.c b/arch/mips/au1000/pb1500/irqmap.c index 8cb76c2..409d161 100644 --- a/arch/mips/au1000/pb1500/irqmap.c +++ b/arch/mips/au1000/pb1500/irqmap.c @@ -52,7 +52,7 @@ char irq_tab_alchemy[][5] __initdata = { [13] = { -1, INTA, INTB, INTC, INTD}, /* IDSEL 13 - PCI slot */ }; -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1500_GPIO_204, INTC_INT_HIGH_LEVEL, 0}, { AU1500_GPIO_201, INTC_INT_LOW_LEVEL, 0 }, { AU1500_GPIO_202, INTC_INT_LOW_LEVEL, 0 }, @@ -60,4 +60,4 @@ au1xxx_irq_map_t au1xxx_irq_map[] = { { AU1500_GPIO_205, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/pb1550/irqmap.c b/arch/mips/au1000/pb1550/irqmap.c index 47c7a1c..24a9d18 100644 --- a/arch/mips/au1000/pb1550/irqmap.c +++ b/arch/mips/au1000/pb1550/irqmap.c @@ -52,9 +52,9 @@ char irq_tab_alchemy[][5] __initdata = { [13] = { -1, INTA, INTB, INTC, INTD}, /* IDSEL 13 - PCI slot 1 (right) */ }; -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1000_GPIO_0, INTC_INT_LOW_LEVEL, 0 }, { AU1000_GPIO_1, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); diff --git a/arch/mips/au1000/xxs1500/irqmap.c b/arch/mips/au1000/xxs1500/irqmap.c index 52f2f7d..3844c64 100644 --- a/arch/mips/au1000/xxs1500/irqmap.c +++ b/arch/mips/au1000/xxs1500/irqmap.c @@ -47,7 +47,7 @@ #include #include -au1xxx_irq_map_t au1xxx_irq_map[] = { +au1xxx_irq_map_t __initdata au1xxx_irq_map[] = { { AU1500_GPIO_204, INTC_INT_HIGH_LEVEL, 0}, { AU1500_GPIO_201, INTC_INT_LOW_LEVEL, 0 }, { AU1500_GPIO_202, INTC_INT_LOW_LEVEL, 0 }, @@ -63,4 +63,4 @@ au1xxx_irq_map_t au1xxx_irq_map[] = { { AU1000_GPIO_5, INTC_INT_LOW_LEVEL, 0 }, }; -int au1xxx_nr_irqs = sizeof(au1xxx_irq_map)/sizeof(au1xxx_irq_map_t); +int __initdata au1xxx_nr_irqs = ARRAY_SIZE(au1xxx_irq_map); -- 1.2.6 From sshtylyov@ru.mvista.com Mon May 8 19:20:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 19:20:54 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:6095 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133477AbWEHSUd (ORCPT ); Mon, 8 May 2006 19:20:33 +0100 Received: (qmail 23961 invoked from network); 8 May 2006 22:25:56 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 8 May 2006 22:25:56 -0000 Message-ID: <445F8BA8.8050006@ru.mvista.com> Date: Mon, 08 May 2006 22:19:20 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux-MIPS CC: Manish Lachwani Subject: [PATCH] RBTX4938: make RTL8019AS work when CONFIG_PCI=n Content-Type: multipart/mixed; boundary="------------070805090307060006080304" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1133 Lines: 36 This is a multi-part message in MIME format. --------------070805090307060006080304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch should make the on-board Ethernet chip (Realtek RTL8019AS) work when CONFIG_PCI is disabled... Signed-off-by: Yuri Shpilevsky Signed-off-by: Sergei Shtylyov --------------070805090307060006080304 Content-Type: text/plain; name="RBTX4938-fix-IO-port-base.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RBTX4938-fix-IO-port-base.patch" diff --git a/arch/mips/tx4938/toshiba_rbtx4938/setup.c b/arch/mips/tx4938/toshiba_rbtx4938/setup.c index 5c7ace9..a96d442 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/setup.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/setup.c @@ -918,7 +918,7 @@ void __init toshiba_rbtx4938_setup(void) TX4938_WR(0xff1ff414, 0x00000000); /* h/w flow control off */ #ifndef CONFIG_PCI - set_io_port_base(RBTX4938_ETHER_BASE); + set_io_port_base(KSEG1); #endif #ifdef CONFIG_SERIAL_TXX9 --------------070805090307060006080304-- From tim.bird@am.sony.com Mon May 8 19:23:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 19:23:21 +0100 (BST) Received: from mail8.fw-sd.sony.com ([160.33.66.75]:30419 "EHLO mail8.fw-sd.sony.com") by ftp.linux-mips.org with ESMTP id S8133504AbWEHSXF (ORCPT ); Mon, 8 May 2006 19:23:05 +0100 Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id k48IMvTU025933; Mon, 8 May 2006 18:22:57 GMT Received: from [43.134.85.135] ([43.134.85.135]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id k48IMvJj002065; Mon, 8 May 2006 18:22:57 GMT Message-ID: <445F8C81.4070406@am.sony.com> Date: Mon, 08 May 2006 11:22:57 -0700 From: Tim Bird User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Thiemo Seufer CC: linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from environment var References: <445A577D.7090507@am.sony.com> <20060504205517.GF18218@networkno.de> <445A6F51.90308@am.sony.com> <20060504223539.GG18218@networkno.de> In-Reply-To: <20060504223539.GG18218@networkno.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tim.bird@am.sony.com Precedence: bulk X-list: linux-mips Content-Length: 1384 Lines: 35 Thiemo Seufer wrote: > Update to a newer version: Of what? I'm using a 2.6.16 kernel here. > config CROSSCOMPILE > bool "Are you using a crosscompiler" > help > Say Y here if you are compiling the kernel on a different > architecture than the one it is intended to run on. This is just a > convenience option which will select the appropriate value for > the CROSS_COMPILE make variable which otherwise has to be passed on > the command line from mips-linux-, mipsel-linux-, mips64-linux- and > mips64el-linux- as appropriate for a particular kernel configuration. > You will have to pass the value for CROSS_COMPILE manually if the > name prefix for your tools is different. Hmmm. Well, I would say that this should be pushed to mainline, but I still think it could be improved a bit. IMHO, the config question should be something like: "Use cross-compiler defined by Makefile", instead of "Are you using a crosscompiler". My recommendation would be to apply my patch and drop the last sentence. Then you get the best of all worlds: - support for command line specification, if you use it - support for env. var specification, if you use it. - automatic prefix selection if you use this option ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Electronics ============================= From tim.bird@am.sony.com Mon May 8 19:35:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 19:35:50 +0100 (BST) Received: from mail8.fw-sd.sony.com ([160.33.66.75]:57048 "EHLO mail8.fw-sd.sony.com") by ftp.linux-mips.org with ESMTP id S8133499AbWEHSfk (ORCPT ); Mon, 8 May 2006 19:35:40 +0100 Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id k48IZWc2028327; Mon, 8 May 2006 18:35:32 GMT Received: from [43.134.85.135] ([43.134.85.135]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id k48IZWsh005225; Mon, 8 May 2006 18:35:32 GMT Message-ID: <445F8F73.6030808@am.sony.com> Date: Mon, 08 May 2006 11:35:31 -0700 From: Tim Bird User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Ralf Baechle CC: Tom Rini , Thiemo Seufer , "Bird, Tim" , linux-mips@linux-mips.org Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from envir onment var References: <20060504230647.GA3465@linux-mips.org> In-Reply-To: <20060504230647.GA3465@linux-mips.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tim.bird@am.sony.com Precedence: bulk X-list: linux-mips Content-Length: 1884 Lines: 45 Ralf Baechle wrote: > On Thu, May 04, 2006 at 02:04:49PM -0700, Tom Rini wrote: > >> Let me ask a stupid question. With all of the ways to otherwise do a >> cross compile, why a config option on MIPS? ARM*/SH*, which are at >> least as likely to not be native-compiled, don't do that. Just >> something I've always wondered, really. > > Having such information in an environment variable is imho terribly > inelegant, having to pass it on the command line for each make > invocation > is terrible abuse for the fingertips so I went for this option which > makes > the makefile pick the right prefix. And a great solution it would be, if it actually picked the right prefix. :-) I understand that having the cross-compiler prefix specified outside the build system has drawbacks. When I first got into embedded Linux (many years ago), I was struck by the inelegance of this also. However, hardcoding the prefixes in the Makefile is, IMHO, not such a great idea either. It really doesn't bother me if the "standard" prefixes are encoded in a Makefile, but it would be nice to be able to select a non-standard prefix the same way as for other Linux architectures. I understand I can do that by turning off the "I'm cross-compiling" option, but that seems counterintuitive given the current wording of that option (not-withstanding the not-yet-mainlined help text). My patch allows to keep the current behaviour, but also supports use of the environment variable. I don't see any downside to it, unless you are actively trying to discourage the use of the environment variable. In my own experience, use of the environment variable, while inelegant for manual use, has certain benefits for automated use. Regards, -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Electronics ============================= From dan@embeddedalley.com Mon May 8 19:57:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 19:57:56 +0100 (BST) Received: from smtp104.biz.mail.re2.yahoo.com ([206.190.52.173]:6275 "HELO smtp104.biz.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S8133499AbWEHS5q (ORCPT ); Mon, 8 May 2006 19:57:46 +0100 Received: (qmail 26676 invoked from network); 8 May 2006 18:57:39 -0000 Received: from unknown (HELO ?172.16.0.134?) (dan@embeddedalley.com@12.6.244.2 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 8 May 2006 18:57:39 -0000 In-Reply-To: <445F8F73.6030808@am.sony.com> References: <20060504230647.GA3465@linux-mips.org> <445F8F73.6030808@am.sony.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <628C0B36-1275-4BCC-AB4D-99D5EBBF6778@embeddedalley.com> Cc: Ralf Baechle , Tom Rini , Thiemo Seufer , linux-mips@linux-mips.org Content-Transfer-Encoding: 7bit From: Dan Malek Subject: Re: [PATCH] fix mips/Makefile to support CROSS_COMPILE from envir onment var Date: Mon, 8 May 2006 14:56:56 -0400 To: Tim Bird X-Mailer: Apple Mail (2.749.3) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 927 Lines: 27 On May 8, 2006, at 2:35 PM, Tim Bird wrote: > ..... I understand that having the cross-compiler prefix > specified outside the build system has drawbacks. When I first got > into embedded Linux (many years ago), I was struck by the inelegance > of this also. The only drawback is you have to type it in correctly :-) This "inelegance" of having to set an environment variable has proven extremely useful in many of my experiences with clients building real products. They have installed many different cross compilers, and often use build procedures to meet various configuration management requirements. The need to explicitly select a complier is absolutely necessary, you can't have a Makefile guessing. I personally like setting the environment option, and wish MIPS would just drop this whole cross compile selection from the configuration process and work like all of the other architectures. Thanks. -- Dan From drow@nevyn.them.org Mon May 8 20:28:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 20:28:35 +0100 (BST) Received: from nevyn.them.org ([66.93.172.17]:22719 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133519AbWEHT2Z (ORCPT ); Mon, 8 May 2006 20:28:25 +0100 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FdBP4-0003fP-Lu; Mon, 08 May 2006 15:28:22 -0400 Date: Mon, 8 May 2006 15:28:22 -0400 From: Daniel Jacobowitz To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Update struct sigcontext member names Message-ID: <20060508192822.GA14037@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 4013 Lines: 112 Rename the MIPS64 sc_hi and sc_lo arrays to use the same names as the MIPS32 struct sigcontext (sc_mdhi, sc_hi1, et cetera). Signed-off-by: Daniel Jacobowitz --- As we discussed earlier - this lets glibc use the same definitions, without breaking source compatibility for the 64-bit sigcontext. diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c index 92b28b6..0facfaf 100644 --- a/arch/mips/kernel/asm-offsets.c +++ b/arch/mips/kernel/asm-offsets.c @@ -272,8 +272,8 @@ void output_sc_defines(void) text("/* Linux sigcontext offsets. */"); offset("#define SC_REGS ", struct sigcontext, sc_regs); offset("#define SC_FPREGS ", struct sigcontext, sc_fpregs); - offset("#define SC_MDHI ", struct sigcontext, sc_hi); - offset("#define SC_MDLO ", struct sigcontext, sc_lo); + offset("#define SC_MDHI ", struct sigcontext, sc_mdhi); + offset("#define SC_MDLO ", struct sigcontext, sc_mdlo); offset("#define SC_PC ", struct sigcontext, sc_pc); offset("#define SC_FPC_CSR ", struct sigcontext, sc_fpc_csr); linefeed; diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 3ca7862..ce6cb91 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -31,7 +31,6 @@ #define save_gp_reg(i) do { \ save_gp_reg(31); #undef save_gp_reg -#ifdef CONFIG_32BIT err |= __put_user(regs->hi, &sc->sc_mdhi); err |= __put_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { @@ -43,20 +42,6 @@ #ifdef CONFIG_32BIT err |= __put_user(mflo3(), &sc->sc_lo3); err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); } -#endif -#ifdef CONFIG_64BIT - err |= __put_user(regs->hi, &sc->sc_hi[0]); - err |= __put_user(regs->lo, &sc->sc_lo[0]); - if (cpu_has_dsp) { - err |= __put_user(mfhi1(), &sc->sc_hi[1]); - err |= __put_user(mflo1(), &sc->sc_lo[1]); - err |= __put_user(mfhi2(), &sc->sc_hi[2]); - err |= __put_user(mflo2(), &sc->sc_lo[2]); - err |= __put_user(mfhi3(), &sc->sc_hi[3]); - err |= __put_user(mflo3(), &sc->sc_lo[3]); - err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); - } -#endif err |= __put_user(!!used_math(), &sc->sc_used_math); @@ -92,7 +77,6 @@ restore_sigcontext(struct pt_regs *regs, current_thread_info()->restart_block.fn = do_no_restart_syscall; err |= __get_user(regs->cp0_epc, &sc->sc_pc); -#ifdef CONFIG_32BIT err |= __get_user(regs->hi, &sc->sc_mdhi); err |= __get_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { @@ -104,20 +88,6 @@ #ifdef CONFIG_32BIT err |= __get_user(treg, &sc->sc_lo3); mtlo3(treg); err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); } -#endif -#ifdef CONFIG_64BIT - err |= __get_user(regs->hi, &sc->sc_hi[0]); - err |= __get_user(regs->lo, &sc->sc_lo[0]); - if (cpu_has_dsp) { - err |= __get_user(treg, &sc->sc_hi[1]); mthi1(treg); - err |= __get_user(treg, &sc->sc_lo[1]); mthi1(treg); - err |= __get_user(treg, &sc->sc_hi[2]); mthi2(treg); - err |= __get_user(treg, &sc->sc_lo[2]); mthi2(treg); - err |= __get_user(treg, &sc->sc_hi[3]); mthi3(treg); - err |= __get_user(treg, &sc->sc_lo[3]); mthi3(treg); - err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); - } -#endif #define restore_gp_reg(i) do { \ err |= __get_user(regs->regs[i], &sc->sc_regs[i]); \ diff --git a/include/asm-mips/sigcontext.h b/include/asm-mips/sigcontext.h index 8edabb0..cefa657 100644 --- a/include/asm-mips/sigcontext.h +++ b/include/asm-mips/sigcontext.h @@ -55,8 +55,14 @@ #if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIP struct sigcontext { unsigned long sc_regs[32]; unsigned long sc_fpregs[32]; - unsigned long sc_hi[4]; - unsigned long sc_lo[4]; + unsigned long sc_mdhi; + unsigned long sc_hi1; + unsigned long sc_hi2; + unsigned long sc_hi3; + unsigned long sc_mdlo; + unsigned long sc_lo1; + unsigned long sc_lo2; + unsigned long sc_lo3; unsigned long sc_pc; unsigned int sc_fpc_csr; unsigned int sc_used_math; -- Daniel Jacobowitz CodeSourcery From sshtylyov@ru.mvista.com Mon May 8 21:01:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 21:02:08 +0100 (BST) Received: from rtsoft2.corbina.net ([85.21.88.2]:8147 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133517AbWEHUB4 (ORCPT ); Mon, 8 May 2006 21:01:56 +0100 Received: (qmail 25379 invoked from network); 9 May 2006 00:07:29 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 9 May 2006 00:07:29 -0000 Message-ID: <445FA36E.3080500@ru.mvista.com> Date: Tue, 09 May 2006 00:00:46 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Jeff Garzik CC: linux-mips@linux-mips.org, linux-net@vger.kernel.org Subject: [PATCH] Fix RTL8019AS init for Toshiba RBTX49xx boards References: <444291E9.2070407@ru.mvista.com> <20060417.110945.59031594.nemoto@toshiba-tops.co.jp> <444392CF.7070808@ru.mvista.com> <20060418.000918.95064811.anemo@mba.ocn.ne.jp> <4443BD39.4030200@ru.mvista.com> <4443BE71.6090908@ru.mvista.com> In-Reply-To: <4443BE71.6090908@ru.mvista.com> Content-Type: multipart/mixed; boundary="------------040703070604020900060909" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 2696 Lines: 84 This is a multi-part message in MIME format. --------------040703070604020900060909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ensure that 8-bit mode is selected for the on-board Realtek RTL8019AS chip on Toshiba RBHMA4x00, get rid of the duplicate #ifdef's when setting ei_status.word16. The chip's datasheet says that the PSTOP register shouldn't exceed 0x60 in 8-bit mode -- ensure this too. Signed-off-by: Sergei Shtylyov --------------040703070604020900060909 Content-Type: text/plain; name="RBTX49xx-RTL8019AS-init-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RBTX49xx-RTL8019AS-init-fix.patch" Index: linus/drivers/net/ne.c =================================================================== --- linus.orig/drivers/net/ne.c +++ linus/drivers/net/ne.c @@ -139,8 +139,9 @@ bad_clone_list[] __initdata = { #if defined(CONFIG_PLAT_MAPPI) # define DCR_VAL 0x4b -#elif defined(CONFIG_PLAT_OAKS32R) -# define DCR_VAL 0x48 +#elif defined(CONFIG_PLAT_OAKS32R) || \ + defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938) +# define DCR_VAL 0x48 /* 8-bit mode */ #else # define DCR_VAL 0x49 #endif @@ -396,10 +397,22 @@ static int __init ne_probe1(struct net_d /* We must set the 8390 for word mode. */ outb_p(DCR_VAL, ioaddr + EN0_DCFG); start_page = NESM_START_PG; - stop_page = NESM_STOP_PG; + + /* + * Realtek RTL8019AS datasheet says that the PSTOP register + * shouldn't exceed 0x60 in 8-bit mode. + * This chip can be identified by reading the signature from + * the remote byte count registers (otherwise write-only)... + */ + if ((DCR_VAL & 0x01) == 0 && /* 8-bit mode */ + inb(ioaddr + EN0_RCNTLO) == 0x50 && + inb(ioaddr + EN0_RCNTHI) == 0x70) + stop_page = 0x60; + else + stop_page = NESM_STOP_PG; } else { start_page = NE1SM_START_PG; - stop_page = NE1SM_STOP_PG; + stop_page = NE1SM_STOP_PG; } #if defined(CONFIG_PLAT_MAPPI) || defined(CONFIG_PLAT_OAKS32R) @@ -509,15 +522,9 @@ static int __init ne_probe1(struct net_d ei_status.name = name; ei_status.tx_start_page = start_page; ei_status.stop_page = stop_page; -#if defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938) - wordlength = 1; -#endif -#ifdef CONFIG_PLAT_OAKS32R - ei_status.word16 = 0; -#else - ei_status.word16 = (wordlength == 2); -#endif + /* Use 16-bit mode only if this wasn't overridden by DCR_VAL */ + ei_status.word16 = (wordlength == 2 && (DCR_VAL & 0x01)); ei_status.rx_start_page = start_page + TX_PAGES; #ifdef PACKETBUF_MEMSIZE --------------040703070604020900060909-- From sam@ravnborg.org Mon May 8 21:02:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 21:02:49 +0100 (BST) Received: from pasmtp.tele.dk ([193.162.159.95]:32778 "HELO pasmtp.tele.dk") by ftp.linux-mips.org with SMTP id S8133519AbWEHUB7 (ORCPT ); Mon, 8 May 2006 21:01:59 +0100 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 064311EC334; Mon, 8 May 2006 22:01:47 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 606D443C069; Mon, 8 May 2006 22:01:53 +0200 (CEST) Date: Mon, 8 May 2006 22:01:53 +0200 From: Sam Ravnborg To: Linus Torvalds Cc: LKML , Atsushi Nemoto , Chris Wright , linux-mips@linux-mips.org, ralf@linux-mips.org, Stephen Hemminger Subject: Re: [git patches] kbuild fixes for -rc Message-ID: <20060508200153.GA3762@mars.ravnborg.org> References: <20060508050809.GA2247@mars.ravnborg.org> <20060508190312.GB2697@moss.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060508190312.GB2697@moss.sous-sol.org> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-mips Content-Length: 355 Lines: 13 Hi Linus. Please revert this bogus commit: > > commit c8d8b837ebe4b4f11e1b0c4a2bdc358c697692ed I was discussed on mips list but apparently the fix was bogus. I will not have time to look into it so mips can carry this local fix until we get a proper fix in mainline. [And I now have i386 toolchain in place so I can bo a better check next time]. Sam From auke-jan.h.kok@intel.com Mon May 8 21:55:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 21:55:29 +0100 (BST) Received: from fmr18.intel.com ([134.134.136.17]:41658 "EHLO orsfmr003.jf.intel.com") by ftp.linux-mips.org with ESMTP id S8133523AbWEHUzS (ORCPT ); Mon, 8 May 2006 21:55:18 +0100 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k48KtBQ0026153; Mon, 8 May 2006 20:55:11 GMT Received: from [134.134.3.210] (ahkok-mobl.jf.intel.com.jf.intel.com [134.134.3.210]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id k48KtAT1005279; Mon, 8 May 2006 20:55:10 GMT Message-ID: <445FB02D.3020905@intel.com> Date: Mon, 08 May 2006 13:55:09 -0700 From: Auke Kok User-Agent: Mail/News 1.5.0.2 (X11/20060424) MIME-Version: 1.0 To: Sergei Shtylyov CC: Jeff Garzik , linux-mips@linux-mips.org, linux-net@vger.kernel.org Subject: Re: [PATCH] Fix RTL8019AS init for Toshiba RBTX49xx boards References: <444291E9.2070407@ru.mvista.com> <20060417.110945.59031594.nemoto@toshiba-tops.co.jp> <444392CF.7070808@ru.mvista.com> <20060418.000918.95064811.anemo@mba.ocn.ne.jp> <4443BD39.4030200@ru.mvista.com> <4443BE71.6090908@ru.mvista.com> <445FA36E.3080500@ru.mvista.com> In-Reply-To: <445FA36E.3080500@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: auke-jan.h.kok@intel.com Precedence: bulk X-list: linux-mips Content-Length: 2719 Lines: 86 Hi, this won't work - first of all patches need to go to netdev and second jeff Garzik is offline for another week. Stephan Hemminger is covering for the net tree. Please repost and add these people. Auke Sergei Shtylyov wrote: > Ensure that 8-bit mode is selected for the on-board Realtek RTL8019AS > chip on Toshiba RBHMA4x00, get rid of the duplicate #ifdef's when setting > ei_status.word16. > The chip's datasheet says that the PSTOP register shouldn't exceed > 0x60 in > 8-bit mode -- ensure this too. > > Signed-off-by: Sergei Shtylyov > > > ------------------------------------------------------------------------ > > Index: linus/drivers/net/ne.c > =================================================================== > --- linus.orig/drivers/net/ne.c > +++ linus/drivers/net/ne.c > @@ -139,8 +139,9 @@ bad_clone_list[] __initdata = { > > #if defined(CONFIG_PLAT_MAPPI) > # define DCR_VAL 0x4b > -#elif defined(CONFIG_PLAT_OAKS32R) > -# define DCR_VAL 0x48 > +#elif defined(CONFIG_PLAT_OAKS32R) || \ > + defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938) > +# define DCR_VAL 0x48 /* 8-bit mode */ > #else > # define DCR_VAL 0x49 > #endif > @@ -396,10 +397,22 @@ static int __init ne_probe1(struct net_d > /* We must set the 8390 for word mode. */ > outb_p(DCR_VAL, ioaddr + EN0_DCFG); > start_page = NESM_START_PG; > - stop_page = NESM_STOP_PG; > + > + /* > + * Realtek RTL8019AS datasheet says that the PSTOP register > + * shouldn't exceed 0x60 in 8-bit mode. > + * This chip can be identified by reading the signature from > + * the remote byte count registers (otherwise write-only)... > + */ > + if ((DCR_VAL & 0x01) == 0 && /* 8-bit mode */ > + inb(ioaddr + EN0_RCNTLO) == 0x50 && > + inb(ioaddr + EN0_RCNTHI) == 0x70) > + stop_page = 0x60; > + else > + stop_page = NESM_STOP_PG; > } else { > start_page = NE1SM_START_PG; > - stop_page = NE1SM_STOP_PG; > + stop_page = NE1SM_STOP_PG; > } > > #if defined(CONFIG_PLAT_MAPPI) || defined(CONFIG_PLAT_OAKS32R) > @@ -509,15 +522,9 @@ static int __init ne_probe1(struct net_d > ei_status.name = name; > ei_status.tx_start_page = start_page; > ei_status.stop_page = stop_page; > -#if defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938) > - wordlength = 1; > -#endif > > -#ifdef CONFIG_PLAT_OAKS32R > - ei_status.word16 = 0; > -#else > - ei_status.word16 = (wordlength == 2); > -#endif > + /* Use 16-bit mode only if this wasn't overridden by DCR_VAL */ > + ei_status.word16 = (wordlength == 2 && (DCR_VAL & 0x01)); > > ei_status.rx_start_page = start_page + TX_PAGES; > #ifdef PACKETBUF_MEMSIZE > > From afleming@freescale.com Mon May 8 23:24:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 May 2006 23:24:39 +0100 (BST) Received: from az33egw02.freescale.net ([192.88.158.103]:19386 "EHLO az33egw02.freescale.net") by ftp.linux-mips.org with ESMTP id S8133498AbWEHWY2 (ORCPT ); Mon, 8 May 2006 23:24:28 +0100 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id k48Me2Ef002410; Mon, 8 May 2006 15:40:02 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id k48MZjao015113; Mon, 8 May 2006 17:35:45 -0500 (CDT) In-Reply-To: <1146734223.31241.44.camel@localhost.localdomain> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <1146674056.31241.18.camel@localhost.localdomain> <1146734223.31241.44.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BF86C09-0732-4322-A43E-29705849886D@freescale.com> Cc: Mark Schank , ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com, netdev@vger.kernel.org, Ralf Baechle , "Robin H. Johnson" Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: new WIP version of au1000_eth.c phylib conversion (was Re: RFC: au1000_etc.c phylib rewrite) Date: Mon, 8 May 2006 17:24:13 -0500 To: Herbert Valerio Riedel X-Mailer: Apple Mail (2.749.3) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: afleming@freescale.com Precedence: bulk X-list: linux-mips Content-Length: 3482 Lines: 127 On May 4, 2006, at 04:17, Herbert Valerio Riedel wrote: > Hello, > > I've tried to adapt the PHY detection code to allow for dynamic > runtime > configuration (with fallback to search for the 2nd MAC PHY on the 1st > MAC's MII bus), as well as selectable static PHY configuration through > Kconfig (e.g. for supporting PHYs w/o MII connection) Comments inline, below: > diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c > index 0823cb8..8c0b26f 100644 > --- a/drivers/net/au1000_eth.c > +++ b/drivers/net/au1000_eth.c > @@ -9,6 +9,9 @@ [snip] > -/* FIXME > - * All of the PHY code really should be detached from the MAC > - * code. > - */ > - [snip] Nothing to say so far, except seeing all those "-" signs was quite the thrill, since one of the goals of the phylib was to lead to reduced complexity. That said, it looked like there were about a dozen PHY-specific code blocks in there. I saw you submit one PHY driver. Were there others in there that could be ported? [snip] > +static int mdiobus_read(struct mii_bus *bus, int phy_addr, int > regnum) > { > - int i, val; > + struct net_device *const dev = bus->priv; /* beware: bus->phy_map > [phy_addr].attached_dev == dev does _NOT_ hold always */ > + enable_mac(dev, 0); /* make sure MAC associated with this mii_bus > is enabled */ > + return mdio_read(dev, phy_addr, regnum); > +} Why is attached_dev not always correct? I'm not sure if I'm not understanding the hardware (I'm unfamiliar with this NIC), or if you've misinterpreted the meaning of the attached_dev field. It's supposed to be a connection between the network device and a PHY, mainly used for allowing the PHY to signal state changes back to the ethernet device. Is it actually the case that there is one MAC being used for two PHYs at the same time? If so, how do you resolve which PHY's state gets used at any given moment? The same question applies for the code in mdiobus_write() [snip] > -static int mii_probe (struct net_device * dev) > +static int mdiobus_reset(struct mii_bus *bus) > { > - struct au1000_private *aup = (struct au1000_private *) dev->priv; > - int phy_addr; > -#ifdef CONFIG_MIPS_BOSPORUS > - int phy_found=0; > -#endif > + struct net_device *dev = bus->priv; > - /* search for total of 32 possible mii phy addresses */ > - for (phy_addr = 0; phy_addr < 32; phy_addr++) { > - u16 mii_status; > - u16 phy_id0, phy_id1; > - int i; > + enable_mac(dev, 0); /* make sure MAC associated with this mii_bus > is enabled */ > Do you need to call enable_mac() every time? If it needs to be up, wouldn't it be easier to make sure it's up during bus initialization? [snip] > aup->mac->control = control; > @@ -1685,57 +808,75 @@ static int au1000_init(struct net_device > [snip] > + > + if (phydev->link && (aup->old_speed != phydev->speed)) { > + // speed changed > + > + switch(phydev->speed) { > + case 10: > + case 100: > + break; > + default: > + printk(KERN_WARNING > + "%s: Speed (%d) is not 10/100/1000 ??\n", > + dev->name, phydev->speed); > + break; > } Might want to change that to be "...not 10/100..." or add a case for 1000. [snip] > + spin_unlock_irqrestore(&aup->lock, flags); > + if (status_change) { > + phy_print_status(phydev); > + } > } Stylistic issue (I've seen it a couple times, at least): don't use "{" and "}" if your block only has one line. ie: if (status_change) phy_print_status(phydev); From zzh.hust@gmail.com Tue May 9 02:03:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 02:03:11 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:53115 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S8133850AbWEIBDB convert rfc822-to-8bit (ORCPT ); Tue, 9 May 2006 02:03:01 +0100 Received: by nf-out-0910.google.com with SMTP id m19so320909nfc for ; Mon, 08 May 2006 18:03:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ueBnC8QhjO9LVR3ZWzbcdM070WWydhKUlncFjNF54wGY4EOeHQ+EefA2RuN32MhwFRWZmtkcD7fMjRzxnCkU5LK9qv8XiwB6H2hI5nexlE6+aHSc0/aYQD0lZlTXNouc0vTEc4Kx8BoIR1bVwMHwMTLnDP2raGOBKhHGHrMWmK0= Received: by 10.49.39.19 with SMTP id r19mr1651864nfj; Mon, 08 May 2006 18:03:00 -0700 (PDT) Received: by 10.48.144.2 with HTTP; Mon, 8 May 2006 18:03:00 -0700 (PDT) Message-ID: <50c9a2250605081803l3ac0465ase56bab689d1b34e8@mail.gmail.com> Date: Tue, 9 May 2006 09:03:00 +0800 From: zhuzhenhua To: linux-mips Subject: how to reuse the initrd ram by busybox? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 396 Lines: 13 now i use a initrd to boot my system, then switch to the real root filesystem, and i want to reuse the initrd. i see in the redhat, it use the blockdev --flushbufs /dev/ram0 to flush the initrd ram. and i can't find blockdev in busybox, so i use the freeramdisk /dev/ram0, but it seems has no effect.is there any other command to finish this job? thanks for any hints Best regards zhuzhenhua From yoichi_yuasa@tripeaks.co.jp Tue May 9 02:21:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 02:21:26 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:45368 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S7619044AbWEIBVR (ORCPT ); Tue, 9 May 2006 02:21:17 +0100 Received: by mo.po.2iij.net (mo31) id k491LCeF055034; Tue, 9 May 2006 10:21:12 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox32) id k491LBRO083770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 10:21:11 +0900 (JST) Date: Tue, 9 May 2006 10:21:11 +0900 From: Yoichi Yuasa To: zhuzhenhua Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: how to reuse the initrd ram by busybox? Message-Id: <20060509102111.01ccd1a8.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <50c9a2250605081803l3ac0465ase56bab689d1b34e8@mail.gmail.com> References: <50c9a2250605081803l3ac0465ase56bab689d1b34e8@mail.gmail.com> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Content-Length: 537 Lines: 17 Hi, On Tue, 9 May 2006 09:03:00 +0800 zhuzhenhua wrote: > now i use a initrd to boot my system, then switch to the real root > filesystem, and i want to reuse the initrd. > i see in the redhat, it use the blockdev --flushbufs /dev/ram0 to > flush the initrd ram. > and i can't find blockdev in busybox, so i use the freeramdisk > /dev/ram0, but it seems has no effect.is there any other command to > finish this job? "blockdev --flushbufs" only do ioctl(fd, BLKFLSBUF, ...). You can make simple program. Yoichi From hvr@gnu.org Tue May 9 03:06:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 03:07:14 +0100 (BST) Received: from h081217049130.dyn.cm.kabsi.at ([81.217.49.130]:18864 "EHLO phobos.hvrlab.org") by ftp.linux-mips.org with ESMTP id S7619154AbWEICGv (ORCPT ); Tue, 9 May 2006 03:06:51 +0100 Received: from mini.intra (dhcp-1432-30.blizz.at [213.143.126.4]) (authenticated bits=0) by phobos.hvrlab.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4926CQQ026552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 May 2006 04:06:12 +0200 Subject: Re: RFC: new WIP version of au1000_eth.c phylib conversion (was Re: RFC: au1000_etc.c phylib rewrite) From: Herbert Valerio Riedel To: Andy Fleming Cc: Mark Schank , ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, jgarzik@pobox.com, netdev@vger.kernel.org, Ralf Baechle , "Robin H. Johnson" In-Reply-To: <6BF86C09-0732-4322-A43E-29705849886D@freescale.com> References: <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <1146510542.16643.10.camel@localhost.localdomain> <1146510542.16643.10.camel@localhost.localdomain> <5.1.0.14.2.20060501144633.025e4e20@205.166.54.3> <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3> <1146674056.31241.18.camel@localhost.localdomain> <1146734223.31241.44.camel@localhost.localdomain> <6BF86C09-0732-4322-A43E-29705849886D@freescale.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nXAAkLu6qAytME5Lt43T" Organization: Free Software Foundation Date: Tue, 09 May 2006 04:04:23 +0200 Message-Id: <1147140263.1328.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: ClamAV 0.88.1/1451/Tue May 9 01:27:49 2006 on phobos.hvrlab.org X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips Content-Length: 86502 Lines: 1214 --=-nXAAkLu6qAytME5Lt43T Content-Type: multipart/mixed; boundary="=-3obsThmJDBZucvHF3QdD" --=-3obsThmJDBZucvHF3QdD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable jfyi, yet another more recent snapshot is attached to this email... On Mon, 2006-05-08 at 17:24 -0500, Andy Fleming wrote: > > I've tried to adapt the PHY detection code to allow for dynamic =20 > > runtime configuration (with fallback to search for the 2nd MAC PHY on t= he 1st > > MAC's MII bus), as well as selectable static PHY configuration through > > Kconfig (e.g. for supporting PHYs w/o MII connection) >=20 > Comments inline, below: > [snip] >=20 > Nothing to say so far, except seeing all those "-" signs was quite =20 > the thrill, since one of the goals of the phylib was to lead to =20 > reduced complexity. That said, it looked like there were about a =20 > dozen PHY-specific code blocks in there. I saw you submit one PHY =20 > driver. Were there others in there that could be ported? could well be, although I hope that most would work with the genphy driver out of the box; but I'm depending on other people here anyway to test it, since I don't have all kinds of evaluation boards available for testing myself... :-) I submitted the SMSC phy driver, because that's a piece of hardware I had to play with... > [snip] >=20 > > +static int mdiobus_read(struct mii_bus *bus, int phy_addr, int =20 > > regnum) > > { > > - int i, val; > > + struct net_device *const dev =3D bus->priv; /* beware: bus->phy_map=20 > > [phy_addr].attached_dev =3D=3D dev does _NOT_ hold always */ > > + enable_mac(dev, 0); /* make sure MAC associated with this mii_bus =20 > > is enabled */ > > + return mdio_read(dev, phy_addr, regnum); > > +} >=20 >=20 > Why is attached_dev not always correct? I'm not sure if I'm not =20 > understanding the hardware (I'm unfamiliar with this NIC), or if =20 > you've misinterpreted the meaning of the attached_dev field. It's =20 > supposed to be a connection between the network device and a PHY, =20 > mainly used for allowing the PHY to signal state changes back to the =20 > ethernet device. Is it actually the case that there is one MAC being =20 > used for two PHYs at the same time?=20 exactly; some au1xxxx based boards have so-called DualPHYs which provide two PHYs, but with only one MII interface... > If so, how do you resolve which =20 > PHY's state gets used at any given moment? the attached_dev points to the net_device for which the PHY state is relevant -- which might not be the net_device whose MII bus the PHY is attached to... it's just that the net_device stored in the mii_bus->priv field points always to the "physical" net_device and finally, each net_device has a pointer to its "logical" phy_dev ...does this answer your question? :-) > The same question applies for the code in mdiobus_write() >=20 > [snip] > > -static int mii_probe (struct net_device * dev) > > +static int mdiobus_reset(struct mii_bus *bus) > > { > > - struct au1000_private *aup =3D (struct au1000_private *) dev->priv; > > - int phy_addr; > > -#ifdef CONFIG_MIPS_BOSPORUS > > - int phy_found=3D0; > > -#endif > > + struct net_device *dev =3D bus->priv; > > - /* search for total of 32 possible mii phy addresses */ > > - for (phy_addr =3D 0; phy_addr < 32; phy_addr++) { > > - u16 mii_status; > > - u16 phy_id0, phy_id1; > > - int i; > > + enable_mac(dev, 0); /* make sure MAC associated with this mii_bus =20 > > is enabled */ > > >=20 > Do you need to call enable_mac() every time? If it needs to be up, =20 > wouldn't it be easier to make sure it's up during bus initialization? it's actually a hack :-/ it's needed for the case where a PHY is attached to a MAC other than the state-associated one... as MAC can be powered down, when the eth is down, this allows to keep the MAC down if it's not needed, and also make sure it get's enabled again, in case something happened between mdiobus_reset and mdiobus_read/write=20 > [snip] > Might want to change that to be "...not 10/100..." or add a case for =20 > 1000. done... > [snip] >=20 > > + spin_unlock_irqrestore(&aup->lock, flags); > > + if (status_change) { > > + phy_print_status(phydev); > > + } > > } >=20 >=20 > Stylistic issue (I've seen it a couple times, at least): don't use =20 > "{" and "}" if your block only has one line. > ie: > if (status_change) > phy_print_status(phydev); you seem to have found one of the very few if(){single-line} cases I introduced... (and that particular one was even a placeholder which got bloated anyway :-)) regards, hvr --=-3obsThmJDBZucvHF3QdD Content-Disposition: attachment; filename=au1000eth_phylib_conversion.patch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=au1000eth_phylib_conversion.patch; charset=UTF-8 ZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L0tjb25maWcgYi9kcml2ZXJzL25ldC9LY29uZmlnDQpp bmRleCAxZWRjYzBjLi4wZjZhNDFhIDEwMDY0NA0KSW5kZXg6IGd3MTU1MGtlcm5lbC9kcml2ZXJz L25ldC9LY29uZmlnDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gZ3cxNTUwa2VybmVsLm9yaWcvZHJpdmVycy9u ZXQvS2NvbmZpZwkyMDA2LTA1LTA5IDAzOjAxOjM3LjAwMDAwMDAwMCArMDIwMA0KKysrIGd3MTU1 MGtlcm5lbC9kcml2ZXJzL25ldC9LY29uZmlnCTIwMDYtMDUtMDkgMDM6MjA6MTkuMDAwMDAwMDAw ICswMjAwDQpAQCAtNDU1LDExICs0NTUsNTAgQEANCiBjb25maWcgTUlQU19BVTFYMDBfRU5FVA0K IAlib29sICJNSVBTIEFVMTAwMCBFdGhlcm5ldCBzdXBwb3J0Ig0KIAlkZXBlbmRzIG9uIE5FVF9F VEhFUk5FVCAmJiBTT0NfQVUxWDAwDQorCXNlbGVjdCBQSFlMSUINCiAJc2VsZWN0IENSQzMyDQog CWhlbHANCiAJICBJZiB5b3UgaGF2ZSBhbiBBbGNoZW15IFNlbWkgQVUxWDAwIGJhc2VkIHN5c3Rl bQ0KIAkgIHNheSBZLiAgT3RoZXJ3aXNlLCBzYXkgTi4NCiANCitjb25maWcgTUlQU19BVTFYMDBf RU5FVF9TVEFUSUNfUEhZX0NPTkZJRw0KKwlib29sICJTdGF0aWMgUEhZIGNvbmZpZ3VyYXRpb24i DQorCWRlcGVuZHMgb24gTUlQU19BVTFYMDBfRU5FVA0KKwlkZWZhdWx0IG4NCisJaGVscA0KKwkg IFNheSBZIGlmIHlvdSBuZWVkIHRvIHNldCBhIHN0YXRpYyBQSFkgY29uZmlndXJhdGlvbi4gSWYg eW91IHNheSBOLCB0aGUNCisJICBkcml2ZXIgd2lsbCB0cnkgdG8gYXV0b2RldGVjdCB0aGUgUEhZ IGNvbmZpZ3VyYXRpb24uDQorDQorY29uZmlnIE1JUFNfQVUxWDAwX0VORVRfRVRIMF9QSFlfQURE Ug0KKwlpbnQgIjFzdCBFdGhlcm5ldCdzIFBIWSBhZGRyZXNzIHstMSwwLi4zMX0iDQorCWRlcGVu ZHMgb24gTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZX0NPTkZJRw0KKwloZWxwDQorCSAgUHJv dmlkZSB0aGUgUEhZIGFkZHJlc3Mgb2YgdGhlIGZpcnN0IER0aGVybmV0IGRldmljZS4NCisJICBJ ZiB0aGUgUEhZIGhhcyBubyBQSFkgYWRkcmVzcywgc2F5ICItMSIuDQorDQorY29uZmlnIE1JUFNf QVUxWDAwX0VORVRfRVRIMF9QSFlfSVJRDQorCWludCAiMXN0IEV0aGVybmV0J3MgUEhZIElSUSIN CisJZGVwZW5kcyBvbiBNSVBTX0FVMVgwMF9FTkVUX1NUQVRJQ19QSFlfQ09ORklHDQorDQorY29u ZmlnIE1JUFNfQVUxWDAwX0VORVRfRVRIMV9QSFlfT05fTUFDMA0KKwlib29sICIybmQgRXRoZXJu ZXQncyBQSFkgaXMgYXR0YWNoZWQgdG8gMXN0IE1BQyINCisJZGVwZW5kcyBvbiBNSVBTX0FVMVgw MF9FTkVUX1NUQVRJQ19QSFlfQ09ORklHDQorCWRlZmF1bHQgbg0KKwloZWxwDQorCSAgU2F5IFkg aGVyZSwgaWYgdGhlIHNlY29uZCBFdGhlcm5ldCdzIFBIWSBpcyBhdHRhY2hlZCB0bw0KKwkgIHRo ZSBNSUkgYnVzIG9mIHRoZSBmaXJzdCBNQUMuDQorDQorY29uZmlnIE1JUFNfQVUxWDAwX0VORVRf RVRIMV9QSFlfQUREUg0KKwlpbnQgIjJuZCBFdGhlcm5ldCdzIFBIWSBhZGRyZXNzIHstMSwwLi4z MX0iDQorCWRlcGVuZHMgb24gTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZX0NPTkZJRw0KKwlo ZWxwDQorCSAgUHJvdmlkZSB0aGUgUEhZIGFkZHJlc3Mgb2YgdGhlIHNlY29uZCBFdGhlcm5ldCBk ZXZpY2UuDQorCSAgSWYgdGhlIFBIWSBoYXMgbm8gUEhZIGFkZHJlc3MsIHNheSAiLTEiLg0KKw0K K2NvbmZpZyBNSVBTX0FVMVgwMF9FTkVUX0VUSDFfUEhZX0lSUQ0KKwlpbnQgIjJuZCBFdGhlcm5l dCdzIFBIWSBJUlEiDQorCWRlcGVuZHMgb24gTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZX0NP TkZJRw0KKw0KIGNvbmZpZyBTR0lfSU9DM19FVEgNCiAJYm9vbCAiU0dJIElPQzMgRXRoZXJuZXQi DQogCWRlcGVuZHMgb24gTkVUX0VUSEVSTkVUICYmIFBDSSAmJiBTR0lfSVAyNw0KSW5kZXg6IGd3 MTU1MGtlcm5lbC9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBndzE1 NTBrZXJuZWwub3JpZy9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmMJMjAwNi0wNS0wOSAwMzowMTo0 NC4wMDAwMDAwMDAgKzAyMDANCisrKyBndzE1NTBrZXJuZWwvZHJpdmVycy9uZXQvYXUxMDAwX2V0 aC5jCTIwMDYtMDUtMDkgMDM6NDU6MDMuMDAwMDAwMDAwICswMjAwDQpAQCAtOSw2ICs5LDkgQEAN CiAgKiBVcGRhdGU6IDIwMDQgQmpvZXJuIFJpZW1lciwgcmllbWVyQGZva3VzLmZyYXVuaG9mZXIu ZGUgDQogICogb3IgcmllbWVyQHJpZW1lci1udC5kZTogZml4ZWQgdGhlIGxpbmsgYmVhdCBkZXRl Y3Rpb24gd2l0aCANCiAgKiBpb2N0bHMgKFNJT0NHTUlJUEhZKQ0KKyAqIENvcHlyaWdodCAyMDA2 IEhlcmJlcnQgVmFsZXJpbyBSaWVkZWwgPGh2ckBnbnUub3JnPg0KKyAqICBjb252ZXJ0ZWQgdG8g dXNlIGxpbnV4LTIuNi54J3MgUEhZIGZyYW1ld29yaw0KKyAqDQogICogQXV0aG9yOiBNb250YVZp c3RhIFNvZnR3YXJlLCBJbmMuDQogICogICAgICAgICAJcHBvcG92QG12aXN0YS5jb20gb3Igc291 cmNlQG12aXN0YS5jb20NCiAgKg0KQEAgLTUzLDYgKzU2LDcgQEANCiAjaW5jbHVkZSA8bGludXgv c2tidWZmLmg+DQogI2luY2x1ZGUgPGxpbnV4L2RlbGF5Lmg+DQogI2luY2x1ZGUgPGxpbnV4L2Ny YzMyLmg+DQorI2luY2x1ZGUgPGxpbnV4L3BoeS5oPg0KICNpbmNsdWRlIDxhc20vbWlwc3JlZ3Mu aD4NCiAjaW5jbHVkZSA8YXNtL2lycS5oPg0KICNpbmNsdWRlIDxhc20vaW8uaD4NCkBAIC04OCwx NyArOTIsMTUgQEANCiBzdGF0aWMgaW50IGF1MTAwMF9yeChzdHJ1Y3QgbmV0X2RldmljZSAqKTsN CiBzdGF0aWMgaXJxcmV0dXJuX3QgYXUxMDAwX2ludGVycnVwdChpbnQsIHZvaWQgKiwgc3RydWN0 IHB0X3JlZ3MgKik7DQogc3RhdGljIHZvaWQgYXUxMDAwX3R4X3RpbWVvdXQoc3RydWN0IG5ldF9k ZXZpY2UgKik7DQotc3RhdGljIGludCBhdTEwMDBfc2V0X2NvbmZpZyhzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBzdHJ1Y3QgaWZtYXAgKm1hcCk7DQogc3RhdGljIHZvaWQgc2V0X3J4X21vZGUoc3Ry dWN0IG5ldF9kZXZpY2UgKik7DQogc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICphdTEw MDBfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICopOw0KLXN0YXRpYyB2b2lkIGF1MTAwMF90 aW1lcih1bnNpZ25lZCBsb25nKTsNCiBzdGF0aWMgaW50IGF1MTAwMF9pb2N0bChzdHJ1Y3QgbmV0 X2RldmljZSAqLCBzdHJ1Y3QgaWZyZXEgKiwgaW50KTsNCiBzdGF0aWMgaW50IG1kaW9fcmVhZChz dHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQsIGludCk7DQogc3RhdGljIHZvaWQgbWRpb193cml0ZShz dHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQsIGludCwgdTE2KTsNCi1zdGF0aWMgdm9pZCBkdW1wX21p aShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2lkKTsNCitzdGF0aWMgdm9pZCBhdTEw MDBfYWRqdXN0X2xpbmsoc3RydWN0IG5ldF9kZXZpY2UgKik7DQorc3RhdGljIHZvaWQgZW5hYmxl X21hYyhzdHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQpOw0KIA0KIC8vIGV4dGVybnMNCi1leHRlcm4g IHZvaWQgYWNrX3Jpc2VfZWRnZV9pcnEodW5zaWduZWQgaW50KTsNCiBleHRlcm4gaW50IGdldF9l dGhlcm5ldF9hZGRyKGNoYXIgKmV0aGVybmV0X2FkZHIpOw0KIGV4dGVybiB2b2lkIHN0cjJlYWRk cih1bnNpZ25lZCBjaGFyICplYSwgdW5zaWduZWQgY2hhciAqc3RyKTsNCiBleHRlcm4gY2hhciAq IF9faW5pdCBwcm9tX2dldGNtZGxpbmUodm9pZCk7DQpAQCAtMTA4LDExICsxMTAsMTEgQEANCiAg Kg0KICAqIFRoZSBBdTEwMDAgTUFDcyB1c2UgYSBzaW1wbGUgcnggYW5kIHR4IGRlc2NyaXB0b3Ig cmluZyBzY2hlbWUuIA0KICAqIFRoZXJlIGFyZSBmb3VyIHJlY2VpdmUgYW5kIGZvdXIgdHJhbnNt aXQgZGVzY3JpcHRvcnMuICBUaGVzZSANCi0gKiBkZXNjcmlwdG9ycyBhcmUgbm90IGluIG1lbW9y eTsgcmF0aGVyLCB0aGV5IGFyZSBqdXN0IGEgc2V0IG9mIA0KKyAqIGRlc2NyaXB0b3JzIGFyZSBu b3QgaW4gbWVtb3J5OyByYXRoZXIsIHRoZXkgYXJlIGp1c3QgYSBzZXQgb2YNCiAgKiBoYXJkd2Fy ZSByZWdpc3RlcnMuDQogICoNCiAgKiBTaW5jZSB0aGUgQXUxMDAwIGhhcyBhIGNvaGVyZW50IGRh dGEgY2FjaGUsIHRoZSByZWNlaXZlIGFuZA0KLSAqIHRyYW5zbWl0IGJ1ZmZlcnMgYXJlIGFsbG9j YXRlZCBmcm9tIHRoZSBLU0VHMCBzZWdtZW50LiBUaGUgDQorICogdHJhbnNtaXQgYnVmZmVycyBh cmUgYWxsb2NhdGVkIGZyb20gdGhlIEtTRUcwIHNlZ21lbnQuIFRoZQ0KICAqIGhhcmR3YXJlIHJl Z2lzdGVycywgaG93ZXZlciwgYXJlIHN0aWxsIG1hcHBlZCBhdCBLU0VHMSB0bw0KICAqIG1ha2Ug c3VyZSB0aGVyZSdzIG5vIG91dC1vZi1vcmRlciB3cml0ZXMsIGFuZCB0aGF0IGFsbCB3cml0ZXMN CiAgKiBjb21wbGV0ZSBpbW1lZGlhdGVseS4NCkBAIC0xMjIsNzA5ICsxMjQsMjMgQEANCiAgKiB0 aGUgbWFjIGFkZHJlc3MgaXMsIGFuZCB0aGUgbWFjIGFkZHJlc3MgaXMgbm90IHBhc3NlZCBvbiB0 aGUNCiAgKiBjb21tYW5kIGxpbmUuDQogICovDQotc3RhdGljIHVuc2lnbmVkIGNoYXIgYXUxMDAw X21hY19hZGRyWzZdIF9fZGV2aW5pdGRhdGEgPSB7IA0KK3N0YXRpYyB1bnNpZ25lZCBjaGFyIGF1 MTAwMF9tYWNfYWRkcls2XSBfX2RldmluaXRkYXRhID0gew0KIAkweDAwLCAweDUwLCAweGMyLCAw eDBjLCAweDMwLCAweDAwDQogfTsNCiANCi0jZGVmaW5lIG5pYnN3YXAoeCkgKCgoKHgpID4+IDQp ICYgMHgwZikgfCAoKCh4KSA8PCA0KSAmIDB4ZjApKQ0KLSNkZWZpbmUgUlVOX0FUKHgpIChqaWZm aWVzICsgKHgpKQ0KLQ0KLS8vIEZvciByZWFkaW5nL3dyaXRpbmcgMzItYml0IHdvcmRzIGZyb20v dG8gRE1BIG1lbW9yeQ0KLSNkZWZpbmUgY3B1X3RvX2RtYTMyIGNwdV90b19iZTMyDQotI2RlZmlu ZSBkbWEzMl90b19jcHUgYmUzMl90b19jcHUNCi0NCiBzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1 X21hY3NbTlVNX0VUSF9JTlRFUkZBQ0VTXTsNCiANCi0vKiBGSVhNRSANCi0gKiBBbGwgb2YgdGhl IFBIWSBjb2RlIHJlYWxseSBzaG91bGQgYmUgZGV0YWNoZWQgZnJvbSB0aGUgTUFDIA0KLSAqIGNv ZGUuDQorLyoNCisgKiBNSUkgb3BlcmF0aW9ucw0KICAqLw0KLQ0KLS8qIERlZmF1bHQgYWR2ZXJ0 aXNlICovDQotI2RlZmluZSBHRU5NSUlfREVGQVVMVF9BRFZFUlRJU0UgXA0KLQlBRFZFUlRJU0VE XzEwYmFzZVRfSGFsZiB8IEFEVkVSVElTRURfMTBiYXNlVF9GdWxsIHwgXA0KLQlBRFZFUlRJU0VE XzEwMGJhc2VUX0hhbGYgfCBBRFZFUlRJU0VEXzEwMGJhc2VUX0Z1bGwgfCBcDQotCUFEVkVSVElT RURfQXV0b25lZw0KLQ0KLSNkZWZpbmUgR0VOTUlJX0RFRkFVTFRfRkVBVFVSRVMgXA0KLQlTVVBQ T1JURURfMTBiYXNlVF9IYWxmIHwgU1VQUE9SVEVEXzEwYmFzZVRfRnVsbCB8IFwNCi0JU1VQUE9S VEVEXzEwMGJhc2VUX0hhbGYgfCBTVVBQT1JURURfMTAwYmFzZVRfRnVsbCB8IFwNCi0JU1VQUE9S VEVEX0F1dG9uZWcNCi0NCi1pbnQgYmNtXzUyMDFfaW5pdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYgZGF0YTsNCi0JDQotCS8qIFN0b3AgYXV0by1uZWdv dGlhdGlvbiAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9M KTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSAmIH5NSUlf Q05UTF9BVVRPKTsNCi0NCi0JLyogU2V0IGFkdmVydGlzZW1lbnQgdG8gMTAvMTAwIGFuZCBIYWxm L0Z1bGwgZHVwbGV4DQotCSAqIChmdWxsIGNhcGFiaWxpdGllcykgKi8NCi0JZGF0YSA9IG1kaW9f cmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYpOw0KLQlkYXRhIHw9IE1JSV9OV0FZX1RYIHwg TUlJX05XQVlfVFhfRkRYIHwgTUlJX05XQVlfVF9GRFggfCBNSUlfTldBWV9UOw0KLQltZGlvX3dy aXRlKGRldiwgcGh5X2FkZHIsIE1JSV9BTkFEViwgZGF0YSk7DQotCQ0KLQkvKiBSZXN0YXJ0IGF1 dG8tbmVnb3RpYXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlf Q09OVFJPTCk7DQotCWRhdGEgfD0gTUlJX0NOVExfUlNUX0FVVE8gfCBNSUlfQ05UTF9BVVRPOw0K LQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhKTsNCi0NCi0JaWYg KGF1MTAwMF9kZWJ1ZyA+IDQpIA0KLQkJZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotCXJldHVy biAwOw0KLX0NCi0NCi1pbnQgYmNtXzUyMDFfcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwg aW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IG1paV9jb250cm9sLCB0aW1lb3V0Ow0KLQkNCi0JbWlp X2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQltZGlv X3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBtaWlfY29udHJvbCB8IE1JSV9DTlRM X1JFU0VUKTsNCi0JbWRlbGF5KDEpOw0KLQlmb3IgKHRpbWVvdXQgPSAxMDA7IHRpbWVvdXQgPiAw OyAtLXRpbWVvdXQpIHsNCi0JCW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIs IE1JSV9DT05UUk9MKTsNCi0JCWlmICgobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgPT0g MCkNCi0JCQlicmVhazsNCi0JCW1kZWxheSgxKTsNCi0JfQ0KLQlpZiAobWlpX2NvbnRyb2wgJiBN SUlfQ05UTF9SRVNFVCkgew0KLQkJcHJpbnRrKEtFUk5fRVJSICIlcyBQSFkgcmVzZXQgdGltZW91 dCAhXG4iLCBkZXYtPm5hbWUpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotCXJldHVybiAwOw0KLX0N Ci0NCi1pbnQgDQotYmNtXzUyMDFfc3RhdHVzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBw aHlfYWRkciwgdTE2ICpsaW5rLCB1MTYgKnNwZWVkKQ0KLXsNCi0JdTE2IG1paV9kYXRhOw0KLQlz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cDsNCi0NCi0JaWYgKCFkZXYpIHsNCi0JCXByaW50ayhL RVJOX0VSUiAiYmNtXzUyMDFfc3RhdHVzIGVycm9yOiBOVUxMIGRldlxuIik7DQotCQlyZXR1cm4g LTE7DQotCX0NCi0JYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQot DQotCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX1NUQVRVUyk7 DQotCWlmIChtaWlfZGF0YSAmIE1JSV9TVEFUX0xJTkspIHsNCi0JCSpsaW5rID0gMTsNCi0JCW1p aV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0FVWF9DTlRSTCk7DQot CQlpZiAobWlpX2RhdGEgJiBNSUlfQVVYXzEwMCkgew0KLQkJCWlmIChtaWlfZGF0YSAmIE1JSV9B VVhfRkRYKSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCQlkZXYtPmlm X3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQl9DQotCQkJZWxzZSB7DQotCQkJCSpzcGVl ZCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJB U0VUWDsNCi0JCQl9DQotCQl9DQotCQllbHNlICB7DQotCQkJKnNwZWVkID0gSUZfUE9SVF8xMEJB U0VUOw0KLQkJCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfMTBCQVNFVDsNCi0JCX0NCi0NCi0JfQ0K LQllbHNlIHsNCi0JCSpsaW5rID0gMDsNCi0JCSpzcGVlZCA9IDA7DQotCQlkZXYtPmlmX3BvcnQg PSBJRl9QT1JUX1VOS05PV047DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBsc2lfODAy MjdfaW5pdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlpZiAo YXUxMDAwX2RlYnVnID4gNCkNCi0JCXByaW50aygibHNpXzgwMjI3X2luaXRcbiIpOw0KLQ0KLQkv KiByZXN0YXJ0IGF1dG8tbmVnb3RpYXRpb24gKi8NCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRy LCBNSUlfQ09OVFJPTCwNCi0JCSAgIE1JSV9DTlRMX0YxMDAgfCBNSUlfQ05UTF9BVVRPIHwgTUlJ X0NOVExfUlNUX0FVVE8pOyAvLyB8IE1JSV9DTlRMX0ZEWCk7DQotCW1kZWxheSgxKTsNCi0NCi0J Lyogc2V0IHVwIExFRHMgdG8gY29ycmVjdCBkaXNwbGF5ICovDQotI2lmZGVmIENPTkZJR19NSVBT X01UWDENCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCAxNywgMHhmZjgwKTsNCi0jZWxzZQ0K LQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIDE3LCAweGZmYzApOw0KLSNlbmRpZg0KLQ0KLQlp ZiAoYXUxMDAwX2RlYnVnID4gNCkNCi0JCWR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQlyZXR1 cm4gMDsNCi19DQotDQotaW50IGxzaV84MDIyN19yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVvdXQ7DQotCQ0KLQlp ZiAoYXUxMDAwX2RlYnVnID4gNCkgew0KLQkJcHJpbnRrKCJsc2lfODAyMjdfcmVzZXRcbiIpOw0K LQkJZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotCX0NCi0NCi0JbWlpX2NvbnRyb2wgPSBtZGlv X3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5 X2FkZHIsIE1JSV9DT05UUk9MLCBtaWlfY29udHJvbCB8IE1JSV9DTlRMX1JFU0VUKTsNCi0JbWRl bGF5KDEpOw0KLQlmb3IgKHRpbWVvdXQgPSAxMDA7IHRpbWVvdXQgPiAwOyAtLXRpbWVvdXQpIHsN Ci0JCW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsN Ci0JCWlmICgobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgPT0gMCkNCi0JCQlicmVhazsN Ci0JCW1kZWxheSgxKTsNCi0JfQ0KLQlpZiAobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkg ew0KLQkJcHJpbnRrKEtFUk5fRVJSICIlcyBQSFkgcmVzZXQgdGltZW91dCAhXG4iLCBkZXYtPm5h bWUpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQNCi1sc2lf ODAyMjdfc3RhdHVzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICps aW5rLCB1MTYgKnNwZWVkKQ0KLXsNCi0JdTE2IG1paV9kYXRhOw0KLQlzdHJ1Y3QgYXUxMDAwX3By aXZhdGUgKmF1cDsNCi0NCi0JaWYgKCFkZXYpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAibHNpXzgw MjI3X3N0YXR1cyBlcnJvcjogTlVMTCBkZXZcbiIpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotCWF1 cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KLQ0KLQltaWlfZGF0YSA9 IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQlpZiAobWlpX2Rh dGEgJiBNSUlfU1RBVF9MSU5LKSB7DQotCQkqbGluayA9IDE7DQotCQltaWlfZGF0YSA9IG1kaW9f cmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9MU0lfUEhZX1NUQVQpOw0KLQkJaWYgKG1paV9k YXRhICYgTUlJX0xTSV9QSFlfU1RBVF9TUEQpIHsNCi0JCQlpZiAobWlpX2RhdGEgJiBNSUlfTFNJ X1BIWV9TVEFUX0ZEWCkgew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQkJ ZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJfQ0KLQkJCWVsc2Ugew0KLQkJ CQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9S VF8xMDBCQVNFVFg7DQotCQkJfQ0KLQkJfQ0KLQkJZWxzZSAgew0KLQkJCSpzcGVlZCA9IElGX1BP UlRfMTBCQVNFVDsNCi0JCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQl9DQot DQotCX0NCi0JZWxzZSB7DQotCQkqbGluayA9IDA7DQotCQkqc3BlZWQgPSAwOw0KLQkJZGV2LT5p Zl9wb3J0ID0gSUZfUE9SVF9VTktOT1dOOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQg YW03OWM5MDFfaW5pdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0K LQlwcmludGsoImFtNzljOTAxX2luaXRcbiIpOw0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGFt NzljOTAxX3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQot CXByaW50aygiYW03OWM5MDFfcmVzZXRcbiIpOw0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IA0K LWFtNzljOTAxX3N0YXR1cyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUx NiAqbGluaywgdTE2ICpzcGVlZCkNCi17DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgYW03OWM4 NzRfaW5pdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlzMTYg ZGF0YTsNCi0NCi0JLyogNzljODc0IGhhcyBxdWl0IHJlc2VtYmxlZCBiaXQgYXNzaWdubWVudHMg dG8gQkNNNTIwMSAqLw0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkNCi0JCXByaW50aygiYW03OWM4 NDdfaW5pdFxuIik7DQotDQotCS8qIFN0b3AgYXV0by1uZWdvdGlhdGlvbiAqLw0KLQlkYXRhID0g bWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYs IHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSAmIH5NSUlfQ05UTF9BVVRPKTsNCi0NCi0JLyog U2V0IGFkdmVydGlzZW1lbnQgdG8gMTAvMTAwIGFuZCBIYWxmL0Z1bGwgZHVwbGV4DQotCSAqIChm dWxsIGNhcGFiaWxpdGllcykgKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBN SUlfQU5BRFYpOw0KLQlkYXRhIHw9IE1JSV9OV0FZX1RYIHwgTUlJX05XQVlfVFhfRkRYIHwgTUlJ X05XQVlfVF9GRFggfCBNSUlfTldBWV9UOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1J SV9BTkFEViwgZGF0YSk7DQotCQ0KLQkvKiBSZXN0YXJ0IGF1dG8tbmVnb3RpYXRpb24gKi8NCi0J ZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCWRhdGEgfD0g TUlJX0NOVExfUlNUX0FVVE8gfCBNSUlfQ05UTF9BVVRPOw0KLQ0KLQltZGlvX3dyaXRlKGRldiwg cGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhKTsNCi0NCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQp IGR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGFtNzlj ODc0X3Jlc2V0KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMx NiBtaWlfY29udHJvbCwgdGltZW91dDsNCi0JDQotCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KLQkJ cHJpbnRrKCJhbTc5Yzg3NF9yZXNldFxuIik7DQotDQotCW1paV9jb250cm9sID0gbWRpb19yZWFk KGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRy LCBNSUlfQ09OVFJPTCwgbWlpX2NvbnRyb2wgfCBNSUlfQ05UTF9SRVNFVCk7DQotCW1kZWxheSgx KTsNCi0JZm9yICh0aW1lb3V0ID0gMTAwOyB0aW1lb3V0ID4gMDsgLS10aW1lb3V0KSB7DQotCQlt aWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCQlp ZiAoKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpID09IDApDQotCQkJYnJlYWs7DQotCQlt ZGVsYXkoMSk7DQotCX0NCi0JaWYgKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpIHsNCi0J CXByaW50ayhLRVJOX0VSUiAiJXMgUEhZIHJlc2V0IHRpbWVvdXQgIVxuIiwgZGV2LT5uYW1lKTsN Ci0JCXJldHVybiAtMTsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IA0KLWFtNzljODc0 X3N0YXR1cyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUxNiAqbGluaywg dTE2ICpzcGVlZCkNCi17DQotCXUxNiBtaWlfZGF0YTsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRl ICphdXA7DQotDQotCS8vIHByaW50aygiYW03OWM4NzRfc3RhdHVzXG4iKTsNCi0JaWYgKCFkZXYp IHsNCi0JCXByaW50ayhLRVJOX0VSUiAiYW03OWM4NzRfc3RhdHVzIGVycm9yOiBOVUxMIGRldlxu Iik7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0NCi0JYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0 ZSAqKSBkZXYtPnByaXY7DQotCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRk ciwgTUlJX1NUQVRVUyk7DQotDQotCWlmIChtaWlfZGF0YSAmIE1JSV9TVEFUX0xJTkspIHsNCi0J CSpsaW5rID0gMTsNCi0JCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0FNRF9QSFlfU1RBVCk7DQotCQlpZiAobWlpX2RhdGEgJiBNSUlfQU1EX1BIWV9TVEFUX1NQ RCkgew0KLQkJCWlmIChtaWlfZGF0YSAmIE1JSV9BTURfUEhZX1NUQVRfRkRYKSB7DQotCQkJCSpz cGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEw MEJBU0VGWDsNCi0JCQl9DQotCQkJZWxzZSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFT RVRYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQl9DQotCQl9 DQotCQllbHNlIHsNCi0JCQkqc3BlZWQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQkJZGV2LT5pZl9w b3J0ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJfQ0KLQ0KLQl9DQotCWVsc2Ugew0KLQkJKmxpbmsg PSAwOw0KLQkJKnNwZWVkID0gMDsNCi0JCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfVU5LTk9XTjsN Ci0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IGx4dDk3MWFfaW5pdChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkNCi0J CXByaW50aygibHh0OTcxYV9pbml0XG4iKTsNCi0NCi0JLyogcmVzdGFydCBhdXRvLW5lZ290aWF0 aW9uICovDQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsDQotCQkgICBN SUlfQ05UTF9GMTAwIHwgTUlJX0NOVExfQVVUTyB8IE1JSV9DTlRMX1JTVF9BVVRPIHwgTUlJX0NO VExfRkRYKTsNCi0NCi0JLyogc2V0IHVwIExFRHMgdG8gY29ycmVjdCBkaXNwbGF5ICovDQotCW1k aW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgMjAsIDB4MDQyMik7DQotDQotCWlmIChhdTEwMDBfZGVi dWcgPiA0KQ0KLQkJZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7DQotCXJldHVybiAwOw0KLX0NCi0N Ci1pbnQgbHh0OTcxYV9yZXNldChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIp DQotew0KLQlzMTYgbWlpX2NvbnRyb2wsIHRpbWVvdXQ7DQotCQ0KLQlpZiAoYXUxMDAwX2RlYnVn ID4gNCkgew0KLQkJcHJpbnRrKCJseHQ5NzFhX3Jlc2V0XG4iKTsNCi0JCWR1bXBfbWlpKGRldiwg cGh5X2FkZHIpOw0KLQl9DQotDQotCW1paV9jb250cm9sID0gbWRpb19yZWFkKGRldiwgcGh5X2Fk ZHIsIE1JSV9DT05UUk9MKTsNCi0JbWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJP TCwgbWlpX2NvbnRyb2wgfCBNSUlfQ05UTF9SRVNFVCk7DQotCW1kZWxheSgxKTsNCi0JZm9yICh0 aW1lb3V0ID0gMTAwOyB0aW1lb3V0ID4gMDsgLS10aW1lb3V0KSB7DQotCQltaWlfY29udHJvbCA9 IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCk7DQotCQlpZiAoKG1paV9jb250 cm9sICYgTUlJX0NOVExfUkVTRVQpID09IDApDQotCQkJYnJlYWs7DQotCQltZGVsYXkoMSk7DQot CX0NCi0JaWYgKG1paV9jb250cm9sICYgTUlJX0NOVExfUkVTRVQpIHsNCi0JCXByaW50ayhLRVJO X0VSUiAiJXMgUEhZIHJlc2V0IHRpbWVvdXQgIVxuIiwgZGV2LT5uYW1lKTsNCi0JCXJldHVybiAt MTsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50DQotbHh0OTcxYV9zdGF0dXMoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyLCB1MTYgKmxpbmssIHUxNiAqc3BlZWQpDQot ew0KLQl1MTYgbWlpX2RhdGE7DQotCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwOw0KLQ0KLQlp ZiAoIWRldikgew0KLQkJcHJpbnRrKEtFUk5fRVJSICJseHQ5NzFhX3N0YXR1cyBlcnJvcjogTlVM TCBkZXZcbiIpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotCWF1cCA9IChzdHJ1Y3QgYXUxMDAwX3By aXZhdGUgKikgZGV2LT5wcml2Ow0KLQ0KLQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+ cGh5X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQlpZiAobWlpX2RhdGEgJiBNSUlfU1RBVF9MSU5LKSB7 DQotCQkqbGluayA9IDE7DQotCQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2Fk ZHIsIE1JSV9JTlRFTF9QSFlfU1RBVCk7DQotCQlpZiAobWlpX2RhdGEgJiBNSUlfSU5URUxfUEhZ X1NUQVRfU1BEKSB7DQotCQkJaWYgKG1paV9kYXRhICYgTUlJX0lOVEVMX1BIWV9TVEFUX0ZEWCkg ew0KLQkJCQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0g SUZfUE9SVF8xMDBCQVNFRlg7DQotCQkJfQ0KLQkJCWVsc2Ugew0KLQkJCQkqc3BlZWQgPSBJRl9Q T1JUXzEwMEJBU0VUWDsNCi0JCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMDBCQVNFVFg7DQot CQkJfQ0KLQkJfQ0KLQkJZWxzZSAgew0KLQkJCSpzcGVlZCA9IElGX1BPUlRfMTBCQVNFVDsNCi0J CQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQl9DQotDQotCX0NCi0JZWxzZSB7 DQotCQkqbGluayA9IDA7DQotCQkqc3BlZWQgPSAwOw0KLQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9S VF9VTktOT1dOOw0KLQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQga3M4OTk1bV9pbml0KHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBwaHlfYWRkcikNCi17DQotCXMxNiBkYXRhOw0KLQkN Ci0vLwlwcmludGsoImtzODk5NW1faW5pdFxuIik7DQotCS8qIFN0b3AgYXV0by1uZWdvdGlhdGlv biAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0J bWRpb193cml0ZShkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgZGF0YSAmIH5NSUlfQ05UTF9B VVRPKTsNCi0NCi0JLyogU2V0IGFkdmVydGlzZW1lbnQgdG8gMTAvMTAwIGFuZCBIYWxmL0Z1bGwg ZHVwbGV4DQotCSAqIChmdWxsIGNhcGFiaWxpdGllcykgKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChk ZXYsIHBoeV9hZGRyLCBNSUlfQU5BRFYpOw0KLQlkYXRhIHw9IE1JSV9OV0FZX1RYIHwgTUlJX05X QVlfVFhfRkRYIHwgTUlJX05XQVlfVF9GRFggfCBNSUlfTldBWV9UOw0KLQltZGlvX3dyaXRlKGRl diwgcGh5X2FkZHIsIE1JSV9BTkFEViwgZGF0YSk7DQotCQ0KLQkvKiBSZXN0YXJ0IGF1dG8tbmVn b3RpYXRpb24gKi8NCi0JZGF0YSA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfQ09OVFJP TCk7DQotCWRhdGEgfD0gTUlJX0NOVExfUlNUX0FVVE8gfCBNSUlfQ05UTF9BVVRPOw0KLQltZGlv X3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBkYXRhKTsNCi0NCi0JaWYgKGF1MTAw MF9kZWJ1ZyA+IDQpIGR1bXBfbWlpKGRldiwgcGh5X2FkZHIpOw0KLQ0KLQlyZXR1cm4gMDsNCi19 DQotDQotaW50IGtzODk5NW1fcmVzZXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9h ZGRyKQ0KLXsNCi0JczE2IG1paV9jb250cm9sLCB0aW1lb3V0Ow0KLQkNCi0vLwlwcmludGsoImtz ODk5NW1fcmVzZXRcbiIpOw0KLQltaWlfY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRy LCBNSUlfQ09OVFJPTCk7DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0ws IG1paV9jb250cm9sIHwgTUlJX0NOVExfUkVTRVQpOw0KLQltZGVsYXkoMSk7DQotCWZvciAodGlt ZW91dCA9IDEwMDsgdGltZW91dCA+IDA7IC0tdGltZW91dCkgew0KLQkJbWlpX2NvbnRyb2wgPSBt ZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wpOw0KLQkJaWYgKChtaWlfY29udHJv bCAmIE1JSV9DTlRMX1JFU0VUKSA9PSAwKQ0KLQkJCWJyZWFrOw0KLQkJbWRlbGF5KDEpOw0KLQl9 DQotCWlmIChtaWlfY29udHJvbCAmIE1JSV9DTlRMX1JFU0VUKSB7DQotCQlwcmludGsoS0VSTl9F UlIgIiVzIFBIWSByZXNldCB0aW1lb3V0ICFcbiIsIGRldi0+bmFtZSk7DQotCQlyZXR1cm4gLTE7 DQotCX0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLWludCBrczg5OTVtX3N0YXR1cyhzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUxNiAqbGluaywgdTE2ICpzcGVlZCkNCi17DQot CXUxNiBtaWlfZGF0YTsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXA7DQotDQotCWlmICgh ZGV2KSB7DQotCQlwcmludGsoS0VSTl9FUlIgImtzODk5NW1fc3RhdHVzIGVycm9yOiBOVUxMIGRl dlxuIik7DQotCQlyZXR1cm4gLTE7DQotCX0NCi0JYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0 ZSAqKSBkZXYtPnByaXY7DQotDQotCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlf YWRkciwgTUlJX1NUQVRVUyk7DQotCWlmIChtaWlfZGF0YSAmIE1JSV9TVEFUX0xJTkspIHsNCi0J CSpsaW5rID0gMTsNCi0JCW1paV9kYXRhID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0FVWF9DTlRSTCk7DQotCQlpZiAobWlpX2RhdGEgJiBNSUlfQVVYXzEwMCkgew0KLQkJCWlm IChtaWlfZGF0YSAmIE1JSV9BVVhfRkRYKSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFT RUZYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQl9DQotCQkJ ZWxzZSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCQlkZXYtPmlmX3Bv cnQgPSBJRl9QT1JUXzEwMEJBU0VUWDsNCi0JCQl9DQotCQl9DQotCQllbHNlICB7CQkJCQkJCQkJ CQkNCi0JCQkqc3BlZWQgPSBJRl9QT1JUXzEwQkFTRVQ7DQotCQkJZGV2LT5pZl9wb3J0ID0gSUZf UE9SVF8xMEJBU0VUOw0KLQkJfQ0KLQ0KLQl9DQotCWVsc2Ugew0KLQkJKmxpbmsgPSAwOw0KLQkJ KnNwZWVkID0gMDsNCi0JCWRldi0+aWZfcG9ydCA9IElGX1BPUlRfVU5LTk9XTjsNCi0JfQ0KLQly ZXR1cm4gMDsNCi19DQotDQotaW50DQotc21zY184M0MxODVfaW5pdCAoc3RydWN0IG5ldF9kZXZp Y2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IGRhdGE7DQotDQotCWlmIChhdTEwMDBf ZGVidWcgPiA0KQ0KLQkJcHJpbnRrKCJzbXNjXzgzQzE4NV9pbml0XG4iKTsNCi0NCi0JLyogU3Rv cCBhdXRvLW5lZ290aWF0aW9uICovDQotCWRhdGEgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBk YXRhICYgfk1JSV9DTlRMX0FVVE8pOw0KLQ0KLQkvKiBTZXQgYWR2ZXJ0aXNlbWVudCB0byAxMC8x MDAgYW5kIEhhbGYvRnVsbCBkdXBsZXgNCi0JICogKGZ1bGwgY2FwYWJpbGl0aWVzKSAqLw0KLQlk YXRhID0gbWRpb19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9BTkFEVik7DQotCWRhdGEgfD0gTUlJ X05XQVlfVFggfCBNSUlfTldBWV9UWF9GRFggfCBNSUlfTldBWV9UX0ZEWCB8IE1JSV9OV0FZX1Q7 DQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0FOQURWLCBkYXRhKTsNCi0JDQotCS8q IFJlc3RhcnQgYXV0by1uZWdvdGlhdGlvbiAqLw0KLQlkYXRhID0gbWRpb19yZWFkKGRldiwgcGh5 X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JZGF0YSB8PSBNSUlfQ05UTF9SU1RfQVVUTyB8IE1JSV9D TlRMX0FVVE87DQotDQotCW1kaW9fd3JpdGUoZGV2LCBwaHlfYWRkciwgTUlJX0NPTlRST0wsIGRh dGEpOw0KLQ0KLQlpZiAoYXUxMDAwX2RlYnVnID4gNCkgZHVtcF9taWkoZGV2LCBwaHlfYWRkcik7 DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQNCi1zbXNjXzgzQzE4NV9yZXNldCAoc3RydWN0IG5l dF9kZXZpY2UgKmRldiwgaW50IHBoeV9hZGRyKQ0KLXsNCi0JczE2IG1paV9jb250cm9sLCB0aW1l b3V0Ow0KLQkNCi0JaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQotCQlwcmludGsoInNtc2NfODNDMTg1 X3Jlc2V0XG4iKTsNCi0NCi0JbWlpX2NvbnRyb2wgPSBtZGlvX3JlYWQoZGV2LCBwaHlfYWRkciwg TUlJX0NPTlRST0wpOw0KLQltZGlvX3dyaXRlKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MLCBt aWlfY29udHJvbCB8IE1JSV9DTlRMX1JFU0VUKTsNCi0JbWRlbGF5KDEpOw0KLQlmb3IgKHRpbWVv dXQgPSAxMDA7IHRpbWVvdXQgPiAwOyAtLXRpbWVvdXQpIHsNCi0JCW1paV9jb250cm9sID0gbWRp b19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCWlmICgobWlpX2NvbnRyb2wg JiBNSUlfQ05UTF9SRVNFVCkgPT0gMCkNCi0JCQlicmVhazsNCi0JCW1kZWxheSgxKTsNCi0JfQ0K LQlpZiAobWlpX2NvbnRyb2wgJiBNSUlfQ05UTF9SRVNFVCkgew0KLQkJcHJpbnRrKEtFUk5fRVJS ICIlcyBQSFkgcmVzZXQgdGltZW91dCAhXG4iLCBkZXYtPm5hbWUpOw0KLQkJcmV0dXJuIC0xOw0K LQl9DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgDQotc21zY184M0MxODVfc3RhdHVzIChzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIHUxNiAqbGluaywgdTE2ICpzcGVlZCkN Ci17DQotCXUxNiBtaWlfZGF0YTsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXA7DQotDQot CWlmICghZGV2KSB7DQotCQlwcmludGsoS0VSTl9FUlIgInNtc2NfODNDMTg1X3N0YXR1cyBlcnJv cjogTlVMTCBkZXZcbiIpOw0KLQkJcmV0dXJuIC0xOw0KLQl9DQotDQotCWF1cCA9IChzdHJ1Y3Qg YXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KLQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYs IGF1cC0+cGh5X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQ0KLQlpZiAobWlpX2RhdGEgJiBNSUlfU1RB VF9MSU5LKSB7DQotCQkqbGluayA9IDE7DQotCQltaWlfZGF0YSA9IG1kaW9fcmVhZChkZXYsIGF1 cC0+cGh5X2FkZHIsIDB4MWYpOw0KLQkJaWYgKG1paV9kYXRhICYgKDE8PDMpKSB7DQotCQkJaWYg KG1paV9kYXRhICYgKDE8PDQpKSB7DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRUZYOw0K LQkJCQlkZXYtPmlmX3BvcnQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JCQl9DQotCQkJZWxzZSB7 DQotCQkJCSpzcGVlZCA9IElGX1BPUlRfMTAwQkFTRVRYOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSBJ Rl9QT1JUXzEwMEJBU0VUWDsNCi0JCQl9DQotCQl9DQotCQllbHNlIHsNCi0JCQkqc3BlZWQgPSBJ Rl9QT1JUXzEwQkFTRVQ7DQotCQkJZGV2LT5pZl9wb3J0ID0gSUZfUE9SVF8xMEJBU0VUOw0KLQkJ fQ0KLQl9DQotCWVsc2Ugew0KLQkJKmxpbmsgPSAwOw0KLQkJKnNwZWVkID0gMDsNCi0JCWRldi0+ aWZfcG9ydCA9IElGX1BPUlRfVU5LTk9XTjsNCi0JfQ0KLQlyZXR1cm4gMDsNCi19DQotDQotDQot I2lmZGVmIENPTkZJR19NSVBTX0JPU1BPUlVTDQotaW50IHN0dWJfaW5pdChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQkvL3ByaW50aygiUEhZIHN0dWJfaW5pdFxu Iik7DQotCXJldHVybiAwOw0KLX0NCi0NCi1pbnQgc3R1Yl9yZXNldChzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgcGh5X2FkZHIpDQotew0KLQkvL3ByaW50aygiUEhZIHN0dWJfcmVzZXRcbiIp Ow0KLQlyZXR1cm4gMDsNCi19DQotDQotaW50IA0KLXN0dWJfc3RhdHVzKHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsIGludCBwaHlfYWRkciwgdTE2ICpsaW5rLCB1MTYgKnNwZWVkKQ0KLXsNCi0JLy9w cmludGsoIlBIWSBzdHViX3N0YXR1c1xuIik7DQotCSpsaW5rID0gMTsNCi0JLyogaG1tbSwgcmV2 aXNpdCAqLw0KLQkqc3BlZWQgPSBJRl9QT1JUXzEwMEJBU0VGWDsNCi0JZGV2LT5pZl9wb3J0ID0g SUZfUE9SVF8xMDBCQVNFRlg7DQotCXJldHVybiAwOw0KLX0NCi0jZW5kaWYNCi0NCi1zdHJ1Y3Qg cGh5X29wcyBiY21fNTIwMV9vcHMgPSB7DQotCWJjbV81MjAxX2luaXQsDQotCWJjbV81MjAxX3Jl c2V0LA0KLQliY21fNTIwMV9zdGF0dXMsDQotfTsNCi0NCi1zdHJ1Y3QgcGh5X29wcyBhbTc5Yzg3 NF9vcHMgPSB7DQotCWFtNzljODc0X2luaXQsDQotCWFtNzljODc0X3Jlc2V0LA0KLQlhbTc5Yzg3 NF9zdGF0dXMsDQotfTsNCi0NCi1zdHJ1Y3QgcGh5X29wcyBhbTc5YzkwMV9vcHMgPSB7DQotCWFt NzljOTAxX2luaXQsDQotCWFtNzljOTAxX3Jlc2V0LA0KLQlhbTc5YzkwMV9zdGF0dXMsDQotfTsN Ci0NCi1zdHJ1Y3QgcGh5X29wcyBsc2lfODAyMjdfb3BzID0geyANCi0JbHNpXzgwMjI3X2luaXQs DQotCWxzaV84MDIyN19yZXNldCwNCi0JbHNpXzgwMjI3X3N0YXR1cywNCi19Ow0KLQ0KLXN0cnVj dCBwaHlfb3BzIGx4dDk3MWFfb3BzID0geyANCi0JbHh0OTcxYV9pbml0LA0KLQlseHQ5NzFhX3Jl c2V0LA0KLQlseHQ5NzFhX3N0YXR1cywNCi19Ow0KLQ0KLXN0cnVjdCBwaHlfb3BzIGtzODk5NW1f b3BzID0gew0KLQlrczg5OTVtX2luaXQsDQotCWtzODk5NW1fcmVzZXQsDQotCWtzODk5NW1fc3Rh dHVzLA0KLX07DQotDQotc3RydWN0IHBoeV9vcHMgc21zY184M0MxODVfb3BzID0gew0KLQlzbXNj XzgzQzE4NV9pbml0LA0KLQlzbXNjXzgzQzE4NV9yZXNldCwNCi0Jc21zY184M0MxODVfc3RhdHVz LA0KLX07DQotDQotI2lmZGVmIENPTkZJR19NSVBTX0JPU1BPUlVTDQotc3RydWN0IHBoeV9vcHMg c3R1Yl9vcHMgPSB7DQotCXN0dWJfaW5pdCwNCi0Jc3R1Yl9yZXNldCwNCi0Jc3R1Yl9zdGF0dXMs DQotfTsNCi0jZW5kaWYNCi0NCi1zdGF0aWMgc3RydWN0IG1paV9jaGlwX2luZm8gew0KLQljb25z dCBjaGFyICogbmFtZTsNCi0JdTE2IHBoeV9pZDA7DQotCXUxNiBwaHlfaWQxOw0KLQlzdHJ1Y3Qg cGh5X29wcyAqcGh5X29wczsJDQotCWludCBkdWFsX3BoeTsNCi19IG1paV9jaGlwX3RhYmxlW10g PSB7DQotCXsiQnJvYWRjb20gQkNNNTIwMSAxMC8xMDAgQmFzZVQgUEhZIiwweDAwNDAsMHg2MjEy LCAmYmNtXzUyMDFfb3BzLDB9LA0KLQl7IkJyb2FkY29tIEJDTTUyMjEgMTAvMTAwIEJhc2VUIFBI WSIsMHgwMDQwLDB4NjFlNCwgJmJjbV81MjAxX29wcywwfSwNCi0JeyJCcm9hZGNvbSBCQ001MjIy IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDA0MCwweDYzMjIsICZiY21fNTIwMV9vcHMsMX0sDQotCXsi TlMgRFA4Mzg0NyBQSFkiLCAweDIwMDAsIDB4NWMzMCwgJmJjbV81MjAxX29wcyAsMH0sDQotCXsi QU1EIDc5QzkwMSBIb21lUE5BIFBIWSIsMHgwMDAwLDB4MzVjOCwgJmFtNzljOTAxX29wcywwfSwN Ci0JeyJBTUQgNzlDODc0IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAyMiwweDU2MWIsICZhbTc5Yzg3 NF9vcHMsMH0sDQotCXsiTFNJIDgwMjI3IDEwLzEwMCBCYXNlVCBQSFkiLDB4MDAxNiwweGY4NDAs ICZsc2lfODAyMjdfb3BzLDB9LA0KLQl7IkludGVsIExYVDk3MUEgRHVhbCBTcGVlZCBQSFkiLDB4 MDAxMywweDc4ZTIsICZseHQ5NzFhX29wcywwfSwNCi0JeyJLZW5kaW4gS1M4OTk1TSAxMC8xMDAg QmFzZVQgUEhZIiwweDAwMjIsMHgxNDUwLCAma3M4OTk1bV9vcHMsMH0sDQotCXsiU01TQyBMQU44 M0MxODUgMTAvMTAwIEJhc2VUIFBIWSIsMHgwMDA3LDB4YzBhMywgJnNtc2NfODNDMTg1X29wcyww fSwNCi0jaWZkZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi0JeyJTdHViIiwgMHgxMjM0LCAweDU2 NzgsICZzdHViX29wcyB9LA0KLSNlbmRpZg0KLQl7MCx9LA0KLX07DQotDQotc3RhdGljIGludCBt ZGlvX3JlYWQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9pZCwgaW50IHJlZykNCitz dGF0aWMgaW50IG1kaW9fcmVhZChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIs IGludCByZWcpDQogew0KIAlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUx MDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KLQl2b2xhdGlsZSB1MzIgKm1paV9jb250cm9sX3Jl ZzsNCi0Jdm9sYXRpbGUgdTMyICptaWlfZGF0YV9yZWc7DQorCXZvbGF0aWxlIHUzMiAqY29uc3Qg bWlpX2NvbnRyb2xfcmVnID0gJmF1cC0+bWFjLT5taWlfY29udHJvbDsNCisJdm9sYXRpbGUgdTMy ICpjb25zdCBtaWlfZGF0YV9yZWcgPSAmYXVwLT5tYWMtPm1paV9kYXRhOw0KIAl1MzIgdGltZWRv dXQgPSAyMDsNCiAJdTMyIG1paV9jb250cm9sOw0KIA0KLQkjaWZkZWYgQ09ORklHX0JDTTUyMjJf RFVBTF9QSFkNCi0JLyogRmlyc3QgdGltZSB3ZSBwcm9iZSwgaXQncyBmb3IgdGhlIG1hYzAgcGh5 Lg0KLQkgKiBTaW5jZSB3ZSBoYXZlbid0IGRldGVybWluZWQgeWV0IHRoYXQgd2UgaGF2ZSBhIGR1 YWwgcGh5LA0KLQkgKiBhdXAtPm1paS0+bWlpX2NvbnRyb2xfcmVnIHdvbid0IGJlIHNldHVwIGFu ZCB3ZSdsbA0KLQkgKiBkZWZhdWx0IHRvIHRoZSBlbHNlIHN0YXRlbWVudC4NCi0JICogQnkgdGhl IHRpbWUgd2UgcHJvYmUgZm9yIHRoZSBtYWMxIHBoeSwgdGhlIG1paV9jb250cm9sX3JlZw0KLQkg KiB3aWxsIGJlIHNldHVwIHRvIGJlIHRoZSBhZGRyZXNzIG9mIHRoZSBtYWMwIHBoeSBjb250cm9s IHNpbmNlDQotCSAqIGJvdGggcGh5cyBhcmUgY29udHJvbGxlZCB0aHJvdWdoIG1hYzAuDQotCSAq Lw0KLQlpZiAoYXVwLT5taWkgJiYgYXVwLT5taWktPm1paV9jb250cm9sX3JlZykgew0KLQkJbWlp X2NvbnRyb2xfcmVnID0gYXVwLT5taWktPm1paV9jb250cm9sX3JlZzsNCi0JCW1paV9kYXRhX3Jl ZyA9IGF1cC0+bWlpLT5taWlfZGF0YV9yZWc7DQotCX0NCi0JZWxzZSBpZiAoYXVfbWFjc1swXS0+ bWlpICYmIGF1X21hY3NbMF0tPm1paS0+bWlpX2NvbnRyb2xfcmVnKSB7DQotCQkvKiBhc3N1bWUg Ym90aCBwaHlzIGFyZSBjb250cm9sbGVkIHRocm91Z2ggbWFjMCAqLw0KLQkJbWlpX2NvbnRyb2xf cmVnID0gYXVfbWFjc1swXS0+bWlpLT5taWlfY29udHJvbF9yZWc7DQotCQltaWlfZGF0YV9yZWcg PSBhdV9tYWNzWzBdLT5taWktPm1paV9kYXRhX3JlZzsNCi0JfQ0KLQllbHNlIA0KLQkjZW5kaWYN Ci0Jew0KLQkJLyogZGVmYXVsdCBjb250cm9sIGFuZCBkYXRhIHJlZyBhZGRyZXNzZXMgKi8NCi0J CW1paV9jb250cm9sX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2NvbnRyb2w7DQotCQltaWlfZGF0YV9y ZWcgPSAmYXVwLT5tYWMtPm1paV9kYXRhOw0KLQl9DQotDQogCXdoaWxlICgqbWlpX2NvbnRyb2xf cmVnICYgTUFDX01JSV9CVVNZKSB7DQogCQltZGVsYXkoMSk7DQogCQlpZiAoLS10aW1lZG91dCA9 PSAwKSB7DQpAQCAtODM1LDcgKzE1MSw3IEBADQogCX0NCiANCiAJbWlpX2NvbnRyb2wgPSBNQUNf U0VUX01JSV9TRUxFQ1RfUkVHKHJlZykgfCANCi0JCU1BQ19TRVRfTUlJX1NFTEVDVF9QSFkocGh5 X2lkKSB8IE1BQ19NSUlfUkVBRDsNCisJCU1BQ19TRVRfTUlJX1NFTEVDVF9QSFkocGh5X2FkZHIp IHwgTUFDX01JSV9SRUFEOw0KIA0KIAkqbWlpX2NvbnRyb2xfcmVnID0gbWlpX2NvbnRyb2w7DQog DQpAQCAtODUxLDMyICsxNjcsMTQgQEANCiAJcmV0dXJuIChpbnQpKm1paV9kYXRhX3JlZzsNCiB9 DQogDQotc3RhdGljIHZvaWQgbWRpb193cml0ZShzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQg cGh5X2lkLCBpbnQgcmVnLCB1MTYgdmFsdWUpDQorc3RhdGljIHZvaWQgbWRpb193cml0ZShzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgcGh5X2FkZHIsIGludCByZWcsIHUxNiB2YWx1ZSkNCiB7 DQogCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAq KSBkZXYtPnByaXY7DQotCXZvbGF0aWxlIHUzMiAqbWlpX2NvbnRyb2xfcmVnOw0KLQl2b2xhdGls ZSB1MzIgKm1paV9kYXRhX3JlZzsNCisJdm9sYXRpbGUgdTMyICpjb25zdCBtaWlfY29udHJvbF9y ZWcgPSAmYXVwLT5tYWMtPm1paV9jb250cm9sOw0KKwl2b2xhdGlsZSB1MzIgKmNvbnN0IG1paV9k YXRhX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2RhdGE7DQogCXUzMiB0aW1lZG91dCA9IDIwOw0KIAl1 MzIgbWlpX2NvbnRyb2w7DQogDQotCSNpZmRlZiBDT05GSUdfQkNNNTIyMl9EVUFMX1BIWQ0KLQlp ZiAoYXVwLT5taWkgJiYgYXVwLT5taWktPm1paV9jb250cm9sX3JlZykgew0KLQkJbWlpX2NvbnRy b2xfcmVnID0gYXVwLT5taWktPm1paV9jb250cm9sX3JlZzsNCi0JCW1paV9kYXRhX3JlZyA9IGF1 cC0+bWlpLT5taWlfZGF0YV9yZWc7DQotCX0NCi0JZWxzZSBpZiAoYXVfbWFjc1swXS0+bWlpICYm IGF1X21hY3NbMF0tPm1paS0+bWlpX2NvbnRyb2xfcmVnKSB7DQotCQkvKiBhc3N1bWUgYm90aCBw aHlzIGFyZSBjb250cm9sbGVkIHRocm91Z2ggbWFjMCAqLw0KLQkJbWlpX2NvbnRyb2xfcmVnID0g YXVfbWFjc1swXS0+bWlpLT5taWlfY29udHJvbF9yZWc7DQotCQltaWlfZGF0YV9yZWcgPSBhdV9t YWNzWzBdLT5taWktPm1paV9kYXRhX3JlZzsNCi0JfQ0KLQllbHNlIA0KLQkjZW5kaWYNCi0Jew0K LQkJLyogZGVmYXVsdCBjb250cm9sIGFuZCBkYXRhIHJlZyBhZGRyZXNzZXMgKi8NCi0JCW1paV9j b250cm9sX3JlZyA9ICZhdXAtPm1hYy0+bWlpX2NvbnRyb2w7DQotCQltaWlfZGF0YV9yZWcgPSAm YXVwLT5tYWMtPm1paV9kYXRhOw0KLQl9DQotDQogCXdoaWxlICgqbWlpX2NvbnRyb2xfcmVnICYg TUFDX01JSV9CVVNZKSB7DQogCQltZGVsYXkoMSk7DQogCQlpZiAoLS10aW1lZG91dCA9PSAwKSB7 DQpAQCAtODg3LDE2NSArMTg1LDE2NyBAQA0KIAl9DQogDQogCW1paV9jb250cm9sID0gTUFDX1NF VF9NSUlfU0VMRUNUX1JFRyhyZWcpIHwgDQotCQlNQUNfU0VUX01JSV9TRUxFQ1RfUEhZKHBoeV9p ZCkgfCBNQUNfTUlJX1dSSVRFOw0KKwkJTUFDX1NFVF9NSUlfU0VMRUNUX1BIWShwaHlfYWRkcikg fCBNQUNfTUlJX1dSSVRFOw0KIA0KIAkqbWlpX2RhdGFfcmVnID0gdmFsdWU7DQogCSptaWlfY29u dHJvbF9yZWcgPSBtaWlfY29udHJvbDsNCiB9DQogDQotDQotc3RhdGljIHZvaWQgZHVtcF9taWko c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IHBoeV9pZCkNCitzdGF0aWMgaW50IG1kaW9idXNf cmVhZChzdHJ1Y3QgbWlpX2J1cyAqYnVzLCBpbnQgcGh5X2FkZHIsIGludCByZWdudW0pDQogew0K LQlpbnQgaSwgdmFsOw0KLQ0KLQlmb3IgKGkgPSAwOyBpIDwgNzsgaSsrKSB7DQotCQlpZiAoKHZh bCA9IG1kaW9fcmVhZChkZXYsIHBoeV9pZCwgaSkpID49IDApDQotCQkJcHJpbnRrKCIlczogTUlJ IFJlZyAlZD0leFxuIiwgZGV2LT5uYW1lLCBpLCB2YWwpOw0KKwkvKiBXQVJOSU5HOiBidXMtPnBo eV9tYXBbcGh5X2FkZHJdLmF0dGFjaGVkX2RldiA9PSBkZXYgZG9lcw0KKwkgKiBfTk9UXyBob2xk IChlLmcuIHdoZW4gUEhZIGlzIGFjY2Vzc2VkIHRocm91Z2ggb3RoZXIgTUFDJ3MgTUlJIGJ1cykg Ki8NCisJc3RydWN0IG5ldF9kZXZpY2UgKmNvbnN0IGRldiA9IGJ1cy0+cHJpdjsNCisNCisJZW5h YmxlX21hYyhkZXYsIDApOyAvKiBtYWtlIHN1cmUgdGhlIE1BQyBhc3NvY2lhdGVkIHdpdGggdGhp cw0KKwkJCSAgICAgKiBtaWlfYnVzIGlzIGVuYWJsZWQgKi8NCisJcmV0dXJuIG1kaW9fcmVhZChk ZXYsIHBoeV9hZGRyLCByZWdudW0pOw0KK30NCisNCitzdGF0aWMgaW50IG1kaW9idXNfd3JpdGUo c3RydWN0IG1paV9idXMgKmJ1cywgaW50IHBoeV9hZGRyLCBpbnQgcmVnbnVtLA0KKwkJCSB1MTYg dmFsdWUpDQorew0KKwlzdHJ1Y3QgbmV0X2RldmljZSAqY29uc3QgZGV2ID0gYnVzLT5wcml2Ow0K Kw0KKwllbmFibGVfbWFjKGRldiwgMCk7IC8qIG1ha2Ugc3VyZSB0aGUgTUFDIGFzc29jaWF0ZWQg d2l0aCB0aGlzDQorCQkJICAgICAqIG1paV9idXMgaXMgZW5hYmxlZCAqLw0KKwltZGlvX3dyaXRl KGRldiwgcGh5X2FkZHIsIHJlZ251bSwgdmFsdWUpOw0KKwlyZXR1cm4gMDsNCit9DQorDQorc3Rh dGljIGludCBtZGlvYnVzX3Jlc2V0KHN0cnVjdCBtaWlfYnVzICpidXMpDQorew0KKwlzdHJ1Y3Qg bmV0X2RldmljZSAqY29uc3QgZGV2ID0gYnVzLT5wcml2Ow0KKw0KKwllbmFibGVfbWFjKGRldiwg MCk7IC8qIG1ha2Ugc3VyZSB0aGUgTUFDIGFzc29jaWF0ZWQgd2l0aCB0aGlzDQorCQkJICAgICAq IG1paV9idXMgaXMgZW5hYmxlZCAqLw0KKwlyZXR1cm4gMDsNCit9DQorDQorc3RhdGljIGludCBt aWlfcHJvYmUgKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQorew0KKwlzdHJ1Y3QgYXUxMDAwX3By aXZhdGUgKmNvbnN0IGF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0K KwlzdHJ1Y3QgcGh5X2RldmljZSAqcGh5ZGV2ID0gTlVMTDsNCisNCisjaWYgZGVmaW5lZChDT05G SUdfTUlQU19BVTFYMDBfRU5FVF9TVEFUSUNfUEhZX0NPTkZJRykNCisJQlVHX09OKGF1cC0+bWFj X2lkIDwgMCB8fCBhdXAtPm1hY19pZCA+IDEpOw0KKw0KKwlpZihhdXAtPm1hY19pZCA9PSAwKSB7 DQorIyBpZiBDT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgwX1BIWV9BRERSPT0tMQ0KKwkJcHJp bnRrIChLRVJOX0lORk8gRFJWX05BTUUgIjolczogdXNpbmcgUEhZLWxlc3MgY29uZmlnXG4iLCBk ZXYtPm5hbWUpOw0KKwkJcmV0dXJuIDA7DQorIyBlbGlmIChDT05GSUdfTUlQU19BVTFYMDBfRU5F VF9FVEgwX1BIWV9BRERSPj0wKSAmJiAoQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMF9QSFlf QUREUjxQSFlfTUFYX0FERFIpDQorCQlwaHlkZXYgPSBhdXAtPm1paV9idXMucGh5X21hcFtDT05G SUdfTUlQU19BVTFYMDBfRU5FVF9FVEgwX1BIWV9BRERSXTsNCisjICAgaWYgZGVmaW5lZChDT05G SUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9JUlEpDQorCQkvKiBmaXggdXAgSVJRICovDQor CQlhdXAtPm1paV9idXMuaXJxW0NPTkZJR19NSVBTX0FVMVgwMF9FTkVUX0VUSDBfUEhZX0FERFJd ID0gQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMF9QSFlfSVJROw0KKwkJaWYocGh5ZGV2KQ0K KwkJCXBoeWRldi0+aXJxID0gQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMF9QSFlfSVJROw0K KyMgICBlbmRpZg0KKyMgZWxzZQ0KKyMgIGVycm9yIEJhZCB2YWx1ZSBmb3IgQ09ORklHX01JUFNf QVUxWDAwX0VORVRfRVRIMF9QSFlfQUREUiBnaXZlbg0KKyMgZW5kaWYNCisJfSBlbHNlIGlmIChh dXAtPm1hY19pZCA9PSAxKSB7DQorIyBpZiBDT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BI WV9BRERSPT0tMQ0KKwkJcHJpbnRrIChLRVJOX0lORk8gRFJWX05BTUUgIjolczogdXNpbmcgUEhZ LWxlc3MgY29uZmlnXG4iLCBkZXYtPm5hbWUpOw0KKwkJcmV0dXJuIDA7DQorIyBlbGlmIChDT05G SUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9BRERSPj0wKSAmJiAoQ09ORklHX01JUFNfQVUx WDAwX0VORVRfRVRIMV9QSFlfQUREUjxQSFlfTUFYX0FERFIpDQorIyAgaWYgZGVmaW5lZChDT05G SUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9PTl9NQUMwKQ0KKyMgICBpZiBDT05GSUdfTUlQ U19BVTFYMDBfRU5FVF9FVEgxX1BIWV9BRERSPT1DT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgw X1BIWV9BRERSDQorIyAgICBlcnJvciBnaXZlbiBzYW1lIHN0YXRpYyBQSFkgYWRkcmVzcywgYW5k IGJvdGggUEhZcyBhcmUgb24gdGhlIHNhbWUgYnVzDQorIyAgIGVuZGlmDQorCQlwaHlkZXYgPSBh dV9tYWNzWzBdLT5taWlfYnVzLnBoeV9tYXBbQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMV9Q SFlfQUREUl07DQorIyAgIGlmIGRlZmluZWQoQ09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMV9Q SFlfSVJRKQ0KKwkJLyogZml4IHVwIElSUSAqLw0KKwkJYXVfbWFjc1swXS0+bWlpX2J1cy5pcnFb Q09ORklHX01JUFNfQVUxWDAwX0VORVRfRVRIMV9QSFlfQUREUl0gPSBDT05GSUdfTUlQU19BVTFY MDBfRU5FVF9FVEgxX1BIWV9JUlE7DQorCQlpZihwaHlkZXYpDQorCQkJcGh5ZGV2LT5pcnEgPSBD T05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9JUlE7DQorIyAgIGVuZGlmDQorIyAgZWxz ZQ0KKwkJcGh5ZGV2ID0gYXVwLT5taWlfYnVzLnBoeV9tYXBbQ09ORklHX01JUFNfQVUxWDAwX0VO RVRfRVRIMV9QSFlfQUREUl07DQorIyAgIGlmIGRlZmluZWQoQ09ORklHX01JUFNfQVUxWDAwX0VO RVRfRVRIMV9QSFlfSVJRKQ0KKwkJLyogZml4IHVwIElSUSAqLw0KKwkJYXVwLT5taWlfYnVzLmly cVtDT05GSUdfTUlQU19BVTFYMDBfRU5FVF9FVEgxX1BIWV9BRERSXSA9IENPTkZJR19NSVBTX0FV MVgwMF9FTkVUX0VUSDFfUEhZX0lSUTsNCisJCWlmKHBoeWRldikNCisJCQlwaHlkZXYtPmlycSA9 IENPTkZJR19NSVBTX0FVMVgwMF9FTkVUX0VUSDFfUEhZX0lSUTsNCisjICAgZW5kaWYNCisjICBl bmRpZg0KKyMgZWxzZQ0KKyMgIGVycm9yIEJhZCB2YWx1ZSBmb3IgQ09ORklHX01JUFNfQVUxWDAw X0VORVRfRVRIMF9QSFlfQUREUiBnaXZlbg0KKyMgZW5kaWYNCiAJfQ0KLQlmb3IgKGkgPSAxNjsg aSA8IDI1OyBpKyspIHsNCi0JCWlmICgodmFsID0gbWRpb19yZWFkKGRldiwgcGh5X2lkLCBpKSkg Pj0gMCkNCi0JCQlwcmludGsoIiVzOiBNSUkgUmVnICVkPSV4XG4iLCBkZXYtPm5hbWUsIGksIHZh bCk7DQotCX0NCi19DQogDQotc3RhdGljIGludCBtaWlfcHJvYmUgKHN0cnVjdCBuZXRfZGV2aWNl ICogZGV2KQ0KLXsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAw MF9wcml2YXRlICopIGRldi0+cHJpdjsNCisjZWxzZSAvKiBydW50aW1lIGRldGVjdGVkIFBIWSBj b25maWd1cmF0aW9uICovDQogCWludCBwaHlfYWRkcjsNCi0jaWZkZWYgQ09ORklHX01JUFNfQk9T UE9SVVMNCi0JaW50IHBoeV9mb3VuZD0wOw0KLSNlbmRpZg0KLQ0KLQkvKiBzZWFyY2ggZm9yIHRv dGFsIG9mIDMyIHBvc3NpYmxlIG1paSBwaHkgYWRkcmVzc2VzICovDQotCWZvciAocGh5X2FkZHIg PSAwOyBwaHlfYWRkciA8IDMyOyBwaHlfYWRkcisrKSB7DQotCQl1MTYgbWlpX3N0YXR1czsNCi0J CXUxNiBwaHlfaWQwLCBwaHlfaWQxOw0KLQkJaW50IGk7DQotDQotCQkjaWZkZWYgQ09ORklHX0JD TTUyMjJfRFVBTF9QSFkNCi0JCS8qIE1hc2sgdGhlIGFscmVhZHkgZm91bmQgcGh5LCB0cnkgbmV4 dCBvbmUgKi8NCi0JCWlmIChhdV9tYWNzWzBdLT5taWkgJiYgYXVfbWFjc1swXS0+bWlpLT5taWlf Y29udHJvbF9yZWcpIHsNCi0JCQlpZiAoYXVfbWFjc1swXS0+cGh5X2FkZHIgPT0gcGh5X2FkZHIp DQotCQkJCWNvbnRpbnVlOw0KLQkJfQ0KLQkJI2VuZGlmDQogDQotCQltaWlfc3RhdHVzID0gbWRp b19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9TVEFUVVMpOw0KLQkJaWYgKG1paV9zdGF0dXMgPT0g MHhmZmZmIHx8IG1paV9zdGF0dXMgPT0gMHgwMDAwKQ0KLQkJCS8qIHRoZSBtaWkgaXMgbm90IGFj Y2Vzc2FibGUsIHRyeSBuZXh0IG9uZSAqLw0KLQkJCWNvbnRpbnVlOw0KLQ0KLQkJcGh5X2lkMCA9 IG1kaW9fcmVhZChkZXYsIHBoeV9hZGRyLCBNSUlfUEhZX0lEMCk7DQotCQlwaHlfaWQxID0gbWRp b19yZWFkKGRldiwgcGh5X2FkZHIsIE1JSV9QSFlfSUQxKTsNCi0NCi0JCS8qIHNlYXJjaCBvdXIg bWlpIHRhYmxlIGZvciB0aGUgY3VycmVudCBtaWkgKi8gDQotCQlmb3IgKGkgPSAwOyBtaWlfY2hp cF90YWJsZVtpXS5waHlfaWQxOyBpKyspIHsNCi0JCQlpZiAocGh5X2lkMCA9PSBtaWlfY2hpcF90 YWJsZVtpXS5waHlfaWQwICYmDQotCQkJICAgIHBoeV9pZDEgPT0gbWlpX2NoaXBfdGFibGVbaV0u cGh5X2lkMSkgew0KLQkJCQlzdHJ1Y3QgbWlpX3BoeSAqIG1paV9waHkgPSBhdXAtPm1paTsNCi0N Ci0JCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6ICVzIGF0IHBoeSBhZGRyZXNzICVkXG4iLA0KLQkJ CQkgICAgICAgZGV2LT5uYW1lLCBtaWlfY2hpcF90YWJsZVtpXS5uYW1lLCANCi0JCQkJICAgICAg IHBoeV9hZGRyKTsNCi0jaWZkZWYgQ09ORklHX01JUFNfQk9TUE9SVVMNCi0JCQkJcGh5X2ZvdW5k ID0gMTsNCi0jZW5kaWYNCi0JCQkJbWlpX3BoeS0+Y2hpcF9pbmZvID0gbWlpX2NoaXBfdGFibGUr aTsNCi0JCQkJYXVwLT5waHlfYWRkciA9IHBoeV9hZGRyOw0KLQkJCQlhdXAtPndhbnRfYXV0b25l ZyA9IDE7DQotCQkJCWF1cC0+cGh5X29wcyA9IG1paV9jaGlwX3RhYmxlW2ldLnBoeV9vcHM7DQot CQkJCWF1cC0+cGh5X29wcy0+cGh5X2luaXQoZGV2LHBoeV9hZGRyKTsNCi0NCi0JCQkJLy8gQ2hl Y2sgZm9yIGR1YWwtcGh5IGFuZCB0aGVuIHN0b3JlIHJlcXVpcmVkIA0KLQkJCQkvLyB2YWx1ZXMg YW5kIHNldCBpbmRpY2F0b3JzLiBXZSBuZWVkIHRvIGRvIA0KLQkJCQkvLyB0aGlzIG5vdyBzaW5j ZSBtZGlvX3tyZWFkLHdyaXRlfSBuZWVkIHRoZSANCi0JCQkJLy8gY29udHJvbCBhbmQgZGF0YSBy ZWdpc3RlciBhZGRyZXNzZXMuDQotCQkJCSNpZmRlZiBDT05GSUdfQkNNNTIyMl9EVUFMX1BIWQ0K LQkJCQlpZiAoIG1paV9jaGlwX3RhYmxlW2ldLmR1YWxfcGh5KSB7DQotDQotCQkJCQkvKiBhc3N1 bWUgYm90aCBwaHlzIGFyZSBjb250cm9sbGVkIA0KLQkJCQkJICogdGhyb3VnaCBNQUMwLiBCb2Fy ZCBzcGVjaWZpYz8gKi8NCi0JCQkJCQ0KLQkJCQkJLyogc2FuaXR5IGNoZWNrICovDQotCQkJCQlp ZiAoIWF1X21hY3NbMF0gfHwgIWF1X21hY3NbMF0tPm1paSkNCi0JCQkJCQlyZXR1cm4gLTE7DQot CQkJCQlhdXAtPm1paS0+bWlpX2NvbnRyb2xfcmVnID0gKHUzMiAqKQ0KLQkJCQkJCSZhdV9tYWNz WzBdLT5tYWMtPm1paV9jb250cm9sOw0KLQkJCQkJYXVwLT5taWktPm1paV9kYXRhX3JlZyA9ICh1 MzIgKikNCi0JCQkJCQkmYXVfbWFjc1swXS0+bWFjLT5taWlfZGF0YTsNCi0JCQkJfQ0KLQkJCQkj ZW5kaWYNCi0JCQkJZ290byBmb3VuZDsNCi0JCQl9DQotCQl9DQotCX0NCi1mb3VuZDoNCisJLyog ZmluZCB0aGUgZmlyc3QgKGxvd2VzdCBhZGRyZXNzKSBQSFkgb24gdGhlIGN1cnJlbnQgTUFDJ3Mg TUlJIGJ1cyAqLw0KKwlmb3IgKHBoeV9hZGRyID0gMDsgcGh5X2FkZHIgPCBQSFlfTUFYX0FERFI7 IHBoeV9hZGRyKyspDQorCQlpZiAoYXVwLT5taWlfYnVzLnBoeV9tYXBbcGh5X2FkZHJdKSB7DQor CQkJcGh5ZGV2ID0gYXVwLT5taWlfYnVzLnBoeV9tYXBbcGh5X2FkZHJdOw0KKwkJCWJyZWFrOyAv KiBmb3VuZCBpdCAqLw0KKwkJfQ0KKw0KKwkvKiB0cnkgaGFyZGVyIHRvIGZpbmQgYSBQSFkgKi8N CisJaWYgKCFwaHlkZXYgJiYgKGF1cC0+bWFjX2lkID09IDEpKSB7DQorCQkvKiBubyBQSFkgZm91 bmQsIG1heWJlIHdlIGhhdmUgYSBkdWFsIFBIWT8gKi8NCisJCXByaW50ayAoS0VSTl9JTkZPIERS Vl9OQU1FICI6IG5vIFBIWSBmb3VuZCBvbiBNQUMxLCAiDQorCQkJImxldCdzIHNlZSBpZiBpdCdz IGF0dGFjaGVkIHRvIE1BQzAuLi5cbiIpOw0KKw0KKwkJQlVHX09OKCFhdV9tYWNzWzBdIHx8ICFh dV9tYWNzWzBdLT5taWlfYnVzKTsNCisNCisJCS8qIGZpbmQgdGhlIGZpcnN0IChsb3dlc3QgYWRk cmVzcykgbm9uLWF0dGFjaGVkIFBIWSBvbg0KKwkJICogdGhlIE1BQzAgTUlJIGJ1cyAqLw0KKwkJ Zm9yIChwaHlfYWRkciA9IDA7IHBoeV9hZGRyIDwgUEhZX01BWF9BRERSOyBwaHlfYWRkcisrKSB7 DQorCQkJc3RydWN0IHBoeV9kZXZpY2UgKmNvbnN0IHRtcF9waHlkZXYgPQ0KKwkJCQlhdXAtPmF1 X21hY3NbMF0tPm1paV9idXMucGh5X21hcFtwaHlfYWRkcl07DQogDQotI2lmZGVmIENPTkZJR19N SVBTX0JPU1BPUlVTDQotCS8qIFRoaXMgaXMgYSB3b3JrYXJvdW5kIGZvciB0aGUgTWljcmVsL0tl bmRpbiA1IHBvcnQgc3dpdGNoDQotCSAgIFRoZSBzZWNvbmQgTUFDIGRvZXNuJ3Qgc2VlIGEgUEhZ IGNvbm5lY3RlZC4uLiBzbyB3ZSBuZWVkIHRvDQotCSAgIHRyaWNrIGl0IGludG8gdGhpbmtpbmcg d2UgaGF2ZSBvbmUuDQotCQkNCi0JICAgSWYgdGhpcyBrZXJuZWwgaXMgcnVuIG9uIGFub3RoZXIg QXUxNTAwIGRldmVsb3BtZW50IGJvYXJkDQotCSAgIHRoZSBzdHViIHdpbGwgYmUgZm91bmQgYXMg d2VsbCBhcyB0aGUgYWN0dWFsIFBIWS4gSG93ZXZlciwNCi0JICAgdGhlIGxhc3QgZm91bmQgUEhZ IHdpbGwgYmUgdXNlZC4uLiB1c3VhbGx5IGF0IEFkZHIgMzEgKERiMTUwMCkuCQ0KLQkqLw0KLQlp ZiAoICghcGh5X2ZvdW5kKSApDQotCXsNCi0JCXUxNiBwaHlfaWQwLCBwaHlfaWQxOw0KLQkJaW50 IGk7DQorCQkJaWYgKCF0bXBfcGh5ZGV2KQ0KKwkJCQljb250aW51ZTsgLyogbm8gUEhZIGhlcmUu Li4gKi8NCiANCi0JCXBoeV9pZDAgPSAweDEyMzQ7DQotCQlwaHlfaWQxID0gMHg1Njc4Ow0KKwkJ CWlmICh0bXBfcGh5ZGV2LT5hdHRhY2hlZF9kZXYpDQorCQkJCWNvbnRpbnVlOyAvKiBhbHJlYWR5 IGNsYWltZWQgYnkgTUFDMCAqLw0KIA0KLQkJLyogc2VhcmNoIG91ciBtaWkgdGFibGUgZm9yIHRo ZSBjdXJyZW50IG1paSAqLyANCi0JCWZvciAoaSA9IDA7IG1paV9jaGlwX3RhYmxlW2ldLnBoeV9p ZDE7IGkrKykgew0KLQkJCWlmIChwaHlfaWQwID09IG1paV9jaGlwX3RhYmxlW2ldLnBoeV9pZDAg JiYNCi0JCQkgICAgcGh5X2lkMSA9PSBtaWlfY2hpcF90YWJsZVtpXS5waHlfaWQxKSB7DQotCQkJ CXN0cnVjdCBtaWlfcGh5ICogbWlpX3BoeTsNCi0NCi0JCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6 ICVzIGF0IHBoeSBhZGRyZXNzICVkXG4iLA0KLQkJCQkgICAgICAgZGV2LT5uYW1lLCBtaWlfY2hp cF90YWJsZVtpXS5uYW1lLCANCi0JCQkJICAgICAgIHBoeV9hZGRyKTsNCi0JCQkJbWlpX3BoeSA9 IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBtaWlfcGh5KSwgDQotCQkJCQkJR0ZQX0tFUk5FTCk7DQot CQkJCWlmIChtaWlfcGh5KSB7DQotCQkJCQltaWlfcGh5LT5jaGlwX2luZm8gPSBtaWlfY2hpcF90 YWJsZStpOw0KLQkJCQkJYXVwLT5waHlfYWRkciA9IHBoeV9hZGRyOw0KLQkJCQkJbWlpX3BoeS0+ bmV4dCA9IGF1cC0+bWlpOw0KLQkJCQkJYXVwLT5waHlfb3BzID0gDQotCQkJCQkJbWlpX2NoaXBf dGFibGVbaV0ucGh5X29wczsNCi0JCQkJCWF1cC0+bWlpID0gbWlpX3BoeTsNCi0JCQkJCWF1cC0+ cGh5X29wcy0+cGh5X2luaXQoZGV2LHBoeV9hZGRyKTsNCi0JCQkJfSBlbHNlIHsNCi0JCQkJCXBy aW50ayhLRVJOX0VSUiAiJXM6IG91dCBvZiBtZW1vcnlcbiIsIA0KLQkJCQkJCQlkZXYtPm5hbWUp Ow0KLQkJCQkJcmV0dXJuIC0xOw0KLQkJCQl9DQotCQkJCW1paV9waHktPmNoaXBfaW5mbyA9IG1p aV9jaGlwX3RhYmxlK2k7DQotCQkJCWF1cC0+cGh5X2FkZHIgPSBwaHlfYWRkcjsNCi0JCQkJYXVw LT5waHlfb3BzID0gbWlpX2NoaXBfdGFibGVbaV0ucGh5X29wczsNCi0JCQkJYXVwLT5waHlfb3Bz LT5waHlfaW5pdChkZXYscGh5X2FkZHIpOw0KLQkJCQlicmVhazsNCi0JCQl9DQorCQkJcGh5ZGV2 ID0gdG1wX3BoeWRldjsNCisJCQlicmVhazsgLyogZm91bmQgaXQgKi8NCiAJCX0NCiAJfQ0KLQlp ZiAoYXVwLT5tYWNfaWQgPT0gMCkgew0KLQkJLyogdGhlIEJvc3BvcnVzIHBoeSByZXNwb25kcyB0 byBhZGRyZXNzZXMgMC01IGJ1dCANCi0JCSAqIDUgaXMgdGhlIGNvcnJlY3Qgb25lLg0KLQkJICov DQotCQlhdXAtPnBoeV9hZGRyID0gNTsNCi0JfQ0KLSNlbmRpZg0KIA0KLQlpZiAoYXVwLT5taWkt PmNoaXBfaW5mbyA9PSBOVUxMKSB7DQotCQlwcmludGsoS0VSTl9FUlIgIiVzOiBBdTF4IE5vIGtu b3duIE1JSSB0cmFuc2NlaXZlcnMgZm91bmQhXG4iLA0KLQkJCQlkZXYtPm5hbWUpOw0KKyNlbmRp Zg0KKwlpZiAoIXBoeWRldikgew0KKwkJcHJpbnRrIChLRVJOX0VSUiBEUlZfTkFNRSAiOiVzOiBu byBQSFkgZm91bmRcbiIsIGRldi0+bmFtZSk7DQogCQlyZXR1cm4gLTE7DQogCX0NCiANCi0JcHJp bnRrKEtFUk5fSU5GTyAiJXM6IFVzaW5nICVzIGFzIGRlZmF1bHRcbiIsIA0KLQkJCWRldi0+bmFt ZSwgYXVwLT5taWktPmNoaXBfaW5mby0+bmFtZSk7DQorCS8qIG5vdyB3ZSBhcmUgc3VwcG9zZWQg dG8gaGF2ZSBhIHByb3BlciBwaHlkZXYsIHRvIGF0dGFjaCB0by4uLiAqLw0KKwlCVUdfT04oIXBo eWRldik7DQorDQorCXBoeWRldiA9IHBoeV9jb25uZWN0KGRldiwgcGh5ZGV2LT5kZXYuYnVzX2lk LCAmYXUxMDAwX2FkanVzdF9saW5rLCAwKTsNCisNCisJaWYgKElTX0VSUihwaHlkZXYpKSB7DQor CQlwcmludGsoS0VSTl9FUlIgIiVzOiBDb3VsZCBub3QgYXR0YWNoIHRvIFBIWVxuIiwgZGV2LT5u YW1lKTsNCisJCXJldHVybiBQVFJfRVJSKHBoeWRldik7DQorCX0NCisNCisJLyogbWFzayB3aXRo IE1BQyBzdXBwb3J0ZWQgZmVhdHVyZXMgKi8NCisJcGh5ZGV2LT5zdXBwb3J0ZWQgJj0gKFNVUFBP UlRFRF8xMGJhc2VUX0hhbGYNCisJCQkgICAgICB8IFNVUFBPUlRFRF8xMGJhc2VUX0Z1bGwNCisJ CQkgICAgICB8IFNVUFBPUlRFRF8xMDBiYXNlVF9IYWxmDQorCQkJICAgICAgfCBTVVBQT1JURURf MTAwYmFzZVRfRnVsbA0KKwkJCSAgICAgIHwgU1VQUE9SVEVEX0F1dG9uZWcNCisJCQkgICAgICAv KiB8IFNVUFBPUlRFRF9QYXVzZSB8IFNVUFBPUlRFRF9Bc3ltX1BhdXNlICovDQorCQkJICAgICAg fCBTVVBQT1JURURfTUlJDQorCQkJICAgICAgfCBTVVBQT1JURURfVFApOw0KKw0KKwlwaHlkZXYt PmFkdmVydGlzaW5nID0gcGh5ZGV2LT5zdXBwb3J0ZWQ7DQorDQorCWF1cC0+b2xkX2xpbmsgPSAw Ow0KKwlhdXAtPm9sZF9zcGVlZCA9IDA7DQorCWF1cC0+b2xkX2R1cGxleCA9IC0xOw0KKwlhdXAt PnBoeV9kZXYgPSBwaHlkZXY7DQorDQorCXByaW50ayhLRVJOX0lORk8gIiVzOiBhdHRhY2hlZCBQ SFkgZHJpdmVyIFslc10gIg0KKwkgICAgICAgIihtaWlfYnVzOnBoeV9hZGRyPSVzLCBpcnE9JWQp XG4iLA0KKwkgICAgICAgZGV2LT5uYW1lLCBwaHlkZXYtPmRydi0+bmFtZSwgcGh5ZGV2LT5kZXYu YnVzX2lkLCBwaHlkZXYtPmlycSk7DQogDQogCXJldHVybiAwOw0KIH0NCkBAIC0xMDk3LDM1ICsz OTcsMzggQEANCiAJYXVfc3luY19kZWxheSgxMCk7DQogfQ0KIA0KLQ0KLXN0YXRpYyB2b2lkIHJl c2V0X21hYyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0KK3N0YXRpYyB2b2lkIGVuYWJsZV9tYWMo c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50IGZvcmNlX3Jlc2V0KQ0KIHsNCi0JaW50IGk7DQot CXUzMiBmbGFnczsNCisJdW5zaWduZWQgbG9uZyBmbGFnczsNCiAJc3RydWN0IGF1MTAwMF9wcml2 YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+cHJpdjsNCiANCi0JaWYg KGF1MTAwMF9kZWJ1ZyA+IDQpIA0KLQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IHJlc2V0IG1hYywg YXVwICV4XG4iLCANCi0JCQkJZGV2LT5uYW1lLCAodW5zaWduZWQpYXVwKTsNCi0NCiAJc3Bpbl9s b2NrX2lycXNhdmUoJmF1cC0+bG9jaywgZmxhZ3MpOw0KLQlpZiAoYXVwLT50aW1lci5mdW5jdGlv biA9PSAmYXUxMDAwX3RpbWVyKSB7LyogY2hlY2sgaWYgdGltZXIgaW5pdHRlZCAqLw0KLQkJZGVs X3RpbWVyKCZhdXAtPnRpbWVyKTsNCi0JfQ0KIA0KLQloYXJkX3N0b3AoZGV2KTsNCi0JI2lmZGVm IENPTkZJR19CQ001MjIyX0RVQUxfUEhZDQotCWlmIChhdXAtPm1hY19pZCAhPSAwKSB7DQotCSNl bmRpZg0KLQkJLyogSWYgQkNNNTIyMiwgd2UgY2FuJ3QgbGVhdmUgTUFDMCBpbiByZXNldCBiZWNh dXNlIHRoZW4gDQotCQkgKiB3ZSBjYW4ndCBhY2Nlc3MgdGhlIGR1YWwgcGh5IGZvciBFVEgxICov DQorCWlmKGZvcmNlX3Jlc2V0IHx8ICghYXVwLT5tYWNfZW5hYmxlZCkpIHsNCiAJCSphdXAtPmVu YWJsZSA9IE1BQ19FTl9DTE9DS19FTkFCTEU7DQogCQlhdV9zeW5jX2RlbGF5KDIpOw0KLQkJKmF1 cC0+ZW5hYmxlID0gMDsNCisJCSphdXAtPmVuYWJsZSA9IChNQUNfRU5fUkVTRVQwIHwgTUFDX0VO X1JFU0VUMSB8IE1BQ19FTl9SRVNFVDINCisJCQkJfCBNQUNfRU5fQ0xPQ0tfRU5BQkxFKTsNCiAJ CWF1X3N5bmNfZGVsYXkoMik7DQotCSNpZmRlZiBDT05GSUdfQkNNNTIyMl9EVUFMX1BIWQ0KKw0K KwkJYXVwLT5tYWNfZW5hYmxlZCA9IDE7DQogCX0NCi0JI2VuZGlmDQorDQorCXNwaW5fdW5sb2Nr X2lycXJlc3RvcmUoJmF1cC0+bG9jaywgZmxhZ3MpOw0KK30NCisNCitzdGF0aWMgdm9pZCByZXNl dF9tYWNfdW5sb2NrZWQoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCit7DQorCXN0cnVjdCBhdTEw MDBfcHJpdmF0ZSAqY29uc3QgYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnBy aXY7DQorCWludCBpOw0KKw0KKwloYXJkX3N0b3AoZGV2KTsNCisNCisJKmF1cC0+ZW5hYmxlID0g TUFDX0VOX0NMT0NLX0VOQUJMRTsNCisJYXVfc3luY19kZWxheSgyKTsNCisJKmF1cC0+ZW5hYmxl ID0gMDsNCisJYXVfc3luY19kZWxheSgyKTsNCisNCiAJYXVwLT50eF9mdWxsID0gMDsNCiAJZm9y IChpID0gMDsgaSA8IE5VTV9SWF9ETUE7IGkrKykgew0KIAkJLyogcmVzZXQgY29udHJvbCBiaXRz ICovDQpAQCAtMTEzNSw5ICs0MzgsMjYgQEANCiAJCS8qIHJlc2V0IGNvbnRyb2wgYml0cyAqLw0K IAkJYXVwLT50eF9kbWFfcmluZ1tpXS0+YnVmZl9zdGF0ICY9IH4weGY7DQogCX0NCi0Jc3Bpbl91 bmxvY2tfaXJxcmVzdG9yZSgmYXVwLT5sb2NrLCBmbGFncyk7DQorDQorCWF1cC0+bWFjX2VuYWJs ZWQgPSAwOw0KKw0KIH0NCiANCitzdGF0aWMgdm9pZCByZXNldF9tYWMoc3RydWN0IG5ldF9kZXZp Y2UgKmRldikNCit7DQorCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqY29uc3QgYXVwID0gKHN0cnVj dCBhdTEwMDBfcHJpdmF0ZSAqKSBkZXYtPnByaXY7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQor DQorCWlmIChhdTEwMDBfZGVidWcgPiA0KQ0KKwkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IHJlc2V0 IG1hYywgYXVwICV4XG4iLA0KKwkJICAgICAgIGRldi0+bmFtZSwgKHVuc2lnbmVkKWF1cCk7DQor DQorCXNwaW5fbG9ja19pcnFzYXZlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCisNCisJcmVzZXRfbWFj X3VubG9ja2VkIChkZXYpOw0KKw0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZhdXAtPmxvY2ss IGZsYWdzKTsNCit9DQogDQogLyogDQogICogU2V0dXAgdGhlIHJlY2VpdmUgYW5kIHRyYW5zbWl0 ICJyaW5ncyIuICBUaGVzZSBwb2ludGVycyBhcmUgdGhlIGFkZHJlc3Nlcw0KQEAgLTEyMzcsMTc4 ICs1NTcsMzEgQEANCiAJcmV0dXJuIDA7DQogfQ0KIA0KLXN0YXRpYyBpbnQgYXUxMDAwX3NldHVw X2FuZWcoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgdTMyIGFkdmVydGlzZSkNCi17DQotCXN0cnVj dCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJp djsNCi0JdTE2IGN0bCwgYWR2Ow0KLQ0KLQkvKiBTZXR1cCBzdGFuZGFyZCBhZHZlcnRpc2UgKi8N Ci0JYWR2ID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0FEVkVSVElTRSk7DQot CWFkdiAmPSB+KEFEVkVSVElTRV9BTEwgfCBBRFZFUlRJU0VfMTAwQkFTRTQpOw0KLQlpZiAoYWR2 ZXJ0aXNlICYgQURWRVJUSVNFRF8xMGJhc2VUX0hhbGYpDQotCQlhZHYgfD0gQURWRVJUSVNFXzEw SEFMRjsNCi0JaWYgKGFkdmVydGlzZSAmIEFEVkVSVElTRURfMTBiYXNlVF9GdWxsKQ0KLQkJYWR2 IHw9IEFEVkVSVElTRV8xMEZVTEw7DQotCWlmIChhZHZlcnRpc2UgJiBBRFZFUlRJU0VEXzEwMGJh c2VUX0hhbGYpDQotCQlhZHYgfD0gQURWRVJUSVNFXzEwMEhBTEY7DQotCWlmIChhZHZlcnRpc2Ug JiBBRFZFUlRJU0VEXzEwMGJhc2VUX0Z1bGwpDQotCQlhZHYgfD0gQURWRVJUSVNFXzEwMEZVTEw7 DQotCW1kaW9fd3JpdGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQURWRVJUSVNFLCBhZHYpOw0K LQ0KLQkvKiBTdGFydC9SZXN0YXJ0IGFuZWcgKi8NCi0JY3RsID0gbWRpb19yZWFkKGRldiwgYXVw LT5waHlfYWRkciwgTUlJX0JNQ1IpOw0KLQljdGwgfD0gKEJNQ1JfQU5FTkFCTEUgfCBCTUNSX0FO UkVTVEFSVCk7DQotCW1kaW9fd3JpdGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQk1DUiwgY3Rs KTsNCi0NCi0JcmV0dXJuIDA7DQotfQ0KLQ0KLXN0YXRpYyBpbnQgYXUxMDAwX3NldHVwX2ZvcmNl ZChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgc3BlZWQsIGludCBmZCkNCi17DQotCXN0cnVj dCBhdTEwMDBfcHJpdmF0ZSAqYXVwID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJp djsNCi0JdTE2IGN0bDsNCi0NCi0JY3RsID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0JNQ1IpOw0KLQljdGwgJj0gfihCTUNSX0ZVTExEUExYIHwgQk1DUl9TUEVFRDEwMCB8IEJN Q1JfQU5FTkFCTEUpOw0KLQ0KLQkvKiBGaXJzdCByZXNldCB0aGUgUEhZICovDQotCW1kaW9fd3Jp dGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQk1DUiwgY3RsIHwgQk1DUl9SRVNFVCk7DQotDQot CS8qIFNlbGVjdCBzcGVlZCAmIGR1cGxleCAqLw0KLQlzd2l0Y2ggKHNwZWVkKSB7DQotCQljYXNl IFNQRUVEXzEwOg0KLQkJCWJyZWFrOw0KLQkJY2FzZSBTUEVFRF8xMDA6DQotCQkJY3RsIHw9IEJN Q1JfU1BFRUQxMDA7DQotCQkJYnJlYWs7DQotCQljYXNlIFNQRUVEXzEwMDA6DQotCQlkZWZhdWx0 Og0KLQkJCXJldHVybiAtRUlOVkFMOw0KLQl9DQotCWlmIChmZCA9PSBEVVBMRVhfRlVMTCkNCi0J CWN0bCB8PSBCTUNSX0ZVTExEUExYOw0KLQltZGlvX3dyaXRlKGRldiwgYXVwLT5waHlfYWRkciwg TUlJX0JNQ1IsIGN0bCk7DQotDQotCXJldHVybiAwOw0KLX0NCi0NCi0NCi1zdGF0aWMgdm9pZA0K LWF1MTAwMF9zdGFydF9saW5rKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBldGh0b29s X2NtZCAqY21kKQ0KLXsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1 MTAwMF9wcml2YXRlICopZGV2LT5wcml2Ow0KLQl1MzIgYWR2ZXJ0aXNlOw0KLQlpbnQgYXV0b25l ZzsNCi0JaW50IGZvcmNlZF9zcGVlZDsNCi0JaW50IGZvcmNlZF9kdXBsZXg7DQotDQotCS8qIERl ZmF1bHQgYWR2ZXJ0aXNlICovDQotCWFkdmVydGlzZSA9IEdFTk1JSV9ERUZBVUxUX0FEVkVSVElT RTsNCi0JYXV0b25lZyA9IGF1cC0+d2FudF9hdXRvbmVnOw0KLQlmb3JjZWRfc3BlZWQgPSBTUEVF RF8xMDA7DQotCWZvcmNlZF9kdXBsZXggPSBEVVBMRVhfRlVMTDsNCi0NCi0JLyogU2V0dXAgbGlu ayBwYXJhbWV0ZXJzICovDQotCWlmIChjbWQpIHsNCi0JCWlmIChjbWQtPmF1dG9uZWcgPT0gQVVU T05FR19FTkFCTEUpIHsNCi0JCQlhZHZlcnRpc2UgPSBjbWQtPmFkdmVydGlzaW5nOw0KLQkJCWF1 dG9uZWcgPSAxOw0KLQkJfSBlbHNlIHsNCi0JCQlhdXRvbmVnID0gMDsNCi0NCi0JCQlmb3JjZWRf c3BlZWQgPSBjbWQtPnNwZWVkOw0KLQkJCWZvcmNlZF9kdXBsZXggPSBjbWQtPmR1cGxleDsNCi0J CX0NCi0JfQ0KLQ0KLQkvKiBDb25maWd1cmUgUEhZICYgc3RhcnQgYW5lZyAqLw0KLQlhdXAtPndh bnRfYXV0b25lZyA9IGF1dG9uZWc7DQotCWlmIChhdXRvbmVnKQ0KLQkJYXUxMDAwX3NldHVwX2Fu ZWcoZGV2LCBhZHZlcnRpc2UpOw0KLQllbHNlDQotCQlhdTEwMDBfc2V0dXBfZm9yY2VkKGRldiwg Zm9yY2VkX3NwZWVkLCBmb3JjZWRfZHVwbGV4KTsNCi0JbW9kX3RpbWVyKCZhdXAtPnRpbWVyLCBq aWZmaWVzICsgSFopOw0KLX0NCisvKg0KKyAqIGV0aHRvb2wgb3BlcmF0aW9ucw0KKyAqLw0KIA0K IHN0YXRpYyBpbnQgYXUxMDAwX2dldF9zZXR0aW5ncyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBz dHJ1Y3QgZXRodG9vbF9jbWQgKmNtZCkNCiB7DQogCXN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqYXVw ID0gKHN0cnVjdCBhdTEwMDBfcHJpdmF0ZSAqKWRldi0+cHJpdjsNCi0JdTE2IGxpbmssIHNwZWVk Ow0KIA0KLQljbWQtPnN1cHBvcnRlZCA9IEdFTk1JSV9ERUZBVUxUX0ZFQVRVUkVTOw0KLQljbWQt PmFkdmVydGlzaW5nID0gR0VOTUlJX0RFRkFVTFRfQURWRVJUSVNFOw0KLQljbWQtPnBvcnQgPSBQ T1JUX01JSTsNCi0JY21kLT50cmFuc2NlaXZlciA9IFhDVlJfRVhURVJOQUw7DQotCWNtZC0+cGh5 X2FkZHJlc3MgPSBhdXAtPnBoeV9hZGRyOw0KLQlzcGluX2xvY2tfaXJxKCZhdXAtPmxvY2spOw0K LQljbWQtPmF1dG9uZWcgPSBhdXAtPndhbnRfYXV0b25lZzsNCi0JYXVwLT5waHlfb3BzLT5waHlf c3RhdHVzKGRldiwgYXVwLT5waHlfYWRkciwgJmxpbmssICZzcGVlZCk7DQotCWlmICgoc3BlZWQg PT0gSUZfUE9SVF8xMDBCQVNFVFgpIHx8IChzcGVlZCA9PSBJRl9QT1JUXzEwMEJBU0VGWCkpDQot CQljbWQtPnNwZWVkID0gU1BFRURfMTAwOw0KLQllbHNlIGlmIChzcGVlZCA9PSBJRl9QT1JUXzEw QkFTRVQpDQotCQljbWQtPnNwZWVkID0gU1BFRURfMTA7DQotCWlmIChsaW5rICYmIChkZXYtPmlm X3BvcnQgPT0gSUZfUE9SVF8xMDBCQVNFRlgpKQ0KLQkJY21kLT5kdXBsZXggPSBEVVBMRVhfRlVM TDsNCi0JZWxzZQ0KLQkJY21kLT5kdXBsZXggPSBEVVBMRVhfSEFMRjsNCi0Jc3Bpbl91bmxvY2tf aXJxKCZhdXAtPmxvY2spOw0KLQlyZXR1cm4gMDsNCisJaWYgKGF1cC0+cGh5X2RldikNCisJCXJl dHVybiBwaHlfZXRodG9vbF9nc2V0KGF1cC0+cGh5X2RldiwgY21kKTsNCisNCisJcmV0dXJuIC1F SU5WQUw7DQogfQ0KIA0KIHN0YXRpYyBpbnQgYXUxMDAwX3NldF9zZXR0aW5ncyhzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBzdHJ1Y3QgZXRodG9vbF9jbWQgKmNtZCkNCiB7DQotCSBzdHJ1Y3QgYXUx MDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnByaXY7DQot CSAgdW5zaWduZWQgbG9uZyBmZWF0dXJlcyA9IEdFTk1JSV9ERUZBVUxUX0ZFQVRVUkVTOw0KKwlz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYt PnByaXY7DQogDQotCSBpZiAoIWNhcGFibGUoQ0FQX05FVF9BRE1JTikpDQotCQkgcmV0dXJuIC1F UEVSTTsNCisJaWYgKCFjYXBhYmxlKENBUF9ORVRfQURNSU4pKQ0KKwkJcmV0dXJuIC1FUEVSTTsN CiANCi0JIGlmIChjbWQtPmF1dG9uZWcgIT0gQVVUT05FR19FTkFCTEUgJiYgY21kLT5hdXRvbmVn ICE9IEFVVE9ORUdfRElTQUJMRSkNCi0JCSByZXR1cm4gLUVJTlZBTDsNCi0JIGlmIChjbWQtPmF1 dG9uZWcgPT0gQVVUT05FR19FTkFCTEUgJiYgY21kLT5hZHZlcnRpc2luZyA9PSAwKQ0KLQkJIHJl dHVybiAtRUlOVkFMOw0KLQkgaWYgKGNtZC0+ZHVwbGV4ICE9IERVUExFWF9IQUxGICYmIGNtZC0+ ZHVwbGV4ICE9IERVUExFWF9GVUxMKQ0KLQkJIHJldHVybiAtRUlOVkFMOw0KLQkgaWYgKGNtZC0+ YXV0b25lZyA9PSBBVVRPTkVHX0RJU0FCTEUpDQotCQkgc3dpdGNoIChjbWQtPnNwZWVkKSB7DQot CQkgY2FzZSBTUEVFRF8xMDoNCi0JCQkgaWYgKGNtZC0+ZHVwbGV4ID09IERVUExFWF9IQUxGICYm DQotCQkJCSAoZmVhdHVyZXMgJiBTVVBQT1JURURfMTBiYXNlVF9IYWxmKSA9PSAwKQ0KLQkJCQkg cmV0dXJuIC1FSU5WQUw7DQotCQkJIGlmIChjbWQtPmR1cGxleCA9PSBEVVBMRVhfRlVMTCAmJg0K LQkJCQkgKGZlYXR1cmVzICYgU1VQUE9SVEVEXzEwYmFzZVRfRnVsbCkgPT0gMCkNCi0JCQkJIHJl dHVybiAtRUlOVkFMOw0KLQkJCSBicmVhazsNCi0JCSBjYXNlIFNQRUVEXzEwMDoNCi0JCQkgaWYg KGNtZC0+ZHVwbGV4ID09IERVUExFWF9IQUxGICYmDQotCQkJCSAoZmVhdHVyZXMgJiBTVVBQT1JU RURfMTAwYmFzZVRfSGFsZikgPT0gMCkNCi0JCQkJIHJldHVybiAtRUlOVkFMOw0KLQkJCSBpZiAo Y21kLT5kdXBsZXggPT0gRFVQTEVYX0ZVTEwgJiYNCi0JCQkJIChmZWF0dXJlcyAmIFNVUFBPUlRF RF8xMDBiYXNlVF9GdWxsKSA9PSAwKQ0KLQkJCQkgcmV0dXJuIC1FSU5WQUw7DQotCQkJIGJyZWFr Ow0KLQkJIGRlZmF1bHQ6DQotCQkJIHJldHVybiAtRUlOVkFMOw0KLQkJIH0NCi0JIGVsc2UgaWYg KChmZWF0dXJlcyAmIFNVUFBPUlRFRF9BdXRvbmVnKSA9PSAwKQ0KLQkJIHJldHVybiAtRUlOVkFM Ow0KLQ0KLQkgc3Bpbl9sb2NrX2lycSgmYXVwLT5sb2NrKTsNCi0JIGF1MTAwMF9zdGFydF9saW5r KGRldiwgY21kKTsNCi0JIHNwaW5fdW5sb2NrX2lycSgmYXVwLT5sb2NrKTsNCi0JIHJldHVybiAw Ow0KLX0NCisJaWYgKGF1cC0+cGh5X2RldikNCisJCXJldHVybiBwaHlfZXRodG9vbF9zc2V0KGF1 cC0+cGh5X2RldiwgY21kKTsNCiANCi1zdGF0aWMgaW50IGF1MTAwMF9ud2F5X3Jlc2V0KHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQotew0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChz dHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKilkZXYtPnByaXY7DQotDQotCWlmICghYXVwLT53YW50X2F1 dG9uZWcpDQotCQlyZXR1cm4gLUVJTlZBTDsNCi0Jc3Bpbl9sb2NrX2lycSgmYXVwLT5sb2NrKTsN Ci0JYXUxMDAwX3N0YXJ0X2xpbmsoZGV2LCBOVUxMKTsNCi0Jc3Bpbl91bmxvY2tfaXJxKCZhdXAt PmxvY2spOw0KLQlyZXR1cm4gMDsNCisJcmV0dXJuIC1FSU5WQUw7DQogfQ0KIA0KIHN0YXRpYyB2 b2lkDQpAQCAtMTQyMywxOSArNTk2LDE1IEBADQogCWluZm8tPnJlZ2R1bXBfbGVuID0gMDsNCiB9 DQogDQotc3RhdGljIHUzMiBhdTEwMDBfZ2V0X2xpbmsoc3RydWN0IG5ldF9kZXZpY2UgKmRldikN Ci17DQotCXJldHVybiBuZXRpZl9jYXJyaWVyX29rKGRldik7DQotfQ0KLQ0KIHN0YXRpYyBzdHJ1 Y3QgZXRodG9vbF9vcHMgYXUxMDAwX2V0aHRvb2xfb3BzID0gew0KIAkuZ2V0X3NldHRpbmdzID0g YXUxMDAwX2dldF9zZXR0aW5ncywNCiAJLnNldF9zZXR0aW5ncyA9IGF1MTAwMF9zZXRfc2V0dGlu Z3MsDQogCS5nZXRfZHJ2aW5mbyA9IGF1MTAwMF9nZXRfZHJ2aW5mbywNCi0JLm53YXlfcmVzZXQg PSBhdTEwMDBfbndheV9yZXNldCwNCi0JLmdldF9saW5rID0gYXUxMDAwX2dldF9saW5rDQorCS5n ZXRfbGluayA9IGV0aHRvb2xfb3BfZ2V0X2xpbmssDQogfTsNCiANCisNCisNCiBzdGF0aWMgc3Ry dWN0IG5ldF9kZXZpY2UgKg0KIGF1MTAwMF9wcm9iZSh1MzIgaW9hZGRyLCBpbnQgaXJxLCBpbnQg cG9ydF9udW0pDQogew0KQEAgLTE1MjcsMjQgKzY5NiwyMiBAQA0KIAkJcHJpbnRrKEtFUk5fRVJS ICIlczogYmFkIGlvYWRkclxuIiwgZGV2LT5uYW1lKTsNCiAJfQ0KIA0KLQkvKiBicmluZyB0aGUg ZGV2aWNlIG91dCBvZiByZXNldCwgb3RoZXJ3aXNlIHByb2JpbmcgdGhlIG1paQ0KLQkgKiB3aWxs IGhhbmcgKi8NCi0JKmF1cC0+ZW5hYmxlID0gTUFDX0VOX0NMT0NLX0VOQUJMRTsNCi0JYXVfc3lu Y19kZWxheSgyKTsNCi0JKmF1cC0+ZW5hYmxlID0gTUFDX0VOX1JFU0VUMCB8IE1BQ19FTl9SRVNF VDEgfCANCi0JCU1BQ19FTl9SRVNFVDIgfCBNQUNfRU5fQ0xPQ0tfRU5BQkxFOw0KLQlhdV9zeW5j X2RlbGF5KDIpOw0KKwkqYXVwLT5lbmFibGUgPSAwOw0KKwlhdXAtPm1hY19lbmFibGVkID0gMDsN CiANCi0JYXVwLT5taWkgPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbWlpX3BoeSksIEdGUF9LRVJO RUwpOw0KLQlpZiAoIWF1cC0+bWlpKSB7DQotCQlwcmludGsoS0VSTl9FUlIgIiVzOiBvdXQgb2Yg bWVtb3J5XG4iLCBkZXYtPm5hbWUpOw0KLQkJZ290byBlcnJfb3V0Ow0KKwlhdXAtPm1paV9idXMu cHJpdiA9IGRldjsNCisJYXVwLT5taWlfYnVzLnJlYWQgPSBtZGlvYnVzX3JlYWQ7DQorCWF1cC0+ bWlpX2J1cy53cml0ZSA9IG1kaW9idXNfd3JpdGU7DQorCWF1cC0+bWlpX2J1cy5yZXNldCA9IG1k aW9idXNfcmVzZXQ7DQorCWF1cC0+bWlpX2J1cy5uYW1lID0gImF1MTAwMF9ldGhfbWlpIjsNCisJ YXVwLT5taWlfYnVzLmlkID0gYXVwLT5tYWNfaWQ7DQorCWF1cC0+bWlpX2J1cy5pcnEgPSBrbWFs bG9jKHNpemVvZihpbnQpKlBIWV9NQVhfQUREUiwgR0ZQX0tFUk5FTCk7DQorCWZvcihpID0gMDsg aSA8IFBIWV9NQVhfQUREUjsgKytpKSB7DQorCQlhdXAtPm1paV9idXMucGh5X21hcFtpXSA9IE5V TEw7IC8qIHBhcmFub2lhICovDQorCQlhdXAtPm1paV9idXMuaXJxW2ldID0gUEhZX1BPTEw7DQog CX0NCi0JYXVwLT5taWktPm5leHQgPSBOVUxMOw0KLQlhdXAtPm1paS0+Y2hpcF9pbmZvID0gTlVM TDsNCi0JYXVwLT5taWktPnN0YXR1cyA9IDA7DQotCWF1cC0+bWlpLT5taWlfY29udHJvbF9yZWcg PSAwOw0KLQlhdXAtPm1paS0+bWlpX2RhdGFfcmVnID0gMDsNCisNCisJbWRpb2J1c19yZWdpc3Rl cigmYXVwLT5taWlfYnVzKTsNCiANCiAJaWYgKG1paV9wcm9iZShkZXYpICE9IDApIHsNCiAJCWdv dG8gZXJyX291dDsNCkBAIC0xNTkwLDcgKzc1Nyw2IEBADQogCWRldi0+c2V0X211bHRpY2FzdF9s aXN0ID0gJnNldF9yeF9tb2RlOw0KIAlkZXYtPmRvX2lvY3RsID0gJmF1MTAwMF9pb2N0bDsNCiAJ U0VUX0VUSFRPT0xfT1BTKGRldiwgJmF1MTAwMF9ldGh0b29sX29wcyk7DQotCWRldi0+c2V0X2Nv bmZpZyA9ICZhdTEwMDBfc2V0X2NvbmZpZzsNCiAJZGV2LT50eF90aW1lb3V0ID0gYXUxMDAwX3R4 X3RpbWVvdXQ7DQogCWRldi0+d2F0Y2hkb2dfdGltZW8gPSBFVEhfVFhfVElNRU9VVDsNCiANCkBA IC0xNjA2LDcgKzc3Miw3IEBADQogCS8qIGhlcmUgd2Ugc2hvdWxkIGhhdmUgYSB2YWxpZCBkZXYg cGx1cyBhdXAtPiByZWdpc3RlciBhZGRyZXNzZXMNCiAJICogc28gd2UgY2FuIHJlc2V0IHRoZSBt YWMgcHJvcGVybHkuKi8NCiAJcmVzZXRfbWFjKGRldik7DQotCWtmcmVlKGF1cC0+bWlpKTsNCisN CiAJZm9yIChpID0gMDsgaSA8IE5VTV9SWF9ETUE7IGkrKykgew0KIAkJaWYgKGF1cC0+cnhfZGJf aW51c2VbaV0pDQogCQkJUmVsZWFzZURCKGF1cCwgYXVwLT5yeF9kYl9pbnVzZVtpXSk7DQpAQCAt MTY0MCwxOSArODA2LDE0IEBADQogCXUzMiBmbGFnczsNCiAJaW50IGk7DQogCXUzMiBjb250cm9s Ow0KLQl1MTYgbGluaywgc3BlZWQ7DQogDQogCWlmIChhdTEwMDBfZGVidWcgPiA0KSANCiAJCXBy aW50aygiJXM6IGF1MTAwMF9pbml0XG4iLCBkZXYtPm5hbWUpOw0KIA0KLQlzcGluX2xvY2tfaXJx c2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQotDQogCS8qIGJyaW5nIHRoZSBkZXZpY2Ugb3V0IG9m IHJlc2V0ICovDQotCSphdXAtPmVuYWJsZSA9IE1BQ19FTl9DTE9DS19FTkFCTEU7DQotICAgICAg ICBhdV9zeW5jX2RlbGF5KDIpOw0KLQkqYXVwLT5lbmFibGUgPSBNQUNfRU5fUkVTRVQwIHwgTUFD X0VOX1JFU0VUMSB8IA0KLQkJTUFDX0VOX1JFU0VUMiB8IE1BQ19FTl9DTE9DS19FTkFCTEU7DQot CWF1X3N5bmNfZGVsYXkoMjApOw0KKwllbmFibGVfbWFjKGRldiwgMSk7DQorDQorCXNwaW5fbG9j a19pcnFzYXZlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCiANCiAJYXVwLT5tYWMtPmNvbnRyb2wgPSAw Ow0KIAlhdXAtPnR4X2hlYWQgPSAoYXVwLT50eF9kbWFfcmluZ1swXS0+YnVmZl9zdGF0ICYgMHhD KSA+PiAyOw0KQEAgLTE2NjgsMTIgKzgyOSwxNiBAQA0KIAl9DQogCWF1X3N5bmMoKTsNCiANCi0J YXVwLT5waHlfb3BzLT5waHlfc3RhdHVzKGRldiwgYXVwLT5waHlfYWRkciwgJmxpbmssICZzcGVl ZCk7DQotCWNvbnRyb2wgPSBNQUNfRElTQUJMRV9SWF9PV04gfCBNQUNfUlhfRU5BQkxFIHwgTUFD X1RYX0VOQUJMRTsNCisJY29udHJvbCA9IE1BQ19SWF9FTkFCTEUgfCBNQUNfVFhfRU5BQkxFOw0K ICNpZm5kZWYgQ09ORklHX0NQVV9MSVRUTEVfRU5ESUFODQogCWNvbnRyb2wgfD0gTUFDX0JJR19F TkRJQU47DQogI2VuZGlmDQotCWlmIChsaW5rICYmIChkZXYtPmlmX3BvcnQgPT0gSUZfUE9SVF8x MDBCQVNFRlgpKSB7DQorCWlmIChhdXAtPnBoeV9kZXYpIHsNCisJCWlmIChhdXAtPnBoeV9kZXYt PmxpbmsgJiYgKERVUExFWF9GVUxMID09IGF1cC0+cGh5X2Rldi0+ZHVwbGV4KSkNCisJCQljb250 cm9sIHw9IE1BQ19GVUxMX0RVUExFWDsNCisJCWVsc2UNCisJCQljb250cm9sIHw9IE1BQ19ESVNB QkxFX1JYX09XTjsNCisJfSBlbHNlIHsgLyogUEhZLWxlc3Mgb3AsIGFzc3VtZSBmdWxsLWR1cGxl eCAqLw0KIAkJY29udHJvbCB8PSBNQUNfRlVMTF9EVVBMRVg7DQogCX0NCiANCkBAIC0xNjg1LDU3 ICs4NTAsODQgQEANCiAJcmV0dXJuIDA7DQogfQ0KIA0KLXN0YXRpYyB2b2lkIGF1MTAwMF90aW1l cih1bnNpZ25lZCBsb25nIGRhdGEpDQorc3RhdGljIHZvaWQNCithdTEwMDBfYWRqdXN0X2xpbmso c3RydWN0IG5ldF9kZXZpY2UgKmRldikNCiB7DQotCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSAo c3RydWN0IG5ldF9kZXZpY2UgKilkYXRhOw0KIAlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9 IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KLQl1bnNpZ25lZCBjaGFyIGlm X3BvcnQ7DQotCXUxNiBsaW5rLCBzcGVlZDsNCisJc3RydWN0IHBoeV9kZXZpY2UgKnBoeWRldiA9 IGF1cC0+cGh5X2RldjsNCisJdW5zaWduZWQgbG9uZyBmbGFnczsNCiANCi0JaWYgKCFkZXYpIHsN Ci0JCS8qIGZhdGFsIGVycm9yLCBkb24ndCByZXN0YXJ0IHRoZSB0aW1lciAqLw0KLQkJcHJpbnRr KEtFUk5fRVJSICJhdTEwMDBfdGltZXIgZXJyb3I6IE5VTEwgZGV2XG4iKTsNCi0JCXJldHVybjsN Ci0JfQ0KKwlpbnQgc3RhdHVzX2NoYW5nZSA9IDA7DQogDQotCWlmX3BvcnQgPSBkZXYtPmlmX3Bv cnQ7DQotCWlmIChhdXAtPnBoeV9vcHMtPnBoeV9zdGF0dXMoZGV2LCBhdXAtPnBoeV9hZGRyLCAm bGluaywgJnNwZWVkKSA9PSAwKSB7DQotCQlpZiAobGluaykgew0KLQkJCWlmICghbmV0aWZfY2Fy cmllcl9vayhkZXYpKSB7DQotCQkJCW5ldGlmX2NhcnJpZXJfb24oZGV2KTsNCi0JCQkJcHJpbnRr KEtFUk5fSU5GTyAiJXM6IGxpbmsgdXBcbiIsIGRldi0+bmFtZSk7DQotCQkJfQ0KLQkJfQ0KLQkJ ZWxzZSB7DQotCQkJaWYgKG5ldGlmX2NhcnJpZXJfb2soZGV2KSkgew0KLQkJCQluZXRpZl9jYXJy aWVyX29mZihkZXYpOw0KLQkJCQlkZXYtPmlmX3BvcnQgPSAwOw0KLQkJCQlwcmludGsoS0VSTl9J TkZPICIlczogbGluayBkb3duXG4iLCBkZXYtPm5hbWUpOw0KLQkJCX0NCisJQlVHX09OKCFhdXAt PnBoeV9kZXYpOw0KKw0KKwlzcGluX2xvY2tfaXJxc2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQor DQorCWlmIChwaHlkZXYtPmxpbmsgJiYgKGF1cC0+b2xkX3NwZWVkICE9IHBoeWRldi0+c3BlZWQp KSB7DQorCQkvLyBzcGVlZCBjaGFuZ2VkDQorDQorCQlzd2l0Y2gocGh5ZGV2LT5zcGVlZCkgew0K KwkJY2FzZSBTUEVFRF8xMDoNCisJCWNhc2UgU1BFRURfMTAwOg0KKwkJCWJyZWFrOw0KKwkJZGVm YXVsdDoNCisJCQlwcmludGsoS0VSTl9XQVJOSU5HDQorCQkJICAgICAgICIlczogU3BlZWQgKCVk KSBpcyBub3QgMTAvMTAwID8/P1xuIiwNCisJCQkgICAgICAgZGV2LT5uYW1lLCBwaHlkZXYtPnNw ZWVkKTsNCisJCQlicmVhazsNCiAJCX0NCisNCisJCWF1cC0+b2xkX3NwZWVkID0gcGh5ZGV2LT5z cGVlZDsNCisNCisJCXN0YXR1c19jaGFuZ2UgPSAxOw0KIAl9DQogDQotCWlmIChsaW5rICYmIChk ZXYtPmlmX3BvcnQgIT0gaWZfcG9ydCkgJiYgDQotCQkJKGRldi0+aWZfcG9ydCAhPSBJRl9QT1JU X1VOS05PV04pKSB7DQorCWlmIChwaHlkZXYtPmxpbmsgJiYgKGF1cC0+b2xkX2R1cGxleCAhPSBw aHlkZXYtPmR1cGxleCkpIHsNCisJCS8vIGR1cGxleCBtb2RlIGNoYW5nZWQNCisNCisJCS8qIHN3 aXRjaGluZyBkdXBsZXggbW9kZSByZXF1aXJlcyB0byBkaXNhYmxlIHJ4IGFuZCB0eCEgKi8NCiAJ CWhhcmRfc3RvcChkZXYpOw0KLQkJaWYgKGRldi0+aWZfcG9ydCA9PSBJRl9QT1JUXzEwMEJBU0VG WCkgew0KLQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBnb2luZyB0byBmdWxsIGR1cGxleFxuIiwg DQotCQkJCQlkZXYtPm5hbWUpOw0KLQkJCWF1cC0+bWFjLT5jb250cm9sIHw9IE1BQ19GVUxMX0RV UExFWDsNCi0JCQlhdV9zeW5jX2RlbGF5KDEpOw0KLQkJfQ0KLQkJZWxzZSB7DQotCQkJYXVwLT5t YWMtPmNvbnRyb2wgJj0gfk1BQ19GVUxMX0RVUExFWDsNCi0JCQlhdV9zeW5jX2RlbGF5KDEpOw0K LQkJfQ0KKw0KKwkJaWYgKERVUExFWF9GVUxMID09IHBoeWRldi0+ZHVwbGV4KQ0KKwkJCWF1cC0+ bWFjLT5jb250cm9sID0gKChhdXAtPm1hYy0+Y29udHJvbA0KKwkJCQkJICAgICB8IE1BQ19GVUxM X0RVUExFWCkNCisJCQkJCSAgICAgJiB+TUFDX0RJU0FCTEVfUlhfT1dOKTsNCisJCWVsc2UNCisJ CQlhdXAtPm1hYy0+Y29udHJvbCA9ICgoYXVwLT5tYWMtPmNvbnRyb2wNCisJCQkJCSAgICAgICYg fk1BQ19GVUxMX0RVUExFWCkNCisJCQkJCSAgICAgfCBNQUNfRElTQUJMRV9SWF9PV04pOw0KKwkJ YXVfc3luY19kZWxheSgxKTsNCisNCiAJCWVuYWJsZV9yeF90eChkZXYpOw0KKwkJYXVwLT5vbGRf ZHVwbGV4ID0gcGh5ZGV2LT5kdXBsZXg7DQorDQorCQlzdGF0dXNfY2hhbmdlID0gMTsNCisJfQ0K Kw0KKwlpZihwaHlkZXYtPmxpbmsgIT0gYXVwLT5vbGRfbGluaykgew0KKwkJLy8gbGluayBzdGF0 ZSBjaGFuZ2VkDQorDQorCQlpZiAocGh5ZGV2LT5saW5rKSAvLyBsaW5rIHdlbnQgdXANCisJCQlu ZXRpZl9zY2hlZHVsZShkZXYpOw0KKwkJZWxzZSB7IC8vIGxpbmsgd2VudCBkb3duDQorCQkJYXVw LT5vbGRfc3BlZWQgPSAwOw0KKwkJCWF1cC0+b2xkX2R1cGxleCA9IC0xOw0KKwkJfQ0KKw0KKwkJ YXVwLT5vbGRfbGluayA9IHBoeWRldi0+bGluazsNCisJCXN0YXR1c19jaGFuZ2UgPSAxOw0KIAl9 DQogDQotCWF1cC0+dGltZXIuZXhwaXJlcyA9IFJVTl9BVCgoMSpIWikpOyANCi0JYXVwLT50aW1l ci5kYXRhID0gKHVuc2lnbmVkIGxvbmcpZGV2Ow0KLQlhdXAtPnRpbWVyLmZ1bmN0aW9uID0gJmF1 MTAwMF90aW1lcjsgLyogdGltZXIgaGFuZGxlciAqLw0KLQlhZGRfdGltZXIoJmF1cC0+dGltZXIp Ow0KKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZhdXAtPmxvY2ssIGZsYWdzKTsNCiANCisJaWYg KHN0YXR1c19jaGFuZ2UpIHsNCisJCWlmIChwaHlkZXYtPmxpbmspDQorCQkJcHJpbnRrKEtFUk5f SU5GTyAiJXM6IGxpbmsgdXAgKCVkLyVzKVxuIiwNCisJCQkgICAgICAgZGV2LT5uYW1lLCBwaHlk ZXYtPnNwZWVkLA0KKwkJCSAgICAgICBEVVBMRVhfRlVMTCA9PSBwaHlkZXYtPmR1cGxleCA/ICJG dWxsIiA6ICJIYWxmIik7DQorCQllbHNlDQorCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IGxpbmsg ZG93blxuIiwgZGV2LT5uYW1lKTsNCisJfQ0KIH0NCiANCiBzdGF0aWMgaW50IGF1MTAwMF9vcGVu KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQpAQCAtMTc0NiwyNSArOTM4LDI2IEBADQogCWlmIChh dTEwMDBfZGVidWcgPiA0KQ0KIAkJcHJpbnRrKCIlczogb3BlbjogZGV2PSVwXG4iLCBkZXYtPm5h bWUsIGRldik7DQogDQorCWlmICgocmV0dmFsID0gcmVxdWVzdF9pcnEoZGV2LT5pcnEsICZhdTEw MDBfaW50ZXJydXB0LCAwLA0KKwkJCQkJZGV2LT5uYW1lLCBkZXYpKSkgew0KKwkJcHJpbnRrKEtF Uk5fRVJSICIlczogdW5hYmxlIHRvIGdldCBJUlEgJWRcbiIsDQorCQkJCWRldi0+bmFtZSwgZGV2 LT5pcnEpOw0KKwkJcmV0dXJuIHJldHZhbDsNCisJfQ0KKw0KIAlpZiAoKHJldHZhbCA9IGF1MTAw MF9pbml0KGRldikpKSB7DQogCQlwcmludGsoS0VSTl9FUlIgIiVzOiBlcnJvciBpbiBhdTEwMDBf aW5pdFxuIiwgZGV2LT5uYW1lKTsNCiAJCWZyZWVfaXJxKGRldi0+aXJxLCBkZXYpOw0KIAkJcmV0 dXJuIHJldHZhbDsNCiAJfQ0KLQluZXRpZl9zdGFydF9xdWV1ZShkZXYpOw0KIA0KLQlpZiAoKHJl dHZhbCA9IHJlcXVlc3RfaXJxKGRldi0+aXJxLCAmYXUxMDAwX2ludGVycnVwdCwgMCwgDQotCQkJ CQlkZXYtPm5hbWUsIGRldikpKSB7DQotCQlwcmludGsoS0VSTl9FUlIgIiVzOiB1bmFibGUgdG8g Z2V0IElSUSAlZFxuIiwgDQotCQkJCWRldi0+bmFtZSwgZGV2LT5pcnEpOw0KLQkJcmV0dXJuIHJl dHZhbDsNCisJaWYgKGF1cC0+cGh5X2Rldikgew0KKwkJLyogY2F1c2UgdGhlIFBIWSBzdGF0ZSBt YWNoaW5lIHRvIHNjaGVkdWxlIGEgbGluayBzdGF0ZSBjaGVjayAqLw0KKwkJYXVwLT5waHlfZGV2 LT5zdGF0ZSA9IFBIWV9DSEFOR0VMSU5LOw0KKwkJcGh5X3N0YXJ0KGF1cC0+cGh5X2Rldik7DQog CX0NCiANCi0JaW5pdF90aW1lcigmYXVwLT50aW1lcik7IC8qIHVzZWQgaW4gaW9jdGwoKSAqLw0K LQlhdXAtPnRpbWVyLmV4cGlyZXMgPSBSVU5fQVQoKDMqSFopKTsgDQotCWF1cC0+dGltZXIuZGF0 YSA9ICh1bnNpZ25lZCBsb25nKWRldjsNCi0JYXVwLT50aW1lci5mdW5jdGlvbiA9ICZhdTEwMDBf dGltZXI7IC8qIHRpbWVyIGhhbmRsZXIgKi8NCi0JYWRkX3RpbWVyKCZhdXAtPnRpbWVyKTsNCisJ bmV0aWZfc3RhcnRfcXVldWUoZGV2KTsNCiANCiAJaWYgKGF1MTAwMF9kZWJ1ZyA+IDQpDQogCQlw cmludGsoIiVzOiBvcGVuOiBJbml0aWFsaXphdGlvbiBkb25lLlxuIiwgZGV2LT5uYW1lKTsNCkBA IC0xNzc0LDE2ICs5NjcsMTkgQEANCiANCiBzdGF0aWMgaW50IGF1MTAwMF9jbG9zZShzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2KQ0KIHsNCi0JdTMyIGZsYWdzOw0KLQlzdHJ1Y3QgYXUxMDAwX3ByaXZh dGUgKmF1cCA9IChzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KKwl1bnNpZ25l ZCBsb25nIGZsYWdzOw0KKwlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmNvbnN0IGF1cCA9IChzdHJ1 Y3QgYXUxMDAwX3ByaXZhdGUgKikgZGV2LT5wcml2Ow0KIA0KIAlpZiAoYXUxMDAwX2RlYnVnID4g NCkNCiAJCXByaW50aygiJXM6IGNsb3NlOiBkZXY9JXBcbiIsIGRldi0+bmFtZSwgZGV2KTsNCiAN Ci0JcmVzZXRfbWFjKGRldik7DQorCWlmIChhdXAtPnBoeV9kZXYpDQorCQlwaHlfc3RvcChhdXAt PnBoeV9kZXYpOw0KIA0KIAlzcGluX2xvY2tfaXJxc2F2ZSgmYXVwLT5sb2NrLCBmbGFncyk7DQot CQ0KKw0KKwlyZXNldF9tYWNfdW5sb2NrZWQgKGRldik7DQorDQogCS8qIHN0b3AgdGhlIGRldmlj ZSAqLw0KIAluZXRpZl9zdG9wX3F1ZXVlKGRldik7DQogDQpAQCAtMTgwNSw3ICsxMDAxLDcgQEAN CiAJCWlmIChkZXYpIHsNCiAJCQlhdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRlICopIGRldi0+ cHJpdjsNCiAJCQl1bnJlZ2lzdGVyX25ldGRldihkZXYpOw0KLQkJCWtmcmVlKGF1cC0+bWlpKTsN CisNCiAJCQlmb3IgKGogPSAwOyBqIDwgTlVNX1JYX0RNQTsgaisrKSB7DQogCQkJCWlmIChhdXAt PnJ4X2RiX2ludXNlW2pdKQ0KIAkJCQkJUmVsZWFzZURCKGF1cCwgYXVwLT5yeF9kYl9pbnVzZVtq XSk7DQpAQCAtMTgzMCw3ICsxMDI2LDcgQEANCiAJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnBz ID0gJmF1cC0+c3RhdHM7DQogDQogCWlmIChzdGF0dXMgJiBUWF9GUkFNRV9BQk9SVEVEKSB7DQot CQlpZiAoZGV2LT5pZl9wb3J0ID09IElGX1BPUlRfMTAwQkFTRUZYKSB7DQorCQlpZiAoIWF1cC0+ cGh5X2RldiB8fCAoRFVQTEVYX0ZVTEwgPT0gYXVwLT5waHlfZGV2LT5kdXBsZXgpKSB7DQogCQkJ aWYgKHN0YXR1cyAmIChUWF9KQUJfVElNRU9VVCB8IFRYX1VOREVSUlVOKSkgew0KIAkJCQkvKiBh bnkgb3RoZXIgdHggZXJyb3JzIGFyZSBvbmx5IHZhbGlkDQogCQkJCSAqIGluIGhhbGYgZHVwbGV4 IG1vZGUgKi8NCkBAIC0yMTA0LDEyNiArMTMwMCwxNSBAQA0KIAl9DQogfQ0KIA0KLQ0KIHN0YXRp YyBpbnQgYXUxMDAwX2lvY3RsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpZnJlcSAq cnEsIGludCBjbWQpDQogew0KIAlzdHJ1Y3QgYXUxMDAwX3ByaXZhdGUgKmF1cCA9IChzdHJ1Y3Qg YXUxMDAwX3ByaXZhdGUgKilkZXYtPnByaXY7DQotCXUxNiAqZGF0YSA9ICh1MTYgKikmcnEtPmlm cl9pZnJ1Ow0KIA0KLQlzd2l0Y2goY21kKSB7IA0KLQkJY2FzZSBTSU9DREVWUFJJVkFURToJLyog R2V0IHRoZSBhZGRyZXNzIG9mIHRoZSBQSFkgaW4gdXNlLiAqLw0KLQkJY2FzZSBTSU9DR01JSVBI WToNCi0JCSAgICAgICAgaWYgKCFuZXRpZl9ydW5uaW5nKGRldikpIHJldHVybiAtRUlOVkFMOw0K LQkJCWRhdGFbMF0gPSBhdXAtPnBoeV9hZGRyOw0KLQkJY2FzZSBTSU9DREVWUFJJVkFURSsxOgkv KiBSZWFkIHRoZSBzcGVjaWZpZWQgTUlJIHJlZ2lzdGVyLiAqLw0KLQkJY2FzZSBTSU9DR01JSVJF RzoNCi0JCQlkYXRhWzNdID0gIG1kaW9fcmVhZChkZXYsIGRhdGFbMF0sIGRhdGFbMV0pOyANCi0J CQlyZXR1cm4gMDsNCi0JCWNhc2UgU0lPQ0RFVlBSSVZBVEUrMjoJLyogV3JpdGUgdGhlIHNwZWNp ZmllZCBNSUkgcmVnaXN0ZXIgKi8NCi0JCWNhc2UgU0lPQ1NNSUlSRUc6IA0KLQkJCWlmICghY2Fw YWJsZShDQVBfTkVUX0FETUlOKSkNCi0JCQkJcmV0dXJuIC1FUEVSTTsNCi0JCQltZGlvX3dyaXRl KGRldiwgZGF0YVswXSwgZGF0YVsxXSxkYXRhWzJdKTsNCi0JCQlyZXR1cm4gMDsNCi0JCWRlZmF1 bHQ6DQotCQkJcmV0dXJuIC1FT1BOT1RTVVBQOw0KLQl9DQorCWlmICghbmV0aWZfcnVubmluZyhk ZXYpKSByZXR1cm4gLUVJTlZBTDsNCiANCi19DQorCWlmICghYXVwLT5waHlfZGV2KSByZXR1cm4g LUVJTlZBTDsgLy8gUEhZIG5vdCBjb250cm9sbGFibGUNCiANCi0NCi1zdGF0aWMgaW50IGF1MTAw MF9zZXRfY29uZmlnKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpZm1hcCAqbWFwKQ0K LXsNCi0Jc3RydWN0IGF1MTAwMF9wcml2YXRlICphdXAgPSAoc3RydWN0IGF1MTAwMF9wcml2YXRl ICopIGRldi0+cHJpdjsNCi0JdTE2IGNvbnRyb2w7DQotDQotCWlmIChhdTEwMDBfZGVidWcgPiA0 KSAgew0KLQkJcHJpbnRrKCIlczogc2V0X2NvbmZpZyBjYWxsZWQ6IGRldi0+aWZfcG9ydCAlZCBt YXAtPnBvcnQgJXhcbiIsIA0KLQkJCQlkZXYtPm5hbWUsIGRldi0+aWZfcG9ydCwgbWFwLT5wb3J0 KTsNCi0JfQ0KLQ0KLQlzd2l0Y2gobWFwLT5wb3J0KXsNCi0JCWNhc2UgSUZfUE9SVF9VTktOT1dO OiAvKiB1c2UgYXV0byBoZXJlICovICAgDQotCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IGNvbmZp ZyBwaHkgZm9yIGFuZWdcbiIsIA0KLQkJCQkJZGV2LT5uYW1lKTsNCi0JCQlkZXYtPmlmX3BvcnQg PSBtYXAtPnBvcnQ7DQotCQkJLyogTGluayBEb3duOiB0aGUgdGltZXIgd2lsbCBicmluZyBpdCB1 cCAqLw0KLQkJCW5ldGlmX2NhcnJpZXJfb2ZmKGRldik7DQotCQ0KLQkJCS8qIHJlYWQgY3VycmVu dCBjb250cm9sICovDQotCQkJY29udHJvbCA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIs IE1JSV9DT05UUk9MKTsNCi0JCQljb250cm9sICY9IH4oTUlJX0NOVExfRkRYIHwgTUlJX0NOVExf RjEwMCk7DQotDQotCQkJLyogZW5hYmxlIGF1dG8gbmVnb3RpYXRpb24gYW5kIHJlc2V0IHRoZSBu ZWdvdGlhdGlvbiAqLw0KLQkJCW1kaW9fd3JpdGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQ09O VFJPTCwgDQotCQkJCQljb250cm9sIHwgTUlJX0NOVExfQVVUTyB8IA0KLQkJCQkJTUlJX0NOVExf UlNUX0FVVE8pOw0KLQ0KLQkJCWJyZWFrOw0KLSAgICANCi0JCWNhc2UgSUZfUE9SVF8xMEJBU0VU OiAvKiAxMEJhc2VUICovICAgICAgICAgDQotCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IGNvbmZp ZyBwaHkgZm9yIDEwQmFzZVRcbiIsIA0KLQkJCQkJZGV2LT5uYW1lKTsNCi0JCQlkZXYtPmlmX3Bv cnQgPSBtYXAtPnBvcnQ7DQotCQ0KLQkJCS8qIExpbmsgRG93bjogdGhlIHRpbWVyIHdpbGwgYnJp bmcgaXQgdXAgKi8NCi0JCQluZXRpZl9jYXJyaWVyX29mZihkZXYpOw0KLQ0KLQkJCS8qIHNldCBT cGVlZCB0byAxME1icHMsIEhhbGYgRHVwbGV4ICovDQotCQkJY29udHJvbCA9IG1kaW9fcmVhZChk ZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCQljb250cm9sICY9IH4oTUlJX0NO VExfRjEwMCB8IE1JSV9DTlRMX0FVVE8gfCANCi0JCQkJCU1JSV9DTlRMX0ZEWCk7DQotCQ0KLQkJ CS8qIGRpc2FibGUgYXV0byBuZWdvdGlhdGlvbiBhbmQgZm9yY2UgMTBNL0hEIG1vZGUqLw0KLQkJ CW1kaW9fd3JpdGUoZGV2LCBhdXAtPnBoeV9hZGRyLCBNSUlfQ09OVFJPTCwgY29udHJvbCk7DQot CQkJYnJlYWs7DQotICAgIA0KLQkJY2FzZSBJRl9QT1JUXzEwMEJBU0VUOiAvKiAxMDBCYXNlVCAq Lw0KLQkJY2FzZSBJRl9QT1JUXzEwMEJBU0VUWDogLyogMTAwQmFzZVR4ICovIA0KLQkJCXByaW50 ayhLRVJOX0lORk8gIiVzOiBjb25maWcgcGh5IGZvciAxMDBCYXNlVFhcbiIsIA0KLQkJCQkJZGV2 LT5uYW1lKTsNCi0JCQlkZXYtPmlmX3BvcnQgPSBtYXAtPnBvcnQ7DQotCQ0KLQkJCS8qIExpbmsg RG93bjogdGhlIHRpbWVyIHdpbGwgYnJpbmcgaXQgdXAgKi8NCi0JCQluZXRpZl9jYXJyaWVyX29m ZihkZXYpOw0KLQkNCi0JCQkvKiBzZXQgU3BlZWQgdG8gMTAwTWJwcywgSGFsZiBEdXBsZXggKi8N Ci0JCQkvKiBkaXNhYmxlIGF1dG8gbmVnb3RpYXRpb24gYW5kIGVuYWJsZSAxMDBNQml0IE1vZGUg Ki8NCi0JCQljb250cm9sID0gbWRpb19yZWFkKGRldiwgYXVwLT5waHlfYWRkciwgTUlJX0NPTlRS T0wpOw0KLQkJCWNvbnRyb2wgJj0gfihNSUlfQ05UTF9BVVRPIHwgTUlJX0NOVExfRkRYKTsNCi0J CQljb250cm9sIHw9IE1JSV9DTlRMX0YxMDA7DQotCQkJbWRpb193cml0ZShkZXYsIGF1cC0+cGh5 X2FkZHIsIE1JSV9DT05UUk9MLCBjb250cm9sKTsNCi0JCQlicmVhazsNCi0gICAgDQotCQljYXNl IElGX1BPUlRfMTAwQkFTRUZYOiAvKiAxMDBCYXNlRnggKi8NCi0JCQlwcmludGsoS0VSTl9JTkZP ICIlczogY29uZmlnIHBoeSBmb3IgMTAwQmFzZUZYXG4iLCANCi0JCQkJCWRldi0+bmFtZSk7DQot CQkJZGV2LT5pZl9wb3J0ID0gbWFwLT5wb3J0Ow0KLQkNCi0JCQkvKiBMaW5rIERvd246IHRoZSB0 aW1lciB3aWxsIGJyaW5nIGl0IHVwICovDQotCQkJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsNCi0J DQotCQkJLyogc2V0IFNwZWVkIHRvIDEwME1icHMsIEZ1bGwgRHVwbGV4ICovDQotCQkJLyogZGlz YWJsZSBhdXRvIG5lZ290aWF0aW9uIGFuZCBlbmFibGUgMTAwTUJpdCBNb2RlICovDQotCQkJY29u dHJvbCA9IG1kaW9fcmVhZChkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9DT05UUk9MKTsNCi0JCQlj b250cm9sICY9IH5NSUlfQ05UTF9BVVRPOw0KLQkJCWNvbnRyb2wgfD0gIE1JSV9DTlRMX0YxMDAg fCBNSUlfQ05UTF9GRFg7DQotCQkJbWRpb193cml0ZShkZXYsIGF1cC0+cGh5X2FkZHIsIE1JSV9D T05UUk9MLCBjb250cm9sKTsNCi0JCQlicmVhazsNCi0JCWNhc2UgSUZfUE9SVF8xMEJBU0UyOiAv KiAxMEJhc2UyICovDQotCQljYXNlIElGX1BPUlRfQVVJOiAvKiBBVUkgKi8NCi0JCS8qIFRoZXNl IE1vZGVzIGFyZSBub3Qgc3VwcG9ydGVkIChhcmUgdGhleT8pKi8NCi0JCQlwcmludGsoS0VSTl9F UlIgIiVzOiAxMEJhc2UyL0FVSSBub3Qgc3VwcG9ydGVkIiwgDQotCQkJCQlkZXYtPm5hbWUpOw0K LQkJCXJldHVybiAtRU9QTk9UU1VQUDsNCi0JCQlicmVhazsNCi0gICAgDQotCQlkZWZhdWx0Og0K LQkJCXByaW50ayhLRVJOX0VSUiAiJXM6IEludmFsaWQgbWVkaWEgc2VsZWN0ZWQiLCANCi0JCQkJ CWRldi0+bmFtZSk7DQotCQkJcmV0dXJuIC1FSU5WQUw7DQotCX0NCi0JcmV0dXJuIDA7DQorCXJl dHVybiBwaHlfbWlpX2lvY3RsKGF1cC0+cGh5X2RldiwgaWZfbWlpKHJxKSwgY21kKTsNCiB9DQog DQogc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICphdTEwMDBfZ2V0X3N0YXRzKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYpDQpJbmRleDogZ3cxNTUwa2VybmVsL2RyaXZlcnMvbmV0L2F1MTAw MF9ldGguaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KLS0tIGd3MTU1MGtlcm5lbC5vcmlnL2RyaXZlcnMvbmV0L2F1 MTAwMF9ldGguaAkyMDA2LTA1LTA5IDAzOjAxOjQ1LjAwMDAwMDAwMCArMDIwMA0KKysrIGd3MTU1 MGtlcm5lbC9kcml2ZXJzL25ldC9hdTEwMDBfZXRoLmgJMjAwNi0wNS0wOSAwMzoyMToxOS4wMDAw MDAwMDAgKzAyMDANCkBAIC00MCwxMjAgKzQwLDYgQEANCiANCiAjZGVmaW5lIE1VTFRJQ0FTVF9G SUxURVJfTElNSVQgNjQNCiANCi0vKiBGSVhNRSANCi0gKiBUaGUgUEhZIGRlZmluZXMgc2hvdWxk IGJlIGluIGEgc2VwYXJhdGUgZmlsZS4NCi0gKi8NCi0NCi0vKiBNSUkgcmVnaXN0ZXIgb2Zmc2V0 cyAqLw0KLSNkZWZpbmUJTUlJX0NPTlRST0wgMHgwMDAwDQotI2RlZmluZSBNSUlfU1RBVFVTICAw eDAwMDENCi0jZGVmaW5lIE1JSV9QSFlfSUQwIDB4MDAwMg0KLSNkZWZpbmUJTUlJX1BIWV9JRDEg MHgwMDAzDQotI2RlZmluZSBNSUlfQU5BRFYgICAweDAwMDQNCi0jZGVmaW5lIE1JSV9BTkxQQVIg IDB4MDAwNQ0KLSNkZWZpbmUgTUlJX0FFWFAgICAgMHgwMDA2DQotI2RlZmluZSBNSUlfQU5FWFQg ICAweDAwMDcNCi0jZGVmaW5lIE1JSV9MU0lfUEhZX0NPTkZJRyAweDAwMTENCi0vKiBTdGF0dXMg cmVnaXN0ZXIgKi8NCi0jZGVmaW5lIE1JSV9MU0lfUEhZX1NUQVQgICAweDAwMTINCi0jZGVmaW5l IE1JSV9BTURfUEhZX1NUQVQgICBNSUlfTFNJX1BIWV9TVEFUDQotI2RlZmluZSBNSUlfSU5URUxf UEhZX1NUQVQgMHgwMDExDQotDQotI2RlZmluZSBNSUlfQVVYX0NOVFJMICAweDAwMTgNCi0vKiBt aWkgcmVnaXN0ZXJzIHNwZWNpZmljIHRvIEFNRCA3OUM5MDEgKi8NCi0jZGVmaW5lCU1JSV9TVEFU VVNfU1VNTUFSWSA9IDB4MDAxOA0KLQ0KLS8qIE1JSSBDb250cm9sIHJlZ2lzdGVyIGJpdCBkZWZp bml0aW9ucy4gKi8NCi0jZGVmaW5lCU1JSV9DTlRMX0ZEWCAgICAgIDB4MDEwMA0KLSNkZWZpbmUg TUlJX0NOVExfUlNUX0FVVE8gMHgwMjAwDQotI2RlZmluZQlNSUlfQ05UTF9JU09MQVRFICAweDA0 MDANCi0jZGVmaW5lIE1JSV9DTlRMX1BXUkRXTiAgIDB4MDgwMA0KLSNkZWZpbmUJTUlJX0NOVExf QVVUTyAgICAgMHgxMDAwDQotI2RlZmluZSBNSUlfQ05UTF9GMTAwICAgICAweDIwMDANCi0jZGVm aW5lCU1JSV9DTlRMX0xQQksgICAgIDB4NDAwMA0KLSNkZWZpbmUgTUlJX0NOVExfUkVTRVQgICAg MHg4MDAwDQotDQotLyogTUlJIFN0YXR1cyByZWdpc3RlciBiaXQgICovDQotI2RlZmluZQlNSUlf U1RBVF9FWFQgICAgICAgIDB4MDAwMSANCi0jZGVmaW5lIE1JSV9TVEFUX0pBQiAgICAgICAgMHgw MDAyDQotI2RlZmluZQlNSUlfU1RBVF9MSU5LICAgICAgIDB4MDAwNA0KLSNkZWZpbmUgTUlJX1NU QVRfQ0FOX0FVVE8gICAweDAwMDgNCi0jZGVmaW5lCU1JSV9TVEFUX0ZBVUxUICAgICAgMHgwMDEw IA0KLSNkZWZpbmUgTUlJX1NUQVRfQVVUT19ET05FICAweDAwMjANCi0jZGVmaW5lCU1JSV9TVEFU X0NBTl9UICAgICAgMHgwODAwDQotI2RlZmluZSBNSUlfU1RBVF9DQU5fVF9GRFggIDB4MTAwMA0K LSNkZWZpbmUJTUlJX1NUQVRfQ0FOX1RYICAgICAweDIwMDAgDQotI2RlZmluZSBNSUlfU1RBVF9D QU5fVFhfRkRYIDB4NDAwMA0KLSNkZWZpbmUJTUlJX1NUQVRfQ0FOX1Q0ICAgICAweDgwMDANCi0N Ci0NCi0jZGVmaW5lCQlNSUlfSUQxX09VSV9MTwkJMHhGQzAwCS8qIGxvdyBiaXRzIG9mIE9VSSBt YXNrICovDQotI2RlZmluZQkJTUlJX0lEMV9NT0RFTAkJMHgwM0YwCS8qIG1vZGVsIG51bWJlciAq Lw0KLSNkZWZpbmUJCU1JSV9JRDFfUkVWCQkweDAwMEYJLyogbW9kZWwgbnVtYmVyICovDQotDQot LyogTUlJIE5XQVkgUmVnaXN0ZXIgQml0cyAuLi4NCi0gICB2YWxpZCBmb3IgdGhlIEFOQVIgKEF1 dG8tTmVnb3RpYXRpb24gQWR2ZXJ0aXNlbWVudCkgYW5kDQotICAgQU5MUEFSIChBdXRvLU5lZ290 aWF0aW9uIExpbmsgUGFydG5lcikgcmVnaXN0ZXJzICovDQotI2RlZmluZQlNSUlfTldBWV9OT0RF X1NFTCAweDAwMWYNCi0jZGVmaW5lIE1JSV9OV0FZX0NTTUFfQ0QgIDB4MDAwMQ0KLSNkZWZpbmUJ TUlJX05XQVlfVAkgIDB4MDAyMA0KLSNkZWZpbmUgTUlJX05XQVlfVF9GRFggICAgMHgwMDQwDQot I2RlZmluZQlNSUlfTldBWV9UWCAgICAgICAweDAwODANCi0jZGVmaW5lIE1JSV9OV0FZX1RYX0ZE WCAgIDB4MDEwMA0KLSNkZWZpbmUJTUlJX05XQVlfVDQgICAgICAgMHgwMjAwIA0KLSNkZWZpbmUg TUlJX05XQVlfUEFVU0UgICAgMHgwNDAwIA0KLSNkZWZpbmUJTUlJX05XQVlfUkYgICAgICAgMHgy MDAwIC8qIFJlbW90ZSBGYXVsdCAqLw0KLSNkZWZpbmUgTUlJX05XQVlfQUNLICAgICAgMHg0MDAw IC8qIFJlbW90ZSBBY2tub3dsZWRnZSAqLw0KLSNkZWZpbmUJTUlJX05XQVlfTlAgICAgICAgMHg4 MDAwIC8qIE5leHQgUGFnZSAoRW5hYmxlKSAqLw0KLQ0KLS8qIG1paSBzdHNvdXQgcmVnaXN0ZXIg Yml0cyAqLw0KLSNkZWZpbmUJTUlJX1NUU09VVF9MSU5LX0ZBSUwgMHg0MDAwDQotI2RlZmluZQlN SUlfU1RTT1VUX1NQRCAgICAgICAweDAwODANCi0jZGVmaW5lIE1JSV9TVFNPVVRfRFBMWCAgICAg IDB4MDA0MA0KLQ0KLS8qIG1paSBzdHNpY3MgcmVnaXN0ZXIgYml0cyAqLw0KLSNkZWZpbmUJTUlJ X1NUU0lDU19TUEQgICAgICAgMHg4MDAwDQotI2RlZmluZSBNSUlfU1RTSUNTX0RQTFggICAgICAw eDQwMDANCi0jZGVmaW5lCU1JSV9TVFNJQ1NfTElOS1NUUyAgIDB4MDAwMQ0KLQ0KLS8qIG1paSBz dHNzdW0gcmVnaXN0ZXIgYml0cyAqLw0KLSNkZWZpbmUJTUlJX1NUU1NVTV9MSU5LICAweDAwMDgN Ci0jZGVmaW5lIE1JSV9TVFNTVU1fRFBMWCAgMHgwMDA0DQotI2RlZmluZQlNSUlfU1RTU1VNX0FV VE8gIDB4MDAwMg0KLSNkZWZpbmUgTUlJX1NUU1NVTV9TUEQgICAweDAwMDENCi0NCi0vKiBsc2kg cGh5IHN0YXR1cyByZWdpc3RlciAqLw0KLSNkZWZpbmUgTUlJX0xTSV9QSFlfU1RBVF9GRFgJMHgw MDQwDQotI2RlZmluZSBNSUlfTFNJX1BIWV9TVEFUX1NQRAkweDAwODANCi0NCi0vKiBhbWQgcGh5 IHN0YXR1cyByZWdpc3RlciAqLw0KLSNkZWZpbmUgTUlJX0FNRF9QSFlfU1RBVF9GRFgJMHgwODAw DQotI2RlZmluZSBNSUlfQU1EX1BIWV9TVEFUX1NQRAkweDA0MDANCi0NCi0vKiBpbnRlbCBwaHkg c3RhdHVzIHJlZ2lzdGVyICovDQotI2RlZmluZSBNSUlfSU5URUxfUEhZX1NUQVRfRkRYCTB4MDIw MA0KLSNkZWZpbmUgTUlJX0lOVEVMX1BIWV9TVEFUX1NQRAkweDQwMDANCi0NCi0vKiBBdXhpbGxp YXJ5IENvbnRyb2wvU3RhdHVzIFJlZ2lzdGVyICovDQotI2RlZmluZSBNSUlfQVVYX0ZEWCAgICAg IDB4MDAwMQ0KLSNkZWZpbmUgTUlJX0FVWF8xMDAgICAgICAweDAwMDINCi0jZGVmaW5lIE1JSV9B VVhfRjEwMCAgICAgMHgwMDA0DQotI2RlZmluZSBNSUlfQVVYX0FORUcgICAgIDB4MDAwOA0KLQ0K LXR5cGVkZWYgc3RydWN0IG1paV9waHkgew0KLQlzdHJ1Y3QgbWlpX3BoeSAqIG5leHQ7DQotCXN0 cnVjdCBtaWlfY2hpcF9pbmZvICogY2hpcF9pbmZvOw0KLQl1MTYgc3RhdHVzOw0KLQl1MzIgKm1p aV9jb250cm9sX3JlZzsNCi0JdTMyICptaWlfZGF0YV9yZWc7DQotfSBtaWlfcGh5X3Q7DQotDQot c3RydWN0IHBoeV9vcHMgew0KLQlpbnQgKCpwaHlfaW5pdCkgKHN0cnVjdCBuZXRfZGV2aWNlICos IGludCk7DQotCWludCAoKnBoeV9yZXNldCkgKHN0cnVjdCBuZXRfZGV2aWNlICosIGludCk7DQot CWludCAoKnBoeV9zdGF0dXMpIChzdHJ1Y3QgbmV0X2RldmljZSAqLCBpbnQsIHUxNiAqLCB1MTYg Kik7DQotfTsNCi0NCiAvKiANCiAgKiBEYXRhIEJ1ZmZlciBEZXNjcmlwdG9yLiBEYXRhIGJ1ZmZl cnMgbXVzdCBiZSBhbGlnbmVkIG9uIDMyIGJ5dGUgDQogICogYm91bmRhcnkgZm9yIGJvdGgsIHJl Y2VpdmUgYW5kIHRyYW5zbWl0Lg0KQEAgLTIwMCw3ICs4Niw2IEBADQogDQogDQogc3RydWN0IGF1 MTAwMF9wcml2YXRlIHsNCi0JDQogCWRiX2Rlc3RfdCAqcERCZnJlZTsNCiAJZGJfZGVzdF90IGRi W05VTV9SWF9CVUZGUytOVU1fVFhfQlVGRlNdOw0KIAl2b2xhdGlsZSByeF9kbWFfdCAqcnhfZG1h X3JpbmdbTlVNX1JYX0RNQV07DQpAQCAtMjEzLDkgKzk4LDE2IEBADQogCXUzMiB0eF9mdWxsOw0K IA0KIAlpbnQgbWFjX2lkOw0KLQltaWlfcGh5X3QgKm1paTsNCi0Jc3RydWN0IG1paV9pZl9pbmZv IG1paV9pZjsNCi0Jc3RydWN0IHBoeV9vcHMgKnBoeV9vcHM7DQorDQorCWludCBtYWNfZW5hYmxl ZDsgICAgICAgLyogd2hldGhlciBNQUMgaXMgY3VycmVudGx5IGVuYWJsZWQgYW5kIHJ1bm5pbmcg KHJlcS4gZm9yIG1kaW8pICovDQorDQorCWludCBvbGRfbGluazsgICAgICAgICAgLyogdXNlZCBi eSBhdTEwMDBfYWRqdXN0X2xpbmsgKi8NCisJaW50IG9sZF9zcGVlZDsNCisJaW50IG9sZF9kdXBs ZXg7DQorDQorCWludCBwaHlfYWRkcjsgICAgICAgICAgLyogcGh5IGFkZHJlc3MgKi8NCisJc3Ry dWN0IHBoeV9kZXZpY2UgKnBoeV9kZXY7DQorCXN0cnVjdCBtaWlfYnVzIG1paV9idXM7DQogCQ0K IAkvKiBUaGVzZSB2YXJpYWJsZXMgYXJlIGp1c3QgZm9yIHF1aWNrIGFjY2VzcyB0byBjZXJ0YWlu IHJlZ3MgYWRkcmVzc2VzLiAqLw0KIAl2b2xhdGlsZSBtYWNfcmVnX3QgKm1hYzsgIC8qIG1hYyBy ZWdpc3RlcnMgICAgICAgICAgICAgICAgICAgICAgKi8gICANCkBAIC0yMjcsMTEgKzExOSw5IEBA DQogCXU4ICpoYXNoX3RhYmxlOw0KIAl1MzIgaGFzaF9tb2RlOw0KIAl1MzIgaW50cl93b3JrX2Rv bmU7IC8qIG51bWJlciBvZiBSeCBhbmQgVHggcGt0cyBwcm9jZXNzZWQgaW4gdGhlIGlzciAqLw0K LQlpbnQgcGh5X2FkZHI7ICAgICAgICAgIC8qIHBoeSBhZGRyZXNzICovDQogCXUzMiBvcHRpb25z OyAgICAgICAgICAgLyogVXNlci1zZXR0YWJsZSBtaXNjLiBkcml2ZXIgb3B0aW9ucy4gKi8NCiAJ dTMyIGRydl9mbGFnczsNCi0JaW50IHdhbnRfYXV0b25lZzsNCisNCiAJc3RydWN0IG5ldF9kZXZp Y2Vfc3RhdHMgc3RhdHM7DQotCXN0cnVjdCB0aW1lcl9saXN0IHRpbWVyOw0KIAlzcGlubG9ja190 IGxvY2s7ICAgICAgIC8qIFNlcmlhbGlzZSBhY2Nlc3MgdG8gZGV2aWNlICovDQogfTsNCm== --=-3obsThmJDBZucvHF3QdD-- --=-nXAAkLu6qAytME5Lt43T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEX/inSYHgZIg/QUIRAqc5AKDcN/EMPnJ0lkOeL4n1lqlqFX8RBACcCtSF qpmrJcycV/aOi53oUDrsLWY= =xM7F -----END PGP SIGNATURE----- --=-nXAAkLu6qAytME5Lt43T-- From anemo@mba.ocn.ne.jp Tue May 9 04:13:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 04:13:26 +0100 (BST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:52123 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8126481AbWEIDNK (ORCPT ); Tue, 9 May 2006 04:13:10 +0100 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Tue, 9 May 2006 12:13:09 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 0AE38203F5; Tue, 9 May 2006 12:13:03 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E3446203DB; Tue, 9 May 2006 12:13:02 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k493D24D093120; Tue, 9 May 2006 12:13:02 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Tue, 09 May 2006 12:13:02 +0900 (JST) Message-Id: <20060509.121302.78496215.nemoto@toshiba-tops.co.jp> To: sam@ravnborg.org Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, chrisw@sous-sol.org, linux-mips@linux-mips.org, ralf@linux-mips.org, shemminger@osdl.org Subject: Re: [git patches] kbuild fixes for -rc From: Atsushi Nemoto In-Reply-To: <20060508200153.GA3762@mars.ravnborg.org> References: <20060508050809.GA2247@mars.ravnborg.org> <20060508190312.GB2697@moss.sous-sol.org> <20060508200153.GA3762@mars.ravnborg.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 2418 Lines: 73 On Mon, 8 May 2006 22:01:53 +0200, Sam Ravnborg wrote: > Please revert this bogus commit: > > > commit c8d8b837ebe4b4f11e1b0c4a2bdc358c697692ed > > I was discussed on mips list but apparently the fix was bogus. > I will not have time to look into it so mips can carry this local > fix until we get a proper fix in mainline. Here is a updated fix to avoid breakage on 32-bit build. 64bit mips has different r_info layout. This patch fixes modpost segfault for 64bit little endian mips kernel. Signed-off-by: Atsushi Nemoto diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 6d04504..692a83b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -709,10 +709,20 @@ static void check_sec_ref(struct module for (rela = start; rela < stop; rela++) { Elf_Rela r; const char *secname; + unsigned int r_sym; r.r_offset = TO_NATIVE(rela->r_offset); - r.r_info = TO_NATIVE(rela->r_info); +#if KERNEL_ELFCLASS == ELFCLASS64 + if (hdr->e_machine == EM_MIPS) { + r_sym = ELF64_MIPS_R_SYM(rela->r_info); + r_sym = TO_NATIVE(r_sym); + } else { + r_sym = ELF_R_SYM(TO_NATIVE(rela->r_info)); + } +#else + r_sym = ELF_R_SYM(TO_NATIVE(rela->r_info)); +#endif r.r_addend = TO_NATIVE(rela->r_addend); - sym = elf->symtab_start + ELF_R_SYM(r.r_info); + sym = elf->symtab_start + r_sym; /* Skip special sections */ if (sym->st_shndx >= SHN_LORESERVE) continue; diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h index b14255c..89b96c6 100644 --- a/scripts/mod/modpost.h +++ b/scripts/mod/modpost.h @@ -39,6 +39,25 @@ #define ELF_R_SYM ELF64_R_SYM #define ELF_R_TYPE ELF64_R_TYPE #endif +/* The 64-bit MIPS ELF ABI uses an unusual reloc format. */ +typedef struct +{ + Elf32_Word r_sym; /* Symbol index */ + unsigned char r_ssym; /* Special symbol for 2nd relocation */ + unsigned char r_type3; /* 3rd relocation type */ + unsigned char r_type2; /* 2nd relocation type */ + unsigned char r_type1; /* 1st relocation type */ +} _Elf64_Mips_R_Info; + +typedef union +{ + Elf64_Xword r_info_number; + _Elf64_Mips_R_Info r_info_fields; +} _Elf64_Mips_R_Info_union; + +#define ELF64_MIPS_R_SYM(i) \ + ((__extension__ (_Elf64_Mips_R_Info_union)(i)).r_info_fields.r_sym) + #if KERNEL_ELFDATA != HOST_ELFDATA static inline void __endian(const void *src, void *dest, unsigned int size) From gowri@bitel.co.kr Tue May 9 08:55:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 08:55:41 +0100 (BST) Received: from www.haninternet.co.kr ([211.63.64.4]:21766 "EHLO www.haninternet.co.kr") by ftp.linux-mips.org with ESMTP id S8133536AbWEIHza (ORCPT ); Tue, 9 May 2006 08:55:30 +0100 Received: from [211.63.70.179] ([211.63.70.179]) by www.haninternet.co.kr (8.9.3/8.9.3) with ESMTP id QAA10866; Tue, 9 May 2006 16:50:27 +0900 Subject: RE: Java virtual machine on linux MIPS From: Gowri Satish Adimulam Reply-To: gowri@bitel.co.kr To: Prashant Viswanathan Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Organization: Bitel Co Ltd Date: Tue, 09 May 2006 16:55:10 +0900 Message-Id: <1147161310.3036.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gowri@bitel.co.kr Precedence: bulk X-list: linux-mips Content-Length: 682 Lines: 31 Hi , I tried to google , but could not find the relevant sources . is it open source? if yes , please share with me . Regards Gowri On Fri, 2006-04-28 at 10:02 -0700, Prashant Viswanathan wrote: > IBM's J9 works on linux-mips. > > > -----Original Message----- > > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux- > > mips.org] On Behalf Of Gowri Satish Adimulam > > Sent: Thursday, April 27, 2006 6:39 PM > > To: linux-mips@linux-mips.org > > Subject: Java virtual machine on linux MIPS > > > > Hi , > > > > He is there any java virtual machine runs on mips based linux . > > > > any pointers will be helpful > > > > Regards > > Gowri > > > From ralf@linux-mips.org Tue May 9 16:15:37 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 16:15:59 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:27270 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S3457184AbWEIOPh (ORCPT ); Tue, 9 May 2006 16:15:37 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k49CWx7O004722; Tue, 9 May 2006 13:32:59 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k49CWwqB004721; Tue, 9 May 2006 13:32:58 +0100 Date: Tue, 9 May 2006 13:32:58 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix kgdb exception handler from user mode Message-ID: <20060509123258.GA3749@linux-mips.org> References: <20060509.202349.80882976.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060509.202349.80882976.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 233 Lines: 8 On Tue, May 09, 2006 at 08:23:49PM +0900, Atsushi Nemoto wrote: > Fix a calculation of saved vector address in trap_low (damage done by > f4c72cc737561aab0d9c7f877abbc0a853f1c465) Applied to master and linux-2.6.16-stable. Ralf From djd20@kent.ac.uk Tue May 9 16:24:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 16:25:06 +0200 (CEST) Received: from mx6.kent.ac.uk ([129.12.21.37]:38827 "EHLO mx6.kent.ac.uk") by ftp.linux-mips.org with ESMTP id S8133857AbWEIOYv (ORCPT ); Tue, 9 May 2006 16:24:51 +0200 Received: from hathor.ukc.ac.uk ([129.12.4.12]) by mx6.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FdT8g-0007RK-80 for linux-mips@linux-mips.org; Tue, 09 May 2006 15:24:38 +0100 Received: from myrtle.ukc.ac.uk ([129.12.3.176] ident=exim) by hathor.ukc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1FdT8g-0000Cf-3s for linux-mips@linux-mips.org; Tue, 09 May 2006 15:24:38 +0100 Received: from fingerpoken.ukc.ac.uk ([129.12.16.14]) by myrtle.ukc.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FdT8f-00049B-Us for linux-mips@linux-mips.org; Tue, 09 May 2006 15:24:37 +0100 From: Damian Dimmich To: linux-mips@linux-mips.org Date: Tue, 9 May 2006 15:16:24 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Disposition: inline Subject: zilog oops with bad scsi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200605091516.24427.djd20@kent.ac.uk> X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: djd20@kent.ac.uk Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djd20@kent.ac.uk Precedence: bulk X-list: linux-mips Content-Length: 5096 Lines: 131 Hi, I have, what I think is a badly set-up scsi system. I think there is an issue with the termination, the attached drives are wide-scsi and I think there is some issue with the termination. That isn't the interesting bit though. When booting with a freshly compiled 2.6.16.12 kernel, running headless with the output coming in on ttyS1, I can get the kernel to oops by pressing any key (sending a keypress down the serial line) while it is trying to figure out what is going on with the scsi subsystem. With the external scsi it boots fine. Interestingly, this did not happen with the debian-rolled 2.4.27 kernel (as in, it would complain about the scis, but not crash when i pressed keys). Thought this may be useful to someone. Please let me know if you need any further information. Cheers, Damian Linux version 2.6.16.12 (ddimmich@indigo) (gcc version 4.0.3 20051201 (prerelea6 ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU revision is: 00000460 FPU revision is: 00000500 MC: SGI memory controller Revision 3 MC: Probing memory configuration: bank0: 64M @ 10000000 bank1: 32M @ 14000000 bank2: 128M @ 08000000 Determined physical RAM map: memory: 0e000000 @ 08000000 (usable) Built 1 zonelists Kernel command line: root=/dev/sda1 console=ttyS0 auto Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 b. Primary data cache 16kB, direct mapped, linesize 16 bytes. Unified secondary cache 1024kB direct mapped, linesize 128 bytes. Synthesized TLB refill handler (21 instructions). Synthesized TLB load handler fastpath (33 instructions). Synthesized TLB store handler fastpath (33 instructions). Synthesized TLB modify handler fastpath (32 instructions). EISA: Probing bus... EISA: Detected 0 card. ISA support compiled in. PID hash table entries: 2048 (order: 11, 32768 bytes) Calibrating system timer... 100500 [201.0000 MHz CPU] Using 100.500 MHz high precision timer. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 222688k/229376k available (2385k kernel code, 6556k reserved, 518k data) Mount-cache hash table entries: 512 Checking for 'wait' instruction... unavailable. NET: Registered protocol family 16 EISA bus registered SCSI subsystem initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered serio: i8042 AUX port at 0xbfbd9843,0xbfbd9847 irq 44 serio: i8042 KBD port at 0xbfbd9843,0xbfbd9847 irq 44 Serial: IP22 Zilog driver (1 chips). ttyS0 at MMIO 0xc001a830 (irq = 45) is a IP22-Zilog Console: ttyS0 (IP22-Zilog) ttyS1 at MMIO 0xc001c838 (irq = 45) is a IP22-Zilog eth0: SGI Seeq8003 08:00:69:08:43:b2 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.26 - 22/Feb/2003, Compiled Apr 15 2006 at 10:15:46 wd33c93-1: chip=unknown/255 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.26 - 22/Feb/2003, Compiled Apr 15 2006 at 10:15:46 --UNKNOWN INTERRUPT:80:01:00--<6>scsi0 : SGI WD93 sending SDTR 0103013f0csync_xfer=2c<5> Vendor: SEAGATE Model: ST34501W 8 Type: Direct-Access ANSI SCSI revision: 02 scsi1 : SGI WD93 scsi1: warning : SCSI command probably completed successfully before ab4 Oops[#1]: Cpu 0 $ 0 : 00000000 1000cc01 01470000 00000000 $ 4 : 95e5dc00 bfbd9830 882a1ee0 1000cc00 $ 8 : 1000cc00 1000001f 00000000 89364000 $12 : 00000002 88310000 ffffffff 00000001 $16 : 00000004 95e5dc00 bfbd9830 0147ae13 $20 : 882a1ee0 88310000 00000038 887fe594 $24 : 00000000 00000000 $28 : 882a0000 882a1df8 00000001 8819b784 Hi : 000000f7 Lo : ae135c80 epc : 8819b254 ip22zilog_receive_chars+0x38/0x3cc Not tainted ra : 8819b784 ip22zilog_interrupt+0x19c/0x1a4 Status: 1000cc03 KERNEL EXL IE Cause : 30000008 BadVA : 00000000 PrId : 00000460 Modules linked in: Process swapper (pid: 0, threadinfo=882a0000, task=882a2000) Stack : 00200200 882a1e68 0000001a 01baa080 00000000 883142dc 00000004 95e5dc00 bfbd9830 0147ae13 882a1ee0 88310000 00000038 887fe594 00000001 8819b784 0000000a 88310000 00000001 88315dd0 95e58300 00000000 00000000 00000001 882a1ee0 0000002d 88810000 8804bd88 882a1e68 882a1e68 00000000 883142dc 882d75e0 95e58300 0000002d fffffffb 88310000 882a1ee0 8804beb0 8804bf24 ... Call Trace: [<8819b784>] ip22zilog_interrupt+0x19c/0x1a4 [<8804bd88>] handle_IRQ_event+0x80/0xf8 [<8804beb0>] __do_IRQ+0xb0/0x140 [<8804bf24>] __do_IRQ+0x124/0x140 [<882d9000>] kernel_entry+0x0/0x7c [<882d9000>] kernel_entry+0x0/0x7c [<880067cc>] do_IRQ+0x1c/0x34 [<8802ee88>] do_softirq+0x90/0xbc [<88003620>] indyIRQ+0x120/0x180 [<88003608>] indyIRQ+0x108/0x180 [<882d9000>] kernel_entry+0x0/0x7c [<88006e6c>] cpu_idle+0x48/0x50 From langabe@gmail.com Tue May 9 16:35:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 16:35:23 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.173]:55500 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133859AbWEIOfO convert rfc822-to-8bit (ORCPT ); Tue, 9 May 2006 16:35:14 +0200 Received: by ug-out-1314.google.com with SMTP id u40so264295ugc for ; Tue, 09 May 2006 07:35:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=a7BCCerGewrZJp0ufQxDU8mMxWqCvKHzgPzB+SDt6u5cOza8FHZKplwnB/eLeLmoxLyqbl33Kkqz0YaThUn4zi++bcefNEV8rjge6oWWXHiUOGLVJOHrLaWSs7eoiCJcBgbo0K8bFRnZs/I7Nn8HFlaRCTNF8MKbVeYc/qZLSk4= Received: by 10.78.17.4 with SMTP id 4mr798270huq; Tue, 09 May 2006 07:35:14 -0700 (PDT) Received: by 10.78.39.13 with HTTP; Tue, 9 May 2006 07:35:14 -0700 (PDT) Message-ID: Date: Tue, 9 May 2006 15:35:14 +0100 From: "Alex Gonzalez" To: linux-mips@linux-mips.org Subject: Boot time memory allocation MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: langabe@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 636 Lines: 18 Hi, I have two independent processors with access to a shared memory region, mapped in the 256MB to 512MB region (kseg0). One is running a propietary OS, and the second one is running Linux 2.6.12. How would I arrange to leave that shared memory region out of the scope of Linux's memory management system, but at the same time make it possible for a driver to access it? I have done similar things before with the help of alloc_bootmem, but this time I don't want the kernel to reserve the memory, I want the kernel to be completely unaware of it, and I need to specify its start and end. Any idea very much welcomed, thanks Alex From djd20@kent.ac.uk Tue May 9 16:38:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 16:38:53 +0200 (CEST) Received: from mx5.kent.ac.uk ([129.12.21.36]:54192 "EHLO mx5.kent.ac.uk") by ftp.linux-mips.org with ESMTP id S8133859AbWEIOil (ORCPT ); Tue, 9 May 2006 16:38:41 +0200 Received: from hathor.ukc.ac.uk ([129.12.4.12]) by mx5.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1FdTM7-0000Cv-L2 for linux-mips@linux-mips.org; Tue, 09 May 2006 15:38:31 +0100 Received: from myrtle.ukc.ac.uk ([129.12.3.176] ident=exim) by hathor.ukc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1FdTM7-0000Tk-HQ for linux-mips@linux-mips.org; Tue, 09 May 2006 15:38:31 +0100 Received: from fingerpoken.ukc.ac.uk ([129.12.16.14]) by myrtle.ukc.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FdTM7-0005Zf-CD for linux-mips@linux-mips.org; Tue, 09 May 2006 15:38:31 +0100 From: Damian Dimmich To: linux-mips@linux-mips.org Subject: Re: zilog oops with bad scsi Date: Tue, 9 May 2006 15:30:17 +0100 User-Agent: KMail/1.8.3 References: <200605091516.24427.djd20@kent.ac.uk> In-Reply-To: <200605091516.24427.djd20@kent.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605091530.17748.djd20@kent.ac.uk> X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: djd20@kent.ac.uk Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djd20@kent.ac.uk Precedence: bulk X-list: linux-mips Content-Length: 5649 Lines: 139 Oh, if I wait and do not press any keys (takes a short time) then after a while the scsi driver times out/stops trying to connect to the not-working device and boot continues. Once it is out of the scsi driver the system does not crash on keypress any more. Damian On Tuesday 09 May 2006 15:16, Damian Dimmich wrote: > Hi, > > I have, what I think is a badly set-up scsi system. I think there is an > issue with the termination, the attached drives are wide-scsi and I think > there is some issue with the termination. > > That isn't the interesting bit though. When booting with a freshly > compiled 2.6.16.12 kernel, running headless with the output coming in on > ttyS1, I can get the kernel to oops by pressing any key (sending a keypress > down the serial line) while it is trying to figure out what is going on > with the scsi subsystem. With the external scsi it boots fine. > > Interestingly, this did not happen with the debian-rolled 2.4.27 kernel (as > in, it would complain about the scis, but not crash when i pressed keys). > > Thought this may be useful to someone. Please let me know if you need any > further information. > > Cheers, > Damian > > Linux version 2.6.16.12 (ddimmich@indigo) (gcc version 4.0.3 20051201 > (prerelea6 > ARCH: SGI-IP22 > PROMLIB: ARC firmware Version 1 Revision 10 > CPU revision is: 00000460 > FPU revision is: 00000500 > MC: SGI memory controller Revision 3 > MC: Probing memory configuration: > bank0: 64M @ 10000000 > bank1: 32M @ 14000000 > bank2: 128M @ 08000000 > Determined physical RAM map: > memory: 0e000000 @ 08000000 (usable) > Built 1 zonelists > Kernel command line: root=/dev/sda1 console=ttyS0 auto > Primary instruction cache 16kB, physically tagged, direct mapped, linesize > 16 b. > Primary data cache 16kB, direct mapped, linesize 16 bytes. > Unified secondary cache 1024kB direct mapped, linesize 128 bytes. > Synthesized TLB refill handler (21 instructions). > Synthesized TLB load handler fastpath (33 instructions). > Synthesized TLB store handler fastpath (33 instructions). > Synthesized TLB modify handler fastpath (32 instructions). > EISA: Probing bus... > EISA: Detected 0 card. > ISA support compiled in. > PID hash table entries: 2048 (order: 11, 32768 bytes) > Calibrating system timer... 100500 [201.0000 MHz CPU] > Using 100.500 MHz high precision timer. > Console: colour dummy device 80x25 > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 222688k/229376k available (2385k kernel code, 6556k reserved, 518k > data) > Mount-cache hash table entries: 512 > Checking for 'wait' instruction... unavailable. > NET: Registered protocol family 16 > EISA bus registered > SCSI subsystem initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > Initializing Cryptographic API > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > serio: i8042 AUX port at 0xbfbd9843,0xbfbd9847 irq 44 > serio: i8042 KBD port at 0xbfbd9843,0xbfbd9847 irq 44 > Serial: IP22 Zilog driver (1 chips). > ttyS0 at MMIO 0xc001a830 (irq = 45) is a IP22-Zilog > Console: ttyS0 (IP22-Zilog) > ttyS1 at MMIO 0xc001c838 (irq = 45) is a IP22-Zilog > eth0: SGI Seeq8003 08:00:69:08:43:b2 > wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 > setup_args=,,,,,,,,, > Version 1.26 - 22/Feb/2003, Compiled Apr 15 2006 at 10:15:46 > wd33c93-1: chip=unknown/255 no_sync=0xff no_dma=0 debug_flags=0x00 > setup_args=,,,,,,,,, > Version 1.26 - 22/Feb/2003, Compiled Apr 15 2006 at 10:15:46 > --UNKNOWN INTERRUPT:80:01:00--<6>scsi0 : SGI WD93 > sending SDTR 0103013f0csync_xfer=2c<5> Vendor: SEAGATE Model: ST34501W > 8 > Type: Direct-Access ANSI SCSI revision: 02 > scsi1 : SGI WD93 > scsi1: warning : SCSI command probably completed successfully > before ab4 > Oops[#1]: > Cpu 0 > $ 0 : 00000000 1000cc01 01470000 00000000 > $ 4 : 95e5dc00 bfbd9830 882a1ee0 1000cc00 > $ 8 : 1000cc00 1000001f 00000000 89364000 > $12 : 00000002 88310000 ffffffff 00000001 > $16 : 00000004 95e5dc00 bfbd9830 0147ae13 > $20 : 882a1ee0 88310000 00000038 887fe594 > $24 : 00000000 00000000 > $28 : 882a0000 882a1df8 00000001 8819b784 > Hi : 000000f7 > Lo : ae135c80 > epc : 8819b254 ip22zilog_receive_chars+0x38/0x3cc Not tainted > ra : 8819b784 ip22zilog_interrupt+0x19c/0x1a4 > Status: 1000cc03 KERNEL EXL IE > Cause : 30000008 > BadVA : 00000000 > PrId : 00000460 > Modules linked in: > Process swapper (pid: 0, threadinfo=882a0000, task=882a2000) > Stack : 00200200 882a1e68 0000001a 01baa080 00000000 883142dc 00000004 > 95e5dc00 > bfbd9830 0147ae13 882a1ee0 88310000 00000038 887fe594 00000001 > 8819b784 > 0000000a 88310000 00000001 88315dd0 95e58300 00000000 00000000 > 00000001 > 882a1ee0 0000002d 88810000 8804bd88 882a1e68 882a1e68 00000000 > 883142dc > 882d75e0 95e58300 0000002d fffffffb 88310000 882a1ee0 8804beb0 > 8804bf24 > ... > Call Trace: > [<8819b784>] ip22zilog_interrupt+0x19c/0x1a4 > [<8804bd88>] handle_IRQ_event+0x80/0xf8 > [<8804beb0>] __do_IRQ+0xb0/0x140 > [<8804bf24>] __do_IRQ+0x124/0x140 > [<882d9000>] kernel_entry+0x0/0x7c > [<882d9000>] kernel_entry+0x0/0x7c > [<880067cc>] do_IRQ+0x1c/0x34 > [<8802ee88>] do_softirq+0x90/0xbc > [<88003620>] indyIRQ+0x120/0x180 > [<88003608>] indyIRQ+0x108/0x180 > [<882d9000>] kernel_entry+0x0/0x7c > [<88006e6c>] cpu_idle+0x48/0x50 From anemo@mba.ocn.ne.jp Tue May 9 16:58:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 16:58:44 +0200 (CEST) Received: from p549F5DF2.dip.t-dialin.net ([84.159.93.242]:64960 "EHLO p549F5DF2.dip.t-dialin.net") by ftp.linux-mips.org with ESMTP id S8133884AbWEIO62 (ORCPT ); Tue, 9 May 2006 16:58:28 +0200 Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:33034 "EHLO topsns2.toshiba-tops.co.jp") by lappi.linux-mips.net with ESMTP id S1098926AbWEILYV (ORCPT ); Tue, 9 May 2006 04:24:21 -0700 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for p549F5DF2.dip.t-dialin.net [84.159.93.242]) with ESMTP; Tue, 9 May 2006 20:24:19 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 1C55420386; Tue, 9 May 2006 20:23:50 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 0857320361; Tue, 9 May 2006 20:23:50 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k49BNn4D095519; Tue, 9 May 2006 20:23:49 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Tue, 09 May 2006 20:23:49 +0900 (JST) Message-Id: <20060509.202349.80882976.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix kgdb exception handler from user mode From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 525 Lines: 22 Fix a calculation of saved vector address in trap_low (damage done by f4c72cc737561aab0d9c7f877abbc0a853f1c465) diff --git a/arch/mips/kernel/gdb-low.S b/arch/mips/kernel/gdb-low.S index 10f28fb..5fd7a8a 100644 --- a/arch/mips/kernel/gdb-low.S +++ b/arch/mips/kernel/gdb-low.S @@ -54,9 +54,11 @@ #endif */ mfc0 k0, CP0_CAUSE andi k0, k0, 0x7c - add k1, k1, k0 - PTR_L k0, saved_vectors(k1) - jr k0 +#ifdef CONFIG_64BIT + dsll k0, k0, 1 +#endif + PTR_L k1, saved_vectors(k0) + jr k1 nop 1: move k0, sp From ralf@linux-mips.org Tue May 9 22:00:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 22:00:14 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:17815 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133876AbWEIUAG (ORCPT ); Tue, 9 May 2006 22:00:06 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k49GfS43010748; Tue, 9 May 2006 17:41:28 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k49GfS8N010747; Tue, 9 May 2006 17:41:28 +0100 Date: Tue, 9 May 2006 17:41:28 +0100 From: Ralf Baechle To: "Mark.Zhan" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Message-ID: <20060509164127.GA10647@linux-mips.org> References: <445C6694.6010901@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445C6694.6010901@windriver.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 405 Lines: 10 On Sat, May 06, 2006 at 05:04:20PM +0800, Mark.Zhan wrote: > According to your comments, I re-create the patch. Hopefully, no line-wrapped problems:-) > Patch 1 and 2 in the original mails are concatenated into one patch in this mail. Well, this patch was still somewhat corrupt, a few spaces were missing but I was somehow able to talk git into taking it. So it's applied on the queue branch. Ralf From ralf@linux-mips.org Tue May 9 22:00:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 22:00:55 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:19095 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133879AbWEIUAM (ORCPT ); Tue, 9 May 2006 22:00:12 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k49GYCdF010523; Tue, 9 May 2006 17:34:12 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k49GYBKu010522; Tue, 9 May 2006 17:34:11 +0100 Date: Tue, 9 May 2006 17:34:11 +0100 From: Ralf Baechle To: Alex Gonzalez Cc: linux-mips@linux-mips.org Subject: Re: Boot time memory allocation Message-ID: <20060509163411.GA8528@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 929 Lines: 22 On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote: > I have two independent processors with access to a shared memory > region, mapped in the 256MB to 512MB region (kseg0). > > One is running a propietary OS, and the second one is running Linux 2.6.12. > > How would I arrange to leave that shared memory region out of the > scope of Linux's memory management system, but at the same time make > it possible for a driver to access it? > > I have done similar things before with the help of alloc_bootmem, but > this time I don't want the kernel to reserve the memory, I want the > kernel to be completely unaware of it, and I need to specify its start > and end. At kernel initialization time just don't tell the kernel about the existence of your memory region. For many systems that just means you shrink the memory region passed to the add_memory_region() call to something that suits your platform. Ralf From tbm@cyrius.com Tue May 9 23:35:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 May 2006 23:35:33 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:8 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133876AbWEIVfX (ORCPT ); Tue, 9 May 2006 23:35:23 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 2A52364D54; Tue, 9 May 2006 21:35:14 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id A43A666E84; Tue, 9 May 2006 23:34:53 +0200 (CEST) Date: Tue, 9 May 2006 23:34:53 +0200 From: Martin Michlmayr To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] [MIPS] create consistency in "system type" selection Message-ID: <20060509213453.GA32050@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 10434 Lines: 389 The "system type" Kconfig options on MIPS are not consistent. For some platforms, only the name is listed while other entries are prepended with "Support for". Remove this as it doesn't make sense when describing the "system type". This is in line with how e.g. ARM handles this. Signed-off-by: Martin Michlmayr --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -13,7 +13,7 @@ choice default SGI_IP22 config MIPS_MTX1 - bool "Support for 4G Systems MTX-1 board" + bool "4G Systems MTX-1 board" select DMA_NONCOHERENT select HW_HAS_PCI select SOC_AU1500 @@ -120,7 +120,7 @@ config MIPS_MIRAGE select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_COBALT - bool "Support for Cobalt Server" + bool "Cobalt Server" select DMA_NONCOHERENT select HW_HAS_PCI select I8259 @@ -132,7 +132,7 @@ config MIPS_COBALT select SYS_SUPPORTS_LITTLE_ENDIAN config MACH_DECSTATION - bool "Support for DECstations" + bool "DECstations" select BOOT_ELF32 select DMA_NONCOHERENT select EARLY_PRINTK @@ -158,7 +158,7 @@ config MACH_DECSTATION otherwise choose R3000. config MIPS_EV64120 - bool "Support for Galileo EV64120 Evaluation board (EXPERIMENTAL)" + bool "Galileo EV64120 Evaluation board (EXPERIMENTAL)" depends on EXPERIMENTAL select DMA_NONCOHERENT select HW_HAS_PCI @@ -175,7 +175,7 @@ config MIPS_EV64120 kernel for this platform. config MIPS_EV96100 - bool "Support for Galileo EV96100 Evaluation board (EXPERIMENTAL)" + bool "Galileo EV96100 Evaluation board (EXPERIMENTAL)" depends on EXPERIMENTAL select DMA_NONCOHERENT select HW_HAS_PCI @@ -195,7 +195,7 @@ config MIPS_EV96100 here if you wish to build a kernel for this platform. config MIPS_IVR - bool "Support for Globespan IVR board" + bool "Globespan IVR board" select DMA_NONCOHERENT select HW_HAS_PCI select ITE_BOARD_GEN @@ -211,7 +211,7 @@ config MIPS_IVR build a kernel for this platform. config MIPS_ITE8172 - bool "Support for ITE 8172G board" + bool "ITE 8172G board" select DMA_NONCOHERENT select HW_HAS_PCI select ITE_BOARD_GEN @@ -228,7 +228,7 @@ config MIPS_ITE8172 a kernel for this platform. config MACH_JAZZ - bool "Support for the Jazz family of machines" + bool "Jazz family of machines" select ARC select ARC32 select ARCH_MAY_HAVE_PC_FDC @@ -246,7 +246,7 @@ config MACH_JAZZ Olivetti M700-10 workstations. config LASAT - bool "Support for LASAT Networks platforms" + bool "LASAT Networks platforms" select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_GT64120 @@ -258,7 +258,7 @@ config LASAT select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_ATLAS - bool "Support for MIPS Atlas board" + bool "MIPS Atlas board" select BOOT_ELF32 select DMA_NONCOHERENT select IRQ_CPU @@ -283,7 +283,7 @@ config MIPS_ATLAS board. config MIPS_MALTA - bool "Support for MIPS Malta board" + bool "MIPS Malta board" select ARCH_MAY_HAVE_PC_FDC select BOOT_ELF32 select HAVE_STD_PC_SERIAL_PORT @@ -311,7 +311,7 @@ config MIPS_MALTA board. config MIPS_SEAD - bool "Support for MIPS SEAD board (EXPERIMENTAL)" + bool "MIPS SEAD board (EXPERIMENTAL)" depends on EXPERIMENTAL select IRQ_CPU select DMA_NONCOHERENT @@ -328,7 +328,7 @@ config MIPS_SEAD board. config MIPS_SIM - bool 'Support for MIPS simulator (MIPSsim)' + bool 'MIPS simulator (MIPSsim)' select DMA_NONCOHERENT select IRQ_CPU select SYS_HAS_CPU_MIPS32_R1 @@ -341,7 +341,7 @@ config MIPS_SIM emulator. config MOMENCO_JAGUAR_ATX - bool "Support for Momentum Jaguar board" + bool "Momentum Jaguar board" select BOOT_ELF32 select DMA_NONCOHERENT select HW_HAS_PCI @@ -361,7 +361,7 @@ config MOMENCO_JAGUAR_ATX Momentum Computer . config MOMENCO_OCELOT - bool "Support for Momentum Ocelot board" + bool "Momentum Ocelot board" select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU @@ -378,7 +378,7 @@ config MOMENCO_OCELOT Momentum Computer . config MOMENCO_OCELOT_3 - bool "Support for Momentum Ocelot-3 board" + bool "Momentum Ocelot-3 board" select BOOT_ELF32 select DMA_NONCOHERENT select HW_HAS_PCI @@ -397,7 +397,7 @@ config MOMENCO_OCELOT_3 PMC-Sierra Rm79000 core. config MOMENCO_OCELOT_C - bool "Support for Momentum Ocelot-C board" + bool "Momentum Ocelot-C board" select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU @@ -414,7 +414,7 @@ config MOMENCO_OCELOT_C Momentum Computer . config MOMENCO_OCELOT_G - bool "Support for Momentum Ocelot-G board" + bool "Momentum Ocelot-G board" select DMA_NONCOHERENT select HW_HAS_PCI select IRQ_CPU @@ -431,23 +431,23 @@ config MOMENCO_OCELOT_G Momentum Computer . config MIPS_XXS1500 - bool "Support for MyCable XXS1500 board" + bool "MyCable XXS1500 board" select DMA_NONCOHERENT select SOC_AU1500 select SYS_SUPPORTS_LITTLE_ENDIAN config PNX8550_V2PCI - bool "Support for Philips PNX8550 based Viper2-PCI board" + bool "Philips PNX8550 based Viper2-PCI board" select PNX8550 select SYS_SUPPORTS_LITTLE_ENDIAN config PNX8550_JBS - bool "Support for Philips PNX8550 based JBS board" + bool "Philips PNX8550 based JBS board" select PNX8550 select SYS_SUPPORTS_LITTLE_ENDIAN config DDB5074 - bool "Support for NEC DDB Vrc-5074 (EXPERIMENTAL)" + bool "NEC DDB Vrc-5074 (EXPERIMENTAL)" depends on EXPERIMENTAL select DDB5XXX_COMMON select DMA_NONCOHERENT @@ -465,7 +465,7 @@ config DDB5074 evaluation board. config DDB5476 - bool "Support for NEC DDB Vrc-5476" + bool "NEC DDB Vrc-5476" select DDB5XXX_COMMON select DMA_NONCOHERENT select HAVE_STD_PC_SERIAL_PORT @@ -486,7 +486,7 @@ config DDB5476 IDE controller, PS2 keyboard, PS2 mouse, etc. config DDB5477 - bool "Support for NEC DDB Vrc-5477" + bool "NEC DDB Vrc-5477" select DDB5XXX_COMMON select DMA_NONCOHERENT select HW_HAS_PCI @@ -504,10 +504,10 @@ config DDB5477 ether port USB, AC97, PCI, etc. config MACH_VR41XX - bool "Support for NEC VR41XX-based machines" + bool "NEC VR41XX-based machines" config PMC_YOSEMITE - bool "Support for PMC-Sierra Yosemite eval board" + bool "PMC-Sierra Yosemite eval board" select DMA_COHERENT select HW_HAS_PCI select IRQ_CPU @@ -524,7 +524,7 @@ config PMC_YOSEMITE manufactured by PMC-Sierra. config QEMU - bool "Support for Qemu" + bool "Qemu" select DMA_COHERENT select GENERIC_ISA_DMA select HAVE_STD_PC_SERIAL_PORT @@ -544,7 +544,7 @@ config QEMU can be found at http://www.linux-mips.org/wiki/Qemu. config SGI_IP22 - bool "Support for SGI IP22 (Indy/Indigo2)" + bool "SGI IP22 (Indy/Indigo2)" select ARC select ARC32 select BOOT_ELF32 @@ -564,7 +564,7 @@ config SGI_IP22 that runs on these, say Y here. config SGI_IP27 - bool "Support for SGI IP27 (Origin200/2000)" + bool "SGI IP27 (Origin200/2000)" select ARC select ARC64 select BOOT_ELF64 @@ -580,7 +580,7 @@ config SGI_IP27 here. config SGI_IP32 - bool "Support for SGI IP32 (O2) (EXPERIMENTAL)" + bool "SGI IP32 (O2) (EXPERIMENTAL)" depends on EXPERIMENTAL select ARC select ARC32 @@ -601,7 +601,7 @@ config SGI_IP32 If you want this kernel to run on SGI O2 workstation, say Y here. config SIBYTE_BIGSUR - bool "Support for Sibyte BCM91480B-BigSur" + bool "Sibyte BCM91480B-BigSur" select BOOT_ELF32 select DMA_COHERENT select PCI_DOMAINS @@ -612,7 +612,7 @@ config SIBYTE_BIGSUR select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_SWARM - bool "Support for Sibyte BCM91250A-SWARM" + bool "Sibyte BCM91250A-SWARM" select BOOT_ELF32 select DMA_COHERENT select SIBYTE_SB1250 @@ -623,7 +623,7 @@ config SIBYTE_SWARM select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_SENTOSA - bool "Support for Sibyte BCM91250E-Sentosa" + bool "Sibyte BCM91250E-Sentosa" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -634,7 +634,7 @@ config SIBYTE_SENTOSA select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_RHONE - bool "Support for Sibyte BCM91125E-Rhone" + bool "Sibyte BCM91125E-Rhone" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -645,7 +645,7 @@ config SIBYTE_RHONE select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_CARMEL - bool "Support for Sibyte BCM91120x-Carmel" + bool "Sibyte BCM91120x-Carmel" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -656,7 +656,7 @@ config SIBYTE_CARMEL select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_PTSWARM - bool "Support for Sibyte BCM91250PT-PTSWARM" + bool "Sibyte BCM91250PT-PTSWARM" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -668,7 +668,7 @@ config SIBYTE_PTSWARM select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_LITTLESUR - bool "Support for Sibyte BCM91250C2-LittleSur" + bool "Sibyte BCM91250C2-LittleSur" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -680,7 +680,7 @@ config SIBYTE_LITTLESUR select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_CRHINE - bool "Support for Sibyte BCM91120C-CRhine" + bool "Sibyte BCM91120C-CRhine" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -691,7 +691,7 @@ config SIBYTE_CRHINE select SYS_SUPPORTS_LITTLE_ENDIAN config SIBYTE_CRHONE - bool "Support for Sibyte BCM91125C-CRhone" + bool "Sibyte BCM91125C-CRhone" depends on EXPERIMENTAL select BOOT_ELF32 select DMA_COHERENT @@ -703,7 +703,7 @@ config SIBYTE_CRHONE select SYS_SUPPORTS_LITTLE_ENDIAN config SNI_RM200_PCI - bool "Support for SNI RM200 PCI" + bool "SNI RM200 PCI" select ARC select ARC32 select ARCH_MAY_HAVE_PC_FDC @@ -729,7 +729,7 @@ config SNI_RM200_PCI support this machine type. config TOSHIBA_JMR3927 - bool "Support for Toshiba JMR-TX3927 board" + bool "Toshiba JMR-TX3927 board" select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_TX3927 @@ -740,7 +740,7 @@ config TOSHIBA_JMR3927 select TOSHIBA_BOARDS config TOSHIBA_RBTX4927 - bool "Support for Toshiba TBTX49[23]7 board" + bool "Toshiba TBTX49[23]7 board" select DMA_NONCOHERENT select HAS_TXX9_SERIAL select HW_HAS_PCI @@ -757,7 +757,7 @@ config TOSHIBA_RBTX4927 support this machine type config TOSHIBA_RBTX4938 - bool "Support for Toshiba RBTX4938 board" + bool "Toshiba RBTX4938 board" select HAVE_STD_PC_SERIAL_PORT select DMA_NONCOHERENT select GENERIC_ISA_DMA -- Martin Michlmayr http://www.cyrius.com/ From sam@catalyst.net.nz Wed May 10 01:25:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 01:25:39 +0200 (CEST) Received: from godel.catalyst.net.nz ([202.78.240.40]:39379 "EHLO mail1.catalyst.net.nz") by ftp.linux-mips.org with ESMTP id S8133880AbWEIXZa (ORCPT ); Wed, 10 May 2006 01:25:30 +0200 Received: from leibniz.catalyst.net.nz ([202.78.240.7] helo=pkunk.wgtn.cat-it.co.nz) by mail1.catalyst.net.nz with esmtps (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1FdbZz-0004r8-79 for linux-mips@linux-mips.org; Wed, 10 May 2006 11:25:23 +1200 Subject: "Badness in local_bh_enable at kernel/softirq.c:140" - sgiseeq and conntrack? From: Sam Cannell To: linux-mips@linux-mips.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tIl8GAIL7RIslTNcG5/k" Date: Wed, 10 May 2006 11:25:22 +1200 Message-Id: <1147217122.20432.14.camel@pkunk.wgtn.cat-it.co.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sam@catalyst.net.nz Precedence: bulk X-list: linux-mips Content-Length: 4030 Lines: 87 --=-tIl8GAIL7RIslTNcG5/k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Since putting a stateful firewall on my Indy, I'm seeing the following error in dmesg fairly often - I believe whenever a tcp connection is closed. Other than filling /var/log/messages, it doesn't seem to be causing any problems - network connections work fine. Is this a known problem? Anything I can or should do about it? [4294795.111000] Badness in local_bh_enable at kernel/softirq.c:140 [4294795.111000] Call Trace: [4294795.111000] [<8802cfdc>] local_bh_enable+0x78/0xa0 [4294795.111000] [] destroy_conntrack+0xdc/0x178 [ip_conntrack] [4294795.111000] [] destroy_conntrack+0x74/0x178 [ip_conntrack] [4294795.111000] [<8817bcbc>] __kfree_skb+0xe4/0x170 [4294795.111000] [<8813ef1c>] sgiseeq_start_xmit+0x2bc/0x388 [4294795.111000] [] ip_nat_out+0x104/0x130 [iptable_nat] [4294795.111000] [] ip_nat_out+0x6c/0x130 [iptable_nat] [4294795.111000] [<88190038>] qdisc_restart+0x70/0x22c [4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8 [4294795.111000] [<88182870>] dev_queue_xmit+0x250/0x2f8 [4294795.111000] [<88182854>] dev_queue_xmit+0x234/0x2f8 [4294795.111000] [<88189748>] neigh_resolve_output+0x1d0/0x2f0 [4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8 [4294795.111000] [<881a2510>] ip_output+0x1b4/0x3cc [4294795.111000] [<881a0900>] dst_output+0x0/0x10 [4294795.111000] [<881a2074>] ip_finish_output+0x0/0x2e8 [4294795.111000] [<881a41d0>] ip_push_pending_frames+0x4ec/0x54c [4294795.111000] [<881c5654>] icmp_push_reply+0x58/0x140 [4294795.111000] [<881c5530>] icmp_glue_bits+0x0/0xcc [4294795.111000] [<881a0900>] dst_output+0x0/0x10 [4294795.111000] [<881c58dc>] icmp_reply+0x1a0/0x260 [4294795.111000] [] ip_confirm+0x4c/0x60 [ip_conntrack] [4294795.111000] [<881c6210>] icmp_echo+0x60/0x6c [4294795.111000] [] ip_nat_in+0x38/0xf0 [iptable_nat] [4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4 [4294795.111000] [<8819d0d4>] ip_rcv_finish+0x0/0x378 [4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4 [4294795.111000] [<881c6668>] icmp_rcv+0x138/0x220 [4294795.111000] [<8819cf74>] ip_local_deliver+0x204/0x364 [4294795.111000] [<8819cabc>] ip_local_deliver_finish+0x0/0x2b4 [4294795.111000] [<8819d7fc>] ip_rcv+0x3b0/0x6e4 [4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158 [4294795.111000] [<8819d0d4>] ip_rcv_finish+0x0/0x378 [4294795.111000] [<88182f14>] netif_receive_skb+0x1b8/0x250 [4294795.111000] [<88183088>] process_backlog+0xdc/0x20c [4294795.111000] [<88183284>] net_rx_action+0xcc/0x214 [4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158 [4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4 [4294795.111000] [<8802cf38>] do_softirq+0x90/0xbc [4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4 [4294795.111000] [<880065d4>] do_IRQ+0x24/0x34 [4294795.111000] [<88003640>] indyIRQ+0x120/0x180 [4294795.111000] [<8805bec4>] do_wp_page+0x280/0x524 [4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4 [4294795.111000] [<88258b14>] pidhash_init+0x164/0x1a4 [4294795.111000] [<88258ae0>] pidhash_init+0x130/0x1a4 [4294795.111000] [<88042574>] ktime_get+0x18/0x3c [4294795.111000] [<8800eacc>] do_page_fault+0x9c/0x3d0 [4294795.111000] [<8805e328>] find_vma+0x58/0x98 [4294795.111000] [<882581e0>] printk_time_setup+0x8/0x20 [4294795.111000] [<88031b34>] run_timer_softirq+0x34/0x240 [4294795.111000] [<8802cde0>] __do_softirq+0x90/0x158 [4294795.111000] [<8800f264>] tlb_do_page_fault_0+0x104/0x10c [4294795.111000] [<88003628>] indyIRQ+0x108/0x180 [4294795.111000]=20 --=-tIl8GAIL7RIslTNcG5/k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEYSTizjWM3BBT1QARAqugAJ43Av08oLkToa9c8jbUqaqRrIv/OwCdEoGP KhbA/FCXCvMTue8hlklzv6g= =0yGr -----END PGP SIGNATURE----- --=-tIl8GAIL7RIslTNcG5/k-- From sam@catalyst.net.nz Wed May 10 01:29:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 01:29:19 +0200 (CEST) Received: from godel.catalyst.net.nz ([202.78.240.40]:52947 "EHLO mail1.catalyst.net.nz") by ftp.linux-mips.org with ESMTP id S8133882AbWEIX3L (ORCPT ); Wed, 10 May 2006 01:29:11 +0200 Received: from leibniz.catalyst.net.nz ([202.78.240.7] helo=pkunk.wgtn.cat-it.co.nz) by mail1.catalyst.net.nz with esmtps (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1Fdbdc-0004z0-IJ for linux-mips@linux-mips.org; Wed, 10 May 2006 11:29:08 +1200 Subject: Re: "Badness in local_bh_enable at kernel/softirq.c:140" - sgiseeq and conntrack? From: Sam Cannell To: linux-mips@linux-mips.org In-Reply-To: <1147217122.20432.14.camel@pkunk.wgtn.cat-it.co.nz> References: <1147217122.20432.14.camel@pkunk.wgtn.cat-it.co.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8x+rN4crMdDDZTOsQsq1" Date: Wed, 10 May 2006 11:29:07 +1200 Message-Id: <1147217347.20432.17.camel@pkunk.wgtn.cat-it.co.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sam@catalyst.net.nz Precedence: bulk X-list: linux-mips Content-Length: 809 Lines: 28 --=-8x+rN4crMdDDZTOsQsq1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sorry .. should have said - I'm running 2.6.16.11. On Wed, 2006-05-10 at 11:25 +1200, Sam Cannell wrote: > [4294795.111000] Badness in local_bh_enable at kernel/softirq.c:140 > [4294795.111000] Call Trace: > [4294795.111000] [<8802cfdc>] local_bh_enable+0x78/0xa0 > [4294795.111000] [] destroy_conntrack+0xdc/0x178 > [ip_conntrack] --=-8x+rN4crMdDDZTOsQsq1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEYSXDzjWM3BBT1QARAmr1AJ4jlPRuKyFQPOj6jTmwYLlT25drlQCaA1SJ VyrTGpLIQeYqielzRvSVu/s= =EQqU -----END PGP SIGNATURE----- --=-8x+rN4crMdDDZTOsQsq1-- From rongkai.zhan@windriver.com Wed May 10 04:21:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 04:21:26 +0200 (CEST) Received: from mail.windriver.com ([147.11.1.11]:27825 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8126484AbWEJCVQ (ORCPT ); Wed, 10 May 2006 04:21:16 +0200 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k4A2L7V8006878; Tue, 9 May 2006 19:21:07 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 19:21:07 -0700 Received: from [192.168.96.26] ([192.168.96.26]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 19:21:06 -0700 Message-ID: <44614E0F.2000207@windriver.com> Date: Wed, 10 May 2006 10:21:03 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ralf Baechle CC: Alex Gonzalez , linux-mips@linux-mips.org Subject: Re: Boot time memory allocation References: <20060509163411.GA8528@linux-mips.org> In-Reply-To: <20060509163411.GA8528@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2006 02:21:07.0061 (UTC) FILETIME=[64F5FA50:01C673D8] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 1130 Lines: 28 Ralf Baechle wrote: > On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote: > >> I have two independent processors with access to a shared memory >> region, mapped in the 256MB to 512MB region (kseg0). >> >> One is running a propietary OS, and the second one is running Linux 2.6.12. >> >> How would I arrange to leave that shared memory region out of the >> scope of Linux's memory management system, but at the same time make >> it possible for a driver to access it? >> >> I have done similar things before with the help of alloc_bootmem, but >> this time I don't want the kernel to reserve the memory, I want the >> kernel to be completely unaware of it, and I need to specify its start >> and end. > > At kernel initialization time just don't tell the kernel about the > existence of your memory region. For many systems that just means you > shrink the memory region passed to the add_memory_region() call to > something that suits your platform. > > Ralf > Maybe it is a more flexible way to specify the memory regions via command line. You know, this will produce User-defined memory regions to kernel. From rongkai.zhan@windriver.com Wed May 10 04:41:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 04:41:37 +0200 (CEST) Received: from mail.windriver.com ([147.11.1.11]:28860 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S8126484AbWEJCl3 (ORCPT ); Wed, 10 May 2006 04:41:29 +0200 Received: from ala-mail04.corp.ad.wrs.com (ala-mail04 [147.11.57.145]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id k4A2fKum009855; Tue, 9 May 2006 19:41:22 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ala-mail04.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 19:41:20 -0700 Received: from [192.168.96.26] ([192.168.96.26]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 19:41:19 -0700 Message-ID: <446152CC.6020904@windriver.com> Date: Wed, 10 May 2006 10:41:16 +0800 From: "Mark.Zhan" User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support References: <445C6694.6010901@windriver.com> <20060509164127.GA10647@linux-mips.org> In-Reply-To: <20060509164127.GA10647@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2006 02:41:19.0553 (UTC) FILETIME=[37A99310:01C673DB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 1005 Lines: 34 Ralf Baechle wrote: > On Sat, May 06, 2006 at 05:04:20PM +0800, Mark.Zhan wrote: > >> According to your comments, I re-create the patch. Hopefully, no line-wrapped problems:-) >> Patch 1 and 2 in the original mails are concatenated into one patch in this mail. > > Well, this patch was still somewhat corrupt, a few spaces were missing Huhh, I don't what's wrong with my thunderbird. > but I was somehow able to talk git into taking it. So it's applied on > the queue branch. > > Ralf After looking into the changeset ac58afdfac792c0583af30dbd9eae53e24c78b, I find what I want to do has been done by you:-) For those MIPS32 boards which only use IRQ_CPU, I think, we can provide a default plat_irq_dispatch() implemention, maybe like this: asmlinkage plat_irq_dispatch(struct pt_regs *regs) { unsigned int pending = read_c0_status() & read_c0_cause(); int irq; irq = ffs(pending >> 8) - 1; return do_IRQ(irq, regs); } I this it will clean up more codes...... Best Regards, Mark.Zhan From anemo@mba.ocn.ne.jp Wed May 10 08:36:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 08:36:22 +0200 (CEST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:60143 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133397AbWEJGgN (ORCPT ); Wed, 10 May 2006 08:36:13 +0200 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 10 May 2006 15:36:12 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 66EC62045A; Wed, 10 May 2006 15:36:05 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 524AD1FFEB; Wed, 10 May 2006 15:36:05 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k4A6a44D099735; Wed, 10 May 2006 15:36:05 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 10 May 2006 15:36:04 +0900 (JST) Message-Id: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] use generic DWARF_DEBUG From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1295 Lines: 32 When debugging a kernel compiled by gcc 4.1 with gdb 6.4, gdb could not show filename, linenumber, etc. It seems fixed if I used generic DWARF_DEBUG macro. Although gcc 3.x seems work without this change, it would be better to use the generic macro unless there were something MIPS specific. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 14fa00e..73f7aca 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -155,16 +155,9 @@ #endif converted to the new style linker. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } - /* DWARF debug sections. - Symbols in the .debug DWARF section are relative to the beginning of the - section so we begin .debug at 0. It's not clear yet what needs to happen - for the others. */ - .debug 0 : { *(.debug) } - .debug_srcinfo 0 : { *(.debug_srcinfo) } - .debug_aranges 0 : { *(.debug_aranges) } - .debug_pubnames 0 : { *(.debug_pubnames) } - .debug_sfnames 0 : { *(.debug_sfnames) } - .line 0 : { *(.line) } + + DWARF_DEBUG + /* These must appear regardless of . */ .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } .gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) } From ths@networkno.de Wed May 10 09:21:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 09:22:07 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:42402 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133397AbWEJHV7 (ORCPT ); Wed, 10 May 2006 09:21:59 +0200 Received: from lagash (88-106-136-76.dynamic.dsl.as9105.com [88.106.136.76]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id C4C6F44F44; Wed, 10 May 2006 09:20:01 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1Fdiyv-00064B-Pb; Wed, 10 May 2006 08:19:37 +0100 Date: Wed, 10 May 2006 08:19:37 +0100 To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG Message-ID: <20060510071937.GA7813@networkno.de> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 464 Lines: 12 Atsushi Nemoto wrote: > When debugging a kernel compiled by gcc 4.1 with gdb 6.4, gdb could > not show filename, linenumber, etc. It seems fixed if I used generic > DWARF_DEBUG macro. Although gcc 3.x seems work without this change, > it would be better to use the generic macro unless there were > something MIPS specific. There was something MIPS specific for n64 (DWARF64) uuntil very recently. GCC HEAD switched n64 Linux to DWARF32 some days ago. Thiemo From anemo@mba.ocn.ne.jp Wed May 10 09:56:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 09:56:29 +0200 (CEST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:28404 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133407AbWEJH4V (ORCPT ); Wed, 10 May 2006 09:56:21 +0200 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 10 May 2006 16:56:20 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 873932035A; Wed, 10 May 2006 16:56:17 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7C84F2034F; Wed, 10 May 2006 16:56:17 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k4A7uH4D099994; Wed, 10 May 2006 16:56:17 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 10 May 2006 16:56:16 +0900 (JST) Message-Id: <20060510.165616.108981664.nemoto@toshiba-tops.co.jp> To: ths@networkno.de Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG From: Atsushi Nemoto In-Reply-To: <20060510071937.GA7813@networkno.de> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> <20060510071937.GA7813@networkno.de> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 625 Lines: 18 On Wed, 10 May 2006 08:19:37 +0100, Thiemo Seufer wrote: > There was something MIPS specific for n64 (DWARF64) uuntil very > recently. GCC HEAD switched n64 Linux to DWARF32 some days ago. The MIPS specifis issue for n64 is covered by current vmlinux.lds.S ? If no, the patch would have no bad side-effects. Also, I suppose we can use STABS_DEBUG too, but not sure. Current MIPS vmlinux.lds.S have this line: .comment : { *(.comment) } and it seems conflicts with a .comment line in STABS_DEBUG. Can we use generic STABS_DEBUG and drop the .comment line in mips vmlinux.lds.S ? --- Atsushi Nemoto From geert@linux-m68k.org Wed May 10 10:27:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 10:27:38 +0200 (CEST) Received: from witte.sonytel.be ([80.88.33.193]:6575 "EHLO witte.sonytel.be") by ftp.linux-mips.org with ESMTP id S8133407AbWEJI1a (ORCPT ); Wed, 10 May 2006 10:27:30 +0200 Received: from pademelon.sonytel.be (mail.sonytel.be [43.221.60.197]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id k4A8RPCQ015616; Wed, 10 May 2006 10:27:25 +0200 (MEST) Date: Wed, 10 May 2006 10:27:25 +0200 (CEST) From: Geert Uytterhoeven To: Martin Michlmayr cc: Ralf Baechle , Linux/MIPS Development Subject: Re: [PATCH] [MIPS] create consistency in "system type" selection In-Reply-To: <20060509213453.GA32050@deprecation.cyrius.com> Message-ID: References: <20060509213453.GA32050@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips Content-Length: 755 Lines: 20 On Tue, 9 May 2006, Martin Michlmayr wrote: > The "system type" Kconfig options on MIPS are not consistent. For > some platforms, only the name is listed while other entries are > prepended with "Support for". Remove this as it doesn't make sense > when describing the "system type". This is in line with how e.g. > ARM handles this. I guess the `Support for' prefix came from the era you could compile one kernel that supported multiple systems. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From langabe@gmail.com Wed May 10 11:11:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 11:11:53 +0200 (CEST) Received: from ug-out-1314.google.com ([66.249.92.175]:8303 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S8133407AbWEJJLo convert rfc822-to-8bit (ORCPT ); Wed, 10 May 2006 11:11:44 +0200 Received: by ug-out-1314.google.com with SMTP id e2so213029ugf for ; Wed, 10 May 2006 02:11:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e19b4B2B1d+PNv8jr4+5yZ6RtfCGU2WuuS/P2mdwkCnLtrWERkKcNsPLqhoGmiJ1cBqG3fJssk8X11tWCF68al3uFNfpzrnysd0gOlwPbcB7hAQH5bfh5J2LpR9QkLjjogmLRQg1jXh1ngSqQUxW35natS3j5657F+oCMpuZojA= Received: by 10.78.57.11 with SMTP id f11mr81793hua; Wed, 10 May 2006 02:11:43 -0700 (PDT) Received: by 10.78.39.13 with HTTP; Wed, 10 May 2006 02:11:43 -0700 (PDT) Message-ID: Date: Wed, 10 May 2006 10:11:43 +0100 From: "Alex Gonzalez" To: Mark.Zhan Subject: Re: Boot time memory allocation Cc: "Ralf Baechle" , linux-mips@linux-mips.org In-Reply-To: <44614E0F.2000207@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <20060509163411.GA8528@linux-mips.org> <44614E0F.2000207@windriver.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: langabe@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1393 Lines: 38 Thanks for the answers. I wrongly assumed I wouldn't be able to access unspecified memory regions, or that I'd have to tweak it somehow. Regards, Alex On 5/10/06, Mark.Zhan wrote: > Ralf Baechle wrote: > > On Tue, May 09, 2006 at 03:35:14PM +0100, Alex Gonzalez wrote: > > > >> I have two independent processors with access to a shared memory > >> region, mapped in the 256MB to 512MB region (kseg0). > >> > >> One is running a propietary OS, and the second one is running Linux 2.6.12. > >> > >> How would I arrange to leave that shared memory region out of the > >> scope of Linux's memory management system, but at the same time make > >> it possible for a driver to access it? > >> > >> I have done similar things before with the help of alloc_bootmem, but > >> this time I don't want the kernel to reserve the memory, I want the > >> kernel to be completely unaware of it, and I need to specify its start > >> and end. > > > > At kernel initialization time just don't tell the kernel about the > > existence of your memory region. For many systems that just means you > > shrink the memory region passed to the add_memory_region() call to > > something that suits your platform. > > > > Ralf > > > > Maybe it is a more flexible way to specify the memory regions via > command line. You know, this will produce User-defined memory regions to > kernel. > From ralf@linux-mips.org Wed May 10 12:28:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 12:29:01 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:5007 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133513AbWEJK2y (ORCPT ); Wed, 10 May 2006 12:28:54 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4AASrBx004197; Wed, 10 May 2006 11:28:53 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4AASq7h004196; Wed, 10 May 2006 11:28:52 +0100 Date: Wed, 10 May 2006 11:28:52 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Martin Michlmayr , Linux/MIPS Development Subject: Re: [PATCH] [MIPS] create consistency in "system type" selection Message-ID: <20060510102852.GA3193@linux-mips.org> References: <20060509213453.GA32050@deprecation.cyrius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 705 Lines: 17 On Wed, May 10, 2006 at 10:27:25AM +0200, Geert Uytterhoeven wrote: > On Tue, 9 May 2006, Martin Michlmayr wrote: > > The "system type" Kconfig options on MIPS are not consistent. For > > some platforms, only the name is listed while other entries are > > prepended with "Support for". Remove this as it doesn't make sense > > when describing the "system type". This is in line with how e.g. > > ARM handles this. > > I guess the `Support for' prefix came from the era you could compile one kernel > that supported multiple systems. You still can but they need to be lumped together into a single group in the "System type" menu. In reality it's not terribly interesting and rarely tested. Ralf From ths@networkno.de Wed May 10 13:24:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 13:25:04 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:55249 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133474AbWEJLYx (ORCPT ); Wed, 10 May 2006 13:24:53 +0200 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id 46B744455A; Wed, 10 May 2006 13:24:52 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1Fdmnn-0006yc-Kd; Wed, 10 May 2006 12:24:23 +0100 Date: Wed, 10 May 2006 12:24:23 +0100 From: Thiemo Seufer To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG Message-ID: <20060510112423.GC7813@networkno.de> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> <20060510071937.GA7813@networkno.de> <20060510.165616.108981664.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510.165616.108981664.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 894 Lines: 25 Atsushi Nemoto wrote: > On Wed, 10 May 2006 08:19:37 +0100, Thiemo Seufer wrote: > > There was something MIPS specific for n64 (DWARF64) uuntil very > > recently. GCC HEAD switched n64 Linux to DWARF32 some days ago. > > The MIPS specifis issue for n64 is covered by current vmlinux.lds.S ? > If no, the patch would have no bad side-effects. Well, I don't know since I don't use gdb on the kernel. I just wanted to give a heads-up there was a change, your patch might even be a fix for n64 kernels compiled with latest gcc. :-) > Also, I suppose we can use STABS_DEBUG too, but not sure. Current > MIPS vmlinux.lds.S have this line: > > .comment : { *(.comment) } > > and it seems conflicts with a .comment line in STABS_DEBUG. Can we > use generic STABS_DEBUG and drop the .comment line in mips > vmlinux.lds.S ? Isn't stabs in general deprecated by now? Thiemo From drow@nevyn.them.org Wed May 10 14:50:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 14:50:57 +0200 (CEST) Received: from nevyn.them.org ([66.93.172.17]:14796 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133520AbWEJMut (ORCPT ); Wed, 10 May 2006 14:50:49 +0200 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fdo9L-0000hz-0e; Wed, 10 May 2006 08:50:43 -0400 Date: Wed, 10 May 2006 08:50:42 -0400 From: Daniel Jacobowitz To: Thiemo Seufer Cc: Atsushi Nemoto , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG Message-ID: <20060510125042.GA2666@nevyn.them.org> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> <20060510071937.GA7813@networkno.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510071937.GA7813@networkno.de> User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 819 Lines: 19 On Wed, May 10, 2006 at 08:19:37AM +0100, Thiemo Seufer wrote: > Atsushi Nemoto wrote: > > When debugging a kernel compiled by gcc 4.1 with gdb 6.4, gdb could > > not show filename, linenumber, etc. It seems fixed if I used generic > > DWARF_DEBUG macro. Although gcc 3.x seems work without this change, > > it would be better to use the generic macro unless there were > > something MIPS specific. > > There was something MIPS specific for n64 (DWARF64) uuntil very > recently. GCC HEAD switched n64 Linux to DWARF32 some days ago. Shouldn't affect this. What Atsushi is deleting are sections for DWARF _1_, not DWARF _2_; that's ancient history. I don't know why they need to be listed at all, though; I've never had a problem, and orphan placement ought to take care of it. -- Daniel Jacobowitz CodeSourcery From dusko.dobranic@micronasnit.com Wed May 10 15:24:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 15:24:55 +0200 (CEST) Received: from krt.tmd.ns.ac.yu ([147.91.177.65]:45251 "EHLO krt.neobee.net") by ftp.linux-mips.org with ESMTP id S8133520AbWEJNYr (ORCPT ); Wed, 10 May 2006 15:24:47 +0200 Received: from localhost (localhost [127.0.0.1]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id k4ADn5Z7009477 for ; Wed, 10 May 2006 15:49:10 +0200 Received: from krt.neobee.net ([127.0.0.1]) by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08252-08 for ; Wed, 10 May 2006 15:49:05 +0200 (CEST) Received: from [192.168.0.91] ([192.168.0.91]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id k4ADn1UQ009466 for ; Wed, 10 May 2006 15:49:02 +0200 Message-ID: <4461E993.3080309@micronasnit.com> Date: Wed, 10 May 2006 15:24:35 +0200 From: Dusko Dobranic User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: gcc-4.0.3, gcc-4.1.0 no output with out Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at krt.neobee.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dusko.dobranic@micronasnit.com Precedence: bulk X-list: linux-mips Content-Length: 3632 Lines: 109 Simple examples compiled with gcc-4.0.3 or gcc-4.1.0 not producing output. There is a piece of code: for (i = 0; i < v.size(); i++) { out << v[i].s << " :\t" << v[i].t * (double(1000000)/n)/CLOCKS_PER_SEC << " ms" << endl; // printf("%s :\t %2.3f ms\n", v[i].s, v[i].t * (double(1000000)/n)/CLOCKS_PER_SEC); } When execute, output looks like this: $./d_1++ 100000 ./d_1 100000 virtual px->f(1) : ms ptr-to-fct p[1](ps,1) : ms virtual x.f(1) : ms ptr-to-fct p[1](&s,1) : ms member px->g(1) : ms global g(ps,1) : ms member x.g(1) : ms global g(&s,1) : ms static X::h(1) : ms global h(1) : ms inline px->k(1) : ms macro K(ps,1) : ms inline x.k(1) : ms macro K(&s,1) : ms base1 member pc->g(i) : ms base2 member pc->gg(i) : ms base1 virtual pa->f(i) : ms base2 virtual pb->ff(i) : ms base1 down-cast cast(pa,pc) : ms base2 down-cast cast(pb,pc) : ms base1 up-cast cast(pc,pa) : ms base2 up-cast cast(pc,pb) : ms base2 cross-cast cast(pb,pa) : ms base1 down-cast2 cast(pa,pcc) : ms base2 down-cast cast(pb,pcc) : ms base1 up-cast cast(pcc,pa) : ms base2 up-cast2 cast(pcc,pb) : ms base2 cross-cast2 cast(pa,pb) : ms base1 cross-cast2 cast(pb,pa) : ms vbase member pd->gg(i) : ms vbase virtual pa->f(i) : ms vbase down-cast cast(pa,pd) : ms vbase up-cast cast(pd,pa) : ms vbase typeid(pa) : ms vbase typeid(pd) : ms pmf virtual (pa->*pmf)(i) : ms pmf (pa->*pmf)(i) : ms call by_ref(pp) : ms call by_val(pp) : ms call ptr-to-fct oper(h,glob) : ms call fct-obj oper(fct,glob) : ms Commented line with printf do produce output: # ./d_1 100000 ./d_1 100000 virtual px->f(1) : 0.5 ms ptr-to-fct p[1](ps,1) : 0.5 ms virtual x.f(1) : 0.5 ms ptr-to-fct p[1](&s,1) : 0.5 ms member px->g(1) : 0.5 ms global g(ps,1) : 0.5 ms member x.g(1) : 0.6 ms global g(&s,1) : 0.5 ms static X::h(1) : 0.4 ms global h(1) : 0.5 ms inline px->k(1) : 0.5 ms macro K(ps,1) : 0.2 ms inline x.k(1) : 0.5 ms macro K(&s,1) : 0.2 ms base1 member pc->g(i) : 0.5 ms base2 member pc->gg(i) : 0.5 ms base1 virtual pa->f(i) : 0.6 ms base2 virtual pb->ff(i) : 0.6 ms base1 down-cast cast(pa,pc) : 0.5 ms base2 down-cast cast(pb,pc) : 0.6 ms base1 up-cast cast(pc,pa) : 2.4 ms base2 up-cast cast(pc,pb) : 2.2 ms base2 cross-cast cast(pb,pa) : 4.7 ms base1 down-cast2 cast(pa,pcc) : 0.5 ms base2 down-cast cast(pb,pcc) : 0.6 ms base1 up-cast cast(pcc,pa) : 2.4 ms base2 up-cast2 cast(pcc,pb) : 2.2 ms base2 cross-cast2 cast(pa,pb) : 4.7 ms base1 cross-cast2 cast(pb,pa) : 4.3 ms vbase member pd->gg(i) : 0.6 ms vbase virtual pa->f(i) : 0.9 ms vbase down-cast cast(pa,pd) : 0.7 ms vbase up-cast cast(pd,pa) : 4.4 ms vbase typeid(pa) : 0.8 ms vbase typeid(pd) : 0.8 ms pmf virtual (pa->*pmf)(i) : 1.2 ms pmf (pa->*pmf)(i) : 0.7 ms call by_ref(pp) : 0.5 ms call by_val(pp) : 0.5 ms call ptr-to-fct oper(h,glob) : 0.8 ms call fct-obj oper(fct,glob) : 0.8 ms When using gcc-3.4.2 everything is OK. From ralf@linux-mips.org Wed May 10 16:08:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 16:08:42 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:54977 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133621AbWEJOIf (ORCPT ); Wed, 10 May 2006 16:08:35 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4AE8XjX010166; Wed, 10 May 2006 15:08:33 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4AE8Vxu010165; Wed, 10 May 2006 15:08:31 +0100 Date: Wed, 10 May 2006 15:08:31 +0100 From: Ralf Baechle To: Daniel Jacobowitz Cc: Thiemo Seufer , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG Message-ID: <20060510140831.GC8063@linux-mips.org> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> <20060510071937.GA7813@networkno.de> <20060510125042.GA2666@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510125042.GA2666@nevyn.them.org> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 428 Lines: 11 On Wed, May 10, 2006 at 08:50:42AM -0400, Daniel Jacobowitz wrote: > Shouldn't affect this. What Atsushi is deleting are sections for DWARF > _1_, not DWARF _2_; that's ancient history. I don't know why they need > to be listed at all, though; I've never had a problem, and orphan > placement ought to take care of it. I think this goes back to this file being derived from one of the binutils generated ld scripts. Ralf From ralf@linux-mips.org Wed May 10 16:57:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 16:57:19 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:11212 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133637AbWEJO5M (ORCPT ); Wed, 10 May 2006 16:57:12 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4AEvBNc015247; Wed, 10 May 2006 15:57:11 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4AEvBuf015246; Wed, 10 May 2006 15:57:11 +0100 Date: Wed, 10 May 2006 15:57:11 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG Message-ID: <20060510145711.GA11961@linux-mips.org> References: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060510.153604.82350680.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 402 Lines: 13 On Wed, May 10, 2006 at 03:36:04PM +0900, Atsushi Nemoto wrote: > When debugging a kernel compiled by gcc 4.1 with gdb 6.4, gdb could > not show filename, linenumber, etc. It seems fixed if I used generic > DWARF_DEBUG macro. Although gcc 3.x seems work without this change, > it would be better to use the generic macro unless there were > something MIPS specific. Okay, applied. Thanks! Ralf From ralf@linux-mips.org Wed May 10 17:32:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 17:32:25 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:3807 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133520AbWEJPcS (ORCPT ); Wed, 10 May 2006 17:32:18 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4AFWGZd016165; Wed, 10 May 2006 16:32:16 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4AFWGsx016164; Wed, 10 May 2006 16:32:16 +0100 Date: Wed, 10 May 2006 16:32:16 +0100 From: Ralf Baechle To: "Mark.Zhan" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Wind River 4KC PPMC Eval Board Support Message-ID: <20060510153215.GB11961@linux-mips.org> References: <445C6694.6010901@windriver.com> <20060509164127.GA10647@linux-mips.org> <446152CC.6020904@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <446152CC.6020904@windriver.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1037 Lines: 29 On Wed, May 10, 2006 at 10:41:16AM +0800, Mark.Zhan wrote: > After looking into the changeset ac58afdfac792c0583af30dbd9eae53e24c78b, > I find what I want to do has been done by you:-) I don't have this changeset in my tree; I assume you're refering to the patch titled "[MIPS] Rewrite all the assembler interrupt handlers to C". > For those MIPS32 boards which only use IRQ_CPU, I think, we can provide > a default plat_irq_dispatch() implemention, maybe like this: > > asmlinkage plat_irq_dispatch(struct pt_regs *regs) > { > unsigned int pending = read_c0_status() & read_c0_cause(); > int irq; > > irq = ffs(pending >> 8) - 1; > return do_IRQ(irq, regs); > } > > I this it will clean up more codes...... There are only few such extremly simple platforms in the tree. The purpose of me rewriting all the handlers to assembler was that many of the handlers has bugs that would not exist in a high level language and much of the code was not scheduled very well - something which gcc does pretty well these days. Ralf From ralf@linux-mips.org Wed May 10 17:35:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 17:35:35 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:39392 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133647AbWEJPf2 (ORCPT ); Wed, 10 May 2006 17:35:28 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4AFZRDv016266; Wed, 10 May 2006 16:35:27 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4AFZQes016265; Wed, 10 May 2006 16:35:26 +0100 Date: Wed, 10 May 2006 16:35:26 +0100 From: Ralf Baechle To: "Mark.Zhan" Cc: Alex Gonzalez , linux-mips@linux-mips.org Subject: Re: Boot time memory allocation Message-ID: <20060510153526.GC11961@linux-mips.org> References: <20060509163411.GA8528@linux-mips.org> <44614E0F.2000207@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44614E0F.2000207@windriver.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 681 Lines: 16 On Wed, May 10, 2006 at 10:21:03AM +0800, Mark.Zhan wrote: > >At kernel initialization time just don't tell the kernel about the > >existence of your memory region. For many systems that just means you > >shrink the memory region passed to the add_memory_region() call to > >something that suits your platform. > Maybe it is a more flexible way to specify the memory regions via > command line. You know, this will produce User-defined memory regions to > kernel. Maybe for a specific application or platform. For a sourcebase like linux-mips.org's with a very large number of users on sometimes very complex platforms I'd never ever think of exposing such details. Ralf From anemo@mba.ocn.ne.jp Wed May 10 17:40:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 17:40:58 +0200 (CEST) Received: from mba.ocn.ne.jp ([210.190.142.172]:22726 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133637AbWEJPku (ORCPT ); Wed, 10 May 2006 17:40:50 +0200 Received: from localhost (p5181-ipad27funabasi.chiba.ocn.ne.jp [220.107.196.181]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C64B1B499; Thu, 11 May 2006 00:40:44 +0900 (JST) Date: Thu, 11 May 2006 00:41:26 +0900 (JST) Message-Id: <20060511.004126.01916795.anemo@mba.ocn.ne.jp> To: ths@networkno.de Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] use generic DWARF_DEBUG From: Atsushi Nemoto In-Reply-To: <20060510112423.GC7813@networkno.de> References: <20060510071937.GA7813@networkno.de> <20060510.165616.108981664.nemoto@toshiba-tops.co.jp> <20060510112423.GC7813@networkno.de> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1369 Lines: 45 On Wed, 10 May 2006 12:24:23 +0100, Thiemo Seufer wrote: > > Also, I suppose we can use STABS_DEBUG too, but not sure. Current > > MIPS vmlinux.lds.S have this line: > > > > .comment : { *(.comment) } > > > > and it seems conflicts with a .comment line in STABS_DEBUG. Can we > > use generic STABS_DEBUG and drop the .comment line in mips > > vmlinux.lds.S ? > > Isn't stabs in general deprecated by now? I think so, but someone might think it's still useful since its size is much smaller. (less than half or so) Anyway, how about this patch? [PATCH] use generic STABS_DEBUG macro. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 73f7aca..b84d1f9 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -151,16 +151,13 @@ SECTIONS /* This is the MIPS specific mdebug section. */ .mdebug : { *(.mdebug) } - /* These are needed for ELF backends which have not yet been - converted to the new style linker. */ - .stab 0 : { *(.stab) } - .stabstr 0 : { *(.stabstr) } + + STABS_DEBUG DWARF_DEBUG /* These must appear regardless of . */ .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } .gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) } - .comment : { *(.comment) } .note : { *(.note) } } From tbm@cyrius.com Wed May 10 22:46:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 May 2006 22:46:27 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:57362 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133716AbWEJUqU (ORCPT ); Wed, 10 May 2006 22:46:20 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 2B3D864D54; Wed, 10 May 2006 20:46:12 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id CE23B66B6D; Wed, 10 May 2006 22:46:01 +0200 (CEST) Date: Wed, 10 May 2006 22:46:01 +0200 From: Martin Michlmayr To: karsten@excalibur.cologne.de Cc: linux-mips@linux-mips.org Subject: pmag* drivers don't build on 2.6 Message-ID: <20060510204601.GA23786@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 187 Lines: 6 The pmag* fb drivers (DECstation) don't build on 2.6. Can someone port them to the 2.6 api (and possibly merge both files into one)? Karsten? -- Martin Michlmayr http://www.cyrius.com/ From kumba@gentoo.org Thu May 11 04:48:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 04:48:42 +0200 (CEST) Received: from sccrmhc12.comcast.net ([204.127.200.82]:39076 "EHLO sccrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S8133354AbWEKCse (ORCPT ); Thu, 11 May 2006 04:48:34 +0200 Received: from [127.0.0.1] (unknown[69.140.185.48]) by comcast.net (sccrmhc12) with ESMTP id <200605110248280120068b1me>; Thu, 11 May 2006 02:48:28 +0000 Message-ID: <4462A603.7080409@gentoo.org> Date: Wed, 10 May 2006 22:48:35 -0400 From: Kumba User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Linux/MIPS Development Subject: Re: [PATCH] [MIPS] create consistency in "system type" selection References: <20060509213453.GA32050@deprecation.cyrius.com> <20060510102852.GA3193@linux-mips.org> In-Reply-To: <20060510102852.GA3193@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 794 Lines: 22 Ralf Baechle wrote: > You still can but they need to be lumped together into a single group > in the "System type" menu. In reality it's not terribly interesting > and rarely tested. > > Ralf Isn't the real blocker for a multi-system kernel the Load Address? I know w/ the different SGI system most of the kernels load at a different address. Is it possible to encode all of these in a way that each system could detect them, or would we need some kind of stub loader ala arcload that'd have to be pre-pended onto the image to handle that for us? --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From macro@linux-mips.org Thu May 11 14:21:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 14:21:30 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:20232 "HELO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with SMTP id S8133401AbWEKMVW (ORCPT ); Thu, 11 May 2006 14:21:22 +0200 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D6B7DF5F85; Thu, 11 May 2006 14:21:17 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15766-07; Thu, 11 May 2006 14:21:17 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 6A0BAF5F2E; Thu, 11 May 2006 14:21:17 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.6/8.13.1) with ESMTP id k4BCLN6L023860; Thu, 11 May 2006 14:21:24 +0200 Date: Thu, 11 May 2006 13:21:20 +0100 (BST) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: karsten@excalibur.cologne.de, linux-mips@linux-mips.org Subject: Re: pmag* drivers don't build on 2.6 In-Reply-To: <20060510204601.GA23786@deprecation.cyrius.com> Message-ID: References: <20060510204601.GA23786@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.2/1456/Thu May 11 07:57:31 2006 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 652 Lines: 16 On Wed, 10 May 2006, Martin Michlmayr wrote: > The pmag* fb drivers (DECstation) don't build on 2.6. Can someone > port them to the 2.6 api (and possibly merge both files into one)? The pmag-ba-fb and pmagb-b-fb drivers have been ported. If there is any problem with them, then I'd like to know about that. The pmag-aa-fb driver has not been ported. I may have a look at it, but I have no hardware to test any changes with. I don't see any point in merging any set of these drivers together -- they support cards of completely different architecture each. OTOH, merging the pmagb-b-fb driver with tgafb may make sense one day. Maciej From tbm@cyrius.com Thu May 11 14:30:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 14:30:44 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:39945 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133401AbWEKMaf (ORCPT ); Thu, 11 May 2006 14:30:35 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id CC85164D55; Thu, 11 May 2006 12:30:26 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 6147066F5B; Thu, 11 May 2006 14:30:16 +0200 (CEST) Date: Thu, 11 May 2006 14:30:16 +0200 From: Martin Michlmayr To: "Maciej W. Rozycki" Cc: karsten@excalibur.cologne.de, linux-mips@linux-mips.org Subject: Re: pmag* drivers don't build on 2.6 Message-ID: <20060511123016.GH7827@deprecation.cyrius.com> References: <20060510204601.GA23786@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 635 Lines: 15 * Maciej W. Rozycki [2006-05-11 13:21]: > > The pmag* fb drivers (DECstation) don't build on 2.6. Can someone > > port them to the 2.6 api (and possibly merge both files into one)? > > The pmag-ba-fb and pmagb-b-fb drivers have been ported. If there is any > problem with them, then I'd like to know about that. > > The pmag-aa-fb driver has not been ported. Ah, yeah, sorry. I saw a build failure in pmag-aa-fb and thought all pmag* drivers were out of date so I didn't try to compile the other drivers. I'm glad to hear that you have ported the other two! -- Martin Michlmayr http://www.cyrius.com/ From macro@linux-mips.org Thu May 11 14:42:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 14:42:38 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:1546 "HELO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with SMTP id S8133401AbWEKMm3 (ORCPT ); Thu, 11 May 2006 14:42:29 +0200 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 05AE0F5F00; Thu, 11 May 2006 14:42:25 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27536-02; Thu, 11 May 2006 14:42:24 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 9A760F5EF0; Thu, 11 May 2006 14:42:24 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.6/8.13.1) with ESMTP id k4BCgV5L031413; Thu, 11 May 2006 14:42:31 +0200 Date: Thu, 11 May 2006 13:42:28 +0100 (BST) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: karsten@excalibur.cologne.de, linux-mips@linux-mips.org Subject: Re: pmag* drivers don't build on 2.6 In-Reply-To: <20060511123016.GH7827@deprecation.cyrius.com> Message-ID: References: <20060510204601.GA23786@deprecation.cyrius.com> <20060511123016.GH7827@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.2/1456/Thu May 11 07:57:31 2006 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 440 Lines: 11 On Thu, 11 May 2006, Martin Michlmayr wrote: > Ah, yeah, sorry. I saw a build failure in pmag-aa-fb and thought all > pmag* drivers were out of date so I didn't try to compile the other > drivers. I'm glad to hear that you have ported the other two! Please note we are also more or less a weekend away only from pixel clock and resolution control in pmagb-b-fb. Not that I can point at any particular weekend, though. ;-) Maciej From djd20@kent.ac.uk Thu May 11 15:09:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 15:09:32 +0200 (CEST) Received: from mx5.kent.ac.uk ([129.12.21.36]:47041 "EHLO mx5.kent.ac.uk") by ftp.linux-mips.org with ESMTP id S8133437AbWEKNJW (ORCPT ); Thu, 11 May 2006 15:09:22 +0200 Received: from apophis.ukc.ac.uk ([129.12.4.11]) by mx5.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1FeAum-0000zS-5z for linux-mips@linux-mips.org; Thu, 11 May 2006 14:09:12 +0100 Received: from myrtle.ukc.ac.uk ([129.12.3.176] ident=exim) by apophis.ukc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1FeAul-0007gy-Ur for linux-mips@linux-mips.org; Thu, 11 May 2006 14:09:11 +0100 Received: from fingerpoken.ukc.ac.uk ([129.12.16.14]) by myrtle.ukc.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1FeAul-0001Qw-Pd for linux-mips@linux-mips.org; Thu, 11 May 2006 14:09:11 +0100 From: Damian Dimmich To: linux-mips@linux-mips.org Subject: seeq driver possibly broken in 2.6.17-rc3-g8f3468ed? Date: Thu, 11 May 2006 14:00:42 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111400.42087.djd20@kent.ac.uk> X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: djd20@kent.ac.uk Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djd20@kent.ac.uk Precedence: bulk X-list: linux-mips Content-Length: 1601 Lines: 48 Hello, I've just compiled a fresh 2.6.17-rc3-g8f3468ed kernel from linux-mips git for my indigo2. The network card seems to have gone wonky, while the seeq driver loads fine: -- snip -- Serial: IP22 Zilog driver (1 chips). ttyS0 at MMIO 0xc000e830 (irq = 45) is a IP22-Zilog Console: ttyS0 (IP22-Zilog) ttyS1 at MMIO 0xc0010838 (irq = 45) is a IP22-Zilog eth0: SGI Seeq8003 08:00:69:08:43:b2 arcnet loaded. wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 -- snip -- when trying to do dhcp: indigo:~# dhclient eth0 Internet Software Consortium DHCP Client 2.0pl5 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved. Please contribute if you find this software useful. For info, please visit http://www.isc.org/dhcp-contrib.html Listening on LPF/eth0/08:00:69:08:43:b2 Sending on LPF/eth0/08:00:69:08:43:b2 Sending on Socket/fallback/fallback-net DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 receive_packet failed on eth0: Network is down even though the network is up... The kernel is compiled in 32bit mode, and everything seems fine otherwise. I am running debian which comes with a 2.4.27 kernel by default, with which the seeq card works fine. There seems to be a lot of packets being sent though, as the light at the other end of the cable blinks a lot. The kernel was compiled with: gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) No errors seem to show up aside rom the recieve_packet failed anywhere... Any ideas? Please let me know if I can provide any more useful info. Cheers, Damian From ralf@linux-mips.org Thu May 11 18:33:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 18:33:33 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:6039 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133503AbWEKQdZ (ORCPT ); Thu, 11 May 2006 18:33:25 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4BGXPDM030081; Thu, 11 May 2006 17:33:25 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4BGXPAo030080; Thu, 11 May 2006 17:33:25 +0100 Date: Thu, 11 May 2006 17:33:25 +0100 From: Ralf Baechle To: Damian Dimmich Cc: linux-mips@linux-mips.org Subject: Re: seeq driver possibly broken in 2.6.17-rc3-g8f3468ed? Message-ID: <20060511163325.GB26812@linux-mips.org> References: <200605111400.42087.djd20@kent.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605111400.42087.djd20@kent.ac.uk> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 402 Lines: 12 On Thu, May 11, 2006 at 02:00:42PM +0100, Damian Dimmich wrote: > Hello, > > I've just compiled a fresh 2.6.17-rc3-g8f3468ed kernel from linux-mips git for > my indigo2. The network card seems to have gone wonky, while the seeq driver > loads fine: Can you try to git bisect to find the bug? The reason for this bug isn't obvious; the Indy network driver was last changed last October. Ralf From ralf@linux-mips.org Thu May 11 18:43:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 18:43:42 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:5050 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133408AbWEKQnf (ORCPT ); Thu, 11 May 2006 18:43:35 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4BGhOdA030402; Thu, 11 May 2006 17:43:24 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4BGhOMe030401; Thu, 11 May 2006 17:43:24 +0100 Date: Thu, 11 May 2006 17:43:24 +0100 From: Ralf Baechle To: Shane McDonald Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] improve readability of arch/mips/Kconfig Message-ID: <20060511164323.GC26812@linux-mips.org> References: <200605062147.k46Llrfb024188@duval.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605062147.k46Llrfb024188@duval.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 214 Lines: 9 On Sat, May 06, 2006 at 03:47:53PM -0600, Shane McDonald wrote: > Oops, heh heh. One last time before I crawl back under my rock... You can return from your rock, this patch was ok ;-) Thanks, applied, Ralf From tbm@cyrius.com Thu May 11 19:31:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 19:31:49 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:17676 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133647AbWEKRbk (ORCPT ); Thu, 11 May 2006 19:31:40 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 2F65864D54; Thu, 11 May 2006 17:30:48 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 7146266F5C; Thu, 11 May 2006 19:30:25 +0200 (CEST) Date: Thu, 11 May 2006 19:30:25 +0200 From: Martin Michlmayr To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: DECstation R3000 boot error Message-ID: <20060511173025.GA28209@deprecation.cyrius.com> References: <20060124122700.GA8527@deprecation.cyrius.com> <20060124232117.GA4165@codecarver> <20060203150232.GA25701@deprecation.cyrius.com> <20060213225927.GB4226@deprecation.cyrius.com> <20060213232329.GA8286@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 887 Lines: 17 * Maciej W. Rozycki [2006-02-14 10:01]: > The driver has been ported by JBG (thanks!) -- it's the zs.c driver > that needs to be ported to the new serial infrastructure. But > that's tough if to be done properly (DMA and synchronous modes are > not handled well by the serial core), so not at the moment, sorry. > I'll think about minimal functionality to keep it going though and > perhaps lk201.c could be changed to work with current zs.c as is > (dz.c has already been ported -- I have no way of testing it, so I > somewhat lack incentive to go through it and verify if it's at least > as good as the old driver in 2.4.)... Do you think you'll have time to port zs.c soon? I'd like to move away from 2.4 in Debian and DECstation is currently the only platform that isn't supported in 2.6 (or at least not fully). -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Thu May 11 19:35:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 19:35:20 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:19212 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133612AbWEKRfJ (ORCPT ); Thu, 11 May 2006 19:35:09 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 9906564D54; Thu, 11 May 2006 17:34:08 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id EDA5366F5C; Thu, 11 May 2006 19:33:50 +0200 (CEST) Date: Thu, 11 May 2006 19:33:50 +0200 From: Martin Michlmayr To: Karel van Houten , macro@linux-mips.org Cc: debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i Message-ID: <20060511173350.GM7827@deprecation.cyrius.com> References: <44635C0D.7040901@vhouten.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44635C0D.7040901@vhouten.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 9619 Lines: 229 * Karel van Houten [2006-05-11 17:45]: > * You don't seem to have included the DEC serial drivers and console > support for the /260, because after the prom-io I loose all output > on the serial line (my /260 has serial console only). Zilog Z8530 support for DECstation hasn't been ported to 2.6 yet. > * When I let it boot without console, it will happily go multiuser. > See boot messages below. > * My second SCSI card does not seem to work as it should. Works OK > under 2.4.27. Maciej, do you have any idea? kernel log: > Linux version 2.6.16-1-sb1-bcm91250a (Debian 2.6.16-12) > (waldi@debian.org) (gcc version 4.0.3 20051201 (prerelease) (Debian > 4.0.2-5)) #2 Tue May 9 21:11:55 UTC 2006 > This is a DECstation 5000/2x0 > CPU revision is: 00000440 > FPU revision is: 00000500 > Determined physical RAM map: > memory: 10000000 @ 00000000 (usable) > On node 0 totalpages: 65536 > DMA zone: 65536 pages, LIFO batch:15 > DMA32 zone: 0 pages, LIFO batch:0 > Normal zone: 0 pages, LIFO batch:0 > HighMem zone: 0 pages, LIFO batch:0 > Built 1 zonelists > Kernel command line: root=/dev/sda1 console=ttyS2 > Primary instruction cache 16kB, physically tagged, direct mapped, > linesize 16 bytes. > Primary data cache 16kB, direct mapped, linesize 16 bytes. > Unified secondary cache 1024kB direct mapped, linesize 32 bytes. > Synthesized TLB refill handler (21 instructions). > Synthesized TLB load handler fastpath (33 instructions). > Synthesized TLB store handler fastpath (33 instructions). > Synthesized TLB modify handler fastpath (32 instructions). > PID hash table entries: 2048 (order: 11, 32768 bytes) > Using 59.999 MHz high precision timer. > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 256224k/262144k available (2270k kernel code, 5716k reserved, > 414k data, 136k init, 0k highmem) > Calibrating delay loop... 59.86 BogoMIPS (lpj=233472) > Security Framework v1.0.0 initialized > SELinux: Disabled at boot. > Capability LSM initialized > Mount-cache hash table entries: 512 > Checking for 'wait' instruction... unavailable. > NET: Registered protocol family 16 > SCSI subsystem initialized > TURBOchannel rev. 1 at 25.0 MHz (without parity) > slot 1: DEC PMAZ-AA V5.3d > audit: initializing netlink socket (disabled) > audit(1147360779.414:1): initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > Initializing Cryptographic API > io scheduler noop registered (default) > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered > rtc: I/O port 530579456 is not free. > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > declance.c: v0.009 by Linux MIPS DECstation task force > declance0: IOASIC onboard LANCE, addr = 08:00:2b:37:63:76, irq = 16 > declance0: registered as eth0. > SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) > SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236) > ESP: Total of 2 ESP hosts found, 2 actually in use. > scsi0 : ESP236 (NCR53C9x) > esp0: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0388 > Type: Direct-Access ANSI SCSI revision: 02 > scsi1 : ESP236 (NCR53C9x) > esp1: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0682 > Type: Direct-Access ANSI SCSI revision: 02 > esp1: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0388 > Type: Direct-Access ANSI SCSI revision: 02 > esp1: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0388 > Type: Direct-Access ANSI SCSI revision: 02 > esp1: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0388 > Type: Direct-Access ANSI SCSI revision: 02 > esp1: hoping for msgout > Vendor: COMPAQ Model: ST34371N Rev: 0682 > Type: Direct-Access ANSI SCSI revision: 02 > Vendor: SONY Model: CD-ROM CDU-55S Rev: 1.0t > Type: CD-ROM ANSI SCSI revision: 02 > SCSI device sda: 8386000 512-byte hdwr sectors (4294 MB) > sda: Write Protect is off > sda: Mode Sense: c7 00 10 08 > SCSI device sda: drive cache: write through w/ FUA > SCSI device sda: 8386000 512-byte hdwr sectors (4294 MB) > sda: Write Protect is off > sda: Mode Sense: c7 00 10 08 > SCSI device sda: drive cache: write through w/ FUA > sda: sda1 sda2 < sda5 > > sd 0:0:0:0: Attached scsi disk sda > esp1: Warning, live target 0 not responding to selection. > esp1: Resetting scsi bus > esp1: SCSI bus reset interrupt > esp1: SCSI bus reset interrupt > esp1: hoping for msgout > sd 1:0:0:0: scsi: Device offlined - not ready after error recovery > sd 1:0:0:0: rejecting I/O to offline device > sd 1:0:0:0: rejecting I/O to offline device > sd 1:0:0:0: rejecting I/O to offline device > sd 1:0:0:0: rejecting I/O to offline device > sdb : READ CAPACITY failed. > sdb : status=0, message=00, host=1, driver=00 > sdb : sense not available. > sd 1:0:0:0: rejecting I/O to offline device > sdb: Write Protect is off > sdb: Mode Sense: 00 00 00 00 > sd 1:0:0:0: rejecting I/O to offline device > sdb: asking for cache data failed > sdb: assuming drive cache: write through > sd 1:0:0:0: Attached scsi disk sdb > esp1: hoping for msgout > esp1: Warning, live target 1 not responding to selection. > esp1: Resetting scsi bus > esp1: SCSI bus reset interrupt > esp1: SCSI bus reset interrupt > esp1: hoping for msgout > sd 1:0:1:0: scsi: Device offlined - not ready after error recovery > sd 1:0:1:0: rejecting I/O to offline device > sd 1:0:1:0: rejecting I/O to offline device > sd 1:0:1:0: rejecting I/O to offline device > sd 1:0:1:0: rejecting I/O to offline device > sdc : READ CAPACITY failed. > sdc : status=0, message=00, host=1, driver=00 > sdc : sense not available. > sd 1:0:1:0: rejecting I/O to offline device > sdc: Write Protect is off > sdc: Mode Sense: 00 00 00 00 > sd 1:0:1:0: rejecting I/O to offline device > sdc: asking for cache data failed > sdc: assuming drive cache: write through > sd 1:0:1:0: Attached scsi disk sdc > esp1: hoping for msgout > esp1: Warning, live target 2 not responding to selection. > esp1: Resetting scsi bus > esp1: SCSI bus reset interrupt > esp1: SCSI bus reset interrupt > esp1: hoping for msgout > sd 1:0:2:0: scsi: Device offlined - not ready after error recovery > sd 1:0:2:0: rejecting I/O to offline device > sd 1:0:2:0: rejecting I/O to offline device > sd 1:0:2:0: rejecting I/O to offline device > sd 1:0:2:0: rejecting I/O to offline device > sdd : READ CAPACITY failed. > sdd : status=0, message=00, host=1, driver=00 > sdd : sense not available. > sd 1:0:2:0: rejecting I/O to offline device > sdd: Write Protect is off > sdd: Mode Sense: 00 00 00 00 > sd 1:0:2:0: rejecting I/O to offline device > sdd: asking for cache data failed > sdd: assuming drive cache: write through > sd 1:0:2:0: Attached scsi disk sdd > esp1: hoping for msgout > esp1: Warning, live target 3 not responding to selection. > esp1: Resetting scsi bus > esp1: SCSI bus reset interrupt > esp1: SCSI bus reset interrupt > esp1: hoping for msgout > sd 1:0:3:0: scsi: Device offlined - not ready after error recovery > sd 1:0:3:0: rejecting I/O to offline device > sd 1:0:3:0: rejecting I/O to offline device > sd 1:0:3:0: rejecting I/O to offline device > sd 1:0:3:0: rejecting I/O to offline device > sde : READ CAPACITY failed. > sde : status=0, message=00, host=1, driver=00 > sde : sense not available. > sd 1:0:3:0: rejecting I/O to offline device > sde: Write Protect is off > sde: Mode Sense: 00 00 00 00 > sd 1:0:3:0: rejecting I/O to offline device > sde: asking for cache data failed > sde: assuming drive cache: write through > sd 1:0:3:0: Attached scsi disk sde > esp1: hoping for msgout > esp1: Warning, live target 5 not responding to selection. > esp1: Resetting scsi bus > esp1: SCSI bus reset interrupt > esp1: SCSI bus reset interrupt > esp1: hoping for msgout > sd 1:0:5:0: scsi: Device offlined - not ready after error recovery > sd 1:0:5:0: rejecting I/O to offline device > sd 1:0:5:0: rejecting I/O to offline device > sd 1:0:5:0: rejecting I/O to offline device > sd 1:0:5:0: rejecting I/O to offline device > sdf : READ CAPACITY failed. > sdf : status=0, message=00, host=1, driver=00 > sdf : sense not available. > sd 1:0:5:0: rejecting I/O to offline device > sdf: Write Protect is off > sdf: Mode Sense: 00 00 00 00 > sd 1:0:5:0: rejecting I/O to offline device > sdf: asking for cache data failed > sdf: assuming drive cache: write through > sd 1:0:5:0: Attached scsi disk sdf > NET: Registered protocol family 2 > IP route cache hash table entries: 4096 (order: 2, 16384 bytes) > TCP established hash table entries: 16384 (order: 4, 65536 bytes) > TCP bind hash table entries: 16384 (order: 4, 65536 bytes) > TCP: Hash tables configured (established 16384 bind 16384) > TCP reno registered > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing unused PROM memory: 124k freed > Freeing unused kernel memory: 260k freed > Warning: unable to open an initial console. > Adding 208804k swap on /dev/sda5. Priority:-1 extents:1 across:208804k > EXT3 FS on sda1, internal journal > -- Martin Michlmayr http://www.cyrius.com/ From macro@linux-mips.org Thu May 11 20:14:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 20:14:31 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:48400 "HELO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with SMTP id S8133646AbWEKSOX (ORCPT ); Thu, 11 May 2006 20:14:23 +0200 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7A7CEF5F46; Thu, 11 May 2006 20:14:17 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03649-06; Thu, 11 May 2006 20:14:17 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 21C48F5EDE; Thu, 11 May 2006 20:14:17 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.6/8.13.1) with ESMTP id k4BIESus012304; Thu, 11 May 2006 20:14:28 +0200 Date: Thu, 11 May 2006 19:14:22 +0100 (BST) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: Karel van Houten , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i In-Reply-To: <20060511173350.GM7827@deprecation.cyrius.com> Message-ID: References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.2/1457/Thu May 11 19:25:16 2006 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1211 Lines: 27 On Thu, 11 May 2006, Martin Michlmayr wrote: > > * You don't seem to have included the DEC serial drivers and console > > support for the /260, because after the prom-io I loose all output > > on the serial line (my /260 has serial console only). > > Zilog Z8530 support for DECstation hasn't been ported to 2.6 yet. Well, not exactly ported, but hacked up enough it worked the last time I tried, but you have to disable the virtual terminal (CONFIG_VT) as it is the keyboard driver (lk201) that has not been ported at all. If in doubt, please start with "decstation_defconfig", that should build and boot successfully, and work from there. > > * When I let it boot without console, it will happily go multiuser. > > See boot messages below. > > * My second SCSI card does not seem to work as it should. Works OK > > under 2.4.27. > > Maciej, do you have any idea? I have a PMAZ-A around, though I am not sure if I have everything needed to wire it to a device (hmm, I should probably make sure if I am to be serious about adding support for the PMAZC...). Meanwhile I can have a look at the source code to see if there is anything obviously wrong there. Maciej From tbm@cyrius.com Thu May 11 20:55:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 May 2006 20:55:15 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:59916 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8133657AbWEKSzE (ORCPT ); Thu, 11 May 2006 20:55:04 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 53B9A64D55; Thu, 11 May 2006 18:54:56 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 1FD3F66F5B; Thu, 11 May 2006 20:54:46 +0200 (CEST) Date: Thu, 11 May 2006 20:54:46 +0200 From: Martin Michlmayr To: "Maciej W. Rozycki" Cc: Karel van Houten , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i Message-ID: <20060511185446.GB7234@deprecation.cyrius.com> References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 5801 Lines: 183 * Maciej W. Rozycki [2006-05-11 19:14]: > > Zilog Z8530 support for DECstation hasn't been ported to 2.6 yet. > > Well, not exactly ported, but hacked up enough it worked the last time I > tried, but you have to disable the virtual terminal (CONFIG_VT) as it is Yeah, but the problem is that ZS is not a config option anymore. I hacked up something to see if the driver works but I guess there's a nicer solution. --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -51,6 +51,8 @@ obj-$(CONFIG_VIOCONS) += viocons.o obj-$(CONFIG_VIOTAPE) += viotape.o obj-$(CONFIG_HVCS) += hvcs.o obj-$(CONFIG_SGI_MBCS) += mbcs.o +obj-$(CONFIG_SERIAL_DZ) += decserial.o +obj-$(CONFIG_SERIAL_ZS) += decserial.o obj-$(CONFIG_PRINTER) += lp.o obj-$(CONFIG_TIPAR) += tipar.o diff --git a/drivers/char/decserial.c b/drivers/char/decserial.c index aa14409..9a320c3 100644 --- a/drivers/char/decserial.c +++ b/drivers/char/decserial.c @@ -28,7 +28,7 @@ extern int zs_init(void); extern int dz_init(void); #endif -#ifdef CONFIG_SERIAL_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE #ifdef CONFIG_ZS extern void zs_serial_console_init(void); @@ -43,7 +43,7 @@ extern void dz_serial_console_init(void) /* rs_init - starts up the serial interface - handle normal case of starting up the serial interface */ -#ifdef CONFIG_SERIAL +#ifdef CONFIG_SERIAL_CORE int __init rs_init(void) { @@ -70,7 +70,7 @@ __initcall(rs_init); #endif -#ifdef CONFIG_SERIAL_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE /* serial_console_init handles the special case of starting * up the console on the serial port diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 7d22dc0..b16b99f 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -398,6 +398,27 @@ config SERIAL_DZ_CONSOLE If unsure, say Y. +config SERIAL_ZS + bool "DECstation Zilog Z8530 support" + depends on MACH_DECSTATION && TC + select SERIAL_CORE + help + Zilog Z8530 serial controllers on DECstation machines using the + TurboChannel bus. + +config SERIAL_ZS_CONSOLE + bool "Support console on DECstation Zilog Z8530" + depends on SERIAL_ZS=y + select SERIAL_CORE_CONSOLE + help + If you say Y here, it will be possible to use a serial port as the + system console (the system console is the device which receives all + kernel messages and warnings and which allows logins in single user + mode). Note that the firmware uses ttyS0 as the serial console on + the Maxine and ttyS2 on the others. + + If unsure, say Y. + config SERIAL_21285 tristate "DC21285 serial port support" depends on ARM && FOOTBRIDGE diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c diff --git a/drivers/tc/Makefile b/drivers/tc/Makefile index 83b5bd7..885d82f 100644 --- a/drivers/tc/Makefile +++ b/drivers/tc/Makefile @@ -5,7 +5,7 @@ # Object file lists. obj-$(CONFIG_TC) += tc.o -obj-$(CONFIG_ZS) += zs.o +obj-$(CONFIG_SERIAL_ZS) += zs.o obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o $(obj)/lk201-map.o: $(obj)/lk201-map.c diff --git a/drivers/tc/zs.c b/drivers/tc/zs.c index 2dffa8e..960f552 100644 --- a/drivers/tc/zs.c +++ b/drivers/tc/zs.c @@ -56,7 +56,7 @@ #include #include #include -#ifdef CONFIG_SERIAL_DEC_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE #include #endif @@ -137,10 +137,10 @@ struct dec_serial *zs_chain; /* list of struct tty_struct zs_ttys[NUM_CHANNELS]; -#ifdef CONFIG_SERIAL_DEC_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE static struct console sercons; #endif -#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ +#if defined(CONFIG_SERIAL_CORE_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ !defined(MODULE) static unsigned long break_pressed; /* break, really ... */ #endif @@ -383,7 +383,7 @@ static void receive_chars(struct dec_ser write_zsreg(info->zs_channel, R0, ERR_RES); } -#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ +#if defined(CONFIG_SERIAL_CORE_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ !defined(MODULE) if (break_pressed && info->line == sercons.index) { /* Ignore the null char got when BREAK is removed. */ @@ -446,7 +446,7 @@ static void status_handle(struct dec_ser stat = read_zsreg(info->zs_channel, R0); if ((stat & BRK_ABRT) && !(info->read_reg_zero & BRK_ABRT)) { -#if defined(CONFIG_SERIAL_DEC_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ +#if defined(CONFIG_SERIAL_CORE_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && \ !defined(MODULE) if (info->line == sercons.index) { if (!break_pressed) @@ -1560,7 +1560,7 @@ static int rs_open(struct tty_struct *tt return retval; } -#ifdef CONFIG_SERIAL_DEC_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE if (sercons.cflag && sercons.index == line) { tty->termios->c_cflag = sercons.cflag; sercons.cflag = 0; @@ -1643,7 +1643,7 @@ static void __init probe_sccs(void) zs_channels[n_channels].data = zs_channels[n_channels].control + 4; -#ifndef CONFIG_SERIAL_DEC_CONSOLE +#ifndef CONFIG_SERIAL_CORE_CONSOLE /* * We're called early and memory managment isn't up, yet. * Thus request_region would fail. @@ -1894,7 +1894,7 @@ int unregister_zs_hook(unsigned int chan * Serial console driver * ------------------------------------------------------------ */ -#ifdef CONFIG_SERIAL_DEC_CONSOLE +#ifdef CONFIG_SERIAL_CORE_CONSOLE /* @@ -2090,7 +2090,7 @@ void __init zs_serial_console_init(void) { register_console(&sercons); } -#endif /* ifdef CONFIG_SERIAL_DEC_CONSOLE */ +#endif /* ifdef CONFIG_SERIAL_CORE_CONSOLE */ #ifdef CONFIG_KGDB struct dec_zschannel *zs_kgdbchan; -- Martin Michlmayr http://www.cyrius.com/ From yshitoot@stellartec.com Fri May 12 02:26:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 02:26:37 +0200 (CEST) Received: from gateway.stellartec.com ([65.107.16.99]:1289 "EHLO gateway.stellartec.com") by ftp.linux-mips.org with ESMTP id S8133888AbWELA03 (ORCPT ); Fri, 12 May 2006 02:26:29 +0200 Content-Transfer-Encoding: 7bit Received: from Exchange.stellartec.com ([10.1.1.7]) by gateway.stellartec.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 17:26:15 -0700 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6755A.AE1DEC0C" Subject: Nedd help burning flash using osprey vr41xx Date: Thu, 11 May 2006 17:26:19 -0700 Message-ID: <7F5F67B895426C40AC75B8290421C239D1EA62@Exchange.stellartec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nedd help burning flash using osprey vr41xx thread-index: AcZ1WrClP4hbWUWtRTqhBsLNWaBU6Q== From: "Yashwant Shitoot" To: X-OriginalArrivalTime: 12 May 2006 00:26:15.0529 (UTC) FILETIME=[AE1D2590:01C6755A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yshitoot@stellartec.com Precedence: bulk X-list: linux-mips Content-Length: 3170 Lines: 126 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6755A.AE1DEC0C X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: E871A6D4-809B-4F4F-9B72-2E88ABBF3B02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I do have a working system with vrboot, vmlinux and romdisk. Now I would like to use about 10 bytes in the unused portion of flash (at addr 0xbfc01fc0) and put in a serial number. I have tried bin2rom serialNum.inf 0xbfc01fc0 0xbfc01fff (and some variations) however ethload hangs up at "sending jump addr". =20 Any suggestions ? =20 Thanks =20 Yash ------_=_NextPart_001_01C6755A.AE1DEC0C X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 24C25BEB-49AF-4F02-B3C8-34A8320CCC93 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I do have a working system with vrboot, vmlinux and = romdisk. Now I would like to use about 10 bytes in the unused portion of flash = (at addr 0xbfc01fc0) and put in a serial number. I have tried bin2rom = serialNum.inf 0xbfc01fc0 0xbfc01fff (and some variations) however ethload hangs up at = “sending jump addr”.

 

Any suggestions ?

 

Thanks

 

Yash

------_=_NextPart_001_01C6755A.AE1DEC0C-- From mrahman@sypixx.com Fri May 12 02:43:00 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 02:43:07 +0200 (CEST) Received: from smtp115.iad.emailsrvr.com ([207.97.245.115]:56533 "HELO smtp135.iad.emailsrvr.com") by ftp.linux-mips.org with SMTP id S8133884AbWELAnA (ORCPT ); Fri, 12 May 2006 02:43:00 +0200 Received: from ratin (adsl-69-233-145-110.dsl.sndg02.pacbell.net [69.233.145.110]) (Authenticated sender: mrahman@sypixx.com) by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 4076A44F85B for ; Thu, 11 May 2006 20:42:51 -0400 (EDT) Message-ID: <006401c6755c$c080def0$2300a8c0@ratin> Reply-To: "Ratin" From: "Ratin" To: References: <20060509163411.GA8528@linux-mips.org> <44614E0F.2000207@windriver.com> Subject: SOAP Date: Thu, 11 May 2006 17:41:04 -0700 Organization: Sypixx Networks MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mrahman@sypixx.com Precedence: bulk X-list: linux-mips Content-Length: 93 Lines: 5 Is there an implementation of SOAP (Simple Object Access Protocol) for linux-mips? Ratin From leoncamel@gmail.com Fri May 12 09:08:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 09:08:57 +0200 (CEST) Received: from py-out-1112.google.com ([64.233.166.177]:10058 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S8133495AbWELHIt (ORCPT ); Fri, 12 May 2006 09:08:49 +0200 Received: by py-out-1112.google.com with SMTP id s49so126939pyc for ; Fri, 12 May 2006 00:08:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mHB+a1d3ILNh4PI2KzDTlBnKtwMK5nyXuJw8LF/c1dncK7ThHlwWygbbjjon346u+NSeX8ISZ+Au/fiCrQ36t4O/gKkMl6yW03Pd5l8l6vbIEtUb2kfZcrGUn5/Qw4yxd7AvYIdyBuoaRwnFqjMvnJvoIU6SsoYY0UArfvKSSAg= Received: by 10.35.39.2 with SMTP id r2mr2139545pyj; Fri, 12 May 2006 00:08:47 -0700 (PDT) Received: by 10.35.48.8 with HTTP; Fri, 12 May 2006 00:08:47 -0700 (PDT) Message-ID: Date: Fri, 12 May 2006 15:08:47 +0800 From: "Leon Zhang" To: Ratin Subject: Re: SOAP Cc: linux-mips@linux-mips.org In-Reply-To: <006401c6755c$c080def0$2300a8c0@ratin> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2045_12789196.1147417727679" References: <20060509163411.GA8528@linux-mips.org> <44614E0F.2000207@windriver.com> <006401c6755c$c080def0$2300a8c0@ratin> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: leoncamel@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1208 Lines: 36 ------=_Part_2045_12789196.1147417727679 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline AFAIK, it is machine independence. You should search it in freshmeat.net or sourceforge.net. 2006/5/12, Ratin : > > Is there an implementation of SOAP (Simple Object Access Protocol) for > linux-mips? > > Ratin > > > ------=_Part_2045_12789196.1147417727679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline AFAIK, it is machine independence. You should search it in freshmeat.net or so= urceforge.net.



2006/5/1= 2, Ratin < mrahman@sypixx.com>:Is there an implemen= tation of SOAP (Simple Object Access Protocol) for
linux-mips?

Ratin



------=_Part_2045_12789196.1147417727679-- From ralf.roesch@rw-gmbh.de Fri May 12 09:51:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 09:52:01 +0200 (CEST) Received: from fw01.bwg.de ([213.144.14.242]:37734 "EHLO fw01.bwg.de") by ftp.linux-mips.org with ESMTP id S8133516AbWELHvw (ORCPT ); Fri, 12 May 2006 09:51:52 +0200 Received: from fw01.bwg.de (localhost [127.0.0.1]) by fw01.bwg.de (8.13.6/8.13.6) with ESMTP id k4C7ppDI021460 for ; Fri, 12 May 2006 09:51:51 +0200 (CEST) Received: from kundenmail (193.47.152.5) by fw01-4.bwg.de (smtprelay) with ESMTP Fri May 12 09:51:41 2006. Received: from [192.168.178.2] (84.162.182.108) by kundenmail with MERCUR Mailserver (v4.03.15 MTI1LTI0MzctNDg3Nw==) for ; Fri, 12 May 2006 09:53:15 +0200 Message-ID: <44643E46.1040309@rw-gmbh.de> Date: Fri, 12 May 2006 09:50:30 +0200 From: Ralf Roesch User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Ratin CC: linux-mips@linux-mips.org Subject: Re: SOAP References: <20060509163411.GA8528@linux-mips.org> <44614E0F.2000207@windriver.com> <006401c6755c$c080def0$2300a8c0@ratin> In-Reply-To: <006401c6755c$c080def0$2300a8c0@ratin> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf.roesch@rw-gmbh.de Precedence: bulk X-list: linux-mips Content-Length: 617 Lines: 22 we have successfully used gSOAP since years now on a mips based embedded target runing linux from mips-org. Further related information about the gSOAP project you can find at http://www.cs.fsu.edu/~engelen/soap.html Ralf Roesch & Walter___________________________________________ Industrie-Elektronik GmbH * Tel.: +49-7824 / 6628-0 Im Heidenwinkel 5 * Fax: +49-7824 / 6628-29 D-77963 Schwanau * mailto:ralf.roesch@rw-gmbh.de Germany * WWW: http://www.rw-gmbh.de Ratin wrote: > Is there an implementation of SOAP (Simple Object Access Protocol) for > linux-mips? > > Ratin > From macro@linux-mips.org Fri May 12 12:57:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 12:57:24 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:58889 "HELO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with SMTP id S8133884AbWELK5L (ORCPT ); Fri, 12 May 2006 12:57:11 +0200 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id CD157F5CD9; Fri, 12 May 2006 12:57:06 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01396-07; Fri, 12 May 2006 12:57:06 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 79301F5CC8; Fri, 12 May 2006 12:57:06 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.6/8.13.1) with ESMTP id k4CAvCUl019261; Fri, 12 May 2006 12:57:12 +0200 Date: Fri, 12 May 2006 11:57:08 +0100 (BST) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: Karel van Houten , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i In-Reply-To: <20060511185446.GB7234@deprecation.cyrius.com> Message-ID: References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> <20060511185446.GB7234@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.2/1459/Thu May 11 22:46:49 2006 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 970 Lines: 21 On Thu, 11 May 2006, Martin Michlmayr wrote: > > Well, not exactly ported, but hacked up enough it worked the last time I > > tried, but you have to disable the virtual terminal (CONFIG_VT) as it is > > Yeah, but the problem is that ZS is not a config option anymore. I > hacked up something to see if the driver works but I guess there's a > nicer solution. Of course there is. Just enable SERIAL_NONSTANDARD, SERIAL_DEC, SERIAL_DEC_CONSOLE and ZS. They are all in drivers/char/Kconfig and it's not a coincidence the options are the same as in 2.4. The driver has NOT been ported to use the serial core and frankly I would rather it went away and write the necessary system specific glue (including that horrible stuff for incorrect wiring used in all DEC systems making use of the Zilog chips) to use drivers/net/wan/z85230.c instead which already has a lot of nice stuff like support for synchronous operation and DMA, HDLC framing, etc. Maciej From tbm@cyrius.com Fri May 12 17:12:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 17:12:31 +0200 (CEST) Received: from sorrow.cyrius.com ([65.19.161.204]:2053 "HELO sorrow.cyrius.com") by ftp.linux-mips.org with SMTP id S8126581AbWELPMV (ORCPT ); Fri, 12 May 2006 17:12:21 +0200 Received: by sorrow.cyrius.com (Postfix, from userid 10) id C9A1564D54; Fri, 12 May 2006 15:12:13 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id A2BA866F5B; Fri, 12 May 2006 17:12:01 +0200 (CEST) Date: Fri, 12 May 2006 17:12:01 +0200 From: Martin Michlmayr To: "Maciej W. Rozycki" Cc: Karel van Houten , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i Message-ID: <20060512151201.GJ7863@deprecation.cyrius.com> References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> <20060511185446.GB7234@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060330 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Content-Length: 543 Lines: 12 * Maciej W. Rozycki [2006-05-12 11:57]: > > Yeah, but the problem is that ZS is not a config option anymore. I > > hacked up something to see if the driver works but I guess there's a > > nicer solution. > Of course there is. Just enable SERIAL_NONSTANDARD, SERIAL_DEC, > SERIAL_DEC_CONSOLE and ZS. They are all in drivers/char/Kconfig and it's > not a coincidence the options are the same as in 2.4. Hmm, okay, they are in the linux-mips tree, but not in mainline. :/ -- Martin Michlmayr http://www.cyrius.com/ From ralf@linux-mips.org Fri May 12 18:20:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 18:20:54 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:42404 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8126579AbWELQUq (ORCPT ); Fri, 12 May 2006 18:20:46 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4CGKjnR022670; Fri, 12 May 2006 17:20:45 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4CGKhYX022669; Fri, 12 May 2006 17:20:43 +0100 Date: Fri, 12 May 2006 17:20:43 +0100 From: Ralf Baechle To: Martin Michlmayr Cc: "Maciej W. Rozycki" , Karel van Houten , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i Message-ID: <20060512162042.GA22611@linux-mips.org> References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> <20060511185446.GB7234@deprecation.cyrius.com> <20060512151201.GJ7863@deprecation.cyrius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060512151201.GJ7863@deprecation.cyrius.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 667 Lines: 15 On Fri, May 12, 2006 at 05:12:01PM +0200, Martin Michlmayr wrote: > * Maciej W. Rozycki [2006-05-12 11:57]: > > > Yeah, but the problem is that ZS is not a config option anymore. I > > > hacked up something to see if the driver works but I guess there's a > > > nicer solution. > > Of course there is. Just enable SERIAL_NONSTANDARD, SERIAL_DEC, > > SERIAL_DEC_CONSOLE and ZS. They are all in drivers/char/Kconfig and it's > > not a coincidence the options are the same as in 2.4. > > Hmm, okay, they are in the linux-mips tree, but not in mainline. :/ And they won't go there just like any other drivers/char/ serial driver.. Ralf From mratin@cisco.com Fri May 12 18:24:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 18:24:47 +0200 (CEST) Received: from sj-iport-5.cisco.com ([171.68.10.87]:1127 "EHLO sj-iport-5.cisco.com") by ftp.linux-mips.org with ESMTP id S8126579AbWELQYi convert rfc822-to-8bit (ORCPT ); Fri, 12 May 2006 18:24:38 +0200 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 12 May 2006 09:24:27 -0700 X-IronPort-AV: i="4.05,122,1146466800"; d="scan'208"; a="275885728:sNHT47624892" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4CGORvo018364; Fri, 12 May 2006 09:24:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4CGORB9027629; Fri, 12 May 2006 09:24:27 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 May 2006 09:24:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: SOAP Date: Fri, 12 May 2006 09:24:25 -0700 Message-ID: <27801B4D04E7CA45825B0E0CE60FE10A01E51ED3@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SOAP Thread-Index: AcZ1mPBlvPMpXG2bSsmNcKCCEepW8wAR1FYQ From: "Ratin Rahman \(mratin\)" To: "Ralf Roesch" Cc: X-OriginalArrivalTime: 12 May 2006 16:24:26.0960 (UTC) FILETIME=[89AD5500:01C675E0] DKIM-Signature: a=rsa-sha1; q=dns; l=962; t=1147451067; x=1148315067; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mratin@cisco.com; z=From:=22Ratin=20Rahman=20\(mratin\)=22=20 |Subject:RE=3A=20SOAP; X=v=3Dcisco.com=3B=20h=3DpkqlvQRZJCCcYqvcM/ZHl4u6qTk=3D; b=lfv+N2ghg+6t++U6yb4/hY4/w4SX5WhiRi4b1eYK1MsImjo53zGpEK0V1CA3cSfXMzDpJ1zQ e+RYImcRtrnXRw3JvEh541pPGpl2zFBNRbYDXgErBRX+OG/mRM4CHDK5; Authentication-Results: sj-dkim-4.cisco.com; header.From=mratin@cisco.com; dkim=pass ( sig from cisco.com verified; ); Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mratin@cisco.com Precedence: bulk X-list: linux-mips Content-Length: 924 Lines: 34 Thanks, good to know about the illegal XML serialization patent that Microsoft obtained from the patent office on that page. Ratin -----Original Message----- From: Ralf Roesch [mailto:ralf.roesch@rw-gmbh.de] Sent: Friday, May 12, 2006 12:51 AM To: Ratin Cc: linux-mips@linux-mips.org Subject: Re: SOAP we have successfully used gSOAP since years now on a mips based embedded target runing linux from mips-org. Further related information about the gSOAP project you can find at http://www.cs.fsu.edu/~engelen/soap.html Ralf Roesch & Walter___________________________________________ Industrie-Elektronik GmbH * Tel.: +49-7824 / 6628-0 Im Heidenwinkel 5 * Fax: +49-7824 / 6628-29 D-77963 Schwanau * mailto:ralf.roesch@rw-gmbh.de Germany * WWW: http://www.rw-gmbh.de Ratin wrote: > Is there an implementation of SOAP (Simple Object Access Protocol) for > linux-mips? > > Ratin > From hvr@gnu.org Fri May 12 22:23:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 12 May 2006 22:24:13 +0200 (CEST) Received: from fencepost.gnu.org ([199.232.76.164]:411 "EHLO fencepost.gnu.org") by ftp.linux-mips.org with ESMTP id S8126624AbWELUXy (ORCPT ); Fri, 12 May 2006 22:23:54 +0200 Received: from hvr by fencepost.gnu.org with local (Exim 4.34) id 1FeeAr-0004Jz-SY; Fri, 12 May 2006 16:23:45 -0400 From: Herbert Valerio Riedel To: netdev@vger.kernel.org Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, ppopov@embeddedalley.com, sshtylyov@ru.mvista.com, afleming@freescale.com Subject: [PATCH] [RFC] net: au1000_eth: PHY framework conversion Message-Id: Date: Fri, 12 May 2006 16:23:45 -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hvr@gnu.org Precedence: bulk X-list: linux-mips Content-Length: 57234 Lines: 2072 convert au1000_eth driver to use PHY framework Signed-off-by: Herbert Valerio Riedel --- drivers/net/Kconfig | 1 drivers/net/au1000_eth.c | 1602 +++++++++++----------------------------------- drivers/net/au1000_eth.h | 134 ---- 3 files changed, 380 insertions(+), 1357 deletions(-) Index: b/drivers/net/Kconfig =================================================================== --- a/drivers/net/Kconfig 2006-05-12 21:18:36.000000000 +0200 +++ b/drivers/net/Kconfig 2006-05-12 21:37:42.000000000 +0200 @@ -455,6 +455,7 @@ config MIPS_AU1X00_ENET bool "MIPS AU1000 Ethernet support" depends on NET_ETHERNET && SOC_AU1X00 + select PHYLIB select CRC32 help If you have an Alchemy Semi AU1X00 based system Index: b/drivers/net/au1000_eth.c =================================================================== --- a/drivers/net/au1000_eth.c 2006-05-12 21:18:36.000000000 +0200 +++ b/drivers/net/au1000_eth.c 2006-05-12 22:05:25.000000000 +0200 @@ -9,6 +9,9 @@ * Update: 2004 Bjoern Riemer, riemer@fokus.fraunhofer.de * or riemer@riemer-nt.de: fixed the link beat detection with * ioctls (SIOCGMIIPHY) + * Copyright 2006 Herbert Valerio Riedel + * converted to use linux-2.6.x's PHY framework + * * Author: MontaVista Software, Inc. * ppopov@mvista.com or source@mvista.com * @@ -53,6 +56,7 @@ #include #include #include +#include #include #include #include @@ -88,17 +92,15 @@ static int au1000_rx(struct net_device *); static irqreturn_t au1000_interrupt(int, void *, struct pt_regs *); static void au1000_tx_timeout(struct net_device *); -static int au1000_set_config(struct net_device *dev, struct ifmap *map); static void set_rx_mode(struct net_device *); static struct net_device_stats *au1000_get_stats(struct net_device *); -static void au1000_timer(unsigned long); static int au1000_ioctl(struct net_device *, struct ifreq *, int); static int mdio_read(struct net_device *, int, int); static void mdio_write(struct net_device *, int, int, u16); -static void dump_mii(struct net_device *dev, int phy_id); +static void au1000_adjust_link(struct net_device *); +static void enable_mac(struct net_device *, int); // externs -extern void ack_rise_edge_irq(unsigned int); extern int get_ethernet_addr(char *ethernet_addr); extern void str2eaddr(unsigned char *ea, unsigned char *str); extern char * __init prom_getcmdline(void); @@ -126,705 +128,83 @@ 0x00, 0x50, 0xc2, 0x0c, 0x30, 0x00 }; -#define nibswap(x) ((((x) >> 4) & 0x0f) | (((x) << 4) & 0xf0)) -#define RUN_AT(x) (jiffies + (x)) - -// For reading/writing 32-bit words from/to DMA memory -#define cpu_to_dma32 cpu_to_be32 -#define dma32_to_cpu be32_to_cpu - struct au1000_private *au_macs[NUM_ETH_INTERFACES]; -/* FIXME - * All of the PHY code really should be detached from the MAC - * code. +/* + * board-specific configurations + * + * PHY detection algorithm + * + * If AU1XXX_PHY_STATIC_CONFIG is undefined, the PHY setup is + * autodetected: + * + * mii_probe() first searches the current MAC's MII bus for a PHY, + * selecting the first (or last, if AU1XXX_PHY_SEARCH_HIGHEST_ADDR is + * defined) PHY address not already claimed by another netdev. + * + * If nothing was found that way when searching for the 2nd ethernet + * controller's PHY and AU1XXX_PHY1_SEARCH_ON_MAC0 is defined, then + * the first MII bus is searched as well for an unclaimed PHY; this is + * needed in case of a dual-PHY accessible only through the MAC0's MII + * bus. + * + * Finally, if no PHY is found, then the corresponding ethernet + * controller is not registered to the network subsystem. */ -/* Default advertise */ -#define GENMII_DEFAULT_ADVERTISE \ - ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | \ - ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full | \ - ADVERTISED_Autoneg - -#define GENMII_DEFAULT_FEATURES \ - SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | \ - SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \ - SUPPORTED_Autoneg - -int bcm_5201_init(struct net_device *dev, int phy_addr) -{ - s16 data; - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int bcm_5201_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -bcm_5201_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "bcm_5201_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AUX_CNTRL); - if (mii_data & MII_AUX_100) { - if (mii_data & MII_AUX_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int lsi_80227_init(struct net_device *dev, int phy_addr) -{ - if (au1000_debug > 4) - printk("lsi_80227_init\n"); - - /* restart auto-negotiation */ - mdio_write(dev, phy_addr, MII_CONTROL, - MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO); // | MII_CNTL_FDX); - mdelay(1); - - /* set up LEDs to correct display */ -#ifdef CONFIG_MIPS_MTX1 - mdio_write(dev, phy_addr, 17, 0xff80); -#else - mdio_write(dev, phy_addr, 17, 0xffc0); -#endif - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int lsi_80227_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) { - printk("lsi_80227_reset\n"); - dump_mii(dev, phy_addr); - } - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -lsi_80227_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "lsi_80227_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_LSI_PHY_STAT); - if (mii_data & MII_LSI_PHY_STAT_SPD) { - if (mii_data & MII_LSI_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int am79c901_init(struct net_device *dev, int phy_addr) -{ - printk("am79c901_init\n"); - return 0; -} - -int am79c901_reset(struct net_device *dev, int phy_addr) -{ - printk("am79c901_reset\n"); - return 0; -} - -int -am79c901_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - return 0; -} - -int am79c874_init(struct net_device *dev, int phy_addr) -{ - s16 data; - - /* 79c874 has quit resembled bit assignments to BCM5201 */ - if (au1000_debug > 4) - printk("am79c847_init\n"); - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - return 0; -} - -int am79c874_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) - printk("am79c874_reset\n"); - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -am79c874_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - // printk("am79c874_status\n"); - if (!dev) { - printk(KERN_ERR "am79c874_status error: NULL dev\n"); - return -1; - } - - aup = (struct au1000_private *) dev->priv; - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AMD_PHY_STAT); - if (mii_data & MII_AMD_PHY_STAT_SPD) { - if (mii_data & MII_AMD_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int lxt971a_init(struct net_device *dev, int phy_addr) -{ - if (au1000_debug > 4) - printk("lxt971a_init\n"); - - /* restart auto-negotiation */ - mdio_write(dev, phy_addr, MII_CONTROL, - MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO | MII_CNTL_FDX); - - /* set up LEDs to correct display */ - mdio_write(dev, phy_addr, 20, 0x0422); - - if (au1000_debug > 4) - dump_mii(dev, phy_addr); - return 0; -} - -int lxt971a_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) { - printk("lxt971a_reset\n"); - dump_mii(dev, phy_addr); - } - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -lxt971a_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "lxt971a_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_INTEL_PHY_STAT); - if (mii_data & MII_INTEL_PHY_STAT_SPD) { - if (mii_data & MII_INTEL_PHY_STAT_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int ks8995m_init(struct net_device *dev, int phy_addr) -{ - s16 data; - -// printk("ks8995m_init\n"); - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - - return 0; -} - -int ks8995m_reset(struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - -// printk("ks8995m_reset\n"); - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int ks8995m_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "ks8995m_status error: NULL dev\n"); - return -1; - } - aup = (struct au1000_private *) dev->priv; - - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_AUX_CNTRL); - if (mii_data & MII_AUX_100) { - if (mii_data & MII_AUX_FDX) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - -int -smsc_83C185_init (struct net_device *dev, int phy_addr) -{ - s16 data; - - if (au1000_debug > 4) - printk("smsc_83C185_init\n"); - - /* Stop auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); - - /* Set advertisement to 10/100 and Half/Full duplex - * (full capabilities) */ - data = mdio_read(dev, phy_addr, MII_ANADV); - data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; - mdio_write(dev, phy_addr, MII_ANADV, data); - - /* Restart auto-negotiation */ - data = mdio_read(dev, phy_addr, MII_CONTROL); - data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; - - mdio_write(dev, phy_addr, MII_CONTROL, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); - return 0; -} - -int -smsc_83C185_reset (struct net_device *dev, int phy_addr) -{ - s16 mii_control, timeout; - - if (au1000_debug > 4) - printk("smsc_83C185_reset\n"); - - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); - mdelay(1); - for (timeout = 100; timeout > 0; --timeout) { - mii_control = mdio_read(dev, phy_addr, MII_CONTROL); - if ((mii_control & MII_CNTL_RESET) == 0) - break; - mdelay(1); - } - if (mii_control & MII_CNTL_RESET) { - printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); - return -1; - } - return 0; -} - -int -smsc_83C185_status (struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - u16 mii_data; - struct au1000_private *aup; - - if (!dev) { - printk(KERN_ERR "smsc_83C185_status error: NULL dev\n"); - return -1; - } - - aup = (struct au1000_private *) dev->priv; - mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); - - if (mii_data & MII_STAT_LINK) { - *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, 0x1f); - if (mii_data & (1<<3)) { - if (mii_data & (1<<4)) { - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - } - else { - *speed = IF_PORT_100BASETX; - dev->if_port = IF_PORT_100BASETX; - } - } - else { - *speed = IF_PORT_10BASET; - dev->if_port = IF_PORT_10BASET; - } - } - else { - *link = 0; - *speed = 0; - dev->if_port = IF_PORT_UNKNOWN; - } - return 0; -} - - -#ifdef CONFIG_MIPS_BOSPORUS -int stub_init(struct net_device *dev, int phy_addr) -{ - //printk("PHY stub_init\n"); - return 0; -} - -int stub_reset(struct net_device *dev, int phy_addr) -{ - //printk("PHY stub_reset\n"); - return 0; -} +/* autodetection defaults */ +#undef AU1XXX_PHY_SEARCH_HIGHEST_ADDR +#define AU1XXX_PHY1_SEARCH_ON_MAC0 -int -stub_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) -{ - //printk("PHY stub_status\n"); - *link = 1; - /* hmmm, revisit */ - *speed = IF_PORT_100BASEFX; - dev->if_port = IF_PORT_100BASEFX; - return 0; -} -#endif - -struct phy_ops bcm_5201_ops = { - bcm_5201_init, - bcm_5201_reset, - bcm_5201_status, -}; - -struct phy_ops am79c874_ops = { - am79c874_init, - am79c874_reset, - am79c874_status, -}; - -struct phy_ops am79c901_ops = { - am79c901_init, - am79c901_reset, - am79c901_status, -}; - -struct phy_ops lsi_80227_ops = { - lsi_80227_init, - lsi_80227_reset, - lsi_80227_status, -}; - -struct phy_ops lxt971a_ops = { - lxt971a_init, - lxt971a_reset, - lxt971a_status, -}; - -struct phy_ops ks8995m_ops = { - ks8995m_init, - ks8995m_reset, - ks8995m_status, -}; +/* static PHY setup + * + * most boards PHY setup should be detectable properly with the + * autodetection algorithm in mii_probe(), but in some cases (e.g. if + * you have a switch attached, or want to use the PHY's interrupt + * notification capabilities) you can provide a static PHY + * configuration here + * + * IRQs may only be set, if a PHY address was configured + * If a PHY address is given, also a bus id is required to be set + * + * ps: make sure the used irqs are configured properly in the board + * specific irq-map + */ -struct phy_ops smsc_83C185_ops = { - smsc_83C185_init, - smsc_83C185_reset, - smsc_83C185_status, -}; +#if defined(CONFIG_MIPS_BOSPORUS) +/* + * Micrel/Kendin 5 port switch attached to MAC0, + * MAC0 is associated with PHY address 5 (== WAN port) + * MAC1 is not associated with any PHY, since it's connected directly + * to the switch. + * no interrupts are used + */ +# define AU1XXX_PHY_STATIC_CONFIG -#ifdef CONFIG_MIPS_BOSPORUS -struct phy_ops stub_ops = { - stub_init, - stub_reset, - stub_status, -}; +# define AU1XXX_PHY0_ADDR 5 +# define AU1XXX_PHY0_BUSID 0 +# undef AU1XXX_PHY0_IRQ + +# undef AU1XXX_PHY1_ADDR +# undef AU1XXX_PHY1_BUSID +# undef AU1XXX_PHY1_IRQ #endif -static struct mii_chip_info { - const char * name; - u16 phy_id0; - u16 phy_id1; - struct phy_ops *phy_ops; - int dual_phy; -} mii_chip_table[] = { - {"Broadcom BCM5201 10/100 BaseT PHY",0x0040,0x6212, &bcm_5201_ops,0}, - {"Broadcom BCM5221 10/100 BaseT PHY",0x0040,0x61e4, &bcm_5201_ops,0}, - {"Broadcom BCM5222 10/100 BaseT PHY",0x0040,0x6322, &bcm_5201_ops,1}, - {"NS DP83847 PHY", 0x2000, 0x5c30, &bcm_5201_ops ,0}, - {"AMD 79C901 HomePNA PHY",0x0000,0x35c8, &am79c901_ops,0}, - {"AMD 79C874 10/100 BaseT PHY",0x0022,0x561b, &am79c874_ops,0}, - {"LSI 80227 10/100 BaseT PHY",0x0016,0xf840, &lsi_80227_ops,0}, - {"Intel LXT971A Dual Speed PHY",0x0013,0x78e2, &lxt971a_ops,0}, - {"Kendin KS8995M 10/100 BaseT PHY",0x0022,0x1450, &ks8995m_ops,0}, - {"SMSC LAN83C185 10/100 BaseT PHY",0x0007,0xc0a3, &smsc_83C185_ops,0}, -#ifdef CONFIG_MIPS_BOSPORUS - {"Stub", 0x1234, 0x5678, &stub_ops }, +#if defined(AU1XXX_PHY0_BUSID) && (AU1XXX_PHY0_BUSID > 0) +# error MAC0-associated PHY attached 2nd MACs MII bus not supported yet #endif - {0,}, -}; -static int mdio_read(struct net_device *dev, int phy_id, int reg) +/* + * MII operations + */ +static int mdio_read(struct net_device *dev, int phy_addr, int reg) { struct au1000_private *aup = (struct au1000_private *) dev->priv; - volatile u32 *mii_control_reg; - volatile u32 *mii_data_reg; + volatile u32 *const mii_control_reg = &aup->mac->mii_control; + volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; u32 mii_control; - #ifdef CONFIG_BCM5222_DUAL_PHY - /* First time we probe, it's for the mac0 phy. - * Since we haven't determined yet that we have a dual phy, - * aup->mii->mii_control_reg won't be setup and we'll - * default to the else statement. - * By the time we probe for the mac1 phy, the mii_control_reg - * will be setup to be the address of the mac0 phy control since - * both phys are controlled through mac0. - */ - if (aup->mii && aup->mii->mii_control_reg) { - mii_control_reg = aup->mii->mii_control_reg; - mii_data_reg = aup->mii->mii_data_reg; - } - else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - /* assume both phys are controlled through mac0 */ - mii_control_reg = au_macs[0]->mii->mii_control_reg; - mii_data_reg = au_macs[0]->mii->mii_data_reg; - } - else - #endif - { - /* default control and data reg addresses */ - mii_control_reg = &aup->mac->mii_control; - mii_data_reg = &aup->mac->mii_data; - } - while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { @@ -835,7 +215,7 @@ } mii_control = MAC_SET_MII_SELECT_REG(reg) | - MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_READ; + MAC_SET_MII_SELECT_PHY(phy_addr) | MAC_MII_READ; *mii_control_reg = mii_control; @@ -851,32 +231,14 @@ return (int)*mii_data_reg; } -static void mdio_write(struct net_device *dev, int phy_id, int reg, u16 value) +static void mdio_write(struct net_device *dev, int phy_addr, int reg, u16 value) { struct au1000_private *aup = (struct au1000_private *) dev->priv; - volatile u32 *mii_control_reg; - volatile u32 *mii_data_reg; + volatile u32 *const mii_control_reg = &aup->mac->mii_control; + volatile u32 *const mii_data_reg = &aup->mac->mii_data; u32 timedout = 20; u32 mii_control; - #ifdef CONFIG_BCM5222_DUAL_PHY - if (aup->mii && aup->mii->mii_control_reg) { - mii_control_reg = aup->mii->mii_control_reg; - mii_data_reg = aup->mii->mii_data_reg; - } - else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - /* assume both phys are controlled through mac0 */ - mii_control_reg = au_macs[0]->mii->mii_control_reg; - mii_data_reg = au_macs[0]->mii->mii_data_reg; - } - else - #endif - { - /* default control and data reg addresses */ - mii_control_reg = &aup->mac->mii_control; - mii_data_reg = &aup->mac->mii_data; - } - while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { @@ -887,165 +249,145 @@ } mii_control = MAC_SET_MII_SELECT_REG(reg) | - MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_WRITE; + MAC_SET_MII_SELECT_PHY(phy_addr) | MAC_MII_WRITE; *mii_data_reg = value; *mii_control_reg = mii_control; } +static int mdiobus_read(struct mii_bus *bus, int phy_addr, int regnum) +{ + /* WARNING: bus->phy_map[phy_addr].attached_dev == dev does + * _NOT_ hold (e.g. when PHY is accessed through other MAC's MII bus) */ + struct net_device *const dev = bus->priv; -static void dump_mii(struct net_device *dev, int phy_id) + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + return mdio_read(dev, phy_addr, regnum); +} + +static int mdiobus_write(struct mii_bus *bus, int phy_addr, int regnum, + u16 value) { - int i, val; + struct net_device *const dev = bus->priv; - for (i = 0; i < 7; i++) { - if ((val = mdio_read(dev, phy_id, i)) >= 0) - printk("%s: MII Reg %d=%x\n", dev->name, i, val); - } - for (i = 16; i < 25; i++) { - if ((val = mdio_read(dev, phy_id, i)) >= 0) - printk("%s: MII Reg %d=%x\n", dev->name, i, val); - } + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + mdio_write(dev, phy_addr, regnum, value); + return 0; } -static int mii_probe (struct net_device * dev) +static int mdiobus_reset(struct mii_bus *bus) { - struct au1000_private *aup = (struct au1000_private *) dev->priv; - int phy_addr; -#ifdef CONFIG_MIPS_BOSPORUS - int phy_found=0; -#endif + struct net_device *const dev = bus->priv; - /* search for total of 32 possible mii phy addresses */ - for (phy_addr = 0; phy_addr < 32; phy_addr++) { - u16 mii_status; - u16 phy_id0, phy_id1; - int i; + enable_mac(dev, 0); /* make sure the MAC associated with this + * mii_bus is enabled */ + return 0; +} - #ifdef CONFIG_BCM5222_DUAL_PHY - /* Mask the already found phy, try next one */ - if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { - if (au_macs[0]->phy_addr == phy_addr) - continue; - } - #endif +static int mii_probe (struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + struct phy_device *phydev = NULL; - mii_status = mdio_read(dev, phy_addr, MII_STATUS); - if (mii_status == 0xffff || mii_status == 0x0000) - /* the mii is not accessable, try next one */ - continue; - - phy_id0 = mdio_read(dev, phy_addr, MII_PHY_ID0); - phy_id1 = mdio_read(dev, phy_addr, MII_PHY_ID1); - - /* search our mii table for the current mii */ - for (i = 0; mii_chip_table[i].phy_id1; i++) { - if (phy_id0 == mii_chip_table[i].phy_id0 && - phy_id1 == mii_chip_table[i].phy_id1) { - struct mii_phy * mii_phy = aup->mii; - - printk(KERN_INFO "%s: %s at phy address %d\n", - dev->name, mii_chip_table[i].name, - phy_addr); -#ifdef CONFIG_MIPS_BOSPORUS - phy_found = 1; -#endif - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - aup->want_autoneg = 1; - aup->phy_ops = mii_chip_table[i].phy_ops; - aup->phy_ops->phy_init(dev,phy_addr); - - // Check for dual-phy and then store required - // values and set indicators. We need to do - // this now since mdio_{read,write} need the - // control and data register addresses. - #ifdef CONFIG_BCM5222_DUAL_PHY - if ( mii_chip_table[i].dual_phy) { - - /* assume both phys are controlled - * through MAC0. Board specific? */ - - /* sanity check */ - if (!au_macs[0] || !au_macs[0]->mii) - return -1; - aup->mii->mii_control_reg = (u32 *) - &au_macs[0]->mac->mii_control; - aup->mii->mii_data_reg = (u32 *) - &au_macs[0]->mac->mii_data; - } - #endif - goto found; - } - } +#if defined(AU1XXX_PHY_STATIC_CONFIG) + BUG_ON(aup->mac_id < 0 || aup->mac_id > 1); + + if(aup->mac_id == 0) { /* get PHY0 */ +# if defined(AU1XXX_PHY0_ADDR) + phydev = au_macs[AU1XXX_PHY0_BUSID]->mii_bus.phy_map[AU1XXX_PHY0_ADDR]; +# else + printk (KERN_INFO DRV_NAME ":%s: using PHY-less setup\n", + dev->name); + return 0; +# endif /* defined(AU1XXX_PHY0_ADDR) */ + } else if (aup->mac_id == 1) { /* get PHY1 */ +# if defined(AU1XXX_PHY1_ADDR) + phydev = au_macs[AU1XXX_PHY1_BUSID]->mii_bus.phy_map[AU1XXX_PHY1_ADDR]; +# else + printk (KERN_INFO DRV_NAME ":%s: using PHY-less setup\n", + dev->name); + return 0; +# endif /* defined(AU1XXX_PHY1_ADDR) */ } -found: -#ifdef CONFIG_MIPS_BOSPORUS - /* This is a workaround for the Micrel/Kendin 5 port switch - The second MAC doesn't see a PHY connected... so we need to - trick it into thinking we have one. - - If this kernel is run on another Au1500 development board - the stub will be found as well as the actual PHY. However, - the last found PHY will be used... usually at Addr 31 (Db1500). - */ - if ( (!phy_found) ) - { - u16 phy_id0, phy_id1; - int i; +#else /* defined(AU1XXX_PHY_STATIC_CONFIG) */ + int phy_addr; + + /* find the first (lowest address) PHY on the current MAC's MII bus */ + for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) + if (aup->mii_bus.phy_map[phy_addr]) { + phydev = aup->mii_bus.phy_map[phy_addr]; +# if !defined(AU1XXX_PHY_SEARCH_HIGHEST_ADDR) + break; /* break out with first one found */ +# endif + } - phy_id0 = 0x1234; - phy_id1 = 0x5678; +# if defined(AU1XXX_PHY1_SEARCH_ON_MAC0) + /* try harder to find a PHY */ + if (!phydev && (aup->mac_id == 1)) { + /* no PHY found, maybe we have a dual PHY? */ + printk (KERN_INFO DRV_NAME ": no PHY found on MAC1, " + "let's see if it's attached to MAC0...\n"); - /* search our mii table for the current mii */ - for (i = 0; mii_chip_table[i].phy_id1; i++) { - if (phy_id0 == mii_chip_table[i].phy_id0 && - phy_id1 == mii_chip_table[i].phy_id1) { - struct mii_phy * mii_phy; - - printk(KERN_INFO "%s: %s at phy address %d\n", - dev->name, mii_chip_table[i].name, - phy_addr); - mii_phy = kmalloc(sizeof(struct mii_phy), - GFP_KERNEL); - if (mii_phy) { - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - mii_phy->next = aup->mii; - aup->phy_ops = - mii_chip_table[i].phy_ops; - aup->mii = mii_phy; - aup->phy_ops->phy_init(dev,phy_addr); - } else { - printk(KERN_ERR "%s: out of memory\n", - dev->name); - return -1; - } - mii_phy->chip_info = mii_chip_table+i; - aup->phy_addr = phy_addr; - aup->phy_ops = mii_chip_table[i].phy_ops; - aup->phy_ops->phy_init(dev,phy_addr); - break; - } + BUG_ON(!au_macs[0]); + + /* find the first (lowest address) non-attached PHY on + * the MAC0 MII bus */ + for (phy_addr = 0; phy_addr < PHY_MAX_ADDR; phy_addr++) { + struct phy_device *const tmp_phydev = + au_macs[0]->mii_bus.phy_map[phy_addr]; + + if (!tmp_phydev) + continue; /* no PHY here... */ + + if (tmp_phydev->attached_dev) + continue; /* already claimed by MAC0 */ + + phydev = tmp_phydev; + break; /* found it */ } } - if (aup->mac_id == 0) { - /* the Bosporus phy responds to addresses 0-5 but - * 5 is the correct one. - */ - aup->phy_addr = 5; - } -#endif +# endif /* defined(AU1XXX_PHY1_SEARCH_OTHER_BUS) */ - if (aup->mii->chip_info == NULL) { - printk(KERN_ERR "%s: Au1x No known MII transceivers found!\n", - dev->name); +#endif /* defined(AU1XXX_PHY_STATIC_CONFIG) */ + if (!phydev) { + printk (KERN_ERR DRV_NAME ":%s: no PHY found\n", dev->name); return -1; } - printk(KERN_INFO "%s: Using %s as default\n", - dev->name, aup->mii->chip_info->name); + /* now we are supposed to have a proper phydev, to attach to... */ + BUG_ON(!phydev); + BUG_ON(phydev->attached_dev); + + phydev = phy_connect(dev, phydev->dev.bus_id, &au1000_adjust_link, 0); + + if (IS_ERR(phydev)) { + printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name); + return PTR_ERR(phydev); + } + + /* mask with MAC supported features */ + phydev->supported &= (SUPPORTED_10baseT_Half + | SUPPORTED_10baseT_Full + | SUPPORTED_100baseT_Half + | SUPPORTED_100baseT_Full + | SUPPORTED_Autoneg + /* | SUPPORTED_Pause | SUPPORTED_Asym_Pause */ + | SUPPORTED_MII + | SUPPORTED_TP); + + phydev->advertising = phydev->supported; + + aup->old_link = 0; + aup->old_speed = 0; + aup->old_duplex = -1; + aup->phy_dev = phydev; + + printk(KERN_INFO "%s: attached PHY driver [%s] " + "(mii_bus:phy_addr=%s, irq=%d)\n", + dev->name, phydev->drv->name, phydev->dev.bus_id, phydev->irq); return 0; } @@ -1097,35 +439,38 @@ au_sync_delay(10); } - -static void reset_mac(struct net_device *dev) +static void enable_mac(struct net_device *dev, int force_reset) { - int i; - u32 flags; + unsigned long flags; struct au1000_private *aup = (struct au1000_private *) dev->priv; - if (au1000_debug > 4) - printk(KERN_INFO "%s: reset mac, aup %x\n", - dev->name, (unsigned)aup); - spin_lock_irqsave(&aup->lock, flags); - if (aup->timer.function == &au1000_timer) {/* check if timer initted */ - del_timer(&aup->timer); - } - hard_stop(dev); - #ifdef CONFIG_BCM5222_DUAL_PHY - if (aup->mac_id != 0) { - #endif - /* If BCM5222, we can't leave MAC0 in reset because then - * we can't access the dual phy for ETH1 */ + if(force_reset || (!aup->mac_enabled)) { *aup->enable = MAC_EN_CLOCK_ENABLE; au_sync_delay(2); - *aup->enable = 0; + *aup->enable = (MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2 + | MAC_EN_CLOCK_ENABLE); au_sync_delay(2); - #ifdef CONFIG_BCM5222_DUAL_PHY + + aup->mac_enabled = 1; } - #endif + + spin_unlock_irqrestore(&aup->lock, flags); +} + +static void reset_mac_unlocked(struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + int i; + + hard_stop(dev); + + *aup->enable = MAC_EN_CLOCK_ENABLE; + au_sync_delay(2); + *aup->enable = 0; + au_sync_delay(2); + aup->tx_full = 0; for (i = 0; i < NUM_RX_DMA; i++) { /* reset control bits */ @@ -1135,9 +480,26 @@ /* reset control bits */ aup->tx_dma_ring[i]->buff_stat &= ~0xf; } - spin_unlock_irqrestore(&aup->lock, flags); + + aup->mac_enabled = 0; + } +static void reset_mac(struct net_device *dev) +{ + struct au1000_private *const aup = (struct au1000_private *) dev->priv; + unsigned long flags; + + if (au1000_debug > 4) + printk(KERN_INFO "%s: reset mac, aup %x\n", + dev->name, (unsigned)aup); + + spin_lock_irqsave(&aup->lock, flags); + + reset_mac_unlocked (dev); + + spin_unlock_irqrestore(&aup->lock, flags); +} /* * Setup the receive and transmit "rings". These pointers are the addresses @@ -1237,178 +599,31 @@ return 0; } -static int au1000_setup_aneg(struct net_device *dev, u32 advertise) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 ctl, adv; - - /* Setup standard advertise */ - adv = mdio_read(dev, aup->phy_addr, MII_ADVERTISE); - adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4); - if (advertise & ADVERTISED_10baseT_Half) - adv |= ADVERTISE_10HALF; - if (advertise & ADVERTISED_10baseT_Full) - adv |= ADVERTISE_10FULL; - if (advertise & ADVERTISED_100baseT_Half) - adv |= ADVERTISE_100HALF; - if (advertise & ADVERTISED_100baseT_Full) - adv |= ADVERTISE_100FULL; - mdio_write(dev, aup->phy_addr, MII_ADVERTISE, adv); - - /* Start/Restart aneg */ - ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); - ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); - - return 0; -} - -static int au1000_setup_forced(struct net_device *dev, int speed, int fd) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 ctl; - - ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); - ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_ANENABLE); - - /* First reset the PHY */ - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl | BMCR_RESET); - - /* Select speed & duplex */ - switch (speed) { - case SPEED_10: - break; - case SPEED_100: - ctl |= BMCR_SPEED100; - break; - case SPEED_1000: - default: - return -EINVAL; - } - if (fd == DUPLEX_FULL) - ctl |= BMCR_FULLDPLX; - mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); - - return 0; -} - - -static void -au1000_start_link(struct net_device *dev, struct ethtool_cmd *cmd) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - u32 advertise; - int autoneg; - int forced_speed; - int forced_duplex; - - /* Default advertise */ - advertise = GENMII_DEFAULT_ADVERTISE; - autoneg = aup->want_autoneg; - forced_speed = SPEED_100; - forced_duplex = DUPLEX_FULL; - - /* Setup link parameters */ - if (cmd) { - if (cmd->autoneg == AUTONEG_ENABLE) { - advertise = cmd->advertising; - autoneg = 1; - } else { - autoneg = 0; - - forced_speed = cmd->speed; - forced_duplex = cmd->duplex; - } - } - - /* Configure PHY & start aneg */ - aup->want_autoneg = autoneg; - if (autoneg) - au1000_setup_aneg(dev, advertise); - else - au1000_setup_forced(dev, forced_speed, forced_duplex); - mod_timer(&aup->timer, jiffies + HZ); -} +/* + * ethtool operations + */ static int au1000_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 link, speed; - cmd->supported = GENMII_DEFAULT_FEATURES; - cmd->advertising = GENMII_DEFAULT_ADVERTISE; - cmd->port = PORT_MII; - cmd->transceiver = XCVR_EXTERNAL; - cmd->phy_address = aup->phy_addr; - spin_lock_irq(&aup->lock); - cmd->autoneg = aup->want_autoneg; - aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed); - if ((speed == IF_PORT_100BASETX) || (speed == IF_PORT_100BASEFX)) - cmd->speed = SPEED_100; - else if (speed == IF_PORT_10BASET) - cmd->speed = SPEED_10; - if (link && (dev->if_port == IF_PORT_100BASEFX)) - cmd->duplex = DUPLEX_FULL; - else - cmd->duplex = DUPLEX_HALF; - spin_unlock_irq(&aup->lock); - return 0; + if (aup->phy_dev) + return phy_ethtool_gset(aup->phy_dev, cmd); + + return -EINVAL; } static int au1000_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct au1000_private *aup = (struct au1000_private *)dev->priv; - unsigned long features = GENMII_DEFAULT_FEATURES; + struct au1000_private *aup = (struct au1000_private *)dev->priv; - if (!capable(CAP_NET_ADMIN)) - return -EPERM; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; - if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE) - return -EINVAL; - if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0) - return -EINVAL; - if (cmd->duplex != DUPLEX_HALF && cmd->duplex != DUPLEX_FULL) - return -EINVAL; - if (cmd->autoneg == AUTONEG_DISABLE) - switch (cmd->speed) { - case SPEED_10: - if (cmd->duplex == DUPLEX_HALF && - (features & SUPPORTED_10baseT_Half) == 0) - return -EINVAL; - if (cmd->duplex == DUPLEX_FULL && - (features & SUPPORTED_10baseT_Full) == 0) - return -EINVAL; - break; - case SPEED_100: - if (cmd->duplex == DUPLEX_HALF && - (features & SUPPORTED_100baseT_Half) == 0) - return -EINVAL; - if (cmd->duplex == DUPLEX_FULL && - (features & SUPPORTED_100baseT_Full) == 0) - return -EINVAL; - break; - default: - return -EINVAL; - } - else if ((features & SUPPORTED_Autoneg) == 0) - return -EINVAL; - - spin_lock_irq(&aup->lock); - au1000_start_link(dev, cmd); - spin_unlock_irq(&aup->lock); - return 0; -} + if (aup->phy_dev) + return phy_ethtool_sset(aup->phy_dev, cmd); -static int au1000_nway_reset(struct net_device *dev) -{ - struct au1000_private *aup = (struct au1000_private *)dev->priv; - - if (!aup->want_autoneg) - return -EINVAL; - spin_lock_irq(&aup->lock); - au1000_start_link(dev, NULL); - spin_unlock_irq(&aup->lock); - return 0; + return -EINVAL; } static void @@ -1423,19 +638,15 @@ info->regdump_len = 0; } -static u32 au1000_get_link(struct net_device *dev) -{ - return netif_carrier_ok(dev); -} - static struct ethtool_ops au1000_ethtool_ops = { .get_settings = au1000_get_settings, .set_settings = au1000_set_settings, .get_drvinfo = au1000_get_drvinfo, - .nway_reset = au1000_nway_reset, - .get_link = au1000_get_link + .get_link = ethtool_op_get_link, }; + + static struct net_device * au1000_probe(u32 ioaddr, int irq, int port_num) { @@ -1527,24 +738,33 @@ printk(KERN_ERR "%s: bad ioaddr\n", dev->name); } - /* bring the device out of reset, otherwise probing the mii - * will hang */ - *aup->enable = MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 | - MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); + *aup->enable = 0; + aup->mac_enabled = 0; - aup->mii = kmalloc(sizeof(struct mii_phy), GFP_KERNEL); - if (!aup->mii) { - printk(KERN_ERR "%s: out of memory\n", dev->name); - goto err_out; - } - aup->mii->next = NULL; - aup->mii->chip_info = NULL; - aup->mii->status = 0; - aup->mii->mii_control_reg = 0; - aup->mii->mii_data_reg = 0; + aup->mii_bus.priv = dev; + aup->mii_bus.read = mdiobus_read; + aup->mii_bus.write = mdiobus_write; + aup->mii_bus.reset = mdiobus_reset; + aup->mii_bus.name = "au1000_eth_mii"; + aup->mii_bus.id = aup->mac_id; + aup->mii_bus.irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL); + for(i = 0; i < PHY_MAX_ADDR; ++i) + aup->mii_bus.irq[i] = PHY_POLL; + + /* if known, set corresponding PHY IRQs */ +#if defined(AU1XXX_PHY_STATIC_CONFIG) +# if defined(AU1XXX_PHY0_IRQ) + if (AU1XXX_PHY0_BUSID == aup->mii_bus.id) + aup->mii_bus.irq[AU1XXX_PHY0_ADDR] = AU1XXX_PHY0_IRQ; +# endif + +# if defined(AU1XXX_PHY1_IRQ) + if (AU1XXX_PHY1_BUSID == aup->mii_bus.id) + aup->mii_bus.irq[AU1XXX_PHY1_ADDR] = AU1XXX_PHY1_IRQ; +# endif +#endif + + mdiobus_register(&aup->mii_bus); if (mii_probe(dev) != 0) { goto err_out; @@ -1590,7 +810,6 @@ dev->set_multicast_list = &set_rx_mode; dev->do_ioctl = &au1000_ioctl; SET_ETHTOOL_OPS(dev, &au1000_ethtool_ops); - dev->set_config = &au1000_set_config; dev->tx_timeout = au1000_tx_timeout; dev->watchdog_timeo = ETH_TX_TIMEOUT; @@ -1606,7 +825,7 @@ /* here we should have a valid dev plus aup-> register addresses * so we can reset the mac properly.*/ reset_mac(dev); - kfree(aup->mii); + for (i = 0; i < NUM_RX_DMA; i++) { if (aup->rx_db_inuse[i]) ReleaseDB(aup, aup->rx_db_inuse[i]); @@ -1640,19 +859,14 @@ u32 flags; int i; u32 control; - u16 link, speed; if (au1000_debug > 4) printk("%s: au1000_init\n", dev->name); - spin_lock_irqsave(&aup->lock, flags); - /* bring the device out of reset */ - *aup->enable = MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 | - MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE; - au_sync_delay(20); + enable_mac(dev, 1); + + spin_lock_irqsave(&aup->lock, flags); aup->mac->control = 0; aup->tx_head = (aup->tx_dma_ring[0]->buff_stat & 0xC) >> 2; @@ -1668,12 +882,16 @@ } au_sync(); - aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed); - control = MAC_DISABLE_RX_OWN | MAC_RX_ENABLE | MAC_TX_ENABLE; + control = MAC_RX_ENABLE | MAC_TX_ENABLE; #ifndef CONFIG_CPU_LITTLE_ENDIAN control |= MAC_BIG_ENDIAN; #endif - if (link && (dev->if_port == IF_PORT_100BASEFX)) { + if (aup->phy_dev) { + if (aup->phy_dev->link && (DUPLEX_FULL == aup->phy_dev->duplex)) + control |= MAC_FULL_DUPLEX; + else + control |= MAC_DISABLE_RX_OWN; + } else { /* PHY-less op, assume full-duplex */ control |= MAC_FULL_DUPLEX; } @@ -1685,57 +903,84 @@ return 0; } -static void au1000_timer(unsigned long data) +static void +au1000_adjust_link(struct net_device *dev) { - struct net_device *dev = (struct net_device *)data; struct au1000_private *aup = (struct au1000_private *) dev->priv; - unsigned char if_port; - u16 link, speed; + struct phy_device *phydev = aup->phy_dev; + unsigned long flags; - if (!dev) { - /* fatal error, don't restart the timer */ - printk(KERN_ERR "au1000_timer error: NULL dev\n"); - return; - } + int status_change = 0; - if_port = dev->if_port; - if (aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed) == 0) { - if (link) { - if (!netif_carrier_ok(dev)) { - netif_carrier_on(dev); - printk(KERN_INFO "%s: link up\n", dev->name); - } - } - else { - if (netif_carrier_ok(dev)) { - netif_carrier_off(dev); - dev->if_port = 0; - printk(KERN_INFO "%s: link down\n", dev->name); - } + BUG_ON(!aup->phy_dev); + + spin_lock_irqsave(&aup->lock, flags); + + if (phydev->link && (aup->old_speed != phydev->speed)) { + // speed changed + + switch(phydev->speed) { + case SPEED_10: + case SPEED_100: + break; + default: + printk(KERN_WARNING + "%s: Speed (%d) is not 10/100 ???\n", + dev->name, phydev->speed); + break; } + + aup->old_speed = phydev->speed; + + status_change = 1; } - if (link && (dev->if_port != if_port) && - (dev->if_port != IF_PORT_UNKNOWN)) { + if (phydev->link && (aup->old_duplex != phydev->duplex)) { + // duplex mode changed + + /* switching duplex mode requires to disable rx and tx! */ hard_stop(dev); - if (dev->if_port == IF_PORT_100BASEFX) { - printk(KERN_INFO "%s: going to full duplex\n", - dev->name); - aup->mac->control |= MAC_FULL_DUPLEX; - au_sync_delay(1); - } - else { - aup->mac->control &= ~MAC_FULL_DUPLEX; - au_sync_delay(1); - } + + if (DUPLEX_FULL == phydev->duplex) + aup->mac->control = ((aup->mac->control + | MAC_FULL_DUPLEX) + & ~MAC_DISABLE_RX_OWN); + else + aup->mac->control = ((aup->mac->control + & ~MAC_FULL_DUPLEX) + | MAC_DISABLE_RX_OWN); + au_sync_delay(1); + enable_rx_tx(dev); + aup->old_duplex = phydev->duplex; + + status_change = 1; + } + + if(phydev->link != aup->old_link) { + // link state changed + + if (phydev->link) // link went up + netif_schedule(dev); + else { // link went down + aup->old_speed = 0; + aup->old_duplex = -1; + } + + aup->old_link = phydev->link; + status_change = 1; } - aup->timer.expires = RUN_AT((1*HZ)); - aup->timer.data = (unsigned long)dev; - aup->timer.function = &au1000_timer; /* timer handler */ - add_timer(&aup->timer); + spin_unlock_irqrestore(&aup->lock, flags); + if (status_change) { + if (phydev->link) + printk(KERN_INFO "%s: link up (%d/%s)\n", + dev->name, phydev->speed, + DUPLEX_FULL == phydev->duplex ? "Full" : "Half"); + else + printk(KERN_INFO "%s: link down\n", dev->name); + } } static int au1000_open(struct net_device *dev) @@ -1746,25 +991,26 @@ if (au1000_debug > 4) printk("%s: open: dev=%p\n", dev->name, dev); + if ((retval = request_irq(dev->irq, &au1000_interrupt, 0, + dev->name, dev))) { + printk(KERN_ERR "%s: unable to get IRQ %d\n", + dev->name, dev->irq); + return retval; + } + if ((retval = au1000_init(dev))) { printk(KERN_ERR "%s: error in au1000_init\n", dev->name); free_irq(dev->irq, dev); return retval; } - netif_start_queue(dev); - if ((retval = request_irq(dev->irq, &au1000_interrupt, 0, - dev->name, dev))) { - printk(KERN_ERR "%s: unable to get IRQ %d\n", - dev->name, dev->irq); - return retval; + if (aup->phy_dev) { + /* cause the PHY state machine to schedule a link state check */ + aup->phy_dev->state = PHY_CHANGELINK; + phy_start(aup->phy_dev); } - init_timer(&aup->timer); /* used in ioctl() */ - aup->timer.expires = RUN_AT((3*HZ)); - aup->timer.data = (unsigned long)dev; - aup->timer.function = &au1000_timer; /* timer handler */ - add_timer(&aup->timer); + netif_start_queue(dev); if (au1000_debug > 4) printk("%s: open: Initialization done.\n", dev->name); @@ -1774,16 +1020,19 @@ static int au1000_close(struct net_device *dev) { - u32 flags; - struct au1000_private *aup = (struct au1000_private *) dev->priv; + unsigned long flags; + struct au1000_private *const aup = (struct au1000_private *) dev->priv; if (au1000_debug > 4) printk("%s: close: dev=%p\n", dev->name, dev); - reset_mac(dev); + if (aup->phy_dev) + phy_stop(aup->phy_dev); spin_lock_irqsave(&aup->lock, flags); - + + reset_mac_unlocked (dev); + /* stop the device */ netif_stop_queue(dev); @@ -1805,7 +1054,7 @@ if (dev) { aup = (struct au1000_private *) dev->priv; unregister_netdev(dev); - kfree(aup->mii); + for (j = 0; j < NUM_RX_DMA; j++) { if (aup->rx_db_inuse[j]) ReleaseDB(aup, aup->rx_db_inuse[j]); @@ -1830,7 +1079,7 @@ struct net_device_stats *ps = &aup->stats; if (status & TX_FRAME_ABORTED) { - if (dev->if_port == IF_PORT_100BASEFX) { + if (!aup->phy_dev || (DUPLEX_FULL == aup->phy_dev->duplex)) { if (status & (TX_JAB_TIMEOUT | TX_UNDERRUN)) { /* any other tx errors are only valid * in half duplex mode */ @@ -2104,126 +1353,15 @@ } } - static int au1000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct au1000_private *aup = (struct au1000_private *)dev->priv; - u16 *data = (u16 *)&rq->ifr_ifru; - - switch(cmd) { - case SIOCDEVPRIVATE: /* Get the address of the PHY in use. */ - case SIOCGMIIPHY: - if (!netif_running(dev)) return -EINVAL; - data[0] = aup->phy_addr; - case SIOCDEVPRIVATE+1: /* Read the specified MII register. */ - case SIOCGMIIREG: - data[3] = mdio_read(dev, data[0], data[1]); - return 0; - case SIOCDEVPRIVATE+2: /* Write the specified MII register */ - case SIOCSMIIREG: - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - mdio_write(dev, data[0], data[1],data[2]); - return 0; - default: - return -EOPNOTSUPP; - } - -} - - -static int au1000_set_config(struct net_device *dev, struct ifmap *map) -{ - struct au1000_private *aup = (struct au1000_private *) dev->priv; - u16 control; - if (au1000_debug > 4) { - printk("%s: set_config called: dev->if_port %d map->port %x\n", - dev->name, dev->if_port, map->port); - } + if (!netif_running(dev)) return -EINVAL; - switch(map->port){ - case IF_PORT_UNKNOWN: /* use auto here */ - printk(KERN_INFO "%s: config phy for aneg\n", - dev->name); - dev->if_port = map->port; - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* read current control */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_FDX | MII_CNTL_F100); - - /* enable auto negotiation and reset the negotiation */ - mdio_write(dev, aup->phy_addr, MII_CONTROL, - control | MII_CNTL_AUTO | - MII_CNTL_RST_AUTO); + if (!aup->phy_dev) return -EINVAL; // PHY not controllable - break; - - case IF_PORT_10BASET: /* 10BaseT */ - printk(KERN_INFO "%s: config phy for 10BaseT\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 10Mbps, Half Duplex */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_F100 | MII_CNTL_AUTO | - MII_CNTL_FDX); - - /* disable auto negotiation and force 10M/HD mode*/ - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - - case IF_PORT_100BASET: /* 100BaseT */ - case IF_PORT_100BASETX: /* 100BaseTx */ - printk(KERN_INFO "%s: config phy for 100BaseTX\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 100Mbps, Half Duplex */ - /* disable auto negotiation and enable 100MBit Mode */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~(MII_CNTL_AUTO | MII_CNTL_FDX); - control |= MII_CNTL_F100; - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - - case IF_PORT_100BASEFX: /* 100BaseFx */ - printk(KERN_INFO "%s: config phy for 100BaseFX\n", - dev->name); - dev->if_port = map->port; - - /* Link Down: the timer will bring it up */ - netif_carrier_off(dev); - - /* set Speed to 100Mbps, Full Duplex */ - /* disable auto negotiation and enable 100MBit Mode */ - control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - control &= ~MII_CNTL_AUTO; - control |= MII_CNTL_F100 | MII_CNTL_FDX; - mdio_write(dev, aup->phy_addr, MII_CONTROL, control); - break; - case IF_PORT_10BASE2: /* 10Base2 */ - case IF_PORT_AUI: /* AUI */ - /* These Modes are not supported (are they?)*/ - printk(KERN_ERR "%s: 10Base2/AUI not supported", - dev->name); - return -EOPNOTSUPP; - break; - - default: - printk(KERN_ERR "%s: Invalid media selected", - dev->name); - return -EINVAL; - } - return 0; + return phy_mii_ioctl(aup->phy_dev, if_mii(rq), cmd); } static struct net_device_stats *au1000_get_stats(struct net_device *dev) Index: b/drivers/net/au1000_eth.h =================================================================== --- a/drivers/net/au1000_eth.h 2006-05-12 21:18:36.000000000 +0200 +++ b/drivers/net/au1000_eth.h 2006-05-12 21:37:42.000000000 +0200 @@ -40,120 +40,6 @@ #define MULTICAST_FILTER_LIMIT 64 -/* FIXME - * The PHY defines should be in a separate file. - */ - -/* MII register offsets */ -#define MII_CONTROL 0x0000 -#define MII_STATUS 0x0001 -#define MII_PHY_ID0 0x0002 -#define MII_PHY_ID1 0x0003 -#define MII_ANADV 0x0004 -#define MII_ANLPAR 0x0005 -#define MII_AEXP 0x0006 -#define MII_ANEXT 0x0007 -#define MII_LSI_PHY_CONFIG 0x0011 -/* Status register */ -#define MII_LSI_PHY_STAT 0x0012 -#define MII_AMD_PHY_STAT MII_LSI_PHY_STAT -#define MII_INTEL_PHY_STAT 0x0011 - -#define MII_AUX_CNTRL 0x0018 -/* mii registers specific to AMD 79C901 */ -#define MII_STATUS_SUMMARY = 0x0018 - -/* MII Control register bit definitions. */ -#define MII_CNTL_FDX 0x0100 -#define MII_CNTL_RST_AUTO 0x0200 -#define MII_CNTL_ISOLATE 0x0400 -#define MII_CNTL_PWRDWN 0x0800 -#define MII_CNTL_AUTO 0x1000 -#define MII_CNTL_F100 0x2000 -#define MII_CNTL_LPBK 0x4000 -#define MII_CNTL_RESET 0x8000 - -/* MII Status register bit */ -#define MII_STAT_EXT 0x0001 -#define MII_STAT_JAB 0x0002 -#define MII_STAT_LINK 0x0004 -#define MII_STAT_CAN_AUTO 0x0008 -#define MII_STAT_FAULT 0x0010 -#define MII_STAT_AUTO_DONE 0x0020 -#define MII_STAT_CAN_T 0x0800 -#define MII_STAT_CAN_T_FDX 0x1000 -#define MII_STAT_CAN_TX 0x2000 -#define MII_STAT_CAN_TX_FDX 0x4000 -#define MII_STAT_CAN_T4 0x8000 - - -#define MII_ID1_OUI_LO 0xFC00 /* low bits of OUI mask */ -#define MII_ID1_MODEL 0x03F0 /* model number */ -#define MII_ID1_REV 0x000F /* model number */ - -/* MII NWAY Register Bits ... - valid for the ANAR (Auto-Negotiation Advertisement) and - ANLPAR (Auto-Negotiation Link Partner) registers */ -#define MII_NWAY_NODE_SEL 0x001f -#define MII_NWAY_CSMA_CD 0x0001 -#define MII_NWAY_T 0x0020 -#define MII_NWAY_T_FDX 0x0040 -#define MII_NWAY_TX 0x0080 -#define MII_NWAY_TX_FDX 0x0100 -#define MII_NWAY_T4 0x0200 -#define MII_NWAY_PAUSE 0x0400 -#define MII_NWAY_RF 0x2000 /* Remote Fault */ -#define MII_NWAY_ACK 0x4000 /* Remote Acknowledge */ -#define MII_NWAY_NP 0x8000 /* Next Page (Enable) */ - -/* mii stsout register bits */ -#define MII_STSOUT_LINK_FAIL 0x4000 -#define MII_STSOUT_SPD 0x0080 -#define MII_STSOUT_DPLX 0x0040 - -/* mii stsics register bits */ -#define MII_STSICS_SPD 0x8000 -#define MII_STSICS_DPLX 0x4000 -#define MII_STSICS_LINKSTS 0x0001 - -/* mii stssum register bits */ -#define MII_STSSUM_LINK 0x0008 -#define MII_STSSUM_DPLX 0x0004 -#define MII_STSSUM_AUTO 0x0002 -#define MII_STSSUM_SPD 0x0001 - -/* lsi phy status register */ -#define MII_LSI_PHY_STAT_FDX 0x0040 -#define MII_LSI_PHY_STAT_SPD 0x0080 - -/* amd phy status register */ -#define MII_AMD_PHY_STAT_FDX 0x0800 -#define MII_AMD_PHY_STAT_SPD 0x0400 - -/* intel phy status register */ -#define MII_INTEL_PHY_STAT_FDX 0x0200 -#define MII_INTEL_PHY_STAT_SPD 0x4000 - -/* Auxilliary Control/Status Register */ -#define MII_AUX_FDX 0x0001 -#define MII_AUX_100 0x0002 -#define MII_AUX_F100 0x0004 -#define MII_AUX_ANEG 0x0008 - -typedef struct mii_phy { - struct mii_phy * next; - struct mii_chip_info * chip_info; - u16 status; - u32 *mii_control_reg; - u32 *mii_data_reg; -} mii_phy_t; - -struct phy_ops { - int (*phy_init) (struct net_device *, int); - int (*phy_reset) (struct net_device *, int); - int (*phy_status) (struct net_device *, int, u16 *, u16 *); -}; - /* * Data Buffer Descriptor. Data buffers must be aligned on 32 byte * boundary for both, receive and transmit. @@ -200,7 +86,6 @@ struct au1000_private { - db_dest_t *pDBfree; db_dest_t db[NUM_RX_BUFFS+NUM_TX_BUFFS]; volatile rx_dma_t *rx_dma_ring[NUM_RX_DMA]; @@ -213,8 +98,15 @@ u32 tx_full; int mac_id; - mii_phy_t *mii; - struct phy_ops *phy_ops; + + int mac_enabled; /* whether MAC is currently enabled and running (req. for mdio) */ + + int old_link; /* used by au1000_adjust_link */ + int old_speed; + int old_duplex; + + struct phy_device *phy_dev; + struct mii_bus mii_bus; /* These variables are just for quick access to certain regs addresses. */ volatile mac_reg_t *mac; /* mac registers */ @@ -223,14 +115,6 @@ u32 vaddr; /* virtual address of rx/tx buffers */ dma_addr_t dma_addr; /* dma address of rx/tx buffers */ - u8 *hash_table; - u32 hash_mode; - u32 intr_work_done; /* number of Rx and Tx pkts processed in the isr */ - int phy_addr; /* phy address */ - u32 options; /* User-settable misc. driver options. */ - u32 drv_flags; - int want_autoneg; struct net_device_stats stats; - struct timer_list timer; spinlock_t lock; /* Serialise access to device */ }; -- From jamiller1110@cox.net Sun May 14 15:51:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 15:51:18 +0200 (CEST) Received: from eastrmmtao01.cox.net ([68.230.240.38]:56562 "HELO eastrmmtao01.cox.net") by ftp.linux-mips.org with SMTP id S8127173AbWENNvK (ORCPT ); Sun, 14 May 2006 15:51:10 +0200 Received: from hermes.mountolympos.net ([70.160.186.45]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060514135102.VCNU17255.eastrmmtao01.cox.net@hermes.mountolympos.net> for ; Sun, 14 May 2006 09:51:02 -0400 Received: from zeus.mountolympos.net (zeus.mountolympos.net [192.168.2.2]) by hermes.mountolympos.net (Postfix) with ESMTP id 5BC1C1677D for ; Sun, 14 May 2006 09:51:02 -0400 (EDT) Received: from [192.168.2.3] (kronos.mountolympos.net [192.168.2.3]) by zeus.mountolympos.net (Postfix) with ESMTP id 494AF100A118 for ; Sun, 14 May 2006 09:51:02 -0400 (EDT) Message-ID: <446735C6.2080306@mountolympos.net> Date: Sun, 14 May 2006 09:51:02 -0400 From: John Miller User-Agent: Thunderbird 1.5 (X11/20060402) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Instruction error with cache opcode Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jamiller1110@cox.net Precedence: bulk X-list: linux-mips Content-Length: 767 Lines: 23 I am attempting to write a routine to initialize the cache for a MIPS 4kc core to get Linux 2.6.16.14 to compile. I am sure someone has probably already done this, but I am doing it for educational reasons. I am receiving the following error: arch/mips/kernel/head.S: Assembler messages: arch/mips/kernel/head.S:131: Error: Instruction cache requires absolute expression From the following code section: li t0, 0x80000000 # start address (KSEG0) addu t1,t0,0x2000 # 8KB I-cache 1: addu t0,0x10 # 16B line size cache Index_Store_Tag_I,-4(t0) # clear tag nop cache Fill_I,-4(t0) # fill line nop bne t0,t1,1b cache Index_Store_Tag_I,-4(t0) I copied the code section from See MIPS Run, so I know the code must be correct. What am I doing wrong? From KevinK@mips.com Sun May 14 16:23:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 16:24:05 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:37609 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133616AbWENOX5 (ORCPT ); Sun, 14 May 2006 16:23:57 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k4EENkJi029922; Sun, 14 May 2006 07:23:47 -0700 (PDT) Received: from Ulysses ([192.168.2.2]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id k4EENjv1017693; Sun, 14 May 2006 07:23:45 -0700 (PDT) Message-ID: <002a01c67761$253e97f0$0202a8c0@Ulysses> From: "Kevin D. Kissell" To: "John Miller" , References: <446735C6.2080306@mountolympos.net> Subject: Re: Instruction error with cache opcode Date: Sun, 14 May 2006 16:17:14 +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 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: KevinK@mips.com Precedence: bulk X-list: linux-mips Content-Length: 899 Lines: 29 > I am attempting to write a routine to initialize the cache for a MIPS > 4kc core to get Linux 2.6.16.14 to compile. I am sure someone has > probably already done this, but I am doing it for educational reasons. > I am receiving the following error: > > arch/mips/kernel/head.S: Assembler messages: > arch/mips/kernel/head.S:131: Error: Instruction cache requires absolute > expression > > From the following code section: > > li t0, 0x80000000 # start address (KSEG0) > addu t1,t0,0x2000 # 8KB I-cache > 1: addu t0,0x10 # 16B line size > cache Index_Store_Tag_I,-4(t0) # clear tag > nop > cache Fill_I,-4(t0) # fill line > nop > bne t0,t1,1b > cache Index_Store_Tag_I,-4(t0) > > I copied the code section from See MIPS Run, so I know the code must be > correct. What am I doing wrong? Where and how is the value of Index_Store_Tag_I defined? Regards, Kevin K. From anemo@mba.ocn.ne.jp Sun May 14 18:08:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 18:08:14 +0200 (CEST) Received: from mba.ocn.ne.jp ([210.190.142.172]:60103 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133616AbWENQIH (ORCPT ); Sun, 14 May 2006 18:08:07 +0200 Received: from localhost (p5058-ipad30funabasi.chiba.ocn.ne.jp [221.184.80.58]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D9379B677; Mon, 15 May 2006 01:08:02 +0900 (JST) Date: Mon, 15 May 2006 01:08:46 +0900 (JST) Message-Id: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: Thiemo Seufer Subject: kernel patch for QEMU ? From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 452 Lines: 13 Now I'm trying QEMU 0.8.1 on mips. I found mips-test-0.1.tar.gz on QEMU download page and can run it (thanks ths!), but I still can not run a kernel (current lmo git) compiled by myself. My kernel stops after the famous "Checking for 'wait' instruction... available." message. The mips-test-0.1 contains kernel 2.6.16-rc6. Is this a stock kernel.org's kernel or lmo's kernel? Or is there any patch to make kernel run on QEMU? --- Atsushi Nemoto From ralf@linux-mips.org Sun May 14 19:52:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 19:52:38 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:1752 "EHLO bacchus.dhis.org") by ftp.linux-mips.org with ESMTP id S8133622AbWENRwb (ORCPT ); Sun, 14 May 2006 19:52:31 +0200 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by bacchus.dhis.org (8.13.6/8.13.4) with ESMTP id k4EHqac9025906; Sun, 14 May 2006 18:52:36 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.13.6/8.13.6/Submit) id k4EHqYIu025905; Sun, 14 May 2006 18:52:34 +0100 Date: Sun, 14 May 2006 18:52:34 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, Thiemo Seufer Subject: Re: kernel patch for QEMU ? Message-ID: <20060514175234.GA25659@linux-mips.org> References: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 617 Lines: 17 On Mon, May 15, 2006 at 01:08:46AM +0900, Atsushi Nemoto wrote: > Now I'm trying QEMU 0.8.1 on mips. > > I found mips-test-0.1.tar.gz on QEMU download page and can run it > (thanks ths!), but I still can not run a kernel (current lmo git) > compiled by myself. My kernel stops after the famous "Checking for > 'wait' instruction... available." message. > > The mips-test-0.1 contains kernel 2.6.16-rc6. Is this a stock > kernel.org's kernel or lmo's kernel? Or is there any patch to make > kernel run on QEMU? Thiemo promised to send me patches so I hope it's only a matter of days to get this fixed. Ralf From ths@networkno.de Sun May 14 20:21:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 20:22:07 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:12218 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133622AbWENSV7 (ORCPT ); Sun, 14 May 2006 20:21:59 +0200 Received: from lagash (88-106-136-76.dynamic.dsl.as9105.com [88.106.136.76]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id 56978448AF; Sun, 14 May 2006 20:21:58 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FfLDz-0008G3-QU; Sun, 14 May 2006 19:21:51 +0100 Date: Sun, 14 May 2006 19:21:51 +0100 From: Thiemo Seufer To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: kernel patch for QEMU ? Message-ID: <20060514182151.GB800@networkno.de> References: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.11+cvs20060403 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 1183 Lines: 29 Atsushi Nemoto wrote: > Now I'm trying QEMU 0.8.1 on mips. > > I found mips-test-0.1.tar.gz on QEMU download page and can run it > (thanks ths!), but I still can not run a kernel (current lmo git) > compiled by myself. My kernel stops after the famous "Checking for > 'wait' instruction... available." message. > > The mips-test-0.1 contains kernel 2.6.16-rc6. Is this a stock > kernel.org's kernel or lmo's kernel? Or is there any patch to make > kernel run on QEMU? This kernel is stock lmo except for a small patch which allows clean system shutdown (qemu 0.8.1 does not have the counterpart to it). The patch should be completely irrelevant otherwise. However, later kernels try to access the CP0 pagemask register which is R10000 specific, IIRC Qemu throws an Reserved Instruction exception on accessing it. I use a heavily patched version of Qemu which mostly supports mips32r2, it also has better decoding of CP0 accesses. My current patchset is available at http://people.debian.org/~ths/qemu/qemu-patches-bogus2, it needs more work before it is ready for inclusion, and may be completely useless for anybody else, since it works ATM only on powerpc hosts. Thiemo From jamiller1110@cox.net Sun May 14 20:39:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 20:39:57 +0200 (CEST) Received: from eastrmmtao01.cox.net ([68.230.240.38]:5268 "HELO eastrmmtao01.cox.net") by ftp.linux-mips.org with SMTP id S8133622AbWENSju (ORCPT ); Sun, 14 May 2006 20:39:50 +0200 Received: from hermes.mountolympos.net ([70.160.186.45]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060514183943.EVXM17255.eastrmmtao01.cox.net@hermes.mountolympos.net> for ; Sun, 14 May 2006 14:39:43 -0400 Received: from zeus.mountolympos.net (zeus.mountolympos.net [192.168.2.2]) by hermes.mountolympos.net (Postfix) with ESMTP id EB4A81677B for ; Sun, 14 May 2006 14:39:42 -0400 (EDT) Received: from [192.168.2.3] (kronos.mountolympos.net [192.168.2.3]) by zeus.mountolympos.net (Postfix) with ESMTP id D75DC100A116 for ; Sun, 14 May 2006 14:39:42 -0400 (EDT) Message-ID: <4467796E.8060000@mountolympos.net> Date: Sun, 14 May 2006 14:39:42 -0400 From: John Miller User-Agent: Thunderbird 1.5 (X11/20060402) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> In-Reply-To: <002a01c67761$253e97f0$0202a8c0@Ulysses> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jamiller1110@cox.net Precedence: bulk X-list: linux-mips Content-Length: 383 Lines: 16 > Where and how is the value of Index_Store_Tag_I defined? > > Regards, > > Kevin K. > I included asm/cacheops.h from the kernel tree, it is defined there as : #define Index_Store_Tag_I 0x08 I also tried to substitute 0x08 directly into my source and I got the same error. Strangely enough, if I remove the include line, I get the same exact error. From kevink@mips.com Sun May 14 21:39:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 21:39:10 +0200 (CEST) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:16107 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133554AbWENTjC (ORCPT ); Sun, 14 May 2006 21:39:02 +0200 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k4EJcpOH000125; Sun, 14 May 2006 12:38:51 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id k4EJcmt4020826; Sun, 14 May 2006 12:38:49 -0700 (PDT) Message-ID: <009501c6778e$947c3ff0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "John Miller" , References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> Subject: Re: Instruction error with cache opcode Date: Sun, 14 May 2006 21:42:46 +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 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Content-Length: 944 Lines: 24 > > Where and how is the value of Index_Store_Tag_I defined? > > I included asm/cacheops.h from the kernel tree, it is defined there as : > > #define Index_Store_Tag_I 0x08 > > I also tried to substitute 0x08 directly into my source and I got the > same error. Strangely enough, if I remove the include line, I get the > same exact error. Have you got your sources properly installes so that include/asm is a symlink to include/asm-mips? I've done the experiment at my end, and it builds just fine so long as regdef.h and cacheops.h are really on the include path of the compilation. If they're not, I get: [kevink@cthulhu tmp]$ mipsel-linux-gcc -I ~/smtchead/include -c cacheop.S cacheop.S: Assembler messages: cacheop.S:4: Error: Instruction cache requires absolute expression cacheop.S:4: Error: Instruction cache requires absolute expression cacheop.S:4: Error: illegal operands `cache' Regards, Kevin K. From jamiller1110@cox.net Sun May 14 22:14:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 14 May 2006 22:15:03 +0200 (CEST) Received: from eastrmmtao05.cox.net ([68.230.240.34]:61648 "HELO eastrmmtao05.cox.net") by ftp.linux-mips.org with SMTP id S8133554AbWENUOz (ORCPT ); Sun, 14 May 2006 22:14:55 +0200 Received: from hermes.mountolympos.net ([70.160.186.45]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060514201448.SPBZ26910.eastrmmtao05.cox.net@hermes.mountolympos.net>; Sun, 14 May 2006 16:14:48 -0400 Received: from zeus.mountolympos.net (zeus.mountolympos.net [192.168.2.2]) by hermes.mountolympos.net (Postfix) with ESMTP id 619081677B; Sun, 14 May 2006 16:14:48 -0400 (EDT) Received: from [192.168.2.3] (kronos.mountolympos.net [192.168.2.3]) by zeus.mountolympos.net (Postfix) with ESMTP id 6A032100A11D; Sun, 14 May 2006 16:14:48 -0400 (EDT) Message-ID: <44678FB8.4070104@mountolympos.net> Date: Sun, 14 May 2006 16:14:48 -0400 From: John Miller User-Agent: Thunderbird 1.5 (X11/20060402) MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> <009501c6778e$947c3ff0$10eca8c0@grendel> In-Reply-To: <009501c6778e$947c3ff0$10eca8c0@grendel> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jamiller1110@cox.net Precedence: bulk X-list: linux-mips Content-Length: 1257 Lines: 31 > > Have you got your sources properly installes so that include/asm is > a symlink to include/asm-mips? Yes, include/asm is symlinked to include/asm-mips. Let me provide a little more detail. I did not want to modify head.S (since this is a kernel file) but I noticed an undefined macro, kernel_entry_setup # cpu specific setup and the include #include I found at least one kernel-entry-init.h file in a hardware specific directory so I made my own under include/asm-mips/rb500 and added a line to the Makefile. Within kernel-entry-init.h are the include for cacheops.h as well as the macro definition. regdef.h is included in head.s. > I've done the experiment at my end, > and it builds just fine so long as regdef.h and cacheops.h are really > on the include path of the compilation. If they're not, I get: > > [kevink@cthulhu tmp]$ mipsel-linux-gcc -I ~/smtchead/include -c cacheop.S > cacheop.S: Assembler messages: > cacheop.S:4: Error: Instruction cache requires absolute expression > cacheop.S:4: Error: Instruction cache requires absolute expression > cacheop.S:4: Error: illegal operands `cache' > > Well, it looks like I am missing something somewhere, just need to pin down what I did wrong. From ths@networkno.de Mon May 15 01:30:14 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 01:30:21 +0200 (CEST) Received: from bender.bawue.de ([193.7.176.20]:32912 "HELO bender.bawue.de") by ftp.linux-mips.org with SMTP id S8133747AbWENXaO (ORCPT ); Mon, 15 May 2006 01:30:14 +0200 Received: from lagash (88-106-136-76.dynamic.dsl.as9105.com [88.106.136.76]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bender.bawue.de (Postfix) with ESMTP id C512F45597; Mon, 15 May 2006 01:30:10 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FfQ2B-0002bi-CD; Mon, 15 May 2006 00:29:59 +0100 Date: Mon, 15 May 2006 00:29:59 +0100 To: John Miller Cc: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode Message-ID: <20060514232959.GD800@networkno.de> References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> <009501c6778e$947c3ff0$10eca8c0@grendel> <44678FB8.4070104@mountolympos.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44678FB8.4070104@mountolympos.net> User-Agent: Mutt/1.5.11+cvs20060403 From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Content-Length: 528 Lines: 18 John Miller wrote: [snip] > > [kevink@cthulhu tmp]$ mipsel-linux-gcc -I ~/smtchead/include -c cacheop.S > > cacheop.S: Assembler messages: > > cacheop.S:4: Error: Instruction cache requires absolute expression > > cacheop.S:4: Error: Instruction cache requires absolute expression > > cacheop.S:4: Error: illegal operands `cache' > > > > > > Well, it looks like I am missing something somewhere, just need to pin > down what I did wrong. Try gcc -E to get the preprocessed source, this is what the assembler sees. Thiemo From anemo@mba.ocn.ne.jp Mon May 15 03:07:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 03:07:14 +0200 (CEST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:23233 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133747AbWEOBHH (ORCPT ); Mon, 15 May 2006 03:07:07 +0200 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Mon, 15 May 2006 10:07:05 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 31F0A203DA; Mon, 15 May 2006 10:07:00 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 1DB3C1FF09; Mon, 15 May 2006 10:07:00 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k4F16x4D026239; Mon, 15 May 2006 10:06:59 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 15 May 2006 10:06:59 +0900 (JST) Message-Id: <20060515.100659.126574393.nemoto@toshiba-tops.co.jp> To: jamiller1110@cox.net Cc: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode From: Atsushi Nemoto In-Reply-To: <4467796E.8060000@mountolympos.net> References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 234 Lines: 9 On Sun, 14 May 2006 14:39:42 -0400, John Miller wrote: > I included asm/cacheops.h from the kernel tree, it is defined there as : > > #define Index_Store_Tag_I 0x08 Then how about Fill_I ? --- Atsushi Nemoto From jamiller1110@cox.net Mon May 15 03:35:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 03:35:25 +0200 (CEST) Received: from eastrmmtao05.cox.net ([68.230.240.34]:165 "HELO eastrmmtao05.cox.net") by ftp.linux-mips.org with SMTP id S8133764AbWEOBfS (ORCPT ); Mon, 15 May 2006 03:35:18 +0200 Received: from hermes.mountolympos.net ([70.160.186.45]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060515013511.IEQQ26910.eastrmmtao05.cox.net@hermes.mountolympos.net>; Sun, 14 May 2006 21:35:11 -0400 Received: from zeus.mountolympos.net (zeus.mountolympos.net [192.168.2.2]) by hermes.mountolympos.net (Postfix) with ESMTP id F29751677B; Sun, 14 May 2006 21:35:10 -0400 (EDT) Received: from [192.168.2.4] (odysseus.mountolympos.net [192.168.2.4]) by zeus.mountolympos.net (Postfix) with ESMTP id BFE17100A116; Sun, 14 May 2006 21:35:10 -0400 (EDT) Message-ID: <4467DACE.9000800@mountolympos.net> Date: Sun, 14 May 2006 21:35:10 -0400 From: John Miller User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Atsushi Nemoto CC: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> <20060515.100659.126574393.nemoto@toshiba-tops.co.jp> In-Reply-To: <20060515.100659.126574393.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jamiller1110@cox.net Precedence: bulk X-list: linux-mips Content-Length: 734 Lines: 20 Atsushi Nemoto wrote: > On Sun, 14 May 2006 14:39:42 -0400, John Miller wrote: > >> I included asm/cacheops.h from the kernel tree, it is defined there as : >> >> #define Index_Store_Tag_I 0x08 >> > > Then how about Fill_I ? > > --- > Atsushi Nemoto > That got it! Sorry, I had my head up somewhere it was not supposed to be. I do not know how many times I went over cacheops.h and missed the fact that Fill was defined, not Fill_I. One I changed my code to Fill, it built the kernel nicely. It still died before the first printk :) but at least I am a little closer. I got Fill_I out of the See MIPS Run book, it has the same option hex (0x14) as Fill, does anyone know why this changed? From jamiller1110@cox.net Mon May 15 03:38:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 03:38:15 +0200 (CEST) Received: from eastrmmtao01.cox.net ([68.230.240.38]:11687 "HELO eastrmmtao01.cox.net") by ftp.linux-mips.org with SMTP id S8133760AbWEOBiI (ORCPT ); Mon, 15 May 2006 03:38:08 +0200 Received: from hermes.mountolympos.net ([70.160.186.45]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060515013801.YQMZ17255.eastrmmtao01.cox.net@hermes.mountolympos.net> for ; Sun, 14 May 2006 21:38:01 -0400 Received: from zeus.mountolympos.net (zeus.mountolympos.net [192.168.2.2]) by hermes.mountolympos.net (Postfix) with ESMTP id 5572C1677B for ; Sun, 14 May 2006 21:38:01 -0400 (EDT) Received: from [192.168.2.4] (odysseus.mountolympos.net [192.168.2.4]) by zeus.mountolympos.net (Postfix) with ESMTP id 3438A100A118 for ; Sun, 14 May 2006 21:38:01 -0400 (EDT) Message-ID: <4467DB78.8030304@mountolympos.net> Date: Sun, 14 May 2006 21:38:00 -0400 From: John Miller User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 CC: linux-mips@linux-mips.org Subject: Re: Instruction error with cache opcode References: <446735C6.2080306@mountolympos.net> <002a01c67761$253e97f0$0202a8c0@Ulysses> <4467796E.8060000@mountolympos.net> <20060515.100659.126574393.nemoto@toshiba-tops.co.jp> <4467DACE.9000800@mountolympos.net> In-Reply-To: <4467DACE.9000800@mountolympos.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jamiller1110@cox.net Precedence: bulk X-list: linux-mips Content-Length: 74 Lines: 1 Sorry, I sent that last message without thanking everyone for their help. From anemo@mba.ocn.ne.jp Mon May 15 03:55:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 03:55:25 +0200 (CEST) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:45943 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S8133767AbWEOBzR (ORCPT ); Mon, 15 May 2006 03:55:17 +0200 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Mon, 15 May 2006 10:55:16 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 86C892058D; Mon, 15 May 2006 10:55:14 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 7B69B20579; Mon, 15 May 2006 10:55:14 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id k4F1tD4D026479; Mon, 15 May 2006 10:55:13 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 15 May 2006 10:55:13 +0900 (JST) Message-Id: <20060515.105513.27954532.nemoto@toshiba-tops.co.jp> To: ths@networkno.de Cc: linux-mips@linux-mips.org Subject: Re: kernel patch for QEMU ? From: Atsushi Nemoto In-Reply-To: <20060514182151.GB800@networkno.de> References: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> <20060514182151.GB800@networkno.de> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 851 Lines: 21 On Sun, 14 May 2006 19:21:51 +0100, Thiemo Seufer wrote: > > The mips-test-0.1 contains kernel 2.6.16-rc6. Is this a stock > > kernel.org's kernel or lmo's kernel? Or is there any patch to make > > kernel run on QEMU? > > This kernel is stock lmo except for a small patch which allows clean > system shutdown (qemu 0.8.1 does not have the counterpart to it). > The patch should be completely irrelevant otherwise. > > However, later kernels try to access the CP0 pagemask register which > is R10000 specific, IIRC Qemu throws an Reserved Instruction exception > on accessing it. Thanks. I'm looking output of "git-diff linux-2.6.16-rc6" but still failed to find relevant changes... The stock QEMU 0.8.1 works ok with vmlinux-r1 in mips-test-0.1 so it should be something different on kernel side. Hmm... --- Atsushi Nemoto From dusko.dobranic@micronasnit.com Mon May 15 10:48:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 10:48:55 +0200 (CEST) Received: from krt.tmd.ns.ac.yu ([147.91.177.65]:53659 "EHLO krt.neobee.net") by ftp.linux-mips.org with ESMTP id S8133411AbWEOIsp (ORCPT ); Mon, 15 May 2006 10:48:45 +0200 Received: from localhost (localhost [127.0.0.1]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id k4F9DrZ7028090 for ; Mon, 15 May 2006 11:13:53 +0200 Received: from krt.neobee.net ([127.0.0.1]) by localhost (krt.neobee.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25991-09 for ; Mon, 15 May 2006 11:13:53 +0200 (CEST) Received: from [192.168.0.91] ([192.168.0.91]) by krt.neobee.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id k4F9DfUQ028080 for ; Mon, 15 May 2006 11:13:42 +0200 Message-ID: <4468405C.3090005@micronasnit.com> Date: Mon, 15 May 2006 10:48:28 +0200 From: Dusko Dobranic User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: gcc-4.0.3, gcc-4.1.0 no output with out Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at krt.neobee.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dusko.dobranic@micronasnit.com Precedence: bulk X-list: linux-mips Content-Length: 3772 Lines: 115 Hello, I'm using linux kernel 2.6.15, uclibc-0.9.28 and toolchains (built using buildroot) on embedded MIPS platform based od 4KEc CPU. Simple examples compiled with gcc-4.0.3 or gcc-4.1.0 not producing output. There is a piece of code: for (i = 0; i < v.size(); i++) { out << v[i].s << " :\t" << v[i].t * (double(1000000)/n)/CLOCKS_PER_SEC << " ms" << endl; // printf("%s :\t %2.3f ms\n", v[i].s, v[i].t * (double(1000000)/n)/CLOCKS_PER_SEC); } When execute, output looks like this: $./d_1++ 100000 ./d_1 100000 virtual px->f(1) : ms ptr-to-fct p[1](ps,1) : ms virtual x.f(1) : ms ptr-to-fct p[1](&s,1) : ms member px->g(1) : ms global g(ps,1) : ms member x.g(1) : ms global g(&s,1) : ms static X::h(1) : ms global h(1) : ms inline px->k(1) : ms macro K(ps,1) : ms inline x.k(1) : ms macro K(&s,1) : ms base1 member pc->g(i) : ms base2 member pc->gg(i) : ms base1 virtual pa->f(i) : ms base2 virtual pb->ff(i) : ms base1 down-cast cast(pa,pc) : ms base2 down-cast cast(pb,pc) : ms base1 up-cast cast(pc,pa) : ms base2 up-cast cast(pc,pb) : ms base2 cross-cast cast(pb,pa) : ms base1 down-cast2 cast(pa,pcc) : ms base2 down-cast cast(pb,pcc) : ms base1 up-cast cast(pcc,pa) : ms base2 up-cast2 cast(pcc,pb) : ms base2 cross-cast2 cast(pa,pb) : ms base1 cross-cast2 cast(pb,pa) : ms vbase member pd->gg(i) : ms vbase virtual pa->f(i) : ms vbase down-cast cast(pa,pd) : ms vbase up-cast cast(pd,pa) : ms vbase typeid(pa) : ms vbase typeid(pd) : ms pmf virtual (pa->*pmf)(i) : ms pmf (pa->*pmf)(i) : ms call by_ref(pp) : ms call by_val(pp) : ms call ptr-to-fct oper(h,glob) : ms call fct-obj oper(fct,glob) : ms Commented line with printf do produce output: # ./d_1 100000 ./d_1 100000 virtual px->f(1) : 0.5 ms ptr-to-fct p[1](ps,1) : 0.5 ms virtual x.f(1) : 0.5 ms ptr-to-fct p[1](&s,1) : 0.5 ms member px->g(1) : 0.5 ms global g(ps,1) : 0.5 ms member x.g(1) : 0.6 ms global g(&s,1) : 0.5 ms static X::h(1) : 0.4 ms global h(1) : 0.5 ms inline px->k(1) : 0.5 ms macro K(ps,1) : 0.2 ms inline x.k(1) : 0.5 ms macro K(&s,1) : 0.2 ms base1 member pc->g(i) : 0.5 ms base2 member pc->gg(i) : 0.5 ms base1 virtual pa->f(i) : 0.6 ms base2 virtual pb->ff(i) : 0.6 ms base1 down-cast cast(pa,pc) : 0.5 ms base2 down-cast cast(pb,pc) : 0.6 ms base1 up-cast cast(pc,pa) : 2.4 ms base2 up-cast cast(pc,pb) : 2.2 ms base2 cross-cast cast(pb,pa) : 4.7 ms base1 down-cast2 cast(pa,pcc) : 0.5 ms base2 down-cast cast(pb,pcc) : 0.6 ms base1 up-cast cast(pcc,pa) : 2.4 ms base2 up-cast2 cast(pcc,pb) : 2.2 ms base2 cross-cast2 cast(pa,pb) : 4.7 ms base1 cross-cast2 cast(pb,pa) : 4.3 ms vbase member pd->gg(i) : 0.6 ms vbase virtual pa->f(i) : 0.9 ms vbase down-cast cast(pa,pd) : 0.7 ms vbase up-cast cast(pd,pa) : 4.4 ms vbase typeid(pa) : 0.8 ms vbase typeid(pd) : 0.8 ms pmf virtual (pa->*pmf)(i) : 1.2 ms pmf (pa->*pmf)(i) : 0.7 ms call by_ref(pp) : 0.5 ms call by_val(pp) : 0.5 ms call ptr-to-fct oper(h,glob) : 0.8 ms call fct-obj oper(fct,glob) : 0.8 ms When using gcc-3.4.2 everything is OK. From anemo@mba.ocn.ne.jp Mon May 15 16:22:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 16:22:52 +0200 (CEST) Received: from mba.ocn.ne.jp ([210.190.142.172]:8174 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133531AbWEOOWp (ORCPT ); Mon, 15 May 2006 16:22:45 +0200 Received: from localhost (p6076-ipad203funabasi.chiba.ocn.ne.jp [222.146.85.76]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 83994847F; Mon, 15 May 2006 23:22:39 +0900 (JST) Date: Mon, 15 May 2006 23:23:24 +0900 (JST) Message-Id: <20060515.232324.95063110.anemo@mba.ocn.ne.jp> To: ths@networkno.de Cc: linux-mips@linux-mips.org Subject: Re: kernel patch for QEMU ? From: Atsushi Nemoto In-Reply-To: <20060515.105513.27954532.nemoto@toshiba-tops.co.jp> References: <20060515.010846.25910142.anemo@mba.ocn.ne.jp> <20060514182151.GB800@networkno.de> <20060515.105513.27954532.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 568 Lines: 12 On Mon, 15 May 2006 10:55:13 +0900 (JST), Atsushi Nemoto wrote: > The stock QEMU 0.8.1 works ok with vmlinux-r1 in mips-test-0.1 so it > should be something different on kernel side. Hmm... It seems the difference comes from configuration. If I enabled CONFIG_DEBUG_SPINLOCK, I can run a kernel compiled from current git tree. Also, if I used kernel-config in mips-test-0.1 and disabled CONFIG_DEBUG_SPINLOCK, the kernel stops at the same place. So I'm quite sure the option affects qemu's behavior. But no idea why ... --- Atsushi Nemoto From Karel@vhouten.xs4all.nl Mon May 15 18:23:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 18:23:21 +0200 (CEST) Received: from vhouten.xs4all.nl ([80.126.144.140]:54953 "HELO vhouten.xs4all.nl") by ftp.linux-mips.org with SMTP id S8133535AbWEOQXN (ORCPT ); Mon, 15 May 2006 18:23:13 +0200 Received: from [10.254.10.11] (faramir.local [10.254.10.11]) by vhouten.xs4all.nl (Postfix) with ESMTP id 4B8D71FF1B8; Mon, 15 May 2006 18:23:02 +0200 (MEST) Message-ID: <4468AAE6.9060605@vhouten.xs4all.nl> Date: Mon, 15 May 2006 18:23:02 +0200 From: Karel van Houten User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Martin Michlmayr , debian-mips@lists.debian.org, linux-mips@linux-mips.org Subject: Re: 2.6 for DECstation, d-i References: <44635C0D.7040901@vhouten.xs4all.nl> <20060511173350.GM7827@deprecation.cyrius.com> <20060511185446.GB7234@deprecation.cyrius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Karel@vhouten.xs4all.nl Precedence: bulk X-list: linux-mips Content-Length: 1072 Lines: 32 Hi all, I've downloaded a current git source tree, and compiled that natively on my /260, using a debian testing/unstable installation (gcc 4.0.3). I only used an older version of the dec_esp driver, which gave me no problems. That kernel boots fine, serial console works as it should. As time permits I'll try to test some more options that I used in my 2.4 kernels. Good work (Maciej and others) ! Regards, Karel. Maciej W. Rozycki wrote: > Of course there is. Just enable SERIAL_NONSTANDARD, SERIAL_DEC, > >SERIAL_DEC_CONSOLE and ZS. They are all in drivers/char/Kconfig and it's >not a coincidence the options are the same as in 2.4. > > The driver has NOT been ported to use the serial core and frankly I would >rather it went away and write the necessary system specific glue >(including that horrible stuff for incorrect wiring used in all DEC >systems making use of the Zilog chips) to use drivers/net/wan/z85230.c >instead which already has a lot of nice stuff like support for synchronous >operation and DMA, HDLC framing, etc. > > Maciej > > From anemo@mba.ocn.ne.jp Mon May 15 18:25:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 18:25:37 +0200 (CEST) Received: from mba.ocn.ne.jp ([210.190.142.172]:59613 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133535AbWEOQZY (ORCPT ); Mon, 15 May 2006 18:25:24 +0200 Received: from localhost (p6076-ipad203funabasi.chiba.ocn.ne.jp [222.146.85.76]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 2A1A1B69B; Tue, 16 May 2006 01:25:19 +0900 (JST) Date: Tue, 16 May 2006 01:26:03 +0900 (JST) Message-Id: <20060516.012603.41010976.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] unify mips_fpu_soft_struct and mips_fpu_hard_struct From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 18819 Lines: 531 The struct mips_fpu_soft_struct and mips_fpu_hard_struct are completely same now and the kernel fpu emulator assumes that. This patch unifies them to mips_fpu_struct and get rid of mips_fpu_union. Signed-off-by: Atsushi Nemoto arch/mips/kernel/asm-offsets.c | 66 ++++++++++++++++++------------------ arch/mips/kernel/branch.c | 2 - arch/mips/kernel/irixsig.c | 2 - arch/mips/kernel/ptrace.c | 26 ++++---------- arch/mips/kernel/ptrace32.c | 16 ++------ arch/mips/kernel/traps.c | 9 ++-- arch/mips/math-emu/cp1emu.c | 15 +++----- arch/mips/math-emu/ieee754.h | 2 - arch/mips/math-emu/kernel_linkage.c | 24 +++++-------- include/asm-mips/fpu.h | 3 - include/asm-mips/fpu_emulator.h | 4 +- include/asm-mips/processor.h | 16 +------- 12 files changed, 76 insertions(+), 109 deletions(-) diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c index 0facfaf..f1bb6a2 100644 --- a/arch/mips/kernel/asm-offsets.c +++ b/arch/mips/kernel/asm-offsets.c @@ -141,72 +141,72 @@ void output_thread_defines(void) void output_thread_fpu_defines(void) { offset("#define THREAD_FPR0 ", - struct task_struct, thread.fpu.hard.fpr[0]); + struct task_struct, thread.fpu.fpr[0]); offset("#define THREAD_FPR1 ", - struct task_struct, thread.fpu.hard.fpr[1]); + struct task_struct, thread.fpu.fpr[1]); offset("#define THREAD_FPR2 ", - struct task_struct, thread.fpu.hard.fpr[2]); + struct task_struct, thread.fpu.fpr[2]); offset("#define THREAD_FPR3 ", - struct task_struct, thread.fpu.hard.fpr[3]); + struct task_struct, thread.fpu.fpr[3]); offset("#define THREAD_FPR4 ", - struct task_struct, thread.fpu.hard.fpr[4]); + struct task_struct, thread.fpu.fpr[4]); offset("#define THREAD_FPR5 ", - struct task_struct, thread.fpu.hard.fpr[5]); + struct task_struct, thread.fpu.fpr[5]); offset("#define THREAD_FPR6 ", - struct task_struct, thread.fpu.hard.fpr[6]); + struct task_struct, thread.fpu.fpr[6]); offset("#define THREAD_FPR7 ", - struct task_struct, thread.fpu.hard.fpr[7]); + struct task_struct, thread.fpu.fpr[7]); offset("#define THREAD_FPR8 ", - struct task_struct, thread.fpu.hard.fpr[8]); + struct task_struct, thread.fpu.fpr[8]); offset("#define THREAD_FPR9 ", - struct task_struct, thread.fpu.hard.fpr[9]); + struct task_struct, thread.fpu.fpr[9]); offset("#define THREAD_FPR10 ", - struct task_struct, thread.fpu.hard.fpr[10]); + struct task_struct, thread.fpu.fpr[10]); offset("#define THREAD_FPR11 ", - struct task_struct, thread.fpu.hard.fpr[11]); + struct task_struct, thread.fpu.fpr[11]); offset("#define THREAD_FPR12 ", - struct task_struct, thread.fpu.hard.fpr[12]); + struct task_struct, thread.fpu.fpr[12]); offset("#define THREAD_FPR13 ", - struct task_struct, thread.fpu.hard.fpr[13]); + struct task_struct, thread.fpu.fpr[13]); offset("#define THREAD_FPR14 ", - struct task_struct, thread.fpu.hard.fpr[14]); + struct task_struct, thread.fpu.fpr[14]); offset("#define THREAD_FPR15 ", - struct task_struct, thread.fpu.hard.fpr[15]); + struct task_struct, thread.fpu.fpr[15]); offset("#define THREAD_FPR16 ", - struct task_struct, thread.fpu.hard.fpr[16]); + struct task_struct, thread.fpu.fpr[16]); offset("#define THREAD_FPR17 ", - struct task_struct, thread.fpu.hard.fpr[17]); + struct task_struct, thread.fpu.fpr[17]); offset("#define THREAD_FPR18 ", - struct task_struct, thread.fpu.hard.fpr[18]); + struct task_struct, thread.fpu.fpr[18]); offset("#define THREAD_FPR19 ", - struct task_struct, thread.fpu.hard.fpr[19]); + struct task_struct, thread.fpu.fpr[19]); offset("#define THREAD_FPR20 ", - struct task_struct, thread.fpu.hard.fpr[20]); + struct task_struct, thread.fpu.fpr[20]); offset("#define THREAD_FPR21 ", - struct task_struct, thread.fpu.hard.fpr[21]); + struct task_struct, thread.fpu.fpr[21]); offset("#define THREAD_FPR22 ", - struct task_struct, thread.fpu.hard.fpr[22]); + struct task_struct, thread.fpu.fpr[22]); offset("#define THREAD_FPR23 ", - struct task_struct, thread.fpu.hard.fpr[23]); + struct task_struct, thread.fpu.fpr[23]); offset("#define THREAD_FPR24 ", - struct task_struct, thread.fpu.hard.fpr[24]); + struct task_struct, thread.fpu.fpr[24]); offset("#define THREAD_FPR25 ", - struct task_struct, thread.fpu.hard.fpr[25]); + struct task_struct, thread.fpu.fpr[25]); offset("#define THREAD_FPR26 ", - struct task_struct, thread.fpu.hard.fpr[26]); + struct task_struct, thread.fpu.fpr[26]); offset("#define THREAD_FPR27 ", - struct task_struct, thread.fpu.hard.fpr[27]); + struct task_struct, thread.fpu.fpr[27]); offset("#define THREAD_FPR28 ", - struct task_struct, thread.fpu.hard.fpr[28]); + struct task_struct, thread.fpu.fpr[28]); offset("#define THREAD_FPR29 ", - struct task_struct, thread.fpu.hard.fpr[29]); + struct task_struct, thread.fpu.fpr[29]); offset("#define THREAD_FPR30 ", - struct task_struct, thread.fpu.hard.fpr[30]); + struct task_struct, thread.fpu.fpr[30]); offset("#define THREAD_FPR31 ", - struct task_struct, thread.fpu.hard.fpr[31]); + struct task_struct, thread.fpu.fpr[31]); offset("#define THREAD_FCR31 ", - struct task_struct, thread.fpu.hard.fcr31); + struct task_struct, thread.fpu.fcr31); linefeed; } diff --git a/arch/mips/kernel/branch.c b/arch/mips/kernel/branch.c index b6232d9..76fd3f2 100644 --- a/arch/mips/kernel/branch.c +++ b/arch/mips/kernel/branch.c @@ -178,7 +178,7 @@ int __compute_return_epc(struct pt_regs if (is_fpu_owner()) asm volatile("cfc1\t%0,$31" : "=r" (fcr31)); else - fcr31 = current->thread.fpu.hard.fcr31; + fcr31 = current->thread.fpu.fcr31; preempt_enable(); bit = (insn.i_format.rt >> 2); diff --git a/arch/mips/kernel/irixsig.c b/arch/mips/kernel/irixsig.c index 8150f07..a9bf6cc 100644 --- a/arch/mips/kernel/irixsig.c +++ b/arch/mips/kernel/irixsig.c @@ -260,7 +260,7 @@ irix_sigreturn(struct pt_regs *regs) for(i = 0; i < 32; i++) error |= __get_user(fregs[i], &context->fpregs[i]); - error |= __get_user(current->thread.fpu.hard.fcr31, &context->fpcsr); + error |= __get_user(current->thread.fpu.fcr31, &context->fpcsr); } /* XXX do sigstack crapola here... XXX */ diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c index 539b357..823c679 100644 --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -120,11 +120,11 @@ int ptrace_getfpregs (struct task_struct __put_user ((__u64) -1, i + (__u64 __user *) data); } + __put_user (child->thread.fpu.fcr31, data + 64); + if (cpu_has_fpu) { unsigned int flags, tmp; - __put_user (child->thread.fpu.hard.fcr31, data + 64); - preempt_disable(); if (cpu_has_mipsmt) { unsigned int vpflags = dvpe(); @@ -142,7 +142,6 @@ int ptrace_getfpregs (struct task_struct preempt_enable(); __put_user (tmp, data + 65); } else { - __put_user (child->thread.fpu.soft.fcr31, data + 64); __put_user ((__u32) 0, data + 65); } @@ -162,10 +161,7 @@ int ptrace_setfpregs (struct task_struct for (i = 0; i < 32; i++) __get_user (fregs[i], i + (__u64 __user *) data); - if (cpu_has_fpu) - __get_user (child->thread.fpu.hard.fcr31, data + 64); - else - __get_user (child->thread.fpu.soft.fcr31, data + 64); + __get_user (child->thread.fpu.fcr31, data + 64); /* FIR may not be written. */ @@ -241,10 +237,7 @@ long arch_ptrace(struct task_struct *chi tmp = regs->lo; break; case FPC_CSR: - if (cpu_has_fpu) - tmp = child->thread.fpu.hard.fcr31; - else - tmp = child->thread.fpu.soft.fcr31; + tmp = child->thread.fpu.fcr31; break; case FPC_EIR: { /* implementation / version register */ unsigned int flags; @@ -336,9 +329,9 @@ long arch_ptrace(struct task_struct *chi if (!tsk_used_math(child)) { /* FP not yet used */ - memset(&child->thread.fpu.hard, ~0, - sizeof(child->thread.fpu.hard)); - child->thread.fpu.hard.fcr31 = 0; + memset(&child->thread.fpu, ~0, + sizeof(child->thread.fpu)); + child->thread.fpu.fcr31 = 0; } #ifdef CONFIG_32BIT /* @@ -369,10 +362,7 @@ long arch_ptrace(struct task_struct *chi regs->lo = data; break; case FPC_CSR: - if (cpu_has_fpu) - child->thread.fpu.hard.fcr31 = data; - else - child->thread.fpu.soft.fcr31 = data; + child->thread.fpu.fcr31 = data; break; case DSP_BASE ... DSP_BASE + 5: { dspreg_t *dregs; diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c index 8704dc0..f40ecd8 100644 --- a/arch/mips/kernel/ptrace32.c +++ b/arch/mips/kernel/ptrace32.c @@ -166,10 +166,7 @@ asmlinkage int sys32_ptrace(int request, tmp = regs->lo; break; case FPC_CSR: - if (cpu_has_fpu) - tmp = child->thread.fpu.hard.fcr31; - else - tmp = child->thread.fpu.soft.fcr31; + tmp = child->thread.fpu.fcr31; break; case FPC_EIR: { /* implementation / version register */ unsigned int flags; @@ -288,9 +285,9 @@ asmlinkage int sys32_ptrace(int request, if (!tsk_used_math(child)) { /* FP not yet used */ - memset(&child->thread.fpu.hard, ~0, - sizeof(child->thread.fpu.hard)); - child->thread.fpu.hard.fcr31 = 0; + memset(&child->thread.fpu, ~0, + sizeof(child->thread.fpu)); + child->thread.fpu.fcr31 = 0; } /* * The odd registers are actually the high order bits @@ -318,10 +315,7 @@ asmlinkage int sys32_ptrace(int request, regs->lo = data; break; case FPC_CSR: - if (cpu_has_fpu) - child->thread.fpu.hard.fcr31 = data; - else - child->thread.fpu.soft.fcr31 = data; + child->thread.fpu.fcr31 = data; break; case DSP_BASE ... DSP_BASE + 5: { dspreg_t *dregs; diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 35cb08d..8b3822a 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -65,7 +65,7 @@ extern asmlinkage void handle_mcheck(voi extern asmlinkage void handle_reserved(void); extern int fpu_emulator_cop1Handler(struct pt_regs *xcp, - struct mips_fpu_soft_struct *ctx); + struct mips_fpu_struct *ctx); void (*board_be_init)(void); int (*board_be_handler)(struct pt_regs *regs, int is_fixup); @@ -600,8 +600,7 @@ asmlinkage void do_fpe(struct pt_regs *r preempt_enable(); /* Run the emulator */ - sig = fpu_emulator_cop1Handler (regs, - ¤t->thread.fpu.soft); + sig = fpu_emulator_cop1Handler (regs, ¤t->thread.fpu); preempt_disable(); @@ -610,7 +609,7 @@ asmlinkage void do_fpe(struct pt_regs *r * We can't allow the emulated instruction to leave any of * the cause bit set in $fcr31. */ - current->thread.fpu.soft.fcr31 &= ~FPU_CSR_ALL_X; + current->thread.fpu.fcr31 &= ~FPU_CSR_ALL_X; /* Restore the hardware register state */ restore_fp(current); @@ -755,7 +754,7 @@ asmlinkage void do_cpu(struct pt_regs *r if (!cpu_has_fpu) { int sig = fpu_emulator_cop1Handler(regs, - ¤t->thread.fpu.soft); + ¤t->thread.fpu); if (sig) force_sig(sig, current); #ifdef CONFIG_MIPS_MT_FPAFF diff --git a/arch/mips/math-emu/cp1emu.c b/arch/mips/math-emu/cp1emu.c index aa5818a..3f0d5d2 100644 --- a/arch/mips/math-emu/cp1emu.c +++ b/arch/mips/math-emu/cp1emu.c @@ -60,15 +60,15 @@ /* Function which emulates a floating point instruction. */ -static int fpu_emu(struct pt_regs *, struct mips_fpu_soft_struct *, +static int fpu_emu(struct pt_regs *, struct mips_fpu_struct *, mips_instruction); #if __mips >= 4 && __mips != 32 static int fpux_emu(struct pt_regs *, - struct mips_fpu_soft_struct *, mips_instruction); + struct mips_fpu_struct *, mips_instruction); #endif -/* Further private data for which no space exists in mips_fpu_soft_struct */ +/* Further private data for which no space exists in mips_fpu_struct */ struct mips_fpu_emulator_stats fpuemustats; @@ -203,7 +203,7 @@ static int isBranchInstr(mips_instructio * Two instructions if the instruction is in a branch delay slot. */ -static int cop1Emulate(struct pt_regs *xcp, struct mips_fpu_soft_struct *ctx) +static int cop1Emulate(struct pt_regs *xcp, struct mips_fpu_struct *ctx) { mips_instruction ir; void * emulpc, *contpc; @@ -595,7 +595,7 @@ DEF3OP(msub, dp, ieee754dp_mul, ieee754d DEF3OP(nmadd, dp, ieee754dp_mul, ieee754dp_add, ieee754dp_neg); DEF3OP(nmsub, dp, ieee754dp_mul, ieee754dp_sub, ieee754dp_neg); -static int fpux_emu(struct pt_regs *xcp, struct mips_fpu_soft_struct *ctx, +static int fpux_emu(struct pt_regs *xcp, struct mips_fpu_struct *ctx, mips_instruction ir) { unsigned rcsr = 0; /* resulting csr */ @@ -759,7 +759,7 @@ static int fpux_emu(struct pt_regs *xcp, /* * Emulate a single COP1 arithmetic instruction. */ -static int fpu_emu(struct pt_regs *xcp, struct mips_fpu_soft_struct *ctx, +static int fpu_emu(struct pt_regs *xcp, struct mips_fpu_struct *ctx, mips_instruction ir) { int rfmt; /* resulting format */ @@ -1233,8 +1233,7 @@ static int fpu_emu(struct pt_regs *xcp, return 0; } -int fpu_emulator_cop1Handler(struct pt_regs *xcp, - struct mips_fpu_soft_struct *ctx) +int fpu_emulator_cop1Handler(struct pt_regs *xcp, struct mips_fpu_struct *ctx) { unsigned long oldepc, prevepc; mips_instruction insn; diff --git a/arch/mips/math-emu/ieee754.h b/arch/mips/math-emu/ieee754.h index 171f177..dd91733 100644 --- a/arch/mips/math-emu/ieee754.h +++ b/arch/mips/math-emu/ieee754.h @@ -329,7 +329,7 @@ struct _ieee754_csr { unsigned pad0:7; #endif }; -#define ieee754_csr (*(struct _ieee754_csr *)(¤t->thread.fpu.soft.fcr31)) +#define ieee754_csr (*(struct _ieee754_csr *)(¤t->thread.fpu.fcr31)) static inline unsigned ieee754_getrm(void) { diff --git a/arch/mips/math-emu/kernel_linkage.c b/arch/mips/math-emu/kernel_linkage.c index d187ab7..56ca0c6 100644 --- a/arch/mips/math-emu/kernel_linkage.c +++ b/arch/mips/math-emu/kernel_linkage.c @@ -39,9 +39,9 @@ void fpu_emulator_init_fpu(void) printk("Algorithmics/MIPS FPU Emulator v1.5\n"); } - current->thread.fpu.soft.fcr31 = 0; + current->thread.fpu.fcr31 = 0; for (i = 0; i < 32; i++) { - current->thread.fpu.soft.fpr[i] = SIGNALLING_NAN; + current->thread.fpu.fpr[i] = SIGNALLING_NAN; } } @@ -59,10 +59,9 @@ int fpu_emulator_save_context(struct sig for (i = 0; i < 32; i++) { err |= - __put_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); + __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); } - err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); return err; } @@ -74,10 +73,9 @@ int fpu_emulator_restore_context(struct for (i = 0; i < 32; i++) { err |= - __get_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); + __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); } - err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); return err; } @@ -94,10 +92,9 @@ int fpu_emulator_save_context32(struct s for (i = 0; i < 32; i+=2) { err |= - __put_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); + __put_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); } - err |= __put_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + err |= __put_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); return err; } @@ -109,10 +106,9 @@ int fpu_emulator_restore_context32(struc for (i = 0; i < 32; i+=2) { err |= - __get_user(current->thread.fpu.soft.fpr[i], - &sc->sc_fpregs[i]); + __get_user(current->thread.fpu.fpr[i], &sc->sc_fpregs[i]); } - err |= __get_user(current->thread.fpu.soft.fcr31, &sc->sc_fpc_csr); + err |= __get_user(current->thread.fpu.fcr31, &sc->sc_fpc_csr); return err; } diff --git a/include/asm-mips/fpu.h b/include/asm-mips/fpu.h index b0f5001..8bf510a 100644 --- a/include/asm-mips/fpu.h +++ b/include/asm-mips/fpu.h @@ -138,10 +138,9 @@ static inline fpureg_t *get_fpu_regs(str if (cpu_has_fpu) { if ((tsk == current) && __is_fpu_owner()) _save_fp(current); - return tsk->thread.fpu.hard.fpr; } - return tsk->thread.fpu.soft.fpr; + return tsk->thread.fpu.fpr; } #endif /* _ASM_FPU_H */ diff --git a/include/asm-mips/fpu_emulator.h b/include/asm-mips/fpu_emulator.h index 16cb4d1..2731c38 100644 --- a/include/asm-mips/fpu_emulator.h +++ b/include/asm-mips/fpu_emulator.h @@ -12,8 +12,8 @@ * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. * - * Further private data for which no space exists in mips_fpu_soft_struct. - * This should be subsumed into the mips_fpu_soft_struct structure as + * Further private data for which no space exists in mips_fpu_struct. + * This should be subsumed into the mips_fpu_struct structure as * defined in processor.h as soon as the absurd wired absolute assembler * offsets become dynamic at compile time. * diff --git a/include/asm-mips/processor.h b/include/asm-mips/processor.h index 0fb75f0..8393646 100644 --- a/include/asm-mips/processor.h +++ b/include/asm-mips/processor.h @@ -71,11 +71,6 @@ extern unsigned int vced_count, vcei_cou typedef __u64 fpureg_t; -struct mips_fpu_hard_struct { - fpureg_t fpr[NUM_FPU_REGS]; - unsigned int fcr31; -}; - /* * It would be nice to add some more fields for emulator statistics, but there * are a number of fixed offsets in offset.h and elsewhere that would have to @@ -83,18 +78,13 @@ struct mips_fpu_hard_struct { * the FPU emulator for now. See asm-mips/fpu_emulator.h. */ -struct mips_fpu_soft_struct { +struct mips_fpu_struct { fpureg_t fpr[NUM_FPU_REGS]; unsigned int fcr31; }; -union mips_fpu_union { - struct mips_fpu_hard_struct hard; - struct mips_fpu_soft_struct soft; -}; - #define INIT_FPU { \ - {{0,},} \ + {0,} \ } #define NUM_DSP_REGS 6 @@ -133,7 +123,7 @@ struct thread_struct { unsigned long cp0_status; /* Saved fpu/fpu emulator stuff. */ - union mips_fpu_union fpu; + struct mips_fpu_struct fpu; #ifdef CONFIG_MIPS_MT_FPAFF /* Emulated instruction count */ unsigned long emulated_fp; From yshitoot@stellartec.com Mon May 15 18:36:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 15 May 2006 18:36:58 +0200 (CEST) Received: from gateway.stellartec.com ([65.107.16.99]:43021 "EHLO gateway.stellartec.com") by ftp.linux-mips.org with ESMTP id S8133569AbWEOQgu (ORCPT ); Mon, 15 May 2006 18:36:50 +0200 Received: from Exchange.stellartec.com ([10.1.1.7]) by gateway.stellartec.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 09:32:50 -0700 Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6783D.34D4EE96" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: normal Priority: normal Subject: Need help burning flash using osprey vr41xx Date: Mon, 15 May 2006 09:32:52 -0700 Message-ID: <7F5F67B895426C40AC75B8290421C239D1ED02@Exchange.stellartec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need help burning flash using osprey vr41xx thread-index: AcZ4PTY+uPxSRx/bR++VWyHo1wyvPg== From: "Yashwant Shitoot" To: X-OriginalArrivalTime: 15 May 2006 16:32:50.0239 (UTC) FILETIME=[34E4DCF0:01C6783D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 11432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yshitoot@stellartec.com Precedence: bulk X-list: linux-mips Content-Length: 3302 Lines: 131 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6783D.34D4EE96 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: E8350D8F-73BE-426E-B8F0-E99E7CB1977F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I do have a working system with vrboot, vmlinux and romdisk. Now I would like to use about 10 bytes in the unused portion of flash (at addr 0xbfc01fc0) and put in a serial number. I have tried bin2rom serialNum.inf 0xbfc01fc0 0xbfc01fff (and some variations) however ethload hangs up at "sending jump addr". =20 Any suggestions ? =20 Thanks =20 Yash =20 ------_=_NextPart_001_01C6783D.34D4EE96 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 6FC3009E-4F04-46E2-B509-239A0C4033E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable