From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 12:48:08 2013 Return-Path: Delivered-To: freebsd-arm@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 ESMTP id 42B03730 for ; Thu, 19 Sep 2013 12:48:08 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4F992B1D for ; Thu, 19 Sep 2013 12:48:07 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8JCOnJ4049162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Sep 2013 08:24:52 -0400 (EDT) (envelope-from rrs@lakerest.net) From: Randall Stewart Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Trouble with a dream plug... Date: Thu, 19 Sep 2013 08:24:49 -0400 Message-Id: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> To: ARM Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 12:48:08 -0000 Hi all: I am playing with a DreamPlug which has the marvell 88F6281 chip set in it: http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx The version number of this seems to be 3. When I first tried to bring it up following the wiki: https://wiki.freebsd.org/FreeBSDMarvell I had no joy, the system would boot up until it tried to find the = ethernet and die=85 So with a bit of playing I figured out that the miiphy was incorrect, it = was trying to use 8 and I found with a bit of poking that the two phys are on 0 and = 1 (There are two Marvell Gig-E's on this critter). Now after I got it to boot, I wanted to find a way to get the second = ethernet up. Linux (which comes with it of course) finds both of them so why can't I? So after digging some and learning about the flattened device tree, I = find that the layout of this in respect to the ether-net is as follows (reported by a modified ofwdump.. I had = to make it so that=20 it did not exit when it sees a next-prop return an error, evidently this = little arm just gives you an error, not a 0 back when you hit the end of the properties). = Anyway here is my=20 ethernet description: ********************************* Node 0x840: ethernet@72000 #address-cells: 00 00 00 01 #size-cells: 00 00 00 01 model: 56 32 00 'V2' compatible: 6d 72 76 6c 2c 67 65 00 'mrvl,ge' reg: 00 07 20 00 00 00 20 00 ranges: =20 00 00 00 00 00 07 20 00 00 00 20 00 local-mac-address: 00 00 00 00 00 00 interrupts: 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e interrupt-parent:=20 00 00 00 01 =20 phy-handle: =20 00 00 00 02 ------------Child of the E-net ------------ Node 0x918: mdio@0 #address-cells: 00 00 00 01 #size-cells: 00 00 00 00 compatible: 6d 72 76 6c 2c 6d 64 69 6f 00 'mrvl,mdio' ---------Child of the mdio ----------- Node 0x95c: ethernet-phy@0 reg: 00 00 00 08 phandle: 00 00 00 02 **************************** =46rom this you can see where the idea of the phy being at 8 is coming = from. Its sure enough is in the ethernet-phy. Now I am *not* sure what an mdio is = supposed to do for us, and even more strange is how does linux seem to be able to bring = up both ports on this? The spec's say that the first port is at 72000 - 73fff and the second is = at 76000 - 77fff. And of course with no FDT description we won't see it. Is our friend linux just assuming that its at those addresses? We end up = with a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses 0xb = for eth0 and 0xf for eth1. Anyone out there familiar with why I can't see the second network? Is = this a bad fdt that came from the vendor? or do we need to just have driver = hacks in that "assume" the second one is there? If so I am not sure how to deal = with the IRQ's can we just allocate one? Linux seems fine with doing that unless there = is something I am missing in my limited understanding of the FDT stuff. Any pointers or hints would be appreciated. R ------------------------------ Randall Stewart 803-317-4952 (cell)