From owner-freebsd-mips@FreeBSD.ORG Mon Oct 17 14:06:39 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 918621065674; Mon, 17 Oct 2011 14:06:39 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 85E708FC12; Mon, 17 Oct 2011 14:06:38 +0000 (UTC) Received: by wyi40 with SMTP id 40so2250215wyi.13 for ; Mon, 17 Oct 2011 07:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6zZtni0FZnNA98DUYdAShayoe2TyiOMXULbxUiO7N3E=; b=Mu1r1mLh/E8XdL5sWWhKlsog4+RDfrw67li+U3kRDPfVtlARNtMSCkK97qCIOh89Ae zsftf+UwOZj6cYKquVGqdyiFEH1BD2O9GOZi+Gr7T/6OPcg3Il3A8Cm2nm/Dpghpmhtq OXxcYWIG9So39+NJ2pMmlovsYujSgZ+iLv6WM= MIME-Version: 1.0 Received: by 10.216.138.82 with SMTP id z60mr3920801wei.11.1318860397388; Mon, 17 Oct 2011 07:06:37 -0700 (PDT) Received: by 10.216.188.3 with HTTP; Mon, 17 Oct 2011 07:06:37 -0700 (PDT) Date: Mon, 17 Oct 2011 19:36:37 +0530 Message-ID: From: "Jayachandran C." To: freebsd-mips@freebsd.org, "M. Warner Losh" , Juli Mallett Content-Type: multipart/mixed; boundary=0016e6d7e1007ea39a04af7f1d1b Cc: Subject: [PATCH] FDT support for mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:06:39 -0000 --0016e6d7e1007ea39a04af7f1d1b Content-Type: text/plain; charset=ISO-8859-1 I'm planning to add basic support for device trees to MIPS. The attached patch adds the required files for MIPS. I have a separate patch which adds device tree support for XLP which is based on this. Comments welcome. JC. --0016e6d7e1007ea39a04af7f1d1b Content-Type: text/x-patch; charset=US-ASCII; name="mips-fdt.patch" Content-Disposition: attachment; filename="mips-fdt.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtvjg7wy0 Y29tbWl0IDI0YWRlYjUyNTM0ZmJkM2Q2ZTc5YTgxMDk0Nzg1NzU5NTI0MTk3MjQKQXV0aG9yOiBK YXlhY2hhbmRyYW4gQyA8amF5YWNoYW5kcmFuY0BuZXRsb2dpY21pY3JvLmNvbT4KRGF0ZTogICBN b24gT2N0IDE3IDE4OjM4OjQzIDIwMTEgKzA1MzAKCiAgICBGRFQgc3VwcG9ydCBmb3IgTUlQUy4K ICAgIAogICAgQWRkIHN1cHBvcnQgZm9yIGNvbXBpbGluZyBNSVBTIHdpdGggRkRUIHN1cHBvcnQu CgpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvTWFrZWZpbGUubWlwcyBiL3N5cy9jb25mL01ha2VmaWxl Lm1pcHMKaW5kZXggYWIyYjQwYS4uNjkyODA3OSAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvTWFrZWZp bGUubWlwcworKysgYi9zeXMvY29uZi9NYWtlZmlsZS5taXBzCkBAIC0yOCw2ICsyOCw4IEBAIFM9 CS4uLy4uLy4uCiAuZW5kaWYKIC5pbmNsdWRlICIkUy9jb25mL2tlcm4ucHJlLm1rIgogCitJTkNM VURFUys9IC1JJFMvY29udHJpYi9saWJmZHQKKwogTERTQ1JJUFRfTkFNRT89bGRzY3JpcHQuJE0K IFNZU1RFTV9MRDo9ICR7U1lTVEVNX0xEOiRTL2NvbmYvJHtMRFNDUklQVF9OQU1FfT0ke0xEU0NS SVBUX05BTUV9fQogU1lTVEVNX0RFUDo9ICR7U1lTVEVNX0RFUDokUy9jb25mLyR7TERTQ1JJUFRf TkFNRX09JHtMRFNDUklQVF9OQU1FfX0KZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLm1pcHMg Yi9zeXMvY29uZi9maWxlcy5taXBzCmluZGV4IDY0MzhjNDkuLmI1MDYyYWUgMTAwNjQ0Ci0tLSBh L3N5cy9jb25mL2ZpbGVzLm1pcHMKKysrIGIvc3lzL2NvbmYvZmlsZXMubWlwcwpAQCAtNzgsNiAr NzgsNyBAQCBsaWJrZXJuL2Zmc2wuYwkJCXN0YW5kYXJkCiBsaWJrZXJuL2Zscy5jCQkJc3RhbmRh cmQKIGxpYmtlcm4vZmxzbC5jCQkJc3RhbmRhcmQKIGxpYmtlcm4vbHNocmRpMy5jCQlzdGFuZGFy ZAorbGlia2Vybi9tZW1jaHIuYwkJb3B0aW9uYWwJZmR0CiBsaWJrZXJuL21lbW1vdmUuYwkJc3Rh bmRhcmQKIGxpYmtlcm4vbW9kZGkzLmMJCW9wdGlvbmFsCWlzYV9taXBzMzIKIGxpYmtlcm4vcWRp dnJlbS5jCQlvcHRpb25hbAlpc2FfbWlwczMyCkBAIC0xMDgsMyArMTA5LDEzIEBAIGRldi9od3Bt Yy9od3BtY19taXBzMjRrLmMJb3B0aW9uYWwgaHdwbWMKIAogZGV2L3J0L2lmX3J0LmMJCQlvcHRp b25hbCAJcnQKIGRldi9udnJhbTJlbnYvbnZyYW0yZW52LmMJb3B0aW9uYWwJbnZyYW0yZW52CisK K2Rldi9vZncvb3BlbmZpcm0uYwkJb3B0aW9uYWwJZmR0CitkZXYvb2Z3L29wZW5maXJtaW8uYwkJ b3B0aW9uYWwJZmR0CitkZXYvb2Z3L29md19idXNfaWYubQkJb3B0aW9uYWwJZmR0CitkZXYvb2Z3 L29md19pZi5tCQlvcHRpb25hbAlmZHQKK2Rldi9vZncvb2Z3X2J1c19zdWJyLmMJCW9wdGlvbmFs CWZkdAorZGV2L29mdy9vZndfZmR0LmMJCW9wdGlvbmFsCWZkdAorCitkZXYvZmR0L2ZkdF9taXBz LmMJCW9wdGlvbmFsCWZkdAorCmRpZmYgLS1naXQgYS9zeXMvZGV2L2ZkdC9mZHRfbWlwcy5jIGIv c3lzL2Rldi9mZHQvZmR0X21pcHMuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAw Li4wZTY4MjhlCi0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi9mZHQvZmR0X21pcHMuYwpAQCAt MCwwICsxLDU2IEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAwOS0yMDEwIFRoZSBGcmVlQlNE IEZvdW5kYXRpb24KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogVGhpcyBzb2Z0d2Fy ZSB3YXMgZGV2ZWxvcGVkIGJ5IFNlbWloYWxmIHVuZGVyIHNwb25zb3JzaGlwIGZyb20KKyAqIHRo ZSBGcmVlQlNEIEZvdW5kYXRpb24uCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24s IGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAq IGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25z IGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBw cm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQ Uk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICog QU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICog Rk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlks IE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9T UyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAq IEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJ TiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdM SUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9G CisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJ RCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMv c3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5o PgorI2luY2x1ZGUgPHN5cy9idXMuaD4KKworI2luY2x1ZGUgPG1hY2hpbmUvaW50cl9tYWNoZGVw Lmg+CisKKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29m d19idXNfc3Vici5oPgorI2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KKworI2luY2x1ZGUg Im9md19idXNfaWYuaCIKKyNpbmNsdWRlICJmZHRfY29tbW9uLmgiCisKK3N0cnVjdCBmZHRfZml4 dXBfZW50cnkgZmR0X2ZpeHVwX3RhYmxlW10gPSB7CisJeyBOVUxMLCBOVUxMIH0KK307CisKK2Zk dF9waWNfZGVjb2RlX3QgZmR0X3BpY190YWJsZVtdID0geworCU5VTEwsCisJTlVMTCwKKwlOVUxM Cit9OwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9mZHQvZmR0YnVzLmMgYi9zeXMvZGV2L2ZkdC9mZHRi dXMuYwppbmRleCA4NmE5ZDE3Li5lMjgwOGQxIDEwMDY0NAotLS0gYS9zeXMvZGV2L2ZkdC9mZHRi dXMuYworKysgYi9zeXMvZGV2L2ZkdC9mZHRidXMuYwpAQCAtNTkxLDYgKzU5MSw5IEBAIGZkdGJ1 c19zZXR1cF9pbnRyKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJj ZSAqcmVzLAogI2lmIGRlZmluZWQoX19wb3dlcnBjX18pCiAJZXJyID0gcG93ZXJwY19zZXR1cF9p bnRyKGRldmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpLAogCSAgICBybWFuX2dldF9zdGFydChyZXMp LCBmaWx0ZXIsIGloYW5kLCBhcmcsIGZsYWdzLCBjb29raWVwKTsKKyNlbGlmIGRlZmluZWQoX19t aXBzX18pCisJY3B1X2VzdGFibGlzaF9oYXJkaW50cihkZXZpY2VfZ2V0X25hbWV1bml0KGNoaWxk KSwgCisJCWZpbHRlciwgaWhhbmQsIGFyZywgcm1hbl9nZXRfc3RhcnQocmVzKSwgZmxhZ3MsIGNv b2tpZXApOwogI2VsaWYgZGVmaW5lZChfX2FybV9fKQogCWFybV9zZXR1cF9pcnFoYW5kbGVyKGRl dmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpLAogCSAgICBmaWx0ZXIsIGloYW5kLCBhcmcsIHJtYW5f Z2V0X3N0YXJ0KHJlcyksIGZsYWdzLCBjb29raWVwKTsKQEAgLTYyNSw2ICs2MjgsOCBAQCBmZHRi dXNfdGVhcmRvd25faW50cihkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBzdHJ1Y3QgcmVz b3VyY2UgKnJlcywKIAogI2lmIGRlZmluZWQoX19wb3dlcnBjX18pCiAJcmV0dXJuIChwb3dlcnBj X3RlYXJkb3duX2ludHIoY29va2llKSk7CisjZWxpZiBkZWZpbmVkKF9fbWlwc19fKQorCXJldHVy biAoMCk7CiAjZWxpZiBkZWZpbmVkKF9fYXJtX18pCiAJcmV0dXJuIChhcm1fcmVtb3ZlX2lycWhh bmRsZXIocm1hbl9nZXRfc3RhcnQocmVzKSwgY29va2llKSk7CiAjZW5kaWYKZGlmZiAtLWdpdCBh L3N5cy9taXBzL2luY2x1ZGUvZmR0LmggYi9zeXMvbWlwcy9pbmNsdWRlL2ZkdC5oCm5ldyBmaWxl IG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjQyNjZlZGYKLS0tIC9kZXYvbnVsbAorKysgYi9z eXMvbWlwcy9pbmNsdWRlL2ZkdC5oCkBAIC0wLDAgKzEsNTMgQEAKKy8qLQorICogQ29weXJpZ2h0 IChjKSAyMDEwIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQu CisgKgorICogVGhpcyBzb2Z0d2FyZSB3YXMgZGV2ZWxvcGVkIGJ5IFNlbWloYWxmIHVuZGVyIHNw b25zb3JzaGlwIGZyb20KKyAqIHRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCisgKgorICogUmVkaXN0 cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9s bG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Yg c291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNl LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgor ICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5k L29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgor ICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRP UlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQor ICogQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJ QlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFM LCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xV RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RT CisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lO RVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9S IFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg V0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQg T0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQK KyAqLworCisjaWZuZGVmIF9NQUNISU5FX0ZEVF9IXworI2RlZmluZSBfTUFDSElORV9GRFRfSF8K KworI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CisjaW5jbHVkZSA8bWFjaGluZS9pbnRyX21hY2hk ZXAuaD4KKworLyogTWF4IGludGVycnVwdCBudW1iZXIgKi8KKyNpZiBkZWZpbmVkKENQVV9STUkp IHx8IGRlZmluZWQoQ1BVX05MTSkKKyNkZWZpbmUgRkRUX0lOVFJfTUFYCVhMUl9NQVhfSU5UUgor I2Vsc2UKKyNkZWZpbmUgRkRUX0lOVFJfTUFYCShOSEFSRF9JUlFTICsgTlNPRlRfSVJRUykKKyNl bmRpZgorCisvKiBNYXAgcGhhbmRsZS9pbnRwaW4gcGFpciB0byBnbG9iYWwgSVJRIG51bWJlciAq LyAKKyNkZWZpbmUJRkRUX01BUF9JUlEobm9kZSwgcGluKQkocGluKQorCisvKgorICogQnVzIHNw YWNlIHRhZy4gWFhYIGVuZGlhbmVzcyBpbmZvIG5lZWRzIHRvIGJlIGRlcml2ZWQgZnJvbSB0aGUg YmxvYi4KKyAqLworI2RlZmluZSBmZHRidXNfYnNfdGFnCU5VTEwKKworI2VuZGlmIC8qIF9NQUNI SU5FX0ZEVF9IXyAqLwpkaWZmIC0tZ2l0IGEvc3lzL21pcHMvaW5jbHVkZS9pbnRyX21hY2hkZXAu aCBiL3N5cy9taXBzL2luY2x1ZGUvaW50cl9tYWNoZGVwLmgKaW5kZXggZjIyNDUxNy4uNzUxOTBm NSAxMDA2NDQKLS0tIGEvc3lzL21pcHMvaW5jbHVkZS9pbnRyX21hY2hkZXAuaAorKysgYi9zeXMv bWlwcy9pbmNsdWRlL2ludHJfbWFjaGRlcC5oCkBAIC0yOSw2ICsyOSw4IEBACiAjaWZuZGVmCV9N QUNISU5FX0lOVFJfTUFDSERFUF9IXwogI2RlZmluZQlfTUFDSElORV9JTlRSX01BQ0hERVBfSF8K IAorI2luY2x1ZGUgPG1hY2hpbmUvYXRvbWljLmg+CisKICNpZiBkZWZpbmVkKENQVV9STUkpIHx8 IGRlZmluZWQoQ1BVX05MTSkKICNkZWZpbmUgWExSX01BWF9JTlRSIDY0IAogI2Vsc2UKZGlmZiAt LWdpdCBhL3N5cy9taXBzL2luY2x1ZGUvb2Z3X21hY2hkZXAuaCBiL3N5cy9taXBzL2luY2x1ZGUv b2Z3X21hY2hkZXAuaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi4zNWFmY2Ux Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL21pcHMvaW5jbHVkZS9vZndfbWFjaGRlcC5oCkBAIC0w LDAgKzEsNDggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDAxIGJ5IFRob21hcyBNb2VzdGwg PHRtbUBGcmVlQlNELm9yZz4uCisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlz dHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0 aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZv bGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9m IHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGlj ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4K KyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUg YWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFu ZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFu ZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoK KyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBgYEFTIElTJycgQU5E IEFOWSBFWFBSRVNTIE9SCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5P VCBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTCisgKiBPRiBNRVJDSEFOVEFCSUxJ VFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgor ICogSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxF IEZPUiBBTlkgRElSRUNULAorICogSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1Q TEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTCisgKiAoSU5DTFVESU5HLCBCVVQgTk9UIExJ TUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IKKyAqIFNFUlZJQ0VT OyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9O KSBIT1dFVkVSCisgKiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVU SEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLAorICogT1IgVE9SVCAoSU5DTFVESU5H IE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRQor ICogVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJ VFkgT0YgU1VDSCBEQU1BR0UuCisgKgorICogJEZyZWVCU0QkCisgKi8KKworI2lmbmRlZiBfTUFD SElORV9PRldfTUFDSERFUF9IXworI2RlZmluZSBfTUFDSElORV9PRldfTUFDSERFUF9IXworCisj aW5jbHVkZSA8c3lzL2NkZWZzLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8 c3lzL3JtYW4uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vcGVu ZmlybS5oPgorCit0eXBlZGVmCXVpbnQzMl90CWNlbGxfdDsKK3N0cnVjdCBtZW1fcmVnaW9uIHsK Kwl2bV9vZmZzZXRfdAltcl9zdGFydDsKKwl2bV9zaXplX3QJbXJfc2l6ZTsKK307CisKKworaW50 ICBPRl9kZWNvZGVfYWRkcihwaGFuZGxlX3QsIGludCwgYnVzX3NwYWNlX3RhZ190ICosIGJ1c19z cGFjZV9oYW5kbGVfdCAqKTsKK3ZvaWQgT0ZfZ2V0ZXRoZXJhZGRyKGRldmljZV90IGRldiwgdV9j aGFyICphZGRyKTsKK3ZvaWQgT0ZfaW5pdGlhbF9zZXR1cCh2b2lkICpmZHRfcHRyLCB2b2lkICpq dW5rLCBpbnQgKCpvcGVuZmlybSkodm9pZCAqKSk7CisKKyNlbmRpZiAvKiBfTUFDSElORV9PRldf TUFDSERFUF9IXyAqLwo= --0016e6d7e1007ea39a04af7f1d1b-- From owner-freebsd-mips@FreeBSD.ORG Mon Oct 17 14:18:27 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4787A106564A; Mon, 17 Oct 2011 14:18:27 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 201928FC17; Mon, 17 Oct 2011 14:18:25 +0000 (UTC) Received: by wyi40 with SMTP id 40so2267325wyi.13 for ; Mon, 17 Oct 2011 07:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8qN2lpt9iWtp9j+aYZhSH3tVFl8vrUKoQhaiZGzEtBY=; b=fyluG5Qpu+gV+uGTeEnId03tz+Gh6TsZS3KHOAaVVdgmILYmoNfKeqIERsDIniso+i vA2gDUD4Jx71F4lU96RTNImVdTvxL1+qbBVCnMrhp4AQQjhZCBOaYDK+VtN6seF++y3s nJwJ+ihuHXA0ZzTKEl2XAJdyNWekoh6YES4ho= MIME-Version: 1.0 Received: by 10.216.139.224 with SMTP id c74mr5012543wej.11.1318861105177; Mon, 17 Oct 2011 07:18:25 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Mon, 17 Oct 2011 07:18:24 -0700 (PDT) In-Reply-To: References: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> Date: Mon, 17 Oct 2011 19:48:24 +0530 X-Google-Sender-Auth: P0xvS8iYLndFzSRqnadewQOMprI Message-ID: From: "Jayachandran C." To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: svn commit: r225892 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:18:27 -0000 On Thu, Oct 13, 2011 at 9:28 PM, Jayachandran C. wro= te: > Hi Adrian, > > On Tue, Oct 4, 2011 at 9:48 PM, Adrian Chadd wrote: >> On 4 October 2011 23:48, Adrian Chadd wrote: >>> Hi all, >>> >>> I've tried jc's patch. The hand-wavy, brief summary when tested on my >>> hostap (mips): >>> >>> * when doing single-stream, one way TCP tests (where it thus needs >>> TX/RX traffic to occur), I get 100% CPU utilisation - 50% interrupt, >>> 50% system, but the total interrupt rate isn't too high. It's much >>> higher than without his patch. I'll go digging later to see what's >>> going on. >> >> This turns out to be my fault. I seem to have somehow messed up >> something in one of my more recent commits. >> I'm quite certain that it won't have any impact on the results, as I >> never see the interrupt latency issue with bidirectional traffic. >> >> The UDP results are correct though - jc's stuff hasn't entirely fixed >> it. I'll do some more testing tomorrow morning and report what I find. > > I'm thinking of checking in this patch so that it gets wider testing. > Did you get a chance to do the tests? > > The patch does not cause any further problems =A0for me on XLR/XLP - I > have been testing it for a few days. =A0But I don't really have a > testcase for the issue you see. If there are no objections, I'm planning to check this in. I can keep the two if(!busy) blocks in cpu_idle() commented if you prefer, and that should give the same behavior as you are seeing now. JC. From owner-freebsd-mips@FreeBSD.ORG Mon Oct 17 14:56:52 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172DD10656D0; Mon, 17 Oct 2011 14:56:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8485E8FC0C; Mon, 17 Oct 2011 14:56:51 +0000 (UTC) Received: by ywm3 with SMTP id 3so1754355ywm.13 for ; Mon, 17 Oct 2011 07:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YNzO99xDiOkTmM7XjTG9mfJmmWah4tEsmrh4jtvR5MU=; b=BkzIEE4zlzNG0tCMn7/5Wyo8QmucsXujjxjTgC5gRPmQG18RdCRGBmk7XbVzm43lWt 8QAsn7qMID6HE90R2u2vxJn+DukqCWckLZEG9WxdPph5HmfwZBNwPbbiCm5QtZlReDYm 9oQe/b4Nd5WNz82PBkdSC0x5J4aq3SiCaA7o0= MIME-Version: 1.0 Received: by 10.236.178.41 with SMTP id e29mr26540757yhm.117.1318863411024; Mon, 17 Oct 2011 07:56:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Mon, 17 Oct 2011 07:56:50 -0700 (PDT) In-Reply-To: References: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> Date: Mon, 17 Oct 2011 22:56:50 +0800 X-Google-Sender-Auth: EViK8lxD2i2emzgZCS1Ws88U4ks Message-ID: From: Adrian Chadd To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: svn commit: r225892 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:56:52 -0000 On 17 October 2011 22:18, Jayachandran C. wrote: >> The patch does not cause any further problems =A0for me on XLR/XLP - I >> have been testing it for a few days. =A0But I don't really have a >> testcase for the issue you see. > > If there are no objections, I'm planning to check this in. > > =A0I can keep the two if(!busy) blocks in cpu_idle() commented if you > prefer, and that should give the same behavior as you are seeing now. I'm happy for you to check it in. I'll do some further testing in my branch and see if I can figure out why it isn't working for me. I've also found the relevant bits in the mips24k programming pdfs which talk about the Config7 bit which indiciates whether wait will break if a mask interrupt is asserted or not. That may be good to include at a later date. (But my SoCs don't have that feature, so we still need this WAR.) Adrian From owner-freebsd-mips@FreeBSD.ORG Wed Oct 19 00:06:28 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A69D21065677 for ; Wed, 19 Oct 2011 00:06:28 +0000 (UTC) (envelope-from root@ns6.wowcardeals.com) Received: from ns6.wowcardeals.com (ns6.wowcardeals.com [217.23.9.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD5A8FC0A for ; Wed, 19 Oct 2011 00:06:28 +0000 (UTC) Received: by ns6.wowcardeals.com (Postfix, from userid 0) id E144290A177; Wed, 19 Oct 2011 03:26:19 +0400 (MSD) To: freebsd-mips@freebsd.org From: 'Drive a New BMW for R4999 P/M' Content-Disposition: inline Message-Id: <20111018232619.E144290A177@ns6.wowcardeals.com> Date: Wed, 19 Oct 2011 03:26:19 +0400 (MSD) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Drive A New BMW for R4999 P/M X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 00:06:28 -0000 wowbmw.com Drive a new BMW from R4999 per month! Can't see the pictures? [1]Click here to view this email online. Save up to R1 411.54 per month [2]BMW E90 320i BMW E90 320i Petrol (Manual) * From R4 999.00 per month. * Manual * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [3]YES / [4]NO Save up to R1 463.76 per month [5]BMW E90 Auto BMW E90 320i Petrol (Automatic) * From R5 299.00 per month. * Automatic * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [6]YES / [7]NO Subject to availability of stock. Extra's not factory fitted will be charged Terms and conditions and cost of credit General terms and conditions and cost of credit Duration of contract 72 months. Once off initiation fee of R1140.00 VAT inclusive, already included in contract. Monthly service fee of R57.00 VAT inclusive. Rate at prime +2% variable. All delivery, lic, registration and number plates included in cost of credit. No residual value or deposit. Cost of credit and repayments may vary due to your credit risk profile. Application subject (at all times) to approval from our credit providers partners. Pre quote and pre contract available at all times. Terms and conditions and cost of credit available or request of contract in all official languages To qualify, the applicant must comply with the following basic conditions: * Earn a minimum salary of R5 500.00 nett (take home); * Not listed on the ITC; * Have a SA Driver's license and ID; * The rest of our terms and conditions are set out in the example [8]Advertising Contract. Advertising initiative cost of credit: * BMW E90 320i Petrol (Manual) = R359 928.00 * BMW E90 320i Petrol (Automatic) = R381 528.00 Please note that your repayment and cost of credit may vary as per terms and conditions of the advertising agreement. Advertised payment reduction is governed by a advertising program. Re-payments exclude monthly services charged and include initiation fee as allowed by the NCR. To view an example of an advertising contract please [9]click here. Example adverts on the back of the vehicles: Branding Branding Cost of credit and repayment if you opt not to enter into the advertising initiative: * BMW E90 320i Petrol (Manual) = R465 662.88 Repayment = R6 467.54 per month * BMW E90 320i Petrol (Automatic) = R491 022.72 Repayment = R6 819.76 per month Repayments and cost of credit includes initiation and monthly service fees as prescribed by the [10]NCR. To stop receiving emails, please [11]UNSUBSCRIBE here References 1. http://www.wowbmw.com/mailer/002/agent.php?page=online&agent=002&campaign=bmw&vehicle=1 2. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 3. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 4. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=25 5. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 6. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 7. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=26 8. http://www.wowbmw.com/contract.pdf 9. http://www.wowbmw.com/contract.pdf 10. http://www.ncr.org.za/ 11. http://www.wowbmw.com/site/decline.php From owner-freebsd-mips@FreeBSD.ORG Thu Oct 20 20:59:04 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B451065740 for ; Thu, 20 Oct 2011 20:59:04 +0000 (UTC) (envelope-from www@s113.loopia.se) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by mx1.freebsd.org (Postfix) with ESMTP id 41BF48FC17 for ; Thu, 20 Oct 2011 20:59:04 +0000 (UTC) Received: from s101.loopia.se (s101.loopia.se [194.9.95.47]) by s87.loopia.se (Postfix) with SMTP id 597264653C2 for ; Thu, 20 Oct 2011 22:40:33 +0200 (CEST) Received: (qmail 37657 invoked from network); 20 Oct 2011 20:40:22 -0000 Received: from s113.loopia.se (HELO s113.loopia.se) (194.9.94.207) by s101.loopia.se (qpsmtpd/0.31.1) with ESMTP; Thu, 20 Oct 2011 22:40:22 +0200 Received: from s113.loopia.se (localhost [127.0.0.1]) by s113.loopia.se (8.14.4/8.14.4) with ESMTP id p9KKePnM007994 for ; Thu, 20 Oct 2011 22:40:25 +0200 (CEST) (envelope-from www@s113.loopia.se) Received: (from www@localhost) by s113.loopia.se (8.14.4/8.14.4/Submit) id p9KKePf7007993; Thu, 20 Oct 2011 22:40:25 +0200 (CEST) (envelope-from www) Date: Thu, 20 Oct 2011 22:40:25 +0200 (CEST) Message-Id: <201110202040.p9KKePf7007993@s113.loopia.se> To: freebsd-mips@freebsd.org From: Security Center Paypal MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Security Center Paypal X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:59:04 -0000 [1]PayPal [pixel.gif] Information Regarding Your account: Dear PayPal Member: Attention! Your PayPal account has been limited! As part of our security measures, we regularly screen activity in the PayPal system.We recently contacted you after noticing an issue on your account.We requested information from you for the following reason: Our system detected unusual charges to a credit card linked to your PayPal account. Reference Number: PP-259-187-991 This is the Last reminder to log in to PayPal as soon as possible. Once you log in, you will be provided with steps to restore your account access. Once you log in, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety. [2]Click here to activate your account We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologise for any inconvenience.. Sincerely, PayPal Account Review Department _________________________________________________________________ Copyright © 1999-2011 PayPal. All rights reserved. PayPal Ltd. PayPal FSA Register Number: 226056. [pixel.gif] PayPal Email ID PP059 Protect Your Account Info Make sure you never provide your password to fraudulent websites. To safely and securely access the PayPal website or your account, open a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal login page (http://paypal.com/) to be sure you are on the real PayPal site. For more information on protecting yourself from fraud, please review our Security Tips at https://www.paypal.com/us/securitytips Protect Your Password You should never give your PayPal password to anyone. References 1. https://www.paypal.com/us 2. http://paypalupdate.com.security.online.unlimited.conceptec.net/paypal.com/ From owner-freebsd-mips@FreeBSD.ORG Fri Oct 21 07:09:24 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC5F61065670 for ; Fri, 21 Oct 2011 07:09:24 +0000 (UTC) (envelope-from mipsjunkie@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 706108FC12 for ; Fri, 21 Oct 2011 07:09:24 +0000 (UTC) Received: by ywm3 with SMTP id 3so4610521ywm.13 for ; Fri, 21 Oct 2011 00:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FQt17EHCiIrSi/2077O7uBBO2lkvAPaiiT/Qy5TW7p8=; b=oDiioYFJybdVbRgiPZ6LDS4ZSCtyjAaKh/IOmAOIF6bGWSZNM/6WNAO+KvwSEuFr8w wAQDrwB5BFp+1fKkUGNV6cN2VqiSS9c5foMFoKd229Ko+UH52T8qFV19r+szYFkj/jBI ZbEij2AsSY+1l2KSZ9SDgtaDinI4G7ImtqWdg= MIME-Version: 1.0 Received: by 10.68.38.41 with SMTP id d9mr6079704pbk.103.1319179098248; Thu, 20 Oct 2011 23:38:18 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Thu, 20 Oct 2011 23:38:18 -0700 (PDT) Date: Fri, 21 Oct 2011 12:08:18 +0530 Message-ID: From: Rohit J To: freebsd-mips Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Assembler complains about use of $at after ".set noat" on sd instr X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:09:24 -0000 Hi FreeBSD MIPS Gurus, Am just starting on MIPS assembly in FreeBSD. The code that I have was building just fine. Then I added an line to a .S file @line# 513 sd k0, mpl(sp) which on make gives an error that says : Assembler messages: octeon_asm.S:440: Error: illegal operands `ld T3,8($7)' octeon_asm.S:513: Error: Macro used $at after ".set noat" The .S file has a noat directive .set noat Silly Questions 1. Why does sd instruction (store double word) end up using at ? I checked the particular manual (Cavium Octeon H/w reference Manual) and didn=92t find anything about sd instr using register at. 2. Why does it complain about ld instr so far up in the file away from the place new code was inserted? Any pointers appreciated Rohit From owner-freebsd-mips@FreeBSD.ORG Fri Oct 21 07:13:41 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E6AC106566B for ; Fri, 21 Oct 2011 07:13:41 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9448FC16 for ; Fri, 21 Oct 2011 07:13:40 +0000 (UTC) Received: by wyi40 with SMTP id 40so4699861wyi.13 for ; Fri, 21 Oct 2011 00:13:40 -0700 (PDT) Received: by 10.227.179.76 with SMTP id bp12mr2475424wbb.82.1319181220177; Fri, 21 Oct 2011 00:13:40 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Fri, 21 Oct 2011 00:13:20 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Fri, 21 Oct 2011 00:13:20 -0700 X-Google-Sender-Auth: i20Tm7kv4LHYy0tEYupy2PcZad4 Message-ID: To: Rohit J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips Subject: Re: Assembler complains about use of $at after ".set noat" on sd instr X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:13:41 -0000 On Thu, Oct 20, 2011 at 23:38, Rohit J wrote: > Hi FreeBSD MIPS Gurus, > > Am just starting on MIPS assembly in FreeBSD. > > The code that I have was building just fine. > Then I added an line to a .S file @line# 513 > > =C2=A0 =C2=A0 sd =C2=A0k0, mpl(sp) > > which on make gives an error that says : > > =C2=A0Assembler messages: > octeon_asm.S:440: Error: illegal operands `ld T3,8($7)' > octeon_asm.S:513: Error: Macro used $at after ".set noat" > > The .S file has a noat directive > =C2=A0.set noat > > Silly Questions > 1. =C2=A0 =C2=A0 =C2=A0Why does sd instruction (store double word) end up= using at ? > I checked the particular manual (Cavium Octeon H/w reference Manual) > and didn=E2=80=99t find anything about sd instr using register at. Probably you are using a symbol/macro that is not locally defined, and so assembler assumes it's an external data reference, and tries to turn sd into a series of instructions using the assembler temporary to load a linker-resolved address into a register to be used in the sd instruction. Try running just the C preprocessor and looking at the resulting assembly to see what's not being resolved properly. > 2. =C2=A0 =C2=A0 =C2=A0Why does it complain about ld instr so far up in t= he file away from > the place > new code was inserted? Can you send the source inline? I suspect you're missing an include or something. Did you change that line? Are you compiling it as it's built on stock FreeBSD, or are you, say, copying the file from the kernel and then trying to build it in userland? From owner-freebsd-mips@FreeBSD.ORG Fri Oct 21 07:38:07 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F08106566C for ; Fri, 21 Oct 2011 07:38:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DEAF8FC18 for ; Fri, 21 Oct 2011 07:38:07 +0000 (UTC) Received: by ywm3 with SMTP id 3so4635761ywm.13 for ; Fri, 21 Oct 2011 00:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=I+dSb8jME6iAkK3nJucqC/rWMa9RVYm0/yuCvaqU/Ds=; b=mrISYkElQpFsobewISbjKEF4I8OiYJOFHLrYCcRgYJrrLjbKT9Ie6IOrbnaAUxZ7i/ 3riCoAejiHZT1EZ3hPRqQ8UXLwFjxlNsV+mXuVbxV53fIDWLazk820pJ2ZnNzheunYVq sx6wCXGEaGphGOFjEEdKCkaIJkfBzfwjZitTg= MIME-Version: 1.0 Received: by 10.236.133.241 with SMTP id q77mr17006852yhi.117.1319182686678; Fri, 21 Oct 2011 00:38:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.109.39 with HTTP; Fri, 21 Oct 2011 00:38:06 -0700 (PDT) Date: Fri, 21 Oct 2011 15:38:06 +0800 X-Google-Sender-Auth: Iy-1Z1xLY63JfLkWHZ14H6mx7Gg Message-ID: From: Adrian Chadd To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: mips4k support? X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:38:07 -0000 Hi guys/girls, The Atheros AR2313 is an old SOC which is mips4k based. There's been a few requests to support this (and I've recently acquired a board with this in it) so I'd like to see how feasible it'd be to get going. So what's the state of mips4k support in the tree? I can port over the chipset specific stuff (bus, peripherals, machdep init code, etc) without too much trouble. I'm just still not up to scratch on the CPU side of things. (This is all conjecture and won't occur until after I solve the mips24k platform issues btw. It's just a fishing expedition for more information. :) Thanks, Adrian From owner-freebsd-mips@FreeBSD.ORG Fri Oct 21 21:56:03 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D646106566C; Fri, 21 Oct 2011 21:56:03 +0000 (UTC) (envelope-from mipsjunkie@gmail.com) Received: from mail-pz0-f68.google.com (mail-pz0-f68.google.com [209.85.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id D133B8FC17; Fri, 21 Oct 2011 21:56:02 +0000 (UTC) Received: by pzk33 with SMTP id 33so2903933pzk.7 for ; Fri, 21 Oct 2011 14:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SOnr0odqy2Nxvbzawll4p6f2KxIbZ2yxEWrEsKli69c=; b=sdDl6XWnfADUHlGX9J878AVYQyUDogCaS22Xq087brCfeblF2Qo3cMV3yWb1vEE1yw ZXFT9VHqwfM/vZDpph4EYdN6NqTGZJ40EBuVF8fNpKBJlhKETJK0wjOcgZtaXASGypRb pwnNcWWbeEJTLxhucFk1HY2CCS4OMPvhsGUmU= MIME-Version: 1.0 Received: by 10.68.28.200 with SMTP id d8mr31190147pbh.35.1319234162623; Fri, 21 Oct 2011 14:56:02 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Fri, 21 Oct 2011 14:56:02 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Oct 2011 03:26:02 +0530 Message-ID: From: Rohit J To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips Subject: Re: Assembler complains about use of $at after ".set noat" on sd instr X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 21:56:03 -0000 >> 2. Why does it complain about ld instr so far up in the file away f= rom >> the place new code was inserted? Hi Juli, thanks for taking time to respond and so quickly and nicely. the "ld" error happened because I fat fingered the operand in vi! ;-p (yes i need to smack myself on the head!!) >> octeon_asm.S:440: Error: illegal operands `ld T3,8($7)' which should have referenced the "t3" register (in small case) >> octeon_asm.S:440: Error: illegal operands `ld t3,8($7)' the big picture story is that as a partial fix to using octeon specific very large mult instructions in our freebsd kernel (for crypto related ops), we had initially disabled interrupts=3D>context switches during these large mult ops as the code wasnt saving the mult related registers/info and if it were to context switch in the middle of these multiplication rout= ines, bad things happened. Need to see if there is a better way to do it. am now trying to see if it makes sense to save those registers and remove the disable interrupt constraint for running these large multiplicat= ion instructions. will be adapting the (multiplication context save/restore) in the octeon HRM and will revert if i have any further questions. thanks a ton rohit ps:got all excited to see that some of the files I am working on now have you as the original author/contributor! On Fri, Oct 21, 2011 at 12:43 PM, Juli Mallett wrote= : > On Thu, Oct 20, 2011 at 23:38, Rohit J wrote: >> Hi FreeBSD MIPS Gurus, >> >> Am just starting on MIPS assembly in FreeBSD. >> >> The code that I have was building just fine. >> Then I added an line to a .S file @line# 513 >> >> =A0 =A0 sd =A0k0, mpl(sp) >> >> which on make gives an error that says : >> >> =A0Assembler messages: >> octeon_asm.S:440: Error: illegal operands `ld T3,8($7)' >> octeon_asm.S:513: Error: Macro used $at after ".set noat" >> >> The .S file has a noat directive >> =A0.set noat >> >> Silly Questions >> 1. =A0 =A0 =A0Why does sd instruction (store double word) end up using a= t ? >> I checked the particular manual (Cavium Octeon H/w reference Manual) >> and didn=92t find anything about sd instr using register at. > > Probably you are using a symbol/macro that is not locally defined, and > so assembler assumes it's an external data reference, and tries to > turn sd into a series of instructions using the assembler temporary to > load a linker-resolved address into a register to be used in the sd > instruction. =A0Try running just the C preprocessor and looking at the > resulting assembly to see what's not being resolved properly. > >> 2. =A0 =A0 =A0Why does it complain about ld instr so far up in the file = away from >> the place >> new code was inserted? > > Can you send the source inline? =A0I suspect you're missing an include > or something. =A0Did you change that line? =A0Are you compiling it as it'= s > built on stock FreeBSD, or are you, say, copying the file from the > kernel and then trying to build it in userland? > From owner-freebsd-mips@FreeBSD.ORG Fri Oct 21 22:27:50 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F086106564A for ; Fri, 21 Oct 2011 22:27:50 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2948FC14 for ; Fri, 21 Oct 2011 22:27:49 +0000 (UTC) Received: by wyi40 with SMTP id 40so5789516wyi.13 for ; Fri, 21 Oct 2011 15:27:48 -0700 (PDT) Received: by 10.227.6.223 with SMTP id a31mr5992502wba.112.1319236068170; Fri, 21 Oct 2011 15:27:48 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Fri, 21 Oct 2011 15:27:28 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Fri, 21 Oct 2011 15:27:28 -0700 X-Google-Sender-Auth: Ui4lgEDJgJZpYJIZMcNmkO6BARM Message-ID: To: Rohit J Content-Type: text/plain; charset=UTF-8 Cc: Oleksandr Tymoshenko , freebsd-mips Subject: Re: Assembler complains about use of $at after ".set noat" on sd instr X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 22:27:50 -0000 On Fri, Oct 21, 2011 at 14:56, Rohit J wrote: > the big picture story is that > as a partial fix to using octeon specific very large mult instructions > in our freebsd kernel > (for crypto related ops), we had initially disabled > interrupts=>context switches Assuming you're using the stuff in-tree, that's my fault :) > Need to see if there is a better way to do it. > am now trying to see if it makes sense to save those registers and > remove the disable interrupt constraint for running these large multiplication > instructions. > will be adapting the (multiplication context save/restore) > in the octeon HRM and will revert if i have any further questions. gonzo@ has incomplete patches, you may want to ask him. Alternately, look at how FPU context is lazily switched on other architectures. In short (but not very short), you disable coprocessor 2 access and enable it only on trap for userland processes. And if there was already a thread using cop2, then you save the state to its PCB and reinitialize cop2 (this is important so you don't leak cryptographic state to the next thread.) And in the kernel when you use cop2, if your thread was already using cop2 then you store cop2 state to the stack as part of the save/restore blocks around the routines that currently just use critical sections. Then you do your work, and context switches that happen are handled as normal (the kernel state will be saved to the PCB.) And then when you switch back, your kernel routines keep operating. And then on return you restore the state if there was any, and clear it out otherwise, from the stack. Depending on your application, you may want to use some other synchronization mechanisms (like mutexes) to limit concurrent kernel access to cop2, so you don't end up switching cop2 state back and forth constantly for two threads that are trying to run, when it would be much faster for one thread to simply block. Hope that helps. And do ask Oleskandr for his patches, if he still has them. Note that whatever you end up with, do look at ways to add a little bit of (compile-time) abstraction so that we can handle other variant coprocessors on other ISAs. Shouldn't be too hard, and the next person can always make the modularization better, but it should help structure and guide the implementation a little to keep that in mind. Thanks, Juli.