From owner-freebsd-mips@FreeBSD.ORG Sun Mar 9 07:39:23 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC8B630C; Sun, 9 Mar 2014 07:39:23 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F1C9DF1; Sun, 9 Mar 2014 07:39:22 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Sun, 09 Mar 2014 08:39:25 +0100 id 004FC9E1.531C1AAD.00005849 Date: Sun, 9 Mar 2014 08:39:19 +0100 From: Milan Obuch To: Adrian Chadd Subject: Re: I (think) the AR8327 switch support now works Message-ID: <20140309083919.2810fa97@zeta.dino.sk> In-Reply-To: References: <20140301143607.13a96bd6@zeta.dino.sk> <20140301200546.7ff373d1@zeta.dino.sk> <20140301231239.023b8733@zeta.dino.sk> <20140307140432.0a460da1@zeta.dino.sk> <20140307204230.3c86b9b1@zeta.dino.sk> <20140308140901.19782009@zeta.dino.sk> <20140308173642.0a48d2c2@zeta.dino.sk> <20140308234129.76800b5c@zeta.dino.sk> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i386-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mailhost.netlab.sk-22601-1394350765-0001-2" Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 07:39:23 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_mailhost.netlab.sk-22601-1394350765-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 8 Mar 2014 14:50:14 -0800 Adrian Chadd wrote: > Ok, well now let's figure out if the reset is working or not. > > look at arswitch_attach(): > > * It sets up the default methods; > * it calls ar8327_attach(); > * it resets the switch via arswitch_reset(); > * it calls the HAL methods to set things up; > * it attaches the PHYs; > * it attaches said PHYs; > * it starts the periodic checks via arswitch_tick(). > > So, I'd add some printf()s in arswitch_attach() to see where it's > getting to before it calls return (ENXIO) or return (err). > > > -a > OK, so I patched said function with some printf's (in attachment), built new kernel and got following result: mdio0: on argemdio0 mdioproxy0: on mdio0 arswitch0: readreg 0x00000000: 0x12041204 arswitch0: readreg 0x00000000: 0x00000000 arswitch0: on mdio0 arswitch0: arswitch_attach 1 device_attach: arswitch0 attach returned 6 Now I put there some more printf's (in arswitch_probe) and things go a bit stranger. I've got: mdio0: on argemdio0 mdioproxy0: on mdio0 unknown: arswitch_probe 1 arswitch0: readreg 0x00000000: 0x00000000 unknown: arswitch_probe 2 0 and for the second time, just doing one more reboot: mdio0: on argemdio0 mdioproxy0: on mdio0 unknown: arswitch_probe 1 arswitch0: readreg 0x00000000: 0x12041204 unknown: arswitch_probe 2 6 unknown: arswitch_probe 1 arswitch0: readreg 0x00000000: 0x00000000 unknown: arswitch_probe 2 0 arswitch0: on mdio0 arswitch0: arswitch_attach 1 0 device_attach: arswitch0 attach returned 6 Next reboot brings again the first result, next one the second, again the second, again the first one etc. It looks like two two possibilities are alternating with some level of randomness. To me this tells that mdio does not work reliably in this case - am I right thinking that reading register 0 should always return the same value, 0x12041204, at least when no other register is touched in between? Well, this was with soft reset - I got every time mountroot promp, so just pressing enter gives me panic and then I typed reboot. when doing power-cycle, things are a bit deterministic - three time in a row I got the first result. Next question - why is arswitch_probe function called second time? It is called twice for both switches, so it is probably by design, and as the second switch is only 'hint probed', it does not matter. But for 8327, register is read, unfortunatelly not the same result is given both times. Also, I played with if_arge.c - arge_fetch_mdiobus_clock_rate() function a bit, but no matter the clock divider I used, the results are still the same. I see in next function, arge_reset_miibus a comment about resetting the mdio block(s), so I suspect it is something to be done, maybe, but is not yet. I have no idea how to try it, however. I can just wait for next hint, now. Regards, Milan --=_mailhost.netlab.sk-22601-1394350765-0001-2 Content-Type: application/octet-stream; name="arswitch.c-diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=arswitch.c-diff SW5kZXg6IC9kYXRhL3NyYy8xMS9zeXMvZGV2L2V0aGVyc3dpdGNoL2Fyc3dpdGNoL2Fyc3dpdGNo LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gL2RhdGEvc3JjLzExL3N5cy9kZXYvZXRoZXJzd2l0Y2gvYXJzd2l0 Y2gvYXJzd2l0Y2guYwkocmV2aXNpb24gMjYyOTI5KQorKysgL2RhdGEvc3JjLzExL3N5cy9kZXYv ZXRoZXJzd2l0Y2gvYXJzd2l0Y2gvYXJzd2l0Y2guYwkod29ya2luZyBjb3B5KQpAQCAtMTM1LDYg KzEzNSw3IEBACiAJCXNjLT5zY19zd2l0Y2h0eXBlID0gQVI4WDE2X1NXSVRDSF9BUjgzMTY7CiAJ CWJyZWFrOwogCWNhc2UgMHgxMjAyOgorCWNhc2UgMHgxMjA0OgogCQljaGlwbmFtZSA9ICJBUjgz MjciOwogCQlzYy0+c2Nfc3dpdGNodHlwZSA9IEFSOFgxNl9TV0lUQ0hfQVI4MzI3OwogCQlzYy0+ bWlpX2xvX2ZpcnN0ID0gMTsKQEAgLTMwNCw2ICszMDUsOCBAQAogCXNjLT5oYWwuYXJzd2l0Y2hf dmxhbl9zZXRfcHZpZCA9IGFyOHh4eF9zZXRfcHZpZDsKIAlzYy0+aGFsLmFyc3dpdGNoX2F0dV9m bHVzaCA9IGFyOHh4eF9hdHVfZmx1c2g7CiAKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJh cnN3aXRjaF9hdHRhY2ggMVxuIik7CisKIAkvKgogCSAqIEF0dGFjaCBzd2l0Y2ggcmVsYXRlZCBm dW5jdGlvbnMKIAkgKi8KQEAgLTMyMiw2ICszMjUsOCBAQAogCWVsc2UKIAkJcmV0dXJuIChFTlhJ Tyk7CiAKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJhcnN3aXRjaF9hdHRhY2ggMlxuIik7 CisKIAkvKiBDb21tb24gZGVmYXVsdHMuICovCiAJc2MtPmluZm8uZXNfbnBvcnRzID0gNTsgLyog WFhYIHRlY2huaWNhbGx5IDYsIGJ1dCA2dGggbm90IHVzZWQgKi8KIApAQCAtMzUwLDE5ICszNTUs MjcgQEAKIAlpZiAoYXJzd2l0Y2hfcmVzZXQoZGV2KSkKIAkJcmV0dXJuIChFTlhJTyk7CiAKKwlk ZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJhcnN3aXRjaF9hdHRhY2ggM1xuIik7CisKIAllcnIg PSBzYy0+aGFsLmFyc3dpdGNoX2h3X3NldHVwKHNjKTsKIAlpZiAoZXJyICE9IDApCiAJCXJldHVy biAoZXJyKTsKIAorCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwgImFyc3dpdGNoX2F0dGFjaCA0 XG4iKTsKKwogCWVyciA9IHNjLT5oYWwuYXJzd2l0Y2hfaHdfZ2xvYmFsX3NldHVwKHNjKTsKIAlp ZiAoZXJyICE9IDApCiAJCXJldHVybiAoZXJyKTsKIAorCWRldmljZV9wcmludGYoc2MtPnNjX2Rl diwgImFyc3dpdGNoX2F0dGFjaCA1XG4iKTsKKwogCS8qIEluaXRpYWxpemUgdGhlIHN3aXRjaCBw b3J0cy4gKi8KIAlmb3IgKHBvcnQgPSAwOyBwb3J0IDw9IHNjLT5udW1waHlzOyBwb3J0KyspIHsK IAkJc2MtPmhhbC5hcnN3aXRjaF9wb3J0X2luaXQoc2MsIHBvcnQpOwogCX0KIAorCWRldmljZV9w cmludGYoc2MtPnNjX2RldiwgImFyc3dpdGNoX2F0dGFjaCA2XG4iKTsKKwogCS8qCiAJICogQXR0 YWNoIHRoZSBQSFlzIGFuZCBjb21wbGV0ZSB0aGUgYnVzIGVudW1lcmF0aW9uLgogCSAqLwpAQCAt MzcwLDIzICszODMsMzEgQEAKIAlpZiAoZXJyICE9IDApCiAJCXJldHVybiAoZXJyKTsKIAorCWRl dmljZV9wcmludGYoc2MtPnNjX2RldiwgImFyc3dpdGNoX2F0dGFjaCA3XG4iKTsKKwogCS8qIERl ZmF1bHQgdG8gaW5ncmVzcyBmaWx0ZXJzIG9mZi4gKi8KIAllcnIgPSBhcnN3aXRjaF9zZXRfdmxh bl9tb2RlKHNjLCAwKTsKIAlpZiAoZXJyICE9IDApCiAJCXJldHVybiAoZXJyKTsKIAorCWRldmlj ZV9wcmludGYoc2MtPnNjX2RldiwgImFyc3dpdGNoX2F0dGFjaCA4XG4iKTsKKwogCWJ1c19nZW5l cmljX3Byb2JlKGRldik7CiAJYnVzX2VudW1lcmF0ZV9oaW50ZWRfY2hpbGRyZW4oZGV2KTsKIAll cnIgPSBidXNfZ2VuZXJpY19hdHRhY2goZGV2KTsKIAlpZiAoZXJyICE9IDApCiAJCXJldHVybiAo ZXJyKTsKLQkKKworCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwgImFyc3dpdGNoX2F0dGFjaCA5 XG4iKTsKKwogCWNhbGxvdXRfaW5pdF9tdHgoJnNjLT5jYWxsb3V0X3RpY2ssICZzYy0+c2NfbXR4 LCAwKTsKIAogCUFSU1dJVENIX0xPQ0soc2MpOwogCWFyc3dpdGNoX3RpY2soc2MpOwogCUFSU1dJ VENIX1VOTE9DSyhzYyk7Ci0JCisKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJhcnN3aXRj aF9hdHRhY2ggMTBcbiIpOworCiAJcmV0dXJuIChlcnIpOwogfQogCg== --=_mailhost.netlab.sk-22601-1394350765-0001-2--