From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 18:11:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A245EE2 for ; Fri, 3 Jan 2014 18:11:41 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F126314EE for ; Fri, 3 Jan 2014 18:11:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz9Dg-0002nG-3M; Fri, 03 Jan 2014 18:11:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s03IBa4W024148; Fri, 3 Jan 2014 11:11:36 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/iHvqRYkQLwvk7HNRwnwTU Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Markus Pfeiffer In-Reply-To: <20140103175914.GC98342@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 11:11:35 -0700 Message-ID: <1388772695.1158.288.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:11:41 -0000 On Fri, 2014-01-03 at 17:59 +0000, Markus Pfeiffer wrote: > Hi Ian, > > On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: > > On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > > > Hi all, > > > > > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > > > > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > > > > > Now I just have to figure out why this "fixes" it, and what damage that patch > > > does. > > > I also have some pathces for the LED on the dockstar which will tip up in my > > > github soon. > > > > > > Cheers, > > > markus > > > > After looking at the marvell code and docs, and some info I found about > > the dockstar at OpenWRT.org, I think the attached patch is the right fix > > for a dockstar (it maps the nand flash, and removes mappings for NOR > > flash and an LED; the dockstar doesn't seem to have NOR flash, and the > > LED thing seems to be out of place). > > > > Can I find information anywhere as to what this ranges command actually means? > I was assuming it has something to do with memory mappings, but I didn't find > any info as to what in particular the 0x2f _means_. > The information is in a PDF document from Marvell: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf The info is a little hard to puzzle out. The 0x2f is the attribute for mapping NAND flash; it's found near the end of Table 4. Because the attribute value was wrong in that dts you were using (it's a value not even listed in the table) I suspect it was making some kind of crazy dram or other device mapping that was interfering with normal memory access. > > Markus, could you please test this; if it works, I'll commit it. The > > only marvell hardware I have for testing is DreamPlug. > > It does indeed work. I am a bit surprised that noone seems to be running > FreeBSD on a dockstar seriously enough to run into these problems. > > Some ugly problem in connection with USB seems to rear it's head atm: if I > fsck a filesystem, it finds a lot of DUPs and starts deleting perfectly fine > files. I changed to using sync as well as disabling clustered reads and > writes. Maybe I'll find the time to investigate this issue as well. > This sounds a bit similar to a problem posted some weeks (hmmm, at this point maybe some months) ago relating to data corruption on USB disk IO on a SheevaPlug (same kirkwood chip). I wasn't able to recreate it then with a quick minimal effort. I need to put better effort into it soon, I think. > I hacked a bit on the gpio/led driver to make the LED work with gpioled, I'll > post a patch to the mailing list when it's cleaned up if that's ok. By all means. That might even be something I can use; my DreamPlugs have LEDs, and the green one is crazy-bright, I'd love to turn it off. Either way, I can get it committed for you. -- Ian