From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 15:30:44 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 604A4E8 for ; Thu, 19 Sep 2013 15:30:44 +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 A8FE42640 for ; Thu, 19 Sep 2013 15:30:43 +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 r8JFUeTl054268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Sep 2013 11:30:42 -0400 (EDT) (envelope-from rrs@lakerest.net) Subject: Re: Trouble with a dream plug... Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randall Stewart In-Reply-To: <523B14A6.8070209@gmail.com> Date: Thu, 19 Sep 2013 11:30:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <523B14A6.8070209@gmail.com> To: Mattia Rossi X-Mailer: Apple Mail (2.1283) Cc: ARM 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 15:30:44 -0000 Mattia: in-line ;-) On Sep 19, 2013, at 11:13 AM, Mattia Rossi wrote: > Hi Randall, >=20 > it's not on the FreeBSDMarvell wiki, but Ian (if I remember correctly) = already added all the necessary tweaks to get FreeBSD on the DreamPlug. = In fact, I'm running the most recent HEAD on it, compiled with Clang. = Both ETH interfaces working, so far no trouble. > He has also created the Kernel for the NAND-Version of the Dreamplug, = which supposedly has an N after the Version number. I'm not too sure = which one you have. > But before getting old trying to fix the DB-* and SHEEVAPLUG Kernconfs = and FDT's I'd suggest t compile using >=20 > KERNCONF=3DDREAMPLUG-1001 Yep, I see that was my error.. I have it up now same .. with head and = clang ;-) I do think the checks in it for pm_is_disabled() and fdt_pm() is = incorrect. According the the marvell spec I have the power management register is at 18 not 1c. I = don't know if this is just my version of the chipset that has this or what. The spec I got is FS_88F6180_9x_6281_OpenSource and it seems correct when I do some debugging and have it give me both the 0x1c and 0x18 register. At least the values returned match the spec.. i.e. 0 =3D=3D device enabled, 1 =3D=3D device disabled = and the 1c register matches what I would guess is the correct settings for the clocks. I am wondering if this is just a code error ... >=20 > Then I'd suggest to use a FAT partition on the internal SDcard of the = dreamplug to host/store the kernel and an additional partiion (or more) = for the world. Yeah that was my next step after I play a bit with it and make sure I = can restore it. My initial boot of the right dream-plug configuration tried to go out to = da0s1, but I changed it locally back to NFS while I am testing. I will move shortly to = booting from flash ;-) >=20 > If the FAT partition is your first partition on the SDcard it will be = da0s1 so change the DREAMPLUG-1001 config file accordingly at the = rootdevice option. >=20 > I'd also suggest to put the world/root on a USB Stick to boot the = first time, and use that instead of the nfs root. > I usually tar and untar world on the stick using the -p option. > On upgrades just remember to do a 'chflags -R noschg *', but I guess = you'd know that. > Remember to set the rc.conf and fstab files up properly. The device = will be da1s1 (or da2s1 if you have an additional sdcard in the sdcard = slot) >=20 > Boot the dreamplug with the usb stick attached, then: >=20 > in U-Boot stop autoboot, then type: >=20 > set ipaddr > set serverip > usb start > tftpboot 0x900000 /kernel.bin > go 900000 >=20 > It should boot, and the kernel should fail to find the root, so just = type ufs:/da1s1 (or da2s1 if you have an additional sdcard in the sdcard = slot) >=20 > then go on booting. You should land in multiuser mode. Cool I will give it a whirl... >=20 > Partition the internal disk into a small msdosfs partition (da0s1) and = a larger (or multiple) root (da0s2) partition(s) (I use ufs) > copy the kernel (tftp) into the msdosfs partition and the world onto = the other partition(s). > If you fixed the kernel config before, the kernel will look for the = root file system on the right spot (da0s2). > Next time you boot you just need to change the x_boot_cmd variable in = u-boot to: >=20 > fatload usb 0 0x900000 kernel.bin >=20 > and the autoboot variable to go 900000 -> that's somewhat trickier and = I can't remember how i did it... > Ask again once you got there. Ok sounds good .. I will give it a go ;-) >=20 > =46rom there on, you should be able to autoboot your dreamplug into = FreeBSD Multiuser without hassle. Neat!! Do you know if the wifi has a driver for this puppy, or is it something = yet to be done ;-) I see the dts does not include a reference to it so I suppose its a "not = yet done" thing ;-D R >=20 > Hope that helps, >=20 > Mat >=20 > Am 19.09.2013 14:24, schrieb Randall Stewart: >> 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 >> 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 >> 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: >> 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: >> 00 00 00 01 >> phy-handle: >> 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)