Date: Thu, 19 Sep 2013 10:56:29 -0400 From: Randall Stewart <rrs@lakerest.net> To: ARM <freebsd-arm@freebsd.org> Subject: Re: Trouble with a dream plug... Message-ID: <6ED6910A-C3C0-432A-B3FF-6F2D76EB6869@lakerest.net> In-Reply-To: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok So I figured it out ;-) Turns out there is a DREAMPLUG configuration.. which then gets the right fdt.. I did not realize we compile it into the kernel..=20 But I have noticed one issue at least with my dream plug.. The power management chip, consulted to see whats up and not, is defined as 0x1c in the mvreg.h. And yet in the spec its 0x18 for at least my model of the chip from marvel). Now another curious thing is that when you read the register, its 0 if its on and 1 if its disabled.=20 The code seems to do the opposite=85 i.e. look for a 1 if its enabled and 0 for not. I suspect this is due to the fact that 0x1c is the clock timing register and the 1's are were being mistaken for "on" when they were looking at the wrong register. It could be that the chip changed however, so I am ifdef'ing all my changes to be around the KIRKWOOD chip. I will supply a patch as soon as I make sure this all does not blow up when I bring it up ;-) R On Sep 19, 2013, at 8:24 AM, Randall Stewart wrote: > Hi all: >=20 > I am playing with a DreamPlug which has the marvell 88F6281 chip set > in it: >=20 > http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx >=20 > The version number of this seems to be 3. >=20 > When I first tried to bring it up following the wiki: > https://wiki.freebsd.org/FreeBSDMarvell >=20 > I had no joy, the system would boot up until it tried to find the = ethernet and die=85 >=20 > 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). >=20 > 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? >=20 > 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 > **************************** >=20 >> =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? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Any pointers or hints would be appreciated. >=20 >=20 > R >=20 >=20 > ------------------------------ > Randall Stewart > 803-317-4952 (cell) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ED6910A-C3C0-432A-B3FF-6F2D76EB6869>