Date: Thu, 19 Sep 2013 11:30:40 -0400 From: Randall Stewart <rrs@lakerest.net> To: Mattia Rossi <mattia.rossi.mailinglists@gmail.com> Cc: ARM <freebsd-arm@freebsd.org> Subject: Re: Trouble with a dream plug... Message-ID: <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> In-Reply-To: <523B14A6.8070209@gmail.com> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <523B14A6.8070209@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <an available ipv4 address> > set serverip <tftp ipv4 server address> > usb start > tftpboot 0x900000 <location>/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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5487FF65-DEF3-4ABF-A72B-CAD0FD35659C>