Date: Thu, 19 Sep 2013 18:28:25 +0200 From: Mattia Rossi <mattia.rossi.mate@gmail.com> To: Randall Stewart <rrs@lakerest.net> Cc: ARM <freebsd-arm@freebsd.org> Subject: Re: Trouble with a dream plug... Message-ID: <523B2629.6080101@gmail.com> In-Reply-To: <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <523B14A6.8070209@gmail.com> <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I just top-post for simplicity: The WiFi and Bluetooth chips sit on a SDIO card. SDIO support is currently being hacked together as far as I'm aware (I'm not involved). About the WiFi driver itself, I recall some messages going on about it, and it seems that that driver needs to include some marvell specific SDIO magic and that it would be tricky to port from Linux. Mat On 19/09/13 17:30, Randall Stewart wrote: > Mattia: > > in-line ;-) > > On Sep 19, 2013, at 11:13 AM, Mattia Rossi wrote: > >> Hi Randall, >> >> 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 >> >> KERNCONF=DREAMPLUG-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 == device enabled, 1 == 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 ... > > >> 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 ;-) > >> 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. >> >> 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) >> >> Boot the dreamplug with the usb stick attached, then: >> >> in U-Boot stop autoboot, then type: >> >> set ipaddr <an available ipv4 address> >> set serverip <tftp ipv4 server address> >> usb start >> tftpboot 0x900000 <location>/kernel.bin >> go 900000 >> >> 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) >> >> then go on booting. You should land in multiuser mode. > Cool I will give it a whirl... > >> 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: >> >> fatload usb 0 0x900000 kernel.bin >> >> 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 ;-) > >> From 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 > >> Hope that helps, >> >> Mat >> >> Am 19.09.2013 14:24, schrieb Randall Stewart: >>> 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… >>> >>> 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 >>> 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 >>> **************************** >>> >>> From 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) >>> >>> _______________________________________________ >>> 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" > ------------------------------ > Randall Stewart > 803-317-4952 (cell) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?523B2629.6080101>