From owner-freebsd-mips@FreeBSD.ORG Mon May 20 17:42:05 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A3BAA78; Mon, 20 May 2013 17:42:05 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 419B08DF; Mon, 20 May 2013 17:42:04 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3bDnVL6qkJz1JH; Mon, 20 May 2013 18:42:02 +0100 (BST) Message-ID: <519A605D.8020304@rewt.org.uk> Date: Mon, 20 May 2013 18:41:49 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Milan Obuch Subject: Re: Ubiquiti EdgeRouter Lite works multi-user with -CURRENT. References: <20130516111059.38543d57@wind.dino.sk> <20130516131642.adfae355aa3bf7767e9b56e5@ddteam.net> <20130516124248.33ae4e05@wind.dino.sk> <51952112.9010607@rewt.org.uk> <20130517192206.5db0533f@zeta.dino.sk> <51966CB6.2040701@rewt.org.uk> <20130520110659.1d1d2165@zeta.dino.sk> <20130520164001.5f7d99b8@zeta.dino.sk> <20130520172508.087daf7b@zeta.dino.sk> <20130520173934.099ea541@zeta.dino.sk> In-Reply-To: <20130520173934.099ea541@zeta.dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , "freebsd-mips@FreeBSD.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:42:05 -0000 Milan Obuch wrote: > On Mon, 20 May 2013 08:27:40 -0700, Juli Mallett > wrote: > >> On Mon, May 20, 2013 at 8:25 AM, Milan Obuch >> wrote: >>> Yes, output is from 'gpioctl -f /dev/gpioc0 -lv' command execution. >>> Actually, I wrote all 16 pins (0 to 15) in >>> sys/mips/cavium/octeon_gpio.c so I can see quickly which GPIO pin >>> is connected to reset switch. Pin 11 changed when pressing the >>> switch. >> Could you try commenting out everything but pin 11 in octeon_gpio.c >> and rebuilding? I'm wondering if one of those pins may have been >> in-use to talk to some Ethernet hardware or something like that, and >> that its operation was disrupted by the GPIO driver. > > As far as I know, it behaved this way even before I added those pin > definition into GPIO driver. Actually, full output is > > gpioctl -f /dev/gpioc0 -lv > pin 00: 0 F/D0, caps: > pin 01: 0 F/D1, caps: > pin 02: 0 F/D2, caps: > pin 03: 0 F/D3, caps: > pin 04: 0 F/D4, caps: > pin 05: 0 F/D5, caps: > pin 06: 0 F/D6, caps: > pin 07: 0 F/D7, caps: > pin 08: 1 F/D8, caps: > pin 09: 1 F/D9, caps: > pin 10: 1 F/D10, caps: > pin 11: 1 F/D11, caps: > pin 12: 0 F/D12, caps: > pin 13: 0 F/D13, caps: > pin 14: 0 F/D14, caps: > pin 15: 0 F/D15, caps: > > and does not change with link status on ethernet port (any). But I will > test it with only pin 11 left there, just in case I overlooked > something. > > Regards, > Milan Hm, I do recall seeing something in a document somewhere that suggested it used gpio/i2c to talk to the PHYs due to the design they've used, is there any way of dumping accesses/messages across gpio pins (without soldering) ?